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

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

《计算机专业5000字外文翻译.docx》由会员分享，可在线阅读，更多相关《计算机专业5000字外文翻译.docx（12页珍藏版）》请在冰豆网上搜索。

计算机专业5000字外文翻译

附录A译文

利用VisualC++把代码运行在多平台上

在今天，多平台的开发是一个热门课题。

开发人员希望能够支持不同的平台，例如Windows3.x,WindowsNT,和Windows95操作系统,还有Apple,Macintosh,UNIX,和RISC（reducedinstructionsetcomputer）等。

直到不久之前，希望开发多平台任务的开发者们，只有很少的几种选择：

根据各个平台的不同的应用程序接口，为每个平台准备一份单独的代码。

利用能跨平台的工具所提供的“虚拟API”。

构建们自己的多平台层并支持它。

但是到了今天，有了一种新的办法。

开发人员可以通过使用微软和第三方的工具，把他们现存的针对WindowsAPI写的代码，对以上列举的各种平台重新编译。

本文要关注的就是与这种新办法相关的方法和论点。

目前，Macintosh是紧随Windows之后，市场上最流行的图形用户界面系统。

但是这两个完全不同的操作系统之间有太多的不同，需要开发人员学习新的API、新的范例程序、新的工具。

一般情况下，对Macintosh应用程序的开发，需要和Windows不同的代码库，这些都增加了维护和升级的复杂度。

因为从Windows到Macintosh的代码转换是最难的情形，所以本文重点是这个内容。

如果你的代码能顺利地实现对Macintosh平台的再编译，那么你就会发现它其它平台上的再编译也不难。

MicrosoftVisualC++针对Macintosh提供的跨平台编辑器提供了一些工具，这些工具是在WindowsNT或Windows95平台上运行，可以把Windows代码再编译，使其适应Motorola680x0和PowerPC处理器。

它还提供了一个转换库来辅助Windows程序在Macintosh上运行。

这就使你可以开发单一的源代码（针对Win32®API的），并使它可以运行在MicrosoftWindows或AppleMacintosh平台上。

下面的第一章，说明了VisualC++是怎样针对Macintosh工作的。

你的源代码在WindowsNT或Windows95上面编写，编译，连接。

这些工具将产生68000和PowerPC的自然代码，以及Macintosh资源。

一个基于以太网或串行连接的传输层会把目标代码移动远端的目的Macintosh机器上运行。

Macintosh应用程序在Macintosh平台上运行，并且在远端的Windows机器上面调试。

现在，Apple公司有两个不同的Macintosh结构来竞争，可转换性尤其重要。

转换的几个步骤取决于你处理的程序是16位还是32位。

一般来说，一个Macintosh转换包括以下几步：

遵循一些转换性的方针以使你的程序更容易转换，这将不仅有助于保证基于680x0的Macintosh机器的转换,也有助于更新，基于RISC芯片的powerfulPowerPC机器的转换。

把你的Windows应用程序从16位代码转换成32位代码，这也许是最复杂和耗时间的工作。

把你独特的Windows应用程序分割，从熟悉的执行方式到Macintosh。

这将涉及到使用条件编译或者设计到你工程的资源树。

利用Macintosh转换库把Win32API代码转换成Macintosh代码，并利用VisualC++来编译、连接、调试。

使用微软基础类库MFC4.0实现一些新功能，例如OLE2.0,服务器，客户端或者利用ODBC的数据库支持。

使用MFC编写的代码对Macintosh有很高的可转换性。

编写专门的Macintosh代码，可以利用Macintosh的独特特点，利用Apple事件或出版和定购。

开发人员通过VisualC++的特殊的多平台编辑器，可以充分利用新的RISC硬件，例如DECAlphaAXP机器。

这些包括针对MIPSR4000处理器系列和前面说的DECAlphaAXP芯片还有MotorolaPowerPC.这些工具在WindowsNT3.51下运行，能都产生针对DECAlpha和MotorolaPowerPC的高度优化的Win32应用程序。

已经使用过这些工具进行再编译Win32资源的开发人员，对这过程的简单感到惊讶，因为这些平台上的操作系统是各自独立的，它们的工具也是独立的，但是完成一个转换确只需要很少的工作量。

微软公司与两个第三方UNIX工具提供商合作密切（BristolTechnology和Mainsoft公司），这使得开发人员把自己的Win32或MFC程序针对UNIX进行再编译。

开发人员可以通过直接和这些公司接触来获得更多的信息。

很早的时候，你可以选择是编写基于原始API或者基于MFC的程序。

一般来说你会发现MFC程序可转换性比Win32程序好，这是因为应用程序框架的一个内在优势是对基本操作系统进行了一定程度的提炼，这种提炼类似于为你提供了一种安全保证。

但是，开发人员常常对MFC有些疑问，例如：

如果我需要一种操作系统服务，但应用程序框架没有提供如何处理?

直接调用Win32API，MFC不会阻止你任何Win32API的直接调用，只要你在函数名前面加全局运算符（:

:

）就可以了.

我不懂C++，还能用MFC吗？

当然可以。

MFC是基于C++的,但是你可以把C和C++代码很好的结合起来。

你在函数名前面加全局运算符（:

:

）就可以了.

我怎么样开始使用MFC？

从类开始，和/或从读一些书开始。

VisualC++系统提供了一个很好地MFC指南（Scribble），然后，购买MFCMigrationKit（可以网上付费，自己邮寄到微软），它将帮助你把C程序移植转换成为MFC和C++。

如果你从今天开始编写可转换性好的程序，那么所有的转换都会变得简单。

遵守一些基本的转换方针会使你的代码减少对特殊平台的依赖。

不要假定任何事，特别是不要假定数据类型的大小、机器的状态、数据类型排序、或者队列不要假定简单数据类型的大小，因为它们在不同的处理器上有不同的大小。

例如，int在Win16和Win32上分别是2个字节和4个字节，无论如何，避免代码依赖于数据类型的大小。

使用sizeof（）来替换。

使用offsetof（）宏来判断结构体的大小，而不要试图手动计算。

使用可编程的借口去访问所有的系统或者隐藏“对象”，例如栈或堆。

分解数据类型以提取单独的字节或比特，会在从Windows到Macintosh的转换时出问题，除非你在写代码时候小心，不假定任何类型分解。

LIMITS.H包含了一些常量，用于辅助书写独立入平台的宏，以访问独立的字节。

这看上去很明显，因为没有什么比汇编语言可转换性更差了。

像MicrosoftVisualC++这样有内置汇编程序的编译器，可以很容易的摆脱汇编码来提高速度。

然而，如果你想转换代码，要避免这种诱惑。

如果不是必须的，当今的编译器可以产生和手动产生效果一样好的汇编码。

我们在微软的研究表明，问题出现的原因往往是算法的不好，而不是代码的不好。

实际上，由于行程和寄存器用法的过于复杂，在RISC机器上，手动产生的汇编码要比机器产生的还要差。

用c语言编写所有的程序，然后，如果你必须用汇编码重写，确保把两种执行程序都保存，利用条件编译，并且保持两种程序的更新。

美国国家标准委员会（ANSI）对C/C++的一个主要目标是，提供一个可转换的这种语言的执行程序。

理论上说，严格按照ANSIC编写的程序，对于任何执行ANSIC标准的编译器都是可以转换的。

MicrosoftVisualC++提供了一个编译器选项，可以用来检查ANSI的兼容性。

MicrosoftVisualC++为ANSIC提供了一些语言细节的补充，例如4字符常数和单行的注释。

使用MicrosoftC扩充的程序可以转换到MicrosoftVisualC++的任何其它执行操作。

因此，你可以使用4字符常数编写程序，并且明白的程序可以转换到任何16位或32位MicrosoftWindows平台，或者是Macintosh平台。

编译器经常定位在目标机器体系上的结构，一些RISC机器，例如MIPSR4000，对排列尤为敏感。

排列错误可能导致执行期错误，或者可能悄悄地和显著的影响你的程序。

因此，避免封装结构，限制对硬件接口与兼容性地东西如文件格式和磁盘结构的封装。

使用函数原型对于可转换代码来说命令，所有的函数都应该有原型，并且这些原型应该与实际声名的函数完全匹配。

遵循上面的方针，将会是你的代码容易转换，但是，如果你代码是16位的Windows代码，那你第一步要做的是使它能在Win32下正常工作，这需要你的资源作额外的改变。

为Win32编写的代码可以在任何Windows版本下运行，有转换库时候还可以在Macintosh下运行。

可转换的代码应该能在任意平台上正确的编译和执行。

当然，如果你使用WindowsNT特有的API，那他们在Windows3.X下将不能工作，例如有些线程在WindowsNT下工作，却不能在Windows3.11工作。

这些函数区别应该在你设计程序时候考虑到。

Win16和Win32的主要区别是寻址长度，意思是现在32位的指针对于或远或近的关键词不再支持了，也意味着分段存储的代码在Win32下会不能工作。

除了指针，句柄和图形调节也是32位，WINDOWS.H会解决一些大小不同的问题，但是仍然有一些工作需要作。

关于把你的程序在Win32下运行的推荐的策略，是把你的代码再编译成32bit的,注意错误消息和警告。

接着，把复杂的函数和汇编语言函数用子函数代替，然后，利用上面的技术使你的主程序正确的工作。

最后用一个可转换的版本代替所有的子函数。

当你已经成功地把你的Windows程序从16bits转换为32bits,你应该准备好了着手把它转换成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一直在Intelx86处理器上运行（除了WindowsNT），并且Macintosh一直在Motorola680x0处理器上运行（当然,Macintosh现在也能在PowerPC上运行）。

两个处理器家族间的区别包括寻址和字节排序，还有opcodes,指令集,以及寄存器的名字和数量。

Intel8086处理器,以及随后衍生的80x86系列处理器使用16-bit地址，只能支持65,536bytes的存储器寻址。

为了支持使用更大的内存，Intel使用分段存储器结构，这样利用16-bit寄存器可以访问1兆（2^20bytes）内存，还有一个unsigned16-bit的偏移量。

Intel最初的这种配置已经扩展，允许访问更大的内存了，但是绝大多数现存的Intel程序需要把分离的代码和数据放在64k的段存储器上。

虽然Intelx86处理器从80386已经开始使用32-bit寻址,但是因为兼容性的原因，MicrosoftWindows3.x实际是一个16-bit程序,并且所有的MicrosoftWindows应用程序都要写成16位的。

这就是说绝大多数的指针和句柄是16bits长。

MicrosoftWindowsNT是一个纯32-bit操作系统,伴随着它的出现，它所有的应用程序都是32-bit的,指针和句柄也都是32bits长。

因为WindowsNT使用线性寻址,程序可以分散在4G的内存里面。

与之对比，Motorola68000和PowerPC处理器只能访问"平坦的"32-bit存储空间，理论上说，这种平坦的存储空间简化了存储器寻址。

实践中，因为4-byte寻址由于太大不会一直使用，Macintosh代码一般分到不大于32K的段中存储。

MicrosoftWindows和WindowsNT只能运行在所谓的"little-endian"机器上—处理器把不重要的字节放在前面，把最重要的字节放在最后面，与之对比，Motorola680x0和PowerPC（一个所谓的"big-endian"结构）把最重要的字节放在最前面，紧接着放第二重要的字节，依此类推，最不重要的放在最后面。

编译器通常为你的程序处理字节排序的细节，然而，好的可转换性强的代码从不依赖字节的排序

MicrosoftWindows和Macintosh在很多关键地方的用户界面有较大区别，包括菜单，文件名，和多文档界面程序。

Macintosh只有一个菜单栏，并且不管屏幕上窗口数量和布局如何，它总是处于同一个位置。

“活动窗口”包含菜单，这个菜单会随着活动窗口的改变而动态的变化。

然而Windows,给每个处于顶端的窗口以菜单。

而且在MDI时,每一个子窗口可以有自己的菜单，MDI会在下面详细讨论。

Macintosh应用程序通常包含"Applemenu"，它包含了所有桌面安装的附件，以及应用程序的入口。

在System7中,Macintosh菜单的最右边包含了一个Apple的帮助图标，还有一个负责应用程序之间切换的菜单。

Windows应用程序通常在窗口左上角有一个系统菜单，这个菜单包含系统级功能如窗口大小，移动，关闭窗口，还有一个可以在应用程序之间切换的被称作任务管理器的项目。

通常，Windows程序包含和键盘等效的菜单项目，这些划有底线的字母分布在每一个菜单入口，用户可以用键盘代替鼠标来选择它们。

这些是惯例而不是必需的，尽管Macintosh程序必须有这些等价项。

文件名和路径名是Windows和Macintosh之间最大的区别之一，而且也许是最难出的。

许多程序员说处理文件名是转换中最费时间和精力的地方。

你的Windows应用程序也许能够处理的文件名类似于"C:

