【IT168 资讯】概述

　　本文介绍了Windows Embedded Standard 2009和Windows Embedded Standard 7在组件化、工具和映像构建流程等方面的部分不同。目的是使用户深入了解这两款嵌入式产品之间的差异，以及这两款产品在创建和部署嵌入式设备映像时在功能、工具和用户整体体验方面的部分不同。

　　组件化对比

　　本文将比较Windows Embedded Standard 2009和Windows Embedded Standard 7在以下方面的不同：

　　• 组件架构

　　• 功能集包

　　• 驱动程序包

　　• 语言包

　　• 组件依赖关系

　　• 宏组件与模板

　　• SMI(Settings Management Infrastructure，设置管理架构)的设置与配置设置

　　• 嵌入式功能(EEFs)

　　• 客户化组件支持

　　• 组件架构

　　Windows Embedded Standard 2009和Windows Embedded Standard 7具有相似的组件化概念，即将注册表信息、依赖关系和其他资源定义在一个统一的二进制文件集中，所有这些数据都作为一个集合安装在运行的映像中。但是，两款产品在组件实现和使用上是不同的。

　　对于Windows Embedded Standard 2009而言，其组件的实现是从头开始的。因为Windows Embedded Standard 2009从Windows XP Pro继承来的二进制文件并未进行组件化。因此，Windows Embedded Standard 2009的组件无法与包括Windows Embedded Standard 7在内的新推出的操作系统兼容。此外，这些组件只是用来导入到用于开发的Windows Embedded Standard 2009的组件数据库中，而无法导入到嵌入式设备中。要为这些设备提供服务，需要OEM开发人员使用更新后的组件重新创建整个运行时的映像。

　　Windows Embedded Standard 7的组件继承自Windows 7，这些组件都列在组件清单上。除了个别的是为了满足某些嵌入式的特殊需求而没有包括在Windows 7中，其他的都与Windows 7清单一样。因此，Windows Embedded Standard 7与Windows 7的设计完全兼容。组件更新升级与Windows 7也相似，仅需创建一个嵌入式开发的专用更新包，用户可将该更新包导入部署在OEM开发人员计算机上的Windows Embedded Standard 7分发共享目录(distribution share)中，或直接安装到嵌入式运行映像上。

　　Windows Embedded Standard 7与Windows Embedded Standard 2009在组件设计上的另一个不同之处体现在嵌入式核心(eCore)这一概念上。eCore包括一系列操作系统基本组件(内核、网络、安全、某些驱动程序等)，这些基本组件用于引导有系统安全和网络功能的嵌入式设备。eCore是嵌入式设备的最小映像，支持OEM开发人员在其上面添加其他功能集、驱动程序和语言包，本文将在下面对此进行讨论。

　　功能集包

　　对于Windows Embedded Standard 2009，当用户创建自己的设备映像时，需要在组件的层面上选择功能集包。甚至某些重要功能(如，Windows Media Player、Windows Internet Explorer、Microsoft Remote Desktop Protocol等)都是作为组件实现的，这是因为这些功能是由大量二进制文件聚集而成。因此，组件和功能的区分不很明显。此外，由于Windows Embedded Standard 2009有1万多个组件，因此用户如何从中选择合适的组件创建自己的映像成为一种挑战。

　　对于Windows Embedded Standard 7，创建功能集包的目的是聚合相关的组件(如，Windows Media Player、Windows Internet Explorer、Microsoft Remote Desktop Protocol等)，OEM开发人员只需选择他们所要部署的功能集即可。由于要将功能集包的数量保持在最低水平(约为150个)，所以功能选择流程更简单，设计和创建设备映像也更容易。

　　驱动包

　　在Windows Embedded Standard 2009中，每个驱动程序都作为独立组件实现，共有约9000个独立的驱动程序，对OEM开发人员而言，将这些驱动程序与相应的硬件设备配在一起是一项重大的挑战。

　　与功能集包类似，Windows Embedded Standard 7也提供包层面的驱动程序。但是，为了降低程序的大小，各驱动程序都是以独立的包的形式提供，只有一个例外是USB 驱动程序，此外，我们还提供了一个可选的支持USB 启动的驱动程序包。。实际上，这些驱动程序包与Windows Embedded Standard 2009中的各个驱动程序组件相似。Windows Embedded Standard 7放弃了Windows 7中部分陈旧的驱动程序，创建了大约400个独立的驱动程序包。此外，嵌入式核心(eCore)中还包括了约100个驱动程序的列表，能够满足例如系统引导、网络通信等基本需要。

　　总体而言，Windows Embedded Standard 2009和Windows Embedded Standard 7的驱动程序基本相似，但Windows Embedded Standard 7中的驱动程序数量明显减少，而且eCore中还包含了部分基本的驱动程序。

　　语言包

　　Windows XP并不是由语言中性的组件组成，所以，它不支持将单个语言包安装在一个语言中性的操作系统上。每个操作系统二进制文件必须对不同的语言进行本地化，以满足不同国家和地区的需要。这种设计不仅使错误修复、测试和OS组件服务复杂化，而且对需要多种语言支持映像的终端设备而言，还大大增加了操作系统的大小。Windows Embedded Standard 继承了Windows XP相同的语言设计，但是，它额外提供了非英语的语言资源包，从而使得用户能够选择是否创建一种或多种语言的设备映像。尽管如此，这并未解决上述的错误修复和OS组件维护复杂、占用内存太大等问题。

　　Windows Embedded Standard 7继承了与Windows 7相同的支持语言中性的设计模型，可以将不同的语言包安装在同一个语言中性的操作系统上。那些存在于Windows XP和Windows Embedded Standard 2009中的问题在这得到了改善。与Windows 7一样，Windows Embedded Standard 7提供了多达36个完全本地化的语言包(LP)，但实际安装的LIP语言包(language-interface package)的数量取决于用户的需求。此外，Windows Embedded Standard 7中的某种语言包只包含与功能和驱动程序包(及Embedded core)中的语言中性组件相对应的某种语言资源文件，从而，与Windows 7相比，大大减小了包的大小。语言包更小，使得OEM开发人员可根据具体需求，更容易地在专业设备上部署各种语言包。

　　组件依赖关系

　　Windows Embedded Standard 7采用了与Windows Embedded Standard 2009类似的组件依赖关系概念。与Windows Embedded Standard 2009不同，Windows Embedded Standard 2009的依赖关系表现在组件层面，Windows Embedded Standard 7则表现在功能集包层面。如下表所示，Windows Embedded Standard 2009和Windows Embedded Standard 7的依赖关系类型相似。

组件依赖关系

　　宏组件与模板

　　在Windows Embedded Standard 2009中，为满足安装某些功能或应用的依赖关系，可应用宏组件，或将宏组件导入组件数据库中。宏组件可指定某些配置设置，以及任何所需的和/或可选的依赖关系。宏组件的安装与标准组件类似，但宏组件中不包含任何文件。因此，OEM开发人员可使用(如Target Designer等)嵌入式工具修改配置的设置。

　　Windows Embedded Standard 7中也采用了类似的概念。有一个模板是用于满足特定功能或应用的安装。该模板详细列出了一系列的功能集包，这些包对于这类功能或应用来说是必需的。但是，模板的安装方式与标准功能集包的安装方式不太相同，它不允许使用(例如映像配置编辑器，ICE)等嵌入式工具更改配置设置。

　　SMI设置与配置设置

　　在Windows Embedded Standard 2009中，用户可以使用组件指定配置设置(例如，定义防火墙端口等)，系统支持OEM开发人员使用Target Designer设定所需的设置值。这些设置使用HTML作为用户界面应用到组件wrapper文件(或SLD)，这些设置可修改某些特定功能的运行(例如，启用或禁用防火墙端口)。

