home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / atari / st / tech / 6618 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!csus.edu!netcom.com!ersmith
  2. From: ersmith@netcom.com (Eric R. Smith)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
  5. Message-ID: <1993Jan13.030029.1407@netcom.com>
  6. Date: 13 Jan 93 03:00:29 GMT
  7. Article-I.D.: netcom.1993Jan13.030029.1407
  8. References: <wmtwen.726497985@rw8.urc.tue.nl> <1993Jan8.183133.12773@netcom.com> <1iv954INN1geq@rs1.rrz.Uni-Koeln.DE>
  9. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  10. Lines: 55
  11.  
  12. In article <1iv954INN1geq@rs1.rrz.Uni-Koeln.DE> kim@vax.mpiz-koeln.mpg.dbp.de writes:
  13. >In <1993Jan8.183133.12773@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
  14. >
  15. >>The answer is quite simple: use malloc() and free(). This has 3 advantages:
  16. >
  17. >>(1) It will work in accessories, if your library is sensible (most are).
  18. >>    The OS Malloc() function cannot be called from accessories at all.
  19. >
  20. >I have a question about this. From what  I  understand,  malloc()
  21. >manages memory that is in turn allocated by Malloc() from the OS.
  22.  
  23. This is generally true, but a clever library will detect whether the
  24. program is running as an accessory or an application and adjust malloc()
  25. to behave accordingly; for accessories, if the amount of memory requested
  26. would exhaust the initial 'pool' of memory that the accessory allocated
  27. when it was starting up, then the malloc() call will fail. For applications,
  28. the library malloc can of course call the OS Malloc to obtain more
  29. memory.
  30.  
  31. (So whether malloc() is safe to use in an accessory depends on which
  32. library you're using. The GNU C and MiNT libraries certainly
  33. give the correct behaviour for accessories; I can't vouch for
  34. any others, but I'm sure some do.)
  35.  
  36. >Two comments on this: Firstly, I have never  understood  why  TOS
  37. >won't  let  accessories  Malloc() their own memory, but considers
  38. >memory Malloc()'ed by accessories to belong to the  main  process
  39. >running  at  the  time  the  Malloc()  occurs. Does anyone know a
  40. >sensible reason why that is? Secondly,  this  silly  problem  may
  41. >become  increasingly  irrelevant  when  MultiTOS  finally becomes
  42. >available...
  43.  
  44. GEMDOS is a single tasking OS. That means that as far as GEMDOS is
  45. concerned, only one application is active at a time. GEM does some
  46. tricks to make it look to the user like accessories can also be
  47. active; but GEMDOS doesn't know about these tricks, all it knows about
  48. is its 1 main application. So every system call (including Malloc,
  49. and also including Fopen and other file calls) made to GEMDOS occurs
  50. in the context of the 1 GEMDOS program running, i.e. the "main"
  51. application.
  52.  
  53. MultiTOS of course will change this. Actually, the whole concept of
  54. an "accessory" becomes rather irrelevant with MultiTOS (since there's
  55. no need for accessories, you can just write applications that stay
  56. around as long as the user wants). Of course MultiTOS does load
  57. accessories (for compatibility) and in fact every accessory becomes
  58. a separate MiNT process (so they can Malloc if they want to; but
  59. an accessory that takes advantage of this feature wouldn't work
  60. under old TOS, and as I said there's really no reason to write
  61. a MultiTOS-only accessory since they can't do anything normal
  62. applications can't do. Applications can even make a menu_register
  63. call to change the way their names appear in the "Desk" menu!)
  64.  
  65. Regards,
  66. Eric
  67.