Date: Mon, 21 Apr 1997 09:45:52 +0300 (IDT) From: Eli Zaretskii To: firewind cc: djgpp AT delorie DOT com Subject: Re: InDOS Flag In-Reply-To: <5jboq2$4o4@usenet.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On 20 Apr 1997, firewind wrote: > I'm writing a TSR using DJGPP. So far, things are going pretty well, but I > have one problem. At the command prompt, the InDOS flag always seems to be > one. Shouldn't it be zero? Am I doing something wrong? The InDOS flag is > (correctly) at zero during idle times of other applications (Telix and > MS-DOS EDIT were two I tried). This is exactly how it's supposed to be; any decent text about TSR programming should explain that. The problem is that COMMAND.COM uses DOS functions to read console input (Int 21h/AH=0Ah, Buffered Keyboard Input), and therefore you are parked inside a DOS call when COMMAND.COM is waiting for input. (Most other programs either use handle-based DOS read function or bypass DOS and go to BIOS or directly hook the keyboard interrupt, that's why you don't see this with most other applications. But DEBUG.COM and FORMAT.COM would show the same behavior as COMMAND.COM.) The good news is that while COMMAND.COM is waiting for input, it calls the Idle interrupt, Int 28h. A TSR should hook that interrupt if it needs to be able to pop up during this time. Note that for DJGPP programs, the complication here is that Int 28h is a *software* interrupt and therefore is not reflected to protected mode by the DPMI host. So you will need to install a real-mode interrupt handler for Int 28h, and that has some nasty limitations (unless you do it entirely in assembly).