mbabramowicz@amherst.bitnet (10/07/90)
Tech Notes seem to say that you can't determine whether or not Multifinder is present. But Font/DA Mover seems to know whether it's present (if it is, it gives you that annoying dialog informing you that fonts/das installed won't really be installed until you start up again.) Does anyone know how it does this or have any other comments about this? Thanks, Michael Abramowicz Amherst College '94
das@Apple.COM (David Shayer) (10/09/90)
In article <10540.270e461f@amherst.bitnet> mbabramowicz@amherst.bitnet writes: >Tech Notes seem to say that you can't determine whether or not Multifinder is >present. But Font/DA Mover seems to know whether it's present (if it is, it >gives you that annoying dialog informing you that fonts/das installed won't >really be installed until you start up again.) Does anyone know how it does >this or have any other comments about this? You probably know the standard answer to this: You don't need to know. Instead, check for the specific feature you need, because in future versions of the OS various features that you associate with MultiFinder may exist without MultiFinder. The Programmers Guide to MultiFinder, available from APDA, tells how to check for each of the individual features you might use. If you simply want to know for academic interest, there are several different (and very easy) ways to check, but I'll leave that as an exercise for the reader. David
ech@cbnewsk.att.com (ned.horvath) (10/10/90)
In article <10540.270e461f@amherst.bitnet> mbabramowicz@amherst.bitnet writes: >Tech Notes seem to say that you can't determine whether or not Multifinder is >present. But Font/DA Mover seems to know... From article <45479@apple.Apple.COM>, by das@Apple.COM (David Shayer): > You probably know the standard answer to this: You don't need to know. > Instead, check for the specific feature you need... And you apparently need the standard rejoinder to this: if Apple programmers have a legitimate need to know (as Font/DA mover needs to know; as the LaserWriter needs to know so that it can selectively highlight the "Background Printing" button; but two ought to suffice), then non-Apple programmers have that very same need to know. The simple example is that I need to know if "Launch" will return or not (the Laserwriter example is a special case of this) so that I know whether or not I can launch a background task. I tried using Gestalt to see if it would help me with the "will Launch return" question. According to IM VI, Gestalt selector 'os ' ought to be just the ticket. But Gestalt returns error -5551 (selector unknown) in system 6.0.x. So much for asking the specific question you need the answer to. > If you simply want to know for academic interest, there are several different > (and very easy) ways to check, but I'll leave that as an exercise for the > reader. Grow up: he asked for help, for a "legit" way to test. If you can provide same, please do so. If not, your "I know, but I won't tell" is merely infuriating. A couple that SHOULD work (no promises): - call SysEnvirons. If the system version is >= $0700, MF is always on. - Use NGetTrapAddress to see if $A88F (OSDispatch) is the same as $A89F (will "always" be unimplemented). If they don't match, MF is running. - Among the first dozen or so events you'd receive from WaitNextEvent there will be a "Resume" event if MF is running. Notice that the last two suggestions may fail with 6.0.6 (the system version for the "new" machines that are being announced 10/15). In fact, any suggestion may fail then, depending on how determined Apple are to protect their monopoly on knowing if MF is running. This is a silly game. Can we stop now? =Ned Horvath=
andyp@treehouse.UUCP (Andy Peterman) (10/10/90)
In article <10540.270e461f@amherst.bitnet> mbabramowicz@amherst.bitnet writes: >Tech Notes seem to say that you can't determine whether or not Multifinder is >present. But Font/DA Mover seems to know whether it's present ... This seems to come up every few months and there always seem to be a multitude of hack answers. Well, here's a way to determine if MF is active that I've been using for 3 years and it continues to work flawlessly! I asked DTS about this method a few years ago and I don't think I ever got a straight answer, which to me means they couldn't find much wrong with it. Here's the C fragment: ... WindowPtr window; Boolean mfActive = TRUE; GetWMgrPort (&window); if (PtrZone ((Ptr)window) == GetZone()) mfActive = FALSE; ... Basically, it determines if the Window Manager port is in the same heap as your application. If it is, then MultiFinder is NOT running. This is basically a legal (i.e. supported) set of tests. Do not use the WM port (window) if MultiFinder is active. Andy Peterman treehouse!andyp@gvgpsa.gvg.tek.com
Greg@AppleLink.apple.com (Greg Marriott) (10/10/90)
In article <1990Oct9.203522.11201@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: > From article <45479@apple.Apple.COM>, by das@Apple.COM (David Shayer): > > You probably know the standard answer to this: You don't need to know. > > Instead, check for the specific feature you need... > > And you apparently need the standard rejoinder to this: if Apple programmers > have a legitimate need to know (as Font/DA mover needs to know; as the > LaserWriter needs to know so that it can selectively highlight the > "Background Printing" button; but two ought to suffice), then non-Apple > programmers have that very same need to know. > ... > depending on how determined Apple are to protect > their monopoly on knowing if MF is running. > > This is a silly game. Can we stop now? > > =Ned Horvath= Can't stop yet... I just have a couple of points to add :) Font/DA Mover, Laserwriter, and MF are System Software. System Software can be as incestuous as it wants. If the methods of implementation of features like MF change, then the rest of sys. software that "peeks" at it will change as well. 3rd party applications aren't afforded the same luxury. If an app takes advantage of implementation details to provide services, it should be willing to handle the consequences of changes in the way features are done. Apple has said (ad. nauseum) that 3rd parties should not check for MF. Actually, what this means is "Check all you want, but we might change it at any moment, so don't screw your users by counting on something that will break you in the future." If you feel the need to check, then be prepared to limit your application to run ONLY on system versions where you a CERTAIN your check is valid. Apple tries really hard not to chnage the way documented calls work. (Honest! :) Even undocumented things undergo a great deal of study before they are changed... But, if DTS says "don't do this" it's for a good reason. We're not protecting "a monopoly on knowing if MF is running", we're trying to protect future systems from architectural limitations based on current implementation details. Greg Marriott Blue Meanie Apple Computer, Inc.
lsr@Apple.COM (Larry Rosenstein) (10/10/90)
ech@cbnewsk.att.com (ned.horvath) writes: >"Background Printing" button; but two ought to suffice), then non-Apple >programmers have that very same need to know. Greg explained why this isn't true. >The simple example is that I need to know if "Launch" will return or not This is acknowledged as something that should be ther ebut is missing. >Grow up: he asked for help, for a "legit" way to test. If you can There is no legit way to test, where "legit" means something that is supported by Apple. On the contrary, DTS has explicitly warned against this. I argue that asking whether MF is presents is almost always the wrong question. In 99% of cases, people want to make the statement that "MF is presents implies xxx about the system"; in those cases, they should be asking if xxx is true. It is true that in some cases there is no way to ask the proper question. The Launch question is known to be missing, and if there are other questions that you want to ask then those should be brought up. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 3-PK Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
ts@cup.portal.com (Tim W Smith) (10/11/90)
Larry Rosenstein asks what questions besides "Will Launch return?" might people have that can not currently be answered without asking if MF is running. Here might be one. Suppose my application runs out of memory. If Finder is running, it wants to say "Out of memory". If MF is running, it wants to see if it is running in a partition that is smaller than the amount of memory not in the System heap, and if so, to tell the user "Out of memory. Try a bigger MF partition". Is this something that is reasonable to want to do? Is there a good way to do this? Tim Smith
gurgle@well.sf.ca.us (Pete Gontier) (10/12/90)
In article <1990Oct9.203522.11201@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: >- Use NGetTrapAddress to see if $A88F (OSDispatch) is the same as $A89F > (will "always" be unimplemented). If they don't match, MF is running. >Notice that the last two suggestions may fail with 6.0.6 (the system version >for the "new" machines that are being announced 10/15). In fact, any >suggestion may fail then, depending on how determined Apple are to protect >their monopoly on knowing if MF is running. I suppose this could be done somehow. But OSDispatch is called by EVERYbody. Finder, Backgrounder, Window Manager (well, the MF version anyway). OSDispatch is a large-scale commitment on Apple's part in terms of engineering. It would simply be too much effort now to back out for a minor revision like 6.0.6. Now, 7.0, that's another matter, but then again, under 7.0, you KNOW MF is running. -- Pete Gontier, gurgle@well.sf.ca.us Software Imagineer, Kiwi Software, Inc.