🚀 go-pugleaf

I am not sure if I should advertise this, but in my opinion, the best
place to do background processing is the BIOS buffered keyboard
interrupt (Int 16H). Reasons:

Timer interrupts (08h and 1Ch): they are the most consistent - occur
once every 1/18.2 seconds. Disadvantage: system could be in very
unstable conditions, such as you may be in the middle of a disk
interrupt. If your handler is prepended, you can't stay on for long. 
Some people also claimed that TSRs that hooks to timer interrupts 
tend to steal a lot of CPU time unneccessarily (may or may not be true). 
If you must use the timer interrupts, appending to int 8 is preferrable 
than attaching to int 1Ch.

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

DOS Idle interrupt (28h): as many have pointed out, this only occurs
when DOS is busy waiting for keyboard input. Moreover, if a TSR pops
itself to the foreground using int 28h as the trigger (and subsequently
uses int 16h to read keystrokes as many TSRs do), you don't get any more
int 28h's even though the system is essentially in the same condition.
Some TSRs popped up this way choose to simulate the condition by issuing
int 28h's themselves, but simulated calls can't really be trusted here.

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 
  foreground program is doing some CPU or disk-intensive stuff, at which
  point you probably really shouldn't be interrupting anyway;
- the system is stable. Int 16h is a software interrupt, which means 
  the foreground program is specifically requesting the interrupt, so
  it must be safely interruptable. In terms of DOS -- it should be in
  the same condition as int 28h, if the int 16h called was from DOS.
- you can stay on relatively long -- just not too long to cause a 
  significant delay in keyboard response for the user. 

You should still carefully check the DOS flags (InDOS flag and Critical
Error flag) and maybe even the interrupt controller status. Someone
could have carelessly issued an int 16h from inside a hardware
interrupt (the same risk with simulated int 28h's).

Comments/discussions are welcome.

yawei

p.s. Assembler programmer with 4+ yrs experience is looking for a job. 
I've been mostly writing TSRs and small utilities. I am looking for a
part-time/contract job to get through school, and maybe a permanent job
after me getting my MS degree. If you know of a position opening, do let
me know. Thanks. (I am best at Assembler and C.)