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