Re: Q [x86] INT in protected mode?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/11/04 

Date: Wed, 11 Feb 2004 04:43:24 -0000

Y wrote:
> Simple question (I guess) from a newbie. Can I, or can I not, call
INT XX
> to access the bios in protected mode? I have this idea that I can't
because
> when I try (linux) I get a segfault. If I can't do it that way then
what is
> the right way to access BIoS info?

No; Other than some "exceptions" wolfgang alluded to, the BIOS
routines are all written for real-mode...a fundamental problem here is
that real-mode addressing is simply _incompatible_ with protected mode
addressing...no useful service is going to be able to go for too long
without accessing memory (and, also, it needs to know that it's
accessing the memory it expects to be accessing but, with protected
mode, the addressing is all "virtual" and some OS or system software
that initiated protected mode is able to set up _any_ memory scheme it
likes...so, there's no guarantee that if a BIOS routine was to write
to 0000A000h of some arbitrary "segment" that it would get the address
it expects - the start of the VGA graphics buffer - because the
"segments" can be set up to reside _anywhere_ and be of any size,
including being "not present" in order that they can be shifted in and
out from a disk file for "virtual memory"...so there's no guarantee
that it's even going to be in RAM, so to speak, as "virtual memory"
can _exceed_ RAM that some of it - though this continually changes -
must be constantly _disk-based_ and not even is it RAM ;)...

Hence, to all intents and purposes, the BIOS becomes _useless_ in
protected mode...there are exceptions of some BIOS routines including
methods for some protected mode access (for example, the VESA VBE
video BIOS routines have a "dual mode" interface...to use these, you
must set up "segments" in a certain way, though, so that the BIOS
routine can be _sure_ that it really is accessing the memory it
expects to...it's also only _16-bit_ PM because real-mode is 16-bit
and the same code has to be run for both :)...

When protected mode operating systems came about, they all simply
moved to using "device drivers" instead...and the BIOS was more or
less abandoned for protected mode...if the OSes were all using there
own routines, what was the point of expanding BIOS to protected mode?
And the BIOS routines do have to reside on ROM chips and in quite a
small memory space (to be useful to real-mode), so it's difficult
enough fitting in everything as it is, without ideas about duplicating
all the code again for protected mode operation...the idea of the BIOS
was simply "given up" when things went protected mode, as "device
drivers" could solve the problem and were software (easy to download
and upgrade off a website, for instance :) that wasn't limited to
occupy a small amount of RAM to be real-mode compatible...

Unfortunately, a consequence that probably wasn't realised (or they
just didn't care) was that the "device drivers" of all these OSes were
_proprietary_...they didn't "standardise" them, as the BIOS
automatically was (the BIOS was kind of a set of "device drivers" in a
"proto-" / "primitive" sort of way ;)...this has meant that Microsoft
got into the lead, made every hardware manufacturer their personal
slaves (if they don't support Windows, then as that's the OS on 99% of
PCs, there's no way they'll sell their hardware) and we have a classic
"unfair fight"...as if writing an OS wasn't hard enough already,
Microsoft have their "monopoly" held up by the fact that hardware
manufacturers automatically write the Windows drivers and make them
available...remembering that these "device drivers" are all in a
proprietary format that is _only_ useful to Windows (although, the
"ReactOS" project is trying to address this in the sneaky way of
making their free OS a "compatible clone" of Windows that people's
current Windows drivers should work happily on ReactOS...a "steal the
carpet from under them" approach to tackling Microsoft's monopoly ;),
this effectively makes them "local branch offices" of Microsoft in
helping them keep "dominance"...I mean, such is the control they have
that, yup, there's little "Windows keys" on the keyboard (never used
to be there, Microsoft heavy handed that lacking these keys was not
"designed for Windows" and you don't get the badge...once some
keyboard manufacturers buckled to the pressure and users got used to
seeing these keys, they've all been more or less forced to follow
suit, just in case users get the wrong idea that a keyboard without
"Windows key" won't work with Windows)...and some bloody "designed for
Windows" badge on the box...and the thing that is crossing a line for
me is that Microsoft are also getting their Windows licences _stamped_
permanently onto boxes these days, as a "piracy measure",
apparently...reformat your hard drive and use only Linux? Doesn't
matter, your PC box is still tainted by the Windows "666 birthmark"
stamped hard onto the case itself...

Linux, though, also uses "device drivers" and the BIOS is gone, as
well...there is no real difference in approach, just "ethics" with the
"open source" attitude...

Hence, the BIOS just isn't there at all in protected mode...there is
no real "right way" to access from protected mode because it doesn't
do anything in protected mode anymore...the "device drivers" take up
that functionality instead...and to use those in the "right way" is to
go via the OS API and that usual stuff...

To be fair, there is a reason why these systems insist on
this...unlike DOS, these modern OSes are _multi-tasking_...worse,
_pre-emptive multi-tasking_ so that a "task" could lose the CPU at any
point, depending usually on some real-world timer signal...hence, if
any two programs were accessing a device in a more "direct" manner
then their accesses would "overlap" and would no end of confusion
(and, likely, a nasty crash and reboot almost immediately)...hence,
the "device driver" isn't only there to take the place of the BIOS in
protected mode to provide "portable" access to hardware devices, it
also regulates access to shared hardware...multiple programs can tell
the device driver what they want to do but only the device driver
actually accesses the hardware so it can queue up and synchronise
requests, divide up the video screen, etc. so that multiple programs
can share hardware under a pre-emptive multi-tasking system without
conflicting with each other all the time...

Anyway, yeah, no BIOS under protected mode, basically (except for a
few isolated examples with their own special methods of working under
PM)...if you're looking to do this kind of thing, then you must take
"other methods"...the device drivers are the "BIOS substitute" here
so, I suppose, look into the device driver information a little
bit...it's possible, sometimes, to talk more directly to them (IOCTRL
stuff) or, to be even more direct with the hardware again, you write
your own device drivers but that, of course, lower-level than the BIOS
and not "device-independent"...

Of course, there's always V86 mode to consider too...that CPU mode is
still in protected mode but the addressing works as it did under
real-mode...so, via this mode, the BIOS could be accessed (and
"protections" still enabled that you can "catch" and "intercept"
things that the BIOS might be doing and "re-direct" it to device
drivers...this is, of course, how something like Windows runs a DOS
prompt and older DOS software...this, though, is effectively just an
"emulation" using V86 mode...Intel, in fact, added the V86 mode, aware
that the protected mode was a "jump" so they created this "backwards
compatibility" mode to allow access to older software under protected
mode...hence, until you look into this stuff, you might see a DOS box
or "dosemu" running and think "hey, look, the BIOS is still there in
protected mode and can be used"...this, though, is really a kind of
"illusion"...the BIOS is "incompatible" with protected mode, in
fact...what happens there is that the CPU is switched to the special
"compatibility" V86 mode and Windows or Linux "intercepts" access to
hardware and "re-directs" it, where necessary, to the usual Windows /
Linux device drivers in the background...this all runs inside a
"virtual machine" of V86 and a "monitor"-like program that wraps this
to "convert" the hardware stuff over into device driver terms...and
that kind of thing...V86, though, is neither real-mode nor PM but a
kind of "bit of both" invented to allow the more modern PM OSes to
somehow be able to run older real-mode software (well, Intel realised
that asking everywhere to throw away all their older software was
unreasonable so added this V86 mode to allow it to be kept and still
used in some "DOS emulation" like a Windows DOS box or Linux "dosemu")

Under strict PM, the BIOS is, to all intents and purposes, "dead",
unfortunately :(

Beth :)