Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!gatech!ncar!ames!pasteur!ucbvax!decwrl!nsc!voder!apple!tecot
From: tecot@apple.UUCP
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is MultiFinder running  [was Re: System 6.0 breaks my cdevs! revisited]
Message-ID: <13829@apple.Apple.COM>
Date: 13 Jul 88 01:14:59 GMT
References: <227@hodge.UUCP> <3988@pasteur.Berkeley.Edu> <5212@batcomputer.tn.cornell.edu> <46753DN5@PSUVM>
Reply-To: tecot@apple.apple.com.UUCP (Ed Tecot)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 23

In article <46753DN5@PSUVM> DN5@PSUVM.BITNET (D. Jay Newman) writes:
>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.

I'd like to correct a misconception.  You are either running under MultiFinder
OR the classic single-tasking OS.  The Finder is an APPLICATION, just like
MacWrite.

>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...

The reason this isn't done is because it would cost over 4K of system heap
space.

						_emt