Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!ukma!widener!netnews.upenn.edu!king.mcs.drexel.edu!ujmurphy
From: ujmurphy@mcs.drexel.edu (Jim Murphy)
Newsgroups: comp.sys.apple2
Subject: MultiFinder IIGS (I hope) Miscellania
Message-ID: <1991Apr5.052529.9974@mcs.drexel.edu>
Date: 5 Apr 91 05:25:29 GMT
Distribution: all
Organization: Drexel University, Dept. of Math. and Comp. Sci.
Lines: 52


     Well, let me throw my $0.02 into the MultiFinder IIGS discussion. First
off, I speak with some experience, since I've written the core of a context-
switching system for my IIGS. I've been playing with the idea of MultiFinder 
IIGS since about '87. I've had my version running (well, let's call it walking
- It's not perfect, by a long shot) since Christmas of 1988. It's been an 
extremely interesting learning process, but I've just not had the time and the
resources to make it what a MultiFinder should be. I've been doing unavoidable
things - like school, work, and foremost, sleep.

     Anyway, the point that Todd Whitesel brought up concerning Close with 
refNum zero has come to me, but I haven't put it way up there on the priority
list. Heck, up until Apple documented 'internal file level' in a recent GS/OS 
Technote, DAs have been able to have their files nuked at any moment under the
official system software. Yes, the chances of it happening to DAs are much
less likely than in a multi-application environment. It is a sticky wicket,
but it's one that can be fixed without too much pain.

     Other items lurking around the corner are such things as handling
HeartBeats, the RunQ, application patches to toolsets, arbitration of user
tool sets, binding of interrupts to the various vectors, notification queue
routines, and more. An application switcher or MF has quite a large context
that it needs to worry about to keep applications insulated from each other.
Without careful management of these things, applications can stomp all over
each other. From what I've seen, that's not a real pretty sight.

     All of this requires the systematic patching of all of the involved tool
calls. In my experiments it requires over 70 patches to get even a basic
switching system going. This doesn't even include any of the items I presented
in the last paragraph. So, what am I getting at? Well, in my humble opinion,
the group best suited to doing something like this is Andy and company. Since
they are the ones responsible for our most cherished system software, they
have the inside track on getting something like this working properly. I 
believe in the French group (well, not _every_ feature. Multiprocessing? Since
when?) but I have a want for the "real" thing from Apple. Andy did say we'd be
extremely pleased with the next Finder dodn't he? Hmmm...

     My only regret in this manner is the double standard that is Apple's
credo. When did the world learn of the impending features in mac System 7.0? 
May of 1989? If only the II world could have knowledge and into what is
really going on with our system software, we could _really_ shape our little
world's direction. Sigh. Then again, dumping suggestions on them doesn't seem
to hurt. Right Andy, Dave?

     Well, my $0.02 in the meter has run out. Catch you later.


Jim Murphy                                  Internet: ujmurphy@mcs.drexel.edu
CoOp - Software Quality Assurance           GEnie:    J.MURPHY7
Reality Technologies, Inc.

- My opinions are mine, all mine, all mine, all mine, all mine...I think. -