Xref: utzoo alt.msdos.programmer:1320 comp.sys.ibm.pc.programmer:195
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!vsi1!teraida!netcom!hinton
From: hinton@netcom.UUCP (Greg Hinton)
Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer
Subject: Re: idling in the interpreter
Message-ID: <8160@netcom.UUCP>
Date: 1 Mar 90 23:46:32 GMT
References: <PAS.90Mar1120125@saffron.lcs.mit.edu>
Organization: NetCom Public Access Unix -- San Jose, CA
Lines: 30

In article <PAS.90Mar1120125@saffron.lcs.mit.edu> Paul A. Selkirk writes:
>
>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume
>2.x or 3.x) is idling in the command interpreter, or executing a program?
>
>       .... rest omitted ....

I think you can accomplish what you want by using three undocumented
DOS functions:

	1)	int 21h function 34h -- Get DOS Busy Flag.
		on return, ES:BX will point to DOS Busy Flag; if this
		byte is nonzero, a DOS function is in progress.
	2)	int 28h -- DOS Safe Interrupt.
		this interrupt is called by DOS whenever it's sitting
		idle, waiting for keystrokes.
	3)	int 21h function 62h -- Get Current PSP.
		on return, BX will contain the current PSP segment.
		Prior to DOS 3.00, use function 51h.

When your TSR first executes, get the address of the DOS Busy Flag & store it
for future use (you don't want to have to call function 34h each time).
Also latch onto interrupt 28h, so you'll be called when DOS is idle.

Then, each time your TSR is activated later, check the DOS Busy Flag byte.
If it's zero, call Get Current PSP and peek around in its address space
to see if it's COMMAND.COM.

I haven't tried any of this, but it seems to me that it should work.
Let me know how it goes.