Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!brunix!iris.brown.edu!ejd
From: ejd@iris.brown.edu (Ed Devinney)
Newsgroups: comp.sys.mac.programmer
Subject: While we're discussing patches...
Message-ID: <19954@brunix.UUCP>
Date: 6 Nov 89 22:51:09 GMT
Sender: news@brunix.UUCP
Distribution: usa
Organization: IRIS/Brown University
Lines: 32

Hi folks -

   In prototyping some desktop extensions here we've written a set of 
patches to the Window Manager which override some standard window 
behavior.  We'd like to permanently install them so that our new window 
behavior is system-wide, preferably via an init.  The init is very simple: 
it reads in our patches (saved as code resources), places them in the 
system heap, stores the 'standard' trap address where the patch can find 
it (actually in the patch's LSC CODE-resource header), and calls 
SetTrapAddress().  Very basic, and following along in TMON shows that the 
patches are actually being installed correctly.  However, TMON also shows 
someone (the Finder, probably) setting a whole bunch of trap addresses 
after the inits have run; many of these traps are the same Window Mgr 
traps that we wish to override, and we're getting bulldozed.
  IM v5 sez PTCH resources run before INITs - INITs are the last thing to 
run before the finder.  I'd prefer not to have to pound through the finder 
with _dumpcode_  or patch the Finder itself, but that's about what's left. 
 
   Now, we can't use an application to set the new traps, as MoFo finder 
apparently swaps trap tables between apps so they can have their own 
overrides.  Any idea why the OS is patching these traps after the 
INIT-stage?
    I've exhausted my local sources of information...any takers?

Thanks very much,

ed


++++++
ed devinney, IRIS/Brown University, Providence, RI...ejd@iris.brown.edu
-- "It's Bread and Circuses, y'all" --