Xref: utzoo comp.sys.mac.programmer:5398 comp.sys.mac:29625
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!husc6!xait!dee
From: dee@XAIT.Xerox.COM (Donald Eastlake)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac
Subject: Re: Need some MF help
Keywords: MultiFinder
Message-ID: <43464@XAIT.Xerox.COM>
Date: 6 Apr 89 17:49:10 GMT
References: <1562@neoucom.UUCP> <28399@apple.Apple.COM>
Reply-To: dee@XAIT.Xerox.COM (Donald Eastlake)
Distribution: na
Organization: Transfinite Systems Company, Cambridge, MA
Lines: 45

In article <28399@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes:
>In article <1562@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes:
>>Firstly,  what is the standard way of checking for MultiFinder
>>existence?
>There currently is no way to determine if MultiFinder is running, but that's
>mostly because we haven't seen a need for this. ...
>If you do have a valid reason for needing to know if MultiFinder is running,
>please let me know! So far it's been a battle, with developers saying "We need
>to know!" and Apple saying "No you don't!". Finding a legitimate reason for
>knowing would put an end to this contest.

The way I try to guess if MultiFinder is running is by checking for the
temporary memory assignment traps.  The reason I want to know is that I
dynamicly generate windows in my application with stepped locations and
I don't want to cover the volume, etc., Icons that MF likes to put down
the right edge of the screen.  I also have a "cover sheet" feature to
cover all of my windows after some period of user inactivity.  For
convenience I also contrain it from the right edge under MultiFinder.

I suspect that 90%+ of large real applications and a significant
proportion of smaller programs check for MF one way or the other.  Many
of them may not need to but quite a few have arguably good reasons to do
so.  By refusing to authorize a way to do this, Apple is guaranteeing
problems for these applications in the future.  In fact, if the goal of
Apple is to make it easy to generate programs that will be compatible
into the future an authorized way to meet a purely psychological need
to know if MF is present seems reasonable to me.  Sometimes you should
assume the customer is right even if you think you know better.  It has
always been easy to find out if Switcher is present and I don't know
of that every causing any particular problems.

While I am sending this message, I'd like to put in my vote for a couple
of new traps:
	TrapExist ( trapnumber ) or the like would do the obvious thing
with get trap addresses and the guaranteed undefined trap returning a
Boolean.  Why make everyone do it the hard way?  And glue could check
the ROM version...
	ApplicationTrap ( ... ); this trap would be guaranteed to never
be used by Apple but the application would have license to patch it.  Sort
of like ApplScratch but in the trap number space.

-- 
	+1 617-969-9570		Donald E. Eastlake, III
	ARPA: dee@XAIT.Xerox.COM    usenet:  {cbosg,decvax,linus}!cca!dee
	P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA