Windows Embedded Standard 7 Versus 2009 � Componentization, Tools, and Building Images

Foreword — Contributed by Robert Smith and the Windows Embedded team, this whitepaper describes some of the differences between Windows Embedded Standard 2009 and Windows Embedded Standard 7 with respect to componentization, tools, and image-building processes. It follows a previous whitepaper (also available on our site, here), that compared the two operating systems at a higher level.

 

Best Microsoft MCTS Training, Microsoft MCITP Training at certkingdom.com

 

Windows Embedded Standard 7 Versus Windows Embedded Standard 2009 Componentization, Tools, and Building Images

Introduction

This paper describes some of the differences between Windows Embedded Standard 2009 and Windows Embedded Standard 7 with respect to componentization, tools, and image-building processes. The goal is to provide customers with a high-level understanding of the differences between the two embedded products, as well as providing an understanding of some of the different behaviors in features, tools, and overall user experience in building and deploying embedded-device images.
Componentization Comparison

In this paper we will look at the following areas to compare some of the differences between Windows Embedded Standard 2009 and Windows Embedded Standard 7:

* Component architecture
* Feature-set packages
* Driver packages
* Language packages
* Component dependencies
* Macro components versus templates
* Settings Management Infrastructure (SMI) settings versus configuration settings
* Embedded enabling features (EEFs)
* Support for customized components

Component Architecture

Both Windows Embedded Standard 2009 and Windows Embedded Standard 7 have a similar componentization concept, namely a set of binaries (files, etc.), specified in a wrapper file together with other information such as registry keys, dependencies, and other resources. All of this data is installed in the run-time image as a group. However, beyond the componentization concept, the implementation and servicing of components is quite different in each product.

For Windows Embedded Standard 2009, the implementation of a component was created from scratch because the original binaries it inherits from Windows XP Pro are not componentized.

As a result, Windows Embedded Standard 2009 components will not be compatible with future versions of the operating system (OS), including Windows Embedded Standard 7. Also, these components were designed to be imported into the Windows Embedded Standard 2009 component database only, in development computers instead of in the embedded target devices. Servicing the devices requires OEM developers to rebuild an entire run-time image with the updated components.

For Windows Embedded Standard 7, the components are inherited from Windows 7, which are specified in component manifests. In addition to a few exceptions needed to satisfy certain embedded requirements, all of these Windows 7 manifests remain unchanged for Windows Embedded Standard 7. As a result, the design maintains complete compatibility between Windows Embedded Standard 7 and Windows 7. Servicing components is similar to that in Windows 7, requiring only the creation of an embedded-specific update package that can be imported to the Windows Embedded Standard 7 distribution share on OEM development computers, or installed directly on the embedded run-time images.

Another component design variation of Windows Embedded Standard 7 from Windows Embedded Standard 2009 is the concept of embedded core (or eCore). eCore consists of a set of fundamental OS components (kernel, networking, security, some drivers, etc.) that facilitate the booting up of an embedded device with system security and networking capabilities. eCore is the minimum image of an embedded device that allows OEM developers to add, on top of it, other feature sets, drivers, and language packages, which will be described later in this paper.
Feature Set Packages
For Windows Embedded Standard 2009, customers are required to choose feature set packages at the component level when building their device images. Even certain large features (for example, Windows Media Player, Windows Internet Explorer, Microsoft Remote Desktop Protocol, etc.) are implemented as components because they are an aggregation of a large set of binaries. Thus, there is no clear distinction between a component and a feature. In addition, Windows Embedded Standard 2009 contains over 10,000 components, which makes it challenging for customers to choose the right components to build their images.

For Windows Embedded Standard 7, feature-set packages are created to aggregate relevant components (for example, Windows Media Player, Windows Internet Explorer, Microsoft Remote Desktop Protocol, etc.); OEM developers are only required to select the feature sets they want to deploy. Because the number of feature-set packages is kept to a minimum (around 150 packages), the feature-selection process is simpler, making it easier to design and build device images.
Driver Packages

For Windows Embedded Standard 2009, each driver is implemented as a separate component. There are about 9,000 individual drivers, which can present a significant challenge to OEM developers when matching drivers to their hardware devices.

