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

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.

- Raw text -