This message was edited by dennisparker at 2005-3-21 11:18:14

---

This message was edited by dennisparker at 2005-3-21 11:17:51

---

I have been reminded on numerous occasions that accessing the BIOS functions from the Windows environment will not work. My question is this: Why was it necessary to prevent programmers access to the BIOS in the Windows environment?

: I have been reminded on numerous occasions that accessing the BIOS functions from the Windows environment will not work. My question is this: Why was it necessary to prevent programmers access to the BIOS in the Windows environment?
:
:
:

It's not really Windows operating system that it doing it, but the CPU chip. There are two modes of operation -- real mode, which is the mode old MS-DOS 6.X and earlier used and which you can easily access all bios functions when you want. In this mode, programs are limited to about 640K RAM regardless of how much physicall memory is actually in the computer.

All programs and operating systems (both MS-Windows and linux) start up in real mode. Those programs then switch the cpu into "protected mode" which allows programs to access all the phisical memory that is in the computer. The flip side of this is that the addressing scheme in protected mode is not the same as it was in real mode. So the address of the bios real-mode bios functions are remapped to something else. Also, the protected-mode cpu only allows certain programs (such as device drivers and the os) to directly access the hardware. These resources are "protected" from normal applications, meaning they are forbidden from directly accessing them.

The above is only a very brief answer. More detailed answers can be obtained by studying the operating systems archeture. It applies to all operating systems that run on the PCs.

: It's not really Windows operating system that it doing it, but the CPU chip. There are two modes of operation -- real mode, which is the mode old MS-DOS 6.X and earlier used and which you can easily access all bios functions when you want. In this mode, programs are limited to about 640K RAM regardless of how much physicall memory is actually in the computer.


Mostly right, but there is a few more.

Memory Addresses
x86 processors, starting with the 386, support these addressing modes:
(1) 16-bit real mode
(2) 16-bit protected mode
(3) 32-bit flat protected mode
(4) 32-bit segmented protected mode

: This message was edited by dennisparker at 2005-3-21 11:18:14

---

: This message was edited by dennisparker at 2005-3-21 11:17:51

---

: I have been reminded on numerous occasions that accessing the BIOS functions from the Windows environment will not work. My question is this: Why was it necessary to prevent programmers access to the BIOS in the Windows environment?
:

The processor is put in protected mode in Windows and in other OS's which prevents access to lower memory which is where the vector table is for the interrupts which is why bios functions will not work.

I'm not privy to the specifics of how protected mode works internally since all I have dealt with so far is real mode, but in protected mode you can have a more stable OS due to the way memory is managed. Remember the GPF god, or the blue screens of death in windows95? That OS wasn't in protected mode and you could run those BIOS routines on the earlier windows, but Windows NT you couldn't beause it did run in protected mode. Another reason for it would be since lower memory is protected, some of the older virus programs that took advantage of the hiding spots in lower memory or revectoring an interrupt to point to it's malicious code were no more.

You can still access interrupts however in windows, but to do this you'll have to use the windows API, however, since interrupts are given a lower priority in windows(like ring 3) it would be extremely slow to do so.

I hope that might of answered your question.

This message was edited by dennisparker at 2005-3-21 14:27:2

---

: :
:
: The processor is put in protected mode in Windows and in other OS's which prevents access to lower memory which is where the vector table is for the interrupts which is why bios functions will not work.
:
: I'm not privy to the specifics of how protected mode works internally since all I have dealt with so far is real mode, but in protected mode you can have a more stable OS due to the way memory is managed. Remember the GPF god, or the blue screens of death in windows95? That OS wasn't in protected mode and you could run those BIOS routines on the earlier windows, but Windows NT you couldn't beause it did run in protected mode. Another reason for it would be since lower memory is protected, some of the older virus programs that took advantage of the hiding spots in lower memory or revectoring an interrupt to point to it's malicious code were no more.
:
: You can still access interrupts however in windows, but to do this you'll have to use the windows API, however, since interrupts are given a lower priority in windows(like ring 3) it would be extremely slow to do so.
:
: I hope that might of answered your question.
:
:
Thanks both for the reply. From your response it appears as if it is a memory mapping issue. Do you know if Windows OS ever accesses the BIOS routines (they have to don't they?)? My Windows XP station here at work runs our old 16 bit DOS CAD system. Can I assume that the CAD system does not make any BIOS calls? I can't be sure of course, but it seems unlikely that the old CAD system did not make such calls.

I can certainly understand how the system would be more stable if only one Master Control Program (remember Tron?) directly accessed system resources. I'll Google the issue (almost sounds naughty). Thanks again for the reply.

That old 16-bit CAD program works in Windows os because Windows provides it a MS-DOS emulator in which the program can do all (or most) of the things it did in MS-DOS 6.X os, including the restriction of 640K memory. You can do the same thing if you use a 16-bit compiler such as Turbo C.

Do you know if Windows OS ever accesses the BIOS routines (they have to don't they?)?

Depends on version of Windows. Windows 2000 and XP do not contain any MS-DOS code, so for them the answer is NO.

: Thanks both for the reply. From your response it appears as if it is a memory mapping issue. Do you know if Windows OS ever accesses the BIOS routines (they have to don't they?)? My Windows XP station here at work runs our old 16 bit DOS CAD system. Can I assume that the CAD system does not make any BIOS calls? I can't be sure of course, but it seems unlikely that the old CAD system did not make such calls.
:
: I can certainly understand how the system would be more stable if only one Master Control Program (remember Tron?) directly accessed system resources. I'll Google the issue (almost sounds naughty). Thanks again for the reply.
:

What Stober said is true in that it emulates DOS to run that program. Programs that are compiled in 16bit can still use interrupts, but if you compile your program in 32bit and try those same interrupts it won't allow you. I guess they did it for backwards compatibility reasons.


Do you know if Windows OS ever accesses the BIOS routines


The Windows Kernel, I would imagine, would use low level interrupts to do some tasks in it's source. It would have to control like interrupt 0x09 which is controlled by the PIC to handle keyboard events and so on I would think.