Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Allocating long-lived memory blocks
Keywords: Malloc, Gemdos
Message-ID: <1186@atari.UUCP>
Date: 7 Oct 88 18:08:18 GMT
References: <39610@yale-celray.yale.UUCP> <39617@yale-celray.yale.UUCP> <686@uhnix2.uh.edu>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 20

In article <686@uhnix2.uh.edu> uace0@uhnix2.UUCP writes:
> The _run pointer MUST point to a valid basepage, not the desktop's, which we
> found to cause trouble.

Oh, yes - I'd forgotten about that restriction.  The most likely candidate
is the basepage of the TSR portion of your application.  If you don't have
one, you'll have to get one.  If you use the basepage of any current process
(your parent or any of its parents, all the way to the desktop) you'll
be sorry.  That's because the context they need to return from the Pexec
they've called is stored in the basepage.

Please don't take this as license to do strange things with _run ... 
remember that _run is STILL only guaranteed as a read-only variable, and
the things it points to are read-only, too (except by the OS itself). 
If something works, fine, but remember that you're taking a chance on
not having it work in the future.

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