局域网聊天软件设计与实现-外文翻译

0外文原文Multiple-platformdevelopmentisahotissuetoday.DeveloperswanttobeabletosupportdiverseplatformssuchastheMicrosoftWindowsversion3.x,MicrosoftWindowsNT,andMicrosoftWindows95operatingsystems,andApple,Macintosh,UNIX,andRISC(reducedinstructionsetcomputer)machines.Untilrecently,developerswantingtobuildversionsoftheirapplicationformorethanoneplatformhadfewchoices:Maintainseparatecodebasesforeachplatform,writtentotheplatformsnativeapplicationprogramminginterface(API).WritetoavirtualAPIsuchasthoseprovidedbycross-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,oredgecode,youmayelecttoinclude),youllfindthatitwillcomeuponotherplatformseasilyaswell.MicrosoftVisualC+Cross-DevelopmentEditionforMacintosh(VisualC+forMac)providesasetofWindowsNTorWindows95hostedtoolsforrecompilingyourWindowscodefortheMotorola680x0andPowerPCprocessors,andaportabilitylibrarythat1implementsWindowsontheMacintosh.ThisallowsyoutodevelopGUIapplicationswithasinglesourcecodebase(writtentotheWin32API)andimplementitonMicrosoftWindowsorAppleMacintoshplatforms.Figure1,below,illustrateshowVisualC+forMacworks.Yoursourcecodeisedited,compiled,andlinkedonaWindowsNTorWindows95based(Intel)hostmachine.Thetoolscreate68000andPowerPCnativecodeandMacintoshresources.AnEthernet-basedorserialtransportlayer(TL)movestheresultingbinariestoaMacintoshtargetmachinerunningremotely.TheMacintoshapplicationisstartedontheMacintoshanddebuggedremotelyfromtheWindows-basedmachine.NowthatApplehastwodifferentMacintosharchitecturestocontendwith(Motorola680x0andPowerPC)portabilityisparticularlyimportant.Portingcaninvolveseveralsteps,dependingonwhetheryouareworkingwithold16-bitapplicationsorwithnew32-bitsources.Ingeneral,thestepstoaMacintoshportareasfollows:1.Makeyourapplicationmoreportablebyfollowingsomegeneralportabilityguidelines.Thiswillhelpinsurenotonlyportabilitytothe680x0-basedMacintoshmachines,butalsotothenewer,morepowerfulPowerPCmachinesthatarebasedonaRISCchip.2.PortyourapplicationfromWindows16-bitcodeto32-bitcode.Thismaybethemostcomplexandtime-consumingpartofthejob.3.SegregatethosepartsofyourapplicationthatareuniquetoWindowsfromsimilarimplementationsthatarespecifictotheMacintosh.Thismayinvolveusingconditionalcompilationoritmayinvolvechangingthesourcetreeforyourproject.4.PortyourWin32APIcodetotheMacintoshbyusingtheportabilitylibraryfortheMacintoshandVisualC+forcompiling,linking,anddebugging.5.UsetheMicrosoftFoundationClassLibrary(MFC)version4.0toimplementnewfunctionalitysuchasOLE2.0containers,servers,andclientsordatabasesupport2usingopendatabaseconnectivity(ODBC).CodewrittenusingMFCishighlyportabletotheMacintosh.6.WriteMacintosh-specificcodetotakeadvantageofuniqueMacintoshfeatures,suchasAppleEventsorPublishandSubscribe.ThechiefchallengeamongthefamiliesofWindowsoperatingsystemsisthebreakfrom16bits(Windows3.11andWindowsforWorkgroups3.11operatingsystemwithintegratednetworking)to32bits(WindowsNTandWindows95).Ingeneral,16-bitand32-bitcodebasesaresomewhatincompatible,unlesstheyarewrittenusingMFC.Developershavethechoiceofbranchingtheirsourcesintotwotrees,ormigratingeverythingto32bits.OncetheWin32choicehasbeenmade,howarelegacyplatformstoberun(thatis,machinesstillrunningWindows3.11)?TheobviouschoiceistousetheWin32sAPIlibraries,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.3YoullhavetodecideearlyonwhethertowritetothenativeAPI(Win32)ortoMFC.IngeneralyoullfindMFCapplicationswillportmorequicklythanWin32applications.Thisisbecauseoneoftheintrinsicbenefitsofanapplicationframeworkisanabstractionofthecodeawayfromthenativeoperatingsystemtosomeextent.Thisabstractionislikeaninsurancepolicyforyou.However,developersfrequentlyhavequestionsaboutMFC,suchas:WhatifIneedanoperatingsystemservicethatisntpartoftheframework?CalltheWin32APIdirectly.MFCneverpreventsyoufromcallinganyfunctionintheWin32APIdirectly.Justprecedeyourfunctioncallwiththeglobalscopeoperator(:).IdontknowC+.CanIstilluseMFC?Sure.MFCisbasedonC+,butyoucanmixCandC+codeseamlessly.HowcanIgetstartedusingMFC?Startbytakingsomeclassesand/orreadingsomebooks.VisualC+shipswithafinetutorialonMFC(Scribble).Then,checkouttheMFCMigrationKit(availableonCompuServeor,foramodestshippingandhandlingfee,fromMicrosoft).ItwillhelpyoumigrateyourC-basedapplicationcodetoMFCandC+.Allportingwillbeeasierifyoubegintodaywritingmoreportableprograms.Followingsomebasicportabilityguidelineswillmakeyourcodelessplatform-specific.Neverassumeanything.Particularly,dontmakeassumptionsaboutthesizesoftypes,thestateofthemachineatanytime,byteordering,oralignment.Dontassumethesizeofprimitivetypes,becausethesehavedifferentsizesondifferentprocessors.Forexample,anintistwobytesinWin16andfourbytesinWin32.Atallcosts,avoidcodethatreliesonthesizeofatype.Usesizeof()instead.Todeterminetheoffsetofafieldinastructure,usetheoffsetof()macro.Donttrytocomputethismanually.Useprogrammaticinterfacestoaccessallsystemorhiddenobjects,forexample,thestackorheap.ParsingdatatypestoextractindividualbytesorevenbitscancauseproblemswhenportingfromWindowstotheMacintoshunlessyouarecarefultowritecodethatdoesnt4assumeanyparticularbyteorder.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.Limit5packingtohardwareinterfacesandtocompatibilityissuessuchasfileformatsandon-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,yourereadytoembarkonportingittotheMacintosh.Becausesignificantdifferencesexistbetweenthetwoplatforms,thistaskcanappeardaunting.Beforeyoucanbegintoportyourapplication,youneedtobetterunderstandthesedifferences.TheMacintoshisdifferentiatedfromWindowsinthreegeneralareas:6ProgrammingmodeldifferencesProcessordifferencesUserinterface(UI)differencesTheseareasofdifferencearedescribedbelow.PortingissuesthataccompanythesedifferencesarediscussedinthesectiontitledPortingfromWin32totheMacintosh.TheWindowsandMacintoshAPIsarecompletelydifferent.Forexample:Theeventmodelsaredifferent.InWindows,youdispatchmessagestoWindowProcs.YouuseDefWindowProctohandlemessagesinwhichyourenotspecificallyinterested.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(220bytes)ofmemorythatusedanunsigned16-bitsegmentregisterandanunsigned16-bitoffset.ThisoriginalIntelschemehasbeenextendedtoallowmuch7largeramountsofmemorytobeaddressed,butmostexistingIntel-basedprogrammingreliesonseparatingcodeanddatainto64Ksegments.AlthoughallIntelx86processorssincethe80386haveused32-bitaddressing,forcompatibilityreasonsMicrosoftWindows3.xisactuallya16-bitapplication,andallMicrosoftWindows-basedapplicationshadtobewrittenas16-bitapplications.Thatmeant,forexample,thatmostpointersandhandleswere16bitswide.WiththeadventofMicrosoftWindowsNT,whichisatrue32-bitoperatingsystem,allnativeapplicationsare32-bitapplications,whichmeansthatpointersandhandlesare32bitswide.BecauseWindowsNTuseslinearaddressing,programscanshareupto4gigabytesofmemory.Incontrast,theMotorola68000andPowerPCprocessorhavealwaysprovidedtheabilitytoaddressaflat32-bitmemoryspace.Intheory,aflatmemoryspaceofthiskindsimplifiesmemoryaddressing.Inpractice,because4-byteaddressesaretoolargetouseallthetime,Macintoshcodeisgenerallydividedintosegmentsnolargerthan32K.MicrosoftWindowsandWindowsNTrunonlyonso-calledlittle-endianmachinesprocessorsthatplacetheleastsignificantbytefirstandthemostsignificantbytelast.Incontrast,theMotorola680x0andPowerPC(aso-calledbig-endianarchitecture)placethemostsignificantbytefirst,followedbythenextmostsignificantbyte,andsoon,withtheleastsignificantbytelast.Compilersnormallyhandlealldetailsofbyteorderingforyourapplicationprogram.Nevertheless,well-writtenportablecodeshouldneverdependontheorderofbytes.MicrosoftWindowsandtheMacintoshpresentquitedifferentuserinterfacesinmanykeyareas,includingmenus,filenames,andmultiple-documentinterface(MDI)applications.OnlyonemenubarexistsontheMacintosh,anditisalwaysinthesameplace,regardlessofthenumberorarrangementofwindowsonthescreen.Theactivewindowcontainsthemenu,whichdynamicallychangesasnecessarywhendifferentwindowsaremadeactive.Windows,ontheotherhand,giveseachtop-levelwindowitsownmenu.Inaddition,underMDI,eachchildwindowcanalsohaveitsownmenu.MDIisdiscussedingreaterdetailbelow.8MacintoshapplicationsgenerallyhaveanApplemenu(theleftmostmenu)thatcontainsalltheinstalledDeskAccessoriesandusuallycontainsanAboutentryfortheapplication.UnderSystem7,theextremerightsideoftheMacintoshmenucontainsaniconforApplesBalloonHelpandtheApplicationmenuforswitchingbetweenapplications.Windows-basedapplicationsalwayshaveaSystemmenuattheupper-leftcorneroftheirtop-levelwindow.Thismenucontainssystem-levelfunctionsforsizing,moving,andclosingthewindow,aswellasanitemthatcallstheTaskManagerforswitchingapplications.Generally,Windows-basedapplicationscontainkeyboardequivalentsintheirmenus.Theseareunderlinedlettersineachmenuentrythattheusercanselectwiththekeyboardinlieuofthemouse.This,however,isconventionratherthanrequirement.AlthoughsomeMacintoshapplicationshavetheseequivalents,mostdonot.FilenamesandpathnamesrepresentoneofthemostfundamentaldifferencesbetweenWindowsandtheMacintosh,aswellasperhapstheonemostdifficulttodealwith.Manyprogrammersreportdealingwithfilenamesastheareaofportinginwhichthemosttimeandenergyisspent.YourWindows-basedapplicationprobablyalreadyhandles(andexpects)filenamessuchasC:ACCTGDATASEPT93.DAT.ApplicationsfortheMS-DOSandWindowsoperatingsystemsareboundbythetraditional8.3filenameformat.Macintoshapplications,ontheotherhand,canhandlefilenamessuchasSeptember,1993AccountingData.MDIwindowsallowformultiplechildwindowswithinthebordersofatop-levelwindow(theMDIframe).ManyWindows-basedapplications,suchastheMicrosoftWordwordprocessorforWindows,areMDIapplications.CharacteristicofMDIapplicationsareclippedchildwindowsthatcanbeminimizedtoaniconwithintheMDIframe.EachMDIchildwindowcanalsohaveitsownmenu.TheMacintoshdoesnotsupportMDIwindows.Anapplicationcanhavemultiplewindowsopen;thosewindows,however,cannotbemadeintoicons,andtheyshareacommonmenu.Dependingontheapplication,thisdifferencemaynecessitatesignificantredesignforaMacintoshport.9Finallyyoucankeepdoingwhatyouknowhowtodobest,writingtotheWindowsAPI,andstillallowforversionsofyourapplicationthatrunonotherplatforms.VisualC+nowgivesyouspecialversionsthatallowyoutodothis.Keepingyourcodeportable,thinkingaboutportabilityallthetime,andusingtherighttoolswillhelpyoumakethemultipleplatformjumpaseffortlessaspossible.10中文翻译在今天，多平台的开发是一个热门课题。开发人员希望能够支持不同的平台，例如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上运行。这就使你可以开发单一的源代码（针对Win32API的），并使它可以运行在MicrosoftWindows或AppleMacintosh平台上。下面的第一章，说明了VisualC+是怎样针对Macintosh工作的。你的源代码在WindowsNT或Windows95上面编写，编译，连接。这些工具将产生68000和PowerPC的自然代码，以及Macintosh资源。一个基于以太网或串行连接的传输层会把目标代码移动远端的目的Macintosh机器上运行。Macintosh应用程序在Macintosh平台上运行，并且在远端的Windows机器上面调试。现在，Apple公司有两个不同的Macintosh结构来竞争，可转换性尤其重要。转换的几个步骤取决于你处理的程序是16位还是32位。一般来说，一个Macintosh转换包括以下几步：1遵循一些转换性的方针以使你的程序更容易转换，这将不仅有助于保证基于680x0的Macintosh机器的转换,也有助于更新，基于RISC芯片的powerfulPowerPC机器的转换。2把你的Windows应用程序从16位代码转换成32位代码，这也许是最复杂和耗时间的工作。3把你独特的Windows应用程序分割，从熟悉的执行方式到Macintosh。这将涉及到使用条件编译或者设计到你工程的资源树。4利用Macintosh转换库把Win32API代码转换成Macintosh代码，并利用VisualC+来编译、连接、调试。115使用微软基础类库MFC4.0实现一些新功能，例如OLE2.0,服务器，客户端或者利用ODBC的数据库支持。使用MFC编写的代码对Macintosh有很高的可转换性。6编写专门的Macintosh代码，可以利用Macintosh的独特特点，利用Apple事件或出版和定购。开发人员通过VisualC+的特殊的多平台编辑器，可以充分利