Re: BIOS

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

Date: Sat, 24 Apr 2004 12:24:55 +0100

Profetas wrote:
> I guess that coding assembly in Linux is different because
> the system calls have been implemented differently. (right?)
> What is I only use the BIOS functions? is that allowed?
> if not. is there any simulator so I could code using the standard
x86 and
> run it in linux?
> Does the OS use the BIOS functions or they have their own
implementation?

The BIOS routines are (except for one or two very minor exceptions)
"real mode only"...protected mode operation uses a vastly different
and quite incompatible form of "addressing" that renders the BIOS
unuseable...well, there are possible ways to get around this, such as
V86 mode (as employed by Windows' DOS box...an "in-between" mode where
the machine acts like "real mode" but is also in "protected mode" at
the same time...yes, this mode was invented by Intel as a means to
"bridge the gap" between the two, knowing how the change of addressing
is not at all "backwards compatible"...but they had to do it,
really...real mode addressing was a terrible, horrible "hack" that was
placing severe limits on using the full memory capacity...plus, they
want to introduce an on-chip MMU and "protections" and so forth, to
keep the chip "respectable" in modern times that it can do all the
"virtual memory" and "multi-tasking" stuff people expect to see :) or
switching back and forth between real mode and protected mode all the
time (messy, problematic and slow)...

Hence, the "modern" OSes like Linux and Windows - at least in most
part - simply switch to protected mode and, indeed, use their "own
implementations"...these are the "device drivers" for these OSes that
we hear all about...they are, basically, a "BIOS replacement" for
protected mode operation (but, yes, also going beyond the BIOS ever
did in defining a model of operation that works under multi-tasking
environments...the BIOS, like DOS, very much presume "single tasking"
in their operations, anyway, that even if you could get access to
them, you might find that it's not as clever an idea as you might
initially think on any "shared" devices :)...

Unfortunately, unlike the BIOS, no "standard" was ever agreed...device
drivers need some basic OS services too and no "standard" about that
was ever agreed either...hence, unlike the BIOS, which _was_
standardised (not really by "agreement", mind you...more by following
IBM's footsteps with "clones" of their original PC...when IBM ceased
to be important in the "leadership" capacity...well.. ;)...these
"device drivers" may just be the modern "replacement" for the BIOS
effectively (just distributed as software rather than on a ROM
chip...the real mode BIOS can be used for booting up the machine,
after all, because PCs still boot into "real mode" for "compatibility"
reasons...so, our protected mode OS can operate with the "real mode"
BIOS stuff until it finally loads in its own "device drivers" :)...but
they are all "proprietary"...a Windows device driver is for
Windows...a Linux device driver is for Linux...a BeOS device driver is
for BeOS...etc., etc....and, as the saying, "never the twain shall
meet"...

For Microsoft, this suits them just fine - and they won't be in any
hurry to sign onto some "universal device driver" model unless forced
upon them by some future court case - as they have monopoly and they
have full coverage of device drivers and Windows is such an important
target, they themselves don't actually have to do any of the work on
this usually...that is, hardware manufacturers will automatically
create the drivers because, well, 90% or so of PCs carry Windows...so,
no Windows device drivers, not going to sell too many "units" of your
hardware to PC customers (and you'll really want to sell to them
mostly because, well, there's so many of them to make profits
from...and next to nothing of anything else to cater for out there
;)...

