> Then those were broken apps! A correctly written program must manage A4 in a
> way that is absolutely transparent to PalmOS and to other program entities.
Yes, of course they were. However, we have an interest in helping developers to
write apps that won't break. Since you're developing tools, I would think that
you would as well. Globals access is a part of the language, and should be
transparently available all the time. I believe that a developer has the right
to assume this. Unfortunately, PalmOS took some shortcuts so that globals are
not available under some launchcodes. I certainly don't believe that the
present GCC/A4 solution is any better. If you make a mistake and try to access
palm-standard globals from a launchcode that doesn't support them, then you
immediately bus error. The developer discovers their mistake very quickly, and
its relatively easy to debug. If you forget to add these wrapper macros, your
app may work just fine until a future rev of the OS, or it may crash
unpredictably. Your tools are helping new developers to create apps that are
just time bombs, waiting to go off.
> Are you talking about reverse-engineering SysAppStartup() and doing what it
> does, i.e., setting up your own A5 world complete with that magical 4-byte
> system pointer at 0(A5)?
Nope - I forgot about that. There are quite easy, only slightly incompatible
ways to set up a valid A5 world for yourself. But of course, "slightly
incompatible" loses next to A4 relative globals which is "not incompatible".
The problem is that A4 globals include tricky pitfalls for novice developers,
who may not discover their mistakes until its too late.
However, if you were willing to be just a little bit incompatible, you could
probably call SysGetAppInfo() to obtain the AppInfoPtr and then store it at A5,
or alternatively set the sysAppLaunchFlagNewGlobals and then call
SysAppStartup(). One perfectly compatible thing you could try is sublaunching
your app again with the sysAppLaunchFlagNewGlobals flag set. This would
(probably - I haven't tried it) work just fine, although it seems like a bit of
a pain. If this doesn't work, though, the only completely compatible thing you
can do is to use an A4 globals scheme such as GCC uses, complete with ugly
macros for callback funtions. What we really need is a trap to allocate
application globals. Its been on our minds for a while, so hopefully we'll get
it for the next release.
> I guess that he was talking about reverse-engineering SysAppStartup(),
...
> I was very surprised to see someone from Palm suggest this...
You're pushing the line a bit here... I didn't suggest it, so please don't go
telling people that I did.
> OTOH, A4-based data access is absolutely transparent and invisible to PalmOS
Right... and if you know what you're doing, this is fine. Its too bad, though,
its not invisible to developers. Even worse that if they forget, they may not
discover their mistake until their app breaks and their users complain.
> Besides, what about program entities other than applications?
Go ahead and compile them with A4 relative globals if you like. Since there's
no support for globals in shared libraries, hacks, etc., then developers that
make these will need to be aware of the issues. No problem there. The great
majority of development, however, is for applications. That's generally where
people start, and where they will make their first mistakes. I do what I can to
help make finding them easy.
> I understand this of course, and my mechanism doesn't *always* manufacture the
> data segment on every launch.
I hope all your developers understand it too. In any case, this is a pretty
cool mechanism. Except that you have to add funny macros to all your callbacks.
This is a pain, and is a bit less efficient (since its not necessary if you use
A5). Out of curiosity, where do you store the globals ptr for the macro to
install, anyways?
Jesse
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
