Mail Archives: djgpp/2000/01/30/16:11:36
The original message was received at Sun, 30 Jan 2000 09:16:00 -0800
from spam-protect AT irs-net DOT com [XXX.XXX.XXX.XXX]
----- The following addresses had permanent fatal errors -----
</dev/null AT irs-net DOT com>
----- Transcript of session follows -----
550 </dev/null AT irs-net DOT com>... User unknown
On 30 Jan 2000, Martin Stromberg wrote:
> But I wondered what would happen if the processor was in some DOZE
> call, an interrupt comes along (I'm assuming that DOZE can be
> interrupted) which some code (not necessarily DJGPP code) handles by
> invalidating the CS selector and then returns to the DOZE call. What
> would happen now (in the DOZE call)?
The routines in any OS don't invalidate the CS. When Windows (or any
32-bit OS) is interrupted, the CS is filled from the IDT descriptor or
from the value in the TSS. At no point of time can the CS contain garbage.
If anything attempted to load garbage into CS, that would immediately
cause a GP Fault (which could crash Windows ;-)).
So, it is not possible for any program to invalidate CS. If Windows tries
to get back to the original process, the retf or iret would itself cause
GP Fault. So, there's no way any such thing can take place.
- Raw text -