dgl292@pallas.athenanet.com (Doug Lee) (03/27/90)
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)
mee@ucscb.UCSC.EDU (Kevin Kahl) (03/27/90)
In article <322@pallas.athenanet.com> dgl292@pallas.UUCP (Doug Lee) writes: >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 [=stuff deleted=] >For an example, I believe [...a particular handler...] >blocks INT 9 upon receiving its "hotkey" to prevent it from >being seen by other programs. Why not adopt a particular convention for each interrupt that has applications where it is necessary to block the rest of the chain? For example, why not have a global flag that is set when a TSR detects its hotkey? All subsequent programs which obey the convention would then do anything that they needed to (except use the same hotkey) and then pass control along. >I agree with you in wanting some kind of management for TSRs; Me too! -Kevin Kahl mee@ucscb.ucsc.edu
frisk@rhi.hi.is (Fridrik Skulason) (03/28/90)
In article <2129@darkstar.ucsc.edu> mee@ucscb.UCSC.EDU (Kevin Kahl) writes: >Why not adopt a particular convention for each interrupt that has >applications where it is necessary to block the rest of the chain? >For example, why not have a global flag that is set when a TSR >detects its hotkey? All subsequent programs which obey the convention >would then do anything that they needed to (except use the same hotkey) >and then pass control along. Consider the following case when one most certainly does not want any previous interrupt handler to interfere: In many countries a TSR program is used to remap the keyboard in order to provide access to the national characters needed there. For example, here in Iceland when the '/' key is pressed, I want the TSR routine to insert a special character (thorn) into the keyboard buffer. If the TSR routine then passed control to the original INT 9 handler, the character '/' would also be inserted. Of course 'a global flag' would solve the problem, but as the original INT 9 rouine is in ROM, this would require a ROM change - hardly a practical solution. No, I just will have to use the following code, which makes the computer forget that the keypress ever occurred.... IN AL,61H MOV AH,AL OR AL,80H OUT 61H,AL XCHG AH,AL JMP SHORT $+2 OUT 61H,AL CLI MOV AL,20H OUT 20H,AL MOV AX,9102H INT 15H POP AX POP DS IRET -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 |