Creating Custom Components for Windows XP Embedded

Article
10/31/2006

Mike Hall
Microsoft Corporation

July 2002

Applies to:
Microsoft® Windows® XP Embedded

Summary: Learn the steps and tools required to build a custom component for Windows XP Embedded and determine what should be included in your custom operating system image to allow a custom application or service to run. (16 printed pages)

Introduction
Installation Options
The Detective's Toolbag
Putting It Together
Conclusion
For More Information

Introduction

There are a number of ways to create custom components for Microsoft® Windows® XP Embedded. For example, import device driver .inf files can be directly imported into the Component Designer tool (a huge step forward compared to Microsoft Windows NT® Embedded 4.0). A component can be created by importing Devices.pmq, the output of Target Analyzer Probe (TAP) or Target Analyzer (TA)—so far, so good—but what about creating a component which describes a custom application?

For the purposes of this document I decided to build a security device which uses the TimerShot Windows XP PowerToy—this is a cool application which captures an image from a connected imaging device and stores the image in a pre-set location, either locally on my hard drive, or on a network share (a link to the Windows XP PowerToys can be found at the end of this paper). TimerShot can be configured to snap an image every few seconds or every few minutes; all of this is configured within the application and stored in the Windows XP registry. I will include a second application called "PhotoDisplay," that I've written for the purposes of this paper. PhotoDisplay can be used to view the stored JPEG files.

Unfortunately, there are not any tools that can automate the process of building a Windows XP Embedded component for applications—there is some detective work that needs to take place. So, I'll break out the deerstalker and call upon my friend, Dr. Watson (pun intended) and get started.

Installation Options

When building a Windows XP Embedded device, a number of options for adding third-party applications/technologies are available. The options mostly depend on the hardware configuration of the device and the method used to manufacture the shipping devices.

The most flexibility comes when building a device that boots from R/W media (typically a hard drive) and contains a CD-ROM/DVD-ROM drive, display, keyboard, and mouse. In this configuration a third-party installation program could be run directly on the Embedded Target, which would copy and configure the application directly on the target device. This is useful if when building a one-off device or if you want to test the application on Windows XP Embedded to ensure all required operating system components are present (discussed below).

Another option is to build the Windows XP Embedded image (typically to the \Windows Embedded Images folder) and then manually add the required applications/resources to the build folder. The Windows XP Embedded operating system image (and the application/resources) can then be copied to the bootable media and the application can then be tested. This only works with simple applications that don't require the registration of COM objects or the installation of underlying operating system services.

The best approach is to create a component, which is then available within Target Designer and can be selected just like any other Windows XP Embedded component. This is ideal if you have installed the Windows XP Embedded tools in a multi-user scenario. However, this requires some work. Let's examine how applications are installed and the portions of the operating system that are typically modified.

Installation programs come in all shapes and sizes, from a simple xcopy, IExpress, through GUI installers that require registration information from the user and may ship on multiple CDs/DVDs—installation programs may install database engines or operating system services, device drivers or support DLLs, and can make changes to the operating systems registry or INI files—in some cases the installed files may be installed to multiple folders on your PC, Program Files for the core application, "\Windows\System32" for device drivers, or other installer dependent folders—determining what should be included into your Windows XP Embedded component would at first appear to be a non-trivial job. Thankfully, there are some tools and techniques that can assist you.

The next section provides a high-level overview of the tools needed to determine which files/registry settings and operating system components should be included in your Windows XP Embedded component.

The Detective's Toolbag

This section provides an overview of the tools needed to build a custom Windows XP Embedded component.

There are two sets of tools needed to build and test the component. Some of these tools will live on the development PC, while others will be included on the target device to debug the application or component. Let's break the tools down into these two categories and then take a look at how each tool is used.

Tools Used on the Development PC

The behavior of the application's installation program cannot be changed, but the operating system can be monitored to figure out what changed as a result of installing an application. There are a number of tools available that can assist with this process. Since some installation programs require a reboot during the installation process, ideally a tool should be used that can monitor changes in the PC's file system and registry across reboots. Applications such as Inctrl5 (ZDNet), SysDiff (Microsoft), and others 'snapshot' the file system and registry before installing an application, then snapshot the file system and registry after the installation and provide a report of the differences—this can assist with determining which files should be included in the component. Note that applications and services already running when the application installed may also make changes to the file system and registry.

