NLS Overview of Windows 95 and OS/2
NLS on Windows 95
Windows 95 supports codepage and language/locale information. Basically, a codepage takes effect on the character string parsing and code conversion, and a language/locale takes effect on cultural information operation and culture-dependent character operation.
Codepage is a system global property for Windows 95 applications. A system default value is set up at Windows 95 installation and all application programs inherit this value. There is no API to change this codepage for application programs.
Language/locale information is a property of a thread according to WIN32 specification. (On Windows 95, since the SetThreadLocale API to change thread's locale is not supported, it can be considered/treated as a property of a process on Windows 95.) As default, the system default locale and the user default locale is provided, the latter of which can be changed by the user. Each application program invoked by the user has the user default locale, so the system default locale is not so important for application programs if they don't stick to the system default locale.
Windows 95 supports a limited set of functions that handle Unicode-encoded
strings, but application programs on Windows 95 can utilize Unicode internally
to simplify the string parsing logic and/or to handle one or more (large
Asian) character sets at a time, after converting character strings by MultiByteToWideChar
API. (Of course, those Unicode strings can be converted back to multi-byte
strings by WideCharToMultiByte API.) Unicode texts can be outputed by using
the limited set of Unicode-enabled GDI func tions such as ExtTextOutW and
MessageBoxW.
NLS on OS/2
OS/2 supports conventional country information such as country code, codepage, collating table, DBCS vector, etc., and newly supports Universal Language Support (ULS) information. The ULS includes locale functions and code conversion functions (code conversion from a certain character set to Unicode, vice versa, and between a certain character set to another character set). Since both locale and code conversion are object based (to use them, application programs need to create an associated object to operate on), they can be utilized to emulate Windows 95's thread-based, object based locale/code conversion. (Windows 95 does not request apps to create an object unlike ULS, but it allows to operate on any installed codepage/locale by specifying it as a locale/codepage ID.)
At C-library level, OS/2 supports XPG/4 compliant locale information. However, since this support is process-based except for code conversion (ICONV), Open32 cannot utilize XPG/4 compliant functions without the client-server mechanism that introduces a special locale server.
Existing OS/2 APIs are not yet Unicode-enabled. They accept input strings only in a multi-byte form. Therefore, Open32 needs to map Unicode Windows APIs to existing, multi-byte OS/2 APIs after converting strings from Unicode to multi-byte.