ASCII and UNICODE Support

• “OptimExitW” is the UNICODE (wide) entry point
• “OptimExitA” is the ASCII (multibyte) entry point

Each of these entry points has two parameters: a code depicting the exit point that is calling the exit, and the address of a callback you can use to get, set, or test information using Optim from your code. The differences between the two entry points is that the callback provided to the ASCII (multibyte) uses “char” parameters, while the UNICODE (wide) uses “wchar_t” parameters.

The wide characters are platform specific: some platforms use 16 bit UTF-16 with surrogates (Windows, I86 Linux®, AIX®), while others use 32 bit UTF-32 encodings (Solaris and HPUX). Unicode is also subject to “Endian” bit order within the numeric Unicode characters. In all cases, Optim uses the “native” form of Unicode.

Multibyte depends on code pages and the “locale” of the process. It can be single-byte ASCII, such as the code page 1252 (English United States) in Windows, ISO 8859 in UNIX, or the built-in “C” code page in Windows or UNIX , or it can be multibyte, such as UTF-8 or SJIS.

You can use the utility program “pr0locl” (supplied with Optim) to determine whether the local you want to use is valid for Optim.

The “OptimExitW” (Unicode/Wide) entry point is addressed first. If it is found, it is used and the ASCII/multibyte version is ignored, if also present. If the Unicode/Wide entry point is not found, the “OptimExitA” (ASCII/multibyte) entry point is addressed. If neither is found, the exit is considered “corrupt” and the Optim program that is loading it will exit and issue the appropriate error messages to the operator.

The Optim exit load module is validated to ensure it contains one of these entry points when it is signed, prior to being used in Optim.

Internally, Optim is written to use Unicode. For it to convert to or from Unicode, it uses the appropriate system API for multibyte to wide (or wide to multibyte) conversions, which use the locale of the process to determine the translation.

This can result in lost characters if the data being passed to or from the exit was put there from a system using a locale other then the one that is active in the process.

That is, while Unicode encompasses all code pages and all characters in all languages, locales refer to one or a few code pages and the characters within them. (There are exceptions to how Unicode is handled on some platforms, but this is basically why you may have unknown characters.)

In our case, we substitute a default character for the invalid character when converting from Unicode (determined by the code pages we support, usually the equivalent of a “?”).

If the conversion fails for any reason other than an unknown character, it is considered a fatal error and an exception is raised.

In this regard, Optim will run a remote request from a client on an Optim server using the same locale that is active in the client process at the time the action is started (we translate between platforms).