c++外文翻譯--利用visual c++把代碼運(yùn)行在多平臺(tái)上

1、<p><b>　　外文原文</b></p><p>　　From one code base to many platforms using Visual C++</p><p>　　Multiple-platform development is a hot issue today. Developers want to be able to suppo

2、rt diverse platforms such as the Microsoft® Windows® version 3.x, Microsoft Windows NT®, and Microsoft Windows 95 operating systems, and Apple®, Macintosh®, UNIX, and RISC (reduced instruction se

3、t computer) machines. Until recently, developers wanting to build versions of their application for more than one platform had few choices: </p><p>　　Maintain separate code bases for each platform, written t

4、o the platform's native application programming interface (API).</p><p>　　Write to a "virtual API" such as those provided by cross-platform toolsets.</p><p>　　Build their own multi

5、ple-platform layer and support it.</p><p>　　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,

6、 recompile for all of the platforms listed above. This paper looks at the methods and some of the issues involved in doing so.</p><p>　　Currently the most lucrative market for graphical user interface (GUI)

7、applications, after Microsoft Windows, is the Apple Macintosh. However, vast differences separate these wholly different operating systems, requiring developers to learn new APIs, programming paradigms, and tools. Genera

8、lly, Macintosh development requires a separate code base from the Windows sources, increasing the complexity of maintenance and enhancement.</p><p>　　Because porting code from Windows to the Macintosh can be

9、 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

10、"edge" code, you may elect to include), you'll find that it will come up on other platforms easily as well.</p><p>　　Microsoft Visual C++® Cross-Development Edition for Macintosh (Visual C

11、++ for Mac?) provides a set of Windows NT– or Windows 95–hosted tools for recompiling your Windows code for the Motorola 680x0 and PowerPC processors, and a portability library that implements Windows on the Macintosh. T

12、his 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.</p><p>　　Figure 1, below, illust

13、rates how Visual C++ for Mac works. Your source code is edited, compiled, and linked on a Windows NT– or Windows 95–based (Intel) host machine. The tools create 68000 and PowerPC native code and Macintosh resources. An E

14、thernet-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 and debugged remotely from the Windows-based

15、 machine.</p><p>　　Now that Apple has two different Macintosh architectures to contend with (Motorola 680x0 and PowerPC) portability is particularly important.</p><p>　　Porting can involve sever

16、al steps, depending 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:</p><p>　　Make your application more portable

17、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 machines that are based on a RISC chip.<

18、/p><p>　　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.</p><p>　　Segregate those parts of your application that are

19、unique to Windows from 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.</p><p>　　Port yo

20、ur Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C++ for compiling, linking, and debugging.</p><p>　　Use the Microsoft Foundation Class Library (MFC) version 4

21、.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.</p><p

22、>　　Write Macintosh-specific code to take advantage of unique Macintosh features, such as Apple Events or Publish and Subscribe.</p><p>　　The chief challenge among the families of Windows operating systems

23、 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 and 32-bit code bases are somewhat incompat

24、ible, 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 b</p&

25、gt;<p>　　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 editions of Visual C++. These includ

26、e 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 application

27、s for DEC Alpha and Motorola PowerPC platforms.</p><p>　　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

28、 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 existence of a native 64-bit integer, which is far more efficient

29、than on 32-bit (that is, Intel) processors.</p><p>　　Microsoft works closely with two third-party UNIX tools providers, Bristol Technology and Mainsoft Corporation, to allow developers to recompile their Win

30、32-based or MFC-based applications for UNIX. Developers seeking additional information should contact those companies directly.</p><p>　　You'll have to decide early on whether to write to the native API

31、(Win32) or to MFC. In general you'll find MFC applications will port more quickly than Win32 applications. This is because one of the intrinsic benefits of an application framework is an abstraction of the code away

32、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:</p><p>　　What if I need an operating s

33、ystem service that isn't part of the framework?</p><p>　　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

34、global scope operator (::).</p><p>　　I don't know C++. Can I still use MFC?</p><p>　　Sure. MFC is based on C++, but you can mix C and C++ code seamlessly.</p><p>　　How can I get

35、 started using MFC?</p><p>　　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

36、, for a modest shipping and handling fee, from Microsoft). It will help you migrate your C-based application code to MFC and C++.</p><p>　　All porting will be easier if you begin today writing more portable

37、programs. Following some basic portability guidelines will make your code less platform-specific.</p><p>　　Never assume anything. Particularly, don't make assumptions about the sizes of types, the state

38、of the machine at any time, byte ordering, or alignment.</p><p>　　Don't assume the size of primitive types, because these have different sizes on different processors. For example, an int is two bytes in

39、 Win16 and four bytes in Win32. At all costs, avoid code that relies on the size of a type. Use sizeof() instead. To determine the offset of a field in a structure, use the offsetof() macro. Don't try to compute this

40、 manually.</p><p>　　Use programmatic interfaces to access all system or hidden "objects," for example, the stack or heap.</p><p>　　Parsing data types to extract individual bytes or eve

41、n bits can cause problems when porting from Windows to the Macintosh unless you are careful to write code that doesn't assume any particular byte order. LIMITS.H contains constants that can be used to help write plat

42、form-independent macros to access individual bytes in a word.</p><p>　　This may seem obvious, because nothing could be less portable than assembly language. Compilers, such as Microsoft Visual C++, that prov

43、ide 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 compilers can often generate code as go

44、od as hand-tuned native assembler code. Our own research at Microsoft indicates that performance problems are more often the result of poor algo</p><p>　　Write all routines in C first; then, if you absolutel

45、y need to rewrite one in assembler, be sure to leave both implementations in your sources, controlled by conditional compiles, and keep both up to date.</p><p>　　A major goal of American National Standards I

