From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
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).

- Raw text -