　　在Windows Embedded Standard 7中，OEM开发人员可以通过ICE控制的唯一设置是从Windows 7继承来的组件中可见和可变的SMI设置。此外在功能集包层面没有任何其他设置可执行。因此，功能的某些操作是不可见的，或者是不能定义为组件层的SMI设置，不能进行修改(例如，设置防火墙端口)。换言之，Windows Embedded Standard 7的OEM开发体验与Windows Embedded Standard 2009大相径庭。

　　嵌入式功能(EEFs)

　　在Windows Embedded Standard 2009中，EEFs与其他组件的实现方式相同。与之类似的是，在Windows Embedded Standard 7中，EEFs的实现方式与其他功能集相同。在EEFs方面，除下表给出的少数例外，Windows Embedded Standard 7基本与Windows Embedded Standard 2009相同 。

在EEFs方面基本相同

在EEFs方面基本相同

　　自定义组件支持

　　在Windows Embedded Standard 2009中，OEM开发人员可通过创建适用的二进制文实现适用的SLD文件自定义组件，然后将组件导入组件数据库。这样，这些客户化的组件就具有扩展功能并可被集成到开发平台，使用(例如Target Designer等)嵌入式工具为用户提供无缝的体验。

　　由于OEM开发人员无法在Windows Embedded Standard 7中创建自定义组件或功能集，所以对于嵌入式包和开发平台，他们的体验会有所不同。然而，OEM开发人员可以创建自定义的功能(包括第三方驱动程序)，放入到分发共享目录中的“$OEM $”文件夹。这样可以支持OEM开发人员将自定义功能加入嵌入式运行时映像，或将它们作为配置集重新分发。但如果使用这种方法，自定义功能不能表示与Windows Embedded Standard 7功能集的任何依赖关系，系统中也没有基于工具的机制可改变设置。

　　满足嵌入式需求/场景的可修改的Windows 7操作

　　如上所述，Windows Embedded Standard 2009 与Windows Embedded Standard 7除在组件化方面有所不同外，为更好满足嵌入的需求，Windows 7功能的某些操作也作了修改。如下表所示，大多数操作的修改是通过SMI设置完成的。

组件方面的不同

　　映像创建进程的比较

　　创建Windows Embedded Standard 操作系统的过程可分解为以下步骤：

　　1. 设备分析——确定目标计算机上有哪些设备，并添加驱动程序，支持这些设备。

　　2. 配置——向操作系统添加所需的包，并配置所有关联设置。

　　3. 创建——形成设备的操作系统。

　　4. 自定义 ——向操作系统添加任何第三方文件或程序。

　　5. 捕获——将操作系统捆绑到一个聚合单元中，用于重新部署至其他设备。

　　6. 部署——将预先配置的操作系统安装到一台或多台设备上。

　　下面的两张图表概括了Windows Embedded Standard 2009和Windows Embedded Standard 7映像的创建过程。

映像创建过程

映像创建过程

　　对照上述各步骤，本文逐步讨论了Windows Embedded Standard 2009和Windows Embedded Standard 7开发流程的差异。

　　设备分析

　　在Windows Embedded Standard 2009中，设备分析是使用Target Analyzer(Tap.exe)程序完成的。建议OEM开发人员在其设备上启动Windows预安装环境(PE)并运行Tap.exe。默认情况下，Tap.exe将生成一个Devices.pmq文件，该文件将列出目标设备上的所有硬件。

　　可在得到Devices.pmq文件后，使用Target Designer导入该文件。系统会自动把设备映射到驱动程序上，将包含这些驱动程序的组件添加到配置中。

　　Windows Embedded Standard 7的设备分析与此类似，但进行了简化。Windows Embedded Standard 7同样利用Target Analyzer创建Devices.pmq文件。但运行Tap.exe的流程更加简单。

　　如果用户使用Image Builder Wizard(映像构建向导，IBW)开发映像，则Tap.exe自动在后台运行，系统会自动把设备映射到驱动程序包上。由于IBW是在目标设备上执行的，所以不用作为创建配置前的单独步骤，可直接在创建时间前对目标硬件进行分析。

　　用户使用ICE开发映像时，设备分析过程几乎与Windows Embedded Standard 2009完全相同。Tap.exe既可从Windows PE运行，也可从IBW的磁盘运行。接下来，OEM开发人员可将Devices.pmq文件导入ICE。在ICE中，各设备将被映射到驱动程序包，并添加到配置中。

　　配置

　　在Windows Embedded Standard 2009中，映像配置在Target Designer工具上完成。Target Designer是一个在OEM开发人员的计算机上运行的应用程序，可提供一个用于创建Windows Embedded Standard 2009 操作系统的IDE。OEM开发人员可创建新配置，并将其添加到驱动程序、软件和嵌入式功能组件中，创建自己的自定义操作系统。开发人员还可以添加宏和模板组件，这些宏和模板组件可包含各种组件二进制文件和设置的组合。此外，开发人员还可选择编辑与操作系统或其组件相关的设置。

　　添加基本组件后，OEM开发人员必须解决依赖关系问题。系统将自动检查添加到配置中的组件，并添加操作系统功能所需的任何其他组件。解决依赖关系问题后，开发人员可将配置保存为.slx文件，该文件用于创建操作系统映像。

　　在Windows Embedded Standard 7中，存在两种相互之间有关联的开发体验。IBW是一个基于向导的开发工具，支持用户快速、简便地对样机设备进行配置。ICE与Target Designer类似，支持OEM开发人员完全控制其操作系统的各个方面。

　　IBW是一个在目标设备上运行的安装向导，可自动检测系统中的设备，并安装相应的驱动程序。OEM开发人员可以从模板配置入手，或手动选择他们希望添加到操作系统中的功能包。解决依赖关系并完成配置后，IBW就可以将操作系统直接安装到设备上。

　　ICE与Target Designer的相似之处在于，ICE是一种在OEM开发人员的计算机上运行的IDE体验。开发人员可以向配置中添加驱动程序、软件和EEF包，可以向配置中添加作为起始点的模板，还可以添加一系列功能。此外，开发人员还能修改操作系统的设置，解决依赖关系问题。

　　OEM开发人员完成所需的配置后，可将配置保存到应答文件中。该文件列出了所有要安装的功能或驱动程序包包和需要进行设置的配置。可将应答文件传送至IBW，由此创建操作系统。

　　在Windows Embedded Standard 2009中，操作系统的创建是在OEM开发人员的计算机上完成的。OEM开发人员可在Target Designer中完成配置后创建映像。Target Designer在开发人员指定的位置创建一个操作系统文件夹结构，并使用目标操作系统的二进制文件和注册表配置单元填充该文件夹结构。然后，OEM开发人员可将这些文件复制到目标设备的磁盘上。系统引导目标设备时，Windows Embedded Standard 2009通过首次启动代理(FBA)，由FBA完成操作系统的最终安装。完成FBA后，操作系统即可投入使用。

　　在Windows Embedded Standard 7中，操作系统的创建完全在目标设备上进行。无论是IBW和ICE配置方法，配置工作都在IBW工具上最终完成，从而实现操作系统的创建。IBW首先在设备上安装基本操作系统，然后安装所选的包，并应用所有配置设置。基本安装完成后，设备将重新启动到安装的操作系统。然后，与FBA非常相似，完成操作系统的最终安装后，操作系统即可投入使用。

　　自定义

　　在Windows Embedded Standard 2009中，OEM开发人员可以通过多种方式向配置中添加第三方应用程序。第一种方法是使用Component Designer工具。这种方法允许开发人员创建自定义组件。这些自定义组件可包含自定义文件、应用程序或驱动程序的注册表项，以及其他组件依赖关系的列表。这些组件被导入组件数据库，并在Target Designer中可见。这样，OEM开发人员可以创建永久组件，永久组件的操作与操作系统的其他部分类似，可由多种配置共享。此外，自定义组件还支持版本修订控制。如果开发人员不希望使用自定义组件而向某个配置添加第三方文件或注册表项，Target Designer还支持使用Extra Files、Extra Registry Data或Extra Resources节点将其他文件和资源手动添加到配置中。使用该配置时，这些文件将安装到设备上，但使用其他配置时，这些文件将无法安装到设备上，也无法进行版本控制。

