bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Notes on Carbon porting

[Anthony K. <ant...@sb...>]

Bernard Bel wrote on 11/21/06 4:55 AM:

>> but it does try to create files in its own folder.
> 
> It is the case with the default settings file.  This one should indeed be
> moved to the proper location.
> Another file that was created in the same folder is an invisible file
> used for registering, but I believe you have already removed that part.

Yes, I have already disabled the registration code.  I hope to release a
new 2.9.5 final version before beginning the Carbon port so that we have a
final "reference version" on OS 9 and so that anyone still using the program
can get these updates.

> The general philosophy was that whenever you open a grammar file the
> machine remembers the location of the folder in which that grammar file
> was located, and it will try to load all related files (settings,
> alphabet, orchestra etc.) from that same folder. It will also propose the
> same folder, by default, for saving files of the same "project".

Hmmm ... this made me realize that it will be a bit more work to allow
different combinations of prefixes/suffixes for filenames.  The file parsers
will have to be updated to understand the new formats.  And if we allow the
user the freedom to use their own conventions, it will be desirable to have
some sort of syntax for marking the filenames as "grammar", "alphabet", etc.

Allowing full or relative pathnames as references to other files would also
make sense on most platforms.
> At one point I was tempted to define a specific "project file" that would
> contain the links/paths to grammar, data etc. but I found it easier to
> maintain the explicit links in grammar and data files.

I've thought about this ... it could always be done later.  One thing to
consider is that once BP is split into libraries, people will be able to
write new GUIs for the engine to work in whatever way seems logical to them.

> It gets a bit more complicating when running scripts: every "open file"
> script instruction contains the ID of the folder in which the file was
> located, but this ID will change if files are moved to another disk. When
> it does not reach the file at the specific location, it tries other
> strategies such as the "current folder", or the last folder in which
> another file of the same type was opened, etc. I am not sure these
> strategies will still work in MacOS X, but redefining them should be done
> only in the next phase (after the release of the beta version) because
> scripting is not a vital feature of BP.

I think the current stategy will still work, but a better way (on OS X or OS
9) might be to use the Alias Manager since under many circumstances it can
track files that have been moved or renamed.

> Since we have larger monitors now they could be flashed on any
> relocatable window.  At least we do it with the first version of the
> port.  They could even disappear because the program is too fast now to
> enable reading those messages, and we still can use the option "Display
> last messages" to trace the recent actions.

OK.

> The option was already there: if you push the 'option' ("alt") key when
> typing "command-O" you get access to all text files whatever their
> prefix/file type.

Oops!  I forgot about that :)  No problem then.

>> As for OS X, I think we should adopt some file extension suffixes as
>> "standard" for each of BP's file types, and continue to set file and creator
>> types when saving files from BP (this is acceptable in OS X if frowned upon
>> by Apple).  When opening a file, a popup menu could be provided for choosing
>> the type. [...]

> This is a nice way to do it. Keeping file creator/type is also a good
> strategy even though we know that it won't make any sense when porting to
> Linux and other systems.

>> The user can then decide how they wish to name files (using prefixes,
>> suffixes, or any scheme of their own) and it will still be possible to open
>> them with BP.

> This option is fine because at this point we cannot decide what is more
> practical for users.  It partly depends on the availability of navigation
> services.

> I agree that the priority is to run the program in MacOSX, even if it is
> at the cost of limiting window sizes to 32,000 characters in the first
> version.  We never see grammars of that size. [...]

>> and I think we could release a version of Carbon BP without printing if it
>> will take significantly longer to add.

> I agree totally.
> At a later stage some users might even wish to use an external editor for
> all Bol Processor files.

Good.  I am glad that we agree on all of these core issues.

Anthony

Re: [bp-dev] Notes on Carbon porting

[Bernard B. <be...@lp...>]

Anthony Kozar <ant...@sb...> wrote:

>1.  Make sure all code is PPC-native

Probably it is because I remember carefully following the guidelines when
I ported from 6800x to PPC. In those days there were a few crashing bugs
and I checked the PPC compatibility again and again hoping that it would
solve them. (Bugs were elsewhere as expected...)

