Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!kaufman From: kaufman@polya.Stanford.EDU (Marc T. Kaufman) Newsgroups: comp.sys.mac.programmer Subject: Re: Standard File and Desk Accessories Message-ID: <9983@polya.Stanford.EDU> Date: 13 Jun 89 04:43:42 GMT References: <13855@dartvax.Dartmouth.EDU> <446@cbnewsk.ATT.COM> Sender: Marc T. Kaufman Reply-To: kaufman@polya.Stanford.EDU (Marc T. Kaufman) Organization: Stanford University Lines: 22 From article <13855@dartvax.Dartmouth.EDU>, by earleh@eleazar.dartmouth.edu (Earle R. Horton): . Aha! So one of you A4-relative types admits that the trick will . fail someday! This makes my day... . It's just not real nice to write computer software which has a . shorter lifetime than it could have, had you coded it differently. . Modifying code space to store variables or Handles to variables seems . to save a lot of work in writing code for desk accessories and other . code resources today, but is the work saved worth the inevitable . aggravation that users will experience if and when the OS makes that . technique invalid? Will you be around to make sure the software you . have written gets re-coded properly at that time, and will you be able . to make sure that users receive upgrades in a timely manner? Perhaps . not... It is EXTREMELY unlikely that Apple will try to separate code and data spaces in the Mac OS. The 680x0 paging system is just not well suited to short, variable length segments. It seems likely (to me) that processes will be protected from one another... but we're unlikely to see protection within a process. Marc Kaufman (kaufman@polya.stanford.edu)