From: Philippe Verdy (email@example.com)
Date: Thu Feb 12 2004 - 16:18:42 EST
From: "Rick Cameron" <Rick.Cameron@businessobjects.com>
To: "unicode" <firstname.lastname@example.org>
Sent: Thursday, February 12, 2004 9:23 PM
Subject: RE: extracting code page of current locale
> The function setlocale is a CRT function; GetACP (and other candidates like
> GetUserDefaultLCID) is a Win32 function - and ne'er the twain shall meet!
> Setting the CRT's locale using setlocale will not, I believe, change the OS
> current user locale, and vice versa.
> My advice: shun the CRT's locale-related functions like the spawn of Satan.
> Use the Win32 functions exclusively.
It seems more reasonnable to write its own wrapper that will use OS-specific
modules implementing them with a portable internal API in the application. The
CRT's setlocale() could be this wrapper as well: write your own version of
setlocale() and link with it before the CRT library, so that your function will
shunt the defective CRT implementation which does not perform all what is
Note that on Windows, most locale-related functions are macros that call actual
functions in the CRT library starting by an underscore. So you can write your
wrapper by disabling these macros and writer functions with the same name that
will use the underscored versions in the CRT if necessary, or the Win32 API when
Also note that GetACP() will only return the codepage used when calling ANSI
versions of the Win32 API and passing them 8-bit or DBCS encoded strings.
There's a similar function to get the "OEM" codepage when calling functions
working with the Console or FAT/FAT32 (non-LFN) filenames.
In fact it becomes just simpler today to compile the application for Unicode and
get way from the ANSI and OEM codepage conversions. Wrappers for the Unicode
Win32 API then become necessary only for a few application-level APIs that don't
work on Windows 95/98/ME with the Win32 Unicode API (in fact the UCS2 API on
Windows NT/95/98, and a UTF-16 API on Windows ME/2000/XP and later that are
enabled with support for Chinese GB18030 and its needed surrogates): notably the
Shell API (shortcuts, notifications in the System Tray, menu items), and Console
It's not extremely complicate to support the transparent conversion from your
internal Unicode application to the external system ANSI or OEM codepages on
Windows 95/98/ME, using the builtin converters supported on Windows 95
(WideCharToMultiByte and MultiByteToWideChar).
The restriction is that these converters will only work with the current ANSI
codepage or current OEM codepages, and that Windows 95/98/ME do not support
changing these 8-bit codepages (you must use those as they are defined on the
runtime system, unlike on Windows NT/2000/XP where you can specify the 8-bit or
MBCS codepage you want, provided that these codepages are installed by the
Administrator in the "Regional settings" of the Control panel: a normal
installation of Windows NT/2000/XP will install a core set of codepages which
will include at least the default codepage for the system localization, the
Windows 1252 codepage, and OEM codepages 437 and 850; almost all other codepages
are optional and the set of codepages varies depending on administrator's
preferences and the OS localization).
This archive was generated by hypermail 2.1.5 : Thu Feb 12 2004 - 17:14:36 EST