Xref: utzoo comp.sys.mac.programmer:5482 comp.sys.mac:29756
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!brunix!omh
From: omh@brunix (Owen M. Hartnett)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac
Subject: Re: Need some MF help
Keywords: MultiFinder
Message-ID: <3637@brunix.UUCP>
Date: 8 Apr 89 15:52:25 GMT
References: <1562@neoucom.UUCP> <28399@apple.Apple.COM>
Sender: news@brunix.UUCP
Reply-To: omh@zaphod.UUCP (Owen M. Hartnett)
Organization: Brown University Department of Computer Science
Lines: 35

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?
>

[comments deleted]

>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.
>

Why does there have to be a reason?  Why not just put up a flag in Sysenvirons?
Apple DTS always seems to have the attitude that it knows best what 
developers should know about (or rather, not know about).  There may be
developers out there with legitimate need to know - to fix bugs, to implement
a novel feature, or for reasons yet unknown.

If the information is available, and properly documented that there
should be no reasons for using it (that we are currently aware of), then
the programmer will know he has to take the responsibility for using it.

True, some developers will misuse it, but then it's their problem.  Apple
should endeavor to make as much information available as possible, and let
us developers write some "insanely great" applications with it.

-Owen

Owen Hartnett
Brown University Computer Science

omh@cs.brown.edu.CSNET