John Marshall <[EMAIL PROTECTED]> wrote:
> The fly in the ointment is that the version of prc-tools which
> supports multiple code resources currently doesn't support GLibs.
> Fixing this shouldn't been too much trouble, and Michael Sokolov
> <[EMAIL PROTECTED]> has already done it, or something
> similar.
OK, now that John has let my genie out of the bottle, I have to tell the folks
what's up. Here it is. While John was doing his version of post-0.5.0 prc-
tools, I have been doing mine. The two versions have been developed completely
independently, and although I have recently been in contact with John exploring
the possibility of joining our efforts, unfortunately there are some major
ideological differences between them (what John considers bugs I consider
features and vice-versa) and it is likely that our enhancements will become
mutually exclusive.
Like John's, my version supports multiple code segments. However, unlike John's
work, in my work GLibs have been one of the highest priorities, and not only
are they not broken, but have underwent major enhancements. To put the icing on
the cake, I have enhanced the GLibs themselves and the GLib caller stubs
completely independently of each other and kept the GLib ABI (Application
Binary Interface) between them exactly the same. I have taken this very
seriously, and I have written the formal GLib ABI that matches the de facto
GLib ABI set by prc-tools-0.5.0. This means that anyone can call any GLib
without ever worrying about versions, as all GLibs and all GLib caller stubs
written to date follow the same ABI.
And yes, with my version you will be able to build GLibs with multiple code
segments out of the box, again without breaking the ABI. In addition to the
standard program entity types defined by PalmOS (applications, SysLibs) or by
prc-tools-0.5.0 developers and me (GLibs), you will be able to define your own
program entity types to your heart delight to implement your own plug-in
interfaces or whatever you can dream of. This is like CodeWarrior's ability to
target an unspecified-purpose bare code resource (see KB article 1143), except
that rather than always having just one bare code resource, you will specify
yourself what segments and resources your custom target has (do you have a data
segment or not, how many code segments, what resources to put all this in).
Among other things, this will allow you to have custom targets that externally
conform to the ABI of a standard target, but internally do things that this
standard target does not support. For example, you will be able to construct
program entities that on the inside have data segments, multiple code segments,
and other goodies, but to PalmOS and everyone else look like plain old boring
SysLibs or plug-ins a la KB article 1143.
Right now my version is too unfinished to give it out to anyone or tell you
anything more. Treat this posting as a sneak preview of a not-yet-released
movie. However, I am tantalizingly close to having a beta that I can give out
to a few people. John will get it among others, and then we'll see if there is
anything we can do to at least partially join our efforts. At that point we'll
know who is going to be making the official release: John, me, or both. Stay
tuned!
And John, I need to talk to you. I have been trying to reach you at Palm
unsuccessfully over the past couple of days. Could you call me at the office (#
in my mail signature) some time today during business hours U.S. Central time?
--
Michael Sokolov 2695 VILLA CREEK DR STE 240
Software Engineer DALLAS TX 75234-7329 USA
JP Systems, Inc. Phone: +1-972-484-5432 x247
or +1-888-665-2460 x247
E-mail: [EMAIL PROTECTED] Fax: +1-972-484-4154
