Ramon van Handel wrote:
> Ulrich Weigand wrote:
> > Indeed.  Still, the only software interrupts used in Windows *are* the
> > BIOS and DOS interrupts
> 
> Really ?  That's interesting... I know very little about windows
> internals.  Does windows use call gates for doing system calls ?

Well, what I wrote wasn't completely correct, it seems :-/

First of all, in Windows NT, you do have a special software interrupt
that is used inside of NTDLL.DLL to switch from ring3 to ring0;
this works basically the same way as in Linux, only that int 0x2e
is used for this purpose.

In Windows 95/98 it's a little more complex.  Here, a large part
of the 'OS' is actually implemented in ring3 itself, so there are
no ring transitions involved at all.  Where the ring3 kernel does
need to call the ring0 kernel, is has basically two methods: either
it performs an operation that is virtualized by the ring0 kernel
(software int, i/o access, memory access); in this case the ring0
kernel gets invoked via the fault handler.

Or else, it calls a 'ring0 callback'.  This is just a far call to
an address that was announced to ring3 by the ring0 code.  What
exactly this address is, is undocumented, but in fact it happens
to point to a normal ring3 code segment containing an int 0x30
instruction.  So you might say that it does indeed use a software
interrupt ...

Unfortunately, this doesn't help a lot for our purposes:  most
of the interrupts are still the DOS and BIOS ones.  And even 
those that are not, the 0x2e of NT and the (undocumented) 0x30
on Windows 95, are nevertheless in the range conflicting with
hardware interrupts on Linux ...  (Well, on uniprocessor machines
0x30 doesn't, but that probably doesn't help a lot.)

> So windows emulates the BIOS/DOS calls in protected mode ?
> I never knew that :)

Windows 95/98 most certainly emulates those interrupts in Win16 code.
In fact, even Win32 code could perform those interrupts, which has
the only drawback that the implementation of those interrupts
assumes a stack frame as would result from a call from 16-bit code;
so upon return from the interrupt, you are hosed :-/

> But if that's true, how can windows use the overlapping
> exception/fault vectors ?

Black magic?  Actually, a much larger problem would seem to me that
the PIC vectors are not remapped; this means that IRQ 0-7 generate
interrupts 0x08-0x0f as set up by the BIOS, overlapping a rather 
important range of exceptions ...   I have no clue how this is sorted 
out, but somehow it appears to work :-/

Bye,
Ulrich

-- 
  Ulrich Weigand,
  IMMD 1, Universitaet Erlangen-Nuernberg,
  Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688

Reply via email to