As a DA developer, I would suggest the feature get/set method. Remember to
change the ownership of the memory chunk so it doesn't get automatically
freed when an app quits.
Maybe you can convnice one of the DA launcher developers to add some code
to their product to support globals (you could call it version 2 of the DA
standard or something). Hmmm....I wonder how long it would take to do it.
You could imagine doing something like:
Proposed DA version 2 standard:
* Register a feature (like 'DAvr') containing the current DA standard.
That way DAs that require version 2 of the standard can check for it.
* DAs contain a resource (like 'DAsz') that indicates the size of the
globals space that is needed for that app. If this is missing, no space
is allocated (so space isn't wasted).
* The lifetime of globals is until the next reset. This would be
relatively easy to do...but you'd have to make sure not to have too
many globals, since they take up heap sapce.
..I'm not positive this would work, since I don't know that extensively
how the OS allocates space for globals, but it sounds reasonable to me.
BTW: the way compilers allocate globals isn't quite as random as I made it
sound (it doesn't just randomly pick, though it could potentially do that).
It usually allocates space sequentially...
---
--On Fri, Jun 25, 1999 8:58 AM +0100 Sergio Carvalho
<[EMAIL PROTECTED]> wrote:
>
> 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. I've been getting the same kind of behaviour
> with FtrSet/FtrGet (app crash after the DA quits). Can you think of any
> reason?
>
> 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
