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?"

Comments

Another great question.

[walt-sjc]

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????

:-)

Pasta

[ealar dlanvuli]

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?

Are there still BIOSs in new PCs?

[Animats]

Is there still a BIOS, the "basic input-output system" that's the low-level part of DOS, in current boot ROMs? You need a boot loader and a hardware initializer, but is there any remaining need for a basic input-output system in ROM at all? No current production OS uses it. It's 16-bit x86 code. Win95/98/ME might still need it in some modes, but for machines that come with XP or NT preloaded, why bother?

Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?

BIOS developers are generally bad programmers

[LordNimon]

I used to work as a BIOS developer for one of the major OEMs. I quit after about two years because I couldn't take it any more. The developers just were awful programmers.

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.