C++多平臺中英文資料外文翻譯文獻(xiàn)

C++多平臺中英文資料外文翻譯文獻(xiàn)C++多平臺中英文資料外文翻譯文獻(xiàn)外文原文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++把代碼運行在多平臺上在今天，多平臺的開發(fā)是一個熱門課題。開發(fā)人員希望能夠支持不同的平臺，例如Windows3.x,WindowsNT,和Windows95操作系統(tǒng),還有Apple,Macintosh,UNIX,和RISC(reducedinstructionsetcomputer)等。直到不久之前，希望開發(fā)多平臺任務(wù)的開發(fā)者們，只有很少的幾種選擇：根據(jù)各個平臺的不同的應(yīng)用程序接口，為每個平臺準(zhǔn)備一份單獨的代碼。利用能跨平臺的工具所提供的“虛擬API”。構(gòu)建們自己的多平臺層并支持它。但是到了今天，有了一種新的辦法。開發(fā)人員可以通過使用微軟和第三方的工具，把他們現(xiàn)存的針對WindowsAPI寫的代碼，對以上列舉的各種平臺重新編譯。本文要關(guān)注的就是與這種新辦法相關(guān)的方法和論點。目前，Macintosh是緊隨Windows之后，市場上最流行的圖形用戶界面系統(tǒng)。但是這兩個完全不同的操作系統(tǒng)之間有太多的不同，需要開發(fā)人員學(xué)習(xí)新的API、新的范例程序、新的工具。一般情況下，對Macintosh應(yīng)用程序的開發(fā)，需要和Windows不同的代碼庫，這些都增加了維護(hù)和升級的復(fù)雜度。因為從Windows到Macintosh的代碼轉(zhuǎn)換是最難的情形，所以本文重點是這個內(nèi)容。如果你的代碼能順利地實現(xiàn)對Macintosh平臺的再編譯，那么你就會發(fā)現(xiàn)它其它平臺上的再編譯也不難。MicrosoftVisualC++針對Macintosh提供的跨平臺編輯器提供了一些工具，這些工具是在WindowsNT或Windows95平臺上運行，可以把Windows代碼再編譯，使其適應(yīng)Motorola680x0和PowerPC處理器。它還提供了一個轉(zhuǎn)換庫來輔助Windows程序在Macintosh上運行。這就使你可以開發(fā)單一的源代碼（針對Win32?API的），并使它可以運行在MicrosoftWindows或AppleMacintosh平臺上。下面的第一章，說明了VisualC++是怎樣針對Macintosh工作的。你的源代碼在WindowsNT或Windows95上面編寫，編譯，連接。這些工具將產(chǎn)生68000和PowerPC的自然代碼，以及Macintosh資源。一個基于以太網(wǎng)或串行連接的傳輸層會把目標(biāo)代碼移動遠(yuǎn)端的目的Macintosh機(jī)器上運行。Macintosh應(yīng)用程序在Macintosh平臺上運行，并且在遠(yuǎn)端的Windows機(jī)器上面調(diào)試?，F(xiàn)在，Apple公司有兩個不同的Macintosh結(jié)構(gòu)來競爭，可轉(zhuǎn)換性尤其重要。轉(zhuǎn)換的幾個步驟取決于你處理的程序是16位還是32位。一般來說，一個Macintosh轉(zhuǎn)換包括以下幾步：遵循一些轉(zhuǎn)換性的方針以使你的程序更容易轉(zhuǎn)換，這將不僅有助于保證基于680x0的Macintosh機(jī)器的轉(zhuǎn)換,也有助于更新，基于RISC芯片的powerfulPowerPC機(jī)器的轉(zhuǎn)換。把你的Windows應(yīng)用程序從16位代碼轉(zhuǎn)換成32位代碼，這也許是最復(fù)雜和耗時間的工作。把你獨特的Windows應(yīng)用程序分割，從熟悉的執(zhí)行方式到Macintosh。這將涉及到使用條件編譯或者設(shè)計到你工程的資源樹。利用Macintosh轉(zhuǎn)換庫把Win32API代碼轉(zhuǎn)換成Macintosh代碼，并利用VisualC++來編譯、連接、調(diào)試。使用微軟基礎(chǔ)類庫MFC4.0實現(xiàn)一些新功能，例如OLE2.0,服務(wù)器，客戶端或者利用ODBC的數(shù)據(jù)庫支持。使用MFC編寫的代碼對Macintosh有很高的可轉(zhuǎn)換性。編寫專門的Macintosh代碼，可以利用Macintosh的獨特特點，利用Apple事件或出版和定購。開發(fā)人員通過VisualC++的特殊的多平臺編輯器，可以充分利用新的RISC硬件，例如DECAlphaAXP機(jī)器。這些包括針對MIPSR4000處理器系列和前面說的DECAlphaAXP芯片還有MotorolaPowerPC.這些工具在WindowsNT3.51下運行，能都產(chǎn)生針對DECAlpha和MotorolaPowerPC的高度優(yōu)化的Win32應(yīng)用程序。已經(jīng)使用過這些工具進(jìn)行再編譯Win32資源的開發(fā)人員，對這過程的簡單感到驚訝，因為這些平臺上的操作系統(tǒng)是各自獨立的，它們的工具也是獨立的，但是完成一個轉(zhuǎn)換確只需要很少的工作量。微軟公司與兩個第三方UNIX工具提供商合作密切（BristolTechnology和Mainsoft公司），這使得開發(fā)人員把自己的Win32或MFC程序針對UNIX進(jìn)行再編譯。開發(fā)人員可以通過直接和這些公司接觸來獲得更多的信息。很早的時候，你可以選擇是編寫基于原始API或者基于MFC的程序。一般來說你會發(fā)現(xiàn)MFC程序可轉(zhuǎn)換性比Win32程序好，這是因為應(yīng)用程序框架的一個內(nèi)在優(yōu)勢是對基本操作系統(tǒng)進(jìn)行了一定程度的提煉，這種提煉類似于為你提供了一種安全保證。但是，開發(fā)人員常常對MFC有些疑問，例如：如果我需要一種操作系統(tǒng)服務(wù)，但應(yīng)用程序框架沒有提供如何處理?直接調(diào)用Win32API，MFC不會阻止你任何Win32API的直接調(diào)用，只要你在函數(shù)名前面加全局運算符(::)就可以了.我不懂C++，還能用MFC嗎？當(dāng)然可以。MFC是基于C++的,但是你可以把C和C++代碼很好的結(jié)合起來。你在函數(shù)名前面加全局運算符(::)就可以了.我怎么樣開始使用MFC？從類開始，和/或從讀一些書開始。VisualC++系統(tǒng)提供了一個很好地MFC指南(Scribble)，然后，購買MFCMigrationKit（可以網(wǎng)上付費，自己郵寄到微軟），它將幫助你把C程序移植轉(zhuǎn)換成為MFC和C++。如果你從今天開始編寫可轉(zhuǎn)換性好的程序，那么所有的轉(zhuǎn)換都會變得簡單。遵守一些基本的轉(zhuǎn)換方針會使你的代碼減少對特殊平臺的依賴。不要假定任何事，特別是不要假定數(shù)據(jù)類型的大小、機(jī)器的狀態(tài)、數(shù)據(jù)類型排序、或者隊列不要假定簡單數(shù)據(jù)類型的大小，因為它們在不同的處理器上有不同的大小。例如，int在Win16和Win32上分別是2個字節(jié)和4個字節(jié)，無論如何，避免代碼依賴于數(shù)據(jù)類型的大小。使用sizeof()來替換。使用offsetof()宏來判斷結(jié)構(gòu)體的大小，而不要試圖手動計算。使用可編程的借口去訪問所有的系統(tǒng)或者隱藏“對象”，例如?；蚨选７纸鈹?shù)據(jù)類型以提取單獨的字節(jié)或比特，會在從Windows到Macintosh的轉(zhuǎn)換時出問題，除非你在寫代碼時候小心，不假定任何類型分解。LIMITS.H包含了一些常量，用于輔助書寫?yīng)毩⑷肫脚_的宏，以訪問獨立的字節(jié)。這看上去很明顯，因為沒有什么比匯編語言可轉(zhuǎn)換性更差了。像MicrosoftVisualC++這樣有內(nèi)置匯編程序的編譯器，可以很容易的擺脫匯編碼來提高速度。然而，如果你想轉(zhuǎn)換代碼，要避免這種誘惑。如果不是必須的，當(dāng)今的編譯器可以產(chǎn)生和手動產(chǎn)生效果一樣好的匯編碼。我們在微軟的研究表明，問題出現(xiàn)的原因往往是算法的不好，而不是代碼的不好。實際上，由于行程和寄存器用法的過于復(fù)雜，在RISC機(jī)器上，手動產(chǎn)生的匯編碼要比機(jī)器產(chǎn)生的還要差。用c語言編寫所有的程序，然后，如果你必須用匯編碼重寫，確保把兩種執(zhí)行程序都保存，利用條件編譯，并且保持兩種程序的更新。美國國家標(biāo)準(zhǔn)委員會（ANSI）對C/C++的一個主要目標(biāo)是，提供一個可轉(zhuǎn)換的這種語言的執(zhí)行程序。理論上說，嚴(yán)格按照ANSIC編寫的程序，對于任何執(zhí)行ANSIC標(biāo)準(zhǔn)的編譯器都是可以轉(zhuǎn)換的。MicrosoftVisualC++提供了一個編譯器選項，可以用來檢查ANSI的兼容性。MicrosoftVisualC++為ANSIC提供了一些語言細(xì)節(jié)的補(bǔ)充，例如4字符常數(shù)和單行的注釋。使用MicrosoftC擴(kuò)充的程序可以轉(zhuǎn)換到MicrosoftVisualC++的任何其它執(zhí)行操作。因此，你可以使用4字符常數(shù)編寫程序，并且明白的程序可以轉(zhuǎn)換到任何16位或32位MicrosoftWindows平臺，或者是Macintosh平臺。編譯器經(jīng)常定位在目標(biāo)機(jī)器體系上的結(jié)構(gòu)，一些RISC機(jī)器，例如MIPSR4000，對排列尤為敏感。排列錯誤可能導(dǎo)致執(zhí)行期錯誤，或者可能悄悄地和顯著的影響你的程序。因此，避免封裝結(jié)構(gòu)，限制對硬件接口與兼容性地東西如文件格式和磁盤結(jié)構(gòu)的封裝。使用函數(shù)原型對于可轉(zhuǎn)換代碼來說命令，所有的函數(shù)都應(yīng)該有原型，并且這些原型應(yīng)該與實際聲名的函數(shù)完全匹配。遵循上面的方針，將會是你的代碼容易轉(zhuǎn)換，但是，如果你代碼是16位的Windows代碼，那你第一步要做的是使它能在Win32下正常工作，這需要你的資源作額外的改變。為Win32編寫的代碼可以在任何Windows版本下運行，有轉(zhuǎn)換庫時候還可以在Macintosh下運行?？赊D(zhuǎn)換的代碼應(yīng)該能在任意平臺上正確的編譯和執(zhí)行。當(dāng)然，如果你使用WindowsNT特有的API，那他們在Windows3.X下將不能工作，例如有些線程在WindowsNT下工作，卻不能在Windows3.11工作。這些函數(shù)區(qū)別應(yīng)該在你設(shè)計程序時候考慮到。Win16和Win32的主要區(qū)別是尋址長度，意思是現(xiàn)在32位的指針對于或遠(yuǎn)或近的關(guān)鍵詞不再支持了，也意味著分段存儲的代碼在Win32下會不能工作。除了指針，句柄和圖形調(diào)節(jié)也是32位，WINDOWS.H會解決一些大小不同的問題，但是仍然有一些工作需要作。關(guān)于把你的程序在Win32下運行的推薦的策略，是把你的代碼再編譯成32bit的,注意錯誤消息和警告。接著，把復(fù)雜的函數(shù)和匯編語言函數(shù)用子函數(shù)代替，然后，利用上面的技術(shù)使你的主程序正確的工作。最后用一個可轉(zhuǎn)換的版本代替所有的子函數(shù)。當(dāng)你已經(jīng)成功地把你的Windows程序從16bits轉(zhuǎn)換為