The ReactOS project is kind of "cheeky" in its solution to this
problem: It'll be an open source "binary compatible" clone of Windows
so that it can just use Windows device drivers "as is"...a funny and
clever solution, _except_ that it will mean that ReactOS _is_
Windows - a "clone" of all the _bad_ design and _bad_ implementation,
as well as any "good" they might be able to find hiding under a rock -
to all intents and purposes, just NOT "Microsoft Windows"...rather
"Free Windows", if you like (it would probably even be called
"FreeWindows", other than Microsoft get really annoyed and take out
court cases for anyone going near the "Windows" name...though MS lost,
they tried to do this with the "Lindows" name...but it was a sensible
judge: "hang on, the word 'window' is part of the English
language...you know, that see-through thing you find in walls
sometimes that lets the sunshine in...it also refers to a generic
'area' thingy in computing, which was a term long in use before you
came along...by what right - other than thinking money will buy you
anything - do you think you've got any cause to complain? What word do
you think you 'own' next? Are you going to try to prohibit parents
calling their children 'Bill' or 'William', just because it's your
name? Are you going to release software called 'Microsoft Hello' and
then ban anyone from ever saying 'hello' to each other ever again
without written permission from you? Geez Louise, you really _do_
think you own the world, don't you?" ;)...

Anyway, as you talk about "system calls being different" then it
should be noted that Linux does fall into the wider UNIX group of OSes
that all use a "compatible" method (at the C level, mind you...but the
thing is written in C and C was invented to write UNIX, so not much
surprise there :)...the usual GUI for Linux is X-Windows, which is a
GUI protocol exported to practically every machine there is...you'll
notice that internet address have a "forwardslash"
UNIX-style...perhaps you have "MAKE" for developing your Windows
software, which was originally a UNIX tool (along with a whole bunch
of other nice programming tools like "GREP" and so forth :)...

The point I'm striving to get at is that, seeing Windows, it's easy to
look at Linux and say "oh, it's done differently"...you know, as if
"Linux" is the oddball here for not being like Windows...not
so...Windows is the OS that avoids "standards" and puts up "city
walls" around itself to "protect" all the source code and
everything...even Apple iMacs are a little UNIX-y these days, that,
really, Windows is the only "oddball" around here...

Learn Windows, only good for Windows...learn Linux and you begin to
gain an appreciation for the UNIX standard - used across many
machines - and the X-Windows standard - again, available across many
machines and is arguably the first and most successful "open source"
project around - and your skills are "transferrable" to other
systems...

Another part of Microsoft monopoly is that you learn Windows but, as
it's only good for Windows coding to do that, then your skills only
permit you to just carry on coding for Windows...from Microsoft
perspective, the "non-standard" thing isn't a mistake...it's all part
of their monopolising "strategy"...they even have names for their
strategies...taking an open standard onto Windows and then altering it
beyond all recognition so that it becomes "incompatible" with the
standard - that is, pretend to be "on board" with an emerging popular
standard, create a Microsoft version of it with "incompatibilities",
everyone runs over to Microsoft because targetting Windows is the
biggest audience, they make things more "incompatible" until it bears
no relation to the original standard and, hey presto, you've killed
the "threat" of any new standard emerging because you basically "took
over" the standard and then delibrately killed it - is called
"de-commoditising"...it's not accidental at all...they sit around
drafting plans about it...

"Code using the standard x86"? You mean, "sans OS"? Just you and the
machine? Ah, like the situation you need for programming your own OS -
the raw machine - but without losing the OS around you to start up
your favourite text editor? Maybe not this exactly...but similar
circumstances? The contradictory "want the OS but don't want the OS" -
want the facilities it has but not that it gets in the way of what
you're coding - situation?

OS developers often have exactly that kind of contradiction to contend
with (want the OS facilities to write the OS...don't want the OS
getting in the way of what they are coding, though...to develop with
the OS but to execute and test without it)...so, if this is what you
mean - sorry, it's all a bit "ambiguous" to me what exactly you're
asking - then try a post asking about that specifically on
news:alt.os.development ...I can no longer access the group but I'm
sure they are still there and all the same helpful people are around
to answer your questions...

One thing that springs to mind is "Bochs" (said "box")...it's a "PC
emulator", available for a whole bunch of OSes that I'm sure Linux is,
without doubt, one of them (though, I only looked at the Windows
version)...it "emulates" a PC...ummm, on a PC...your Bochs PC's hard
drive is actually just one big file sitting on your actual hard
drive...the PC that is booted up inside the emulation, though, doesn't
have any OS...well, not unless you put one into the "hard drive file"
or pass it a "floppy disk" file...Hopefully, you get the picture...it
can't emulate everything on a PC completely yet...but it handles the
x86 chip, basic standard hardware and so forth...you can remain in
your favourite OS but boot up a "raw machine" inside a "Bochs" (the
name just seems to suit it just right...open up a PC inside a little
"Bochs" ;) and then test your program - without any OS interference
but that which you may install - inside the "bochs"...this lets you
stay inside Linux to use all of the Linux stuff for developing your
code...but you can put the code into the "Bochs" where it runs on a
"raw machine"...the emulation isn't good enough for something like
Windows XP to be installed inside the "Bochs" but it _is_ good enough
for some simpler OSes to be installed inside the emulator that you can
even run two OSes at the same time...obviously, because it's an
"emulation" of the very PC you are actually using, it cannot emulate
as fast as your PC actually goes...everything will be slower...in a
sense, you could think of it emulating a lesser PC rather...you know,
only basic standard hardware of an older machine, running much slower
than your current PC...well, it is an "emulation" running on the real
thing, not the real thing itself...

Which is another simple solution - my preferred one that I'm actually
myself trying to get working for "cross OS" stuff - to actually get
yourself a "second machine"...put it together next to your main
PC...install something different on the second machine (say, DOS :) or
leave it without an OS or whatever...then you can develop in your
favourite Linux environment, just pop it on a disk and boot up the
other machine to see how it works...no "emulation" problems (though, I
am suffering "hardware problems" but that's another story ;) because
it's the "real deal" you're using to test out your code...of course,
problem is getting two PCs and setting them up side by side...I
delibrately "recycle" PC parts people are just throwing out to put
together my second machine...it's one way to achieve this set-up
without spending any great amounts of money...people either give it
away or say "$10 and you can have the lot of it" or whatever...well,
there's no way to sell an obselete PC for any reasonable price, as
no-one wants to buy them...you solve a "disposal" problem for
them...it's amazing what you can get your hands on like that...sort of
"good for the environment" in a twisted kind of way (yes, not
really...but slightly better than just throwing a PC box onto a
landfill site somewhere...which many people do when the technology is
still perfectly useable and, say, a 450MHz machine isn't exactly
"useless" at all...absolutely perfect for a "second machine" :)...

If you don't want a totally blank canvas, then use DOS or
something...it doesn't really get in the way unless you ask it to and
you can happily access the BIOS from there...if it weren't for that
bloody "real mode addressing" and 640KB limits and 16-bit nature then
DOS would actually be the perfect environment for such
things...provides a "base" to launch code from and moves files around
and so forth...but a program isn't prohibited from doing anything in
that environment...you can take it all over...access BIOS, access
hardware directly...whatever...you can surely install some DOS of some
kind under the "Bochs" emulator, no problems...

Also, if you mean something slightly less ambitious then there are
educational "simulators" around...I think it's "Ketman" or
something...a tutorial in x86 programming that - never used it myself
but this is what I hear reported (so, if this isn't right, don't blame
me, just passing on what I heard ;) - has a visual "simulator" of an
x86 running so you can see what instructions do inside the chip or
something like that...don't think it extends passed the tutorial in
any way, though...just a "simulator" of how an x86 chip works...nah,
probably not what you want...but best mentioned it in case this is
what you actually meant or something...

As for "does the OS use the BIOS functions"? For Windows and Linux,
the answer is basically "no"...they use them for the initial booting
up sequence, DOS box emulations, access to VESA and a few minor,
exceptional things like that...but, otherwise, no...they are
"protected mode" OSes and the BIOS is incompatible and useless in that
mode...it's "real mode" code in the BIOS and the "addressing" in real
mode and protected mode is NOTHING alike...segments are just
extensions to the address, one part of an overall "segment:offset"
address pair, under real mode (with all that strange: "address =
(segment * 16) + offset" weirdness ;)...segments under protected mode,
though...well, there's enough to fill a bunch of Intel volumes about
"protections" and how "paging" and "segmentation" work in protected
mode...for the "flat" memory model that Windows and Linux take, the
segments, in fact, cease to do anything obvious for a program and you
might as well leave them completely alone...so, no, they don't use the
BIOS because trying to use it would be complicated and
messy...switching modes all the time and so forth...as I say, part of
Microsoft monopoly _IS_ actually related to the fact that when you go
"real mode -> protected mode", the BIOS vanishes from under your
feet...want to use the hardware? Got to do it _directly_..."but
there's all the different types of hardware out there!"...yes,
exactly, got to use some kind of "device drivers" to do what the BIOS
used to do...oh, there's the problem for you! All the device drivers
are hard-wired to be "Windows device drivers" or "Linux device
drivers"...no more univeral standards (though, some leading companies
_are_ trying - about a decade too late! - to draft up some "UDI" -
universal driver interface - which isn't tied to any particular
OS...Linux has "declared an interest" in being able to support these
things, should the project actually go anywhere...it may, indeed, be
too late...if they'd only bloody thought about this when Windows 3.x
was around and things were starting to move over to protected mode,
then we might have been saved from much of Microsoft monopoly as well
as one driver download whatever OS or OSes you were using, alternative
OSes wouldn't be at all disadvantaged by having lesser hardware
coverage because there'd be "UDI" drivers for everything...might even
be the case that Microsoft would have had to have thrown in their own
driver models and complied with the "industry standard" so as not to
lose out by being the "oddball"..._that_ was what should have happened
all that time ago...but they all got greedy...rather than "agree
standards", they all wanted to rush out their own proprietary things
to take over everything...as you can probably tell, Microsoft won that
particular battle hands down)...

For DOS, though, it runs in "real mode" so the BIOS is still perfectly
available...so's accessing hardware directly...mind you, so is no
protections and programs overwriting each other, so is the horrible
640KB limits and so forth...but, really, only if you go totally
"raw" - no OS - or use DOS does the "BIOS" serve any purpose...

Intel made a big mistake; "Real mode addressing" was a terrible hack
that couldn't be extended when RAM sizes went far, far beyond
1MB...think about it, how do you "extend": "address = (segment * 16) +
offset" to handle 256MB of RAM? Intel's answer was simply: "let's not
bother whatsoever to even try"...protected mode was "starting afresh"
with a sensible scheme, built-in MMU, basic support for "tasks" and so
forth...but not in any way "backwards compatible" with the older
procesor mode in any useful way...addressing is completely different,
with no compatibility at all, and how far can any code go without
accessing even a byte of memory? Exactly...nowhere of any use...

In "correcting" the mistake - which _had to_ be done, as the mistake
would have held everything back - Intel introduced a very large
"backwards _incompatibility_"...real and protected mode aren't really
different modes - at least, not in practice - they are more like
"different realities"...switch to protected mode and everything from
real mode - like the BIOS - is rendered useless...when you make the
switch, all the support vanishes and it's "do it yourself or it don't
get done at all"...you can't make the switch itself, in fact, without
ensuring all the interrupts point to meaningful _protected mode code_
places (rather than their current real mode BIOS places :) or the
first "timer" IRQ will, no doubt, crash the entire machine...kind of a
"running joke" with the OS developers, that _everyone's_ first attempt
at code to switch to protected mode will just generate a "triple
fault" (an exception inside the "double exception" exception handler
triggered because an exception happened in some exception handler
elsewhere...in short, so many exceptions in a row that it's impossible
to recover from it in any way...many chips will actually automatically
reboot themselves if a "triple fault" happens...can't do anything to
recover, everything's been lost already as you can't reasonably get
back to it anymore, that there's only one thing for it: reboot and try
again ;)...because, oops, forgot about those interrupts and didn't
issue a "CLI" to stop the timer happening...the timer IRQ triggers, it
jumps to the real mode BIOS code for the timer, hits the first memory
access: exception! Goes to the exception handler and hits another
memory access: Double Exception! Goes to the double exception
exception handler and hits another memory access: Triple Fault!
Reboot! Not the most encouraging thing when you try to switch to
protected mode...the instant you try: Bang! Reboot! Awww, crap! ;)...

