Path: utzoo!utgpu!watserv1!ria!uwovax!7103_2622
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Malloc() and desk accessories
Message-ID: <6841.26dd14bb@uwovax.uwo.ca>
Date: 30 Aug 90 17:29:31 GMT
References: <2261@atari.UUCP> <1632@van-bc.wimsey.bc.ca> <6828.26dba802@uwovax.uwo.ca> <25938@cs.yale.edu>
Lines: 28

In article <25938@cs.yale.edu>, fischer-michael@cs.yale.edu (Michael Fischer) writes:
[ In response to a question about how a DA can Malloc memory ]
> 
> There is a trick that will work (at least in TOS 1.4) but is also not
> portable.  Namely, change the current process pointer to point to the
> DA before doing the Malloc, and restore it to its original value
> immediately afterwards.  This causes Gemdos to think that the DA is
> the owner of the newly-allocated block, not the currently-running
> application, which is what you want.  The current process pointer is
> kept in a documented low-memory location.  What isn't officially
> sanctioned is changing the pointer; it is supposed to be read-only.
> Thus, the behavior of TOS when you change it is not guaranteed to be
> the same in future versions of TOS.  Another warning besides the
> non-portability issue: memory fragmentation can become a real problem
> if DA's go around Mallocing memory at random times.  What Ken
> described is much safer.
> 
I hadn't thought of that trick; it's not a bad idea. As you say, though,
it may not work in future versions of TOS. It certainly doesn't work
under MiNT (which sets the current process pointer, but otherwise ignores
it). I don't know about RTX, but I'd suspect that it would have similar
problems.
--
Eric R. Smith                     email:
Dept. of Mathematics            ersmith@uwovax.uwo.ca
University of Western Ontario   ersmith@uwovax.bitnet
London, Ont. Canada N6A 5B7
ph: (519) 661-3638