Experimental UNICODE-only MinGW Build]

[João Garcia]

Hi Mohan,

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

No. What I say is that its distribution is difficult (and you have already
agreed to this) and would exclude many users (killing the use of 
gcj-compiled
applications for those users).
And there is a much more democratic solution available without breaking 
your own
options.
So, would you not share this democratic solution with all of us, please?
It is clearly within your power to do so.

Besides that, it is 245K + 399K = 644K (you forget the static portion in 
this post).
Anyway, you know that the size is not the main issue here. So, please
keep the noise level low...

 >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 accommodate an
 >OS API.

You should know that this is more than enough to block the use of gcj for
many purposes (restricting it to academic use). Please state here, for the
record, if this is an objective to achieve.

 >
 >>- would lead to many changes in function names and type casts.
 >
 >
 >I don't understand this. Could you clarify this?
 >

Just to begin with, please make a search on your own patch for:

- TCHAR

- _T

- _tcscpy

- _stprintf

- _tcslen

None of those changes would be strictly necessary at the moment, if you
would implement the unicode configuration switch. And we could start
by replacing only JV_TEMP_STRING for the Win32 version.


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

I deeply disagree. But this will not be my fight for sure. Again, lets 
keep the
noise level down, please. There are more fundamental things to fight 
for, and that
would make gcj more and more functional for more global purposes...


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

Because of what I have written above (again in this post you exclude the 
static
portion from your calculations).
And because it would not shut a door that would not need to be shut 
(except for
your own personal judgment).


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

Can you not thing of a better way to implement it?
Can you not think of a better way to ensure it is delivered to all 
Win9X/Me users
(perhaps using windows update)?


 >The only thing I don't like is its
 >redistribution policy.

This is the main thing. And it is bad enough as I have said to you many 
times.

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

For me, the only strength of Win32 is its usage by many users...
I would prefer to have Linux everywhere (or anything like it). But this
is not a perfect world.


 >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 have written to much about this already. But I will add some more again:
once again, you are not including the size of the static portion.

Could you please elaborate more on the cost of an additional configuration?
This should be quite easy for someone like you (or others in this 
mailing list)
if you would be willing to do it. Besides, the configuration is not that
different! It is only a define!!!...

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

I will ask you, once again, to re-consider you position.
Please do not impose your own will on others, when you have easy means 
at your
disposal to avoid doing so.


 >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

 From the link you have supplied:

-WinMe Direct OEM and Retail License Availability (end date) is December 
31, 2003
-WinMe System Builder License Availability (end date) is December 31, 2004
-Win98 System Builder License Availability (end date) is November 30, 2003
-Win98 SE System Builder License Availability (end date) is March 31, 2004

All products can still be licensed at current time!
And do you think that these licenses are not being sold? Think about
laptops at least...

Do you really think that this will change the following statistics much in
the following years?

http://www.w3schools.com/browsers/browsers_stats.asp


Users are not directly ruled by MS administrative strategy. And you will
not change the world alone.

And what about the WinMe users that will still have support?

- WinMe  End of Life (effective date after end of online self-help support)
  December 31, 2005.

If MS supports WinMe, Win9X is implicitly supported for most relevant 
things
(same platform branch).

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

Why not?
This would not give them much more effort than live the current support 
there!
I can assure you that function calls for Win9X API will not change in 
the future.

And your use of TCHAR assures parallel maintenance of code for libjava. 
So why would
we suppress this inherent backwards compatibility?

And WinMe will also still be supported by MS for a little longer.
(and, again, this will implicitly support Win9X).

Again, will you not leave the door open for others that might think like me?

If you still want to argue against all this, please find something 
really relevant for
not to support the configuration switch (a simple "#define" statement 
and a command line
parameter). Otherwise we are both loosing precious time!


João