🚀 go-pugleaf

In article <5187@trantor.harris-atd.com> sonny@trantor.harris-atd.com (Bob Davis) writes:
>>If you must use the timer interrupts, appending to int 8 is preferrable 
>>than attaching to int 1Ch.
>	Could you please elaborate. Other things I have read (e.g. Dettmann's
>_DOS Programmer's Reference 2nd Edition_, page 417) recommend hooking to
>1Ch in preference to 08.

Int 1Ch is not very consistent. In most machines, EOI is supposed to
have been acknowledged when int 1Ch is called, but this is not universally
true. Supposedly on some Compaq(?) machines, the EOI is acknowledged
AFTER int 1Ch. Thus if you stay on thinking that EOI has already been
acknowdged, the machine would hang. (I am not sure whether this is true
for all Compaq machines. It was obviously a bug that could have been
corrected. I can dig up the reference if neccessary.)

Moreover, if you would ever trace through the int 8h and int 1Ch
handlers of Sidekick (SK), you'd find something interesting. The int 8
handler has something at its beginning like:
     call  cs:old_int_1C
     call  cs:old_int_8
     ...
And its new int 1Ch handler is simply:
     iret
This means even on a machine where you can normally expect EOI to have
been ack'ed, it wouldn't be if SK is loaded after you. (Most of the
problems with int 1Ch is with SK.)

I have always taken it as a challenge to make my programs compatible
with SK, but those guys are making it harder and harder. Maybe this is a
dumb question, but is anyone out there still using SK? 

> I confess that I do not understand a preference
>for EITHER over the other, since 1Ch is called by 08 and both block further
>hardware interrupts until done.

Not true. Hardware interrupts are blocked only when EOI hasn't been
acknowledged (assuming that interrupt flag is enabled).

>>Keyboard interrupt (09h): this only happens when a key is struck. System
>>could also be in unstable conditions (for this reason, I don't recommend
>>doing anything useful(!) in the background by hooking to any hardware
>>generated interrupts).
>	Even if adequate safeguards against DOS re-entrancy are employed?
>Which you have to do - do you not? - even when hooked to INT16.

DOS re-entrancy is not the only consideration. It's the infinutely
unpredictable nature of the hardware interrupts. It could happen when
the disk head in the middle of writing something, or it could happen in
the middle of a lower-priority hardware interrupt. You can check for
most-likely problems, but you can't possibly check for everything. (I am
beginning to sound like a mathmatician here, which I am not. :-) )

>>What's so good about int 16h?
>>- it's (almost) always there. Most of the time it is called even more
>>  frequently than the timer interrupts. It's called whether of not a
>>  key has been hit. The only times int 16h is inactive is when the 
>	Are you saying that DOS frequently calls this INT16 even though
>no INT09 (Key press hardware interrupt) has occurred? Why does it do that?

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

>>You should still carefully check the DOS flags (InDOS flag and Critical
>>Error flag) and maybe even the interrupt controller status. 
>	Just as if you had triggered on INT09, for example? Doesn't
>this somewhat decreased the presumed advantage to hooking INT16?

Cautionary steps should be taken however you do it, it's the likelihood
of running into real problems that is different.

>>                                                            Someone
>>could have carelessly issued an int 16h from inside a hardware
>>interrupt (the same risk with simulated int 28h's).
>	What is the bad thing about calling INT16 from inside a hardware
>interrupt handler?

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've written TSRs that are triggered by hardware signals. I simply let
the hardware interrupt handler set a flag, and have the int 16h handler
to check for this flag and then do the real work. I found this to be the
best solution, especially on a system with a dozen TSRs loaded.

yawei