Path: utzoo!attcan!uunet!pyrdc!pyrnj!esquire!sbb
From: sbb@esquire.UUCP (Stephen B. Baumgarten)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is MultiFinder running  [was Re: System 6.0 breaks my cdevs! revisited]
Message-ID: <480@esquire.UUCP>
Date: 13 Jul 88 13:46:49 GMT
References: <227@hodge.UUCP> <3988@pasteur.Berkeley.Edu> <5212@batcomputer.tn.cornell.edu> <46753DN5@PSUVM> <13829@apple.Apple.COM> <478@esquire.UUCP>
Reply-To: sbb@esquire.UUCP (Stephen B. Baumgarten)
Organization: DP&W, New York, NY
Lines: 27

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

4k?  Is this a typo or have you guys totally lost it?  By not backpatching,
each application that wants to support both color and b/w has dozens of
duplicated calls, making programming difficult and applications grow in 
size.  The code for handling color is always going to have to be there;
why force applications to carry around the extra baggage of code that will
never get used on a Plus/SE (or vice versa)?

-- 
   Steve Baumgarten             | "New York... when civilization falls apart,
   Davis Polk & Wardwell        |  remember, we were way ahead of you."
   {uunet,cmcl2}!esquire!sbb    |                           - David Letterman