Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!shebanow1@applelink.apple.com From: shebanow1@applelink.apple.com (Andrew G. Shebanow) Newsgroups: comp.sys.mac.programmer Subject: Re: HiliteMode versus compatibility Message-ID: <12293@goofy.Apple.COM> Date: 27 Feb 91 02:07:40 GMT References: Sender: usenet@Apple.COM Distribution: na Organization: Apple Computer, Inc. Lines: 27 In article , bruner@sp15.csrd.uiuc.edu (John Bruner) writes: > However, modifying low-memory globals is a future-compatibility no-no. > So, what's the best way to do this? As a related question, is there > any reason to believe that using the BitClr trap to effect this change > is better (in terms of future compatibility) than just zapping the bit > with an inline BCLR instruction (as also described in *Inside > Macintosh* volume 5)? I think that the dangers of accessing public low memory globals (LMGs) has been highly overemphasized. It is true that we (Apple) prefer the procedural interfaces to these things over the direct use of low memory globals, but in cases where no procedural interfaces are provided, you are perfectly safe accessing these globals. Apple can't (won't) just get rid of LMGs overnight - we will make sure that the transistion to a no low memory world will be a gradual one. There are easy MMU hacks we can use to map low memory accesses into the correct trap calls, and I would expect that we would do this (at least temporariliy) if we ever decided to move to a no-LMG world. In any event, developers will be given plenty of notice to make any necessary app changes should they be necessary. As for the use of BitClr, it has absolutely no advantages in this particular case. Use it if it is more convenient, but given that this is something you do in user interface code, you probably should save yourself the extra cycles. Andrew Shebanow DTS Emeritus