OEM, ANSI, and Unicode considerations

Most of the iSeries™ Access for Windows^® C/C++ APIs that accept string parameters exist in three forms: OEM, ANSI, or Unicode.

The generic version of the iSeries Access for Windows 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 definitions
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
```
See 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.