Here's the list of tools I've used on my development PC to determine which files/registry entries should be included in my custom component—I will explain the use of each tool through each step of the process later in this paper.

InCtrl5—used to snapshot the file system and registry and provide a list of differences (ZDNet)
Dumpbin—used to determine which DLLs are used by an application/DLL (Microsoft Visual Studio® .NET)
Depends—can also be used to determine which DLLs (and APIs) are used by an application
RegMon—dynamically monitor changes to the registry (NT System Internals)
FileMon—dynamically monitor the file system (NT System Internals)
Windows XP Embedded development tools—Target Analyzer Probe, Component Designer, Component Database Manager, Target Designer

Tools Used on the Target Device

Using the above tools to determine which files and registry entries are needed is only one piece of the puzzle. Once the Windows XP Embedded image has been built, the application will also need to be tested to ensure it behaves as expected—it's possible the application may be dynamically loading DLLs or creating instances of COM objects, but this can't be caught using Dumpbin or Depends. Therefore some debug tools on the target device are needed. Here's the list of tools I've used on my target device (these should be removed before deploying the final operating system image):

RegMon—dynamically monitor changes to the registry (NT System Internals)
FileMon—dynamically monitor the file system (NT System Internals)

I walk through how these tools are used in the next section.

Putting It Together

Overview of the process

First, let's recap the security device and list out the components available. The plan is to build a security device based on Windows XP Embedded. In this case I'm using a Toshiba Tecra 9000 laptop as my development PC and I'm using a Logitech USB Camera and the Windows XP Embedded TimerShot PowerToy (check the link at the end of this document for a download location for this component) as my target device and my detective's toolbag referred to earlier.

The Toshiba laptop has two hard-disc partitions. The main partition contains Windows XP Professional and all of my development tools (Windows XP Embedded, Visual Studio .NET and so forth), and is formatted as NTFS. I also have a secondary partition of 700MB (spookily about the same size as a CD-Rom), which is formatted as FAT32. I've modified my BOOT.INI (which resides in the root of my bootable drive to add a second boot option for Windows XP Embedded—note that Boot.ini is configured to have System and Hidden attributes)—here's how my Boot.ini looks.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
  Professional" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
  Embedded" /fastdetect

At boot time, I'm offered two options: either to boot into Windows XP Professional (on my primary partition), or to boot into my Windows XP Embedded image (on my secondary partition). The default option, after a 30 second timeout is to boot to Windows XP Professional.

Step 1—Capturing Information from the Setup Program

The first step in creating the custom component is to determine the files and registry settings needed for the application. The setup program and the detective tools should be run on Windows XP Professional. The application can be ran and tested against a fully configured operating system image—the application will be tested against Windows XP Embedded later in the paper.

The Windows XP PowerToys Web site lists a number of PowerToys; clicking the link to download a PowerToy will prompt you to select Open, Save, Cancel, or More Info. Click "Save" to save the TimershotPowertoySetup.exe program to your hard drive. Note that selecting "Open" will download and install the PowerToy. The information from the install process doesn't need to be captured at this time.

A file system and registry snapshot tool will also be needed. For the purposes of this paper I've chosen to use Inctrl5 from ZDNet, although there are many similar tools available.

Here's how Inctrl5 looks: the location of the setup/installer program is plugged in (which in my case is c:\stuff\XP-PowerToys\TimershotPowertoySetup.exe), the Report output location is changed to point to my install folder, and then I click GO!.

Figure 1.

InCtrl5 captures a snapshot of my development PC's registry and file system and then launches the PowerToy setup program. Once the installation process is complete, a second snapshot is taken and a report is generated.

The compiled report will list all changes to the filesystem, registry, INI files and text files (autoexec.nt, and config.nt)—in the case of installing the PowerToy, the report includes changes made to the file system and registry by other applications that were running at the time of installing the PowerToy. The report also includes registry keys and files that are used to uninstall the PowerToy. Since I'm building an embedded device and don't want users removing this application, I can ignore the uninstall information.

Let's review some of the changes to my system as a result of installing the PowerToy.

Registry

Seventeen keys were added, including:

HKEY_CLASSES_ROOT\Installer\Products\CCBB347A83433BB43879C6D9A91C526A

This will obviously be used by the un-installer for the PowerToy, and can be ignored. There were also a number of additional sub-keys added; again, these can be ignored.

One hundred and thirty-eight values were added to the registry, including:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
  RecentDocs\.bmp

I'm writing and saving this paper during the install of the PowerToy, and a number of registry values were changed by me continuing with my work.

HKEY_CLASSES_ROOT\Installer\Products\CCBB347A83433BB43879C6D9A91C526A

A number of values have been added to the registry which are used by the uninstall process—these can be ignored since I don't want users removing the application.

Curiously, there aren't any TimerShot registry entries listed. It is therefore assumed that the TimerShot PowerToy checks for the existence of optional registry keys at runtime and uses default options if none of the registry settings exist.

Files

And now, onto the files. Here's a listing of the files that changed during the installation of the TimerShot PowerToy (taken from the Inctrl5 report)—you can see that most files are used by the install/uninstall process. The one interesting line is timershot.exe; this has been installed to the \Windows\System32 folder.

c:\Documents and Settings\All Users\Start Menu\Programs\Powertoys for 
  Windows XP\Timershot.lnk 
Date: 4/29/2002 4:53 AM 
Size: 1,641 bytes 
c:\WINDOWS\Downloaded Installations\Timershot Powertoy for Windows XP.msi 
Date: 4/29/2002 4:53 AM 
Size: 411,684 bytes 
c:\WINDOWS\Installer\2a1e66.msi 
Date: 4/29/2002 4:53 AM 
Size: 349,696 bytes 
c:\WINDOWS\Installer\{A743BBCC-3438-4BB3-8397-
  6C9D9AC125A6}\ARPPRODUCTICON.exe 
Date: 4/29/2002 4:53 AM 
Size: 22,486 bytes 
c:\WINDOWS\Installer\{A743BBCC-3438-4BB3-8397-6C9D9AC125A6}\Readme_1.htm 
Date: 4/29/2002 4:53 AM 
Size: 318 bytes 
c:\WINDOWS\Installer\{A743BBCC-3438-4BB3-8397-
  6C9D9AC125A6}\Timershot_1.exe 
Date: 4/29/2002 4:53 AM 
Size: 22,486 bytes 
c:\WINDOWS\system32\timershot.exe 
Date: 3/19/2002 5:30 PM 
Size: 192,000 bytes 
d:\System Volume Information\_restore{1FE94AF8-3502-4A8F-8658-
  25737CDB40DE}\RP46\change.log.1 
Date: 4/29/2002 4:53 AM 
Size: 496 bytes 
d:\System Volume Information\_restore{1FE94AF8-3502-4A8F-8658-
  25737CDB40DE}\RP46\RestorePointSize 
Date: 4/29/2002 4:53 AM 
Size: 8 bytes

Note At this point I have the file listing for the application. This could, of course, include a number of executables and DLLs.

Step 2—Registry Settings

I know that the TimerShot application has a number of user-configurable options, including the timer interval between taking pictures, the location of the output files and the size of the output image. What I don't know at this time is the location of the options within the registry (I'm assuming that the application stores its configuration information in the registry, the application could just as easily store the configuration information in an INI file, using WritePrivateProfileString).

Here's how the TimerShot application looks, including some of the user configurable options (note that I've cut off some of the options to reduce the size of the bitmap in the document).

Figure 2.

I could guess at the name of the registry keys used by the TimerShot PowerToy, perhaps TimerShot, or PowerToy, and I could use RegEdit to search for the registry keys. However, it is possible that a number of keys could change within the registry, including some of the registry keys associated with the Logitech Camera. So, I have some options at this point:

I could run the snapshot software, install and run the TimerShot PowerToy, make changes to PowerToy options and then allow my snapshot software to list the differences.
I can also make changes to the registry and monitor the changes at runtime. This is where the SysInternals RegMon utility can be used. RegMon intercepts read and write requests to the registry and lists these in its report window.

I can determine the registry keys used by the program at runtime by running the RegMon utility, then running the application, TimerShot; I then make changes to the application's options and use RegMon to monitor the changed registry keys. Here's RegMon in action. I've changed the TimerShot timer interval from 10 minutes (the default), to every 5 seconds. Notice the following registry keys have been changed.

HKEY_CURRENT_USER\Software\Microsoft\Powertoys for XP\TimerShot

Figure 3.

Note At this point I have the file listing and the registry entries needed for the application.

Step 3—Application Dependencies

The name and location of the application binaries (EXE/DLL) and the registry entries used for the application are now known. What isn't known at this point is the core operating system files used by this application. This is where dumpbin (a command line tool that ships with Visual Studio .NET) or Depends (Web-downloadable tool—see the links at the end of this document for more information) comes in handy.

Below, you see depends.exe in action. You can clearly see the list of required DLLs in the top left pane of the application. The list includes KERNEL32.DLL, GDI32.DLL, USER32.DLL (no surprises so far), MSVCRT.DLL and SHLWAPI.DLL, which has a number of dependencies including OLE32.DLL, APPHELP.DLL, MLANG.DLL.

Figure 4.

These files need to be available to the application, so the build output folder should be checked (usually \Windows Embedded Images) to ensure the files are part of the Windows XP Embedded operating system image.

What happens if you don't find the files in the build output folder? How do you determine which component(s) need to be added to your operating system image?

The answers to these questions are fairly straightforward. The Target Designer Filter Manager (Tools | Filter Manager) can be used to locate the component(s), which contain the necessary files—I'll take OLE32.DLL as an example. I created a filter that looks for all components containing the file, OLE32.DLL. When I apply the filter, the search comes back with zero hits, but this cannot be right since I know that OLE32.DLL ships with Windows XP Embedded. This is where visibility comes in. Within Target Designer, select Tools | Options | Advanced—you will notice that the default view will display components with a visibility of 1000 or greater; the chances are that OLE has a low visibility. Change the visibility to 100, and re-apply the filter (the OLE32 component has a visibility of 200). Now, notice two components listed—MCI Support and Primitive: Ole32. If required, this component can be added to the project workspace.

What is a primitive? A primitive is a component that contains only a single binary file resource. All other components may (and usually do) contain additional binaries and resources you may not require in your runtime image, and they may cause your operating system footprint to increase in size.

Figure 5.

Note At this point I have a list of the files, registry entries, and required DLLs—the next step is to build the component.

Step 4—Building the Component

Building the component is no different to building any other component. I have the list of required files, I know which registry entries need to be added and I have the component dependencies (based on the list of dependent files from dumpbin/depends). For more information on component design and development, take a look at the Windows XP Embedded online documentation or the MSDN online documentation.

There are some issues to consider for the custom component. There may be, for example, some COM objects or Microsoft ActiveX® controls that need to be registered before the 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. If the functions DllRegisterServer, DllUnRegisterServer, and DllCanUnloadNow are exposed then you have a COM object or ActiveX control.) The First Boot Agent (FBA) can be used to register the COM objects. This is enabled through component resources. Take a look at the Component Designer screen shot below and you can see a number of custom resources that can be enabled, including FBA COM/DLL Registration, creation of a shortcut, and so forth. The Windows XP Embedded documentation provides an overview of how the FBA commands can be used—take a look in the System Design Guide for Windows XP Embedded topic—Appendix Info—Custom Resources.

Figure 6.

You may be wondering what First Boot Agent does. After a Windows XP Embedded image is created and deployed to the device, the first time the device is turned on institutes a first boot. At this time the First Boot Agent (FBA) can perform the following system configuration tasks:

Tasks that cannot be performed offline using Target Designer, such as device detection and configuration using Plug and Play
Tasks that are more practical to perform at run time, such as registering a Component Object Model (COM) server

Step 5—Building the Windows XP Embedded Operating System Image

Building the Windows XP Embedded image is straightforward. I've been through the process of creating a component based on the output of Target Analyzer Probe (TAP), including the drivers for the Logitech Camera. However, there is a small list of components I need to add to my project. These components include:

Tecra9000-Including Logitech WebCam (the component created from the output of TAP).
TimerShot (the component just created in Component Designer).
One of the Design Templates (I chose Information Appliance).
The FAT component, which can be found under Software | System | Storage and File Systems | Infrastructure | File Systems.
The FAT Format component, which can be found under Software | System | Storage and File Systems | Applications.
The Explorer Shell component, which can be found under Software | System | User Interface | Shells.
You must include an OS Loader. Select the Windows NT Loader component, which can be found under Software | System | System Services | Base.
The English Language component, which can be found under Software | System | International | Infrastructure | English Language Support.
I also added the Windows Image Acquisition User Interface component, which can be found under Software | System | Printing & Imaging | Applications. I wanted to test out the Logitech Camera on the Windows XP Embedded image using the Control Panel Scanners & Cameras applet, which is enabled through the Windows Image Acquisition User Interface Component. Adding this component provides the ability to test the camera without running the TimerShot application; once I know the camera is working correctly I can then move on to running the application. The camera could be tested, if required, and then this control panel applet could be removed and the operating system image could be rebuilt.
I also need to make a change to User Interface Core | Settings within the project workspace to enable Control Panel on the Start menu.

