Experimental UNICODE-only MinGW Build]
Fri Nov 21 12:07:00 GMT 2003
>I am still sensing some hesitation about the unicows.dll option which I'd
>like to resolve with you.
After this post from Luciano:
I am absolutely convinced that, at this moment, unicows is not a good
Unless you would like to deeply penalize many users (mainly based in
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
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
anyway. There are several reasons to support this argument. But my main
that we should live the door open for simple and rapid-development
across libjava. To force your unicode solution across java.io and
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
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
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
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
combined with MultiByteToWideChar()/WideCharToMultiByte() support when
unset (the major beauty here is not in the programing side of it --
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
I also do not like Win9X/Me. But I like to support all users, so it is a
platform for preliminary tests of applications in Windows environment.
application can run there, it can, in theory, run across all Win32
(although I have some Java code that can run on Standard JVM but, when
gcj, will run on Win9X/Me but will fail to run in NT/2000/XP -- it is
related code and there are known workarounds, so it is not a priority).
More information about the Java