Similar to feature-set packages, drivers in Windows Embedded Standard 7 are also provided at the package level. However, to keep the footprint size small each driver is provided as a single package, with the exception of the USB drivers, which are also aggregated and implemented with an alternative USB Boot package. Essentially, these driver packages are similar to the individual driver components in Windows Embedded Standard 2009. By eliminating some of the legacy drivers in Windows 7, Windows Embedded Standard 7 contains approximately 400 individual driver packages. In addition, there is a list of about 100 drivers included in the embedded core (eCore) to facilitate basic needs such as system boot-up, network communication, etc.

Overall, drivers are provided in similar granularity between Windows Embedded Standard 2009 and Windows Embedded Standard 7. However, Windows Embedded Standard 7 contains significantly fewer drivers. A list of drivers is included in the eCore.
Language Packages

Because Windows XP was not designed with language-neutral components, it does not include individual language packages to apply on top of the base-neutral OS. Each OS binary must be fully localized for different languages to meet the needs of different countries and regions. Such a design not only complicates bug fixing, testing, and servicing of OS components, it also significantly increases the OS footprint size for devices that require multiple languages on their images. Windows Embedded Standard 2009 inherits the same language design as Windows XP, with the exception of providing the non-English language resources in separate media, which gives customers a choice to build their device images with one or more languages; however, this does not eliminate the complication of fixing bugs, servicing OS components, and footprint size issue, as mentioned earlier.

Windows Embedded Standard 7 inherits the same language-neutral design model from Windows 7. Different language packages can be applied on top of the base-neutral OS. This approach makes it easier to fix bugs, provide service, and manage the size of the memory footprint in Windows XP and Windows Embedded Standard 2009. As with Windows 7, Windows Embedded Standard 7 provides up to 36 fully localized language packages (LPs). However, the number of available language-interface packages (LIPs) will depend on customer demand. Also, the language packages in Windows Embedded Standard 7 will only contain relevant language resources for their corresponding neutral components for each feature set and driver package (and eCore); therefore, their package sizes will be significantly smaller than those in Windows 7. Smaller language-package size should make it easier for OEM developers to deploy various language packages to their field devices, depending on the specific needs of each.
Component Dependency

Windows Embedded Standard 7 adopts a similar component-dependency concept as Windows Embedded Standard 2009. Unlike Windows Embedded Standard 2009, whose dependencies are expressed at the component level, dependencies in Windows Embedded Standard 7 are expressed at the feature-set package level. The types of dependencies are similar between Windows Embedded Standard 2009 and Windows Embedded Standard 7, as shown in the following table.

No (but is covered bydirect or Zero or more)
Macro Components vs. Templates

In Windows Embedded Standard 2009, to satisfy the dependencies to install a certain feature or application, a macro component can be implemented and imported into the component database. The macro component can specify certain configuration settings, as well as any required and/or optional dependencies. A macro component is implemented much like a standard component, however, the former does not contain any file. As a result, OEM developers can use the embedded tool (for example, Target Designer) to change the configuration settings.

In Windows Embedded Standard 7, a similar concept is used. A template is defined to satisfy the installation of a given feature or application. A template specifies a list of feature-set packages that are necessary for the feature or application. However, a template is not implemented quite the same way as a standard feature-set package; it does not allow the specification of configuration settings that can be altered by using the embedded tool (for example, Image Configuration Editor, or ICE).
SMI Settings vs. Configuration Settings

In Windows Embedded Standard 2009, a component can specify configuration settings (for example, defining firewall ports, etc.) and let OEM developers set the desired values for these settings by using Target Designer. Such settings are implemented in the component wrapper file (or SLD) using HTML as the user interface. The settings can change the behavior of a particular feature (for example, enabling or disabling a firewall port).

In Windows Embedded Standard 7, the only settings that can be manipulated by OEM developers through ICE are the visible and mutable SMI settings in the components inherited from Windows 7. There is no additional setting implemented at the feature-set package level. As a result, certain behaviors of a feature that are invisible, or not defined as part of the component level SMI settings, cannot be altered (for example, setting a firewall port). This means the OEM development experience will be significantly different than that of Windows Embedded Standard 2009.