Developing Applications for Far East Versions of 
Windows 3.1 and Windows NT

Summary of Issues

Aside from translation work, the major effort in creating a Chinese, Japanese, or Korean-language application from the code base of an English-language application is to change structures and algorithms to handle characters properly.  Once this work has been done for one of these languages, only minor adjustments are necessary to create working programs for the other languages.  This paper will provide a brief overview of issues relating to the “enabling” of applications for the Far East versions of Windows 3.1, Windows 95, and Windows NT.

National Language Support in Windows 3.1, Windows 95, and 
Windows NT

The Windows 3.1 and Windows NT operating systems carry a great deal of information that developers can use to achieve locale-independence in their programs.  Examples are sorting; upper-casing and lower-casing tables; country and language codes and strings; default date and time formats and separators; currency symbols and formatting information; decimal and list separators.  All of the information is based on the locale that is currently defined for the system through the International section of the Control Panel.  Windows NT and Windows 95 carry additional information, such as the abbreviated and full names of the months of the year and the days of the week.

An alternative to using the C run-time library string functions is to call Windows 3.1 or Win32 APIs that return similar information.  In addition to the sorting and casing operations mentioned above, each operating system has APIs to determine whether a character is alpha-numeric and to convert characters from one code page to another (between ANSI and OEM, or between Unicode and Multi-byte).  For more detailed information on these APIs or on the National Language Support offered by the operating systems, consult the Windows 3.1 or Win32 Software Development Kit (SDK) documentation.

In general, it is a good idea to use the Windows APIs when possible, as this minimizes the amount of work that has to be done to get a program to work on different versions of the operating system.  For example, a program for the MS-DOS/V version of Japanese Windows 3.1 that accesses hardware directly may need to be modified to run on the NEC version of Japanese Windows 3.1.  It will also need to be modified to run correctly on the Japanese version of Windows NT, as this operating system does not allow applications to access hardware directly.  Since Far East versions of each Windows operating system are based on a common set of sources, writing to the APIs would additionally minimize the amount of effort necessary to create a Korean or Chinese-language version of an application that works for Japanese.

Resource Files

Windows supports resource (.rc) files, which should contain all the localizable strings, menus, and dialogs, plus the icons and bitmaps used in a program.  In Windows 3.1, a resource file is attached to an executable using the Windows Resource Compiler (rc.exe). In Win32, the resource file is converted into an object (.obj) file and linked linked into the executable. The .rc files are edited using tools provided by the Windows 3.1 or Win32 SDKs.  The Far East versions of these tools must be used in order to see Chinese characters properly displayed.  Win32 supports multi-lingual resource files.  These resource files can contain strings and other localizable information for more than one language, making it possible for the program to switch user-interface languages on the fly.

Input Method Editors (IMEs)

Input Method Editors are programs that convert keystrokes into Chinese characters for use by an application.  Each language version of Windows supports several common methods for entering these characters.  Characters can be selected by their phonetic sounds, their basic radicals, or their numerical value.  Windows 3.1 and Windows 95 also support the use of a pen or stylus to enter characters through the Windows for Pen extensions.

Example of Romaji input and its conversion to Kanji
Keyboard Input	Display	Description	
H		“H” is echoed in double-byte	
A		“HA” is converted to phonetic character (Kana) automatically	
S		“S” is echoed in double-byte	
H		“H” is echoed in double-byte	
I		“SHI” is converted to phonetic character (kana) automatically	
CONVERT		Pressing the CONVERT key converts the phonetic string to Kanji string (means “bridge”)	
CONVERT		Pressing the CONVERT key one more time gives alternative Kanji homophone (means “chopsticks”)	

Windows supports IMEs written by third parties.  However, most developers only need to understand how the IMEs interface with applications.  The IME systems for the Far East versions of Windows 3.1 each share a common API with the corresponding Far East versions of Windows NT.  The IME systems for Far East versions of Windows 95 and Windows “Cairo” will share a common API.  Applications use the IME APIS to request that IMEs enable, disable, or position the IME conversion window, or to execute virtual keys.  Virtual keys can trigger commands to convert a string to a Chinese character, which is then passed to an application as a WM_CHAR message.  Alternately, they can change the type of input used for entering characters (alpha-numeric, katakana, hiragana, Roman, etc.).  Korean-language applications may also choose to support the display of interim characters.