>    It is easiest to do the porting on OS 9 so that changes can be made
>    slowly and the application will still compile and run.  (I also want
>    to conditionalize all changes so that a non-Carbon build can be
>    maintained for now -- that way we will not leave behind anyone who
>    is still using BP2 on OS 7-9 until it is absolutely necessary). Once
>    the application can be built linking only to CarbonLib, then we can
>    begin testing on OS X.

It is a good strategy.

>    WindowPtr, GrafPtr, and DialogPtr can no longer be used interchangably
>    in Carbon and every occurrence of code that assumes they can be must
>    instead call a function to convert between pointer types.

Normally I had done it (when chasing interface bugs) but it needs to be
checked again.

>5.  Remove direct access to Low-Memory Globals
>
>    The Carbon Report did not find any instances of this.  Hopefully, it is
>    correct.

Right.

>I don't think BP2 writes to its
>    resource fork

It does not.

> but it does try to create files in its own folder.

It is the case with the default settings file.  This one should indeed be
moved to the proper location.
Another file that was created in the same folder is an invisible file
used for registering, but I believe you have already removed that part.

The general philosophy was that whenever you open a grammar file the
machine remembers the location of the folder in which that grammar file
was located, and it will try to load all related files (settings,
alphabet, orchestra etc.) from that same folder. It will also propose the
same folder, by default, for saving files of the same "project".

At one point I was tempted to define a specific "project file" that would
contain the links/paths to grammar, data etc. but I found it easier to
maintain the explicit links in grammar and data files.

It gets a bit more complicating when running scripts: every "open file"
script instruction contains the ID of the folder in which the file was
located, but this ID will change if files are moved to another disk. When
it does not reach the file at the specific location, it tries other
strategies such as the "current folder", or the last folder in which
another file of the same type was opened, etc. I am not sure these
strategies will still work in MacOS X, but redefining them should be done
only in the next phase (after the release of the beta version) because
scripting is not a vital feature of BP.

>9.  BP2's "message" windows at the bottom of the screen will have to be
>    relocated when the OS X Dock is in their way=3F

Since we have larger monitors now they could be flashed on any
relocatable window.  At least we do it with the first version of the
port.  They could even disappear because the program is too fast now to
enable reading those messages, and we still can use the option "Display
last messages" to trace the recent actions.

>> 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.
>
>Yes, this will likely need to be redone as allocating system memory is no
>longer an option.  (I think it will compile and run OK under Carbon, it is
>just pointless).

Then simply use "Newhandle()" in replacement of "GiveSpace()"

>This is an issue that I may even address for the final pre-Carbon release
>(2.9.5 final).  As it is, the prefix files will not get the correct file
>types on OS 9 or OS X when checked out from CVS.  And BP2 will not open a
>file with type 'TEXT' as a grammar, etc.  I think an immediate improvement
>would be to allow opening any file with type 'TEXT' on OS 9.

The option was already there: if you push the 'option' ("alt") key when
typing "command-O" you get access to all text files whatever their
prefix/file type.

>As for OS X, I think we should adopt some file extension suffixes as
>"standard" for each of BP's file types, and continue to set file and =
creator
>types when saving files from BP (this is acceptable in OS X if frowned upon
>by Apple).  When opening a file, a popup menu could be provided for =
choosing
>the type.  For example, when opening a grammar, the choices would be "BP
>grammar", "Any text file", "Any file".  The filter for "BP grammar" could
>include any file with the correct OS 9 type, the prefix "-gr", or the new
>suffix (maybe .bpgr =3F).

This is a nice way to do it. Keeping file creator/type is also a good
strategy even though we know that it won't make any sense when porting to
Linux and other systems.

>The user can then decide how they wish to name files (using prefixes,
>suffixes, or any scheme of their own) and it will still be possible to open
>them with BP.

This option is fine because at this point we cannot decide what is more
practical for users.  It partly depends on the availability of navigation
services.

