Thank you for your reply. The information is very helpful.


For the reason why I would like to know how system globals
are allocated, I'm trying to implement an utility that takes snapshots
of the dynamic heap and then the dynamic heap could be recovered
later using the snapshot. In my experiment, the recovery process
restores all the memory content except the stack region of the recovery
process itself. The restoration of memory content seemed successful
when I ran the utility through debugger, but finally the system crashed
when I tapped on the silk-screen button after the restoration completed.
I'm wondering if I should not overwrite the system globals, so I would
like to know where the system globals are and try not to overwrite them
during recovery.

--Chiyi Lin

"Scott Johnson (Bellevue)" [EMAIL PROTECTED]> wrote:
> > From: Chi-Yi Lin [mailto:[EMAIL PROTECTED]]
> > In the documentation, it says that a running process has a stack
> > of size 4K.
>
> Generally true, but you can change the size at build time if needed.
>
> > I'm wondering if it means that there is only one application stack
> > and once the application quits, it returns the stack to the system;
>
> Yes, that's how it works.
>
> > the documentation says 40KB of system globals is in the dynamic heap.
> > Does this chunk of memory have a fixed address in the dynamic heap?
> > I would like to know where system globals are.
>
> It's not necessarily a single chunk, and you don't have access to such
> objects anyway.  The OS allocates memory for itself in the heap at various
> times when your app is running.  In addition, there is a separate fixed
size
> block of system globals that exists outside the heap at a certain fixed
> address, but your code is not allowed to poke at this region of memory
> either.  You need to use documented APIs.
>
> > If you have any clue on these topics, it is most welcome to drop me a
> > line. Your help is deeply appreciated.
>
> Are you trying to accomplish something specific here?  If you post
details,
> you should get solutions that don't involve "hacking".
>





-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/tech/support/forums/

Reply via email to