　　Windows Embedded Standard 7中没有Component Designer(组件设计)工具。Windows Embedded Standard 7使用$OEM$文件夹的概念将第三方文件加入目标映像。如果必须通过安装程序安装第三方文件，则用户可在安装过程中使用同步命令执行安装程序。$OEM $文件夹不支持依赖关系或内置的版本控制功能。但用户可以创建模板，将功能包组合到一起，然后按照文件版本的不同区分文件夹。

　　捕获

　　在对所需映像进行配置，并创建到设备上以后， OEM开发人员可能需要捕获映像，用于日后在多台设备上部署相同配置。

　　在Windows Embedded Standard 2009中，OEM开发人员必须在捕获操作系统映像前使用包含Fbreseal.exe的系统克隆(System Cloning)工具。在安装过程中，每次安装都具有唯一性。Fbreseal.exe可去除任何唯一标识符，以便这种安装可以复制到多台计算机上。运行Fbreseal.exe后，OEM开发人员可使用第三方工具捕获映像，供日后部署时使用。Windows Embedded Standard 2009还对Sysprep提供有限支持。Sysprep仅用于为使用系统中心配置管理器操作系统部署方法(System Center Configuration Manager’s Operating System Deployment)而准备映像时使用。

　　在Windows Embedded Standard 7中，OEM开发人员使用的是Sysprep，而不是Fbreseal.exe。Sysprep的功能与Fbreseal.exe类似，可生成映像，以便可以捕获映像，并用于重新部署。Sysprep具有强制被部署的操作系统进入Out of Box Experience (OOBE) 或Audit模式，支持最终用户配置操作系统设置，以及OEM开发人员确保在向最终用户发布设备前已完成了全部预设置工作。用户也可将无人值守安装应答文件传递到Sysprep，以便系统执行其他命令或对设置进行配置。

　　运行Sysprep后，用户即可使用ImageX捕获映像用于重新部署。ImageX可将目标磁盘的全部内容捕获到Windows Imaging(WIM)文件中。WIM文件是基于文件的，可进行大规模压缩。对于重复的文件，系统只在WIM文件中存储一次，这样同一文件的多个副本不会显著增加WIM文件的大小。此外，一个WIM文件可存储多个类似的映像;只有多个映像之间的差异才会增加WIM文件的整体内存占用。

　　部署

　　生成并捕获映像后，即可在产品计算机部署映像。根据环境的不同，OEM开发人员可能需要重新在一台、数台，乃至成千上万台设备上重新部署映像。应针对不同场景，采取不同的部署方法。

　　Windows Embedded Standard 2009中没有专门针对重新部署流程提供帮助的工具。进行小批量重新部署时，OEM开发人员可简单地将操作系统文件复制到目标设备的磁盘上。大批量重新部署则需借助第三方工具。

　　微软在Windows Embedded Standard 7中提供了多种部署选项。第一种方法是使用ImageX。ImageX不仅可将文件捕获为WIM文件格式，而且还可将WIM文件部署到目标磁盘上。OEM开发人员可使用ImageX手动部署WIM文件，或使用ImageX编写脚本，进行自动部署。

　　对于小批量部署的第二种方法是通过IBW进行。用户可以使用IBW查看WIM文件并完成安装。除进行标准WIM部署外，IBW还可以向正在安装的映像中添加语言包，用户甚至可以利用IBW将无人参与文件应用到映像。

　　最后，OEM开发人员可以为了部署Windows Embedded Standard 7映像，而设置Windows Deployment Services(WDS)或System Center Configuration Manager服务器。WDS和Configuration Manager支持面向多个设备进行大规模部署，Windows Embedded Standard 7对它们提供全面支持。

        开发流程各阶段所用工具总结

工具总结