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.
In Windows Embedded Standard 2009, EEFs are implemented the same way as other components. In Windows Embedded Standard 7, similarly, EEFs are implemented the same way as other feature sets. Windows Embedded Standard 7 is designed to keep parity with Windows Embedded Standard 2009 for EEFs, with a few exceptions as listed in the following table.
Support for Customized Components
In Windows Embedded Standard 2009, OEM developers can implement their own customized components by creating the appropriate SLD files with the appropriate binaries, and then importing them into the component database. This process gives customized components the capability of extending features and integrating them into the development platform to provide a seamless user experience using the embedded toolkit (for example, Target Designer).
In Windows Embedded Standard 7, OEM developers cannot create customized components or feature sets; therefore, their experience with the embedded toolkit and development platform will not be the same. However, OEM developers can create customized features (including third-party drivers) that can be placed under the $OEM$ folder in the distribution share. This will allow OEM developers to include customized features in the embedded run-time images, or redistribute them as a configuration set. However, by using this approach the customized features cannot express any dependencies to Windows Embedded Standard 7 feature sets. There is no tool-based mechanism to change settings.
Modified Windows 7 Behavior for Embedded Needs/Scenarios
In addition to the differences in componentization between Windows Embedded Standard 2009 and Windows Embedded Standard 7 as mentioned above, certain behaviors for Windows 7 features have also been modified to better suit embedded needs. Most of these behaviors are modified using the SMI settings, which are listed in the following table.
Comparing the Image-Building Process
The process of creating a Windows Embedded Standard OS can be broken down into the following steps:
1. Device Analysis Determining what devices are on the target computer and adding drivers to support those devices.
2. Configuration Adding the desired packages for the OS and configuring any associated settings.
3. Building Forming the OS for the device
4. Customization Adding any third-party files or programs to the OS
5. Capture Bundling the OS into one cohesive unit for redeployment on other devices.
6. Deployment Taking the preconfigured OS and installing it on one or more devices.
Shown below are two diagrams that give an overview of the Windows Embedded Standard 2009 and Windows Embedded Standard 7 image building process. (Click on either image to enlarge.)
In this paper, each step in the list above is examined for the differences in the development process between Windows Embedded Standard 2009 and Windows Embedded Standard 7.
Device Analysis
In Windows Embedded Standard 2009, device analysis is done by using the Target Analyzer (Tap.exe) program. OEM developers are advised to boot Windows Preinstallation Environment (PE) on their device and run Tap.exe. Tap.exe will, by default, generate a Devices.pmq file, which lists all hardware on the target device.
Once the Devices.pmq file is obtained, it can be imported using Target Designer. Devices will be automatically mapped to drivers, and the components containing these drivers will be added to the configuration.
In Windows Embedded Standard 7, device analysis is done in a similar manner, but is somewhat streamlined. Similarly, Target Analyzer is used to create a Devices.pmq file. The process for running Tap.exe, however, is made easier.
If you are developing images using the Image Builder Wizard (IBW), Tap.exe is run automatically in the background, and devices are automatically mapped to driver packages. As IBW is executed on the target device, the target hardware can be analyzed directly before build time, instead of as a separate step before creating the configuration.
If you are developing images using ICE, the device-analysis procedure is nearly the same as with Windows Embedded Standard 2009. Tap.exe can be run from Windows PE, or it can be run from the IBW disk. The OEM developer can then import the Devices.pmq file into ICE, where each device will be mapped to a driver package and added to the configuration.
Configuration
In Windows Embedded Standard 2009, image configuration is done in the Target Designer tool. Target Designer is an application that runs on an OEM developers computer and provides an IDE for creating the Windows Embedded Standard 2009 OS. OEM developers can create a new configuration and add drivers, software, and Embedded Enabling Feature components to create their own customized OS. Developers can also add macro and template components which can contain groupings of component binaries and settings. Developers can also choose to edit settings associated with the OS or its components.
Once the basic components have been added, OEM developers must resolve dependencies. This will automatically check the components that were added to the configuration, and add in any additional components that are required for the OS to function. After dependencies have been resolved, the configuration can be saved as a .slx file and used to build OS images.
In Windows Embedded Standard 7, two interconnected development experiences are available. IBW is a wizard-based development tool that allows users to quickly and easily prototype device configurations. ICE is similar to Target Designer, allowing the OEM developer to fully control every aspect of their OS.
IBW is a setup wizard that is run on the target device. It can automatically detect devices on the system and install the appropriate drivers. OEM developers can start from a template configuration, or manually choose the feature packages they want in their OS. Dependencies are resolved, and once the configuration is done, IBW installs the OS directly onto the device.
ICE is similar to Target Designer in that it is an IDE experience that runs on the OEM developers computer. Developers can add drivers, software, and EEF packages to their configuration. They can also add templates to configurations to serve as starting points, or they can add a collection of functionality. The OEM developer can also modify settings for the OS and resolve dependencies.
Once an OEM developer decides a given configuration is done, it can be saved to an answer file. This file lists all of the packages to be installed, and settings to be set. The answer file is passed on to IBW so that the OS can be built.
In Windows Embedded Standard 2009, building the OS is done on the OEM developers computer. After the configuration is finalized in Target Designer, the OEM developer can build the image. Target Designer creates the OS folder structure at a build location specified by the developer, and populates the folder structure with the binaries and registry hives for the target OS. The OEM developer can then copy these files to the disk on the target device. When the target device is booted, Windows Embedded Standard 2009 goes through the First Boot Agent (FBA), which finalizes the installation of the OS. After FBA is complete, the OS is ready to use.
In Windows Embedded Standard 7, building the OS happens entirely on the target device. In both the IBW and ICE configuration methods, the configuration is finalized in the IBW tool, and the OS is built. IBW installs the base OS on the device first, then installs the selected packages and applies any configured settings. After the basic installation is finished, the device will reboot into the installed OS. Then, much like in FBA, the finalization of the OS will take place, and the OS will be ready to use.
Customization
In Windows Embedded Standard 2009, OEM developers have several ways to add third-party applications to their configurations. The first method is by using the Component Designer tool. This allows developers to create custom components that contain the custom files and registry keys for their applications or drivers, as well as listing the dependencies on other components. These components are imported into the Component Database and are visible in Target Designer. In this way, OEM developers can create permanent components which act like any other part of the OS and can be shared between multiple configurations. Custom components are also versioned to allow for revision control. If developers want to add third-party files or registry keys to a single configuration without using a custom component, Target Designer also allows for additional files and resources to be manually added to the configuration using the Extra Files, Extra Registry Data, or Extra Resources nodes. These files will be installed to the device when using this configuration, but will not be available in other configurations, and cannot be version controlled.
In Windows Embedded Standard 7, there is no Component Designer tool. Windows Embedded Standard 7 uses the concept of $OEM$ folders to place third-party files onto the target image. If third-party files must be installed through an installation program, synchronous commands can be used to execute installers during the installation process. $OEM$ folders do not allow for dependencies or built-in version control. However, users can create templates to group feature packages together, and then separate folders for different versions of files.
Capture
After the desired image has been configured and built onto a device, the OEM developer might want to capture the image so that the identical configuration can later be deployed to multiple devices.
In Windows Embedded Standard 2009, OEM developers must use the System Cloning tool, which contains Fbreseal.exe, before capturing their image. During the installation process, each installation is made unique. Fbreseal.exe strips out any unique identifiers so that the installation can be transferred to multiple computers. After running Fbreseal.exe, OEM developers can use third-party tools to capture their images for later deployment. Windows Embedded Standard 2009 also provides limited support for Sysprep, which can only be used to prepare an image for use with System Center Configuration Managers Operating System Deployment method.
In Windows Embedded Standard 7, OEM developers use Sysprep instead of Fbreseal.exe. Sysprep performs similar functions as Fbreseal.exe, generalizing the image so that it can be captured and later redeployed. Sysprep has the option to force the deployed OS into the Out of Box Experience (OOBE), or Audit mode, which allows either the end user to configure the OS settings, or allows the OEM developer to ensure everything is preset before the device is released to the end-user customer. An unattended file can also be passed to Sysprep so that additional commands can be executed, or settings configured.
After running Sysprep, the image can be captured by using ImageX for later redeployment. ImageX captures the entire contents of a target disk to a Windows Imaging (WIM) file. WIM files are file-based, which allows for substantial compression. Duplicate files are only stored in the WIM file once, so multiple copies of the same file will not significantly increase the size of the WIM file. Additionally, multiple similar images can be stored within a single WIM file; only the differences between the images increase the overall memory footprint of the WIM file.
Deployment
After the image has been generalized and captured, it can be deployed to production computers. Depending on the environment, OEM developers might need to redeploy the image to one, several, or even thousands of devices. Different deployment methods can be used for each scenario.
In Windows Embedded Standard 2009, no dedicated tools were available to aid in the redeployment process. For low-volume redeployments, OEM developers would simply copy the OS files to the disk on the target device. High-volume redeployments would require the use of third-party tools.
In Windows Embedded Standard 7, several deployment options are available from Microsoft. The first, ImageX, not only captures files into the WIM file format, but also deploys WIM files to a target disk. OEM developers can use ImageX to manually deploy WIM files, or write scripts that use ImageX for automated deployment.
The second method for low-volume deployment is through IBW. Using IBW, users can browse to a WIM file and complete the installation. In addition to standard WIM deployment, IBW can also add Language Packages to an image being installed, and can even be used to apply an unattended file to an image.
Finally, OEM developers can set up Windows Deployment Services (WDS) or System Center Configuration Manager servers to deploy Windows Embedded Standard 7 images. WDS and Configuration Manager allow for large-scale deployment to multiple devices, and are both fully supported in Windows Embedded Standard 7.
Summary of Tools Used in Each Stage of the Development Process
Read the views of online Certification Experts, which provide the real questions and correct answer and explanation for the students / professionals who are seeking or enhancing their level of expertise. more at certkingdom.com
