Path: utzoo!attcan!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Preloading revised
Message-ID: <1030@philmds.UUCP>
Date: 18 May 89 06:52:54 GMT
References: <1028@philmds.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 35

In article <1028@philmds.UUCP> leo@philmds.UUCP (I) wrote:
    [a sample program demonstrating preloading]

As it stands, there is still a problem: the second vector of the
basepage should be updated to match the new Mshrinked program top. This
address is currently used by Pexec(0,...) and Pexec(4,...) to determine
where to build a stack. For Pexec(0,...) this is not a problem, 'cause
the system allocates a (maximal sized & contiguous?) space for the
program, inits the appropriate vectors on the basepage and goes off.
Startup code that Mshrinks also adjusts the stack pointer to point at
the end of the new space. However, if Pexec(4,...) is used and the
preloaded program has been Mshrinked by its parent, the stack must be
guaranteed to be set up properly beforehand. One line of code at the
end of the function preload() (the one marked with /*** ***/) will do
this:

   memneed &= ~1;                         /* Make it even */
   Mshrink(basaddr,memneed);              /* Now shrink to required size */
   ((long *)basaddr)[1] = basaddr + memneed; /*** Adjust new program top ***/

   return OK;
}

[The funny thing is that this line WAS present in my original code - a
shell -; since I could not explain it, and the program appeared to work
without it, I decided to remove it. Note also that only in rare cases
there are problems to be expected: for instance, if a preloaded program
starts another program its own stack will be corrupted. This should be
solved using the above code.]

I will look into supplying some more code (like clearing the BSS,
making copies of the data segment etc.), which could make the concept
of preloading even more userful.

    Leo.