\ACCTG\DATA\SEPT93.DAT."MS-DOS和Windows应用程序遵守传统的8.3文件格式。

另一方面Macintosh应用程序处理的文件名却类似于"September,1993AccountingData."

MDI窗口允许一个活动窗口框架内有多个子窗口，许多Windows程序，例如MicrosoftWord是MDI应用程序。

MDI程序的一个特点是子窗口最小化后，会在MDI框架内部产生一个图标。

每个MDI子窗口也会自己的菜单。

Macintosh不支持MDI窗口，一个应用程序可以打开多个窗口；然而这些窗口不能变成图标，并且它们共享一个菜单。

这个区别也许需要程序针对Macintosh转换而重新设计。

最终你能够继续作你最了解的工作。

编写针对WindowsAPI，但又能转换成其它平台版本运行的程序，VisualC++现在使你能够做到这些。

保持你的代码的可转换性，时时考虑到转换性能，并且使用有效的工具可以帮助你在多平台之间轻松地跳跃。

附录B外文原文

FromonecodebasetomanyplatformsusingVisualC++

Multiple-platformdevelopmentisahotissuetoday.DeveloperswanttobeabletosupportdiverseplatformssuchastheMicrosoft®Windows®version3.x,MicrosoftWindowsNT®,andMicrosoftWindows95operatingsystems,andApple®,Macintosh®,UNIX,andRISC（reducedinstructionsetcomputer）machines.Untilrecently,developerswantingtobuildversionsoftheirapplicationformorethanoneplatformhadfewchoices:

Maintainseparatecodebasesforeachplatform,writtentotheplatform'snativeapplicationprogramminginterface（API）.

Writetoa"virtualAPI"suchasthoseprovidedbycross-platformtoolsets.

Buildtheirownmultiple-platformlayerandsupportit.

Today,however,anewchoiceexists.DeveloperscanusetheirexistingcodewrittentotheWindowsAPIand,usingtoolsavailablefromMicrosoftandthirdparties,recompileforalloftheplatformslistedabove.Thispaperlooksatthemethodsandsomeoftheissuesinvolvedindoingso.

Currentlythemostlucrativemarketforgraphicaluserinterface（GUI）applications,afterMicrosoftWindows,istheAppleMacintosh.However,vastdifferencesseparatethesewhollydifferentoperatingsystems,requiringdeveloperstolearnnewAPIs,programmingparadigms,andtools.Generally,MacintoshdevelopmentrequiresaseparatecodebasefromtheWindowssources,increasingthecomplexityofmaintenanceandenhancement.

BecauseportingcodefromWindowstotheMacintoshcanbethemostdifficultportingcase,thispaperconcentratesinthisarea.Ingeneral,ifyourcodebaseissufficientlyportabletoenablestraightforwardrecompilingfortheMacintosh（excludinganyplatform-specific,or"edge"code,youmayelecttoinclude）,you'llfindthatitwillcomeuponotherplatformseasilyaswell.

MicrosoftVisualC++®Cross-DevelopmentEditionforMacintosh（VisualC++forMac™）providesasetofWindowsNT–orWindows95–hostedtoolsforrecompilingyourWindowscodefortheMotorola680x0andPowerPCprocessors,andaportabilitylibrarythatimplementsWindowsontheMacintosh.ThisallowsyoutodevelopGUIapplicationswithasinglesourcecodebase（writtentotheWin32®API）andimplementitonMicrosoftWindowsorAppleMacintoshplatforms.

Figure1,below,illustrateshowVisualC++forMacworks.Yoursourcecodeisedited,compiled,andlinkedonaWindowsNT–orWindows95–based（Intel）hostmachine.Thetoolscreate68000andPowerPCnativecodeandMacintoshresources.AnEthernet-basedorserialtransportlayer（TL）movestheresultingbinariestoaMacintoshtargetmachinerunningremotely.TheMacintoshapplicationisstartedontheMacintoshanddebuggedremotelyfromtheWindows-basedmachine.

NowthatApplehastwodifferentMacintosharchitecturestocontendwith（Motorola680x0andPowerPC）portabilityisparticularlyimportant.

Portingcaninvolveseveralsteps,dependingonwhetheryouareworkingwithold16-bitapplicationsorwithnew32-bitsources.Ingeneral,thestepstoaMacintoshportareasfollows:

Makeyourapplicationmoreportableby