You either "put up" with how Linux works...or go to DOS and "put up"
with how pathetically limited it is...or, ummm, you spend the next few
years of your life writing your own OS...which won't have the required
hardware coverage to be useful to anyone other than probably just
yourself with your own machine...

Exactly; None of these are really any kind of option...all boils down
to Intel's "mistake" in the end rendering "real" and "protected" mode
so completely different and incompatible, that they really are two
completely separate worlds...that's the best way to look at them...two
completely different chips...two completely different PCs...though not
entirely technically accurate, this "nothing alike" perspective will
serve you better than any thoughts about using real mode BIOSes in
protected mode...

And what you're also looking at is a fundamental reason how Microsoft
have no real competition...I mean, even if they "win" the entire
"market" by other means, why a total absence of alternative OSes that
are at least _trying_ to knock it off its perch? "Intel's mistake" is
a _physical_ barrier...when you go protected mode, everything has to
be done directly to hardware...and, for the PC, there's masses and
masses of hardware out there...plus, PC architecture itself means that
you could have practically _ANY_ combination of hardware inside the
box...got to make sure all of it will work happily together...someone
may have exactly the same videocard and soundcard as you but what
about their motherboard and support chips? Have a look at all the
stuff listed in something like Windows "device manager" and there's a
"driver" of some kind for all of them...it's an _impractical_ problem
and a _physical_ barrier...otherwise, oh, there's _plenty_ of people
writing their own "hobby OSes"...following in Linus' footsteps...

