Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Pexec question
Keywords: GEMDOS, Pexec, developer docs
Message-ID: <1463@atari.UUCP>
Date: 24 Apr 89 18:53:17 GMT
References: <1927@hall.cray.com> <477@electro.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 33

In article <477@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
> In article <1927@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes:
> >i have a question on Pexec, specifically on load/nogo then go more than once.

> [I have the same problem...]
> ... the ability to do this would allow
> people to write really HUGE accessories, but instead of eating up 200K for 
> the huge accessory all at once, the modules it need to run can be pexeced
> when needed into an internal buffer.

I will tell the net the same thing I told Bill Rosenkranz: don't try to
use Pexec to load overlays. 

If you want to load overlays, do it some other way.  For example, demand
that the overlays be position-independent and load them anyplace you
want.  Alternatively, load them and fix them up yourself -- there is
enough information in the documentation to do this.  The normal startup
will not work, of course, because an overlay is a fragment, not a
program.  Certainly, an overlay should never call Pterm(), and should
not expect to have a basepage. 

Some programs which have multiple printer drivers, like Degas and (I
believe) MicroSoft Write, use this trick.  The driver is a module, not a
program: the beginning of the module contains relative pointers to the
externally-visible entry points. 

Your best bet is to load the driver code into memory and relocate it
yourself (unless it's position independent), JSR to it, and have it RTS
to you, and stop trying to think of it as a process. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt