This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj (UPDATED)
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: tromey at redhat dot com, luciano at virgilio dot it, Ranjit Mathew <rmathew at hotmail dot com>, GCJ Patches <java-patches at gcc dot gnu dot org>, java at gcc dot gnu dot org, MinGW Developer <mingw-dvlpr at lists dot sourceforge dot net>, João Garcia <jgarcia at uk2 dot net>
- Date: Thu, 04 Dec 2003 18:43:30 -0600
- Subject: Re: [PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj (UPDATED)
- Reply-to: gnustuff at thisiscool dot com
Hi Bryce,
>> This patch supersedes this:
>>
>> http://gcc.gnu.org/ml/java-patches/2003-q4/msg00430.html
>>
>> ...and attempts to address the outcry from those who didn't
>> want the UNICOWS licensing restrictions on Win9X. It adds
>> a configure switch for the compiler called --enable-libgcj-mingw-osapi
>> which can take one of three values:
>>
>> ansi: Use the char and the Win32 A functions natively, translating
>> to and from UNICODE when using these functions.
>>
>> unicows: Use the WCHAR and Win32 W functions natively. Adds -lunicows
>> to libgcj.spec to link with libunicows. unicows.dll needs to be
>> deployed on Win9X machines running built executables.
>>
>> unicode: Use the WCHAR and Win32 W functions natively. Does not add
>> -lunicows to libgcj.spec. The built executables will only run
>> on WinNT and above.
>
>Which is the default?
The default is ansi.
>Am I right in assuming that this gives the choice between:
>ansi: libgcj that works everywhere, but is somewhat inefficient because
>it converts all strings twice
>unicows: libgcj that works everywhere but requires third party
>libunicows to be available, and unicows.dll at runtime on win9x
>unicode: fast libgcj that needs no extra library but only runs on >=
>Win NT
100% correct (actually WinNT converts the strings from ANSI to UNICODE
internally).
>I'm presuming its just not really possible to just determine at runtime
>which (ansi or unicode) should be used, right?
It is, but I deemed this way more trouble than it's worth. Eventually, the
ANSI stuff will be phased out when Win9X dies its welcome^H^H^H^H^H^H^H
inevitable death and removing the extraneous code can be done in a couple
of minutes. No one seemed to care about the runtime inefficiency. (All things
considered, I don't think it's a big deal either.)
>Please be sure to document this in gcj.texi.
Will do. I'm still on the hook for --enable-libgcj-multifile too.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/