home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14741 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  2.3 KB
  1. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!usc!rpi!uwm.edu!ogicse!das-news.harvard.edu!husc-news.harvard.edu!tara!fry
  2. From: fry@tara.harvard.edu (David Fry)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: How to save a PICT file?
  5. Message-ID: <1992Aug30.002216.15223@husc3.harvard.edu>
  6. Date: 30 Aug 92 04:22:14 GMT
  7. Article-I.D.: husc3.1992Aug30.002216.15223
  8. References: <1992Aug26.000749.3750@desire.wright.edu> <zben-280892151439@zben-mac-ii.umd.edu> <1992Aug29.003233.3802@desire.wright.edu>
  9. Distribution: usa
  10. Organization: Harvard Math Department
  11. Lines: 31
  12. Nntp-Posting-Host: tara.harvard.edu
  13.  
  14. In article <1992Aug29.003233.3802@desire.wright.edu> jmatthews@desire.wright.edu writes:
  15. >In article <zben-280892151439@zben-mac-ii.umd.edu>, zben@ni.umd.edu (Charles B. Cranston) writes:
  16. >> Ahem, wouldn't it be a good idea to lock the handle while writing
  17. >> it out?  I wasn't aware _Write refrained from moving memory.  Please
  18. >> correct me if I'm wrong about this...
  19. >
  20. >An excellent question. An expression such as Ptr(picHdl^) creates a
  21. >copy of a master pointer; the original will change if the block to
  22. >which it points gets moved. Fortunately, I haven't found _Write on
  23. >any list of traps that move memory (IM vol I-VI; THINK Reference).
  24. >
  25. >I suppose that believing _Write will never move memory in the future
  26. >is a shade optimistic. I hope the "lock everything" partisans don't
  27. >don't wind up being too right:-)
  28.  
  29. I don't think there's any chance that _Write will ever move memory.
  30. First, they didn't put it on that list so everybody is counting on it not
  31. moving memory, and _Write is a VERY popular trap call - lots of
  32. programs would break.  Second, if _Write did move memory, lots of
  33. useful interrupt, VBL, and time manager tasks would break because they
  34. couldn't communicate with the disk, serial port, or AppleTalk (I think
  35. that last one is correct).  In fact, would AppleTalk work at all?
  36.  
  37. What are the chances that a future version of the MacOS, or an OS that
  38. existing Mac programs run on like PowerOpen or Pink, will not have
  39. relocatable blocks and all of this is moot?
  40.  
  41. David Fry                                  fry@math.harvard.edu
  42. Division of Applied Sciences               fry@huma1.bitnet
  43. Harvard University                      ...!harvard!huma1!fry
  44. Cambridge, MA  02138            
  45.