Re: Experimental UNICODE-only MinGW Build]

[João Garcia <jgarcia at uk2 dot net>]

I am re-sending this message to the maling list, because I've got this 
error in the first one:

ezmlm-reject: fatal: Sorry, I don't accept messages of MIME Content-Type 
'text/html' (#5.2.3)

It seems that my "plain text send" is not working well sometimes...
-----------------------------------------------------------------------

Hi Mohan,

Mohan Embar wrote:

>Hi Jeff,
>
>
>
>>>During this experiment, I changed my mind about UNICOWS. My stance 
is that
>>>making libgcj UNICODE-only and supporting WinNT / Win2K / WinXP 
elegantly
>>>and out-of-the-box is more important than inconveniencing Win9X 
users. I am
>>>also capitalizing on Bryce's post:
>>>
>>>
>>I don't have much of an opinion on the matter, but short of satisfying
>>everyone why not make win32 unicode a configure option, so those that 
need
>>it can have it?
>>
>>
>
>This hasn't been suggested already. I thought about this, but wanted 
to avoid
>mucking around in configure.in too much so this thing had a half a 
chance of
>going in this late in the game. I think it's a good idea, but, then again,
>we'd have another target to test and maintain....
>
>
>
I have just read your patch. It is beautiful, congratulations!
I hope it runs as well as it looks in all the situations proposed!

I think a win32 unicode configure option combined with your current 
patch would solve the so called "controversial decision".
Your patch would join the best of both worlds (at any time and at any 
need) and would render useless the A/W patch (your initial suggestion) 
that I was planing to propose.
It is also easy to maintain.

In other words: I think that you have a master piece lacking the final 
touch. :-)
This touch would include:
1- the win32 unicode configure option.
2- MultiByteToWideChar()/WideCharToMultiByte() support when UNICODE is 
unset (at least I have not found it in your patch).

Step 2 would allow the use without UNICOWS and would allow a preliminary 
use across several sections of libjava without too much type changes on 
function names.

I have just lost my motivation to finish the A/W patch. I will no longer 
do it. For me, the best way now would be to add the win32 unicode 
configure option (this way we could opt easily between the alternatives).
I would propose a patch to the configuration if I could, but it is out 
of my know-how at the moment.

If you or anyone else would do the configuration change, it would be great.
This is not only about Win9X, because I guess it would also allow other 
uses without changing too many function names at once. But if you really 
want to force the end of the support for Win9X over everybody else, and 
reduce it to UNICOWS (or even to no support at all) I will have to 
understand (this is no longer the main issue -- it seems that it would 
only affect "minorities" in less developed countries that might want to 
use programs compiled with gcj). Besides that, gcj would not fully 
replace a Standard JVM without Win9X support (but this may not be an 
issue for the guidelines of this project).

I also do not know if the libunicows static portion that you are willing 
to link with libjava has the GPL "special exception". But I am sure that 
someone will address this licensing issue.

Anyway. I like your patch very much and would never oppose to it (even 
if my single opinion would matter for the decision).

I have already written too much about this subject. I apologize to all 
the members of the mailing list...


João