30 languages, only three code bases
Microsoft is saving a lot of time by developing just three separate code bases: SBCS (single-byte), DBCS (double-byte or multibyte) and Mideast (bidirectional). These three cover 30 languages. For example, Microsoft isn't building just an English-language version of Windows 95. Rather, it's building a single-byte version that happens to have an English user interface (UI) but can be easily transformed into German or French through "no-compile" techniques of exchanging Win32 resources.
If you want to see no-compile Win32 resource editing and many other Windows 95 internationalization issues covered in technical detail, the Microsoft Developer Relations Group will hold a one-day Win32 globalization seminar in 14 cities during February. The cost is approximately US$150. To register, call (800) 619-7689 or (415) 979-2288, or fax (415) 979-2270.
The efficiency gains are substantial, since Microsoft no longer has to spend an additional minute (or year) ripping apart existing code to create another language edition. Simultaneous shipping in several languages becomes practical, instead of merely theoretical. This also improves quality, because the sources remain unchanged and only the localized portions of the UI require testing. In addition, bug fixes affect all localized versions automatically, since builds are based on a common binary.
New emerging markets can be added to the list at any time—for example, the SBCS version can be localized into Klingon with no additional technical work. Unfortunately for Trekkers, there is currently not enough interstellar commerce to justify a Klingon edition of Windows 95. (If there were a Klingon edition it probably would look like Figure 1.) If someone could make a compelling case for it, Microsoft might consider adding it to the list.
Figure 1: Klingon language edition of Windows 95 (not currently scheduled).
Why stop at three code bases?
But why limit the streamlining to three code bases? Isn't one worldwide (or even one interplanetary) code base the ultimate goal? What about that thingamajig called Unicode, wasn't it supposed to handle this all automatically?
Well, not exactly. Internationalization means a heck of a lot more than what code page you pick, or using a universal language-independent code page (that is, Unicode).
Remember the fundamental design goals of Windows 95—while it gets a bunch of new cool stuff, it also has to be as small as possible, be very fast, run on the majority of today's hardware, and not break too many existing apps.
Microsoft took a hard look at this and came up with three language-region families required for Windows 95. The DBCS editions, which ship to the Far East, include some code that really doesn't need to be shipped elsewhere, such as an IME (input method editor) for complex writing systems, an EUDC (end-user defined character) editor, and all the code for passing DBCS (mixture of 8-bit or 16-bit) characters through the UI, as well as a bunch of applications in the Far East region that require DBCS support.
The editions for the Middle East support both left-to-right and right-to-left UI text placement, and special ligature and text justification (Kashida) handling—an absolute requirement for that region, but not elsewhere.
Thus, if Microsoft had one worldwide binary, we would have saved a few additional steps, but at the unacceptable expense of shipping a larger product at a much later time. What we have instead are three well-optimized source trees that cover 30 languages, all tested and developed by one team.
Responding quickly
The most successful companies will be those that can quickly respond to emerging growth opportunities anywhere in the world. So, Microsoft encourages any application developer (that means you) at a minimum to set up projects so they can be localized through no-compile Win32 resource-file editing. If you need to optimize for size (as many of us do), consider managing your projects as three major language regions like Microsoft did, but within each region stick to only one code base. You will find this approach easiest if you are targeting Windows 95.
If you have the type of project that can afford more size, it is entirely possible to ship one binary with worldwide functionality that will run across all language editions of Windows 95, and on Windows NT. An example of this is the English version of Visual C++ 2.0, which is DBCS-enabled. If you run Visual C++ on Japanese Windows, you can add Kanji literals and comments to your source files.
Want to know more? Read the International Handbook for Software Design, which is in the Developer Network Development Library. Nadine Kano of Microsoft's Developer Relations Group is also currently rewriting the handbook. Her book is scheduled to be published this spring by Microsoft Press.
Another resource is the Globalization Resource Kit (GRK), a CD-ROM with basic technical and marketing information plus a directory of third-party vendors who can provide internationalization-related services. If you don't have one, send e-mail with your mailing address to global@microsoft.com and ask for a GRK. Also, if you want to get Windows 95 internationalization information that will be published in the future, join the Developer Network, which will release information when it becomes publicly available.
Ken Fowles manages the Microsoft Developer Relations Group's globalization team. His distractions include playing the violin, rebuilding his house, and riding his Harley to biker events in Sturgis, South Dakota.