The Windows-native localization model differs from that of IBM C and C++ Compilers in two ways:
1. Windows and IBM C and C++ Compilers
Locales
The Windows-native localization model (as supported by
the Win32 APIs) is not the same as the POSIX model supported by
IBM C and C++ Compilers. For this reason, changing the country via
the Control Panel will not alter the cultural behavior
of your IBM C and C++ Compilers application. Similarly, changing the LC_ environment
variables will have no effect on an
application calling native-Windows APIs.
Further, confusion may arise because both the Windows operating system and IBM C and C++ Compilers files are known as locales and, while there is some similarity between the two, each is a distinct implementation.
2. Windows ANSI and Windows OEM Code
Pages
The Windows operating systems support two classes of code
page:
Because locales are bound to a specific code page, there must be a separate locale for each country-language-codepage combination. If you want the locale that is bound to the ANSI code page, you must specify the codeset-qualified name that identifies the code page. For example, the following specifies the English, Great Britain, code page 1252:
en_GB.IBM-1252
For locales bound to OEM code pages, you should specify only the language-country name. For example, the following identifies French Canada, using the currently active code page:
fr_CA
Windows controls (e.g. entry fields, list boxes, menus, multi-line edit, etc.) use the ANSI code page. If the source or target of the data is a Windows control, your application must use the locale bound to the ANSI code page. Otherwise, you can use the locale bound to the OEM code page.
![]()
Internationalization
Localization and
Locales
![]()
Make Your
Program International