I've just left a software engineering position with AMI where I have been working with (U)EFI for the last four and a half years. I can't claim to be an expert on everything, but I wanted to check if the Bit community might want to learn a little bit about that mysterious bit of code that gets you to the "loading windows" screen while I have a little time over the next few days.
I looked it up on wiki and I still don't understand any of it. Best of luck with wherever you go next though
BIOS is getting long in the tooth, there's no denying it. But you don't fix what isn't broken. Is UEFI really necessary, and why? Aren't more complex systems more prone to problems?
All we want to know is whether or not it'll run Crysis? Seriously, though, what does UEFI bring to the table that'll improve the computing experience?
I'm trying to not write a text wall full of tech specs and focusing on the details of how a system functions. It's pretty hard because that's the level I'm used to working at I'll start with complexity. Yes, UEFI is complex. Just look at that specification! But then, we can see the spec and see just how complex it is. In comparison, BIOS has no equivalent. The innards of how it works are specific to each BIOS vendor and can vary between versions of the BIOS. Because you have to have to sign a license agreement with an IBV to even see their internal specs on their implementation, you don't get to see the complexity. For those who have and still complain about UEFI, my experience is that they are still new to it. UEFI is completely different and having a lot of experience in BIOS is not necessarily helpful in understanding it. I have seen this cause a lot of frustration. I think the best I can do for an analogy is that is' like going from one OS to another. The frustration of learning something new causes a lot of complaints that fade away as more people become familiar with the new OS. And BIOS is broken, it's just that the we are use to working around the broken parts of it. It's hard to explain without delving pretty deep into PC architecture and the required reading tends to put people to sleep But as a quick example, to boot a system, a computer uses 440 bytes on the "C" drive. The code MUST be on that drive and that drive only. Unless you are working with it, it's hard to see what in BIOS is broken. Boot speed is a pretty common topic to have come up. There are a lot of white papers on it, sample implementations, and demos showing how something might work. But at least a few of the big time penalties are paid in hardware. But that doesn't mean it's hopeless, one area a system stands to gain some time is in the BIOS->OS hand off. Right now, a system needs to act like a 1980s PC and start things in 16 bit real mode with 440 bytes of code from the boot sector. The OS boot process is then handled in stages. With UEFI, the BIOS can hand off the system in a state that looks a bit closer to the final configuration of the OS and can provide some more useful APIs to help make the boot a bit 'easier'. There may be some other tricks that could be done, but what I an guessing at would require hardware that needs protected mode to operate. BIOS operates in real mode so it wouldn't be compatible. As for what UEFI can bring to the table, it's already making an impact in the enterprise environment: http://intelstudios.edgesuite.net/idf/2010/sf/aep/EFIS004/EFIS004.html Skip to the part of the presentation done by the Dell engineer at about 4:30. At the consumer level, I'm not exactly certain. I know I have used UEFI to get information on the state of the hardware, manipulate certain system BIOS settings, run BIOS flash utilities, and small tasks like that. With a working network stack, things like getting a BIOS update strait from a server on a LAN or the internet would be possible. Maybe tweakers could download system configs from each other. Unfortunately, I'm better at implementing other peoples' ideas or just fixing my own problems that coming up with marketable stuff on my own The framework UEFI provides makes developing for it a lot like developing for a 'lite' version of Windows or Linux.
