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