什么是 EFI？

如果回想一下 DOS 编程的时代，您可能还记得使用软件中断进行 BIOS 调用。PC BIOS 是 PC 硬件的低级别抽象，这种方式提供了从显示 ASCII 字符到 RS-232 I/O 等范围广泛的服务。在此后的十年或更长时间里，在 PC BIOS 的体系结构方面，或在提供给应用程序和 OS 开发人员的服务方面，基本上没有多少更改。由于 Intel 最近提供的“可扩展固件接口”(EFI)，所有这些已经改变。

EFI 是 Intel 为全新类型的 PC 固件的体系结构、接口和服务提出的建议标准。其主要目的是为了提供一组在 OS 加载之前（启动前）在所有平台上一致的、正确指定的启动服务。可以从 http://developer.intel.com/technology/efi 中“Specifications”超级链接下面下载 EFI 标准文档本身。EFI 的参考实现（包含用于 x86 处理器的源代码）也可以在相同 URL 的“Tools”超级链接下面得到。该参考实现运行在使用标准 BIOS 的现有旧式 PC 上，实际上可以构建为在重新启动 PC 时直接从软盘加载。这样，即使您的 PC 不支持 EFI，也可以开始目前的 EFI 实验。

这对 Windows CE 开发人员意味着什么？

目前，当您决定让您的 Microsoft Windows CE 平台基于嵌入式 PC 时，您一定非常希望保持 BIOS 不变，或者通过许可使用一个可提供增强服务的替代 BIOS（可能需要额外的费用）。您可能还是会选择该替代 BIOS，因为它使您能够访问源代码并且/或者会得到知识丰富的开发人员团体的良好支持。例如，如果将自定义 Windows CE 内核映像从硬盘加载到 RAM 中，可能还需要通过许可使用一份 MS DOS 来维护文件系统，以便将内核映像文件存储在硬盘上。这是在 Platform Builder 附带的 LOADCEPC.EXE 示例应用程序的实现中所使用的模型。

让我们感激的是，仅仅是为了初始化基于 PC 的 Windows CE 平台和加载内核映像就需要许可新的 BIOS 和/或一份 MSDOS 的情况不再是必需的了。“可扩展固件接口”名称中的关键词是“可扩展”，正是有了这种可扩展性才为添加驱动程序和应用程序模块提供了经过广泛证明的机制。与在桌面操作系统中一样，EFI 驱动程序使用定义的接口（或用 EFI 的说法称为“协议”）提供了一个在硬件之间的抽象层。应用程序只是能够访问由 EFI 定义的范围广大的各种所选协议的模块。

EFI 还有另外一个不是很直观、但却非常有用的目标。以我的经验看，专用于平台初始化的代码（在 Windows CE 中通常称为启动加载程序）包含了最低限度的体系结构，大多数是为嵌入式系统匆忙制作的组件。随着日程的进展，它通常处在“关键途径”上，并且经常被后期指派负责通常在使用原型硬件时所需要的平台诊断、闪存更新和其他任何内容。通常，时间只够大体实现这些功能，它们很少可用在未来的平台上。这正是 EFI 真正发挥作用的地方。虽然只是简短的介绍，但您不久将会看到，EFI 的构造非常精良，并且它附带了在没有功能完整的 OS 时无法期望的那种调试工具。

这回避了问题的实质，如果从 EFI Web 站点得到的参考实现不直接支持 Windows CE 平台，那么如何使用 EFI？EFI 在发布时带有使您能够移植到您自己的平台和目标处理器的源代码。本文不讨论这样做的过程，但这种做法的优点应当是清楚的。您可以在创建 Windows CE 启动加载程序时立即继承 C 源代码的牢固基础，以及一组设备驱动程序和工具，而所有这些在很大程度上都是独立于平台的。这意味着，随着平台连续升级换代，您可以重复利用以前的启动前软件投资，同时又能隔离任何对 EFI 设备驱动程序必需的更改。本文随后将从编写一个 EFI Windows CE OS 加载程序出发，将其作为一个示例，以用来探讨关于如何在 EFI 下面创建一个独立于平台、启动前、可重用的软件组件这一问题。

EFI 概述

EFI 服务划分为两个不同的阵营，一些只在 OS 加载之前可用，称为“启动服务”，另一些还会在 EFI 已经采用它的最低占用配置之后可用，这称为“运行时服务”。启动服务为平台配置、初始化、诊断、OS 内核映像加载和其他功能（数量太多，无法全部列出）提供了由 EFI 实现的范围广泛的各种功能。但是，运行时服务只是一组最少的服务，主要用来查询和更新永久性 EFI 设置。启动服务会消耗更多的资源，这取决于所选择的构建选项；而运行时服务消耗的资源非常少，这是为了尽可能地保持运行中的 OS 的透明性。

在 EFI 规范中，EFI 内的服务正式指定为核心服务和协议接口。用于访问多种启动设备的多种协议接口已经定义，其中很多接口都能在 EFI 参考实现中找到。其他协议接口为应用程序级函数提供服务，例如内存分配和获得对指定协议接口的访问权。

EFI 模块通常被定义为应用程序或驱动程序。驱动程序遵守在 EFI 规范中定义的模型，并被用于实现特定的协议接口。很多情况下，实现一个协议接口可能要使用或增强现有协议接口的功能，从而为称为包含和聚合的面向对象设计实践提供了一个机制。

对特定于平台的功能进行抽象的 EFI 驱动程序存在于 COREFW\fw\platform 源代码树中，并且链接到核心 EFI 映像。用于实现对某些硬件功能的功能性抽象的其他驱动程序则与特定于平台的驱动程序分开，位于 EDK 子目录中。它们遵守在 1.10 EFI 规范中定义的驱动程序模型（到编写本文时为止，仍在审阅中），并且应用于诸如 SCSI、视频、IDE、LAN、USB 等启动设备硬件类别。EDK 驱动程序被构建为扩展名为 .efi 的、独立的可执行文件，并且可以在 EFI 启动序列期间动态加载。

EFI 应用程序通常由启动管理器加载，并与它们在启动设备介质上的位置一起列在一系列永久变量中。也可以从参考实现中提供的 EFI 命令外壳来加载应用程序。因为应用程序没有通过协议接口公开它们的服务，所以应用程序模型略微简单一些。EFI 外壳和启动管理器是 Web 站点的参考实现中与源代码一起提供的两个 EFI 应用程序示例。

EFI 规范还定义了一个调试支持协议，以便允许在远程调试控制台上用 C 进行源代码级别调试。它支持实现第三方调试器。

在当前 EFI 规范草案 1.10 版中用超过 1000 页的篇幅，定义了本文无法详尽描述的很多功能。请访问 Intel Web 站点以下载该规范和当前的参考实现。表 1 提供了在开发应用程序和设备驱动程序模块时可用的函数列表的一部分。