Path: utzoo!attcan!uunet!cs.utexas.edu!yale!quasi-eli!cs.yale.edu!fischer-michael From: fischer-michael@cs.yale.edu (Michael Fischer) Newsgroups: comp.sys.atari.st.tech Subject: Re: Malloc() and desk accessories Message-ID: <25938@cs.yale.edu> Date: 29 Aug 90 19:53:44 GMT References: <2261@atari.UUCP> <1632@van-bc.wimsey.bc.ca> <6828.26dba802@uwovax.uwo.ca> Sender: news@cs.yale.edu Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158 Lines: 37 Nntp-Posting-Host: ginkgo.theory.cs.yale.edu Originator: fischer@ginkgo.CS.Yale.Edu In article <6828.26dba802@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: >In article <1632@van-bc.wimsey.bc.ca>, jhenders@van-bc.wimsey.bc.ca (John Henders) writes: >> Thanks for the explanation Ken. Would using an auto program to serve >> DA memory requests work? Could the auto program somehow wake up once Gem was >> initialized so it could use the gem pipeline to get requests for memory from >> DA's and attach them to it's basepage. If this worked,it would seem we could >> have one auto program handle requests from many DA's. I know this is off- >> topic from Steve's question,but I'm curious. Actually,I'd guess this is how >> the non reset proof version of Shadow works. >> >(I'm not Ken, but...) >I would say not. There's no way to "wake up" a TSR under TOS; from TOS's >point of view the program is dead and buried. If you want to go for >non-portable code, the desk accessory certainly could dig through the TOS >memory allocation list and "attach" any memory it allocates to some other >program that won't terminate (the desktop being an obvious candidate). >This strikes me as being quite ugly, and moreover I'm not sure that it would >be guaranteed to work. 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. -- ================================================== | Michael Fischer | ==================================================