Ooops. This is serious stuff. When I'm allocating ANY global var I'm sort of playing russian roulette. I may hit a global var of the running app... I can't even save a pointer to a global variable structure allocated in the heap.
So, I see to workarounds:
- Use FtrSet/FtrGet to save a pointer to my global struct.
- Follow David Fedor's suggestion (thanks David), and use global variables at will, but manually allocate space for them at startup time, and set the A5 register to the bottom of the allocated space. Obviously, upon cleanup I must restore the A5 register to the previous value.
- Use one pointer in the app global address space for a global struct. Before allocating this global space, save the pointer's value and restore it upon exit.
Thank you for your bed-time writing :). Proved quite useful. If everything I said is correct, I will post a summary for those who didn't want to follow the thread.
"Douglas I. Anderson" wrote:
Ok...how's this for an explanation:In PalmOS, space is allocated by the OS for an application's global
variables. As has been pointed out, this happens when an application
starts up normally (though it doesn't happen with some launch codes).
PalmOS then lets applications access this chunk of memory by placing a
pointer to it in A5 (if I recall correctly, A5 points just below the block
of memory).The memory that has been allocated is for the application to use however it
wants. The operating system won't clobber it, and if PalmOS is ever
designed to run more than one user application at the same time, it would
have to make sure to allocate lots of separate globals spaces and change
the value of A5 each application switch.Now, let's look at the compiler. The compiler knows that the OS has
allocated this big jucy chunk of memory that can be accessed relative to
A5. That's where the compiler is going to put its globals. As I've said,
this block of memory is owned by the running application. Thus, the
compiler can divy it up as it sees fit. The compiler does this "divying"
at compile time. It knows about all the globals in the application and can
decide where all of them go. Thus, a reference to a variable called
"gResult" might be placed _at compile time_ at -16(A5), depending on how
many other global variables were present in the app. Remember, since the
compiler knows that nobody else will be screwing with this memory, it can
decide what locations it wants to use and just hard-code them into the
final binary.Now, let's imagine writing a desk accessory, where (as we have been told),
a new globals space is _not_ allocated when the desk accessory launches
(the same is true of hacks for you hackers out there). First, we compile
our code resource. The compiler, knowing of the PalmOS's convention for
using A5-relative globals, will figure out how many globals we have in our
DA and then allocate space for them relative to A5 (at compile time). As
it knows about "all" the globals, it can pick whatever locations it wants
to store something (as long as it's in the OS'es block). Let's say it
picks -16(A5). Now, we run our DA. The application puts something
-16(A5), knowing that nothing else is going to be clobbering it. Then, the
DA gets launched. Note that A5 hasn't changed, as DA's don't get their own
globals space. The DA now stores something -16(A5), thinking it has its
own globals space. Oops!..hopefully, that makes sense. I'm not sure I'm thinking right, since
it's past my bedtime. :)
--
Sergio Carvalho
---------------
[EMAIL PROTECTED]
If at first you don't succeed, skydiving is not for you
