在组件化工具和映像创建等方面的对比.docx
《在组件化工具和映像创建等方面的对比.docx》由会员分享，可在线阅读，更多相关《在组件化工具和映像创建等方面的对比.docx（14页珍藏版）》请在冰点文库上搜索。
在组件化工具和映像创建等方面的对比
WindowsEmbeddedStandard7与WindowsEmbeddedStandard2009在组件化、工具和映像创建等方面的对比
概述
本文介绍了WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7在组件化、工具和映像构建流程等方面的部分不同。
目的是使用户深入了解这两款嵌入式产品之间的差异，以及这两款产品在创建和部署嵌入式设备映像时在功能、工具和用户整体体验方面的部分不同。
组件化对比
本文将比较WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7在以下方面的不同：
∙组件架构
∙功能集包
∙驱动程序包
∙语言包
∙组件依赖关系
∙宏组件与模板
∙SMI（SettingsManagementInfrastructure，设置管理架构）的设置与配置设置
∙嵌入式功能（EEFs）
∙客户化组件支持
∙组件架构
WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7具有相似的组件化概念，即将注册表信息、依赖关系和其他资源定义在一个统一的二进制文件集中，所有这些数据都作为一个集合安装在运行的映像中。
但是，两款产品在组件实现和使用上是不同的。
对于WindowsEmbeddedStandard2009而言，其组件的实现是从头开始的。
因为WindowsEmbeddedStandard2009从WindowsXPPro继承来的二进制文件并未进行组件化。
因此，WindowsEmbeddedStandard2009的组件无法与包括WindowsEmbeddedStandard7在内的新推出的操作系统兼容。
此外，这些组件只是用来导入到用于开发的WindowsEmbeddedStandard2009的组件数据库中，而无法导入到嵌入式设备中。
要为这些设备提供服务，需要OEM开发人员使用更新后的组件重新创建整个运行时的映像。
WindowsEmbeddedStandard7的组件继承自Windows7，这些组件都列在组件清单上。
除了个别的是为了满足某些嵌入式的特殊需求而没有包括在Windows7中，其他的都与Windows7清单一样。
因此，WindowsEmbeddedStandard7与Windows7的设计完全兼容。
组件更新升级与Windows7也相似，仅需创建一个嵌入式开发的专用更新包，用户可将该更新包导入部署在OEM开发人员计算机上的WindowsEmbeddedStandard7分发共享目录（distributionshare）中，或直接安装到嵌入式运行映像上。
WindowsEmbeddedStandard7与WindowsEmbeddedStandard2009在组件设计上的另一个不同之处体现在嵌入式核心（eCore）这一概念上。
eCore包括一系列操作系统基本组件（内核、网络、安全、某些驱动程序等），这些基本组件用于引导有系统安全和网络功能的嵌入式设备。
eCore是嵌入式设备的最小映像，支持OEM开发人员在其上面添加其他功能集、驱动程序和语言包，本文将在下面对此进行讨论。
功能集包
对于WindowsEmbeddedStandard2009，当用户创建自己的设备映像时，需要在组件的层面上选择功能集包。
甚至某些重要功能（如，WindowsMediaPlayer、WindowsInternetExplorer、MicrosoftRemoteDesktopProtocol等）都是作为组件实现的，这是因为这些功能是由大量二进制文件聚集而成。
因此，组件和功能的区分不很明显。
此外，由于WindowsEmbeddedStandard2009有1万多个组件，因此用户如何从中选择合适的组件创建自己的映像成为一种挑战。
对于WindowsEmbeddedStandard7，创建功能集包的目的是聚合相关的组件（如，WindowsMediaPlayer、WindowsInternetExplorer、MicrosoftRemoteDesktopProtocol等），OEM开发人员只需选择他们所要部署的功能集即可。
由于要将功能集包的数量保持在最低水平（约为150个），所以功能选择流程更简单，设计和创建设备映像也更容易。
驱动包
在WindowsEmbeddedStandard2009中，每个驱动程序都作为独立组件实现，共有约9000个独立的驱动程序，对OEM开发人员而言，将这些驱动程序与相应的硬件设备配在一起是一项重大的挑战。
与功能集包类似，WindowsEmbeddedStandard7也提供包层面的驱动程序。
但是，为了降低程序的大小，各驱动程序都是以独立的包的形式提供，只有一个例外是USB驱动程序，此外，我们还提供了一个可选的支持USB启动的驱动程序包。
。
实际上，这些驱动程序包与WindowsEmbeddedStandard2009中的各个驱动程序组件相似。
WindowsEmbeddedStandard7放弃了Windows7中部分陈旧的驱动程序，创建了大约400个独立的驱动程序包。
此外，嵌入式核心（eCore）中还包括了约100个驱动程序的列表，能够满足例如系统引导、网络通信等基本需要。
总体而言，WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7的驱动程序基本相似，但WindowsEmbeddedStandard7中的驱动程序数量明显减少，而且eCore中还包含了部分基本的驱动程序。
语言包
WindowsXP并不是由语言中性的组件组成，所以，它不支持将单个语言包安装在一个语言中性的操作系统上。
每个操作系统二进制文件必须对不同的语言进行本地化，以满足不同国家和地区的需要。
这种设计不仅使错误修复、测试和OS组件服务复杂化，而且对需要多种语言支持映像的终端设备而言，还大大增加了操作系统的大小。
WindowsEmbeddedStandard继承了WindowsXP相同的语言设计，但是，它额外提供了非英语的语言资源包，从而使得用户能够选择是否创建一种或多种语言的设备映像。
尽管如此，这并未解决上述的错误修复和OS组件维护复杂、占用内存太大等问题。
WindowsEmbeddedStandard7继承了与Windows7相同的支持语言中性的设计模型，可以将不同的语言包安装在同一个语言中性的操作系统上。
那些存在于WindowsXP和WindowsEmbeddedStandard2009中的问题在这得到了改善。
与Windows7一样，WindowsEmbeddedStandard7提供了多达36个完全本地化的语言包（LP），但实际安装的LIP语言包（language-interfacepackage）的数量取决于用户的需求。
此外，WindowsEmbeddedStandard7中的某种语言包只包含与功能和驱动程序包（及Embeddedcore）中的语言中性组件相对应的某种语言资源文件，从而，与Windows7相比，大大减小了包的大小。
语言包更小，使得OEM开发人员可根据具体需求，更容易地在专业设备上部署各种语言包。
组件依赖关系
WindowsEmbeddedStandard7采用了与WindowsEmbeddedStandard2009类似的组件依赖关系概念。
与WindowsEmbeddedStandard2009不同，WindowsEmbeddedStandard2009的依赖关系表现在组件层面，WindowsEmbeddedStandard7则表现在功能集包层面。
如下表所示，WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7的依赖关系类型相似。
依赖关系类型
WindowsEmbeddedStandard2009
WindowsEmbeddedStandard7
直接（必需）依赖关系
是
是
一个组满足可以选择其中零个或者多个
否
是
一个组满足必须而且只能选择一个
是
是
一个组满足必须选择一个或者一个以上
是
是
一个组满足不能选择任何一个
是
是
一个组必须同时包含组里所有的依赖关系
是
否（但包含在直接依赖关系或“零个或多个”依赖关系中）
宏组件与模板
在WindowsEmbeddedStandard2009中，为满足安装某些功能或应用的依赖关系，可应用宏组件，或将宏组件导入组件数据库中。
宏组件可指定某些配置设置，以及任何所需的和/或可选的依赖关系。
宏组件的安装与标准组件类似，但宏组件中不包含任何文件。
因此，OEM开发人员可使用（如TargetDesigner等）嵌入式工具修改配置的设置。
WindowsEmbeddedStandard7中也采用了类似的概念。
有一个模板是用于满足特定功能或应用的安装。
该模板详细列出了一系列的功能集包，这些包对于这类功能或应用来说是必需的。
但是，模板的安装方式与标准功能集包的安装方式不太相同，它不允许使用（例如映像配置编辑器，ICE）等嵌入式工具更改配置设置。
SMI设置与配置设置
在WindowsEmbeddedStandard2009中，用户可以使用组件指定配置设置（例如，定义防火墙端口等），系统支持OEM开发人员使用TargetDesigner设定所需的设置值。
这些设置使用HTML作为用户界面应用到组件wrapper文件（或SLD），这些设置可修改某些特定功能的运行（例如，启用或禁用防火墙端口）。
在WindowsEmbeddedStandard7中，OEM开发人员可以通过ICE控制的唯一设置是从Windows7继承来的组件中可见和可变的SMI设置。
此外在功能集包层面没有任何其他设置可执行。
因此，功能的某些操作是不可见的，或者是不能定义为组件层的SMI设置，不能进行修改（例如，设置防火墙端口）。
换言之，WindowsEmbeddedStandard7的OEM开发体验与WindowsEmbeddedStandard2009大相径庭。
嵌入式功能（EEFs）
在WindowsEmbeddedStandard2009中，EEFs与其他组件的实现方式相同。
与之类似的是，在WindowsEmbeddedStandard7中，EEFs的实现方式与其他功能集相同。
在EEFs方面，除下表给出的少数例外，WindowsEmbeddedStandard7基本与WindowsEmbeddedStandard2009相同。
EEFs
WindowsEmbeddedStandard2009
WindowsEmbeddedStandard7
增强型写入过滤器（EWF）
是
是
基于文件的写入过滤器（FBWF）
是
是
注册表过滤器
是
是
消息框默认回复
是
是
自定义外壳支持
是
是（已改进）
RAM磁盘控制器
是
是
USB引导
是
是
CD/DVD引导
是
否
SD引导
否
未来可能
VHD引导
否
未来可能
对话框过滤器
否
是
版本标识
否
是
自定义登录桌面背景
否
是
隐藏引导屏幕
否
是
基于.NET设备的Web服务
否
是
设备更新代理
是
否
电源管理程序
是
电源管理功能集
自定义组件支持
在WindowsEmbeddedStandard2009中，OEM开发人员可通过创建适用的二进制文实现适用的SLD文件自定义组件，然后将组件导入组件数据库。
这样，这些客户化的组件就具有扩展功能并可被集成到开发平台，使用（例如TargetDesigner等）嵌入式工具为用户提供无缝的体验。
由于OEM开发人员无法在WindowsEmbeddedStandard7中创建自定义组件或功能集，所以对于嵌入式包和开发平台，他们的体验会有所不同。
然而，OEM开发人员可以创建自定义的功能（包括第三方驱动程序），放入到分发共享目录中的“$OEM$”文件夹。
这样可以支持OEM开发人员将自定义功能加入嵌入式运行时映像，或将它们作为配置集重新分发。
但如果使用这种方法，自定义功能不能表示与WindowsEmbeddedStandard7功能集的任何依赖关系，系统中也没有基于工具的机制可改变设置。
满足嵌入式需求/场景的可修改的Windows7操作
如上所述，WindowsEmbeddedStandard2009与WindowsEmbeddedStandard7除在组件化方面有所不同外，为更好满足嵌入的需求，Windows7功能的某些操作也作了修改。
如下表所示，大多数操作的修改是通过SMI设置完成的。
功能
Windows7的操作
WindowsEmbeddedStandard7的操作
防火墙通知
默认为启用
默认为禁用
UAC
默认为启用
默认为禁用
页面文件
默认为启用
默认为禁用
自动更新
有更新时自动下载更新，并在下载完毕后通知安装
默认为禁用
休眠启用
启用
禁用
映像创建进程的比较
创建WindowsEmbeddedStandard操作系统的过程可分解为以下步骤：
1.设备分析——确定目标计算机上有哪些设备，并添加驱动程序，支持这些设备。
2.配置——向操作系统添加所需的包，并配置所有关联设置。
3.创建——形成设备的操作系统。
4.自定义——向操作系统添加任何第三方文件或程序。
5.捕获——将操作系统捆绑到一个聚合单元中，用于重新部署至其他设备。
6.部署——将预先配置的操作系统安装到一台或多台设备上。
下面的两张图表概括了WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7映像的创建过程。
对照上述各步骤，本文逐步讨论了WindowsEmbeddedStandard2009和WindowsEmbeddedStandard7开发流程的差异。
设备分析
在WindowsEmbeddedStandard2009中，设备分析是使用TargetAnalyzer（Tap.exe）程序完成的。
建议OEM开发人员在其设备上启动Windows预安装环境（PE）并运行Tap.exe。
默认情况下，Tap.exe将生成一个Devices.pmq文件，该文件将列出目标设备上的所有硬件。
可在得到Devices.pmq文件后，使用TargetDesigner导入该文件。
系统会自动把设备映射到驱动程序上，将包含这些驱动程序的组件添加到配置中。
WindowsEmbeddedStandard7的设备分析与此类似，但进行了简化。
WindowsEmbeddedStandard7同样利用TargetAnalyzer创建Devices.pmq文件。
但运行Tap.exe的流程更加简单。
如果用户使用ImageBuilderWizard（映像构建向导，IBW）开发映像，则Tap.exe自动在后台运行，系统会自动把设备映射到驱动程序包上。
由于IBW是在目标设备上执行的，所以不用作为创建配置前的单独步骤，可直接在创建时间前对目标硬件进行分析。
用户使用ICE开发映像时，设备分析过程几乎与WindowsEmbeddedStandard2009完全相同。
Tap.exe既可从WindowsPE运行，也可从IBW的磁盘运行。
接下来，OEM开发人员可将Devices.pmq文件导入ICE。
在ICE中，各设备将被映射到驱动程序包，并添加到配置中。
配置
在WindowsEmbeddedStandard2009中，映像配置在TargetDesigner工具上完成。
TargetDesigner是一个在OEM开发人员的计算机上运行的应用程序，可提供一个用于创建WindowsEmbeddedStandard2009操作系统的IDE。
OEM开发人员可创建新配置，并将其添加到驱动程序、软件和嵌入式功能组件中，创建自己的自定义操作系统。
开发人员还可以添加宏和模板组件，这些宏和模板组件可包含各种组件二进制文件和设置的组合。
此外，开发人员还可选择编辑与操作系统或其组件相关的设置。
添加基本组件后，OEM开发人员必须解决依赖关系问题。
系统将自动检查添加到配置中的组件，并添加操作系统功能所需的任何其他组件。
解决依赖关系问题后，开发人员可将配置保存为.slx文件，该文件用于创建操作系统映像。
在WindowsEmbeddedStandard7中，存在两种相互之间有关联的开发体验。
IBW是一个基于向导的开发工具，支持用户快速、简便地对样机设备进行配置。
ICE与TargetDesigner类似，支持OEM开发人员完全控制其操作系统的各个方面。
IBW是一个在目标设备上运行的安装向导，可自动检测系统中的设备，并安装相应的驱动程序。
OEM开发人员可以从模板配置入手，或手动选择他们希望添加到操作系统中的功能包。
解决依赖关系并完成配置后，IBW就可以将操作系统直接安装到设备上。
ICE与TargetDesigner的相似之处在于，ICE是一种在OEM开发人员的计算机上运行的IDE体验。
开发人员可以向配置中添加驱动程序、软件和EEF包，可以向配置中添加作为起始点的模板，还可以添加一系列功能。
此外，开发人员还能修改操作系统的设置，解决依赖关系问题。
OEM开发人员完成所需的配置后，可将配置保存到应答文件中。
该文件列出了所有要安装的功能或驱动程序包包和需要进行设置的配置。
可将应答文件传送至IBW，由此创建操作系统。
在WindowsEmbeddedStandard2009中，操作系统的创建是在OEM开发人员的计算机上完成的。
OEM开发人员可在TargetDesigner中完成配置后创建映像。
TargetDesigner在开发人员指定的位置创建一个操作系统文件夹结构，并使用目标操作系统的二进制文件和注册表配置单元填充该文件夹结构。
然后，OEM开发人员可将这些文件复制到目标设备的磁盘上。
系统引导目标设备时，WindowsEmbeddedStandard2009通过首次启动代理（FBA），由FBA完成操作系统的最终安装。
完成FBA后，操作系统即可投入使用。
在WindowsEmbeddedStandard7中，操作系统的创建完全在目标设备上进行。
无论是IBW和ICE配置方法，配置工作都在IBW工具上最终完成，从而实现操作系统的创建。
IBW首先在设备上安装基本操作系统，然后安装所选的包，并应用所有配置设置。
基本安装完成后，设备将重新启动到安装的操作系统。
然后，与FBA非常相似，完成操作系统的最终安装后，操作系统即可投入使用。
自定义
在WindowsEmbeddedStandard2009中，OEM开发人员可以通过多种方式向配置中添加第三方应用程序。
第一种方法是使用ComponentDesigner工具。
这种方法允许开发人员创建自定义组件。
这些自定义组件可包含自定义文件、应用程序或驱动程序的注册表项，以及其他组件依赖关系的列表。
这些组件被导入组件数据库，并在TargetDesigner中可见。
这样，OEM开发人员可以创建永久组件，永久组件的操作与操作系统的其他部分类似，可由多种配置共享。
此外，自定义组件还支持版本修订控制。
如果开发人员不希望使用自定义组件而向某个配置添加第三方文件或注册表项，TargetDesigner还支持使用ExtraFiles、ExtraRegistryData或ExtraResources节点将其他文件和资源手动添加到配置中。
使用该配置时，这些文件将安装到设备上，但使用其他配置时，这些文件将无法安装到设备上，也无法进行版本控制。
WindowsEmbeddedStandard7中没有ComponentDesigner（组件设计）工具。
WindowsEmbeddedStandard7使用$OEM$文件夹的概念将第三方文件加入目标映像。
如果必须通过安装程序安装第三方文件，则用户可在安装过程中使用同步命令执行安装程序。
$OEM$文件夹不支持依赖关系或内置的版本控制功能。
但用户可以创建模板，将功能包组合到一起，然后按照文件版本的不同区分文件夹。
捕获
在对所需映像进行配置，并创建到设备上以后，OEM开发人员可能需要捕获映像，用于日后在多台设备上部署相同配置。
在WindowsEmbeddedStandard2009中，OEM开发人员必须在捕获操作系统映像前使用包含Fbreseal.exe的系统克隆（SystemCloning）工具。
在安装过程中，每次安装都具有唯一性。
Fbreseal.exe可去除任何唯一标识符，以便这种安装可以复制到多台计算机上。
运行Fbreseal.exe后，OEM开发人员可使用第三方工具捕获映像，供日后部署时使用。
WindowsEmbeddedStandard2009还对Sysprep提供有限支持。
Sysprep仅用于为使用系统中心配置管理器操作系统部署方法（SystemCenterConfigurationManager’sOperatingSystemDeployment）而准备映像时使用。
在WindowsEmbeddedStandard7中，OEM开发人员使用的是Sysprep，而不是Fbreseal.exe。
Sysprep的功能与Fbreseal.exe类似，可生成映像，以便可以捕获映像，并用于重新部署。
Sysprep具有强制被部署的操作系统进入OutofBoxExperience（OOBE）或Audit模式，支持最终用户配置操作系统设置，以及OEM开发人员确保在向最终用户发布设备前已完成了全部预设置工作。
用户也可将无人值守安装应答文件传递到Sysprep，以便系统执行其他命令或对设置进行配置。
运行Sysprep后，用户即可使用ImageX捕获映像用于重新部署。
ImageX可将目标磁盘的全部内容捕获到WindowsImaging（WIM）文件中。
WIM文件是基于文件的，可进行大规模压缩。
对于重复的文件，系统只在WIM文件中存储一次，这样同一文件的多个副本不会显著增加WIM文件的大小。
此外，一个WIM文件可存储多个类似的映像；只有多个映像之间的差异才会增加WIM文件的整体内存占用。
部署
生成并捕获映像后，即可在产品计算机部署映像。
根据环境的不同，OEM开发人员可能需要重新在一台、数台，乃至成千上万台设备上重新部署映像。
应针对不同场景，采取不同的部署方法。
WindowsEmbeddedStandard2009中没有专门针对重新部署流程提供帮助的工具。
进行小批量重新部署时，OEM开发人员可简单地将操作系统文件复制到目标设备的磁盘上。
大批量重新部署则需借助第三方工具。
微软在WindowsEmbeddedStandard7中提供了多种部署选项。
第一种方法是使用ImageX。
ImageX不仅可将文件捕获
升级会员 