From: "Rick Cameron" <[EMAIL PROTECTED]> To: "unicode" <[EMAIL PROTECTED]> 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).
