C++外文翻译Word文档格式.docx

1、, and Microsoft Windows 95 operating systems, and Apple, Macintosh, UNIX, 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, writte

2、n to the platforms native application programming interface （API）.Write 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

3、, using tools available from Microsoft and third parties, recompile 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

4、Apple Macintosh. However, vast differences separate these wholly different 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 an

5、d enhancement.Because porting code from Windows to the Macintosh can 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

6、, you may elect to include）, youll find that it will come up on other 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 p

7、rocessors, and a portability library that implements Windows on the 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 w

8、orks. Your source code is edited, compiled, and linked on a Windows 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

9、remotely. The Macintosh application is started on the Macintosh 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, dependin

10、g on whether you are working with old 16-bit applications or with 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 Macinto

11、sh machines, but also to the newer, more powerful PowerPC machines 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 fro

12、m similar implementations that are specific to the Macintosh. 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

13、, and debugging.5.Use the Microsoft Foundation Class 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-spe

14、cific code to take advantage of unique Macintosh features, 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

15、 （Windows NT and Windows 95）. In general, 16-bit 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

16、 to be run （that is, machines still running Windows 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 machine

17、s, can use the special multiple platform editions 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 fo

18、r DEC Alpha and Motorola PowerPC platforms.Developers 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 dif

19、ference in the RISC machines from Intel is the 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

20、 their Win32-based or MFC-based applications for 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 applic

21、ations. This is because one of the intrinsic 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

22、an operating system service that isnt part of 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 yo

23、u can mix C and C+ code seamlessly.How can 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

24、）. It will help you migrate your C-based 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 abou

25、t 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, avoid code that relies on the

26、size of a type. Use sizeof（） instead. To determine the offset of a field in a structure, use the offsetof（） macro. Dont try to compute this manually.Use programmatic interfaces to access all system or hidden objects, for example, the stack or heap.Parsing data types to extract individual bytes or ev

27、en bits can cause problems when porting from Windows to the Macintosh unless you are careful to write code that doesnt assume any particular byte order. LIMITS.H contains constants that can be used to help write platform-independent macros to access individual bytes in a word.This may seem obvious,

28、because nothing could be less portable than assembly language. Compilers, such as Microsoft Visual C+, that provide inline assemblers make it easy to slip in a little assembler code to speed things up. If you want portable code, however, avoid this temptation. It may not be necessary. Modern compile

29、rs can often generate code as good as hand-tuned native assembler code. Our own research at Microsoft indicates that performance problems are more often the result of poor algorithms than they are of poor code generation. Indeed, with RISC machines, hand-turned native assembler code may actually be

30、worse than machine-generated code, due to the complexity of instruction scheduling and picking register usage.Write all routines in C first; then, if you absolutely need to rewrite one in assembler, be sure to leave both implementations in your sources, controlled by conditional compiles, and keep b

31、oth up to date.A major goal of American National Standards Institute （ANSI） C/C+ is to provide a portable implementation of the language. Theoretically, code written to strict ANSI C compliance is completely portable to any compiler that implements the standard correctly. Microsoft Visual C+ provide

32、s a compiler option （/Za） to enable strict ANSI compatibility checking.Microsoft Visual C+ provides some language features that are in addition to ANSI C, such as four-character constants and single-line comments. Programs that use the Microsoft C extensions should be portable to all other implementations of Microsoft Visual C+. Thus,