C++多平台中英文资料外文翻译文献

1、C+多平台中英文资料外文翻译文献C+多平台中英文资料外文翻译文献外文原文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

2、 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, written to the pl

3、atform's nativeapplication 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 A

4、PI and, 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, i

5、s the 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 maintena

6、nce and enhancement.C+多平台中英文资料外文翻译文献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-

7、specific, or "edge" code, you may elect to include), you'll 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 Wind

8、ows code for the Motorola 680x0 and PowerPC processors, 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.F

9、igure 1, below, illustrates how Visual C+ for Mac works. 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 result

10、ing binaries to a Macintosh target machine running 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 im

11、portant.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:1. Make your application more portable by following some general portability guidelines.This will help ins

12、ure 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.2. Port your application from Windows 16-bit code to 32-bit code. This may be the mostcomplex and time-consuming part of the job.3. Segregate those part

13、s of your application that are unique to Windows from similarimplementations 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 fo

14、r theMacintosh and Visual C+ for compiling, linking, and debugging.5. Use the Microsoft Foundation Class Library (MFC) version 4.0 to implement newfunctionality such as OLE 2.0 containers, servers, and clients or database supportC+多平台中英文资料外文翻译文献using open database connectivity (ODBC). Code written u

15、sing MFC is highly portable to the Macintosh.6. Write Macintosh-specific code to take advantage of unique Macintosh features, suchas 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 Workg

16、roups 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 incompatible, unless they are written using MFC. Developers have the choice of branching their sources into two trees, or migrating everything to 32 b

17、its. Once the Win32 choice has been made, how are legacy platforms 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 ta

18、ke advantage of the hot new RISC hardware, such as DEC Alpha AXP machines, 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

19、Windows NT 3.51 and create highly optimized native Win32 applications for 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 ident

20、ical, 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 than on 32-bit (that is, Intel) processors.Microsoft works closely with two third-party UNIX tools providers, Brist

21、ol Technology and Mainsoft Corporation, to allow developers to recompile their Win32-based or MFC-based applications for UNIX. Developers seeking additional information should contact those companies directly.You'll have to decide early on whether to write to the native API (Win32) or to MFC. In

22、 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 from the native operating system to some extent. This abstraction is like an insurance policy for you

23、. However, developers frequently have questions about MFC, such as:What if I need an operating system service that isn't 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

24、scope operator (:).C+多平台中英文资料外文翻译文献 I don't know C+. Can I still use MFC?Sure. MFC is based on C+, but you 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

25、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-based application code to MFC and C+. All porting will be easier if you begin today writing more portable programs. Following some basic portability guideli

26、nes will make your code less platform-specific.Never assume anything. Particularly, don't make assumptions about the sizes of types, the state of the machine at any time, byte ordering, or alignment.Don't assume the size of primitive types, because these have different sizes on different pro

27、cessors. 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 offsetof() macro. Don't try to compute this manually.Use programmatic interface

28、s to access all system or hidden "objects," for example, the stack or heap.Parsing 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. LIMIT

29、S.H contains constants that can be used to help write platform-independent macros to access individual bytes in a word.This may seem obvious, 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

30、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 good as hand-tuned native assembler code. Our own research at Microsoft indicates that performance problems are more often the r

31、esult of poor algorithms than they are of poor code generation. Indeed, with RISC machines, hand-turned native assembler code may actually be 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 abso

32、lutely 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.A major goal of American National Standards Institute (ANSI) C/C+ is to provide a portable implementation of the language. Theoretically, code

33、written to strict ANSI CC+多平台中英文资料外文翻译文献compliance is completely portable to any compiler that implements the standard correctly. Microsoft Visual C+ provides a compiler option (/Za) to enable strict ANSI compatibility checking.Microsoft Visual C+ provides some language features that are in addition

34、 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 write programs that use four-character constants, for example, and know that your program is porta

