davidc%yak@gatech.edu (Dave Corbin) (11/28/87)
Correct me where I go wrong. SetFunction allows you to patch in your own replacement function for a function in a library. Thus, if I want to monitor certain calls (like all SizeWindow()s, or some such), I should be able to use SetFunction to do it. Here's my problem. I get back a zero value from the SetFunction, and apparently my new routine is NOT being called. Can someone offer me some info on what the most likely stumbling blocks are? David Corbin
bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/03/87)
In article <4562@pyr.gatech.EDU> davidc%yak@gatech.edu (Dave Corbin) writes: >Correct me where I go wrong. SetFunction allows you to patch in your own >replacement function for a function in a library. True. Also note that if you want to replace a vector you *must* use SetFunction()... it is not good enough to just patch it yourself. >Thus, if I want to monitor >certain calls (like all SizeWindow()s, or some such), I should be able to use >SetFunction to do it. True, sort of. Intuition itself does not loop back through the library vectors. Thus any program calling SizeWindow() would trigger, but mousing arround would produce no results. >Here's my problem. I get back a zero value from the >SetFunction, and apparently my new routine is NOT being called. Can someone >offer me some info on what the most likely stumbling blocks are? Zero result is wrong, it should return the old function's address. (This will be something in the $00FC0000-$00FFFFFF range, but don't count on it). You are using 68000, right? 1/2 :-). A1 must contain a pointer to the library base, A0 must contain an offset just as you might use to call the routine (_LVOSizeWindow), and D0 must contain the address of your new function. Here's a fragment from my requester Cancel!ing Cancel! program: ;SetFunction lock structure lea.l NewAutoRequest-HS(a2),a0 ;our new function move.l a0,d0 move.w #_LVOAutoRequest,a0 ;offset move.l IBase,a1 ;library jsrlib SetFunction |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U WARNING: hoser's spool directory eats a *lot* of mail. :-(
michael@stb.UUCP (Michael) (12/12/87)
In article <22035@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >True, sort of. Intuition itself does not loop back through the library >vectors. Thus any program calling SizeWindow() would trigger, but >mousing arround would produce no results. Its not just intuition. Dos library doesn't. None of the BCPL handlers do. Heck, Translator didn't. Commodore, please, some of us are starting to do some very interesting stuff with this. WE NEED *ALL* system software to support the library vectors-- INCLUDING DOS.LIBRARY. I was actually going to re-write dos.library in C and just throw out all BCPL support. C: can be replaced by ARP and a shell or two; fexec() would need replacement, but not much else (Who out there actually looks at the cli structure or other such things besides the shells?). Unfortunately, things like RAW:, CON:, PRT:, PAR:, etc. are still in BCPL, using the global vector, making it impossible. Michael -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : "Copy Protection? Just say 'Off site backup'. "
hamilton@uxc.cso.uiuc.edu (12/16/87)
michael@stb says: > In article <22035@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > >True, sort of. Intuition itself does not loop back through the library > >vectors. Thus any program calling SizeWindow() would trigger, but > >mousing arround would produce no results. > > Its not just intuition. Dos library doesn't. None of the BCPL handlers do. > Heck, Translator didn't. > > Commodore, please, some of us are starting to do some very interesting stuff > with this. WE NEED *ALL* system software to support the library vectors-- > INCLUDING DOS.LIBRARY. I was actually going to re-write dos.library in > C and just throw out all BCPL support. ... > Unfortunately, things like [handlers] > etc. are still in BCPL, using the global vector, making it impossible. no, the global vector is BCPL's equivalent of the library vector. dos.library and the handlers don't bypass it for internal calls; they always go thru the GV. thus, patch the GV, and you're in business. i did this a long time ago to implement something like phil lindsay's "monproc"; i stole the file-handler GV entries for things like pktwait(). your only real problem is identifying the GV entries and what they do. as for re-writing dos.library, you'll just have to rewrite the handlers too. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton