Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!bbn!lawrence From: lawrence@bbn.COM (Gabriel Lawrence) Newsgroups: comp.sys.mac Subject: Re: (LSC) Deep Dark Secrets Wanted! Message-ID: <6296@ccv.bbn.COM> Date: 25 Jan 88 17:39:32 GMT References: <870111@hpcilzb.HP.COM> <817@thorin.cs.unc.edu> <15349@think.UUCP> Reply-To: lawrence@ccv.bbn.com.BBN.COM (Gabriel Lawrence) Organization: Bolt, Baranek and Newman Inc., Cambridge MA Lines: 35 (ephraim vishniac) writes: >(Oliver Steele) writes: >>tedj@hpcilzb.HP.COM (Ted Johnson) writes: >>>Would someone please share the DEEP DARK programming secrets on how to: >>> (2)make a DA live forever (i.e., remain active across launching >>> different applications from the non-multi Finder), unless >>> you explicitly close it by clicking on it's close box. >>> I assume this means patching one or more of the ROM routines.... >> >>Set the DA up to launch a VBL task. I think da-insect at sumex has >>C source for this. > >...VBL tasks can do little. They can't use any memory manager routines. >They can't expect unlocked handles to be valid. They can't use most >of the toolbox. They certainly can't expect A5 to be current. In fact, they >can't even expect CurrentA5 to be valid! (There are ways of checking on that >one, but it's nasty = undocumented.) Of course the easiest way to make a DA live forever is to use the same "trick" that MultiFinder uses, place the DA into the System heap rather than the application heap. There are no restrictions I know of that prevent a DA from placing a copy of itself into the System heap and altering the DCE information to indicate the new location of the DA. For non-critical timing background operation, setting the DA dNeedTime header bit should suffice, relieving you from having to play games with the Vertical Blanking Interrupt Manager. I haven't written any DA's that actually use this technique but it seems to work just fine for the other types of device drivers I've written. Does anybody detect any logical flaws to this approach? =Gabe Lawrence= =BBN Communications= USENET: ...!harvard!bbn!lawrence@BBN.COM INTERNET: lawrence@BBN.COM