35、ble to any 16-bit or 32-bit Microsoft Windows platform or to the Macintosh.Compilers normally align structures 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

36、 silently and seriously 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.Using function prototypes is mandatory for fully portable code. All

37、functions should be prototyped, and the prototype should exactly match the actual function declaration.Following the 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 addition

38、al changes in your sources.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 use APIs that only function under Windows NT, they will not work when y

39、our 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 of your application.Chief among the differences between Win16 and Win32 is linear addressing. That means

40、 pointers are now 32 bits wide and the keywords near and far are no longer supported. It also means code that assumes segmented memory will break under Win32.In addition to pointers, handles and graphic coordinates are now 32 bits. WINDOWS.H will resolve many of these size differences for you, but s

41、ome work is still necessary.The recommended strategy to get your application running under Win32 is to recompile for 32 bits, noting error messages and warnings. Next, replace complex procedures and assembly language routines with stub procedures. Then, make your main program work properly using the

42、 techniques above. Finally, replace each stubbed-out procedure with a portable version.C+多平台中英文资料外文翻译文献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 p

43、latforms, 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 general areas: Programming model differences Processor differences User interface (UI) differencesThese areas

44、 of difference are described below. Porting issues that accompany these differences are discussed in the section titled "Porting from Win32 to the Macintosh."The Windows and Macintosh APIs are completely different. For example: The event models are different. In Windows, you dispatch messa

45、ges 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 handle all possible events. Windows uses the concept of child windows. The Macintosh uses no child windows. Windows-based applications can

46、draw using either pens or brushes. Macintoshapplications can use only pens.Controls in Windows are built-in window classes. On the Macintosh, controls are unrelated to windows.Windows allows for 256 binary raster operations; the Macintosh allows for only 16. Because of the differences between the tw

47、o platforms, porting a Windows-based application to the Macintosh can be monumental task without powerful tools.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).

48、 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 number of registers.The Intel 8086 processor, from which subsequent 80x86 processors are descended, used 16-bit addresses, w

49、hich unfortunately allowed only 65,536 bytes of memory to be addressed. To allow the use of more memory, Intel implemented a segmented memory architecture to address one megabyte (220 bytes) of memory that used an unsigned 16-bit segment register and an unsigned 16-bit offset. This original Intel sc

50、heme has been extended to allow much larger amounts of memory to be addressed, but most existing Intel-based programming relies on separating code and data into 64K segments.C+多平台中英文资料外文翻译文献Although all Intel x86 processors since the 80386 have used 32-bit addressing, for compatibility reasons Micro

51、soft 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 wide. With the advent of Microsoft Windows NT, which is a true 32-bit operating system, all n

52、ative applications are 32-bit applications, which means that pointers and handles are 32 bits wide. Because Windows NT uses linear addressing, programs can share up to 4 gigabytes of memory.In contrast, the Motorola 68000 and PowerPC processor have always provided the ability to address a "flat

53、" 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 time, Macintosh code is generally divided into segments no larger than 32K.Microsoft Windows and Windows NT run only on so-called &

54、quot;little-endian" machinesprocessors 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 significant byte first, followed by the next most significant byte,

55、 and so on, with the least significant byte last.Compilers normally handle all details of byte ordering for your application program. Nevertheless, well-written portable code should never depend on the order of bytes.Microsoft Windows and the Macintosh present quite different user interfaces in many

56、 key areas, including menus, filenames, and multiple-document interface (MDI) applications.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 the menu, which dynamical

57、ly 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 menu. MDI is discussed in greater detail below.Macintosh applications generally have an "Apple me

58、nu" (the leftmost menu) that contains all the 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 for switching between application

59、s.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 that calls the Task Manager for switching applications.Generally, Windows-based applications contain keyboard equivalents in their menus. These are underlined letters in each menu entry that the user can select with the keyboard inC+多平台中英文资料外文翻译文献lieu of the mouse. This, however, is convention rather than requirement. Although some Macinto