Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: Dos File Access In TSR's
Message-ID: <24a24caa@ralf>
Date: 23 Jun 89 14:43:54 GMT
Sender: ralf@b.gp.cs.cmu.edu
Organization: Carnegie Mellon University School of Computer Science
Lines: 18
In-Reply-To: <491@enprt.Wichita.NCR.COM>

In article <491@enprt.Wichita.NCR.COM>, gharring@enprt.Wichita.NCR.COM (Gary Harrington) writes:
}To allow a TSR program to operate safely (and even do file I/O) without 
}having to worry about DOS re-entrancy problems, several undocumented 
}features of DOS can be used.  These undocumented DOS features are:
}
}        1.  The COMMAND.COM Background Task:  INT 28h is called by
}            COMMAND.COM while it is waiting for input from the keyboard.

Minor nit: this is internal to IBMDOS.COM.  Any program that calls the
buffered input (INT 21/AH=0Ah), such as DEBUG or EDLIN, will cause INT 28h to
be called repeatedly while the INT 21h call is waiting for keystrokes.

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school)
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/46
			Disclaimer? I claimed something?
"When things start going your way, it's usually because you stopped going the
 wrong way down a one-way street."