Date: Mon, 10 Apr 2000 19:54:51 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Kalum Somaratna aka Grendel <kalum AT lintux DOT cx>
cc: djgpp AT delorie DOT com
Subject: Re: HARDWARE INTERRUPT HANDLING BY CWSDPMI
In-Reply-To: <Pine.LNX.4.10.10004101933460.1286-100000@darkstar.grendel.net>
Message-ID: <Pine.SUN.3.91.1000410195120.26090C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 10 Apr 2000, Kalum Somaratna aka Grendel wrote:

> > However, in this case, we have the opposite situation: the handler is
> > a real-mode one (a real-mode TSR), while the CPU stays in protected
> > mode most of the time because a DJGPP program runs in the foreground.
> > A real-mode handler worn't help here, since most DPMI servers will
> > call the protected-mode handler first, and only then reflect to the
> > real mode.
> 
> Would it be possible then for him to rewrite the 16-bit TSR as a
> protected mode TSR  with a real mode handler too..then wouldn't that avoid
> the problem...

That is possible, but not too easy: protected-mode TSRs are a pain, and 
also highly unportable (since most DPMI servers don't support the 
necessary functions, which are only part of DPMI 1.0 spec).

Note that in many cases, installing a protected-mode interrupt handler is 
all you need to avoid overhead: if the foreground program stays in 
protected mode most of the time, there's no reflection involved.  See 
section 18.11 of the FAQ for more details.