moyman@ea.ecn.purdue.edu (James M Moya) (11/30/89)
How do you determine (if possible) whether finder or multifinder is running from within an application?? Please reply directly to me, I will post composite if necessary...thankin' --moya Mike Moya Software Specialist ...!pur-ee!moyman Engineering Computer Network moyman@coral.ecn.purdue.edu Purdue University (317) 494-2349
chewy@apple.com (Paul Snively) (11/30/89)
In article <17708@ea.ecn.purdue.edu> moyman@ea.ecn.purdue.edu (James M Moya) writes: > How do you determine (if possible) whether finder or multifinder is running > from within an application?? This is a popular one here in DTS, so here goes, hopefully for the benefit of all: First, consider what it is that you really want to know. Do you want to know if you have MultiFinder's temporary memory capabilities around? Do you want to know whether you have _WaitNextEvent as opposed to _GetNextEvent? In other words, please try to check for a specific piece of functionality, rather than trying to globally determine whether MultiFinder is around or not. Part of the problem is that there is no supported way to know whether MultiFinder is around or not. Since most of MultiFinder's functionality, from a programmatical perspective, exists in the _OSDispatch trap, USUALLY the best thing to do is to check to see if _OSDispatch is implemented or not. Hope this helps! __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
xdaa374@ut-emx.UUCP (Vance Strickland) (11/30/89)
In article <5499@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >First, consider what it is that you really want to know. Do you want to >know if you have MultiFinder's temporary memory capabilities around? Do >you want to know whether you have _WaitNextEvent as opposed to >_GetNextEvent? I would like to chack for the presence for task swapping: specifically, I'd like to avoid running when the user has the ability to switch from one application to another. Unfortunately, I'm working w/ XCMDs within a commercial application, & I cannot simple change the application to avoid swapping. Is there any test for determining whether or not the user can do context switches? Thx. -- Bill Douglass, TCADA "I dreamed I was to take a test, in a Dairy Queen, on another planet." L. Anderson
lsr@Apple.COM (Larry Rosenstein) (12/02/89)
In article <21640@ut-emx.UUCP> xdaa374@ut-emx.UUCP (Vance Strickland) writes: > I would like to chack for the presence for task swapping: specifically, I'd > like to avoid running when the user has the ability to switch from one This seems equivalent to the question "Does a sublaunch return to the caller?" (Under MultiFinder, if you sublaunch a program, your application does not quit.) The Tech Notes explain that this is a valid question, for which there is currently no explicit answer. (In the future there may be a way to detect this.) I think the best suggestion is to check for the presence of the _OSDispatch trap, and if it exists assume that task switching is present. Unfortunately, this isn't guaranteed to be true in the future; for example, a future system might provide the MultiFinder memory calls all the time. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
tim@hoptoad.uucp (Tim Maroney) (12/05/89)
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"
earleh@eleazar.dartmouth.edu (Earle R. Horton) (12/05/89)
In article <9190@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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..." The last check won't do much for you if the last item in the Apple menu is "A-propos de MultiFinder," "Uber den MultiFinder," or something in Kanji, Devanagari, Urdu, Hebrew, Arabic, Tamil, Icelandic, Spanish, ... Someone also mentioned looking for the next to the last Apple menu item being a grey line, but that won't work either if there is just one desk accessory installed. You cannot get this information from the Apple menu. Earle R. Horton
chewy@apple.com (Paul Snively) (12/06/89)
In article <17695@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > In article <9190@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >In article <17708@ea.ecn.purdue.edu> moyman@ee.ecn.purdue.edu (James M Moya) > >writes: [Several generations of "how to detect MultiFinder" removed...] Probably the best way, UNDER SYSTEM 6.0.x, to determine whether MultiFinder is present or not is to check to see if the System Heap and the "Application Heap" are contiguous. That is, get the SysZone, add the ZoneLimit, and check to see if you wind up butting up against ApplZone. If you do ,MultiFinder ain't around. If you don't, MultiFinder is around (under 6.0.x, some of MultiFinder's code winds up lying BETWEEN the System and Application heaps). Hope this helps. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
tim@hoptoad.uucp (Tim Maroney) (12/11/89)
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?? >In article <9190@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>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..." In article <17695@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >The last check won't do much for you if the last item in the Apple >menu is "A-propos de MultiFinder," "Uber den MultiFinder," or >something in Kanji, Devanagari, Urdu, Hebrew, Arabic, Tamil, >Icelandic, Spanish, ... Sure it will. I hope you aren't running around embedding string constants in your code! At the time when you update all the STR# and STR resources for the new language, you would also change the string for "About MultiFinder..." >You cannot get this information from the Apple menu. Sure you can, if you're programming your strings correctly. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The above opinions and suggestions have absolutely nothing to do with the little fat man putting crisp $100 bills in my pocket." -- Alan Vymetalik
jmunkki@kampi.hut.fi (Juri Munkki) (12/11/89)
In article <9247@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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..." > >In article <17695@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu >(Earle R. Horton) writes: >>The last check won't do much for you if the last item in the Apple >>menu is "A-propos de MultiFinder," "Uber den MultiFinder," or > >Sure it will. I hope you aren't running around embedding string >constants in your code! At the time when you update all the STR# and >STR resources for the new language, you would also change the string >for "About MultiFinder..." Oh... I guess I'm running programs like Ajatus-C instead of Think-C and the Finnish version of SimCity? The truth is that most programs are not translated to all these languages. I already have make too many changes to existing programs in order for them to work with our itl and INTL resources. In fact, I'm using an Australian system because some programmers are trying to follow the guidelines, but only manage to create programs that either crash or go crazy when they are used with a foreign system. (Think C and SimCity both behave ok with a Finnish system: I just used them as examples of programs that I use in their English versions.) Of course I'm happy if you keep all your strings and graphics (and anything language-dependent) in resources. I also hope that you supply templates for any custom resource types that might also need translation... What I don't want is you to start requiring me to change strings every time I move a program from my Australian system Mac II to the Finnish system in our Mac IIx. Come on... finding out if you are under multifinder is simple. Just assume that you aren't running under MF until you get your first suspend or resume event! Most users will be happy with this approach and it will probably never break. Also remember that MultiFinder is just an extension of desk accessories. If you intend to be MF friendly, it's probably quite close to being DA friendly. Another possible way to find out if MF is running (this might break in the future) is to see where fonts and stuff like that loads. Depending on what a menu looks like is a bad idea. Depending on a programming interface is not much better, but at least it tends to be more stable than the user interface (especially, if you consider international systems). _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
earleh@eleazar.dartmouth.edu (Earle R. Horton) (12/11/89)
In article <9247@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: ... >>In article <9190@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>>... 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..." > >In article <17695@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu >(Earle R. Horton) writes: >>The last check won't do much for you if the last item in the Apple >>menu is "A-propos de MultiFinder," "Uber den MultiFinder," or... > >Sure it will. I hope you aren't running around embedding string >constants in your code! At the time when you update all the STR# and >STR resources for the new language, you would also change the string >for "About MultiFinder..." > >>You cannot get this information from the Apple menu. > >Sure you can, if you're programming your strings correctly. Well meant, but bad advice. Even if your application is properly localized for all the international systems in existence, you have no guarantee that your customers will use the same international version of your program as they do System Tools. There are also users who insist on more customization than this, and who even modify the Finder menus to contain humorous messages not intended by the system designers at Apple! (I have never done this. :-)) Such a user is well within her rights to modify the "About MultiFinder..." message without sending notification to all software developers from whom she might purchase products. Looking at something in the user interface to determine what system features are present is almost as bad as asking the user directly, and should be avoided. Use one of the undocumented programmatic interface tricks discussed here, instead. Better yet, write programs that are compatible with all system configurations! Earle R. Horton
d88-jwa@nada.kth.se (Jon Watte) (12/12/89)
In article <9247@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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 last check won't do much for you if the last item in the Apple >>menu is "A-propos de MultiFinder," "Uber den MultiFinder," or >Sure it will. I hope you aren't running around embedding string >constants in your code! At the time when you update all the STR# and Well, up to system 6.x, the second-to-last apple menu item is a gray line. From system 7 and up, you're running MF. Period. (Or, you might check for the precense of icons in any of the Apple menu's items, or for the name "Finder" when CurApName != Finder, or for the number of gray lines being >2 or...) Happy hacking ! Apple doesn't support this, of course :-) h+@nada.kth.se -- -- Stay alert ! - Trust noone ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
silverio@brahms.berkeley.edu (C J Silverio) (12/12/89)
This whole train of thought is veering rapidly in the direction of the absurd. I think the original theory was, "since there is absolutely no RIGHT way to tell if MultiFinder is running (which is a shame for the few applications that absolutely need it), here is a SIMPLE way." Obviously, if one wanted to be very clever, one could merely compare the last Apple-menu item against the 30 or so strings that comprise the Apple International System strings. One could then simply allow the user to tack on whatever strings his or her little heart desires. But this begs a further question: Did I miss something, or isn't there a RIGHT and OFFICIAL way (I presume through the use of SysEnvirons) to tell which International System an app is running under? Wouldn't this be nice? Then one could ship a really international version of the program that automatically (if possible) come up in whatever language was appropriate. Too much disk space? Pish and poddle! I'll betcha people like it.
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (12/12/89)
In article <1989Dec11.172400.25746@agate.berkeley.edu> silverio@brahms.berkeley.edu.UUCP (C J Silverio) writes: >Wouldn't this be nice? Then one could ship a really international >version of the program that automatically (if possible) come up in >whatever language was appropriate. Too much disk space? Pish and >poddle! I'll betcha people like it. I'm afraid most people wouldn't even care. Macs are expensive overseas, and while I don't have the exact numbers, I think American macs outnumber foreign macs by quite a bit (correct me if I'm wrong.) For big dog programs, this might be a viable option (things like Word, PageMaker, etc.) but you would have to do a lot more than just change the menu names for these programs. Imagine PageMaker in Japanese. Perhaps all this will be easier when the line layout manager gets here. So for these big programs, a) there are possibly major differences in code between different versions b) they are going to have to do different packaging for the things anyway. Besides. Word is buggy enough without sticking more code onto it. -Sho -- sho@physics.purdue.edu <<-- betcha didn't think anyone was going to comment on that, did you? oh, the bandwidth i waste.
andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) (12/12/89)
ARGH!!!! I can't stand it anymore. Here's method of determining if
MultiFinder is running (in C):
WindowPtr deskTop; /* usable if mfActive is false */
Boolean mfActive; /* true if MultiFinder is running */
GetWMgrPort (&deskTop);
mfActive = (PtrZone ((Ptr)deskTop) == GetZone());
As long as the the call GetWMgrPort works (which Apple has said not to
use because "its going away") this will determine if MultiFinder is
active. It uses the assumption that if the Window Manager's Port is in
your heap, then MultiFinder must not be running (since when it is
running, it has control of it). This has worked for me since long
before MultiFinder was released and has not presented any problems yet.
It may even continue to work under System 7.0 (which is always
MultiFinder) if the GetWMgrPort continues to work.
Andy Peterman
andyp@gvgpvd.gvg.tek.comstores@unix.SRI.COM (Matt Mora) (12/13/89)
In article <1451@gvgpvd.GVG.TEK.COM> andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) writes: >ARGH!!!! I can't stand it anymore. Here's method of determining if >MultiFinder is running (in C): > > WindowPtr deskTop; /* usable if mfActive is false */ > Boolean mfActive; /* true if MultiFinder is running */ > > GetWMgrPort (&deskTop); > mfActive = (PtrZone ((Ptr)deskTop) == GetZone()); > >Andy Peterman >andyp@gvgpvd.gvg.tek.com Here's another way (qouted from John Norstad article # 48669) "When using Disinfectant to repair WDEF infections, you must use Finder instead of MultiFinder. Under MultiFinder the Desktop files are always Rbusy,S and Disinfectant is not able to repair them. If you try to repair using MultiFinder, you will get an error message." Check the desktop file and see if its busy :-) -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
tim@hoptoad.uucp (Tim Maroney) (12/13/89)
In article <1989Dec11.172400.25746@agate.berkeley.edu> silverio@brahms.berkeley.edu.UUCP (C J Silverio) writes: >This whole train of thought is veering rapidly in the direction of the >absurd. I think the original theory was, "since there is absolutely no >RIGHT way to tell if MultiFinder is running (which is a shame for the >few applications that absolutely need it), here is a SIMPLE way." Another point, which should have been made earlier, is that MultiFinder incompatibility is simply not acceptable for production software. I took the original message as meaning that a program was in development and had not yet been made MultiFinder compatible, and the check for MultiFinder's presence was to be made solely to prevent inadvertant system crashes among people using development versions. All this stuff about international usage is beside the point, since no development version with flaws this serious should be propagated beyond the local site. >Obviously, if one wanted to be very clever, one could merely compare >the last Apple-menu item against the 30 or so strings that comprise >the Apple International System strings. One could then simply allow >the user to tack on whatever strings his or her little heart desires. One could instead search the menu for an item corresponding to the name of the application, gotten from a PBGetFCBInfo on the application resource file descriptor. This would work regardless of internationalization or user reconfiguration. >But this begs a further question: Did I miss something, or isn't there >a RIGHT and OFFICIAL way (I presume through the use of SysEnvirons) to >tell which International System an app is running under? There is, but I don't know of an easy one; much of the Script Manager documentation is opaque to me, and I believe the fault is in the quality of the documentation, not in my reading abilities. In any case, the way seems to be to call GetSysFont and compare it numerically to the fixed international ranges. >Wouldn't this be nice? Then one could ship a really international >version of the program that automatically (if possible) come up in >whatever language was appropriate. Too much disk space? Pish and >poddle! I'll betcha people like it. I think this idea should be discussed by the group; it's a good one. (I imagine most of us have toyed with the idea already at some time or other.) First, the disk space issues are not as trivial as you seem to think. It would involve a virtual duplication of most of the resource fork, excluding code resources; a 250K application with resources for ten languages could easily become well over a megabyte and a half. This is not acceptable. However, if you *were* going to do it this way, perhaps for a small program, it seems likely you would use an anlogy to the "resource base" idea already used for desk accessories. All accesses to possibly internationalizable resources (which includes MENUs, STRs, STR#s, DLOGs, DITLs, WINDs, CNTLs, FONTs, FONDs, etc.) would not be by means of direct resource id, as in most current applications, but relative to a resource base id determined by the language code. Each resource would have an id consisting of the relative id plus the resource base id. The base id would be stored in a global and computed at application startup. This involves a nontrivial, but not enormous, amount of programmer work. The alternative is to give each country's resources the same ids, and to customize the application by putting an external resource file into the same folder as the application. The application would contain in itself the default resources (those for the language of its origin, usually American English), but if it detected a different language code on application startup, it would open the appropriate international resource file. Because of the way resource search paths work, these resources would override the defaults automatically, provided the application kept the resource search path including the international resources file. This way, no one would have to have hundreds of K of unwanted resources, but the application could be distributed with all necessary resource files for running in many countries. Rather than separate applications for each language, each language would have only a single resource file which must sit by the side of the application. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Mere opinion without supporting argument is no more than the American Bandstand school of literary evaluation." -- Tom Maddox
keith@Apple.COM (Keith Rollin) (12/13/89)
In article <1451@gvgpvd.GVG.TEK.COM> andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) writes: > >As long as the the call GetWMgrPort works (which Apple has said not to >use because "its going away") ... What reference are you quoting? I don't think that Apple's ever said anything like this. The closest we've come is in discouraging people from writing directly to the window manager port, as that will cause problems in shared environments. That is the thrust of Technote #194. I don't think we've said that"it's going away". -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
macman@ethz.UUCP (Danny Schwendener) (12/14/89)
>>The last check won't do much for you if the last item in the Apple >>menu is "A-propos de MultiFinder," "Uber den MultiFinder," or >>something in Kanji, Devanagari, Urdu, Hebrew, Arabic, Tamil, >>Icelandic, Spanish, ... > >Sure it will. I hope you aren't running around embedding string >constants in your code! At the time when you update all the STR# and >STR resources for the new language, you would also change the string >for "About MultiFinder..." No, no, no! Don't ever assume that people use the local language for all their applications *and* the Finder environment. This is almost never the case. Most of the time, companies take months if not years to publish a localised version of their software. This has the unfortunate effect that international customers have to take what is available, even if it isn't localised. Also, don't forget that several countries are multilingual. Switzerland, with four languages (plus english) is a good example. Many people here don't mind to use a german System with a french word processing program, and they get *very* confused if their application doesn't behave the same way if they use a french System instead. +-----------------------------------------------------------------------+ | Danny Schwendener, Apple Developer Services Switzerland | | AppleLink: danny.s UUCP : {cernvax,mcvax}ethz!macman | | Internet: macman@ifi.ethz.ch Voice : yodel three times | +-----------------------------------------------------------------------+ DISCLAIMER: These are my very own opinions. Leave my employer alone.
andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) (12/15/89)
In article <37225@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1451@gvgpvd.GVG.TEK.COM> andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) writes: >> >>As long as the the call GetWMgrPort works (which Apple has said not to >>use because "its going away") ... > >What reference are you quoting? I don't think that Apple's ever said anything >like this. The closest we've come is in discouraging people from writing >directly to the window manager port, as that will cause problems in shared >environments. That is the thrust of Technote #194. I don't think we've said >that"it's going away". I just re-read the MultiFinder Guide and the Tech Note and must agree that Apple does not mention that GetWMgrPort is going away, and in fact seems to admit that it will be around for a while, although strongly discourages its use. However, I do remember quite a while ago (perhaps in some old Juggler documentation) the comment that it would be going away. Andy Peterman
t-jlee@microsoft.UUCP (Johnny Lee) (12/15/89)
In article <6785@unix.SRI.COM> stores@unix.UUCP (Matt Mora) writes: >In article <1451@gvgpvd.GVG.TEK.COM> andyp@gvgpvd.GVG.TEK.COM (Andy Peterman) writes: >>ARGH!!!! I can't stand it anymore. Here's method of determining if [Stuff Deleted about checking if Window Manager port is in current heap] > >Here's another way >(qouted from John Norstad article # 48669) > >"When using Disinfectant to repair WDEF infections, you >must use Finder instead of MultiFinder. Under MultiFinder >the Desktop files are always Rbusy,S and Disinfectant is >not able to repair them. If you try to repair using >MultiFinder, you will get an error message." > >Check the desktop file and see if its busy :-) This will work in most cases since most people don't get too sneaky with MultiFinder. But when I used to have a lowly 1 MB of RAM and was trying to port Nethack 3 (not fun!), in order to use the Lightspeed C/ Think C debugger (which has to be run under Multifinder) I used to quit out of the Finder to get more memory. (Try typing 'es' from your favourite ML debugger when the CurApName is Finder or setup an FKEY to do an ExitToShell() for you). So this method of checking for MultiFinder wouldn't work since the Finder would be closed and the Desktop file along with it. I guess this would also be one way to use Disinfectant under MF. When you quit out of the last app running you're usually returned to the Finder (it's always worked for me). Johnny Lee t-jlee@microsoft.UUCP ...!{uunet, uw-beaver, sun}!microsoft!t-jlee
tecot@Apple.COM (Ed Tecot) (12/16/89)
In article <6785@unix.SRI.COM> stores@unix.UUCP (Matt Mora) writes: >Here's another way >(qouted from John Norstad article # 48669) > >"When using Disinfectant to repair WDEF infections, you >must use Finder instead of MultiFinder. Under MultiFinder >the Desktop files are always Rbusy,S and Disinfectant is >not able to repair them. If you try to repair using >MultiFinder, you will get an error message." > >Check the desktop file and see if its busy :-) If you're using the Desktop Manager, there won't be a "Desktop" file. _emt
dee@XAIT.Xerox.COM (Donald Eastlake) (12/22/89)
To get back to the original question, almost everyone (including
myself) has suggested relatively complex methods (digging around in
the apple menu) or multi step methods (first, is system 7 running,
if not then test...); however, the more I think about it the more
it seems like just testing for _OSDispatch should do it. That
certainly works for systems pre-7 and _OSDispatch is hardly likely
to go away in system 7. Testing for the existance of a trap is
even a recommended technique (in general) by Apple. Anyone see a
problem with this?
--
+1 617-969-9570 Donald E. Eastlake, III
ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee
AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USAzben@umd5.umd.edu (Ben Cranston) (01/09/90)
In article <51508@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: > To get back to the original question, almost everyone (including > myself) has suggested relatively complex methods (digging around in > the apple menu) or multi step methods (first, is system 7 running, > if not then test...); however, the more I think about it the more > it seems like just testing for _OSDispatch should do it. That > certainly works for systems pre-7 and _OSDispatch is hardly likely > to go away in system 7. Testing for the existance of a trap is > even a recommended technique (in general) by Apple. Anyone see a > problem with this? Anyone see a problem with just testing the long at $282 for being negative? -- Sig DS.L ('ZBen') ; Ben Cranston <zben@Trantor.UMD.EDU> * Network Infrastructures Group, Computer Science Center * University of Maryland at College Park * of Ulm
chewy@apple.com (Paul Snively) (01/09/90)
In article <5897@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: > In article <51508@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: > > > To get back to the original question, almost everyone (including > > myself) has suggested relatively complex methods (digging around in > > the apple menu) or multi step methods (first, is system 7 running, > > if not then test...); however, the more I think about it the more > > it seems like just testing for _OSDispatch should do it. That > > certainly works for systems pre-7 and _OSDispatch is hardly likely > > to go away in system 7. Testing for the existance of a trap is > > even a recommended technique (in general) by Apple. Anyone see a > > problem with this? No, but it doesn't do anything at all to tell you if you have context-switching or not. Or rather, it does, now, under systems 6 and 7, as far as I know, but will it always? It's hard to tell. In article <5897@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: > Anyone see a problem with just testing the long at $282 for being negative? Yes! Don't check low-RAM globals; some of 'em don't even exist under A/UX, and we're trying to get to the point where we have a procedural interface to everything down there anyway; ya never know when that stuff's gonna change or possibly go away for some reason (supervisor exceptions under VM, anyone)? __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
ldo@waikato.ac.nz (Lawrence D'Oliveiro) (01/13/90)
In <6075@internal.Apple.COM>, chewy@apple.com (Paul Snively) says that checking for the OSDispatch/JugglerDispatch trap "doesn't do anything at all to tell you if you have context-switching or not. Or rather, it does, now, under systems 6 and 7, as far as I know, but will it always? It's hard to tell." Come on Paul, stop hedging! Apple keep telling us that under System 7, MultiFinder will be mandatory--you can't turn it off. Would you say there's a chance Apple will go back on that at some point in the future? Besides, OSDispatch is a documented trap--it's what gives you access to the MultiFinder temporary memory allocation calls. Is there a chance these will actually go away in the future? My guess is, the answer to both these questions is "no". So if you find that OSDispatch is present, then MultiFinder is present. QED. While we're talking about MultiFinder... I think MultiFinder is absolutely wonderful, and I run it all the time. As far as I'm concerned, any piece of software that doesn't like MultiFinder can go straight into the trash. *BUT*... There is *one* nuisance, and that's the way memory management is done. This business of fixed-size application heaps can be greatly annoying with programs that have highly variable memory requirements (that is, some, but not all of them). Having to quit a program and (shock! horror!) *configure* it to use a larger or smaller amount of memory surely goes against everything that the User Interface Guidelines stand for. And I haven't even mentioned fragmentation... However, there is a solution, though it does require developers to do a little more work. *And* it requires you to know whether MultiFinder is actually running. The solution? Under MF, allocate your large or varying-sized objects in the system heap. Under MultiFinder, the system heap will expand as necessary to accommodate the demands that everybody puts on it, provided there's room for it to do so. The nice thing about this technique is that it uses only the existing memory management calls. For example, you can use SetHandleSize and DisposPtr or DisposHandle without having to remember whether you allocated the block on the application or the system heap. And, unlike the MultiFinder memory-allocation calls, you can keep the memory you've allocated for as long as you need it. The simplest way to use this trick is to set TheZone to the appropriate value (ApplZone if MF isn't there, or SysZone if it is) before each of your important calls to NewPtr or NewHandle. Not only is this simpler than putting in alternative calls to NewPtrSys or NewHandleSys (particularly if you're allocating several blocks over a section of code), you can even make the OS and Toolbox allocate their memory in the appropriate heap zone, by setting TheZone before making the OS/Toolbox call. The obvious drawback is that you have to remember to free everything you've allocated before you quit, otherwise that memory is lost until the system is shut down or restarted. Would anybody at Apple like to comment on this technique? Don't tell us "don't do it"--unless you can offer an alternative. Remember, Mac software has traditionally been self-configuring--let's keep it that way! What would be useful is to have some more information on what exactly happens to the system heap under MultiFinder. For example, what conditions could prevent the system heap from expanding? Under what conditions can it shrink again (yes, it does shrink)? That way, we'll know the right way to use this technique. Lawrence D'Oliveiro Mac-hacker-in-residence Computer Services Dept University of Waikato Hamilton New Zealand
chewy@apple.com (Paul Snively) (01/16/90)
In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > Come on Paul, stop hedging! Apple keep telling us that under System 7, > MultiFinder will be mandatory--you can't turn it off. Would you say > there's a chance Apple will go back on that at some point in the future? No; if anything, I'd say that it's more likely that the whole distinction will go away--there won't be a separate Finder and MultiFinder anymore. What I was really trying to point out, and didn't include enough words to do so effectively ;-) was that what OSDispatch really tells you at this point is whether you have "MultiFinder" temporary memory calls, and it wouldn't be out of the question for us to release a System version that had OSDispatch in the System rather than in MultiFinder, in effect similar to System 6, which put WaitNextEvent in the System rather than in MultiFinder. That's what I meant; sorry that I wasn't especially clear the first time. In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > Besides, OSDispatch is a documented trap--it's what gives you access to > the MultiFinder temporary memory allocation calls. Is there a chance > these will actually go away in the future? No, but again, where it comes from may change. The implicit assumption is that MultiFinder implements OSDispatch; THAT'S the assumption that seems weak to me. My personal opinion is that the appropriate thing for us at Apple to do would be to implement various Gestalt selectors indicating whether certain important functionality is available: context switching, temporary memory, etc. In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > My guess is, the answer to both these questions is "no". So if you > find that OSDispatch is present, then MultiFinder is present. QED. You're quite correct, given the implicit assumption named above. If that assumption should at any time prove false, you've got problems. In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > There is *one* nuisance, and that's the way memory management is done. > This business of fixed-size application heaps can be greatly annoying > with programs that have highly variable memory requirements... I agree. In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: [Lots of stuff about using the dynamically-resized System Heap under MF deleted] > Would anybody at Apple like to comment on this technique? Don't tell > us "don't do it"--unless you can offer an alternative. Remember, Mac > software has traditionally been self-configuring--let's keep it that way! It will solve the problem, but at some cost to the developer (we're trying to make MultiFinder comparatively transparent), and with a great deal of danger for really nasty bugs, like forgetting to deallocate the stuff in the System Heap. Besides which, the System Heap is called that for a reason--it's for stuff that's (at least theoretically) global to the entire system, all applications, and so forth. We'd really prefer to keep it that way. There are obvious performance hits when the System Heap has to resize as well, and what are you going to do when the System Heap gets big enough that the next time you try to resize it, it fails because it can't allocate enough MF free space? You can't very well install a GrowZoneProc in the System Heap! Basically, the goal is noble but the implementation idea is flawed. And no, we don't have a good alternative. After all, for as nice as some of MultiFinder's functionality is, it IS very much a Mac OS afterthought; if we had the whole Mac OS to do over again, we'd almost certainly have hardware-protected paged dynamic memory management and the like, and the problem wouldn't exist. As it stands, well, we do what we do now mostly to avoid breaking as many things as possible. In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > What would be useful is to have some more information on what exactly > happens to the system heap under MultiFinder. For example, what conditions > could prevent the system heap from expanding? Under what conditions can > it shrink again (yes, it does shrink)? That way, we'll know the right > way to use this technique. There is no right way, and the reason that kind of information isn't available is that it may change from one version of MultiFinder to another. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
lsr@Apple.COM (Larry Rosenstein) (01/20/90)
In article <1990Jan13.041909.10943@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: > My guess is, the answer to both these questions is "no". So if you > find that OSDispatch is present, then MultiFinder is present. QED. What if a future system always implements the temporary memory calls? This happened before with WaitNextEvent. The only case where it makes sense to ask whether MultiFinder is running is if you want to display a window that says "MultiFinder is running." That's really the only case where the question make sense. If you want to know whether the system heap can expand, whether the Launch trap will return, or whether the Finder is running, those are independent questions. > This business of fixed-size application heaps can be greatly annoying True. > a little more work. *And* it requires you to know whether MultiFinder > is actually running. It requires that you know whether the System Heap can expand. > The solution? Under MF, allocate your large or > varying-sized objects in the system heap. Under MultiFinder, the system > heap will expand as necessary to accommodate the demands that everybody > puts on it, provided there's room for it to do so. I can think of a couple of problems with this. One is that the System Heap is generally very fragmented. There are INITs, and other system objects there that are locked down. Second is that giving the application its own heap makes it easier for the system to clean up. If an application does crash or doesn't free everything, the heap is blown away and the memory is reclaimed anyway. If you put everything in the System Heap, then garbage may be left behind (as you mentioned). It also seems dangerous to start mixing application objects and system objects in the same heap, where is bug in the application could trash a system heap block and bring down the whole system. Also, this would be a bad architecture if we wanted to some day support protected application heaps. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1