At 08:17 AM 7/20/00 -0800, John O'Conner wrote:
>2. Compiling your app as a UNICODE application means that all Win32 API calls
>use Unicode-enabled versions of the API. Text areas expect you to pass
>Unicode, and it displays correctly when an appropriate font is used.
Even if you don't compile an application as UNICODE you can make calls to
the Unicode version of a Win32 API function by appending a W to the end of
This is a useful technique to allow programs for Win9x to access the half
dozen API functions that are implemented for Unicode on that platform.
When might you want to do that? For example if you write an editor. The low
level text output functions support Unicode on Win9x, so you can write an
editor that lets you display and edit Unicode text and support Unicode
fonts quite easily. The same editor can run unchanged on NT.
In the scenario I mentioned, Menus, Dialogs, etc. are still limited to what
MS calls the "ANSI" character set on Win9x. On NT, you would need to use
the Unicode version of these, which is easiest done by compiling the
application with #define UNICODE.
You can see how this leads to a hybrid design where the UI support might be
separately compiled for NT and Win9x, but the 'engine' of your application
resides in a DLL that, unencumbered by standard dialog controls, can be
written in Unicode, still display data using Unicode and support a common
file format for you application.
MSJ publishes articles on this and related topics at regular intervals -
check Microsoft's MSDN for this kind of information.
Finally, there are commercially released libraries that will insert
themselves between a UNICODE application when it's running on Win9x and
redirect the API calls to the ANSI version of the API (they attempt to do a
conversion of the text in the string parameters). This should work quite
well, as long as the user on the Win9x system doesn't need to use
non-native characters in dialogs or filenames.
You might want to check out the "Cheops" product from Basis Technology
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:06 EDT