The formats currently supported by MaxOmfSdk (Omf, Ale) are not, and never will be, Unicode. So, the API treats most format-related variables in their natural char (ascii) string manner.
(Future versions of the MaxOmfSdk API are planned to use Unicode interface variables to support AAF (Advanced Authoring Format) and MXF (Material eXchange Format), which both require Unicode.)
However, modern systems require supporting Unicode for GUI and file paths. For example, if a user's Windows system is running in Japanese - (Settings >> Control Panel >> Regional Options >> General >> Your Locale (location) == "Japanese" and Language settings for the system == "Japanese") - that system can create and use Japanese directory and file names. These are entirely different from English names, of course - Japanese can only be supported in Unicode - ascii strings are not enough.
For this reason, MaxOmfSdk is compiled for (see builds), and uses, Unicode to support foreign language file paths and some GUI interface variables.
MaxOmfSdk is (currently) built for use by a Windows client application using MFC and Unicode.
_AFXDLL (Use MFC in a shared DLL) and UNICODE,_UNICODE are defined in MaxOmfSdk to -
A) Help ensure UNICODE consistency and to pull in CString
B) Make the MFC debug capabilities (ASSERT, TRACE, etc) available
C) Enforce consistent preprocessor defines for C Runtime linkage
Your Client Application should be built similarly, and we strongly recommend it.
(We are sure you will inform us if this is not feasible for your environment. The core components of the SDK do not rely on Windows or MFC and it is feasible for us to build it for other systems - this version needs both.)
The relevant Settings >> C/C++ >> Preprocessor Defines (nmake preprocessor defines) are:
_DEBUG,_WINDOWS,WIN32,UNICODE,_UNICODE,_AFXDLL
NDEBUG,_WINDOWS,WIN32,UNICODE,_UNICODE,_AFXDLL
This combination (especially UNICODE,_UNICODE, and _AFXDLL) implies (by MSVC IDE Settings default), and requires, Settings >> C/C++ >> Code Generation >> Use Runtime Library >>
MultiThreaded DLL
Debug MultiThreaded DLL
To link properly, it also requires - Settings >> LINK >> Output >> Entry Point Symbol -
wWinMainCRTStartup
Use both UNICODE and _UNICODE in Preprocessor Defines to ensure all Windows and C Runtime headers are compiled and linked correctly. DO NOT use _MBSC, see below.
From MSDN Knowledge Base :
--------------------
INFO: UNICODE and _UNICODE Needed to Compile for Unicode
Article ID : 99359
Last Review : December 3, 2003
Revision : 1.0
This article was previously published under Q99359
SUMMARY
To compile code for Unicode, you need to #define UNICODE for the
Win32 header files and #define _UNICODE for the C Run-time header
files. These #defines must appear before the following
#include <windows.h>
and before any included C Run-time headers. The leading
underscore indicates deviance from the ANSI C standard. Because
the Windows header files are not part of this standard, it is
allowable to use UNICODE without the leading underscore.
--------------------
DO NOT use _MBSC when using Unicode.
Note that the MSVC IDE will default to define _MBCS when "Use MFC
in a shared DLL" is first selected in Settings >> General >> MFC.
You must remove it by hand!
From MSDN Knowledge Base :
--------------------
"Unicode and Multibyte Character Set (MBCS) Support" -
"Note - The symbols _MBCS and _UNICODE are mutually exclusive."
--------------------