Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Is multifinder or finder running?? Message-ID: <9190@hoptoad.uucp> Date: 5 Dec 89 05:02:19 GMT References: <17708@ea.ecn.purdue.edu> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 32 In article <17708@ea.ecn.purdue.edu> moyman@ee.ecn.purdue.edu (James M Moya) writes: >How do you determine (if possible) whether finder or multifinder is running >from within an application?? The official line is that there isn't a way, but this isn't true. Still, make sure that you really need to do this; don't do it lightly. Here's how. First, if the system is 7.0 or higher, then MultiFinder is running; MultiFinder is always running on system 7.0 or higher. You find out what system is running by calling SysEnvirons. Second, if the system is 6.0.x, then MultiFinder may or may not be running; check it by seeing whether the last entry in the Apple menu is "About MultiFinder..." This may change on future systems, but not in 6.0.x, so this is safe. Third, if the system is less than 6.0, then check to see if WaitNextEvent's trap address is the same as the address of the unimplemented trap. If it is, MultiFinder is not running, otherwise it is. Step 2 might possibly be done better by checking to see if the temporary memory allocation calls are present, but I'm not absolutely sure that they aren't available under Finder in 6.0 (pretty sure, but not completely), and I don't feel like rebooting twice to find out. You can check this yourself. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Now hear a plain fact: Swedenborg has not written one new truth: Now hear another: he has written all the old falshoods. And now hear the reason. He conversed with Angels who are all religious, & conversed not with Devils who all hate religion..." - Blake, "The Marriage of Heaven and Hell"