goldman@apple.com (Phil Goldman) (04/05/89)
In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > The standard, from Apple is "Don't even try to do this". Most people do > it by checking to see if the end of the system heap is close to the > beginning of the application heap. If it is, no multifinder. This is a very bad thing to do, and, as was mentioned in a previous posting, the one known legitimate reason for doing so will soon be fixed in SysEnvirons. Reasons such as putting up a dialog box saying "Cannnot do...with MultiFinder" are very poor ones. When MF was first released there were certain apps that had these same warnings for Switcher. These dialogs became very embarrassing for the developers, and an annoyance for users. This will happen again apparently. Doing such checks makes it very much harder to move MultiFinder functionality to the System or ROM. Worse, it makes it dirtier to add new Mac OS functionality. -Phil Goldman Apple Computer
ech@pegasus.ATT.COM (Edward C Horvath) (04/06/89)
This isn't a need-to-know, but rather an annoyance. I have an application that tries to be a good citizen by shrinking windows when it's not the foreground app. I'm not the author of VersaTerm, but it does this also. No problem: initially set up for foreground; then on a Suspend event, switch to background appearance; on a Resume, switch to foreground. This works fine EXCEPT when the application is part of a "Set Startup" set and does not wind up frontmost. The app is set up in background, and stays in background, but doesn't receive an initial Resume OR Suspend. Minor, but several of my users have complained about it. Simplest fix for Apple is just to make sure startup apps get a Suspend event (preferably excepting the frontmost app). =Ned Horvath= ech@pegasus.att.com; AppleLink D1619
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/06/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David >Phillip Oster) writes: >> The standard, from Apple is "Don't even try to do this". Most people do >> it by checking to see if the end of the system heap is close to the >> beginning of the application heap. If it is, no multifinder. > >This is a very bad thing to do, and, as was mentioned in a previous >posting, the one known legitimate reason for doing so will soon be fixed >in SysEnvirons. > I fully agree that it is bad to check for Multifinder in terms of future compatibility. If Apple wants developers to refrain from doing this, they should NOT DISTRIBUTE DEVELOPER'S TOOLS WHICH OBVIOUSLY DO. I have MPW Shell 2.0.2, and it obviously knows whether Launch will return or not, and therefore knows whether MultiFinder is active. It undoubtedly uses some non-approved method of finding out whether MultiFinder is active or not. Apple cannot reasonably expect developers to refrain from checking for MultiFinder active, and at the same time sell them a program which does. "Don't do as I do, do as I say." is not very convincing coming from anybody. > >Doing such checks makes it very much harder to move MultiFinder >functionality to the System or ROM. Worse, it makes it dirtier to add new >Mac OS functionality. Yes. I can imagine all sorts of nifty features that could be added to MultiFinder and the OS, and that would be incompatible with present applications which check for MultiFinder active. So please, don't attempt to find out, and ignore the bad example set by certain distributors of development systems. Earle
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (04/06/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >This is a very bad thing to do, and, as was mentioned in a previous >posting, the one known legitimate reason for doing so will soon be fixed >in SysEnvirons. But for now you can check if the standard MDEF (id=0) is in the system heap or the application heap. If it's in the system heap then MF is probably running. I say probably because an init I'm working on loads the MDEF into the system heap and there may be other inits that do this too. >Doing such checks makes it very much harder to move MultiFinder >functionality to the System or ROM. Worse, it makes it dirtier to add new >Mac OS functionality. > >-Phil Goldman >Apple Computer What he said. Use my method only at your own risk. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
dee@XAIT.Xerox.COM (Donald Eastlake) (04/07/89)
In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David >Phillip Oster) writes: >> The standard, from Apple is "Don't even try to do this". Most people do >> it by checking to see if the end of the system heap is close to the >> beginning of the application heap. If it is, no multifinder. >This is a very bad thing to do, ... >Reasons such as putting up a dialog box saying "Cannnot do...with >MultiFinder" are very poor ones. ... Thanks for reminding me. There is another place I "check for MultiFinder". My program allows a user to Unmount volumes. Unfortunately, there is a bug in MultiFinder, which is supposed to close the DeskTop file when an application does an Unmount, where it fails to do this on flat file system volumes and you get a busy error message. Things are a bit complicated because a volume could be legitamately busy but if I get this error when trying to unmount a volume and its non-hierarchial and MF (actually the temp mem traps) is present I suggest the user try switching to the Finder and drag the volume to the trash, which will work if this MF bug is their problem. -- +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
goldman@apple.com (Phil Goldman) (04/07/89)
In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > This works fine EXCEPT when the application is part of a "Set Startup" > set and does not wind up frontmost. The app is set up in background, > and stays in background, but doesn't receive an initial Resume OR Suspend. > > Minor, but several of my users have complained about it. Simplest fix for > Apple is just to make sure startup apps get a Suspend event (preferably > excepting the frontmost app). MF *does* give background apps a suspend event as the first event. However, like all suspend/resume events the event will be dropped if the app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked out. Perhaps this is why your app does not see it. -Phil Goldman Apple Computer
goldman@apple.com (Phil Goldman) (04/07/89)
In article <43465@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: > Thanks for reminding me. There is another place I "check for MultiFinder". > My program allows a user to Unmount volumes. Unfortunately, there is a bug > in MultiFinder, which is supposed to close the DeskTop file when an > application does an Unmount, where it fails to do this on flat file > system volumes and you get a busy error message. Things are a bit > complicated because a volume could be legitamately busy but if I get > this error when trying to unmount a volume and its non-hierarchial and > MF (actually the temp mem traps) is present I suggest the user try > switching to the Finder and drag the volume to the trash, which will > work if this MF bug is their problem. This is a bug, albeit a minor one, in the system. The problem is that it is extremely difficult to find the Desktop file on an MFS disk, because the FCB does not contain a name. There are gross ways to do it, but the feeling was that it was unimportant since there is no reason to use MFS disks in any case. Anway...if you are convinced that this is a serious bug, you should probably tell Mac Tech support. If enough developers complain then we would reevaluate the priority of the bug fix. You might also inform them if you can think of a clever fix. -Phil Goldman Apple Computer
goldman@apple.com (Phil Goldman) (04/07/89)
In article <12910@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > In article <1179@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: > >In article <28689@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David > >Phillip Oster) writes: > >> The standard, from Apple is "Don't even try to do this". Most people do > >> it by checking to see if the end of the system heap is close to the > >> beginning of the application heap. If it is, no multifinder. > > > >This is a very bad thing to do, and, as was mentioned in a previous > >posting, the one known legitimate reason for doing so will soon be fixed > >in SysEnvirons. > > > I fully agree that it is bad to check for Multifinder in terms of > future compatibility. If Apple wants developers to refrain from doing > this, they should NOT DISTRIBUTE DEVELOPER'S TOOLS WHICH OBVIOUSLY DO. > I have MPW Shell 2.0.2, and it obviously knows whether Launch will > return or not, and therefore knows whether MultiFinder is active. It > undoubtedly uses some non-approved method of finding out whether > MultiFinder is active or not. Apple cannot reasonably expect > developers to refrain from checking for MultiFinder active, and at the > same time sell them a program which does. "Don't do as I do, do as I > say." is not very convincing coming from anybody. As I mentioned in the original posting, there is currently one legitimate reason to check for MF. It can be done by applications that need to know whether _Launch will return. This will be fixed in a future System release. Until then, the approved method, which the MPW Shell uses, is to check for the existence of the temporary memory trap. What Apple says (in the Technotes), and does (in the code for the Shell) is to request that _Launch not even be called, unless the application is a programming environment and is willing to be broken across System releases. This is a bit harsh, and will probably not happen, but both criteria are true of the Shell. -Phil Goldman Apple Computer
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (04/07/89)
In article <1234@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) >writes: .> This works fine EXCEPT when the application is part of a "Set Startup" .> set and does not wind up frontmost. The app is set up in background, .> and stays in background, but doesn't receive an initial Resume OR .Suspend. >MF *does* give background apps a suspend event as the first event. >However, like all suspend/resume events the event will be dropped if the >app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked >out. Perhaps this is why your app does not see it. Or perhape we are all calling GetNextEvent 4 times before actually looking at the event returned [I forget what this hack was for]? Or calling FlushEvents at the start of the App? Marc Kaufman (kaufman@polya.stanford.edu)
ech@pegasus.ATT.COM (Edward C Horvath) (04/08/89)
From article <1234@internal.Apple.COM>, by goldman@apple.com (Phil Goldman): > MF *does* give background apps a suspend event as the first event. > However, like all suspend/resume events the event will be dropped if the > app calls _WaitNextEvent/_GetNextEvent/EventAvail with app4 events masked > out. Perhaps this is why your app does not see it. Thanks, Phil, I'll go look for that. I don't mask out ANYTHING. Unfortunately, I also notice that (consistent with ancient guidelines!) my app calls FlushEvents (allEvents) early...I'll try it with app4Events unflushed. =Ned Horvath=
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/08/89)
In article <2749@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >This isn't a need-to-know, but rather an annoyance. > >I have an application that tries to be a good citizen by shrinking windows >when it's not the foreground app. I'm not the author of VersaTerm, but it >does this also. > I for one do not ever want to have to write code which does this. Window sizes and locations should always be under user control. The new MultiFinder (6.1a2, I ftp'ed if from somewhere, and don't remember where if you're asking) has an option to "Set Aside" applications so that their windows are not visible. This means that you can use it sort of like Switcher if you want, or like the "regular" MultiFinder if you want. If Apple ever makes an official release out of it, lots of problems like those above will vanish. One of the beauties of MultiFinder is how surprisingly little you have to do to be compatible with it. If developers resort to tricks like shrinking their windows when suspended, I think they are second-guessing what Apple is going to do, and what users are going to need, and will probably experience problems in the future. ... >This works fine EXCEPT when the application is part of a "Set Startup" >set and does not wind up frontmost. The app is set up in background, >and stays in background, but doesn't receive an initial Resume OR Suspend. I agree that this is definitely a bug. Keeping track of Resume/Suspend events is not a good way for an application to find out if is in the background or foreground, especially if there are conditions where you don't get all of them you are entitled to. Earle
dee@XAIT.Xerox.COM (Donald Eastlake) (04/08/89)
In article <1235@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <43465@XAIT.Xerox.COM> dee@XAIT.Xerox.COM (Donald Eastlake) writes: >> My program allows a user to Unmount volumes. Unfortunately, there is a bug >> in MultiFinder, which is supposed to close the DeskTop file when an >> application does an Unmount, where it fails to do this on flat file >> system volumes and you get a busy error message. ... >This is a bug, albeit a minor one, in the system. The problem is that it >is extremely difficult to find the Desktop file on an MFS disk, because >the FCB does not contain a name. There are gross ways to do it, but the >feeling was that it was unimportant since there is no reason to use MFS >disks in any case. I don't know how the current kludge for unmounting volumes works but why do you need a name? TN 180 clearly says that MF asks the finder to close the DeskTop file. If the Finder is what opened it and keeps it opne how can it possibly be any problem for it to close it??? There will be MFS disks around for MANY YEARS. Ignoring them is a bad idea. (My program even makes a try at running under the 64K ROM although many of its features are disabled.) -- +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 USA