> It has to do with the locking of the code 1 resource into memory.
> The memory manager can move unlocked resources around to compact
> the storage heap.i So the launch code looks up the code 1
> resource, pushes its start address on the stack and jumps to it
> with RTS.
Sorry, I still don't understand. Most of what you describe above is done by the OS (the Memory Manager). OK, so it finds the most appropriate place where to move the code 1 resource, locks it, and transfers control to it.
But it's not it (the Memory Manager) that does the weird push/ret stuff - it's the first few instructions of the loaded code 1 resource. Are you saying that, after loading them in memory, the memory manager *modifies* the operands of these instructions, in order to reflect the place of the code 1 resource in memory?
(This is very important to me - so far I've assumed that the contents of the code 1 resource of the normal applications is constant. If that contents - i.e., its first few instructions - constantly changes as the applications are launched, that would have serious impact on the application I'm writing.)
> The D0 register is typically used for integer type return codes
> by most 68k compilers.
Yes, I knew that. But that's the purpose of setting its least significant bit to 1 as first thing when the code is launched?
> Look at the SystemMgr.c code in the Limited PalmOS 4 sources.
> You'll find the answer to your questions there.
Uhm that's some 230 Kb of C source - any hints at which function(s) I should look? Much of the code of SysAppLaunch seems to be censored anyway... and what is left basically sets a pointer (codeP) to the memory block containing the code 1 resource and calls PrvCallWithNewStack which essentially does a JSR to it.
I can't see anything modifying the beginning of the loaded code 1 resource and I can't see why the code in that code 1 resource transfers control via push/add/rts instead of via a normal jmp.