[PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj (UPDATED)
Fri Dec 5 00:46:00 GMT 2003
>> This patch supersedes this:
>> ...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 >=
100% correct (actually WinNT converts the strings from ANSI to UNICODE
>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.
More information about the Java