From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Question about djgpp's int-wrapper Date: Sun, 09 Jun 2002 12:21:03 CDT Organization: Rice University, Houston TX Lines: 20 Message-ID: <3d038e7f.sandmann@clio.rice.edu> References: <5 DOT 0 DOT 2 DOT 1 DOT 2 DOT 20020609104552 DOT 009e64e0 AT pop DOT gmx DOT net> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1023643630 13871 128.42.105.3 (9 Jun 2002 17:27:10 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 9 Jun 2002 17:27:10 GMT X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > >If interrupts were enabled before the interrupt came along, the iret > >that returns control to the interrupted code should enable them again > >as the IF is set in the image on the stack. > > The problem i mean is that the DPMI Specification says that non-priviledged > code may not be able to alter the IF via 'popf' or 'iret'. > Therefore the DPMI Spec. suggests to insert a 'sti' before an 'iret' in > hardware interrupt handlers, because 'sti' is a priviledged instruction it > will be trapped and the DPMI Host will then execute an 'sti' in Ring0. Yes, the whole thing is a mess. But the DPMI provider reflects these interrupts to you (unless they were chained) - and the Windows DPMI providers have done things internally to try and fix the mess. Adding a STI can cause problems also when chaining or fcall'ing (and you aren't ready for them to be enabled yet). There is no good universal fix, We've recently found out that Windows 2000 seems to ignore the DPMI 0x9 call to block interrupts (and this interrupt is actually recommended in the spec to avoid the emulation overhead of STI/CLI).