emerrill@pro-carolina.UUCP (Eric Merrill) (05/28/89)
I have a _lot_ of desk accessories that I'm going through, deciding which ones to put in cold storage and which ones are actually usefull. I have acc.chooser (the NDA that will load desk accessories into memory w/o having to reboot), but my problem is how can I delete DA's that are already in memory? Do I have to reboot my system disk each time I get the menus full? I know that there are DA's which will let me have more room to list other ones, but I want something to delete unneeded DA's from memory. Thanks for any help!! ___________________________________________________________________________ | | | Eric Merrill INET: emerrill@pro-carolina.cts.com SPACE FOR RENT!! | | Alink PE: Doc Neuro GEnie: emerrill CHEAP!! | | ARPA: crash!pro-carolina!emerrill@nosc.mil $49.95/MO | | UUCP: [ sdcsvax nosc ] !crash!pro-carolina!emerrill or best offer | |___________________________________________________________________________|
) (05/28/89)
In article <8905272100.AA01113@obsolete.UUCP> emerrill@pro-carolina.UUCP (Eric Merrill) writes: > ...How can I delete DA's that are already in >memory? Do I have to reboot my system disk each time I get the menus full? > | Eric Merrill INET: emerrill@pro-carolina.cts.com SPACE FOR RENT!! | According to the (non-updated) Toolbox References, there is no Desk Manager routine to Uninstall a DA, only to INSTALL a CDA or NDA. It would seem to be a bit of a problem uninstallinDA without using the Desk Manager, as it is thorougly tied in to most DAs (anything that is run at intervals, such as a clock). (~~~~) ____________________________________________________________ ( 0 0 ) / \ (| > |) ___/ Johnson Earls - jearls@polyslo.calpoly.EDU | ( \__/ ) <___ - ..!ucbvax!voder!polyslo!jearls | (____) \_____________________________________________________________/
dlyons@Apple.COM (David Lyons) (05/31/89)
In article <8905272100.AA01113@obsolete.UUCP> emerrill@pro-carolina.UUCP (Eric Merrill) writes: >[...] >Do I have to reboot my system disk each time I get the menus full? >I know that there are DA's which will let me have more room to list other >ones, but I want something to delete unneeded DA's from memory. Thanks for >any help!! Under System Disk 4.0 and earlier, there is no legitimate way to remove a DA. Under System Disk 5.0 and later, there are two new Desk Manager calls: RemoveCDA and RemoveNDA (just like InstallCDA and InstallNDA, only different). These calls remove a DA from the Desk Manager's tables, but they do *not* actually remove the DA's code from memory, because there's no safe way to do that. (The DA may have intercepted system vectors or toolbox functions or installed heartbeat interrupt tasks, so that freeing up its memory could easily crash the system.) It would be neat if there were a way for a DA to identify itself as "removable" and have a routine to call that unhooks the DA from the system if necessary. But that's not happening in 5.0. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
wombat@claris.com (Scott Lindsey) (05/31/89)
From article <31983@apple.Apple.COM>, by dlyons@Apple.COM (David Lyons): > Under System Disk 5.0 and later, there are two new Desk Manager calls: > RemoveCDA and RemoveNDA (just like InstallCDA and InstallNDA, only different). > These calls remove a DA from the Desk Manager's tables, but they do *not* > actually remove the DA's code from memory, because there's no safe way to do > that. (The DA may have intercepted system vectors or toolbox functions or > installed heartbeat interrupt tasks, so that freeing up its memory could easily > crash the system.) Why couldn't you just send that DA a shutdown, at which point it *should* undo anything it has done. Then just unload its segment. Does the fear of mis- behaved DA's in this respect prevent it? -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
dlyons@Apple.COM (David Lyons) (05/31/89)
In article <10220@claris.com> wombat@claris.com (Scott Lindsey) writes: >From article <31983@apple.Apple.COM>, by dlyons@Apple.COM (David Lyons): > >> Under System Disk 5.0 and later, there are two new Desk Manager calls: >> RemoveCDA and RemoveNDA (just like InstallCDA and InstallNDA, only different). [...] >Why couldn't you just send that DA a shutdown, at which point it *should* undo >anything it has done. Then just unload its segment. Does the fear of mis- >behaved DA's in this respect prevent it? The purpose of the Shutdown routine for a CDA or NDA is *not* necessarily to tell it to get its grubby fingers out of the system, unfortunately. Consider CDAs like MacroMate (a macro program which watches the keyboard for special keystrokes during an interrupt routine & simulates extra keypresses when appropriate). It actually uses its ShutDown routine to *install* itself, which is its only sensible alternative. NDAs have an Init entry point called by DeskStartUp and DeskShutDown, but there could be NDAs that leave stuff installed even after they are shut down (although I don't know of any offhand). --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
wombat@claris.com (Scott Lindsey) (05/31/89)
From article <31991@apple.Apple.COM>, by dlyons@Apple.COM (David Lyons): > > The purpose of the Shutdown routine for a CDA or NDA is *not* necessarily to > tell it to get its grubby fingers out of the system, unfortunately. Consider > CDAs like MacroMate (a macro program which watches the keyboard for special > keystrokes during an interrupt routine & simulates extra keypresses when > appropriate). It actually uses its ShutDown routine to *install* itself, > which is its only sensible alternative. Only "sensible" alternative to *automatically* install itself, that is. It could, of course, require that you turn it on manually through the CDA menu... And the Toolbox Reference *does* say "The second entry point is necessary because CDAs can spawn background tasks that rely on the availability of the current ProDOS. The shutdown routine allows the CDA to stop the tasks." And NDA's *should* get their grubby fingers out of the system on a ShutDown. Oh well. Arguing for the sake of arguing :-) -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
dlyons@Apple.COM (David Lyons) (06/01/89)
In article <10221@claris.com> wombat@claris.com (Scott Lindsey) writes: [...] >Only "sensible" alternative to *automatically* install itself, that is. It >could, of course, require that you turn it on manually through the CDA menu... Yup, that's what I meant. >And the Toolbox Reference *does* say "The second entry point is necessary >because CDAs can spawn background tasks that rely on the availability of the >current ProDOS. The shutdown routine allows the CDA to stop the tasks." True. But it doesn't say that's the *only* use for the shutdown routine, or that background tasks should *always* be stopped. >And NDA's *should* get their grubby fingers out of the system on a ShutDown. Well...I don't think that that's specified clearly anywhere. But as soon as 5.0 is out, there's nothing stopping 3rd parties from writing a utility that calls RemoveNDA on an NDA's main handle and then calls UserShutdown on its ID. I just realized there's no wonderfully straightforward way to get a list of all the handles appropriate for use with RemoveNDA/RemoveCDA. I guess you have to call GetLoadSegInfo on memory IDs in the $50xx range, and then use FindHandle to get the handle for the first segment. >Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air >Claris Corp. | About an age of power when no one had an hour to spare" >ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, >wombat@claris.com | StyleWare, the author, or anyone else living or dead. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jason@madnix.UUCP (Jason Blochowiak) (06/05/89)
In article <31983@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes: >Under System Disk 4.0 and earlier, there is no legitimate way to remove a >DA. > >Under System Disk 5.0 and later, there are two new Desk Manager calls: >RemoveCDA and RemoveNDA (just like InstallCDA and InstallNDA, only different). >These calls remove a DA from the Desk Manager's tables, but they do *not* >actually remove the DA's code from memory, because there's no safe way to do >that. (The DA may have intercepted system vectors or toolbox functions or >installed heartbeat interrupt tasks, so that freeing up its memory could easily >crash the system.) > >It would be neat if there were a way for a DA to identify itself as "removable" >and have a routine to call that unhooks the DA from the system if necessary. How about something like: If the first word that's pointed to by both the CDA Entry and ShutDown addresses in the CDA header is $0000, then the CDA is considered removeable. Perhaps something similar for the NDAs. I don't understand why they didn't put a "supported calls" count in the headers - then there could be a "are you removeable?" call to the DA. Perhaps this could be done with the "pointing to 0 word" thingie I just mentioned - if that was the case, then the word after the aforementioned 0 word would be the supported calls count. So the header for a CDA would look like this: Header data str 'I be the new kind of CDA' dc i4'NewHeader,NewHeader' NewHeader anop dc i2'0,3' ;# of calls (<2 would cause an error) dc i4'StartOfDACode,ShutDownRoutine' dc i4'CheckRemove' ;Or whatever new calls... end ;End of Header Perhaps instead of a CheckRemove there could be a RemoveThySelf call which would return failure if the DA wasn't removeable (or, of course, if the removal failed for some reason for another). It doesn't seem like it'd be incredibly useful to be able to nuke the thing from the Desk Mgr's list if it can't be removed from memory, especially since both DA menus scroll on 5.0... >But that's not happening in 5.0. Oh, well... :) > --Dave Lyons, Apple Computer, Inc. -- _______________________________________________________________________________ jason@madnix.UUCP, methinks. Formerly blochowi@garfield.cs.wisc.edu "It beats working" - Harrison Ford
dlyons@Apple.COM (David Lyons) (06/10/89)
In article <678@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes: >How about something like: If the first word that's pointed to by both >the CDA Entry and ShutDown addresses in the CDA header is $0000, then the CDA >is considered removeable. Perhaps something similar for the NDAs. Remember that any new format invented needs to do something reasonable under previously released system disks. Having the old systems execute BRK instructions for new DAs wouldn't be terribly reasonable. :-) (The *new* system could check for the $0000, but the old systems can't be changed to do that.) > I don't >understand why they didn't put a "supported calls" count in the headers - then >there could be a "are you removeable?" call to the DA. I personally think that sounds like a nifty idea--but any new standards for DA formats would have to be compatible with the existing formats and would have to come from the appropriate group within Apple. > jason@madnix.UUCP, methinks. Formerly blochowi@garfield.cs.wisc.edu > "It beats working" - Harrison Ford --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
mmunz@pro-beagle.cts.com (Mark Munz) (06/11/89)
Network Comment: to #8631 by pnet01!crash!apple.com!dlyons
> Removable CDA's and NDA's... keeping the compatiblity
Here's an idea.. how about a Toolbox call that the NDA or CDA could make that
would tell the system, "Hey, you can kill me once you shut me down"..
--Mark Munzjason@madnix.UUCP (Jason Blochowiak) (06/15/89)
Pardon any typos, etc., in this article - the editor is being flaky. In article <32347@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes: >In article <678@madnix.UUCP> jason@madnix.UUCP (Jason Blochowiak) writes: >>How about something like: If the first word that's pointed to by both >>the CDA Entry and ShutDown addresses in the CDA header is $0000, then the CDA >>is considered removeable. Perhaps something similar for the NDAs. > Having the old systems execute BRK >instructions for new DAs wouldn't be terribly reasonable. :-) (The *new* >system could check for the $0000, but the old systems can't be changed to >do that.) Picky, picky :) Ok, then how about this: Header data str 'I be a better new kind of CDA' dc i4'CDAEntry,CDAShutdown' end NewHeader data dc i'3' ;# of supported new calls dc i4'RemoveThySelf' ;A new call dc i4'0' ;A new call that isn't really supported dc i4'SomeOtherCall' ;Another new call that's supported end CDAEntry start bra really dc i'0' dc i4'NewHeader' really anop * Entry code for CDA rtl end CDAShutdown start bra really dc i'0' dc i4'NewHeader' really anop * Shutdown code for CDA rtl end I suppose that it'd only be necessary to have the bra, 0, and ptr to the new header right after whatever is pointed to in the first pointer in the header (CDAEntry in this case). Considering the structure of the header is rather fragile already, I guess that the redundancy wouldn't "robustify" it enough to make a difference. >I personally think that sounds like a nifty idea--but any new standards for >DA formats would have to be compatible with the existing formats and would >have to come from the appropriate group within Apple. Ok, well condition #1 is satisfied, but there isn't much that I can do about #2 :) The reason I posted my first response (as well as this one) is so that if other people have comments about my comments they can say so... I'd appreciate it if you'd forward this (assuming the system design folks don't read comp.sys.apple) to the necessary people. As a tangent - there's one thing (and pretty much only one thing) that I like about GEM on the Atari ST: The messaging architecture. If things were set up like that, this wouldn't be a problem, as new message types could be added. If an application or DA were unable to comprehend a message, it could say so and that would be that... I like quite a bit of the gs' architecture, but it seems that quite often the system software isn't set up in a particularly expandable fashion, even when there wouldn't be much (if any) performance degradation. Anyways, my feet are getting soapy :) > --Dave Lyons, Apple Computer, Inc. | DAL Systems -- --------8<------------------------------------------------------------8<-------- jason@madnix.UUCP "I am opposed 180 degrees" - George Bush, master mixer of metaphors. (Is the IInix mailing group still out there?)