Hi,
> In protected mode popf _never_ traps (except for stack fault), from
> the Intel Programmers Manual:
True.
> > pushf
> normally without exception in protected mode
> > cli
> this gives "general exception" in user space, because CPL>IOPL.
> DOSEMU does _not_ set IF due to this
But the CLI *does* modify DosEmu's internal representation of the "emulated"
IF, right? It is understood that CPL>IOPL, therefore everything is
virtualized. I mean, after this "cli" the "emulated" INT8 (timer/IRQ0)
should not be delivered (i.e. the DOS app's INT8 handler will not get
called) until a STI is invoked in the DOS app.
> > ...
> > popf ; restores if to previous value
> this gives no exception, but leaves IF unchanged (set).
However, DosEmu's *internal* ("virtual") IF remains cleared (from the CLI
above), right?
> > my question is: how does dosemu work around this limitation?
> It should not have any effect except that you can't "protect" parts
> of your code from being really interrupted within CLI/STI brackets
I'm talking strictly "emulation". My intention is *not* performing a real
CLI/STI to disable real hardware interrupts on the physical machine. I am
simply concerned with the fact that, because popf is not trapped, DOS games'
idea of what the interrupt state currently is (enabled/disable) will get out
of sync with what DosEmu uses to decide whether or not to deliver emulated
IRQs to the aforementioned game(s). This why on Windoze NT Doom locks at
startup, I presume waiting for a flag to be set from an ISR (but NT's NTVDM
still has its internal IF representation cleared by the cli because popf was
not trapped, so no ISRs get called).
> [...] we may keep the DPMI programm with emulated interrupts disabled
until
> the next signal that comes through.
So, if I understood right, in the ASM example above (pushf/cli/.../popf)
DosEmu will indeed clear the virtual IF when CLI is executed, will *not* set
it back upon POPF (no trap), but *will* set it back unconditionally at some
point (when "the next signal" comes through?) By "next signal" do you mean
the next emulated IRQ (e.g. SBEmu interrupt or virtual IRQ0 from the
emulated PIT?) If so, then CLI effectively does nothing since the next
(emulated) hardware interrupt will be delivered independently of the state
of IF. ?:/
Thanks!
Vlad.
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