Sample Korean input conversion on Windows Write screen
{ewc MVBMP2, ViewerBmp2, !techkor.bmp}

With Windows 95, applications may either inherit the default IME functionality offered by the system, or they may customize the IME User Interface and directly control the conversion of keystrokes into characters.

Far East Writing Systems

Chinese, Japanese, and Korean all use characters that originated in China as pictographs.  Called Hantsu in Chinese, Kanji in Japanese, and Hanja in Korean, these characters are ideograms that represent words or syllables and have no case distinction.Each character consists of one or more elements, a radical and another element that indicates the phonetic value. Radicals represent simpler, more common morphemes that are basically indivisible and in themselves give the character meaning. Simple examples of radicals are those for fire, water, sun, vision, and hearing.
Simplified Chinese character samples
Character	Chinese	Japanese	Korean	Meaning	
	tsuoh	hidari	jua	“left”	
	yu	migi	woo	“right”	
	jin	kin	goom	“gold”	
	mu	moku	nahmoo	“wood”	
	shui	shui	mool	“water”	
	huo	ka	bool	“fire”	
	tu	do	huk	“earth”	

Original-form Chinese characters, which are used in Taiwan, are generally more complex and more pictorial than the simplified form characters, which were developed in mainland China in recent years to speed up the educational process.  Although some characters are the same, the less than 7000 simplified characters use fewer and simpler strokes than their original counterparts.  Japanese kanji characters are also of simpler construction than orginal-form Chinese characters. 

Chinese hantsu characters and Japanese kanji characters are traditionally written from top to bottom in a vertical line that shifts from right to left.  Korean hanja characters are read vertically from left to right.  However, today many texts are written from left to right on a horizontal line. Foreign words are written using Latin script. Numerals, especially when written horizontally, are Arabic.

The Japanese Language
Japanese text can be spelled using kanji and three other types of characters.  Hiragana and katakana are phonetic alphabets referred to collectively as kana.  Hiragana is used for articles, prepositions, and word endings.  Katakana is commonly used to spell words that are borrowed from other languages.  The Latin representation of Japanese sounds is called romaji.  Most Japanese-language programs support Latin characters, and romaji is used by some input methods for entering the several thousand different kanji characters that form the basic set used in Japanese books, magazines, and newspapers.

	Hiragana	
	Katakana	
ka      ki      ku      ke     ko	Romaji	

 The Korean Language

The Korean written language consists of hanja and another type of character called hangeul.  Hangeul uses a unique system in which one syllabic letter consists of a consonant sign or signs and a vowel sign.  Korean letters are divided into two categories: basic element signs (phonemes) and combined scripts (syllabics).  There are 24 basic element signs (14 consonants and 10 vowels) called jamos, which can be combined to extend the number of vowels and consonants to 52 — 21 vowels (10 basic and 11 combined) and 30 consonants (14 basic and 16 combined).

One basic Korean letter (syllabic) consists of an initial-consonant and a medial-vowel. Sometimes a final-consonant is added. 19 of the 30 consonants can be initial-consonants. All 21 vowels can be medial-vowels and 27 of the 30 consonants can be final-consonants. There are a possible 11,172 Hangeul character combinations, however far fewer are in actual use.

Hanja is used for more formal written communication and for names of people. Hangeul characters are preferred for most daily communications.  Today, most Korean texts are written from left to right on a horizontal line without Chinese characters.

Double-Byte Character Sets (DBCS)

The Japanese versions of Windows 3.1 and Windows 95 are based on the Japan Industry Standard (JIS), and Shift-JIS code pages.  JIS is based on a 7-bit format, and Shift-JIS is based on an 8-bit format.  Since a single-byte code page can only support 256 characters, a two-byte encoding system is used to represent hiragana, katakana, and several thousand kanji characters.  For similar reasons, the Taiwanese version of Windows 3.1 and Windows 95 use the Big-5 code page, the Korean versions use KSC (Korean Standard Code) 5601, and the Mainland Chinese versions use GB (Guo Biuo, or “Country Code”) 2312-1980, all of which are DBCS standards.  The term “DBCS” is misleading, however, as some characters in these code-pages are single-byte and some are double-byte.  For this reason, programmers must handle string operations carefully.

