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