>What I would like to do is investigate three different options for the =
first
>round of porting: 1)  carbonizing WASTE, 2)  using MLTE if it is simple
>enough to wrap the code so that we can stick with ASCII text throughout the
>rest of BP, or 3)  "downgrading" to TextEdit temporarily until the text
>editing can be completely reworked.
>
>I would give preference to either 1 or 2 and my choice would depend on =
which
>option is simpler.  Option 3 would be a last resort since limiting text
>files to 32K is very annoying.
>
>My goal is to get to a mostly functional Carbon port of BP2 as fast as
>possible.  This means that in the first round of changes, I will be =
focusing
>only on those parts of the code that HAVE to be changed and I would like to
>give priority to solutions that are simpler to code when there is more than
>one choice.  Certainly, once we have a version of BP that can actually run
>on OS X, we can go back and implement more ideal solutions for the long
>term.

I agree that the priority is to run the program in MacOSX, even if it is
at the cost of limiting window sizes to 32,000 characters in the first
version.  We never see grammars of that size.  The only cases would be
the display of very large BP2 scores or the tracing of large Csound
scores, both of which are quite useless.  Csound scores are directly
stored as text files with no limit on the length, and they can later be
opened with a more suitable text editor.

Unicode sounds great but in my opinion it should be targetted in the next
phase, after the porting.

>MLTE is supposed to make it very easy to print text windows as well.  I
>honestly do not consider printing to be essential to the first round port
>though.  Since all of BP's data files are plain text, they can be opened in
>any text editor (such as BBEdit) and printed from there.  Therefore, I will
>likely focus on getting the rest of BP2 ported before working on printing
>and I think we could release a version of Carbon BP without printing if it
>will take significantly longer to add.

I agree totally.
At a later stage some users might even wish to use an external editor for
all Bol Processor files.

Bernard Bel <be...@up...>
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/

Re: [bp-dev] Notes on Carbon porting

[Anthony K. <ant...@sb...>]

I have been spending more time looking into the porting process and thinking
about solutions.  In addition to the replacement of various Toolbox calls as
already discussed, there are a few other steps that need to be taken.  These
are described in Apple's book "Carbon Porting Guide" available at

<http://developer.apple.com/documentation/Carbon/Conceptual/carbon_porting_g
uide/index.html>

Here is an overview as it pertains to BP2:

1.  Make sure all code is PPC-native

    This is simple since there are no custom definition procedures.  The
    built-in MIDI driver will have to go but that was already true for
    other reasons as well.

2.  Update to recent Universal Interfaces (and CodeWarrior 8)

    This will require some work as BP2 currently does not compile with
    CW8 (but does with Cwpro4).  Many of the errors seem to be because
    of name conflicts with newer Toolbox calls and greater strictness
    in the compiler.  Hopefully only 4-8 hours of work to finish.

Targeting OS 9 first (this applies to steps 3-6 below)

    It is easiest to do the porting on OS 9 so that changes can be made
    slowly and the application will still compile and run.  (I also want
    to conditionalize all changes so that a non-Carbon build can be
    maintained for now -- that way we will not leave behind anyone who
    is still using BP2 on OS 7-9 until it is absolutely necessary). Once
    the application can be built linking only to CarbonLib, then we can
    begin testing on OS X.

3.  Eliminate direct access to opaque structures

    Many common toolbox structs are opaque in Carbon and their members
    must be accessed via accessor functions.  This includes WindowRecords,
    DialogRecords, GrafPorts, ControlRecords, QuickDraw globals, etc.
    I have not audited BP2 in this regard, and I expect a significant
    amount of work (maybe as much as "simple replacements" for obsolete
    Toolbox calls).  Fortunately, Apple has made it easy to do this one
    file at a time and keep the application working (on OS 9).

4.  Use "casting functions" for converting between certain pointer types.

    WindowPtr, GrafPtr, and DialogPtr can no longer be used interchangably
    in Carbon and every occurrence of code that assumes they can be must
    instead call a function to convert between pointer types.  This will be
    quite a bit of work too but can be done at the same time as step #4.

5.  Remove direct access to Low-Memory Globals

    The Carbon Report did not find any instances of this.  Hopefully, it is
    correct.

6.  Update modified or obsolete functions

    I have already described this part in detail.  I have found that many
    of the functions will take at least one extra parameter so it will be
    marginally more difficult than an auotmatic search and replace.
    Adopting replacements for entire toolboxes (Navigation Services,
    Carbon Printing, and possibly MLTE) will take the most time.

7.  Adding a 'plst' resource and conditionalizing Quit menu item

    These are required for a Carbon app to run on OS X (the Quit menu item
    is in a different location).  Both are trivial.

8.  Making sure we don't write files to places we shouldn't

    We cannot assume that the application resource fork or the application
    directory are writable on OS X.  I don't think BP2 writes to its
    resource fork, but it does try to create files in its own folder.
    Should not be too hard to add some OS X-only code to write these files
    somewhere else instead (such as the user's preferences folder).

9.  BP2's "message" windows at the bottom of the screen will have to be
    relocated when the OS X Dock is in their way?

10. Apple has lots of recommendations for optimizing Carbon applications,
    many of which may apply to BP.  Some of these can be tackled in the
    "second round" of changes after we have a working Carbon build.


More comments in response to Bernard's previous comments are below! :)


Bernard Bel wrote on 11/14/06 12:01 PM:

> 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.

Yes, this will likely need to be redone as allocating system memory is no
longer an option.  (I think it will compile and run OK under Carbon, it is
just pointless).

> 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.

This is an issue that I may even address for the final pre-Carbon release
(2.9.5 final).  As it is, the prefix files will not get the correct file
types on OS 9 or OS X when checked out from CVS.  And BP2 will not open a
file with type 'TEXT' as a grammar, etc.  I think an immediate improvement
would be to allow opening any file with type 'TEXT' on OS 9.

As for OS X, I think we should adopt some file extension suffixes as
"standard" for each of BP's file types, and continue to set file and creator
types when saving files from BP (this is acceptable in OS X if frowned upon
by Apple).  When opening a file, a popup menu could be provided for choosing
the type.  For example, when opening a grammar, the choices would be "BP
grammar", "Any text file", "Any file".  The filter for "BP grammar" could
include any file with the correct OS 9 type, the prefix "-gr", or the new
suffix (maybe .bpgr ?).

The user can then decide how they wish to name files (using prefixes,
suffixes, or any scheme of their own) and it will still be possible to open
them with BP.

> 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.

I think MidiShare and CoreMidi (the two drivers I have in mind for the OS X
port) will probably function like OMS, but I have not looked at them yet.

>> 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 (??).
> 
> 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().

Yes, I will just need to check whether we have to deallocate the structures
returned by GetMenu.

>> 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.

I think that the suggestion above will work as a first attempt.

>> --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.
> 
> 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.

Yes, MLTE is a replacement for TextEdit allowing > 32K of text.  It runs on
OS 8.6 and greater.  The chief difficulty with it however is that it is
based on Unicode for storing text.  I do not want to completely rewrite BP2
to support Unicode throughout just to get a Carbon port up and running.  In
addition, we need to plan for the future port to Linux where Unicode may be
problematic.

What I would like to do is investigate three different options for the first
round of porting: 1)  carbonizing WASTE, 2)  using MLTE if it is simple
enough to wrap the code so that we can stick with ASCII text throughout the
rest of BP, or 3)  "downgrading" to TextEdit temporarily until the text
editing can be completely reworked.

I would give preference to either 1 or 2 and my choice would depend on which
option is simpler.  Option 3 would be a last resort since limiting text
files to 32K is very annoying.

My goal is to get to a mostly functional Carbon port of BP2 as fast as
possible.  This means that in the first round of changes, I will be focusing
only on those parts of the code that HAVE to be changed and I would like to
give priority to solutions that are simpler to code when there is more than
one choice.  Certainly, once we have a version of BP that can actually run
on OS X, we can go back and implement more ideal solutions for the long
term.

> 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.

It is very handy that compatibility with TextEdit was maintained in the code
and this would be a useful route for a short term solution if it is both too
complicated to carbonize WASTE and too much of a rewrite to immediately add
MLTE support.