46、nstitute (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. Micros

47、oft Visual C++ provides a compiler option (/Za) to enable strict ANSI compatibility checking.</p><p>　　Microsoft Visual C++ provides some language features that are in addition to ANSI C, such as four-charac

48、ter constants and single-line comments. Programs that use the Microsoft C extensions should be portable to all other implementations of Microsoft Visual C++. Thus, you can write programs that use four-character constants

49、, for example, and know that your program is portable to any 16-bit or 32-bit Microsoft Windows platform or to the Macintosh.</p><p>　　Compilers normally align structures based on the target machine architec

50、ture; some RISC machines, such as the MIPS R4000, are particularly sensitive to alignment. Alignment faults may generate run-time errors or, instead, may silently and seriously degrade the performance of your application

51、. For portability, therefore, avoid packing structures. Limit packing to hardware interfaces and to compatibility issues such as file formats and on-disk structures.</p><p>　　Using function prototypes is man

52、datory for fully portable code. All functions should be prototyped, and the prototype should exactly match the actual function declaration.</p><p>　　Following the guidelines above will make your code a lot m

53、ore portable. However, if you have 16-bit Windows code, your first step is to make it work properly under Win32. This will require additional changes in your sources. </p><p>　　Code written for Win32 can run

54、 on any version of Windows, including on the Macintosh, using the portability library. Portable code should compile and execute properly on any platform. Of course, if you use APIs that only function under Windows NT, th

55、ey will not work when your application runs under Windows 3.x. For example, threads work under Windows NT but not under Windows 3.11. Those types of functionality differences will have to be accounted for in the design o

56、f your application. </p><p>　　Chief among the differences between Win16 and Win32 is linear addressing. That means pointers are now 32 bits wide and the keywords near and far are no longer supported. It also

57、 means code that assumes segmented memory will break under Win32.</p><p>　　In addition to pointers, handles and graphic coordinates are now 32 bits. WINDOWS.H will resolve many of these size differences for

58、you, but some work is still necessary. </p><p>　　The recommended strategy to get your application running under Win32 is to recompile for 32 bits, noting error messages and warnings. Next, replace complex

59、procedures and assembly language routines with stub procedures. Then, make your main program work properly using the techniques above. Finally, replace each stubbed-out procedure with a portable version.</p><p

60、>　　After you successfully convert your Windows-based program from 16 bits to 32 bits, you're ready to embark on porting it to the Macintosh. Because significant differences exist between the two platforms, this ta

61、sk can appear daunting. Before you can begin to port your application, you need to better understand these differences. The Macintosh is differentiated from Windows in three general areas:</p><p>　　Programmi

62、ng model differences</p><p>　　Processor differences</p><p>　　User interface (UI) differences</p><p>　　These areas of difference are described below. Porting issues that accompany th

63、ese differences are discussed in the section titled "Porting from Win32 to the Macintosh."</p><p>　　The Windows and Macintosh APIs are completely different. For example:</p><p>　　The e

64、vent models are different. In Windows, you dispatch messages to WindowProcs. You use DefWindowProc to handle messages in which you're not specifically interested. On the Macintosh, you have a big main event loop to h

65、andle all possible events.</p><p>　　Windows uses the concept of child windows. The Macintosh uses no child windows.</p><p>　　Windows-based applications can draw using either pens or brushes. Mac

66、intosh applications can use only pens.</p><p>　　Controls in Windows are built-in window classes. On the Macintosh, controls are unrelated to windows.</p><p>　　Windows allows for 256 binary raste

67、r operations; the Macintosh allows for only 16. </p><p>　　Because of the differences between the two platforms, porting a Windows-based application to the Macintosh can be monumental task without powerful to

68、ols.</p><p>　　Windows has always run on Intel x86 processors (until Windows NT), and the Macintosh has run on Motorola 680x0 processors (of course, the PowerPC-based Macintosh is now available as well). Diff

69、erences between the processor families include addressing and byte ordering, in addition to the more expected differences like opcodes, instruction sets, and the name and number of registers.</p><p>　　The In

70、tel 8086 processor, from which subsequent 80x86 processors are descended, used 16-bit addresses, which unfortunately allowed only 65,536 bytes of memory to be addressed. To allow the use of more memory, Intel implemented

71、 a segmented memory architecture to address one megabyte (2^20 bytes) of memory that used an unsigned 16-bit segment register and an unsigned 16-bit offset. This original Intel scheme has been extended to allow much larg

72、er amounts of memory to be addressed, but most existin</p><p>　　Although all Intel x86 processors since the 80386 have used 32-bit addressing, for compatibility reasons Microsoft Windows 3.x is actually a 16

73、-bit application, and all Microsoft Windows-based applications had to be written as 16-bit applications. That meant, for example, that most pointers and handles were 16 bits wide. With the advent of Microsoft Windows NT,

74、 which is a true 32-bit operating system, all native applications are 32-bit applications, which means that pointers and handles are 32 b</p><p>　　In contrast, the Motorola 68000 and PowerPC processor have a

75、lways provided the ability to address a "flat" 32-bit memory space. In theory, a flat memory space of this kind simplifies memory addressing. In practice, because 4-byte addresses are too large to use all the t

76、ime, Macintosh code is generally divided into segments no larger than 32K.</p><p>　　Microsoft Windows and Windows NT run only on so-called "little-endian" machines—processors that place the least s

77、ignificant byte first and the most significant byte last. In contrast, the Motorola 680x0 and PowerPC (a so-called "big-endian" architecture) place the most significant byte first, followed by the next most sig

78、nificant byte, and so on, with the least significant byte last.</p><p>　　Compilers normally handle all details of byte ordering for your application program. Nevertheless, well-written portable code should n

79、ever depend on the order of bytes.</p><p>　　Microsoft Windows and the Macintosh present quite different user interfaces in many key areas, including menus, filenames, and multiple-document interface (MDI) ap

80、plications.</p><p>　　Only one menu bar exists on the Macintosh, and it is always in the same place, regardless of the number or arrangement of windows on the screen. The "active window" contains th

81、e menu, which dynamically changes as necessary when different windows are made active. Windows, on the other hand, gives each top-level window its own menu. In addition, under MDI, each child window can also have its own

82、 menu. MDI is discussed in greater detail below.</p><p>　　Macintosh applications generally have an "Apple menu" (the leftmost menu) that contains all the installed Desk Accessories and usually cont

83、ains an About entry for the application. Under System 7, the extreme right side of the Macintosh menu contains an icon for Apple's Balloon Help and the Application menu for switching between applications.</p>

84、<p>　　Windows-based applications always have a System menu at the upper-left corner of their top-level window. This menu contains system-level functions for sizing, moving, and closing the window, as well as an item

85、 that calls the Task Manager for switching applications.</p><p>　　Generally, Windows-based applications contain keyboard equivalents in their menus. These are underlined letters in each menu entry that the u

86、ser can select with the keyboard in lieu of the mouse. This, however, is convention rather than requirement. Although some Macintosh applications have these equivalents, most do not.</p><p>　　Filenames and p

87、athnames represent one of the most fundamental differences between Windows and the Macintosh, as well as perhaps the one most difficult to deal with. Many programmers report dealing with filenames as the area of porting

88、in which the most time and energy is spent.</p><p>　　Your Windows-based application probably already handles (and expects) filenames such as "C:\ACCTG\DATA\SEPT93.DAT." Applications for the MS-DOS

89、and Windows operating systems are bound by the traditional 8.3 filename format. Macintosh applications, on the other hand, can handle filenames such as "September, 1993 Accounting Data."</p><p>　　M

90、DI windows allow for multiple child windows within the borders of a top-level window (the "MDI frame"). Many Windows-based applications, such as the Microsoft Word word processor for Windows, are MDI applicatio

91、ns. Characteristic of MDI applications are clipped child windows that can be minimized to an icon within the MDI frame. Each MDI child window can also have its own menu.</p><p>　　The Macintosh does not suppo

92、rt MDI windows. An application can have multiple windows open; those windows, however, cannot be made into icons, and they share a common menu. Depending on the application, this difference may necessitate significant re

93、design for a Macintosh port.</p><p>　　Finally you can keep doing what you know how to do best, writing to the Windows API, and still allow for versions of your application that run on other platforms. Visual

94、 C++ now gives you special versions that allow you to do this. Keeping your code portable, thinking about portability all the time, and using the right tools will help you make the multiple platform jump as effortless as

95、 possible.</p><p><b>　　. </b></p><p><b>　　外文翻譯</b></p><p>　　利用Visual C++把代碼運(yùn)行在多平臺(tái)上</p><p>　　在今天，多平臺(tái)的開發(fā)是一個(gè)熱門課題。開發(fā)人員希望能夠支持不同的平臺(tái)，例如Windows 3.x, Win

96、dows NT, 和 Windows 95 操作系統(tǒng), 還有Apple, Macintosh, UNIX, 和 RISC (reduced instruction set computer)等。直到不久之前，希望開發(fā)多平臺(tái)任務(wù)的開發(fā)者們，只有很少的幾種選擇：</p><p>　　根據(jù)各個(gè)平臺(tái)的不同的應(yīng)用程序接口，為每個(gè)平臺(tái)準(zhǔn)備一份單獨(dú)的代碼。</p><p>　　利用能跨平臺(tái)的工具所提供的

97、“虛擬API”。</p><p>　　構(gòu)建們自己的多平臺(tái)層并支持它。</p><p>　　但是到了今天，有了一種新的辦法。開發(fā)人員可以通過(guò)使用微軟和第三方的工具，把他們現(xiàn)存的針對(duì)Windows API寫的代碼，對(duì)以上列舉的各種平臺(tái)重新編譯。本文要關(guān)注的就是與這種新辦法相關(guān)的方法和論點(diǎn)。</p><p>　　目前，Macintosh是緊隨Windows之后，市場(chǎng)上最流

98、行的圖形用戶界面系統(tǒng)。但是這兩個(gè)完全不同的操作系統(tǒng)之間有太多的不同，需要開發(fā)人員學(xué)習(xí)新的API、新的范例程序、新的工具。一般情況下，對(duì)Macintosh應(yīng)用程序的開發(fā)，需要和Windows不同的代碼庫(kù)，這些都增加了維護(hù)和升級(jí)的復(fù)雜度。</p><p>　　因?yàn)閺腤indows到Macintosh的代碼轉(zhuǎn)換是最難的情形，所以本文重點(diǎn)是這個(gè)內(nèi)容。如果你的代碼能順利地實(shí)現(xiàn)對(duì)Macintosh平臺(tái)的再編譯，那么你就會(huì)發(fā)現(xiàn)

99、它其它平臺(tái)上的再編譯也不難。</p><p>　　Microsoft Visual C++針對(duì)Macintosh提供的跨平臺(tái)編輯器提供了一些工具，這些工具是在Windows NT或 Windows 95平臺(tái)上運(yùn)行，可以把Windows代碼再編譯，使其適應(yīng)Motorola 680x0和PowerPC 處理器。它還提供了一個(gè)轉(zhuǎn)換庫(kù)來(lái)輔助Windows程序在Macintosh上運(yùn)行。這就使你可以開發(fā)單一的源代碼（針對(duì)W