Re: extracting code page of current locale

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Feb 12 2004 - 16:18:42 EST

  • Next message: Rick McGowan: "New Public Review Issue posted"

    From: "Rick Cameron" <Rick.Cameron@businessobjects.com>
    To: "unicode" <unicode@unicode.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
    intended.
    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
    appropriate.
    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
    I/O functions.

    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