Re: BIOS

From: Eric (nospam_at_email.com)
Date: 04/25/04

  • Next message: Jim Carlock: "Re: The best Assembler." 
    Date: Sun, 25 Apr 2004 04:29:35 GMT

    Beth! Just how many keyboards do you wear out each year?
    Eric

    Beth wrote:

    > 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 :)

  • Next message: Jim Carlock: "Re: The best Assembler."
    Loading