-
The BIOS is not totally ignored in Windows, but I'm not sure about Linux. More than likely through the years, MS wrote a driver to interface with the auto-power on/off feature of the BIOS. You can still generate interrupts in protected mode, contrary to popular belief, but it comes at a performance price. I'm not saying that Windows never fires off interrupts because it does. I know that interrupt 13h is hooked by Windows for hard drive control. If it did not use the BIOS to control the hardware then vendors of drives would have to agree to a standard about how drives are accessed and used. Perhaps they have such a standard and thus Microsoft can now access the drives w/o using interrupt 13h.
Interrupts are generated in 32-bit protected mode via the IDT or interrupt descriptor table which maps into the IVT or interrupt vector table. To execute one you must pop out of PM temporarily, execute, and pop back in. You don't have to setup your selectors and limits again, however, as it is a simple pop out pop in operation. Check the Intel docs concerning interrupts in 32-bit PM as well as interrupts as they relate to the 32-bit protected mode programming paradigm.
As for Linux, I'm not sure how they do all of these things. If you do not use the BIOS for some things, though, you will have devices that just won't function - UNLESS they are geared towards a specific standard - and MS has the monopoly on that one.
The main idea of 32-bit PM is that drivers do all the work. A driver is installed which can then access the device in question directly. The goal is to hide the underlying nitty gritty work that is going on from the end user or even programmer. The bulk of the work is done by the driver which has PL0 access and thus can pretty much do anything it wants.
However on boot-up ALL OS's must get the system into PM because all Intel CPUs start out in real mode. The BIOS looks for the boot sector on drive 0, sector 0 and if not found looks on drive 1, sector 0. The boot sector must end with a special signature or it will not boot and it must be EXACTLY 512 bytes in length. Once the BIOS starts it then loads 512 bytes from sector 0 into memory location 0000:07C00 and performs a jump to that address to pass control to the boot strap code. The boot strap code then will more than likely setup the IDT, GDT, and LDT for use and pop into protected mode ASAP. After doing this, it will probably re-locate itself at another memory address and continue loading more sectors of boot code. Windows 95 took 4 sectors of boot code to get to the kernel load and shell. After re-locating the boot code will then allocate memory for the kernel and load it from the disk into memory and then Windows probably fires off it's pre-emptive multi-tasking environment.
The whole process can be quite complex.
-
I learned some good things:
It is up to OS to use BIOS methods or not
System should go from PM to RM and bask to perform a BIOS call.
What about x64?