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

1、<p><b>　　外文文獻(xiàn)翻譯</b></p><p>　　原文： </p><p>　　From one code base to many platforms using Visual C++</p><p>　　Multiple-platform development is a hot is

2、sue 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

3、®, 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: </p><p>　　Maintain se

4、parate code bases for each platform, written to the platform's native application programming interface (API).</p><p>　　Write to a "virtual API" such as those provided by cross-platform toolset

5、s.</p><p>　　Build their own multiple-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 too

6、ls 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.</p><p>　　Currently the most lucrat

7、ive market for graphical user interface (GUI) applications, after Microsoft Windows, is the Apple Macintosh. However, vast differences separate these wholly different operating systems, requiring developers to learn new

8、APIs, programming paradigms, and tools. Generally, Macintosh development requires a separate code base from the Windows sources, increasing the complexity of maintenance and enhancement.</p><p>　　Because por

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

10、acintosh (excluding any platform-specific, or "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++® Cro

11、ss-Development Edition for Macintosh (Visual C++ 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 libra

12、ry 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.

13、</p><p>　　Figure 1, below, illustrates 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 Pow

14、erPC 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 Macintos

15、h and debugged remotely from the Windows-based machine.</p><p>　　Now that Apple has two different Macintosh architectures to contend with (Motorola 680x0 and PowerPC) portability is particularly important.&l

16、t;/p><p>　　Porting can involve several 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>&

17、lt;p>　　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 Power

18、PC machines that are based on a RISC chip.</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>　　Segre

19、gate those parts of your application that are 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 f

20、or your project.</p><p>　　Port your 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 Micr

21、osoft 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 high

22、ly portable to the Macintosh.</p><p>　　Write Macintosh-specific code to take advantage of unique Macintosh features, such as Apple Events or Publish and Subscribe.</p><p>　　The chief challenge a

23、mong 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-b

24、it 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 b

25、een made, how are legacy platforms to b</p><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

26、 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 cr

27、eate highly optimized native Win32 applications 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.

28、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 existence of a nativ

29、e 64-bit integer, which is far more efficient than on 32-bit (that is, Intel) processors.</p><p>　　Microsoft works closely with two third-party UNIX tools providers, Bristol Technology and Mainsoft Corporati

30、on, to allow developers to recompile their Win32-based or MFC-based applications for UNIX. Developers seeking additional information should contact those companies directly.</p><p>　　You'll have to decid

31、e early on whether to write to the native API (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

32、 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:</p

33、><p>　　What if I need an operating system 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 direc

34、tly. Just precede your function call with the 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 s

35、eamlessly.</p><p>　　How can I get 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

36、 MFC Migration Kit (available on CompuServe or, 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 ea

37、sier if you begin today writing more portable programs. Following some basic portability guidelines will make your code less platform-specific.</p><p>　　Never assume anything. Particularly, don't make as

38、sumptions about the sizes of types, the state 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 p

39、rocessors. For example, an int is two bytes in 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 o

40、ffsetof() macro. Don't try to compute this manually.</p><p>　　Use programmatic interfaces to access all system or hidden "objects," for example, the stack or heap.</p><p>　　Parsing

41、 data types to extract individual bytes or even 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

42、 constants that can be used to help write platform-independent macros to access individual bytes in a word.</p><p>　　This may seem obvious, because nothing could be less portable than assembly language. Comp

43、ilers, 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.

44、Modern compilers 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 algo</p><p>　　Write a

45、ll 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 both up to date.</p><p>　

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

47、that implements the standard correctly. Microsoft Visual C++ provides a compiler option (/Za) to enable strict ANSI compatibility checking.</p><p>　　Microsoft Visual C++ provides some language features that

48、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, you can wr

49、ite programs that use four-character constants, 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 s

50、tructures based on the target machine architecture; 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 serious

51、ly degrade the performance of your application. For portability, therefore, avoid packing structures. Limit packing to hardware interfaces and to compatibility issues such as file formats and on-disk structures.</p>

52、;<p>　　Using function prototypes is mandatory for fully portable code. All functions should be prototyped, and the prototype should exactly match the actual function declaration.</p><p>　　Following th

53、e guidelines above will make your code a lot more 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&

54、gt;<p>　　Code written for Win32 can run 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 us

55、e APIs that only function under Windows NT, they 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

56、 will have to be accounted for in the design of 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

57、 near and far are no longer supported. It also 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 wi

58、ll resolve many of these size differences for 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

59、 messages and warnings. Next, replace complex procedures and assembly language routines with stub procedures. Then, make your main program work properly using the techniques above. Finally, replace each stubbed-out proce

60、dure with a portable version.</p><p>　　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 differ

61、ences exist between the two platforms, this task 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

62、general areas:</p><p>　　Programming model differences</p><p>　　Processor differences</p><p>　　User interface (UI) differences</p><p>　　These areas of difference are des

63、cribed below. Porting issues that accompany these differences are discussed in the section titled "Porting from Win32 to the Macintosh."</p><p>　　The Windows and Macintosh APIs are completely diffe

64、rent. For example:</p><p>　　The event 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

65、Macintosh, you have a big main event loop to handle all possible events.</p><p>　　Windows uses the concept of child windows. The Macintosh uses no child windows.</p><p>　　Windows-based applicati

66、ons can draw using either pens or brushes. Macintosh applications can use only pens.</p><p>　　Controls in Windows are built-in window classes. On the Macintosh, controls are unrelated to windows.</p>

67、<p>　　Windows allows for 256 binary raster operations; the Macintosh allows for only 16. </p><p>　　Because of the differences between the two platforms, porting a Windows-based application to the Macint

68、osh can be monumental task without powerful tools.</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-b

69、ased Macintosh is now available as well). Differences between the processor families include addressing and byte ordering, in addition to the more expected differences like opcodes, instruction sets, and the name and num

70、ber of registers.</p><p>　　The Intel 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 a

71、llow the use of more memory, Intel implemented 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 Int

72、el scheme has been extended to allow much larger 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

73、reasons Microsoft Windows 3.x is actually a 16-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

74、wide. With the advent of Microsoft Windows NT, 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, t

75、he Motorola 68000 and PowerPC processor have always 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

76、-byte addresses are too large to use all the time, 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&qu

77、ot; machines—processors that place the least significant byte first and the most significant byte last. In contrast, the Motorola 680x0 and PowerPC (a so-called "big-endian" architecture) place the most signifi

78、cant byte first, followed by the next most significant byte, and so on, with the least significant byte last.</p><p>　　Compilers normally handle all details of byte ordering for your application program. Nev

79、ertheless, well-written portable code should never depend on the order of bytes.</p><p>　　Microsoft Windows and the Macintosh present quite different user interfaces in many key areas, including menus, filen

80、ames, and multiple-document interface (MDI) applications.</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 scr

81、een. The "active window" contains the 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, unde

82、r MDI, each child window can also have its own menu. MDI is discussed in greater detail below.</p><p>　　Macintosh applications generally have an "Apple menu" (the leftmost menu) that contains all t

83、he installed Desk Accessories and usually contains 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 f

84、or switching between applications.</p><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, movi

85、ng, and closing the window, as well as an item that calls the Task Manager for switching applications.</p><p>　　Generally, Windows-based applications contain keyboard equivalents in their menus. These are un

86、derlined letters in each menu entry that the user 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

87、 do not.</p><p>　　Filenames and pathnames 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

88、dealing with filenames as the area of porting 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\

89、SEPT93.DAT." Applications for the MS-DOS 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

90、Accounting Data."</p><p>　　MDI 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

91、word processor for Windows, are MDI applications. 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.</

92、p><p>　　The Macintosh does not support 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,

93、this difference may necessitate significant redesign 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 a

94、pplication that run on other platforms. Visual 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 ma

95、ke the multiple platform jump as effortless as possible.</p><p><b>　　. </b></p><p><b>　　外文翻譯</b></p><p>　　利用Visual C++把代碼運(yùn)行在多平臺上</p><p>　　在今天，多平

96、臺的開發(fā)是一個熱門課題。開發(fā)人員希望能夠支持不同的平臺，例如Windows 3.x, Windows NT, 和 Windows 95 操作系統(tǒng), 還有Apple, Macintosh, UNIX, 和 RISC (reduced instruction set computer)等。直到不久之前，希望開發(fā)多平臺任務(wù)的開發(fā)者們，只有很少的幾種選擇：</p><p>　　根據(jù)各個平臺的不同的應(yīng)用程序接口，為每個平臺

97、準(zhǔn)備一份單獨(dú)的代碼。</p><p>　　利用能跨平臺的工具所提供的“虛擬API”。</p><p>　　構(gòu)建們自己的多平臺層并支持它。</p><p>　　但是到了今天，有了一種新的辦法。開發(fā)人員可以通過使用微軟和第三方的工具，把他們現(xiàn)存的針對Windows API寫的代碼，對以上列舉的各種平臺重新編譯。本文要關(guān)注的就是與這種新辦法相關(guān)的方法和論點(diǎn)。</p&

98、gt;<p>　　目前，Macintosh是緊隨Windows之后，市場上最流行的圖形用戶界面系統(tǒng)。但是這兩個完全不同的操作系統(tǒng)之間有太多的不同，需要開發(fā)人員學(xué)習(xí)新的API、新的范例程序、新的工具。一般情況下，對Macintosh應(yīng)用程序的開發(fā)，需要和Windows不同的代碼庫，這些都增加了維護(hù)和升級的復(fù)雜度。</p><p>　　因?yàn)閺腤indows到Macintosh的代碼轉(zhuǎn)換是最難的情形，所以

99、本文重點(diǎn)是這個內(nèi)容。如果你的代碼能順利地實(shí)現(xiàn)對Macintosh平臺的再編譯，那么你就會發(fā)現(xiàn)它其它平臺上的再編譯也不難。</p><p>　　Microsoft Visual C++針對Macintosh提供的跨平臺編輯器提供了一些工具，這些工具是在Windows NT或 Windows 95平臺上運(yùn)行，可以把Windows代碼再編譯，使其適應(yīng)Motorola 680x0和PowerPC 處理器。它還提供了一個轉(zhuǎn)