Xref: utzoo comp.sys.ibm.pc.programmer:1771 alt.msdos.programmer:1710
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!uvaarpa!haven!aplcen!unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!uwm.edu!cs.utexas.edu!usc!ucsd!hub.ucsb.edu!6600sirt
From: 6600sirt@ucsbuxa.ucsb.edu (Mike O'Brien)
Newsgroups: comp.sys.ibm.pc.programmer,alt.msdos.programmer
Subject: Re: Removing int 2f TSR
Message-ID: <4892@hub.ucsb.edu>
Date: 3 Jun 90 10:24:26 GMT
References: <138@matrix.UUCP>
Sender: news@hub.ucsb.edu
Reply-To: 6600sirt@ucsbuxa.ucsb.edu
Distribution: na
Lines: 25

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