Slashdot Mirror
How Good is Commercial BIOS Code?
Bitten-by-BIOSbugs asks: "My job involves porting PC BIOS code supplied by one of the Big Names to my employer's products. In my experience, this code seems to be so full of holes you could strain pasta with it. However, the vendor seems not to care when I report bugs, and rarely have fixes been made available. What is the experience of other Slashdot readers regarding the quality of commercial BIOS products?"
Since so few BIOS functions are actually used once the operating system gets into place, it's becoming less and less of a concern to get things perfect. Unless it causes the computer to explode, fixing a bug doesn't get them any more customers so companies don't bother.
I'm sure at least 70% of slashdot readers have worked with commercial PC bios source. All right people, pony up with the great responses already! Here we are finally with a question perfectly appropriate for /. and nobody is responding.... What's the deal????
:-)
IMO, too many BIOSes are incomplete or are mis-implemented. Most seem to only implement the bare minimum needed for a given motherboard/chipset.
You are being MICROattacked, from various angles, in a SOFT manner.
...wouldnt know QA if it hit them on the head with a mallet...
Finally! A year of moderation! Ready for 2019?
so full of holes I could strain pasta with it
At least it's not writen in perl. Then how could you tell it from the pasta your straining?
I live in a giant bucket.
You're forgetting about embedded applications using "sort-of-standard" hardware. The more you can pack in to the smaller space, the better in those situations. So if a bios provides "service X" then why should you be expected to write "service X" all over again just so you can have two copies in your romset and occupy more space.
If you're a zombie and you know it, bite your friend!
I dunno about commercial BIOS code, but the BIOS I use is pretty good... and I can verify it for myself if I want to. :-)
Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?
The reason why is that they've been working with assembly language for most of their careers, while everyone else was learning advanced techniques like object-oriented design and development, and working on multiple languages (C++, Java, C#, etc). There were a dozen BIOS developers in my department, and I was the only one who lnew object-oriented programming. The only one!
Now, you might be saying, what does OO have to do with BIOS? True, you're not supposed to write OO assembly code, but you are at least supposed to understand the concept, so that you can apply them in some way. The Linux kernel is written like this - the kernel developers know OO concepts, but they use them only where necessary, and the code is still written in C.
I firmly believe that the only reason why these people worked there was because no one could write this code. Writing BIOS is hard, and it's almost impossible to find someone who knows BIOS and modern programming techniques. I remember this one guy who consumed caffeine all day long and was completely wired. He wrote code really fast, but it was all very poorly designed, and none of it was documented. Every time a new feature was added, the guy had to hack it in somehow, because the original code was always written to just what it was supposed to do, no more.
Another reason why they were so bad is that BIOS developers are highly resistant to change. Most of them spend all their time updating the code to support new motherboards, but they would never rewrite anything to improve its design. The majority of code was written back in the 80's, and no one wants to touch it. So this code just sits there, from one version to the next.
What made it more pathetic was that these people were actually better than most BIOS programmers. We would have conference calls with some of these other developers (the company doesn't write the BIOS for all motherboards they sell), and we would ask them technical questions, and they couldn't answer half of them!
The real solution is to rewrite the entire BIOS from scratch, using proper OO techniques, and writing as much code as possible in C. But today's BIOS programmers aren't qualified for that job.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
It's not hard to figure out that BIOS programmers are pretty unprofessional. Just go get a half dozen different motherboards, boot into CMOS config, and select one of the cryptic little configuration options nobody ever messes with, say, "Chronosynclastic Infandibulum". Now, press the "help" key and read the incredibly useful help message: "This option selects Chronosynclastic Infandibulum".
I'd fire any programmer who did that, but it's de rigeur for BIOSes.
There's an open source group doing it.
May we never see th
That said, as a meer admin and user I take it as a rule of thumb that if a new system is acting flaky for no obvious reason, firmware upgrades are on the short list of things to check into along with RAM and video drivers.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I've seen some custom bios'es for various mobos on some of the overclocking boards' floating around, so obviously poeople have done it. I'd poke around in the OC boards/newsgroups.
DO NOT DISTURB THE SE
A very, very insightful post, but I have to pick one nit: equating OO programming with programming in an OO language. In point of fact, you can do OOP in assembler -- there are even assemblers that support it, though I guess they're not very popular. You probably know all this and were just speaking loosely. But it's a sin to encourage well-meaning nitwits who learn a little C++ and tell themselves they are now doing Objects. Which is, of course, the big problem with MFC!