The BIOS of today's x86 platforms and the DNA of human beings share one characteristic: They are both comprised largely of vestigial code that is ignored because it no longer functions in a modern context, yet must remain in order to maintain the overall structure of the system.

"A number of us in the industry," says AMD's Richard Brunner, "would like to be able to use a firmware stack that actually exploits modern instruction set features, such as 32 bit and 64 bit pointers, rather than the kludges that we have to do with fake real mode in 16 bit BIOS."

One of the vestigial functions of BIOS - dating back to the time Charlie Chaplin appeared in IBM ads - involves how the operating system or a device driver gets the BIOS's attention to request a data transfer. It performs the 1980s equivalent of yanking the stop chain on a public subway car, triggering assembly-language interrupt routines by setting registers called traps, which still have hexadecimal names like INT 13h and INT 19h. Interrupt routines do exactly what their names suggest, creating latencies and thwarting the objectives of multithreading. Under UEFI, the hardware is contacted using a more modern, less complex API model. Conceivably, operating systems such as Windows Longhorn and future Linux versions would be able to implement the new API without forcing device manufacturers to rewrite their existing drivers (though they may want to consider recompiling them for their new OS).

"[UEFI] is about initializing the hardware so that you can load the operating system. It's not providing a runtime interface," proclaims Insyde's Jonathan Joseph. "The runtime interface is still handled by operating system-level device drivers. So nothing we're doing in this pre-OS world changes that."

New firmware should be able to make bolder assumptions about the minimum capabilities of present hardware, not the least of which is the existence of 32 bit protected mode. "We can almost assume there's a network device on a platform now," states Brian Richardson, EFI Product Manager and Technical Evangelist of American Megatrends, the longtime manufacturer of AMI BIOS. "We can assume we're running something capable of 32 bit protected mode. We're assuming we've got good VGA, or something that can display better than 640 x 480 x 16 bit."

Under a UEFI-enabled system, all the least-common-denominator features that BIOS presumes must exist on the platform can finally go away. For this to happen, continues Richardson, the x86 has to come to an important self-realization, which Richardson phrases like this: "Look, [although] I'm not in the operating system, I'm not an 8086 anymore. I can actually go out and solve a real TCP/IP stack, I can present a user with something that involves a mouse and buttons like they're used to, so I can get out of this text interface thing I've been doing for so long, and give the user an opportunity to do something outside of the operating system. I can help them recover or restore or maintain their platform when the OS just doesn't respond, short of '1-800-Why-Am-I-Hosed?'"

But perhaps the most appreciated change to the "ex post BIOS" x86 platform will be the recognition of all storage devices, whether they're rotating cylinders or solid-state blocks, as geometrically linear. Since the introduction of EIDE in 1986, special INT 13h service routines have used mathematical tricks to translate linear LBA addresses into "head/sector/cylinder" coordinates that appear to apply to a hard drive with less than 2.8 GB capacity, no matter how large it actually is.

With a UEFI interface, any storage device is addressable in a standard, linear manner, without mathematical tricks in the background. This opens up the possibility, says Richardson, of enabling administrators to plug USB Key storage devices into systems whose boot devices are failing, automatically bypassing those devices. Through the UEFI firmware shell, admins could then access scripts or other utilities from the USB Key. Since the shell would be running in protected mode, these utilities would not be restricted to one megaByte of address space as with present-day real mode. The user couldn't possibly access these utilities by accident, because when not in use, they'd reside not in the computer or even the network, but on the admin's keychain.

"UEFI firmware can easily extend itself," says Brunner, "simply by shoving a USB Key into the drive. All of a sudden it can access additional drivers, UEFI applications - there's so much flexibility there that would be very hard to get with legacy BIOS."