Xref:	news-dnh.mv.net comp.os.msdos.djgpp:3639
Path:	news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!academ!news.sesqui.net!rice!news!sandmann
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Is DPMI screwing things up?
Date:	Tue, 05 Dec 1995 07:52:08 CST
Organization:	Rice University, Houston, Texas
Lines:	16
References:	<49uj8t$hk0 AT news DOT cea DOT fr> <49v1ai$atf AT odin DOT diku DOT dk> <4a0041$oqt AT nuke DOT csu DOT net>
Reply-To:	sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host:	clio.rice.edu
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

The DPMI specification states that hardware interrupts which happen in 
real mode will be reflected to protected mode if a PM handler is installed.
I don't know what your program does while waiting for characters, but if
this waiting is in PM then you should almost never see a RM handler called
anyway.  If you are worried about response, your PM handler would handle
the interrupt, EOI the controller, then IRET (and no mode switches would
be needed at all).

The PM interrupt hook procedure modifies the PM IDT to point to your routine
and also modifies the RM vectors to point to a reflection routine.  If you
set the RM interrupt second, it would not reflect, and you should be able to 
have a routine which buffers the characters in low memory.  Make sure you
are setting the right RM interrupt - the primary PIC is sometimes 
revectored.  There may be some glitch in CWSDPMI which prevents the RM
routine  from being hooked, but it should work elsewhere if this is the
only problem.

- Raw text -