Globalizing Applications for Windows: More Frequently Asked Questions
Q: I have the Japanese version of Win32s. Where can I get Win32s for Taiwan, Korea, and Mainland China?
A: Japanese Win32s is the only localized version of Win32s for double-byte languages. An unlocalized version of Win32s that is double-byte-enabled (called "Far East Win32s") is available on the MSDN Development Platform. This version will work for Chinese and Korean. The current edition, as of January 1996, is 1.30c.
Q: Can I test double-byte-enabled programs with Visual Test 4.0?
A: Yes, the U.S. version of Visual Test 4.0 is fully double-byte-enabled and is also enabled for the Windows 95 Input Method Editor (IME). You can run Visual Test 4.0 on the Japanese, Chinese, or Korean versions of Windows 95 and Windows NT to test applications enabled for the double-byte character set (DBCS).
Q: The English version of my product has qualified for the Windows 95 logo. I would now like to get the logo for the Japanese edition of my product. What should I do?
A: If the product has simply been localized (that is, major functionality has not been changed), the product does not need to be retested to get the Windows 95 logo for other languages. Note that if you do retest, your Japanese Windows 95-based application should run on Japanese Windows NT 3.51, not on Japanese Windows NT 3.5.
Q: Can international product developers expect the backslash and colon hex code points in file paths to be the same all over the world? I understand the backslash is the yen symbol in Japan, but the hex code point works OK as the file path separator. Can the user configure the file path separator?
A: Character 0x5c is always the directory delimiter, no matter what glyph it is associated with in a particular code page (for example, the Yen symbol in the Japanese code page). It’s not user-configurable.
Q: Will U.S.-only applications run on a non-U.S.-English version of Windows 95?
A: This shouldn’t be a problem, since the U.S. ASCII character set is a subset of every code page. (Actually, cp 932—shift JIS—has a yen mark where the backslash should be, but people just use the yen mark in path names as if it were a backslash, so there’s no effective difference.) Also, non-U.S. English versions of Windows 95 are all supersets of the U.S. version. However, you should test your application on a DBCS version of Windows, such as Japanese Windows 95, just to be sure.
Unicode
Q: Can I create Unicode-based applications using Visual Basic 4.0?
A: By default, Visual Basic relies on whichever code page is loaded for the operating system, but you can handle Unicode data in Visual Basic 4.0. Visual Basic will convert to or from Unicode when calling into dynamic-link libraries (DLLs) or when reading or writing to files. There is also a function called StrConv that will do ANSI/Unicode translations. You can always call the Win32 MultiBytetoWideChar function, but to pass a Unicode string you would need to create a typelib for the declaration and set the parameter as a BStr. Visual Basic 4.0, which is 32-bit, uses Unicode internally.
Q: How do I implement a Unicode application on all three Win32 platforms (Windows 95, Windows NT, and Windows 3.1 using Win32s)?
A: You can make a single binary that runs on all three platforms (including Win32s), but it takes some work. You basically have to write wrapper functions for the Win32 API functions that deal with strings (hereafter I’ll use CreateWindowU as an example of these wrapper functions). Inside the function you’ll detect the platform using GetVersionEx. If it’s Windows NT, you’ll just call the "W" version of the functions (e.g., CreateWindowW).
However, if the platform is Windows 95 or Win32s, you’ll need to convert the Unicode input/output string to/from the local code page before/after you call the "A" (code page) version of the function (e.g., CreateWindowA), using WideCharToMultiByte/MultiByteToWideChar.
European Languages
Q: I’m using LCMapString to strip diacritics from Danish characters, and it is stripping the accents from "Ø" and "Å"—these letters are treated as separate letters in Danish and should not be treated as accented characters. Is this a system bug?
A: LCMapString will always remove diacritics to get the base characters for ALL languages. "Ø", "Å", and several other characters are unique to Danish; they are not base characters plus diacritics. However, Microsoft chose not to implement a language-specific LCMapString because doing so requires additional, complex code to swap tables, and other international features took precedence.
Japanese Win32s is the only localized version of Win32s for double-byte languages.
You can run Visual Test 4.0 on the Japanese, Chinese, or Korean versions of Windows 95 and Windows NT to test DBCS-enabled applications.
A complete version of this article can be found on For Developers Only, Microsoft’s World Wide Web site, at: