Path: utzoo!attcan!uunet!husc6!ukma!psuvm.bitnet!dn5
From: DN5@PSUVM.BITNET (D. Jay Newman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is MultiFinder running  [was Re: System 6.0 breaks my cdevs! revisited]
Message-ID: <46753DN5@PSUVM>
Date: 1 Jul 88 12:53:52 GMT
References: <227@hodge.UUCP> <3988@pasteur.Berkeley.Edu> <5212@batcomputer.tn.cornell.edu>
Organization: The Pennsylvania State University - Computation Center
Lines: 24

Actually, I was glad when they made WaitNextEvent a standard system trap, but
I wish they had made many of the other multi-finder calls available.  The
most important (from my point of view) is the temporary memory allocation
calls.  Under unifinder, they would just revert to standard memory allocation,
but under multifinder, they would grab from wherever multifinder gets them
from (system heap?).

I feel that WaitNextEvent and the temp memory calls are the most important
calls available, and I shouldn't have to write large sections of code twice,
depending on which finder I am running under.

Another thing, I would like to see the Color Quickdraw code patched for the
Plus/SE machines, so that the color calls would revert to the basic b/w calls.
This can't be too hard, can it?  Again, why write twice the code so that the
user can have optional color (I thought that the Mac Interface Guidelines
tried to let the user have as much information and convinience as possible,
and I interpret that to mean that if color can be useful, and color is
available, give him color--if color isn't available, then use b/w).  Apple
seams to be making this hard right now.  Maybe later, when we all have
68020 machines, with color monitors, then this won't matter, but for now...

                                  Jay, etc...
ps.
   I LIKE black and white!