计算机专业5000字外文翻译.docx

计算机专业5000字外文翻译附录A 译文 利用Visual C+把代码运行在多平台上 在今日，多平台的开发是一个热门课题。开发人员希望能够支持不同的平台，例如Windows 3.x, Windows NT, 和 Windows 95 操作系统, 还有Apple, Macintosh, UNIX, 和 RISC (reduced instruction set computer)等。直到不久之前，希望开发多平台任务的开发者们，只有很少的几种选择： 依据各个平台的不同的应用程序接口，为每个平台打算一份单独的代码。利用能跨平台的工具所供应的“虚拟API”。构建们自己的多平台层并支持它。但是到了今日，有了一种新的方法。开发人员可以通过运用微软和第三方的工具，把他们现存的针对Windows API写的代码，对以上列举的各种平台重新编译。本文要关注的就是与这种新方法相关的方法和论点。目前，Macintosh是紧随Windows之后，市场上最流行的图形用户界面系统。但是这两个完全不同的操作系统之间有太多的不同，须要开发人员学习新的API、新的范例程序、新的工具。一般状况下，对Macintosh应用程序的开发，须要和Windows不同的代码库，这些都增加了维护和升级的困难度。因为从Windows到Macintosh的代码转换是最难的情形，所以本文重点是这个内容。假如你的代码能顺当地实现对Macintosh平台的再编译，那么你就会发觉它其它平台上的再编译也不难。Microsoft Visual C+针对Macintosh供应的跨平台编辑器供应了一些工具，这些工具是在Windows NT或 Windows 95平台上运行，可以把Windows代码再编译，使其适应Motorola 680x0和PowerPC 处理器。它还供应了一个转换库来协助Windows程序在Macintosh上运行。这就使你可以开发单一的源代码（针对Win32® API的），并使它可以运行在Microsoft Windows 或 Apple Macintosh平台上。下面的第一章，说明白Visual C+是怎样针对Macintosh工作的。你的源代码在Windows NT或Windows 95上面编写，编译，连接。这些工具将产生68000 和PowerPC的自然代码，以及Macintosh资源。一个基于以太网或串行连接的传输层会把目标代码移动远端的目的Macintosh机器上运行。Macintosh应用程序在Macintosh平台上运行，并且在远端的Windows机器上面调试。现在，Apple公司有两个不同的Macintosh结构来竞争，可转换性尤其重要。转换的几个步骤取决于你处理的程序是16位还是32位。一般来说，一个Macintosh转换包括以下几步： 遵循一些转换性的方针以使你的程序更简单转换，这将不仅有助于保证基于680x0的 Macintosh机器的转换,也有助于更新，基于RISC 芯片的powerful PowerPC机器的转换。把你的Windows应用程序从16位代码转换成32位代码，这或许是最困难和耗时间的工作。把你独特的Windows应用程序分割，从熟识的执行方式到Macintosh。这将涉及到运用条件编译或者设计到你工程的资源树。利用Macintosh转换库把Win32 API代码转换成Macintosh代码，并利用Visual C+来编译、连接、调试。运用微软基础类库MFC 4.0实现一些新功能，例如OLE 2.0,服务器，客户端或者利用ODBC的数据库支持。运用MFC编写的代码对Macintosh有很高的可转换性。编写特地的Macintosh代码，可以利用Macintosh的独特特点，利用Apple 事务或出版和定购。开发人员通过Visual C+的特别的多平台编辑器，可以充分利用新的RISC硬件，例如DEC Alpha AXP机器。这些包括针对MIPS R4000 处理器系列和前面说的DEC Alpha AXP 芯片还有Motorola Power PC.这些工具在Windows NT 3.51下运行，能都产生针对DEC Alpha和Motorola PowerPC的高度优化的Win32应用程序。已经运用过这些工具进行再编译Win32资源的开发人员，对这过程的简洁感到惊异，因为这些平台上的操作系统是各自独立的，它们的工具也是独立的，但是完成一个转换确只须要很少的工作量。微软公司与两个第三方UNIX工具供应商合作亲密（Bristol Technology和 Mainsoft公司），这使得开发人员把自己的Win32或MFC程序针对UNIX进行再编译。开发人员可以通过干脆和这些公司接触来获得更多的信息。很早的时候，你可以选择是编写基于原始API或者基于MFC的程序。一般来说你会发觉MFC程序可转换性比Win32程序好，这是因为应用程序框架的一个内在优势是对基本操作系统进行了肯定程度的提炼，这种提炼类似于为你供应了一种平安保证。但是，开发人员经常对MFC有些疑问，例如： 假如我须要一种操作系统服务，但应用程序框架没有供应如何处理? 干脆调用Win32 API，MFC 不会阻挡你任何Win32 API的干脆调用，只要你在函数名前面加全局运算符(:)就可以了. 我不懂C+，还能用MFC吗？ 当然可以。MFC是基于C+的, 但是你可以把C和 C+ 代码很好的结合起来。 你在函数名前面加全局运算符(:)就可以了. 我怎么样起先运用MFC？ 从类起先，和/或从读一些书起先。Visual C+ 系统供应了一个很好地MFC指南(Scribble)，然后，购买MFC Migration Kit（可以网上付费，自己邮寄到微软），它将帮助你把C程序移植转换成为MFC和C+。 假如你从今日起先编写可转换性好的程序，那么全部的转换都会变得简洁。遵守一些基本的转换方针会使你的代码削减对特别平台的依靠。不要假定任何事，特殊是不要假定数据类型的大小、机器的状态、数据类型排序、或者队列不要假定简洁数据类型的大小，因为它们在不同的处理器上有不同的大小。例如，int在Win16和Win32上分别是2个字节和4个字节，无论如何，避开代码依靠于数据类型的大小。运用size of()来替换。运用offset of()宏来推断结构体的大小，而不要试图手动计算。运用可编程的借口去访问全部的系统或者隐藏“对象”，例如栈或堆。分解数据类型以提取单独的字节或比特，会在从Windows到Macintosh的转换时出问题，除非你在写代码时候当心，不假定任何类型分解。LIMITS.H包含了一些常量，用于协助书写独立入平台的宏，以访问独立的字节。这看上去很明显，因为没有什么比汇编语言可转换性更差了。像Microsoft Visual C+这样有内置汇编程序的编译器，可以很简单的摆脱汇编码来提高速度。然而，假如你想转换代码，要避开这种诱惑。假如不是必需的，当今的编译器可以产生和手动产生效果一样好的汇编码。我们在微软的探讨表明，问题出现的缘由往往是算法的不好，而不是代码的不好。事实上，由于行程和寄存器用法的过于困难，在RISC机器上，手动产生的汇编码要比机器产生的还要差。用c语言编写全部的程序，然后，假如你必需用汇编码重写，确保把两种执行程序都保存，利用条件编译，并且保持两种程序的更新。美国国家标准委员会（ANSI）对C/C+的一个主要目标是，供应一个可转换的这种语言的执行程序。理论上说，严格根据ANSI C编写的程序，对于任何执行ANSI C标准的编译器都是可以转换的。Microsoft Visual C+供应了一个编译器选项，可以用来检查ANSI的兼容性。Microsoft Visual C+为ANSI C供应了一些语言细微环节的补充，例如4字符常数和单行的注释。运用Microsoft C扩充的程序可以转换到Microsoft Visual C+的任何其它执行操作。因此，你可以运用4字符常数编写程序，并且明白的程序可以转换到任何16位或32位Microsoft Windows平台，或者是Macintosh平台。编译器常常定位在目标机器体系上的结构，一些RISC机器，例如MIPS R4000，对排列尤为敏感。排列错误可能导致执行期错误，或者可能静静地和显著的影响你的程序。因此，避开封装结构，限制对硬件接口与兼容性地东西如文件格式和磁盘结构的封装。运用函数原型对于可转换代码来说吩咐，全部的函数都应当有原型，并且这些原型应当与实际声名的函数完全匹配。遵循上面的方针，将会是你的代码简单转换，但是，假如你代码是16位的Windows代码，那你第一步要做的是使它能在Win32下正常工作，这须要你的资源作额外的变更。为Win32编写的代码可以在任何Windows版本下运行，有转换库时候还可以在Macintosh下运行。可转换的代码应当能在随意平台上正确的编译和执行。当然，假如你运用Windows NT 特有的API，那他们在Windows 3.X下将不能工作，例如有些线程在Windows NT 下工作，却不能在Windows 3.11工作。这些函数区分应当在你设计程序时候考虑到。Win16 和 Win32的主要区分是寻址长度，意思是现在32位的指针对于或远或近的关键词不再支持了，也意味着分段存储的代码在Win32下会不能工作。除了指针，句柄和图形调整也是32位，WINDOWS.H会解决一些大小不同的问题，但是仍旧有一些工作须要作。关于把你的程序在Win32下运行的举荐的策略，是把你的代码再编译成 32 bit的, 留意错误消息和警告。接着，把困难的函数和汇编语言函数用子函数代替，然后，利用上面的技术使你的主程序正确的工作。最终用一个可转换的版本代替全部的子函数。当你已经胜利地把你的Windows程序从16 bits 转换为32 bits,你应当打算好了着手把它转换成 Macintosh，因为这两个平台之间存在很大的区分，所以这个工作会显得令人畏惧。在你起先转换你的程序之前，你最好先明白这些区分。Macintosh 与 Windows区分在三个方面： 编程样式的区分 处理器的区分 用户界面的区分 这些方面的区分会在下面叙述。伴随这些区分出现的转换问题会在“从Win32 到 Macintosh的转换”一节中探讨。Windows和Macintosh的APIs 完全不同，例如: 事务模型不同。在Windows里，你分派消息到 WindowProcs，运用 DefWindowProc 处理你不关切的消息 。在 Macintosh里，你有一个大的事务循环来处理全部可能出现的消息。Windows运用子窗口的概念，Macintosh 不运用子窗口。Windows应用程序可以运用画笔或者画刷绘图， Macintosh 应用程序只能运用画笔。Windows中的控件建立在窗口类上，在Macintosh中， 控件和窗口没有关系。Windows 允许256位的色调的操作;Macintosh 只允许16位的操作。因为两个平台之间的这些区分，从一个Windows应用程序到 Macintosh 程序的转变假如没有有力的工具，那将是一个艰难的任务。Windows 始终在 Intel x86 处理器上运行 (除了 Windows NT)，并且Macintosh 始终在Motorola 680x0 处理器上运行(当然, Macintosh 现在也能在PowerPC上运行)。两个处理器家族间的区分包括寻址和字节排序，还有opcodes, 指令集,以及寄存器的名字和数量。Intel 8086 处理器, 以及随后衍生的80x86系列处理器运用16-bit地址， 只能支持65,536 bytes 的存储器寻址。为了支持运用更大的内存，Intel 运用分段存储器结构， 这样利用16-bit寄存器可以访问1兆(220 bytes)内存，还有一个unsigned 16-bit的偏移量。Intel 最初的这种配置已经扩展，允许访问更大的内存了，但是绝大多数现存的Intel程序须要把分别的代码和数据放在64k的段存储器上。虽然Intel x86处理器从80386已经起先运用32-bit寻址, 但是因为兼容性的缘由，Microsoft Windows 3.x 实际是一个16-bit程序, 并且全部的Microsoft Windows应用程序都要写成16位的。这就是说绝大多数的指针和句柄是16 bits 长。Microsoft Windows NT是一个纯32-bit操作系统, 伴随着它的出现，它全部的应用程序都是32-bit的, 指针和句柄也都是32 bits长。因为 Windows NT 运用线性寻址,程序可以分散在 4G的内存里面。与之对比， Motorola 68000和 PowerPC 处理器只能访问“平坦的“ 32-bit存储空间， 理论上说，这种平坦的存储空间简化了存储器寻址。实践中，因为4-byte 寻址由于太大不会始终运用， Macintosh 代码一般分到不大于32K的段中存储。Microsoft Windows 和 Windows NT 只能运行在所谓的 “little-endian“ 机器上处理器把不重要的字节放在前面，把最重要的字节放在最终面，与之对比， Motorola 680x0和PowerPC (一个所谓的 “big-endian“ 结构)把最重要的字节放在最前面，紧接着放其次重要的字节，依此类推，最不重要的放在最终面。编译器通常为你的程序处理字节排序的细微环节，然而，好的可转换性强的代码从不依靠字节的排序 Microsoft Windows 和 Macintosh 在许多关键地方的用户界面有较大区分，包括菜单，文件名，和多文档界面程序。Macintosh 只有一个菜单栏，并且不管屏幕上窗口数量和布局如何，它总是处于同一个位置。“活动窗口” 包含菜单，这个菜单会随着活动窗口的变更而动态的改变。然而Windows, 给每个处于顶端的窗口以菜单。而且在 MDI时,每一个子窗口可以有自己的菜单， MDI会在下面具体探讨 。Macintosh 应用程序通常包含“Apple menu“，它包含了全部桌面安装的附件，以及应用程序的入口。在System 7中, Macintosh 菜单的最右边包含了一个Apple的帮助图标，还有一个负责应用程序之间切换的菜单。Windows应用程序通常在窗口左上角有一个系统菜单，这个菜单包含系统级功能如窗口大小，移动，关闭窗口，还有一个可以在应用程序之间切换的被称作任务管理器的项目。通常， Windows程序包含和键盘等效的菜单项目，这些划有底线的字母分布在每一个菜单入口，用户可以用键盘代替鼠标来选择它们。这些是惯例而不是必需的，尽管Macintosh 程序必需有这些等价项。 文件名和路径名是Windows 和 Macintosh之间最大的区分之一，而且或许是最难出的。很多程序员说处理文件名是转换中最费时间和精力的地方。你的Windows应用程序或许能够处理的文件名类似于“C:ACCTGDATASEPT93.DAT.“ MS-DOS 和Windows 应用程序遵守传统的8.3 文件格式。另一方面Macintosh 应用程序处理的文件名却类似于“September, 1993 Accounting Data.“ MDI窗口允许一个活动窗口框架内有多个子窗口，很多Windows程序，例如 Microsoft Word是MDI应用程序。MDI 程序的一个特点是子窗口最小化后，会在MDI框架内部产生一个图标。每个MDI子窗口也会自己的菜单 。 Macintosh 不支持 MDI 窗口，一个应用程序可以打开多个窗口；然而这些窗口不能变成图标，并且它们共享一个菜单。这个区分或许须要程序针对Macintosh 转换而重新设计。最终你能够接着作你最了解的工作。编写针对Windows API，但又能转换成其它平台版本运行的程序，Visual C+现在使你能够做到这些。保持你的代码的可转换性，时时考虑到转换性能，并且运用有效的工具可以帮助你在多平台之间轻松地跳动。 附录B 外文原文 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 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 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+® 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 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. Figure 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 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 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 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) processors. Microsoft works closely with two third-party UNIX tools providers, Bristol 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. 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 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. However, developers frequently have questions about MFC, such as: What if I need 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 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 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 guidelines will make your code less platform-specific. Never assume anything. Particularly, dont make assumptions about 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 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 even bits can cause problems when porting from Windows to the Macin