|
From: Bernard B. <be...@lp...> - 2006-11-14 17:04:36
|
I kept the entire message sent by Anthony and inserted the information I have that may help sorting out a few points, see below. Thank you again for this work! 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 occasionally >tedious. There are only a few difficult areas such as MIDI, printing, and >probably WASTE that will require significant attention. Memory management may also be simplified. In "BP2main.c" I had created a procedure "GiveSpace()" to replace "NewHandle()", in which we first check whether enough space is available in the heap, and if it not we temporarily use the stack of the system. This is indeed obsolete. >Adding support for >Navigation Services may also require more than trivial changes. Though it will be nice not to make it look as a low-grade Windows program! = ;-) Another point that needs to be decided is the naming of files. I used prefixes "-gr", "-da", "+sc" etc. so that BP recognizes different sorts of text files. In MacOS X, file extensions do the same and the file "creator/type" information is overrun by the extension. We might simply decide to go on with prefixes (they are nice if you put files in a list and sort them on names) and append the ".txt" extension to all text files. Or rather use a specific extension, such as "bp3", that will launch BP3 when double-clicking any of its files. > >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). A global variable called "Oms" is set to 1 if the program succeeds opening the OMS driver. When it is set to 0, the old buit-in (loaded as a resource) MIDI driver (designed by Joe Chung) is used. That old driver is documented in "MIDI Driver.doc". Using OMS versus the old driver is clear in files "MIDIdrivers.c" and "MIDIstuff.c". The procedures used by the old driver are all located at the bottom of "MIDIdrivers.c" The major difference between the two drivers is that the old one accepts time-stamped MIDI events and it manages to send them at the proper dates to the MIDI device. In OMS, the event is "played" as soon as you send it to the driver. Therefore we need a scheduling procedure for OMS. I adapted one by Tom Demeyer in 1997 (this is reminded in "BP2 history") and its code is in "Schedule.c". When using a different MIDI driver we will need to see whether it takes time-stamped events or it plays them immediately. The advantage of the second solution (i.e. the one of OMS) is that we keep control of the scheduling process and this may be useful when we need to flush the driver or suppress queued events beyond a certain limit of time, etc. It would be nice to keep it open for future development. In other words I suggest that we go on using our "schedule" procedure even if the MIDI driver allows for time-stamped data. >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 (=3F=3F). In "Script.c" the procedure ExecSriptLine() scans all the menus to try to match a line of the script with one of the items in a menu. It was a simple way of enhancing the script language automatically when a new menu item has been implemented. To do this we need to call GetMenu() and GetMenuItem(). >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. Actually, Date(char* line) returns the current date and time in "line". There are probably straightforward ways to do it in MacOS X. >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. Calling Moremasters() was supposed to provide "more space for handles". I believe it is obsolete. >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. This is hard stuff and we need to figure out the best way of implementing the scheduling procedure. >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=3F >Not interested in converting to MLTE as recommended by Apple. However, >WASTE may require significant modification (=3F) and newer, already = Carbonized >versions of WASTE are not free. I used WASTE for the only reason that it allows more than 32,000 signs in a text window. I do not think WASTE should be recycled (!) because I assume that in MacOS X you will have a variant of TextEdit that allows for more than 32,000 signs. In "BP2.h" there is a WASTE flag that sets up conditional compilation depending on whether we use WASTE or standard TextEdit. Let us set it to 0 and keep only the remaining code. >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. "WEArrays.c" (and all files starting with "WE") will disappear since we leave out the WASTE package. >CallUniversalProc > >Many instances of this in WASTE. Not sure what to replace them with. Ditto >(Maybe just simple function pointers since Carbon does not need to worry >about 68K code=3F=3F). > > >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. I was not aware of DisposeRoutineDescriptor() and indeed it is cleaner to release the memory used by the routine. Fortunately NewRoutineDescriptor() was only used in the handling of mouse events. >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. It wasn't used. >DIBadMount > >Again, could not find in the code. Not used. > > >-- 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. If you use a standard TextEdit procedure then most likely you will have a simple procedure for printing a text window... It may only be a bit more complicated with graphic windows. Although it is not of great interest to print BP graphics. :-( >PBControlSync >PBOpenSync >PBStatusSync > >Could not find calls to these functions either. Perhaps they are in the >OMSGLue or Metrowerks libraries =3F=3F PBControl() is used in MIDIdriver.c, not PBControlSync() Same with the other procedures. >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 (=3F). SystemTask() was a way to give a hand to other applications in multifinder (cooperative multitasking) >(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). They are used only once because there is a single procedure for opening/ creating all sorts of text files. They worked fine with Navigation Services. I always used Default Folder on MacOS 9 (and am still using it on MacOS X). >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). Bernard Bel <be...@lp...> Laboratoire Parole et Langage http://www.lpl.univ-aix.fr UMR 6057 CNRS - Universit=E9 de Provence / salle A464 29 av. R. Schuman 13621 Aix-en-Provence cedex 1 (France) Sec'y, Special Interest Group on Speech Prosody (SProSIG) http://www.lpl.univ-aix.fr/projects/sprosig/ Centre de Ressources pour la Description de l'Oral (CRDO) http://crdo.fr Bol Processor project http://sourceforge.net/projects/bolprocessor/ Blog perso : http://bernard-bel.over-blog.com/ |