Figure 7.

Note At this point I can build the operating system image (refer to the Target Designer online help for more information on configuring and building your Windows XP Embedded operating system image).

Testing the Application within Windows XP Embedded

The application needs to be tested to make sure that everything is working as expected. Some tools should be included in the Windows XP Embedded image to aid the test/debug phase of deploying the customized application.

The TimerShot application runs just fine on Windows XP Embedded. Here's how it looks when running:

Figure 8.

The first step in testing the application is simply running the application on Windows XP Embedded and seeing what works (and more importantly, what doesn't work). If everything works then testing is finished. The chances are, however, that one or more required resources could be missing. These could be COM objects that have not been registered, regular DLLs, secondary applications (EXEs) and resource files (data files, bitmaps, .wav files, and so on ), or missing registry entries. How do you determine what's missing? This is where the SysInternals tools FileMon and Regmon can be used. You have a couple of options at this point; you could either create a toolbox component for Target Designer which would include the RegMon and FileMon applications (preferred), or build your o/s image (typically to the \Windows Embedded Images folder) and drop the FileMon/Regmon files into your build folder. The applications will then be available when you copy your Windows XP Embedded operating system image to bootable media and boot the o/s.

You've already seen how RegMon can be used to track changes to the registry as I configured the options of the TimerShot application before building the TimerShot Component. I can use RegMon on the Windows XP Embedded device to track read/write operations to the registry—this can assist with determining which additional registry keys will be needed to run the application. You could, for example, start RegMon on the target, then start the TimerShot application and view the keys that are being read from the registry at startup. RegMon will report NOTFOUND for any keys that do not exist in the devices registry.

The FileMon tool can be used to track missing files and DLLs—I've added two applications to my Windows XP Embedded device: TimerShot (which captures JPEG images from the Logitech Camera) and "PhotoDisplay", as well as MFC application, which has been written in Visual Studio .NET and has an external support DLL which is used to display the JPEG files in the applications client area. When I ran the PhotoDisplay application I received the following cryptic message:

Figure 9.

I know that the application won't function because a required DLL is missing. I can't determine which DLL is missing, but I can run Depends or Dumpbin to list the statically linked DLLs (and all of these appear to be included in my Windows XP Embedded image). I don't know which DLLs (or COM objects) are being dynamically loaded, but I can use RegMon to track the files being loaded by the PhotoDisplay application. Below is a snapshot of FileMon running on my Windows XP Embedded target device. Note that I've highlighted the section that shows the PhotoDisplay application attempting to load DispImage.DLL. This DLL was not included in the Windows XP Embedded image and therefore cannot be loaded by the application. To fix the application, I simply need to add the DispImage.DLL file to my Windows XP Embedded image (by updating my PhotoDisplay component).

Figure 10.

Note At this point I've created a component for the TimerShot application, including all of the files and registry entries needed to run the TimerShot application on the Windows XP Embedded device.

Conclusion

Building a Windows XP Embedded component for applications requires some work and a number of tools. In this paper I've highlighted the general steps needed to build a component for a Windows XP Professional PowerToy TimerShot; the principles and tools used to build this component would be exactly the same for building a component for a larger application.

For More Information

For the latest information on Windows XP Embedded, visit 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.

More information about building components using Component Designer is available in the product documentation and in the "Get Embedded" columns on this Microsoft Web site.

To access the online documentation for Windows XP Embedded

Start Target Designer.
Select the Contents tab on the Help menu to view the documentation.

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

Utilities used in this paper

NtRegMon and NtFileMon tools can be found on the SysInternals Web site.

InCtrl5 can be downloaded from the ZDNet Web site.

DependencyWalker can be downloaded from the Dependency Walker Web site.

Download Windows XP Embedded TimerShot PowerToy from the Microsoft PowerToys for Windows XP Web site.