home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / atari / st / tech / 4393 < prev    next >
Encoding:
Text File  |  1992-08-12  |  1.2 KB  |  32 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!cs.utexas.edu!torn!newshost.uwo.ca!uwovax.uwo.ca!7103_2622
  3. From: 7103_2622@uwovax.uwo.ca (Eric Smith)
  4. Subject: Re: Can a TSR Malloc()?
  5. Organization: University of Western Ont, London
  6. Date: Wed, 12 Aug 1992 13:52:16 GMT
  7. Message-ID: <1992Aug12.095216.1@uwovax.uwo.ca>
  8. References: <sourada.713595993@vincent1.iastate.edu>
  9. Sender: news@julian.uwo.ca (USENET News System)
  10. Nntp-Posting-Host: hydra.uwo.ca
  11. Lines: 19
  12.  
  13. In article <sourada.713595993@vincent1.iastate.edu>, sourada@iastate.edu (Steven D Ourada) writes:
  14. > Is it possible (and good practice) for a TSR program to Malloc() 
  15. > (the GEMDOS way) after Ptermres()?
  16.  
  17. No, and no.
  18.  
  19. Or, more accurately, it's possible, but not likely to produce the desired
  20. effect. As you point out, GEMDOS will think that it's the invoking program
  21. that did the Malloc, and will free the memory when the invoker exits.
  22.  
  23. There is no reliable way to make GEMDOS change the memory ownership of
  24. Malloc'd memory.  The tricks people use to do this *will* break in
  25. future versions of TOS (in particular, MultiTOS) and neither will they
  26. work under MiNT.
  27. --
  28. Eric R. Smith                     email:
  29. Dept. of Mathematics            eric.smith@uwo.ca
  30. University of Western Ontario
  31.  
  32.