外文原文
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 Microsoftreg; Windowsreg; version 3.x, Microsoft Windows NTreg;, and Microsoft Windows 95 operating systems, and Applereg;, Macintoshreg;, 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 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, 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 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 and 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, you may elect to include), youll find that it will come up on other platforms easily as well.
Microsoft Visual C reg; Cross-Development Edition for Macintosh (Visual C for Mactrade;) 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. This allows you to develop GUI applications with a single source code base (written to the Win32reg; 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 Windows NT– or Windows 95–based (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 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 with new 32-bit sources. In general, the steps to a Macintosh port are as follows:
- 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 machines that are based on a RISC chip.
- 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.
- Segregate 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 for your project.
- Port your Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C for compiling, linking, and debugging.
- 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.
- Write Macintosh-specific 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 (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 to be run (that is, machines still running Windows 3.11)? The obvious choice is to use the Win32sreg; 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 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 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 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 than on 32-bit (that is, Intel) pr
剩余内容已隐藏，支付完成后下载完整资料
外文原文
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 Microsoftreg; Windowsreg; version 3.x, Microsoft Windows NTreg;, and Microsoft Windows 95 operating systems, and Applereg;, Macintoshreg;, 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 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, 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 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 and 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, you may elect to include), youll find that it will come up on other platforms easily as well.
Microsoft Visual C reg; Cross-Development Edition for Macintosh (Visual C for Mactrade;) 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. This allows you to develop GUI applications with a single source code base (written to the Win32reg; 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 Windows NT– or Windows 95–based (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 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 with new 32-bit sources. In general, the steps to a Macintosh port are as follows:
- 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 machines that are based on a RISC chip.
- 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.
- Segregate 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 for your project.
- Port your Win32 API code to the Macintosh by using the portability library for the Macintosh and Visual C for compiling, linking, and debugging.
- 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.
- Write Macintosh-specific 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 (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 to be run (that is, machines still running Windows 3.11)? The obvious choice is to use the Win32sreg; 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 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 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 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 than on 32-bit (that is, Intel) pr
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[499639]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
