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: <6828.26dba802@uwovax.uwo.ca> Date: 29 Aug 90 15:33:22 GMT References: <2261@atari.UUCP> <1632@van-bc.wimsey.bc.ca> Lines: 27 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. Your suggestion of having a "server" handle memory requests from DA's would work quite well under a multi-tasking system such as RTX or MiNT, and should be easy to code under either of those two systems. -- 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