Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is multifinder or finder running??
Message-ID: <6176@internal.Apple.COM>
Date: 15 Jan 90 17:35:45 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 89
References:<6075@internal.Apple.COM> <1990Jan13.041909.10943@waikato.ac.nz>

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
> 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?

No; if anything, I'd say that it's more likely that the whole distinction 
will go away--there won't be a separate Finder and MultiFinder anymore.  
What I was really trying to point out, and didn't include enough words to 
do so effectively ;-) was that what OSDispatch really tells you at this 
point is whether you have "MultiFinder" temporary memory calls, and it 
wouldn't be out of the question for us to release a System version that 
had OSDispatch in the System rather than in MultiFinder, in effect similar 
to System 6, which put WaitNextEvent in the System rather than in 
MultiFinder.  That's what I meant; sorry that I wasn't especially clear 
the first time.

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
> 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?

No, but again, where it comes from may change.  The implicit assumption is 
that MultiFinder implements OSDispatch; THAT'S the assumption that seems 
weak to me.  My personal opinion is that the appropriate thing for us at Apple to do would be to implement various Gestalt selectors indicating whether certain important functionality is available: context switching, temporary memory, etc.

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
> My guess is, the answer to both these questions is "no". So if you
> find that OSDispatch is present, then MultiFinder is present. QED.

You're quite correct, given the implicit assumption named above.  If that 
assumption should at any time prove false, you've got problems.

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
> 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...

I agree.

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
[Lots of stuff about using the dynamically-resized System Heap under MF 
deleted]
> 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!

It will solve the problem, but at some cost to the developer (we're trying 
to make MultiFinder comparatively transparent), and with a great deal of 
danger for really nasty bugs, like forgetting to deallocate the stuff in 
the System Heap.  Besides which, the System Heap is called that for a 
reason--it's for stuff that's (at least theoretically) global to the 
entire system, all applications, and so forth.  We'd really prefer to keep 
it that way.  There are obvious performance hits when the System Heap has 
to resize as well, and what are you going to do when the System Heap gets 
big enough that the next time you try to resize it, it fails because it 
can't allocate enough MF free space?  You can't very well install a 
GrowZoneProc in the System Heap!  Basically, the goal is noble but the 
implementation idea is flawed.  And no, we don't have a good alternative.  
After all, for as nice as some of MultiFinder's functionality is, it IS 
very much a Mac OS afterthought; if we had the whole Mac OS to do over 
again, we'd almost certainly have hardware-protected paged dynamic memory 
management and the like, and the problem wouldn't exist.  As it stands, 
well, we do what we do now mostly to avoid breaking as many things as 
possible.

In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz 
(Lawrence D'Oliveiro) writes:
> 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.

There is no right way, and the reason that kind of information isn't 
available is that it may change from one version of MultiFinder to another.


__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________