oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/19/88)
Thanks to all who replied to my posting about the low memory globals on future systems. Note: This posting contains valuable information: the procedural interfaces to many of the low memory globals, information not otherwise brought all together in one place. (It would be a good topic for a tech note.) ----------------------------- From darin@apple.com Wed Nov 2 20:35:44 1988 Subject: Globals Status: R I'm currently thinking a lot about low-memory globals. Just a few immediate comments on your list: CurApRefNum is unnecessary. Instead you should call CurResFile when the application starts up and store it in your globals. CurApName is unnecessary. Get the refNum of the application, and call GetFCBInfo to get its name. JGNEFilter is definitely unecessary. Maybe you can be more specific what you're doing with it. PaintWhite is probably a bad idea. Why are you using it? Particularly legitimate uses are: CaretTime CurDirStore CurrentA5 DoubleTime FractEnable GrayRgn HiliteMode SFSaveDisk These should have procedural interfaces some time in the "near" future. For the others, I'd like to hear more specific reasons why you're using them, and what kind of progam (driver, application, INIT) it's for. ----------------------------- From well!wdh@cogsci.berkeley.edu Thu Nov 3 15:31:37 1988 Subject: Re: Don't take my low-mem globals away! It's clear that a device driver will always need to know more than applications do, so that it will (for example) probably always be legit to get at VIA or UTableBase for system level software, although it might make sense to add a programmatic interface for them, too. Some of the other ones (SFSaveDisk, etc) are clearly the result of a lack of forethought on the part of Apple. The designers of the Mac were Apple II hackers, not mainframe programmers, so "zero-page" globals were an obvious solution. Why do you need EventQueue? Are you hacking with it with your jGNEFilter? What about PostEvent? I agree (and I've heard Apple agree) that there needs to be more programmatic interfaces before they take away the direct interface. -Bill ----------------------------- From earleh@eleazar.Dartmouth.EDU Fri Nov 4 13:57:22 1988 Subject: Re: Don't take my low-mem globals away! ... >CurApRefNum >CurApName - so an application can find out what the user has renamed > it to. GetAppParms will do these two for you, plus a Handle to the Finder info. It's in ROM. ... >DoubleTime - so an application can time mouse clicks to see if it > should treat them as double clicks. GetDblTime returns the value of DoubleTime. It's not in ROM, and presently just reads the value from the low-memory global. ... I consider the GetAppParms call to be a "real" procedural interface, because it's a trap call and can be considered a part of the Toolbox/Operating System. It is probably the only one which exists for any of the low-memory globals you have listed. I do not consider the GetDblTime call to be a "real" procedural interface, because it is in a library, and accesses the low-memory global directly. Using GetDblTime is therefore equivalent to reading DoubleTime yourself. I would add this to the points you made in your posting: If we get procedural interfaces, then we want "real" ones that will allow binaries to continue to function after low-memory changes. Earle Horton -- Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Sorry, no fancy stuff, since this program limits my .signature to three ----------------------------- From David Phillip Oster Although it is important to get a procedural interface that works by calling some trap, so that Apple gets the independence it wants, giving us the procedural interface is a good first step. I'd be happy to see something like the old serial interface stuff, where the procedure calls connected to code resources, which in turn, if the version of the system was new enough, just call the revised ROM. ----------------------------- From decvax!eagle_snax!mer@vindaloo.Berkeley.EDU Sat Nov 5 23:12:34 1988 Date: Sat, 5 Nov 88 11:16:16 PST Subject: Re: Don't take my low-mem globals away! >CaretTime ***GetCaretTime() >DoubleTime ***GetDblTime() >GrayRgn ***GetGrayRgn() >MenuCInfo ***GetMCInfo() (maybe, didn't look it up) >MenuList ***GetMenuBar() As an additional comment, most or all of the "approved" access methods are actually glue routines that merely return the value of the low mem global, not traps. This means that even if you use the approved access method, your code will only be source-code compatible with future breakage, not object-code. ---------------------------------------------------------------- Give a man a fish and he's full for a day. Teach him to fish and he's full for life. Therefore, the answer to most tech support questions is, "Read the f'in manual!" --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
jkjl@munnari.oz (John Lim) (11/21/88)
I think that the best method for low mem globals is FUNCTION GetLowMemGlobals(address : Ptr; Size: integer; buffer:Ptr): Boolean; Thus if you want to get Mouse ($830), check := GetLowMemGlobals($830,sizeof(Point),@Whereismouse); and check will be FALSE if the mac no longer supports mice :-). john
ech@poseidon.ATT.COM (Edward C Horvath) (11/23/88)
From article <26867@ucbvax.BERKELEY.EDU>, by oster@dewey.soe.berkeley.edu (David Phillip Oster): > From darin@apple.com Wed Nov 2 20:35:44 1988 > JGNEFilter is definitely unecessary. Maybe you can be more specific what you're > doing with it. > PaintWhite is probably a bad idea. Why are you using it? Given the dictum "no tail patches," jGNEFilter provides the means to get control of the processor under "stable" conditions and to inject events. While I don't need either of those for applications I write, I DO need them for applications didn't write and for system software. It isn't ONLY Apple that writes system-level software, even Darin used to live near Chicago... As for PaintWhite, if the background of what's revealed is anything but white, the "flash" can be very distracting. I wouldn't use paintWhite if the Window Manager did "the right thing", i.e. "paint background pattern" rather than "paint white." =Ned Horvath=