This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Experimental UNICODE-only MinGW Build]
- From: João Garcia <jmgarcia at abscindere dot com>
- To: gnustuff at thisiscool dot com
- Cc: João Garcia <jgarcia at uk2 dot net>, java at gcc dot gnu dot org, luciano at virgilio dot it
- Date: Fri, 21 Nov 2003 15:28:12 +0000
- Subject: Re: Experimental UNICODE-only MinGW Build]
- References: <OIB6GC4YRNUTVHC42USWSQN75QMSPFC.3fbe0d75@d7500>
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