[PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj (UPDATED)

Bryce McKinlay bryce@mckinlay.net.nz
Thu Dec 4 22:38:00 GMT 2003

Hi Mohan,

On Nov 24, 2003, at 5:25 AM, Mohan Embar wrote:

> 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? Am I right in assuming that this gives the choice 

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

I'm presuming its just not really possible to just determine at runtime 
which (ansi or unicode) should be used, right?

Please be sure to document this in gcj.texi.



More information about the Java mailing list