Each double-byte character consists of a lead-byte plus a trail-byte, which must always be dealt with as a unit.  Randomly accessing strings, scanning for special delimters (such as backslash, colon, period, space, or tab), or performing case conversions can produce unexpected results if a lead-byte or trail-byte is treated as a single-byte character.  Strings must be scanned linearly from the beginning to the end, and double-byte characters should be noted as they are found.  Insertion, deletion, truncation, and cursor movement must never separate a lead-byte from its trail byte.  For this reason, string pointers should be incremented or decremented using macros, or function calls, rather than the ++ and -- operators in C, which do not account for double-byte characters.  The Windows 3.1 APIs AnsiNext and AnsiPrev (CharNext and CharPrev in Win32) are useful for manipulating strings.  The guidelines above should be carefully followed when dealing with the file system, as mixtures of single- and double-byte characters can also be used in file names.

Keyboard input handling is another feature that is affected by double-byte characters. Since low-level functions typically read characters into a buffer one at a time, the program must buffer lead bytes as necessary in order to keep track of double-byte characters.  Trail bytes should never be left in the type-ahead buffer.  The program should either process the trail-byte or discard the leading byte and flush the input queue.  

Double-byte characters are either passed as entire strings (wparam = = IR_STRING) or appear as two consecutive WM_CHAR messages.  When a lead byte is received (as determined by calling IsDBCSLeadByte), a PeekMessage call with wMsgFilterMin and wMsgFilterMax set to WM_CHAR can be issued to get the trailing byte of the double-byte character.  For the Korean versions of Windows, all Hangeul interim characters should be displayed at the current cursor location until an application receives a code indicating that a final character has been formed.

Unicode

Unicode is a fixed-width, 16-bit character encoding system that covers most of the world’s scripts in current or expected use in computers.  It simplifies the character handling for programs that wish to support multi-lingual text.  It also simplifies the creation of applications for Far East languages. With Unicode, the basic code for handling Latin-based characters does not have to be changed  to support Far East character sets.  Unicode contains around 21,000 unique Han characters defined by industry standards in China, Japan, Korea, and Taiwan, including characters from literary Chinese.

Unicode is a plain text standard.  Programs need to provide their own font support, formatting and rendering algorithms, methods for exchanging data with non-Unicode programs, sorting orders, and case-conversion tables.  Some of this functionality is provided by Windows NT, which uses Unicode as its internal encoding system (see next section).  The Win32 APIs MultiByteToWideChar and WideCharToMultiByte can be used to map characters between DBCS and Unicode.  These APIs are supported by Windows NT, Windows 95, and Win32s version 1.2.  The conversion between wide characters and multi-byte characters, and back, with these two APIs is guaranteed (unlike the Windows 3.1 calls AnsiToOEM and OEMToAnsi), so non-Unicode text that is translated into Unicode at “the boundary” of a program will not lose any information.

The steps for porting applications to Unicode are relatively simple.  ANSI C has defined a new wide-character type, wchar_t, which is supported by Microsoft C in wide-character versions of the common string functions. In addition to changing to wide-character types and adusting string functions, programmers converting to Unicode will need to adjust pointer arithmetic to account for the 16-bit width of characters, and will need to add support for mapping data into and out of Unicode, if necessary.  Any code that assumes the size of characters is 8-bits and that there are only 256 possibilities will also need to be changed.

