Path: utzoo!attcan!uunet!husc6!mailrus!ames!amdahl!nsc!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 6.0 breaks my cdevs! revisited
Message-ID: <12523@apple.Apple.COM>
Date: 20 Jun 88 18:19:53 GMT
References: <227@hodge.UUCP>
Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 34

In article <227@hodge.UUCP> thecloud@pnet06.cts.com (Ken Mcleod) writes:
>
> Then there's the MultiFinder test. Most sample source code I've seen
>(actually, ALL) checks for MultiFinder's presence by testing to see
>whether the WaitNextEvent trap is implemented. Now, in System 6.0,
>it's implemented ALL THE TIME, whether you're in MF or not. So if
>application X assumes it's running under MultiFinder when it isn't,
>well, look out.

You must not have looked at the sample code in the Tech Notes.  The Tech
Notes on MultiFinder have been very clear that you cannot test for the
existence of MultiFinder by looking for the WaitNextEvent trap.  As you
discovered, WaitNextEvent is always installed under System 6.0.

> Question: how do you detect MultiFinder's presence or absence under 6.0?

The question is what about MultiFinder do you want to know.  Apple does not
want people writing code that depends on MultiFinder being present or
absent, since future systems might migrate some MultiFinder features into a
non-MultiFinder environment (as with WaitNextEvent).  

So far, it is only possible to test for 2 particular MultiFinder-related
services: WaitNextEvent and temporary memory allocation.

I have heard from people who want to know whether or not the Launch trap can
return to the caller.  That is a valid request, and I believe Tech Support
is looking into a solution.  


-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr