How about something like this to avoid additional complication:
ptr = *++basep;
// Get the LocalID so we could use MemLocalIDKind to identify
// what type of pointer we have
LocalID locID = MemPtrToLocalID (ptr); // this is pretty fast
if (MemLocalIDKind (locID) == memIDPtr) // also pretty fast
{
MemPtrUnlock (ptr); // avoid handle operations on a ptr
// that is not handle-based
}
else
{
// do the handle-based stuff here...
hnd = MemPtrRecoverHandle (ptr);
MemHandleUnlock (hnd);
DmReleaseResource (hnd);
}
Vitaly
P.S. The startup code could alternatively allocate a dynamic chunk and store
the segment handles in it. The handle or ptr to the chunk could be stored in
a local variable of the startup code, so it will be available when PilotMain
returns back to the startup code. Since the number of segments is not
likely to be very large, this dynamic chunk should not be a burden on
dynamic memory. However, I don't have the details of the multi-segment
implementation, so this alternative suggestion could be pretty stupid :-)
>>>>>>>>>>>>>>>
Subject: Re: Problem running app from Flash ROM
From: John Marshall <[EMAIL PROTECTED]>
Date: Wed, 15 Mar 2000 10:00:03 -0800 (PST)
X-Message-Number: 34
Charles Morris <[EMAIL PROTECTED]> wrote:
> would the fact that
> I now have multiple segments require some sort of clean up on application
> exit trigger this situation?
Yes. The prc-tools startup code does the following to release the extra
code resources when your app exits:
MemHandle hnd = MemPtrRecoverHandle (*++basep);
MemHandleUnlock (hnd);
DmReleaseResource (hnd);
Bummer. So maybe this should be rewritten for ROM apps...
>[Quoting Bob Ebert...]
>> Probably by
>> keeping the handle around in a different variable...
Right. I didn't want to use up some more global space and complicate
the startup code doing this, but perhaps we'll have to. :-(
John
<<<<<<<<<<<<<<<<
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
