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

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