Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pallas!dgl292
From: dgl292@pallas.athenanet.com (Doug Lee)
Newsgroups: comp.sys.ibm.pc
Subject: Interrupting An Interrupt Chain
Summary: I can't ALWAYS call what was before me.
Message-ID: <322@pallas.athenanet.com>
Date: 27 Mar 90 05:39:58 GMT
References: <26909@ut-emx.UUCP>
Reply-To: dgl292@pallas.UUCP (Doug Lee)
Organization: Athenanet, Inc.,  Springfield, Illinois
Lines: 30

In article <26909@ut-emx.UUCP> boerner@ut-emx.UUCP (Brendan B. Boerner) writes:
This mechanism [a TSR manager -DL] could
>also handle making sure ALL tasks attached to that interrupt get
>called.  This would prevent TSRs from attaching to an interrupt and
>then not calling whatever was previously attached.  By not requiring
>TSRs to call others in the chain, it seems that memory could be
>compacted when a TSR was removed without affecting others (since they
>wouldn't be storing addresses of other TSRs to run).

Unfortunately for this idea, I have run into several situations in which
it is necessary that the chain NOT be followed all the way down.  I am
currently working on something which is obliged to stop TWO interrupts
from passing beyond it under certain conditions.  For an example, I believe
the example keyboard interrupt (INT 9) handler from Assembly Magazine (an
on-line magazine which, to my knowledge, has enjoyed only three issues
to date) blocks INT 9 upon receiving its "hotkey" to prevent it from
being seen by other programs.

I agree with you in wanting some kind of management for TSRs; writing
hitch and unhitch code for each and every one is a PAIN--particularly
where portability among DOS versions is an important issue.  However, I'll
be in DEEP trouble the day it becomes mandatory that no TSR EVER block
the completion of an interrupt chain.

I heartily welcome ideas on how to go about interrupt snagging (particularly
for keyboard interrupt/request functions) without ever being obliged to stop
the chain.  I've only been writing 8086/286 assembly for two years--and that
somewhat sparsely.

Doug Lee  (dgl292@athenanet.com or uunet!pallas!dgl292)