>> 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. :-(

MLTE is supposed to make it very easy to print text windows as well.  I
honestly do not consider printing to be essential to the first round port
though.  Since all of BP's data files are plain text, they can be opened in
any text editor (such as BBEdit) and printed from there.  Therefore, I will
likely focus on getting the rest of BP2 ported before working on printing
and I think we could release a version of Carbon BP without printing if it
will take significantly longer to add.

Anthony Kozar
anthonykozar AT sbcglobal DOT net

Re: [bp-dev] Notes on Carbon porting

[Bernard B. <be...@lp...>]

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/

Re: [bp-dev] Notes on Carbon porting

[Bernard B. <be...@lp...>]

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

Re: [bp-dev] Antw: Welcome to new subscribers

[Anthony K. <ant...@sb...>]

Dear Rainer,

I am so glad that there is interest in the project and want you and any
other observers to feel free to offer suggestions at any time.  Progress ha=
s
been rather slow to date, but that may change soon.

We will keep posting to this list as new developments transpire.

Take care,=20

Anthony

Rainer Sch=FCtz wrote on 11/13/06 1:39 PM:

> Dear Anthony,
>=20
> Thank you for the welcome. Bernard told me that you were the main force
> behind the port. Thank you very much for your initiative and work - this
> is a lovely thing to happen.
>=20
> While I would love to help - I am completely unqualified for this job
> (and these months I have no time at all besides my dayjob). As you say,
> I am here to see with big sympathy how things are developing. I hope you
> don't mind.

[bp-dev] Antw: Welcome to new subscribers

[<rai...@ku...>]

Dear Anthony,

Thank you for the welcome. Bernard told me that you were the main force
behind the port. Thank you very much for your initiative and work - this
is a lovely thing to happen.

While I would love to help - I am completely unqualified for this job
(and these months I have no time at all besides my dayjob). As you say,
I am here to see with big sympathy how things are developing. I hope you
don't mind.

Best
Rainer Schuetz
Graz
-- 

http://www.bagong.de

>>> Anthony Kozar <ant...@sb...> schrieb am Montag, 13.
November 2006
um 18:39 in Nachricht <C17E17FC.1930C%ant...@sb...>:
> I've noticed that we have some new subcribers to bolprocessor-devel
and I
> wanted to say "Welcome".
> 
> I'm interested to know whether you are just here to "keep an eye on
things"
> or if any of you would like to help with BP development.  We
certainly could
> use more people working on the project!!
> 
> As you can see from the other message that I just sent, I am again
looking
> at beginning the Carbon porting effort.  This would result in a new
version
> of BP2 that runs on MacOS X.  Porting to Linux and separation of BP2
into
> multiple, reusuable components are currently lower on the list of
priorities
> but I will make changes to the code to facilitate these goals as I go
along.
> (And they do not have to remain low priorities if other developeres
become
> involved! :)
> 
> Any offers to help or other comments/suggestions would be greatly
> appreciated.
> 
> Thanks.
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> 
> PS.  I would like to finish soon the few minor changes that I began
in June
> and make a non-beta release of BP 2.9.5.  Look for that to happen in
the
> next month (hopefully).
> 
> 
>
-------------------------------------------------------------------------
> 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

[bp-dev] Welcome to new subscribers

[Anthony K. <ant...@sb...>]

I've noticed that we have some new subcribers to bolprocessor-devel and I
wanted to say "Welcome".

I'm interested to know whether you are just here to "keep an eye on things"
or if any of you would like to help with BP development.  We certainly could
use more people working on the project!!

As you can see from the other message that I just sent, I am again looking
at beginning the Carbon porting effort.  This would result in a new version
of BP2 that runs on MacOS X.  Porting to Linux and separation of BP2 into
multiple, reusuable components are currently lower on the list of priorities
but I will make changes to the code to facilitate these goals as I go along.
(And they do not have to remain low priorities if other developeres become
involved! :)

Any offers to help or other comments/suggestions would be greatly
appreciated.

Thanks.

Anthony Kozar
anthonykozar AT sbcglobal DOT net

PS.  I would like to finish soon the few minor changes that I began in June
and make a non-beta release of BP 2.9.5.  Look for that to happen in the
next month (hopefully).

[bp-dev] Notes on Carbon porting

[Anthony K. <ant...@sb...>]

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).

