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
June 23, 2011
June 21, 2011
Windows signage modules follow Intel Open Pluggable Specfication
NEC unveiled two computing modules that follow Intel's Open Pluggable Specification (OPS) for digital signs running Windows Embedded Standard 7. Designed to slot into the back of the company's displays, they're the Intel Core i5-powered N8000-8330 and the AMD-powered SB-02SC-2, according to the company.
Last year, Intel announced its Open Pluggable Specification (OPS), a standardized design for digital signage computers. At the time, not much information was revealed publicly, but the chipmaker said the OPS would involve the use of its Core processors along with Microsoft's Windows Embedded Standard operating system.
We've now unearthed a little more information about what OPS involves -- reviewed later in this story -- and NEC, an early supporter of the spec, has revealed two new devices using it. Both, the company says, are 7.87 x 5.41 x 1.18-inch modules designed to slot into the back of "select NEC X, P and V Series displays, including the new V462, P402 and P462."
According to NEC, the N8000-8330 module incorporates an Intel Core i5 processor (module not specified), a 320GB hard disk drive, and the Windows Embedded Standard 7 operating system. Further specs were not provided, but the images at left and lower below make clear that the device has an Ethernet port, two USB 2.0 ports, audio I/O, and a DisplayPort output for a secondary display.
Intel had touted fanless operation for OPS devices, but the N8000-8330 appears to incorporate a cooling fan. The device features Intel's vPro technology, with keyboard-video-ouse redirection capabilities that allow IT administrators to run diagnostic tests, install upgrades, and view and control the digital display content remotely, according to NEC.
We'd assumed that OPS would be limited to Intel-based devices, but this is not the case. NEC's digital signage website has also listed -- but has not yet pictured -- another model known as the SB-02SC-2, which it says will use a dual-core, 1.6GHz AMD Fusion processor. (Probably the E-350.) According to the company, this device will also come with Windows Embedded Compact 7, and features a 32GB solid state disk.
Pierre Richer, president and COO of NEC Display Solutions, stated, "As the first industry-wide standard for digital signage, the OPS will simplify the use and maintenance of digital signage, and create a smaller product footprint, allowing for thinner displays. The operation of OPS-based products will allow easier installations, resulting in more deployments by current and new customers."
Jose Avalos, director of retail and digital signage for Intel's Embedded Communications group, stated, "Installing digital signage equipment based on Intel architecture results in scalable digital signage networks that are easy to maintain and upgrade to fit customer requirements for lower total cost of ownership. The release of the first OPS-based accessory from NEC Display Solutions is the next step in bringing standardization to the digital signage market segment."
More about the Open Pluggable Specification
As we've mentioned, Intel didn't reveal much about the Open Pluggable Specification when it was first announced last October. A December blog entry clarified matters as follows, however.
According to the posting, OPS defines a standardized module and related interconnections "to insure compatibility and ease of integration between digital signage components from multiple vendors." As shown below, the standard specifies an off-the-shelf 80-pin JAE Electronics TX24/TX25 blind mate plug and receptacle connector system to interface the pluggable module and the display.
A diagam of Intel's Open Pluggable Specification
(Click to enlarge)
The pluggable module itself consists of a printed circuit computing board housed in a protective wrapper chassis, Intel adds. The circuit board should be equal to or smaller than the EPIC (Embedded Platform for Industrial Computing) standard size of 115 x 165mm, and the overall dimension of the module including the mounting frame is 200 x 119 x 30mm, the company says.
It's said the OPS standard also defines the interface signals for all 80 pins of the JAE connector. For example, power input is specified as 12~19V DC at less than 4A and is spread over multiple pins to stay within the connector's maximum current rating. Other pins carry the digital signals for interface to the display, including HDMI, DVI, DisplayPort, audio, serial, plus provision for both USB 2.0 and USB 3.0, according to Intel.
According to Intel, the OPS standard also includes thermal specifications and details cooling requirements for modules based on the Core i7 processor and QM57 chipset. The company adds, "Although it is not required by the specification, installing digital signage equipment based on Intel architecture helps you implement scalable digital signage applications that can network easily with other equipment."
Last year, Intel announced its Open Pluggable Specification (OPS), a standardized design for digital signage computers. At the time, not much information was revealed publicly, but the chipmaker said the OPS would involve the use of its Core processors along with Microsoft's Windows Embedded Standard operating system.
We've now unearthed a little more information about what OPS involves -- reviewed later in this story -- and NEC, an early supporter of the spec, has revealed two new devices using it. Both, the company says, are 7.87 x 5.41 x 1.18-inch modules designed to slot into the back of "select NEC X, P and V Series displays, including the new V462, P402 and P462."
According to NEC, the N8000-8330 module incorporates an Intel Core i5 processor (module not specified), a 320GB hard disk drive, and the Windows Embedded Standard 7 operating system. Further specs were not provided, but the images at left and lower below make clear that the device has an Ethernet port, two USB 2.0 ports, audio I/O, and a DisplayPort output for a secondary display.
Intel had touted fanless operation for OPS devices, but the N8000-8330 appears to incorporate a cooling fan. The device features Intel's vPro technology, with keyboard-video-ouse redirection capabilities that allow IT administrators to run diagnostic tests, install upgrades, and view and control the digital display content remotely, according to NEC.
We'd assumed that OPS would be limited to Intel-based devices, but this is not the case. NEC's digital signage website has also listed -- but has not yet pictured -- another model known as the SB-02SC-2, which it says will use a dual-core, 1.6GHz AMD Fusion processor. (Probably the E-350.) According to the company, this device will also come with Windows Embedded Compact 7, and features a 32GB solid state disk.
Pierre Richer, president and COO of NEC Display Solutions, stated, "As the first industry-wide standard for digital signage, the OPS will simplify the use and maintenance of digital signage, and create a smaller product footprint, allowing for thinner displays. The operation of OPS-based products will allow easier installations, resulting in more deployments by current and new customers."
Jose Avalos, director of retail and digital signage for Intel's Embedded Communications group, stated, "Installing digital signage equipment based on Intel architecture results in scalable digital signage networks that are easy to maintain and upgrade to fit customer requirements for lower total cost of ownership. The release of the first OPS-based accessory from NEC Display Solutions is the next step in bringing standardization to the digital signage market segment."
More about the Open Pluggable Specification
As we've mentioned, Intel didn't reveal much about the Open Pluggable Specification when it was first announced last October. A December blog entry clarified matters as follows, however.
According to the posting, OPS defines a standardized module and related interconnections "to insure compatibility and ease of integration between digital signage components from multiple vendors." As shown below, the standard specifies an off-the-shelf 80-pin JAE Electronics TX24/TX25 blind mate plug and receptacle connector system to interface the pluggable module and the display.
A diagam of Intel's Open Pluggable Specification
(Click to enlarge)
The pluggable module itself consists of a printed circuit computing board housed in a protective wrapper chassis, Intel adds. The circuit board should be equal to or smaller than the EPIC (Embedded Platform for Industrial Computing) standard size of 115 x 165mm, and the overall dimension of the module including the mounting frame is 200 x 119 x 30mm, the company says.
It's said the OPS standard also defines the interface signals for all 80 pins of the JAE connector. For example, power input is specified as 12~19V DC at less than 4A and is spread over multiple pins to stay within the connector's maximum current rating. Other pins carry the digital signals for interface to the display, including HDMI, DVI, DisplayPort, audio, serial, plus provision for both USB 2.0 and USB 3.0, according to Intel.
According to Intel, the OPS standard also includes thermal specifications and details cooling requirements for modules based on the Core i7 processor and QM57 chipset. The company adds, "Although it is not required by the specification, installing digital signage equipment based on Intel architecture helps you implement scalable digital signage applications that can network easily with other equipment."
June 20, 2011
Windows coming to more devices, Steve Ballmer reaffirms
"There are more than 1 billion Windows PCs in the hands of customers around the world today, and in January we announced [link] that the next version of Windows will support system-on-chip architectures from Intel, AMD and ARM," Ballmer told the Convergence audience in Atlanta. "So, whatever device that you use now or in the future, Windows will be there."
ARM-based systems from companies such as Qualcomm, Nvidia and Texas Instruments currently power a wide range of popular mobile devices, including tablets. In theory, SoC support would allow some version of Windows to appear on those devices, although Microsoft remains tight-lipped about details of any next-version operating system.
Throughout April, bloggers Rafael Rivera and Paul Thurrott, in a series of postings on Riveras Within Windows blog, have dissected what they call an early build of "Windows 8," which includes some features -- including a lock screen with an icon for power management -- seemingly designed for portable devices.
A prospective Windows 8 welcome screen
Source: Within Windows(Click to enlarge)
A ribbon-equipped explorer for Windows 8?
Source: Within Windows(Click to enlarge)
Ballmers comments echo earlier ones he made at the Gartner Symposium/ITxpo in October 2010, in which he hinted that the companys software running on smartphones fell under the same "Windows" umbrella as the desktop-and-laptop version. At the time, he also characterized "the next release of Windows" as Microsofts riskiest bet.
Despite its longtime hegemony of the operating system market, Windows faces a number of challenges in coming years: from an increasing emphasis on the cloud, which takes various functions traditionally restricted to a local drive and places them online, and from mobile-based operating systems such as iOS and Google Android, which have risen in prominence as people use their smartphones and tablets more and more for daily computing.
A version of Windows that embraces both the traditional, desktop-bound paradigm and the newer, mobile-centric one would help counter both those threats. In the meantime, Microsoft has been very loudly proclaiming its "all in" cloud strategy, particularly with regard to business applications.
"Make no mistake, when it comes to the cloud, Microsofts all in," Ballmer told the audience gathered at the Convergence conference. "Every one of our products will be engineered to deliver the full benefits of the cloud."
As part of that effort, Microsoft is planning to release the next versions of its enterprise-resource planning applications on the cloud-based Windows Azure platform. At the conference, the company also provided a glimpse of Microsoft Dynamics AX 2012, an ERP application whose beta is due this month. Microsoft Dynamics AX 2012 includes Unified Natural Models, a library of business processes for real-world situations, and enhanced business intelligence capabilities for discovering fresh insights in data.
Earlier this year, Microsoft released Dynamics CRM Online, a cloud competitor to similar offerings from the likes of Salesforce.com and Oracle. It is also planning a wide release of Office 365, the cloud-subscription version of its productivity-software suite.
ARM-based systems from companies such as Qualcomm, Nvidia and Texas Instruments currently power a wide range of popular mobile devices, including tablets. In theory, SoC support would allow some version of Windows to appear on those devices, although Microsoft remains tight-lipped about details of any next-version operating system.
Throughout April, bloggers Rafael Rivera and Paul Thurrott, in a series of postings on Riveras Within Windows blog, have dissected what they call an early build of "Windows 8," which includes some features -- including a lock screen with an icon for power management -- seemingly designed for portable devices.
A prospective Windows 8 welcome screen
Source: Within Windows(Click to enlarge)
A ribbon-equipped explorer for Windows 8?
Source: Within Windows(Click to enlarge)
Ballmers comments echo earlier ones he made at the Gartner Symposium/ITxpo in October 2010, in which he hinted that the companys software running on smartphones fell under the same "Windows" umbrella as the desktop-and-laptop version. At the time, he also characterized "the next release of Windows" as Microsofts riskiest bet.
Despite its longtime hegemony of the operating system market, Windows faces a number of challenges in coming years: from an increasing emphasis on the cloud, which takes various functions traditionally restricted to a local drive and places them online, and from mobile-based operating systems such as iOS and Google Android, which have risen in prominence as people use their smartphones and tablets more and more for daily computing.
A version of Windows that embraces both the traditional, desktop-bound paradigm and the newer, mobile-centric one would help counter both those threats. In the meantime, Microsoft has been very loudly proclaiming its "all in" cloud strategy, particularly with regard to business applications.
"Make no mistake, when it comes to the cloud, Microsofts all in," Ballmer told the audience gathered at the Convergence conference. "Every one of our products will be engineered to deliver the full benefits of the cloud."
As part of that effort, Microsoft is planning to release the next versions of its enterprise-resource planning applications on the cloud-based Windows Azure platform. At the conference, the company also provided a glimpse of Microsoft Dynamics AX 2012, an ERP application whose beta is due this month. Microsoft Dynamics AX 2012 includes Unified Natural Models, a library of business processes for real-world situations, and enhanced business intelligence capabilities for discovering fresh insights in data.
Earlier this year, Microsoft released Dynamics CRM Online, a cloud competitor to similar offerings from the likes of Salesforce.com and Oracle. It is also planning a wide release of Office 365, the cloud-subscription version of its productivity-software suite.
Subscribe to:
Posts (Atom)
