root@brain.UUCP (Chuck Shotton) (02/09/90)
Multifinder has an interesting quirk in that it patches ExitToShell, and doesn't give a damn about any patches that may already be in place. Does anyone have a suggestion as to how an INIT can patch ExitToShell at boot time (prior to knowing if Multifinder is going to be active) and make sure that the patch is in place AFTER Multifinder is done munging the trap? I can think of a few hacks, like having VBL task delay for a while (until MF is up and running) and then apply the patch, but that seems ugly. Any suggestions or comments on this phenomena would be appreciated. Chuck Shotton root@brain.uucp ...!buster!brain!root cshotton@girch1.hsch.utexas.edu
erics@eleazar.dartmouth.edu (Eric Schlegel) (02/10/90)
In article <204@brain.UUCP> root@brain.UUCP (Chuck Shotton) writes: >Multifinder has an interesting quirk in that it patches ExitToShell, and doesn't >give a damn about any patches that may already be in place. Does anyone have >a suggestion as to how an INIT can patch ExitToShell at boot time (prior to >knowing if Multifinder is going to be active) and make sure that the patch is >in place AFTER Multifinder is done munging the trap? MultiFinder patches a number of traps in this fashion - it's quite annoying. I haven't tried this yet, but I think installing a Notification Manager callback in your INIT, and having the callback routine patch the trap, would work. The Notification Manager certainly won't start notifying until after MF is installed, so you should be able to safely patch over MF's patches. -eric -- Eric Schlegel '90 | "Never underestimate the bandwidth of a eric.schlegel@dartmouth.edu | station wagon full of tapes."