[bp-dev] Carbon compatibility report

[Anthony K. <ant...@sb...>]

The results of running BP 2.9.5 through Apple's Carbon Dating tool are now
online:

http://bolprocessor.sourceforge.net/BP2_Carbon_Port/BP2_Carbon_Dating.html


Carbon is the application framework from Apple that creates a bridge between
MacOS 9 and MacOS X.  A large percentage of the former Mac Toolbox calls are
present within Carbon plus some new stuff.  "Carbonized" applications can
run on both OS 9 and OS X -- on OS X they have an Aqua appearance and enjoy
the true multitasking and memory protection features of that OS.  The Carbon
compatibility report gives details on what parts of BP2 will need to be
modified.

Porting BP2 to Carbon will be the fastest way to get it running on MacOS X.
(It may not be the best move for ultimately making BP cross-platform, but
most of the interest right now seems to be in an OS X port).  Making BP run
as a "native" OS X application (using the Cocoa framework) would always be a
possibility for the future.

My plan at this time is to maintain backwards compatibility with a "Classic"
OS 7-9 build by using #ifdefs around the new and changed code for Carbon.
The primary reason I want to do this is because there seem to be serious
bugs in the Carbon library for OS 9 that make every Carbon program
frustrating to use on that platform.

Any comments or offers to help with this process would be appreciated.

Thanks!

Anthony Kozar
anthonykozar AT sbcglobal DOT net

[bp-dev] First changes

[Anthony K. <ant...@sb...>]

I have been stepping through the BP2 code recently and trying to get a
beginning understanding of how it works.  I've made it through the
initialization process (which is long!) and watched what happens when BP2
quits as well.  Very basic, I know ... ;)

Along the way though, I think that I have managed to correctly disable all
of the registration-related functionality.  Also, I changed the code that
would open the Registation.txt file to open the License file now instead.

A few other changes (along with those above) have all been committed to the
CVS repository.  Instructions for Mac users wanting to use CVS will be
coming soon (I promise!).

I am going to make a few other small changes soon related to versioning and
preprocessor flags (to make it easier to compile debug and non-debug
versions).  When that is done, I may do a release for 2.9.5 (final).  If
there are any other requested changes before then, I can look into it.

Anthony Kozar
anthonykozar AT sbcglobal DOT net


Change Log since last week:

2006-06-06    Anthony Kozar    <ant...@sb...>
    * source/BP2/BP2main.c (main):
    * source/BP2/MenuCommands.c (mAbout):
    * source/BP2/Dialogs.c (DoDialog):
        Disabled the registration system.  Modified "Register" buttons in
        opening and about alerts so that they read "License" and display the
        "License.txt" file.  Disabled launching the Kagi "Register" app.
    
    * BP2 help: Updated FAQ entry for "How do I register for BP2?"
    
    * resources/BP2-MacOS.rsrc: Updated info in the about alert.

2006-06-05    Anthony Kozar    <ant...@sb...>
    * source/BP2/Strings.c (MystrcpyHandleToString):  Fixed a buffer overrun
bug.

    * data/Thierry_Montaudon/-or.piano: Moved to data/Harm_Visser.

    * New ChangeLog file :)

2006-06-02    Anthony Kozar    <ant...@sb...>
    * Many more example files added to new directories:
        bolprocessor/data/Harm_Visser
        bolprocessor/data/Jerome_Demolliens
        bolprocessor/data/Thierry_Montaudon

    * New CVS module, QAVAID, containing the Prolog II code and projects
      from Bernard that create grammars from sets of musical examples.

[bp-dev] Welcome to Bol Processor development

[Anthony K. <ant...@sb...>]

Hello to anyone interested in observing or participating in the Bol
Processor development process.

This list will be used by the BP dev team for discussing development issues
(i.e. non-user-related issues).

Please join this list if you have any interest in the process and send a
"hello" message so that we know that you are out there :)

Thanks.

Anthony Kozar
anthonykozar AT sbcglobal DOT net