🚀 go-pugleaf

In article <1991Jan6.001935.25969@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes:
>In article <5187@trantor.harris-atd.com> sonny@trantor.harris-atd.com (Bob Davis) writes:

	The attributions for PRIOR posts are somewhat scrambled, so I 
indicate them.

[yawei]:
>
>That's correct. Int 16h is not coupled to int 9 (unlike int 1Ch to int
>8). Int 16h is an extension of the foreground software. Most programs
>spend most of their time repeatedly calling int 16h. They do this
>because they want to find out whether int 9 has placed any keystrokes in
>the buffer. :-)  [Well, most programs actually call DOS, which in turn
>calls int 16h.]

	So, DOS does not, on its own, initiate the calling of INT16 -- a 
foreground program is actually doing it? The background task (a print 
spooler, for example) will simply stop being serviced if the foreground 
program terminates and a return to the DOS command prompt occurs while work 
yet remains for the background task, will it not?

---
[yawei]:
>>>                                                            Someone
>>>could have carelessly issued an int 16h from inside a hardware
>>>interrupt (the same risk with simulated int 28h's).

[Davis]:
>>	What is the bad thing about calling INT16 from inside a hardware
>>interrupt handler?

[yawei]:
>
>I am saying that it's bad to pop up a window from inside a hardware
>interrupt, do some useful work, and maybe access int 16h and/or DOS disk
>services. If we agree to avoid this then there's not much reasons left
>to call int 16h from inside a hardware interrupt.
>

	I guess everytime you have said "hardware interrupt", I have
thought of INT09, the keyboard hardware interrupt, and I believe now
you must be thinking of things like serial ports and disk 
controllers. Certainly I agree that trying to tie background processing
to serial port and disk controller interrupts sounds like a bad idea.
But many TSRs pop-up and can do their useful processing inside
the INT09 hardware interrupt handler. And some further call INT16, 
Function 2 from inside the INT09 hardware interrupt handler to look at 
the keyboard shift flags to determine if the hot-key has been pressed.

	Again, let me thank you for your interesting post and responses
to my questions. And I do think your idea of hooking INT16 to provide
service to a background task has a lot to recommend it. My major
remaining concern is that the background task evidently stops being
serviced if no foreground task uses INT16 to interact with the keyboard.

_____________________________________________________________________________
Bob Davis, UofALA alum \\ INTERNET: sonny@trantor.harris-atd.com  |  _   _  |
Harris Corporation, ESS \\    UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | |
Advanced Technology Dept.\\ AETHER: K4VNO          |==============|_/\/\/\|_|
PO Box 37, MS 3A/1912     \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| |
Melbourne, FL 32902        \\  FAX: (407) 729-2537 | FOR MYSELF.  |_________|