Note the only real successful OSes that have surmounted the problem
are Windows and Linux...Windows does it by being the "dominant"
OS...the third party hardware manufacturers all automatically write
drivers for their hardware as a matter of course...no Windows driver,
ain't going to sell any "units" of hardware...the Linux approach is
"sheer force of numbers"...exploiting "open source"
development...thousands of developers all over the world just working
on their own little "obscure" bit of hardware...when they get it
working, send it on back...it's a massive, impractical amount of
work...at least, for one or two people it is...but spread it out
across a "thousand eyes" and it becomes a much smaller problem..."many
hands make light work"...but getting enough of a popular following for
enough people to be working for that OS to give it a chance at
collecting up enough hardware coverage? Well, only Linux can be named
as managing to achieve that so far...

Mind you, Linux drivers are "open source" (excluding infamously nVidia
with their "binary only" :)...so, everyone can use them, right? Well,
kind of...you can but Linux also does like Windows does...it's a
"Linux specific" format...you know, drivers expect Linux memory
management API, they expect Linux memory layout, they expect Linux
this and Linux that...to make use of them "as is" would require making
a Linux clone...a "ReactOS for Linux", if you will..."binary
compatible" with Linux so exactly that, to all intents and purposes,
it _is_ Linux, other than perhaps a different looking "shell"...

