Creating a Windows XP Embedded Shell

Mike Hall
Microsoft Corporation

August 2002

Applies to:
    Microsoft® Windows® XP Embedded
    Component Designer
    Target Designer

Summary: Learn how to build a Windows XP Embedded Shell Component. A custom shell component can be selected in the same manner as the standard Explorer Shell. A custom shell can be used to create a fixed function device. (6 printed pages)

Contents

Introduction
Creating the Shell Component Using Component Designer
Booting the Embedded Device Without the Splash Screen
Conclusion
For More Information

Introduction

Microsoft® Windows® XP Embedded provides the ability to build a customized operating system image which contains the components and technologies that are appropriate for your specific device. The image may contain customized device drivers and applications, and in some cases, it would also be appropriate to boot the Windows XP Embedded device directly into a customized application, or shell. This could prevent users from switching applications, accessing the control panel, or underlying filing system of the device. A retail point of sale (RPOS) device could simply boot directly into the RPOS application.

Windows XP Embedded provides a number of standard "Shells". These include the Command Shell, Explorer Shell, and Task Manager Shell. Each of these shells is available as components within Target Designer, and can be found under Software | System | User Interface | Shells.

There are a number of steps involved in creating a custom shell component. Typically, the component will contain the executable, any required support Dynamic Link Libraries (DLLs), registry entries, and resources and may also have dependencies on additional components within Windows XP Embedded. In most cases, the custom shell component will be a custom application, which perhaps ships with its own installer program. In this case, you must determine which files and registry entries are needed for the application to run correctly. This process should be handled before creating the shell component, using the Explorer Shell, and creating a stand-alone component for your application. You can then use tools such as Regmon, and Filemon (available from https://www.sysinternals.com) to assist in debugging the application component. There is a Windows XP Embedded article that can assist with the development of custom components—Creating Custom Components for Windows XP Embedded.

After determining the files and registry components needed for the custom shell, the process of creating the Shell Component is fairly straightforward. For this paper, a Retail Point of Sale application for the fictitious Northwind Traders company will be used as the example custom shell application. The application has been created by using Microsoft Visual Studio .NET, and communicates with a back-end server using Message Queuing (MSMQ). In this paper, the focus will be on creating the shell component.

Creating the Shell Component Using Component Designer

Building the custom shell component is no different than building any other component. You have the list of required files, you know which registry entries need to be added and you have your component dependencies that have been determined either because you created the application (which is the case for the Northwind RPOS application) or because they're based on a list of dependent files that have been determined from running applications such as dumpbin or depends. For more information about component design and development, refer to the Windows XP Embedded online documentation, or the product documentation in the MSDN Library.

There are some issues that you must consider for your component. You may, for example, have some Component Object Model (COM) objects or Microsoft ActiveX® controls that need to be registered before your core application can use them (you can use the Dumpbin /EXPORTS command to examine the exports of a DLL to determine whether this is a COM/ActiveX component [dumpbin is a tool that ships with Microsoft Visual Studio®]. If the functions DllRegisterServer, DllUnRegisterServer, and DllCanUnloadNow are exposed, then you have a COM object or ActiveX control). You can use the First Boot Agent (FBA) to register our COM objects, which is enabled through component resources. The Windows XP Embedded documentation provides an overview of how the FBA commands can be used. Review the System Design Guide for Windows XP Embedded topic—Appendix Info—Custom Resources.

The RPOS application you that you will use for this paper has three dependent files, RPOS.exe (the RPOS application), MFC70.dll and MFCR70.dll (Visual Studio dependencies).

When building components, it can be useful to place all of the files and your component file (SLD) into the same folder. In this case, a folder called C:\RPOS has been created, which will contain the files listed previously and your component definition file, RPOS.SLD. Go through the process and create the Shell Component.

First, you must run Component Designer. On the File menu, click New. This creates a new component workspace. The workspace by default will be called "New Document 1.sld". During the component creation process, you will need to add a repository and a component to your SLD.

Expand the component so you can see the New Document 1.sld, Windows XP Embedded Client (x86) and the subfolders : Components, Repositories, Dependencies, Packages, and Repository Sets. The SLD is currently empty. We will need to create a new Component. Select the Components folder and either right-click and select Add Component, or use the Add | Component menu. A new component will have been added to the workspace, called New Component 2—you will notice a number of subitems have been created, these include Group Memberships, Files, Registry Data, Component or Group Dependency, Build Order Dependency, and Resources. A typical component may make use of the Files folder (to point at the files needed by this component), the registry folder (to contain the registry items needed by this folder), and dependencies on other operating system features (such as networking, Message Queuing (MSMQ), and hardware such as a modem).

Select the New Component 2 item, using the Component Properties you can change the name of your component to match the name of the executable, or the function that your application will carry out, perhaps RPOS Shell would be appropriate in this case.

There are a number of properties that can be set for this component, which include the location of component Help, the repository used for this component, and a component prototype. Windows XP Embedded ships with a number of component prototypes, including the Shell Prototype Component, Keyboard layout prototype, MUI prototype, Font prototype and the Selector Prototype. You may have already created a component based on the output of Target Analyzer Probe (TAP), or Target Analyzer (TA), which in effect, is a macro component that wraps up the functionality of the hardware for your device. You may be interested in removing some of the functionality that TAP/TA has found, which can be enabled by using the Selector Prototype (Software | Test and Development | Selector Prototype Component).

In this case, you want to base the component on the Shell Prototype Component. On the Component Properties page, select Prototype and then browse to Software | System | User Interface | Shells | Windows Shell. Select the Shell Prototype Component and Click OK.

You also must set an extended property for this component. Click the Advanced button on the Component Properties page. This will display the Advanced Properties dialog box. To add an Extended Property, click the Add button to display the Extended Property dialog box. Extended properties are typically used to hold optional parameters or configuration information for a component, or to conditionally enable a feature. For example, a network component might use an extended property to hold a Transmission Control Protocol/Internet Protocol (TCP/IP) address. An extended property has a name, a data format and a data value. The data type is determined by the format.

The Extended Property dialog box contains three fields: Name, Format and Value. The Format item can be set to a number of different types, including String, Int, Raw Binary and so forth. In your case, you will use the default value of String. The Name field should be set to cmiShellPath and the value field should point to the location of the executable for your shell, in this case %SystemRoot%\System32\RPOS.exe. Click OK to close the Extended Property and Advanced Property dialog boxes. Note that the files RPOS.exe, MFC70.dll and MFCR70.dll by default will be included into the final operating system image at their default folder location, which in this case would be C:\RPOS. You can check and modify the destination folder location for each file in Component Designer—the default folder location for your files would be %24%\RPOS (%24% resolves to C:\. Therefore, the effective path would resolve to C:\RPOS). You must change the path for your files to %11%, which resolves to \Windows\System32. There is no need to remember the %#% values, because the folder locations are listed out for you in Component Designer.

There are two final steps to configuring our component as a shell component. First, add your shell component to the "shell" dependency group. This is achieved by selecting the Group Memberships item for this component (either right-click, and select Add Group Membership, or select the Group Memberships item, and use the Add menu to add Group Membership). This will display an Add Component Group Memberships dialog box—browse to Dependencies and select Shell, then click OK to close the Group Memberships dialog box.

The final step to configuring our shell component is to add our shell to the Shell Dependency Group. Select the Group Memberships item for this component (either right-click, and select Add Group Membership, or select the Group Memberships item, and use the Add menu to add Group Membership). This will display an Add Component Group Memberships dialog box—browse to Categories | Software | System | User Interface | Shells, then click OK to close the Group Memberships dialog box.

For your component to be complete, you will of course need to add the files to the component and create and select the appropriate Repository.

At this point, the custom shell component is complete. In order to use the component, you must import it to the component database using Component Database Manager. After it is imported, the component can be selected like any other shell component (Task Manager, Command Shell or Explorer Shell). The following image shows the RPOS Shell component exposed in the Shells folder within Target Designer.

Figure 1.

If you build an operating system image based on one of the design templates (such as Advanced Set Top Box) and do not include a shell component, the dependency analysis will create a task that requires you to resolve a shell for the device. The following image shows the resolve dependency dialog box for an advanced set top box-based configuration that did not contain a shell component. You can clearly see the RPOS Shell component in the list of available shells.

Figure 2.

Booting the Embedded Device Without the Splash Screen

Because you are building a device that has a customized shell, you may also be interested in adding a final piece to the boot image of your device. By default, a Windows XP Embedded device boots showing the Windows XP Embedded splash screen. You can remove this screen by modifying the configuration properties in Target Designer before the runtime is built. In Target Designer, select the Settings item under your configuration. In the Details pane, find Other Settings, and click Show under it. Select the Do not display GUI boot screens check box and build your configuration.

This setting changes the ARC path for your runtime in the BOOT.INI to include the /noguiboot switch. Your ARC path would look something like this:

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Windows XP Embedded" 
  /fastdetect /noguiboot

You can also hand edit the BOOT.INI to add this switch.

Conclusion

Creating a custom Windows XP Embedded shell component is quick and easy. The process starts with creating your custom shell application and getting it working as a component within Component Designer and Target Designer. Converting this component into a custom shell component requires some minor alterations to the component definition file (SLD). This can be an extremely powerful and flexible solution for creating stand-alone, fixed-function devices such as Retail Point of Sale and ATM devices (custom shells can also be used in a wide range of other devices).

For More Information

The latest information about Windows XP Embedded is available at this Microsoft Web site.

The online documentation and context-sensitive Help included with Windows XP Embedded also provide comprehensive background information and instructions for using Windows XP Embedded.

To access the online documentation for Windows XP Embedded

1. Start Target Designer.
2. To view the documentation, click the Contents tab on the Help menu.

You can also access the Windows XP Embedded product documentation on MSDN.

© Microsoft Corporation. All rights reserved.