ldo@peace.waikato.ac.nz (Lawrence D'Oliveiro) (01/22/90)
In <6075@internal.Apple.COM>, chewy@apple.com (Paul Snively) says that checking for the OSDispatch/JugglerDispatch trap "doesn't do anything at all to tell you if you have context-switching or not. Or rather, it does, now, under systems 6 and 7, as far as I know, but will it always? It's hard to tell." Come on Paul, stop hedging! Apple keep telling us that under System 7, MultiFinder will be mandatory--you can't turn it off. Would you say there's a chance Apple will go back on that at some point in the future? Besides, OSDispatch is a documented trap--it's what gives you access to the MultiFinder temporary memory allocation calls. Is there a chance these will actually go away in the future? My guess is, the answer to both these questions is "no". So if you find that OSDispatch is present, then MultiFinder is present. QED. While we're talking about MultiFinder... I think MultiFinder is absolutely wonderful, and I run it all the time. As far as I'm concerned, any piece of software that doesn't like MultiFinder can go straight into the trash. *BUT*... There is *one* nuisance, and that's the way memory management is done. This business of fixed-size application heaps can be greatly annoying with programs that have highly variable memory requirements (that is, some, but not all of them). Having to quit a program and (shock! horror!) *configure* it to use a larger or smaller amount of memory surely goes against everything that the User Interface Guidelines stand for. And I haven't even mentioned fragmentation... However, there is a solution, though it does require developers to do a little more work. *And* it requires you to know whether MultiFinder is actually running. The solution? Under MF, allocate your large or varying-sized objects in the system heap. Under MultiFinder, the system heap will expand as necessary to accommodate the demands that everybody puts on it, provided there's room for it to do so. The nice thing about this technique is that it uses only the existing memory management calls. For example, you can use SetHandleSize and DisposPtr or DisposHandle without having to remember whether you allocated the block on the application or the system heap. And, unlike the MultiFinder memory-allocation calls, you can keep the memory you've allocated for as long as you need it. The simplest way to use this trick is to set TheZone to the appropriate value (ApplZone if MF isn't there, or SysZone if it is) before each of your important calls to NewPtr or NewHandle. Not only is this simpler than putting in alternative calls to NewPtrSys or NewHandleSys (particularly if you're allocating several blocks over a section of code), you can even make the OS and Toolbox allocate their memory in the appropriate heap zone, by setting TheZone before making the OS/Toolbox call. The obvious drawback is that you have to remember to free everything you've allocated before you quit, otherwise that memory is lost until the system is shut down or restarted. Would anybody at Apple like to comment on this technique? Don't tell us "don't do it"--unless you can offer an alternative. Remember, Mac software has traditionally been self-configuring--let's keep it that way! What would be useful is to have some more information on what exactly happens to the system heap under MultiFinder. For example, what conditions could prevent the system heap from expanding? Under what conditions can it shrink again (yes, it does shrink)? That way, we'll know the right way to use this technique. Lawrence D'Oliveiro Mac-hacker-in-residence Computer Services Dept University of Waikato Hamilton New Zealand