1、外文原文 From one code base to many platforms using Visual C+ Multiple-platform development is a hot issue today. Developers want to be able to support diverse platforms such as the Microsoft Windows version 3.x, Microsoft Windows NT, and Microsoft Windows 95 operating systems, and Apple, Macintosh, UNI
2、X, and RISC (reduced instruction set computer) machines. Until recently, developers wanting to build versions of their application for more than one platform had few choices: Maintain separate code bases for each platform, written to the platforms native application programming interface (API). Writ
3、e to a virtual API such as those provided by cross-platform toolsets. Build their own multiple-platform layer and support it. Today, however, a new choice exists. Developers can use their existing code written to the Windows API and, using tools available from Microsoft and third parties, recompile
4、for all of the platforms listed above. This paper looks at the methods and some of the issues involved in doing so. Currently the most lucrative market for graphical user interface (GUI) applications, after Microsoft Windows, is the Apple Macintosh. However, vast differences separate these wholly di
5、fferent operating systems, requiring developers to learn new APIs, programming paradigms, and tools. Generally, Macintosh development requires a separate code base from the Windows sources, increasing the complexity of maintenance and enhancement. Because porting code from Windows to the Macintosh c
6、an be the most difficult porting case, this paper concentrates in this area. In general, if your code base is sufficiently portable to enable straightforward recompiling for the Macintosh (excluding any platform-specific, or edge code, you may elect to include), youll find that it will come up on ot
7、her platforms easily as well. Microsoft Visual C+ Cross-Development Edition for Macintosh (Visual C+ for Mac) provides a set of Windows NT or Windows 95hosted tools for recompiling your Windows code for the Motorola 680x0 and PowerPC processors, and a portability library that implements Windows on t
8、he Macintosh. This allows you to develop GUI applications with a single source code base (written to the Win32 API) and implement it on Microsoft Windows or Apple Macintosh platforms. Figure 1, below, illustrates how Visual C+ for Mac works. Your source code is edited, compiled, and linked on a Wind
9、ows NT or Windows 95based (Intel) host machine. The tools create 68000 and PowerPC native code and Macintosh resources. An Ethernet-based or serial transport layer (TL) moves the resulting binaries to a Macintosh target machine running remotely. The Macintosh application is started on the Macintosh
10、and debugged remotely from the Windows-based machine. Now that Apple has two different Macintosh architectures to contend with (Motorola 680x0 and PowerPC) portability is particularly important. Porting can involve several steps, depending on whether you are working with old 16-bit applications or w
11、ith new 32-bit sources. In general, the steps to a Macintosh port are as follows: 1. Make your application more portable by following some general portability guidelines. This will help insure not only portability to the 680x0-based Macintosh machines, but also to the newer, more powerful PowerPC ma
12、chines that are based on a RISC chip. 2. Port your application from Windows 16-bit code to 32-bit code. This may be the most complex and time-consuming part of the job. 3. Segregate those parts of your application that are unique to Windows from similar implementations that are specific to the Macin
13、tosh. This may involve using conditional compilation or it may involve changing the source tree for your project. 4. Port your Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C+ for compiling, linking, and debugging. 5. Use the Microsoft Foundation Class
14、 Library (MFC) version 4.0 to implement new functionality such as OLE 2.0 containers, servers, and clients or database support using open database connectivity (ODBC). Code written using MFC is highly portable to the Macintosh. 6. Write Macintosh-specific code to take advantage of unique Macintosh f
15、eatures, such as Apple Events or Publish and Subscribe. The chief challenge among the families of Windows operating systems is the break from 16 bits (Windows 3.11 and Windows for Workgroups 3.11 operating system with integrated networking) to 32 bits (Windows NT and Windows 95). In general, 16-bit
16、and 32-bit code bases are somewhat incompatible, unless they are written using MFC. Developers have the choice of branching their sources into two trees, or migrating everything to 32 bits. Once the Win32 choice has been made, how are legacy platforms to be run (that is, machines still running Windo
17、ws 3.11)? The obvious choice is to use the Win32s API libraries, which thunk 32-bit calls down to their 16-bit counterparts. Developers who want their applications to be able to take advantage of the hot new RISC hardware, such as DEC Alpha AXP machines, can use the special multiple platform edition
18、s of Visual C+. These include versions for the MIPS R4000 series of processors as well as the aforementioned DEC Alpha AXP chip and the Motorola Power PC. These toolsets run under Windows NT 3.51 and create highly optimized native Win32 applications for DEC Alpha and Motorola PowerPC platforms. Deve
19、lopers who have recompiled their Win32 sources using these toolsets are amazed at how simple it is. Since the operating system is identical on all platforms, and the tools are identical, little work has to be done in order to achieve a port. The key difference in the RISC machines from Intel is the
20、existence of a native 64-bit integer, which is far more efficient than on 32-bit (that is, Intel) processors. Microsoft works closely with two third-party UNIX tools providers, Bristol Technology and Mainsoft Corporation, to allow developers to recompile their Win32-based or MFC-based applications f
21、or UNIX. Developers seeking additional information should contact those companies directly. Youll have to decide early on whether to write to the native API (Win32) or to MFC. In general youll find MFC applications will port more quickly than Win32 applications. This is because one of the intrinsic
22、benefits of an application framework is an abstraction of the code away from the native operating system to some extent. This abstraction is like an insurance policy for you. However, developers frequently have questions about MFC, such as: What if I need an operating system service that isnt part o
23、f the framework? Call the Win32 API directly. MFC never prevents you from calling any function in the Win32 API directly. Just precede your function call with the global scope operator (:). I dont know C+. Can I still use MFC? Sure. MFC is based on C+, but you can mix C and C+ code seamlessly. How c
24、an I get started using MFC? Start by taking some classes and/or reading some books. Visual C+ ships with a fine tutorial on MFC (Scribble). Then, check out the MFC Migration Kit (available on CompuServe or, for a modest shipping and handling fee, from Microsoft). It will help you migrate your C-base
25、d application code to MFC and C+. All porting will be easier if you begin today writing more portable programs. Following some basic portability guidelines will make your code less platform-specific. Never assume anything. Particularly, dont make assumptions about the sizes of types, the state of the machine at any time, byte ordering, or alignment. Dont assume the size of primitive types, because these have different sizes on different processors. For example, an int is two bytes in Win16 and four bytes in Win32. At all costs,
