Microsoft Vista Not To Support UEFI

According to this article at eWeek (http://www.eweek.com/article2/0,1895,1937668,00.asp), Microsoft's initial release of Vista won't support EFI. I wasnt' actually at the IDF presentation where Andrew Ritz said this, but I was in one of the UEFI meetings running in the Marriott next door to listen to the aftermath discussion. Quite a stir, I guarantee. So the real question becomes: what does this do to the BIOS companies, like Phoenix or AMI or Insyde? On the face of this, the delay by MS also delays the transition to UEFI. But actually, there are two other forces at work within UEFI which are pushing adoption regardless of what MS does. Driver Model Comes To BIOS The first is the Platform Initialization Working Group, which was formed to help standardize silicon enabling in the firmware. Silicon enabling has become one of the costliest portions of the process of getting a standard PC platform out the door. The first specification hasn't been released yet, but it allows silicon providers create "drivers" for BIOS which should plug in to any compliant implementation. Right now, each motherboard silicon vendor has created their own model for delivering code to board providers, generally through one of the BIOS vendors. But, since there has been no standard for silicon-in-BIOS, each vendor has created a method of isolating their code from the BIOS so that they can easily ship updates. But the methods are all different and generally only cover a small amount of the silicon initialization required for booting the system. Also, bug fixes take longer to reach the OEM/ODM because it has to go through an "integration" phase where BIOS vendors take bug fixes, add them to their code, and then turn around and hand it to the OEM/ODM. There is a lot of wasted time and energy here which has nothing to do with value-add for either the BIOS vendor or the OEM. So this delivery model is coming to BIOS and has very little to do with loading an OS Application Portability The other major area where I am seeing interest is UEFI applications. OEMs need to add functionality which is close to the platform which works on different BIOS vendors. OEMs often like to switch between board vendors. Board vendors have often used the accreted libraries of special OEM features on a particular BIOS as a way of preventing the OEMs from switching (because it would cost too much). But if the feature can be implemented in UEFI and UEFI is supported by all vendors, then it makes it easier to switch. It also allows OEMs to keep their features to themselves without sharing with the board manufacturers, since they can just hand them a binary executable and say: put it in the system. Applications like those supported by UEFI are also useful as a way of replacing dependency on DOS. People just aren't writing drivers for DOS anymore. But, because UEFI is tied to the BIOS, there is a good possibility that there will be drivers written for the silicon which supports UEFI. Since UEFI 2.0 now supports TCP/IP explicitly, as well as a large number of other devices, it makes it useful for a lot of manufacturing tasks. BTW, the article has a number of inaccuracies around the topic of the so-called compatibility support module (CSM). Actually, this term comes from the way that Intel's Framework implementation of EFI (http://www.intel.com/technology/framework/) supports the current OS (DOS/WinXP/Linux) boot model. Other implementations (like Phoenix's) have gone the other way and just made EFI yet-another-interface supported by the firmware. You can see some aspects of the Framework at www.tianocore.org although the CSM isn't there.