The following are recommendations when working with Office in the global environment. Concepts that have been developed throughout this book resurface here, such as the importance of having a single binary, of globalizing your application from the start, and of making your application localizable.
In addition to a single code base, try to maintain-as much as possible-a single code path, regardless of the specific Windows version on which you need to run your application. As mentioned earlier, the Office 97 team decided to write code for Windows NT, and to simulate Windows NT on Windows 95/98/Me by using a layer. This practice kept the code simple and encouraged future-and even exclusive-support for for Windows NT-based operating systems such as Windows 2000 and Windows XP.
The market for Windows 95/98/Me will soon begin shrinking as Windows XP gains usage. Carefully examine where your software sales are. You might assume that you need to support Windows 95/98/Me, but the majority of software is sold to people buying new PCs, or to those who purchased PCs in the last year. As Windows XP becomes more widespread, you might be able to drop support for Windows 95/98/Me sooner than you think. This makes coding your application for globalization significantly easier. If a globalized application is important to your user, which is most likely the case, consider making your application support only Windows NT, Windows 2000, or Windows XP.
Adapting something so that it is localizable is an obvious practice in terms of strings. However, you should also be prepared for when you need to change bitmaps, user interface (UI) direction, or even logic rules (such as the order of user operations) in order to make your application localizable. (For more information, see Chapter 7, "Software Localizability Guidelines," and Chapter 9, "Content Localizability Guidelines.")