Modules in Windows Embedded Standard 8

  • Article

Posted By J.T. Kimbell
Program Manager

As you may have noticed from our Community Technology Previews for Windows Embedded Standard 8, there have been some tweaks to how various technologies are represented and grouped in our toolkits, and they are not just cosmetic changes. Windows Embedded Standard 8 introduces the concept of modules, replacing the packages that were in Windows Embedded Standard 7 and providing more flexibility and enhanced functionality. In this post, Dave Massy gives an overview of modules and how they will change your development experience in Windows Embedded Standard 8. Dave is a Program Manager working on the componentization team of Windows Embedded. When not spending time with his young son and daughter, he enjoys driving his 1958 Jaguar XK 150 around the Puget Sound area. Additionally, Dave derives great pleasure from replacing any Z he finds with the letter S to properly conform to the Queen’s English.

Introduction

In Windows Embedded Standard 8 there are subtle changes from Windows Embedded Standard 7 in how we expose individual technologies as building blocks for creating your OS These building blocks allow you to create an OS image that matches your needs and not include functionality you do not need.

In Windows Embedded Standard 7 we referred to the building blocks of the OS as packages. In Windows Embedded Standard 8, they are modules. Packages and modules may seem similar because you use them to build up a functional image. However, under the hood there are technical differences that allow us to improve the overall experience of using the catalog and defining an image that meets your needs. For instance, one of the key advantages is that third-party modules can be in the catalog alongside OS modules. You can even create your own modules using the Module Designer tool that is included in the Windows Embedded Standard 8 toolkit.

A Module is a Module is a Module

The Windows Embedded Standard 8 toolkit treats modules the same regardless of whether they are Microsoft Windows modules, third-party modules or modules that you create. I describe some of the different types of modules below.

clip_image002

Modules in the Windows Embedded Standard 8 Catalog

To help find the functionality that you wish to include in your device, modules are separated into a number of categories in the catalog.

Although not always identified as such, the catalog contains various types of modules:

  • OS modules
  • Driver modules
  • Language Pack modules
  • Scenario modules
  • Application support modules

OS Modules

OS Modules are provided as part of the catalog and form the parts of the Windows 8 OS from which you can build a functional image. For example these include the Embedded Core, Windows Shell, Internet Explorer, Wireless Networking etc.

We’ll cover some of the OS feature modules in more detail in future blog posts. Do let us know if there are specific modules you’d like to understand and hear more about. The catalog continues to evolve and feedback is gratefully received.

Embedded Specific Modules

The Lockdown and Branding categories in the catalog contain embedded-specific modules that are not part of Windows 8 but supply functionality that is specific to Windows Embedded. The Lockdown category supplies filters, such as the Unified Write Filter and the Keyboard filter, to help you lock down a device. The Branding category contains modules to help you create a customized experience.

Another example of an embedded-specific module is the Kinect for Windows Compatibility module in the Natural User Interface category that makes it easy to include support for Kinect as part of your image.

Scenario Modules

Scenario modules are intended to provide all that is needed to support a specific scenario or software application. It is a module that groups together a set of modules to meet a particular requirement, such as a networking configuration or a set of management functionality that is often used together.

You can use Module Designer to create scenario modules and then share them. If there are particular scenarios you’d like to see support for, please let us know. If you create your own modules that you believe might be generally useful then we’d really like to hear about it.

Application Support Modules

Similar to scenario modules are application support modules. You can use Module Designer to create these modules, pulling together all the needed support for an application that you might use on your device. In Standard 7 we provided Application Templates which helped ensure that the necessary support for an application was included in the developed image. In Windows Embedded Standard 8 this role moves to Application Support modules. For example, a module could be provided to support Silverlight.

We would really like to hear from you if there are particular application support modules that you’d like to have.

Templates

In addition to modules, Windows Embedded Standard 8 also provides templates, which are answer files available in Image Builder Wizard (IBW) that are used for starter projects. The main starter project template available in the CTP2 release is the Thin Client Template that provides functionality for a thin client, and includes Windows Shell, Remote Desktop and Internet Explorer functionality. The starter projects in IBW are intended to help you to quickly get to a functional image for a particular class of device so that you can then add or remove the specific functionality that you need.

Templates are saved answer files of a configuration and as such are different from modules. Templates define one or more building blocks and can contain additional metadata on what dependencies they have, default settings, etc.

Once again feedback on what you’d like to see for starter projects is welcome so we can focus on the most important work moving forward.

Who Depends on You?

We often use the term dependencies when describing the building blocks of the OS. A dependency is when one part of the OS requires that another part is present for it to function. An example is the Internet Explorer module which relies on the HTML Display Engine module to provide some of the functionality. Dependencies are expressed in the definition of the module so when you add Internet Explorer to your image and then resolve dependencies, the system also adds the HTML Display Engine to the image.

Too many Options

In Windows Embedded Standard 7 we introduced the concept of optional dependencies to express functionality that was not essential or required for the main functionality of the selected package, but that might add to the overall functionality in some way. This seemed like a helpful approach at the time that would allow people to decide what packages they should and should not include in their image.

However we found that in practice, it was not as successful as we hoped. In a survey, only half (129 out of 243) of the respondents indicated that they used optional dependencies when building their image. Customers who used optional dependencies clearly struggled with deciding whether to include an optional dependency, and many included all optional dependencies to their image. Examples of feedback received include “Usually it adds too many unwanted components like speech recognition” and “Not helpful because of too much added overhead features which are not (directly) traceable”.

Scenario Focused Approach

In Windows Embedded Standard 8 we decided to change our approach and we no longer have optional dependencies. Instead, we are focusing on scenario modules to group modules together that will meet a particular scenario. In this way, you can create a module that meets a particular need and provides all the necessary functionality to the image. This allows not only Microsoft to provide a set of modules but third parties such as yourselves can create and publish your own sets of functionality to meet needs. As new business opportunities and technologies for devices present themselves, someone can create a new set of modules that meets those needs and make it easy to include the functionality in your dedicated device.

Summary

The Catalog in the Windows Embedded Standard 8 CTP2 release is continuing to evolve and we’d welcome feedback on what is difficult to find and what modules you’d like to see. The flexible nature of modules means that you can create modules for your own specific purposes and add them to the catalog alongside the OS modules. We strive to continue to improve the catalog to help meet your needs.

So based on what you’ve ready today, what are your thoughts? What kind of scenario modules should we provide? What templates have you found useful in the past? What common configurations did you need to save or re-make often? We’d love to hear about these so that we can take your feedback into account as we continue product development.