Re: Experimental UNICODE-only MinGW Build]

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

Hi Mohan,

>I am still sensing some hesitation about the unicows.dll option which I'd
>like to resolve with you.
>

After this post from Luciano:
http://gcc.gnu.org/ml/java/2003-11/msg00243.html

I am absolutely convinced that, at this moment, unicows is not a good 
solution.
Unless you would like to deeply penalize many users (mainly based in 
developing
countries or using older laptop/desktop PCs). This would, for sure, affect
Win9X/Me users. So, at this moment, I am totally against unicows as an 
exclusive
solution.

To kill Win9X/Me is a main objective to MS for obvious reasons. Why would
you want to help them? They can manage by them selves. They may achieve the
objective at some point in time. But an OS with so many users is not really
dead at the moment (users make the rules here)...


Besides that, I think that your patch should implement the configuration 
switch
anyway. There are several reasons to support this argument. But my main 
one is
that we should live the door open for simple and rapid-development 
patches all
across libjava. To force your unicode solution across java.io and 
java.nio (or
even more portions of libjava):

- would lead to many changes in function names and type casts.

- would make it difficult to go back to a unified solution with POSIX 
(which I
think it would be good because of code maintenance in the future).


Unless one of your main objectives is to delay the usability of gcj
across a global scope of applications, I do not see any reason to oppose
to the configuration switch and to the 
MultiByteToWideChar()/WideCharToMultiByte()
support when UNICODE is unset. It is the most democratic one (and it also
does not limit future development options).


I am also surprised (and somehow disappointed, because I like coherent 
arguments)
that your aesthetic sense is not deeply shocked by the nature of unicows.
And also that you are rejecting the beauty of the configuration switch 
solution
combined with MultiByteToWideChar()/WideCharToMultiByte() support when 
UNICODE is
unset (the major beauty here is not in the programing side of it -- 
although there
is also merit on the programing side).

I also hope that you do not let your wrath against Win9X/Me break
anything else related with that platform on libjava. This would not be very
democratic... And do not forget that Standard JVMs have support for
Win9X/Me.

I also do not like Win9X/Me. But I like to support all users, so it is a 
good
platform for preliminary tests of applications in Windows environment. 
If an
application can run there, it can, in theory, run across all Win32 
desktop platforms
(although I have some Java code that can run on Standard JVM but, when 
compiled with
gcj, will run on Win9X/Me but will fail to run in NT/2000/XP -- it is 
mainly SWT
related code and there are known workarounds, so it is not a priority).


João