Microsoft C and the Win32 API support the concept of “generic data types” and “generic function prototypes.”  A compile flag (#define UNICODE) changes the generic types or APIs to wide-character defaults.  Compiling without the flag results in types and prototypes based on the ANSI character set.  This functionality offers the flexibility of compiling either Unicode or non-Unicode versions of a program.  If your code uses the ‘C’ run-time library, also use the compile flag UNICODE.

Hardware Requirements and Available Development Tools

For the Far East editions of Windows 3.1 and Windows 95, the suggested configuration is as follows:

*	Intel 80386 or above microprocessor
*	AT-compatible machine (in Japan, NEC machines running NEC Windows 3.1 are also supported)
*	4 MB RAM
*	VGA display or adaptor
*	60MB or more disk space
*	Mouse
*	MS-DOS — for the Japanese version, MS-DOS 5.0/V is required.  For the Taiwanese version, MS-DOS 5.0 or MS-DOS 6.0 (U.S. edition), or MS-DOS 5.0 retail upgrade (ETen or Zero/One Chinese System Bundle), or MS-DOS 6.0 retail upgrade (ETen - Chinese System Bundle) can be used.  For the Korean version, MS-DOS 5.0 (U.S. or Hangeul edition) or MS-DOS 6.0 (U.S. edition) can be used.
*	For the Korean version, a Hangeul or Standard BIOS can be used.

For the Japanese version of Windows NT, the suggested configuration is as follows:

*	Intel 80386 or above microprocessor
*	AT-compatible (or other supported RISC or OEM machines)
*	VGA display or adaptor
*	Mouse
*	16 MB RAM
*	100 MB or more disk space

For development environments, additional RAM and hard disk space is recommended.  Applications for the NEC version of Japanese Windows 3.1 and Windows 95 can be developed on AT-compatible machines if the Windows API calls are used.  However, it is recommended that any such application be tested on an NEC machine before it is shipped.

The Windows 3.1 Far East SDK, which contains SDKs and Device Driver Kits (DDKs) for the Chinese, Japanese, and Korean-language editions of Windows 3.1, is available via the Microsoft Developer Network (MSDN) Level 2.  To order, call 1-800-759-5474 in the U.S..  The Japanese Edition of the Win32 SDK is also available via MSDN.  It is possible to start developing Far East versions of applications for Windows NT using the U.S. Win32 SDK, which contains full Unicode support.  The Japanese edition contains support for IMEs, plus tools that can be used to edit and compile sources containing kanji characters.

Other development tools include the Japanese versions of Visual Basic 2.0 and Visual C++ 1.5.  In addition, Japanese, Chinese, and Korean-language versions of Word for Windows can be used to create help files.  Retail products can be obtained in the United States from the following distributors:

Chinese:	Chase Computers	(818) 300-8666
Japanese:	SystemSoft Florida	(800) 992-9894
	or	Unitrendix Corp.	(800) 946-7788
Korean:	Computer Plus	(213) 480-6777

Developer Resources

A great deal of help is available for developers working on creating applications for the Far East Windows environments.

The Microsoft Developer Network (MSDN) is a program that provides information to developers via a CD-ROM that is issued 4 times a year and a newspaper that is issued 6 times per year. Call 1-800-759-5474 (or 402-691-0173) to enroll or 1-800-227-4679, ext. 11771 for questions about membership benefits.  The Level 1 CD-ROM contains coding samples, whitepapers, reprints of technical journals, and other technical information, including the Microsoft Windows International Handbook for Software Design.  MSDN Level 2 contains all language versions of Microsoft operating systems and software development kits.

Support for developers writing applications for the Far East versions of Windows 3.1 and Windows NT is available on CompuServe.  The WINEXT forum, FESDK Section deals with Windows 3.1.  MSWin32 supports Unicode and Win32 programming (including programming for Far East versions of Windows NT), and other forums exist for Multimedia and Microsoft Languages.  The forums are monitored by Microsoft Product Support Services.  The Internet FTP site is machine name: ftp.uu.net; directory: ~ftp/vendor/microsoft.

Fee-based Professional and Premier support programs are available from Product Support Services and the Developer Services Team.  Call 1-800-227-4679-11771 for information.

The Microsoft Developer Relations Group sponsors periodic developer’s conferences and co-marketing programs, such as vendor booths at Fall Comdex or Spring Windows World.  It also runs a porting lab, which is available on an invitation-only basis to help developers incorporate the latest technology into their applications, including support for Far East versions of Windows NT.  For more information on these programs, email the internet alias global@microsoft.com.

Additional Reading

Windows 3.1 Developer's Workshop, published by Microsoft Press.

Soft Landing in Japan: A Market Entry Handbook for U.S. Software Companies, published by the American Electronics Association

Software Internationalization and Localization: an Introduction, by Emmanuel Uren, Robert Howard, and Tiziana Perinotti, published by Van Nostrand Reinhold

Software Partners: The Directory of Japanese Software Distributors, published by the American Electronics Association

Understanding Japanese Information Processing, by Ken Lunde, published by O’Reilly and Associates, Inc.

The International Handbook for Software Design, prepared by Microsoft Developer Relations and available through the Microsoft Developer Network CD-ROM.

“Internationalization in Windows NT,” by William S. Hall, in Microsoft Systems Journal, June and July, 1994.

Price Waterhouse offers handbooks on entering various international markets.