OEM, ANSI, and Unicode considerations

Most of the C/C++ APIs that accept string parameters exist in three forms: OEM, ANSI, or Unicode.

The generic version of the C/C++ APIs follows the same form as the default OEM version. Only a single name for each function appears in this information, but there are three different system entry points. For example:

cwbNL_GetLang();

	compiles to:

cwbNL_GetLang();    //CWB_OEM or undefined

		or:

cwbNL_GetLangA();   //CWB_ANSI defined

		or:

cwbNL_GetLangW();   //CWB_UNICODE defined
Table 1. API types, name formats, and pre-processor definition
API type API name format (if it exists) Pre-processor definition
OEM cwbXX_xxx None (may specify CWB_OEM explicitly)
ANSI cwbXX_xxxA CWB_ANSI
UNICODE cwbXX_xxxW CWB_UNICODE
Note:
  • Data transformation APIs (cwbDT_xxx) do not follow the "A" and "W" suffix conventions. The generic version of the APIs uses "String" as part of the function name. The ANSI/OEM version uses "ASCII" as part of the function name. The Unicode version uses "Wide" as part of the function name. There is no difference between OEM and ANSI character sets in cwbDT_xxx APIs, which handle numeric strings. Therefore, ANSI and OEM versions of the relevant APIs are the same. For example:
    cwbDT_HexToString();
    
    	compiles to:
    
    cwbDT_HexToASCII();   //CWB_UNICODE not defined
    
    		or:
    
    cwbDT_HexToWide();    //CWB_UNICODE defined
    
    Select the related link to the data transformation cwbdt.h header file for more details.
  • For Unicode APIs that take a buffer and a length for passing strings (for example, cwbCO_GetUserIDExW), the length is treated as the number of bytes. It is not treated as the number of characters.