venkat@matrix.UUCP (D Venkatrangan) (06/03/90)
I plan on using the INT 2f multiplex interrupt for installing and accessing my TSR. It seems easy enough to do the install and chain to the old int 2f ISR (if the request is not ours). But what is the best way to remove? As long as no other TSR that comes in later changes the int 2f, I can reset it to the old value that was saved when we installed, and of course, free our TSR's memory block. What should be done if this is not the case? I have heard of the Mark/Release TSR management utilities, but I want a programmable interface. It seems like if all int 2f TSRs were required to supply a standard function code that returns the location (both segment and offset) where it has saved the old int 2f ISR address, we can save our saved int 2f ISR address at that location (thus replacing our ISR address with the one we saved - the next one in the chain) and remove ourselves from the chain. Is there such a convention?
6600sirt@ucsbuxa.ucsb.edu (Mike O'Brien) (06/03/90)
From article <138@matrix.UUCP>, by venkat@matrix.UUCP (D Venkatrangan): > It seems like if all int 2f TSRs were required to supply a standard > function code that returns the location (both segment and offset) where it > has saved the old int 2f ISR address, we can save our saved int 2f ISR > address at that location (thus replacing our ISR address with the one we > saved - the next one in the chain) and remove ourselves from the chain. > > Is there such a convention? There is a proposed standard for doing that, and it's called Tessaract. Unfortunately, nobody uses it. Three big reasons are: it violates Microsoft's published guidelines for the use of Int 2F, it requires alot of code (and therefore memory) to implement, and the authors of the proposed standard demand royalties from those who use it. So, the way things are currently, I don't think there's a good way to pull out a multiplexing TSR after others have been loaded. Two not-so-good ways are: 1> don't remove yourself from memory, but at least de-actify yourself 2> free up all of your program's memory except your multiplex ISR, and keep that small. Michael O'Brien 6600sirt@ucsbuxa.ucsb.edu