From:	vladr AT usa DOT net (Vlad R.)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Question about djgpp's int-wrapper
Date:	9 Jun 2002 18:19:52 -0700
Organization:	http://groups.google.com/
Lines:	65
Message-ID:	<fc5733ab.0206091719.322f6c70@posting.google.com>
References:	<5 DOT 0 DOT 2 DOT 1 DOT 2 DOT 20020609104552 DOT 009e64e0 AT pop DOT gmx DOT net> <advaa1$cgm$1 AT antares DOT lu DOT erisoft DOT se> <DILM8.896$ca2 DOT 121610 AT newsfep1-win DOT server DOT ntli DOT net>
NNTP-Posting-Host:	207.107.235.190
X-Trace:	posting.google.com 1023671992 10160 127.0.0.1 (10 Jun 2002 01:19:52 GMT)
X-Complaints-To:	groups-abuse AT google DOT com
NNTP-Posting-Date:	10 Jun 2002 01:19:52 GMT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

For the record: starting with Windows XP there is a built-in
(undocumented) workaround to this problem, but you have to perform a
system call from within NTVDM.EXE in order to activate it
(NTDLL.DLL:NtVdmControl with function 0x0d and parameter 0x01
activates the workaround, and function 0x0d with parameter 0x00
deactivates it).  Still a big pain, though.

V.

"Lawrence Rust" <lvr AT nospam DOT softsystem DOT co DOT uk> wrote in message news:<DILM8.896$ca2 DOT 121610 AT newsfep1-win DOT server DOT ntli DOT net>...
> "Martin Stromberg" <eplmst AT lu DOT erisoft DOT se> wrote in message
> news:advaa1$cgm$1 AT antares DOT lu DOT erisoft DOT se...
> > Martin Steuer (martinSteuer AT gmx DOT de) wrote:
> > : 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.
> >
> > 1. Where does it say that?
> 
> http://www.delorie.com/djgpp/doc/dpmi/ch4.4.2.html
> 
> 
> > 2. IIRC, if sti is a priviledged instruction (because of IOPL < 3),
> > then iret and popf are too. So why would an emulated sti set IF and
> > not an emulated iret or popf?
> 
> If you look at Intel's IA32 architecture manual:
> 
> ftp://download.intel.com/design/pentium4/manuals/24547107.pdf
> 
> you'll see on page 3-49 that in protected mode, iret only restores
> EFLAGS(IF) if CPL <= IOPL.  This is also true of popf.  So if the code is
> run on a system such as Windows NT, 2K or XP where CPL is 3 and IOPL is 0
> then the task will be left with virtual interrupts disabled.  The system
> will remain responsive but the task will not receive any more interrupts
> :-(.
> 
> However, sti signals GP(0) if CPL > IOPL, which on NT is handled by the
> NTVDM and will enable virtual interrupts to the task.
> 
> IMHO this is a design fault in the IA32.  The correct action would have been
> to signal GP(0) if EFLAGS(IF) is altered.  This gives the host OS (NTVDM)
> the chance to update the state of virtual interrupts for the task.
> 
> This design fault prevents many protected mode games, like Doom and
> DukeNukem3D, from running with sound on NT, Win2K and XP.  In many cases the
> sound driver disables interrupts around sound card h/w accesses with code
> like...
> 
> pushf
> cli
> ...
> popf ; Restore IRQ state
> 
> Here the cli traps to NTVDM which obligingly disables the virtual interrupt
> state.  However the popf that should restore the interrupt state does
> nothing so virtual interrupts remain disabled.
> 
> If you want to run these games with a sound card emulator like SoundFX
> (www.softsystem.co.uk/sndfx202.zip) then it's necessary to patch the code to
> remove the cli opcodes.

- Raw text -