This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Hi Mohan,

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

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

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]