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
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.

- Raw text -