Compatibility Issues

The API in Far East editions of Windows constitutes a superset of the API in European editions of Windows, so English-language applications will run correctly on Far East editions of Windows. But what about the reverse situation? Is there a way to run Japanese-language or Chinese-language applications on English editions of Windows? Because Windows 95 is based on local character sets, supporting double-byte ideographic characters on single-byte editions of Windows 95 is not possible without some serious hacking.

On Windows NT, however, it is possible to at least display ideographic characters on non–Far East editions because Windows NT supports Unicode. You can display Japanese characters on any language edition of Windows NT if you have an application that is Unicode-enabled and you have installed a Japanese font, such as the MS Mincho font or MS Gothic font that ships with Japanese Windows NT 3.5. However, you will be unable to display characters that aren't included both in Unicode and in your installed fonts. For example, Unicode version 1.1 does not support Korean combining jamos and some rare Korean hangul characters, so Windows NT 3.5 cannot display them. (Windows NT 3.51, which is based on Unicode 2, does support these characters.) Keep in mind as well that non–Far East editions of Windows NT do not support Far East National Language Support information, such as calendars and currencies, although future versions of Windows NT will.

Using a Unicode-enabled edit control on Windows NT gives your application "free" support for the entering of ideographic characters. The following code excerpt creates an edit control that can display any Unicode character, given the appropriate font:

// You can replace the following line with the compiler
// switch -DUNICODE
#define UNICODE
#include <windows.h>

...inside the Windows procedure (WndProc)...
switch (message)
{
case WM_CREATE:
// Sets up edit control.
// If UNICODE is defined, the preprocessor will replace
// CreateWindow with CreateWindowW, the Unicode
// version of this function.
hWndEdit = CreateWindow(TEXT("edit"), NULL,
WS_CHILD | WS_VISIBLE | WS_HSCROLL
| WS_VSCROLL | WS_BORDER | ES_LEFT

| ES_MULTILINE | ES_NOHIDESEL
| ES_AUTOHSCROLL | ES_AUTOVSCROLL,
0,0,0,0,
hwnd, (HMENU) ID_WEDIT,
hThisInstance, NULL) ;

SendMessage(hWndEdit, EM_LIMITTEXT, MAXBUFF, 0L) ;

...other initialization code...

break ;

case WM_SETFOCUS:
SetFocus(hWndEdit) ;
return 0 ;

// other message handling...
case WM_COMMAND:
switch (LOWORD(wParam)) // main menu messages
{
// other menu commands...
case IDM_FONT:
if (Choosefont(cfFont))
{
if ( NULL == (hfScreenFont =
CreateFontIndirect(cfFont.lpLogFont)) )
{
...error out...
}
}
return 0 ;

...

}
}

One advantage of the above approach is that the application inherits the edit control from a system DLL. Therefore, when you run this code on Japanese Windows NT, the application uses a system edit control that is IME-aware. The user can enter Japanese characters into the edit control buffer, which the application can process at will. This functionality is also available in MFC using CEditView.

Running a Single Binary on Japanese Windows and US Windows

Suppose you have a slightly different goal—a single, worldwide binary that runs on both Japanese Windows and US Windows. Because Japanese editions of Windows support functions that the US editions do not, your application will have to "gracefully degrade" on US Windows. On Windows 95, this is a very simple matter, because additional Far East–specific functions are stubbed on non–Far East editions of the operating system. On US Windows NT 3.x, however, this matter is considerably more complex, because the operating system does not stub the additional functions that ship with Japanese Windows NT. For example, the following functions are undefined on Western editions of Windows NT 3.x. Note that they are all related to IMEs.

You can still share a single binary by taking advantage of the Win32 function GetProcAddress. Instead of calling the additional API functions by name, you can call them by address. The array IMEFunc below contains the names of three IME-related functions, each followed by a pointer to a procedure address that is initialized to NULL.

Const int NUMIMEFUNCS = 3;
struct _tagIMEfuncs {
LPCHAR pszName;
FARPROC *pFunc;
} IMEFunc[NUMIMEFUNCS] = {"IMPAddIMEA", NULL,
"IMPDeleteIMEA", NULL,
"IMPGetIMEA", NULL};

During its initialization phase, your application will call a function such as LoadIMEFuncs, shown below.

This function will attempt to find each of the procedures named in the array IMEFunc. If the application is running on US Windows NT, the IME functions will be undefined, and the procedure addresses in the IMEFunc array will remain NULL. If you are running on Japanese Windows NT, the NULL values will be replaced with the correct procedure addresses. Code in other parts of the application should check to make sure the procedure addresses are not NULL before executing any IME-related code.

HMODULE LoadIMEFuncs(struct _tagIMEFuncs* pIME, int cFuncs)
{
HMODULE hDLL = LoadLibrary(TEXT("user32"));
if (hDLL)
while (cFuncs-- > 0)
pIME[cFuncs].pFunc = GetProcAddress(hDLL,
pIME[cFuncs].pszName);
return (hDLL);
}

...

LoadIMEFuncs(IMEFunc, NUMIMEFUNCS);

Running a Single Binary on Windows NT 3.5 and Windows 95

Another important compatibility issue involves the ability to run a single binary on both Windows NT 3.5 and Windows 95, since the API sets for each platform are slightly different. The major difference for Far East editions of Windows NT and Windows 95 is in the IME support. Applications written for the Windows NT 3.5–based IME model will run correctly on Windows 95, but applications written for the Windows 95–based IME model will not run on Windows NT 3.5. If Windows 95 is the main platform for your application, you should definitely implement IME support based on Windows 95's model. Keep in mind that Windows NT 3.51 and the next version of Windows NT, often referred to as "Cairo," use the same IME model as Windows 95 does.