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. :)
---
--On Wed, Jun 23, 1999 6:15 PM +0100 Sergio Carvalho
<[EMAIL PROTECTED]> wrote:
>
> No, I had already read this document before. there's a paragraph stating
> you can't use global variables, but it doesn't explain why.
>
> I looked at the source code for the tutorial DA, and it does allocate one
> global variable that points to a structure holding all the global
> variables, contradicting the document. Smaller tests with DAs worked well
> with quite a few global variables.
>
> My question is: Why is there a limitation on global variables for Desk
> Accessories?
>
> Are global variables allocated on the stack? If so, shouldn't there be
> the same kind of restriction for local vars (allocated on the stack, even
> if temporarily).
>
> Desk Accessories are quite a good idea, but it is really lacking
> documentation...
>
> Ivan Shiyan wrote:
>
>> Well, as I remember, there's a special paragraph in
>> http://home.earthlink.net/~terada/pilot/da_memo_e.txt
>> explaining this
>>
>> Ivan
>>
>
> --
> Sergio Carvalho
> ---------------
> [EMAIL PROTECTED]
>
> If at first you don't succeed, skydiving is not for you
>
>
