sonenbli@oxy.edu (Andrew D. Sonenblick) (01/02/90)
Ok, some DA questions.... I have many a DA which are utilities which must be loaded into the application heap (so they can be assured of communication with the appl). No biggie, option down on opening the DA. Ok, but I also *need* the DA's to be closed upon quitting the applications they reside in. However, under MultiFinder, when the application quits *none* of my DA's receive any goodbye kiss. Thus, they are still running! (Which is a bit screwy if you ask me since the heap they were supposedly loaded into is no longer in existence....) Where are they? Are they still where they were in the appl heap which just hasn't yet been written over? I suppose I could close them myself by ascertaining if the appl is no longer runnin (and then not have to worry about where in memory they may be floating around)--but I shouldn't have to!!!!! That's why they gave DA's the "goodbye kiss!!" What I would like to know is why are the DA's not receiving the calls and what workarounds/solutions there may be... (I really find it hard to believe that Erich and Phil would patch exittoshel in such a way as to preclude application resident drivers from closing themselves...) Thanks much in advance.... Ando "thePort" Moon.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/05/90)
In article <68060@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: >I have many a DA which are utilities which must be loaded into the >application heap (so they can be assured of communication with the appl). >No biggie, option down on opening the DA. Ok, but I also *need* the >DA's to be closed upon quitting the applications they reside in. I, too, had this problem in the "Flips" desk accessory that is shipped in Scott Kim's "Letterforms & Illusions" product. This product has close to 100 paint files of Kim's beautiful calligraphic puzzle art, a demo version of MacPaint, and my desk accessory that adds new commands to macpaint for file traversal, and exploring symmetries of rotation and reflection. I solved the problem by installing a head patch on ExitToShell that, when triggered, attempts to remove my patches. (It may not be able to remove them, since thwey might have gotten re-patched by something else in the interim, and that something else will have cached away my procedure pointers as what it saw as the old value of the traps.) I patch through small "islands" in the system heap, so if it can't remove them, it can at least make them innocuous. I checked, applications _can_ exit via a return from main(), without directly calling ExitToShell(). But, if they try, the O.S. executes an ExitToShell() for them. "Letterforms & Illusions" is published by Scott Foresman & co. Check it out. --- David Phillip Oster -- No, I come from Boston. I just work Arpa: oster@dewey.soe.berkeley.edu -- in cyberspace. Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
goldman@apple.com (Phil Goldman) (01/05/90)
In article <33466@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > In article <68060@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > >I have many a DA which are utilities which must be loaded into the > >application heap (so they can be assured of communication with the appl). > >No biggie, option down on opening the DA. Ok, but I also *need* the > >DA's to be closed upon quitting the applications they reside in. > The DA will receive a goodbye kiss if any of the following is true: - The driver handle is in the app heap - The driver's storage handle (dce->dCtlStorage) is in the app heap - The driver's window ptr (dce->dCtlWindow) is in the app heap The idea here is that only drivers that have memory allocated in an app heap need to know when that app quits. I suppose it may be possible to have other memory allocated per app, but in that case one of the conditions above should be true also, to guarantee correct behavior. Note that the case that is *not* supported well is the system driver that has multiple app clients, for each of which it must maintain state. Such a driver would like a goodbye kiss when *any* app quits. The problem is that goodbye kisses do not translate well into the multitasking world. The original gb kiss meant that the app was expiring, but it also implied that the entire world was disappearing, since only one app ran at a time, and drivers were (often) loaded in the app heap. Therefore, for compatibility reasons, as usual, MF only gives gb kisses to drivers for which the world truly is going away -- those that have some type of storage in the particular app heap. What is needed is a "global gb kiss". The only other alternatives are for the driver to remain stateless (the best, if possible), timeout on state, or patch _ExitToShell. > I, too, had this problem in the "Flips" desk accessory that is shipped in > Scott Kim's "Letterforms & Illusions" product. This product has close to > 100 paint files of Kim's beautiful calligraphic puzzle art, a demo version > of MacPaint, and my desk accessory that adds new commands to macpaint for > file traversal, and exploring symmetries of rotation and reflection. > > I solved the problem by installing a head patch on ExitToShell that, when > triggered, attempts to remove my patches. It sounds like you should just Font/DA move your DA into MacPaint, if it is the only app it is used for. You will get the gb kiss when MacPaint quits. Thus, you can avoid the _ExitToShell patch altogether. > I checked, applications _can_ exit via a return from main(), without > directly calling ExitToShell(). But, if they try, the O.S. executes an > ExitToShell() for them. _ExitToShell will *always* be called when an app quits under MF, even if it does so because of a _SysErr. This is not true of UniFinder, because _Launch may terminate an app. as well. -Phil Goldman Apple Computer