Xref: news2.mv.net comp.os.msdos.4dos:5331 comp.os.msdos.apps:8285 comp.os.msdos.desqview:3649 comp.os.msdos.djgpp:5147 comp.os.msdos.mail-news:2577 comp.os.msdos.misc:33365 comp.os.msdos.pcgeos:313 comp.os.msdos.programmer:25581 comp.os.msdos.pr ...
From: Sean McNamee <seanmc AT wolfenet DOT com>
Newsgroups: comp.os.msdos.4dos,comp.os.msdos.apps,comp.os.msdos.desqview,comp.os.msdos.djgpp,comp.os.msdos.mail-news,comp.os.msdos.misc,comp.os.msdos.pcgeos,comp.os.msdos.programmer,comp.os.msdos.programmer.turbovision
Subject: Re: abort/kill - TSR
Date: Tue, 18 Jun 1996 17:33:43 -0700
Organization: Danar Corp.
Lines: 12
Distribution: inet
Message-ID: <31C74AE7.C26@wolfenet.com>
References: <31C0734A DOT 4F20 AT msmail4 DOT hac DOT com> <4pshkf$155a AT msunews DOT cl DOT msu DOT edu> <4pvk0c$h7s AT electra DOT saaf DOT se> <4q64j1$tmj AT earth DOT njcc DOT com>
NNTP-Posting-Host: sea-ts2-p56.wolfenet.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Actually, the problem with unloading TSR's isn't the 'hole' they 
leave in memory, but due to the fact that TSR's generally patch 
interrupts- and then call into the previous TSR's code via the last 
interrupt vector.
	When you remove a TSR from memory, any more-recently loaded 
TSR's will still have a pointer into the now releasd memory.  When that 
interrupt is called : BOOM!

-Any opinions expressed here do not reflect the opinions of those who 
have brain-washed me.