|
From: Bernard B. <be...@lp...> - 2006-11-13 23:40:47
|
Dear Anthony, dear colleagues, I have replies to allmost all these points. I'll try to find time to send them to-morrow. Today (yesterday?) I was too busy to answer your very kind message. With warm regards Bernard Bel >Looking through the Carbon Report from Apple, I have begun to check how BP2 >uses the Mac Toolbox calls that the report indicates need to be changed or >removed. Below are my first thoughts on how easy or difficult the changes >for each Toolbox call will be. > >SUMMARY: a lot of the recoding should be fairly trivial if occassionally >tedious. There are only a few difficult areas such as MIDI, printing, and >probably WASTE that will require significant attention. Adding support for >Navigation Services may also require more than trivial changes. > > >Anthony Kozar >anthonykozar AT sbcglobal DOT net > > >-------------------------------- >MODIFIED AND UNRECOMMENDED CALLS > >GetProcessInformation > >This is only used in Inits.c and WEMouse.c and should be compatible without >any changes. > > >PBReadSync >PBWriteAsync >PBWriteSync > >I believe that these device manager calls are only used by BP2's direct >serial port MIDI driver. This driver is unnecessary in the Carbon port and >can be removed. Related code for choosing and loading the driver can be >#ifdefed out. >(Search for "PBRead" and "PBWrite" in code). > > >GetMenu > >I don't think the changed behavior of GetMenu will affect BP2 at all unless >it means that the GetMenu call in Script.c will be a memory leak (??). > > >GetIntlResource > >Used in Date() of Misc.c. Not sure if the change in behavior on OS X (not >returning a resource handle) is an issue or not. > > >MoreMasters > >Only called in Inits() of Inits.c. Should be #ifdefed to be >MoreMasterPointers for Carbon build. Can be removed if we ever do an OS >X-only build. > > >InsXTime > >Called in InstallTMTask() of Schedule.c. Should be #ifdefed to use >InstallXTimeTask for Carbon build. TDesc() and TDesc68K() may need to be >changed as well. > > >GetControlMaximum >GetControlMinimum >GetControlTitle >GetControlValue >SetControlMaximum >SetControlTitle >SetControlValue > >Apple recommends replacing all of these calls with Carbon versions using >32-bit ints and CFStrings for values. This would require lots of careful >checking to make sure that all integer variables manipulating returned >values are wide enough and would require some rewriting for different string >types. I think these changes should be put off until they become more >compelling. > > >HiliteControl > >Can be #ifdefed to ActivateControl or DeactivateControl, but there are many >instances to change -- would be messy to read in many cases. I would either >put off this change or use a function/macro call to maintain readability. > > >NewControl > >Apple recommends replacing each call with a Carbon call for a specific type >of control. I would put off these changes until after the first Carbon >build of BP2 is complete. > > >TrackControl > >Eight instances of this call in Interface1.c and Interface2.c. May want to >#ifdef them to HandleControlClick as recommended by Apple. > > >--Window Manager calls-- > >(Need to take a closer look at these). > > >--TextEdit calls-- > >Most of these seem to be conditionally included in BP2 based on WASTE usage? >Not interested in converting to MLTE as recommended by Apple. However, >WASTE may require significant modification (?) and newer, already Carbonized >versions of WASTE are not free. > > >UNSUPPORTED APIs > >FSDelete > >Used in Inits.c for invisible registration/y2k files, in MIDIfiles.c for >deleting aborted file writes, and ProduceItems.c and SaveLoads3.c for >deleting temp files in the BP2 folder. Can #ifdef out the code in Inits.c >and convert all other uses to FSpDelete (with a FSMakeFSSpec call first). > > >-- Low Memory accessors -- > >Must replace all of these as per the suggestions in the Carbon report. > > >ApplicationZone >MaxApplZone >SetZone > >I think we can just #ifdef out all of these calls in the Carbon build. Grow >Zone support can also probably be #ifdefed out. > > >InlineGetHandleSize > >These calls are in WEArrays.c. Must be replaced by something. > > >CallUniversalProc > >Many instances of this in WASTE. Not sure what to replace them with. >(Maybe just simple function pointers since Carbon does not need to worry >about 68K code??). > > >NewRoutineDescriptor >DisposeRoutineDescriptor > >All calls to NewRoutineDescriptor should be replaced by specific UPP creator >calls. Could not find calls to DisposeRoutineDescriptor, so we may need to >add explicit calls to specific UPP disposal routines for each creator call. > > >GetToolTrapAddress > >Could not find a call to this in the main code. If it does turn up, I >assume that we can just #ifdef out. > > >DIBadMount > >Again, could not find in the code. > > >-- Printing Manager calls -- > >>From the report: "The original Printing Manager defined in Printing.h is not >supported in Carbon. Carbon applications must use the Carbon Printing >Manager." This is a bummer :( I have no idea yet how much work this will >be. All seems to be confined to Print.c though. Perhaps Carbon printing >routines can go in a new file if the code will be significantly different. > > >PBControlSync >PBOpenSync >PBStatusSync > >Could not find calls to these functions either. Perhaps they are in the >OMSGLue or Metrowerks libraries ?? > > >InitGraf >InitDialogs >InitMenus >InitWindows >InitFonts >TEInit > >Just #ifdef these out for Carbon build. > > >OpenDeskAcc >SystemClick >SystemTask (5 instances) > >Just #ifdef out these parts of event handling code for Carbon builds (?). > >(No plans to use Carbon Event Manager anytime soon since that will likely >require a large rewrite of event handling code). > > >CheckItem --> CheckMenuItem >CountMItems --> CountMenuItems >DisableItem --> DisableMenuItem >EnableItem --> EnableMenuItem > >The many occurences of each of these calls must be replaced as indicated. > > >CloseDialog --> DisposeDialog >CloseWindow --> DisposeWindow > >More replacement calls. We should make sure that we are not allocating our >own memory for these dialogs and windows. > > >GetScrap >PutScrap >ZeroScrap > >Many calls in WASTE and some in BP. See Carbon report for recommendations >on replacing these functions. > > >StandardGetFile >StandardPutFile > >These are amazingly only used in one place each. They are simple wrapper >functions which could be conditionalized to include support for Navigation >Services in both Carbon and non-Carbon builds. However, the many places >that call the wrappers may need to be modified significantly. (And I have >shied away from Nav Services in the past because it is overly complicated). > > >InvalRect --> InvalWindowRect >ValidRect --> ValidWindowRect > >These should be easy to replace -- they each take a window ptr as an >additional parameter. > > >IUDatePString --> DateString >IUTimeString --> TimeString > >IUDatePString not found; only one instance of IUTimeString in Date() of >Misc.c. > > >CharByte --> CharacterByteType >CharType --> CharacterType >FindWord --> FindWordBreaks > >These are only part of WASTE for pre-System 7.5. We can exclude these calls >by defining SystemSevenFiveOrLater. (We will not follow Apple's >recommendation at this time to use Unicode instead, since that would be a >complete rewrite of the text editing code). > > >c2pstr > >This would be easy to replace ourselves. (Apple recommends using >CopyCStringToPascal which might be appropriate in many cases as pStrCopy is >immediately called after c2pstr anyways -- in other cases though, a >non-copying replacement would be better). > > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >bolprocessor-devel mailing list >bol...@li... >https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel |
