Experimental UNICODE-only MinGW Build]

Mohan Embar gnustuff@thisiscool.com
Fri Nov 21 13:11:00 GMT 2003


Hi João,

>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)...

Throughout your posts, you seem to equate the necessity of including a
245K DLL with killing Win9X. For me, these two things aren't synonymous.

>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):

Let's not forget that Java is UNICODE by nature. We only break out
of that for locale-specific stuff and in some cases, to accomodate an
OS API.

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

I don't understand this. Could you clarify this?

>- 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).

Go back to a unified solution? I can't imagine this being remotely
possible even without my change.

>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).

Again, why the resistance to the inclusion of a tiny 245K DLL?

>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.

On the contrary: I sort of like UNICOWS because it reminds me of a JVM
and also libjava: I get a uniform API so I don't have to deal with variations
across the underlying platforms. The only thing I don't like is its
redistribution policy. It also sort of reminds me of Win32s, which I didn't
think was a bad thing for the goals it was trying to accomplish.

>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).

The configuration solution is somewhat aesthetic, but for me, the cost
of an additional configuration inclines me to let MS manage the problem
with their 245K DLL.

>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.

First of all, I would like to think that all of my actions thus
far have proven that despite my being appointed to review Win32
patches, that I have taken a democratic approach to the point of
disqualifying myself from making this decision.

Secondly, I do not want to break Win9X for one of the main reasons
you mentioned: the continued use of this OS in developing countries.
I take this very seriously. I do not consider the requirement of the
inclusion of a 245K DLL as breaking Win9X.

Thirdly, Win98 is due to enter its non-supported phase in a couple of months:

http://www.microsoft.com/windows/lifecycle/desktop/consumer/default.mspx

...with its end-of-life being in a year from now. I highly doubt that
standard JVMs will continue to officially support an OS for longer than
the OS vendor does.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/





More information about the Java mailing list