There's light on the horizon, though, should Linux come to support a
"standard" like UDI - which is intended - and that drivers are moved
over to use UDI (re-write the current ones, make new ones use it
straight away, etc. :)...then there'll be a set of "universal" drivers
that should be "non-OS specific" with Linux "hardware
coverage"...which ain't as good as Windows, true, but it's good enough
for a beginning...if other OSes also adopt the "UDI" interface then
hardware manufacturers finally have a _tempting_ alternative...that
is, write one "UDI" driver and you can support _multiple OSes_...ah,
_NOW_ it's worth the effort of writing them...because "write once,
hardware support for everything"...the only exception now being
_Windows_ with its "proprietary" formats...they'll never change, mind
you...Microsoft ain't completely dumb and realise that UDI - featuring
support from "known enemies" like Sun, IBM, etc. - has been formulated
basically as a means to destroy their monopoly...this is perhaps the
only project to do with hardware and drivers and so forth that
features big name companies to which, suspiciously, Microsoft has no
representative...if they ever did send anyone, then you can be 100%
that it would be as a "spy" and "saboteur", trying to "de-commoditise"
it from within...the others, in fact, would probably reject the
application and not take any Microsoft "suggestions" seriously...this
is their "way out" of being under Microsoft's thumb...requires a lot
of things to fall into place...probably won't work in the end...but,
well, when locked inside Shawshank prison, what else are you going to
do but hack away at the wall with a spoon and try to cover it up from
the Microsoft wardens with a Raquel Welsh poster? Actually, probably
shouldn't have phrased it that way...the last thing I'd want to do is
spoil the brilliant, brilliant "twist" at the end of that film...one
of those times when Hollywood actually "does good" that you only wish
that this was the _worst_ standard they worked to, not some of the
best they do...anyway, anyway...not the topic here, right?

Ah, pardon the negative spin, but such is the depressing nature of the
reality...been like this for years - a decade at least - that, unlike
Tim Robins in Shawshank prison, it's easy to lose Hope and give up on
the idea of any "salvation"...at least you're using Linux...that's
"phase one" of the plan already working well ;)...

Beth :)

Loading