shebanow1@applelink.apple.com (Andrew G. Shebanow) (02/27/91)
In article <BRUNER.91Feb26101455@sp15.csrd.uiuc.edu>, 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
ksand@Apple.COM (Kent Sandvik) (02/28/91)
In article <12297@goofy.Apple.COM> shebanow1@applelink.apple.com (Andrew G. Shebanow) writes: >In article <49662@apple.Apple.COM>, ksand@Apple.COM (Kent Sandvik) writes: >> There's one noticeable exception, and that's the MacOS emulation under >> A/UX. Sure, many low-level globals are supported, but then again there >> are some which ain't. I tried to get a list of the non-supported >> low-mem globals from engineering, but they did not want to publish this, >> which is understandable - this list is in flux and subject to change >> any minute, second... >With A/UX 2.0, the list of unsupported low memory globals is much smaller >than it was in AUX 1.0.x, and I don't know offhand of any LMGs that aren't >supported that don't have procedural equivalents (e.g., Gestalt). There may be some, >but even so the most use of non-hardware related LMGs should be safe. I stand >by my original advice: feel free to use LMGs where there is no safer alternative. Well, just as an example the MBarHeight LMG is not supported - so there are some presentation programs that don't work under A/UX 2.0. Problems with unsupported LMG creep up now and then - that's why I suggested to test if the LMG is supported under A/UX, and if not provide an alternate function to achive the same end result. It is true that many critical LMGs are supported, as long as the Manager itself is supported (for instance no SCSI Manager support - no SCSI Manager LMGs, no new Sound Manager support (6.0.7), no LMGs). I could try to get together a list of unsupported LMGs, but I think it's in vain because engineering adds and changes the design time after time. One must also take into account Managers/features not supported with various releases, like no Script Manager support in 2.0 (now supported in 2.0.,1), so it should not hurt to run the program under A/UX before assuming it works with that platform as well. Anyway Andy, I hope we agree on the idea of moving away from LMG dependencies in the long run ;-). regards, Kent, DTS Polecat -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
lippin@ronzoni.berkeley.edu (The Apathist) (02/28/91)
Instead of clearing the bit in the low memory global, I prefer to use PenMode(hilite); PaintRgn(selection). I suspect that this method is less popular because the description of it in IM V is somewhat difficult to puzzle out. The value of hilite is (rather curiously) 50. You'll need this if you're using the latest MPW interfaces, as this constant is missing from them. --Tom Lippincott lippin@math.berkeley.edu "I just channel my rebellion into the mainstream." --Something Wild