www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/04/21/02:56:43

Date: Mon, 21 Apr 1997 09:45:52 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: firewind <firewind AT constellation DOT stu DOT rpi DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: InDOS Flag
In-Reply-To: <5jboq2$4o4@usenet.rpi.edu>
Message-ID: <Pine.SUN.3.91.970421094517.2725B-100000@is>
MIME-Version: 1.0

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019