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

C++多平台中英文资料外文翻译文献C++多平台中英文资料外文翻译文献外文原文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:Makeyourapplicationmoreportablebyfollowingsomegeneralportabilityguidelines.Thiswillhelpinsurenotonlyportabilitytothe680x0-basedMacintoshmachines,butalsotothenewer,morepowerfulPowerPCmachinesthatarebasedonaRISCchip.PortyourapplicationfromWindows16-bitcodeto32-bitcode.Thismaybethemostcomplexandtime-consumingpartofthejob.SegregatethosepartsofyourapplicationthatareuniquetoWindowsfromsimilarimplementationsthatarespecifictotheMacintosh.Thismayinvolveusingconditionalcompilationoritmayinvolvechangingthesourcetreeforyourproject.PortyourWin32APIcodetotheMacintoshbyusingtheportabilitylibraryfortheMacintoshandVisualC++forcompiling,linking,anddebugging.UsetheMicrosoftFoundationClassLibrary(MFC)version4.0toimplementnewfunctionalitysuchasOLE2.0containers,servers,andclientsordatabasesupportusingopendatabaseconnectivity(ODBC).CodewrittenusingMFCishighlyportabletotheMacintosh.WriteMacintosh-specificcodetotakeadvantageofuniqueMacintoshfeatures,suchasAppleEventsorPublishandSubscribe.ThechiefchallengeamongthefamiliesofWindowsoperatingsystemsisthebreakfrom16bits(Windows3.11andWindowsforWorkgroups3.11operatingsystemwithintegratednetworking)to32bits(WindowsNTandWindows95).Ingeneral,16-bitand32-bitcodebasesaresomewhatincompatible,unlesstheyarewrittenusingMFC.Developershavethechoiceofbranchingtheirsourcesintotwotrees,ormigratingeverythingto32bits.OncetheWin32choicehasbeenmade,howarelegacyplatformstoberun(thatis,machinesstillrunningWindows3.11)?TheobviouschoiceistousetheWin32s®APIlibraries,whichthunk32-bitcallsdowntotheir16-bitcounterparts.DeveloperswhowanttheirapplicationstobeabletotakeadvantageofthehotnewRISChardware,suchasDECAlphaAXPmachines,canusethespecialmultipleplatformeditionsofVisualC++.TheseincludeversionsfortheMIPSR4000seriesofprocessorsaswellastheaforementionedDECAlphaAXPchipandtheMotorolaPowerPC.ThesetoolsetsrununderWindowsNT3.51andcreatehighlyoptimizednativeWin32applicationsforDECAlphaandMotorolaPowerPCplatforms.DeveloperswhohaverecompiledtheirWin32sourcesusingthesetoolsetsareamazedathowsimpleitis.Sincetheoperatingsystemisidenticalonallplatforms,andthetoolsareidentical,littleworkhastobedoneinordertoachieveaport.ThekeydifferenceintheRISCmachinesfromIntelistheexistenceofanative64-bitinteger,whichisfarmoreefficientthanon32-bit(thatis,Intel)processors.Microsoftworkscloselywithtwothird-partyUNIXtoolsproviders,BristolTechnologyandMainsoftCorporation,toallowdeveloperstorecompiletheirWin32-basedorMFC-basedapplicationsforUNIX.Developersseekingadditionalinformationshouldcontactthosecompaniesdirectly.You'llhavetodecideearlyonwhethertowritetothenativeAPI(Win32)ortoMFC.Ingeneralyou'llfindMFCapplicationswillportmorequicklythanWin32applications.Thisisbecauseoneoftheintrinsicbenefitsofanapplicationframeworkisanabstractionofthecodeawayfromthenativeoperatingsystemtosomeextent.Thisabstractionislikeaninsurancepolicyforyou.However,developersfrequentlyhavequestionsaboutMFC,suchas:WhatifIneedanoperatingsystemservicethatisn'tpartoftheframework?CalltheWin32APIdirectly.MFCneverpreventsyoufromcallinganyfunctionintheWin32APIdirectly.Justprecedeyourfunctioncallwiththeglobalscopeoperator(::).Idon'tknowC++.CanIstilluseMFC?Sure.MFCisbasedonC++,butyoucanmixCandC++codeseamlessly.HowcanIgetstartedusingMFC?Startbytakingsomeclassesand/orreadingsomebooks.VisualC++shipswithafinetutorialonMFC(Scribble).Then,checkouttheMFCMigrationKit(availableonCompuServeor,foramodestshippingandhandlingfee,fromMicrosoft).ItwillhelpyoumigrateyourC-basedapplicationcodetoMFCandC++.Allportingwillbeeasierifyoubegintodaywritingmoreportableprograms.Followingsomebasicportabilityguidelineswillmakeyourcodelessplatform-specific.Neverassumeanything.Particularly,don'tmakeassumptionsaboutthesizesoftypes,thestateofthemachineatanytime,byteordering,oralignment.Don'tassumethesizeofprimitivetypes,becausethesehavedifferentsizesondifferentprocessors.Forexample,anintistwobytesinWin16andfourbytesinWin32.Atallcosts,avoidcodethatreliesonthesizeofatype.Usesizeof()instead.Todeterminetheoffsetofafieldinastructure,usetheoffsetof()macro.Don'ttrytocomputethismanually.Useprogrammaticinterfacestoaccessallsystemorhidden"objects,"forexample,thestackorheap.ParsingdatatypestoextractindividualbytesorevenbitscancauseproblemswhenportingfromWindowstotheMacintoshunlessyouarecarefultowritecodethatdoesn'tassumeanyparticularbyteorder.LIMITS.Hcontainsconstantsthatcanbeusedtohelpwriteplatform-independentmacrostoaccessindividualbytesinaword.Thismayseemobvious,becausenothingcouldbelessportablethanassemblylanguage.Compilers,suchasMicrosoftVisualC++,thatprovideinlineassemblersmakeiteasytoslipinalittleassemblercodetospeedthingsup.Ifyouwantportablecode,however,avoidthistemptation.Itmaynotbenecessary.Moderncompilerscanoftengeneratecodeasgoodashand-tunednativeassemblercode.OurownresearchatMicrosoftindicatesthatperformanceproblemsaremoreoftentheresultofpooralgorithmsthantheyareofpoorcodegeneration.Indeed,withRISCmachines,hand-turnednativeassemblercodemayactuallybeworsethanmachine-generatedcode,duetothecomplexityofinstructionschedulingandpickingregisterusage.WriteallroutinesinCfirst;then,ifyouabsolutelyneedtorewriteoneinassembler,besuretoleavebothimplementationsinyoursources,controlledbyconditionalcompiles,andkeepbothuptodate.AmajorgoalofAmericanNationalStandardsInstitute(ANSI)C/C++istoprovideaportableimplementationofthelanguage.Theoretically,codewrittentostrictANSICcomplianceiscompletelyportabletoanycompilerthatimplementsthestandardcorrectly.MicrosoftVisualC++providesacompileroption(/Za)toenablestrictANSIcompatibilitychecking.MicrosoftVisualC++providessomelanguagefeaturesthatareinadditiontoANSIC,suchasfour-characterconstantsandsingle-linecomments.ProgramsthatusetheMicrosoftCextensionsshouldbeportabletoallotherimplementationsofMicrosoftVisualC++.Thus,youcanwriteprogramsthatusefour-characterconstants,forexample,andknowthatyourprogramisportabletoany16-bitor32-bitMicrosoftWindowsplatformortotheMacintosh.Compilersnormallyalignstructuresbasedonthetargetmachinearchitecture;someRISCmachines,suchastheMIPSR4000,areparticularlysensitivetoalignment.Alignmentfaultsmaygeneraterun-timeerrorsor,instead,maysilentlyandseriouslydegradetheperformanceofyourapplication.Forportability,therefore,avoidpackingstructures.Limitpackingtohardwareinterfacesandtocompatibilityissuessuchasfileformatsandon-diskstructures.Usingfunctionprototypesismandatoryforfullyportablecode.Allfunctionsshouldbeprototyped,andtheprototypeshouldexactlymatchtheactualfunctiondeclaration.Followingtheguidelinesabovewillmakeyourcodealotmoreportable.However,ifyouhave16-bitWindowscode,yourfirststepistomakeitworkproperlyunderWin32.Thiswillrequireadditionalchangesinyoursources.CodewrittenforWin32canrunonanyversionofWindows,includingontheMacintosh,usingtheportabilitylibrary.Portablecodeshouldcompileandexecuteproperlyonanyplatform.Ofcourse,ifyouuseAPIsthatonlyfunctionunderWindowsNT,theywillnotworkwhenyourapplicationrunsunderWindows3.x.Forexample,threadsworkunderWindowsNTbutnotunderWindows3.11.Thosetypesoffunctionalitydifferenceswillhavetobeaccountedforinthedesignofyourapplication.ChiefamongthedifferencesbetweenWin16andWin32islinearaddressing.Thatmeanspointersarenow32bitswideandthekeywordsnearandfararenolongersupported.ItalsomeanscodethatassumessegmentedmemorywillbreakunderWin32.Inadditiontopointers,handlesandgraphiccoordinatesarenow32bits.WINDOWS.Hwillresolvemanyofthesesizedifferencesforyou,butsomeworkisstillnecessary.TherecommendedstrategytogetyourapplicationrunningunderWin32istorecompilefor32bits,notingerrormessagesandwarnings.Next,replacecomplexproceduresandassemblylanguageroutineswithstubprocedures.Then,makeyourmainprogramworkproperlyusingthetechniquesabove.Finally,replaceeachstubbed-outprocedurewithaportableversion.AfteryousuccessfullyconvertyourWindows-basedprogramfrom16bitsto32bits,you'rereadytoembarkonportingittotheMacintosh.Becausesignificantdifferencesexistbetweenthetwoplatforms,thistaskcanappeardaunting.Beforeyoucanbegintoportyourapplication,youneedtobetterunderstandthesedifferences.TheMacintoshisdifferentiatedfromWindowsinthreegeneralareas:ProgrammingmodeldifferencesProcessordifferencesUserinterface(UI)differencesTheseareasofdifferencearedescribedbelow.Portingissuesthataccompanythesedifferencesarediscussedinthesectiontitled"PortingfromWin32totheMacintosh."TheWindowsandMacintoshAPIsarecompletelydifferent.Forexample:Theeventmodelsaredifferent.InWindows,youdispatchmessagestoWindowProcs.YouuseDefWindowProctohandlemessagesinwhichyou'renotspecificallyinterested.OntheMacintosh,youhaveabigmaineventlooptohandleallpossibleevents.Windowsusestheconceptofchildwindows.TheMacintoshusesnochildwindows.Windows-basedapplicationscandrawusingeitherpensorbrushes.Macintoshapplicationscanuseonlypens.ControlsinWindowsarebuilt-inwindowclasses.OntheMacintosh,controlsareunrelatedtowindows.Windowsallowsfor256binaryrasteroperations;theMacintoshallowsforonly16.Becauseofthedifferencesbetweenthetwoplatforms,portingaWindows-basedapplicationtotheMacintoshcanbemonumentaltaskwithoutpowerfultools.WindowshasalwaysrunonIntelx86processors(untilWindowsNT),andtheMacintoshhasrunonMotorola680x0processors(ofcourse,thePowerPC-basedMacintoshisnowavailableaswell).Differencesbetweentheprocessorfamiliesincludeaddressingandbyteordering,inadditiontothemoreexpecteddifferenceslikeopcodes,instructionsets,andthenameandnumberofregisters.TheIntel8086processor,fromwhichsubsequent80x86processorsaredescended,used16-bitaddresses,whichunfortunatelyallowedonly65,536bytesofmemorytobeaddressed.Toallowtheuseofmorememory,Intelimplementedasegmentedmemoryarchitecturetoaddressonemegabyte(2^20bytes)ofmemorythatusedanunsigned16-bitsegmentregisterandanunsigned16-bitoffset.ThisoriginalIntelschemehasbeenextendedtoallowmuchlargeramountsofmemorytobeaddressed,butmostexistingIntel-basedprogrammingreliesonseparatingcodeanddatainto64Ksegments.AlthoughallIntelx86processorssincethe80386haveused32-bitaddressing,forcompatibilityreasonsMicrosoftWindows3.xisactuallya16-bitapplication,andallMicrosoftWindows-basedapplicationshadtobewrittenas16-bitapplications.Thatmeant,forexample,thatmostpointersandhandleswere16bitswide.WiththeadventofMicrosoftWindowsNT,whichisatrue32-bitoperatingsystem,allnativeapplicationsare32-bitapplications,whichmeansthatpointersandhandlesare32bitswide.BecauseWindowsNTuseslinearaddressing,programscanshareupto4gigabytesofmemory.Incontrast,theMotorola68000andPowerPCprocessorhavealwaysprovidedtheabilitytoaddressa"flat"32-bitmemoryspace.Intheory,aflatmemoryspaceofthiskindsimplifiesmemoryaddressing.Inpractice,because4-byteaddressesaretoolargetouseallthetime,Macintoshcodeisgenerallydividedintosegmentsnolargerthan32K.MicrosoftWindowsandWindowsNTrunonlyonso-called"little-endian"machines—processorsthatplacetheleastsignificantbytefirstandthemostsignificantbytelast.Incontrast,theMotorola680x0andPowerPC(aso-called"big-endian"architecture)placethemostsignificantbytefirst,followedbythenextmostsignificantbyte,andsoon,withtheleastsignificantbytelast.Compilersnormallyhandlealldetailsofbyteorderingforyourapplicationprogram.Nevertheless,well-writtenportablecodeshouldneverdependontheorderofbytes.MicrosoftWindowsandtheMacintoshpresentquitedifferentuserinterfacesinmanykeyareas,includingmenus,filenames,andmultiple-documentinterface(MDI)applications.OnlyonemenubarexistsontheMacintosh,anditisalwaysinthesameplace,regardlessofthenumberorarrangementofwindowsonthescreen.The"activewindow"containsthemenu,whichdynamicallychangesasnecessarywhendifferentwindowsaremadeactive.Windows,ontheotherhand,giveseachtop-levelwindowitsownmenu.Inaddition,underMDI,eachchildwindowcanalsohaveitsownmenu.MDIisdiscussedingreaterdetailbelow.Macintoshapplicationsgenerallyhavean"Applemenu"(theleftmostmenu)thatcontainsalltheinstalledDeskAccessoriesandusuallycontainsanAboutentryfortheapplication.UnderSystem7,theextremerightsideoftheMacintoshmenucontainsaniconforApple'sBalloonHelpandtheApplicationmenuforswitchingbetweenapplications.Windows-basedapplicationsalwayshaveaSystemmenuattheupper-leftcorneroftheirtop-levelwindow.Thismenucontainssystem-levelfunctionsforsizing,moving,andclosingthewindow,aswellasanitemthatcallstheTaskManagerforswitchingapplications.Generally,Windows-basedapplicationscontainkeyboardequivalentsintheirmenus.Theseareunderlinedlettersineachmenuentrythattheusercanselectwiththekeyboardinlieuofthemouse.This,however,isconventionratherthanrequirement.AlthoughsomeMacintoshapplicationshavetheseequivalents,mostdonot.FilenamesandpathnamesrepresentoneofthemostfundamentaldifferencesbetweenWindowsandtheMacintosh,aswellasperhapstheonemostdifficulttodealwith.Manyprogrammersreportdealingwithfilenamesastheareaofportinginwhichthemosttimeandenergyisspent.YourWindows-basedapplicationprobablyalreadyhandles(andexpects)filenamessuchas"C:\ACCTG\DATA\SEPT93.DAT."ApplicationsfortheMS-DOSandWindowsoperatingsystemsareboundbythetraditional8.3filenameformat.Macintoshapplications,ontheotherhand,canhandlefilenamessuchas"September,1993AccountingData."MDIwindowsallowformultiplechildwindowswithinthebordersofatop-levelwindow(the"MDIframe").ManyWindows-basedapplications,suchastheMicrosoftWordwordprocessorforWindows,areMDIapplications.CharacteristicofMDIapplicationsareclippedchildwindowsthatcanbeminimizedtoaniconwithintheMDIframe.EachMDIchildwindowcanalsohaveitsownmenu.TheMacintoshdoesnotsupportMDIwindows.Anapplicationcanhavemultiplewindowsopen;thosewindows,however,cannotbemadeintoicons,andtheyshareacommonmenu.Dependingontheapplication,thisdifferencemaynecessitatesignificantredesignforaMacintoshport.Finallyyoucankeepdoingwhatyouknowhowtodobest,writingtotheWindowsAPI,andstillallowforversionsofyourapplicationthatrunonotherplatforms.VisualC++nowgivesyouspecialversionsthatallowyoutodothis.Keepingyourcodeportable,thinkingaboutportabilityallthetime,andusingtherighttoolswillhelpyoumakethemultipleplatformjumpaseffortlessaspossible..中文翻译利用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转换为