The New Addition: Windows XP Embedded with Service Pack 1


Jon Fincher
Microsoft Corporation

December 19, 2002

Summary: Jon Fincher introduces the new Microsoft Windows XP Embedded with Service Pack 1, and describes key changes in the tools and components. (5 printed pages)

Well, it's been a while. As with my other absences and missed issues, there's no interesting story to explain why, other than I've been busier than a one-toothed man in a corn-on-the-cob eating contest. I actually started writing this column during the Embedded DevCon in Las Vegas in October. I just never got around to finishing it. So, here, without further adieu (or is that ado? Whatever...), is the long-awaited introduction to Microsoft® Windows® XP Embedded with Service Pack 1.

What Is It?

Windows XP Embedded with Service Pack 1 is more than just updating components with Windows XP Service Pack 1 binaries (although that's a big part of it). We also added some features to the tools and some components for embedded enabling features.


The first (and most visible change) is that we're now shipping on two CDs. (Just 24 more to catch up to Windows CE!) We needed two CDs to hold everything. Not only are we shipping new components and binaries, but we're also shipping old components from last year as well. Those old components need to have the old binaries available for them to work properly. Why ship both? Simple: backwards compatibility. If you have an SLX that works with the original Windows XP Embedded, we want to make sure it continues to work when you install Windows XP Embedded with Service Pack 1. This way, you can use the new stuff when you need it, but still be able to build original configurations.

However, there is a catch here. There's no way to reliably mix Windows XP Embedded components with Windows XP Embedded with Service Pack 1 components. This requirement actually comes from the desktop world. Imagine a Windows XP Professional desktop system with part original and part SP1 binaries. There's no way to reliably predict its behavior, and certainly no way to reliably test such a system in polynomial time. So either you have SP1 installed or not. There's no partial install, no some of this and some of the other.

This has two important ramifications for embedded configurations. The first is that you cannot create original configurations using the new tools and database. You can use existing configurations, but not create them. The second caveat here is that whenever you add a component from Windows XP Embedded with Service Pack 1 to a configuration, you have to upgrade the entire configuration to the Service Pack 1 level. This is enforced in the Target Designer: Once an SP1-level component is added to a configuration, the original components are disabled until they're upgraded. And no, we're not going to change that or help you work around that.


The second most visible new feature is in Target Designer; it's called Size Estimation. It works like this: Whenever a configuration is initialized, or a component added, its estimated size is calculated. That estimated size is displayed in the status bar for both compressed and uncompressed runtimes. These two numbers are just estimates, so your mileage may vary. The numbers come from the components themselves. They can either be described in the component, or discovered dynamically from the repository files referred to by the component. This means your components will automatically benefit; Target Designer will find the size of the files in the repository and report them back for configuration size estimation.

There is also a size-estimation feature added to Component Browser in Target Designer, which gives you an idea of what adding a component to your configuration will do to the footprint. To use it, open a configuration, and then find the component you want to add. Right-click the component in Component Browser, and select Estimate Size from the context menu. This feature follows the dependency chain of the selected component, taking into account dependent components that are already in the configuration, and outputs an estimate of the size of the runtime were that component added and a full dependency check done. Because we're adding a component and doing a full dependency check, this process takes a little while to do, but the results are worth it.

One other small change in the way Target Designer works: All help files are now not copied by default. To copy help files, go to the configuration Settings, click Other Settings, and clear the check box labeled "Do no copy help files for this configuration."

Embedded Enabling Features

We've also added some new embedded enabling features (EEFs) to the database for SP1-level configurations, and modified a few of them to include new features.

SDI (No, Not Reagan's Star Wars Thing)

The first and most useful to me is the System Deployment Image format, or SDI, which implements a file-backed virtual disk drive. It's basically a file (with an .sdi extension) containing the full description of a partition, disk, or file system. You can manipulate the SDI image with the SDI Manager tool. SDI Manager lets your create and edit SDI files, and copy the contents of an SDI file to an existing disk, partition, or file system. You can even boot your runtime from an SDI file using the SDI device driver provided. SDI files handle FAT, FAT32, NTFS, and NTFS compressed partitions with no worries.

WinPE (No, Not the Hamburger Guy from Popeye Cartoons)

On its own, SDI is very useful, but there's more to it than that. This is where the second new feature comes in. The first Windows XP Embedded with Service Pack 1 CD actually boots to the Windows Preinstall Environment (called WinPE). WinPE is basically a full Win32 operating system designed to boot from an El Torito CD. It has the complete Win32 API set, and even does HW enumeration and populates an in-memory registry. It loads standard networking protocol stacks, and presents a command-line shell for device manipulation.

So, you've created an SDI image for your device. Now you can boot your device using WinPE, and run SDI Manager. Because WinPE is network-ready, you can then grab your SDI file from anywhere on your network, and lay the image down onto the media present in the device. Boot the device with that image, let it run through FBA, use FBReseal to clone the system, then use SDI Manager to capture the image as an SDI file again, and bingo!—one golden master image ready for duplication, and no worries about losing long-file names through DOS XCOPY again.

Remote Boot (No, Not That… No Wait, Yes, That's It)

One other thing SDI files are good for is remote booting. The Remote Boot features in Windows XP Embedded with Service Pack 1 are REALLY cool. (At least they are to me.) To use it, you need a server that can handle remote boots through PXE, and that runs the TFTP daemon service (TFTP is Trivial File Transfer Protocol, a different flavor of standard FTP using a different client). Your device also needs to have a PXE-enabled network card. The device boots using PXE, queries the server, and gets an IP. It then initializes a TFTP session to the server and downloads a specific SDI image onto a RAM disk set up on the device, which is then booted as normal.

Remote Boot allows you to service an entire networked bank of embedded devices by changing a single image. (Think of a department store full of RAM-disk enabled cash registers grabbing their image every day from a central server.) It also provides the ultimate in image security. There's no disk to maintain, no disk to go bad, and no worries about power-down situations. And since the image is completely RAM-based, each time the machine is power cycled, it gets a fresh image that has never been run on that device loaded onto it. That's cool.

DUA (Or DUA for Short)

Of course, if you have a bunch of devices with storage on them, you probably want a better way to service them than re-imaging all their media. That's where Device Update Agent (DUA for short) comes in. DUA was originally released with Windows XP Embedded last year as a technology preview. Now it's a complete feature in its own right.

DUA is a lightweight client (30 KB) that runs on the device. It can be set to monitor a specific network share, URL, or local folder, and look at specific times or a range of times. Whatever location it's looking at, it's waiting for a script to appear. You write (using Notepad or some other text editor), compile (using the DUA script compiler, DUSC.EXE), and publish the script at that location. Once the compiled script appears, the DUA client reads it and runs it. The script can specify files to copy, delete, or move, registry keys to write, modify, or delete, and commands to run. You can even script the device to delete the script and reboot when done.

The real strength of DUA is shown with Windows XP Embedded QFEs. Currently (and for the foreseeable future), QFEs for Windows XP Embedded with Service Pack 1 will be distributed as component updates. This means you need to rebuild your runtimes to take advantage of the QFE. However, all QFEs are also published with a complete list of updated files and registry keys that are implemented in the new component. Using that information, you can write DUA scripts to copy the files and create the registry keys on an existing runtime, in effect applying the QFE to an active runtime. Put one script in one location, set up multiple devices polling that location for new scripts, and you've now created a distributed updating mechanism for devices capable of fixing themselves. Add in some T-lymphocytes to write the scripts, and you've got yourself an automated immune system for your embedded device network (T-lymphocytes not included).

FBA (No, the Other One Is with an "I")

We've made some changes to how FBA (First Boot Agent) works as well. If you remember, a while back we issued a QFE for FBA to allow it not to lose domain registration information during its processing. Now we've extended that to include computer name and IP address. There are new extended properties in the FBA component that control this, which are exposed in the settings for the component.

EWF (Like a Female Sheep, but with an "F")

Enhanced Write Filter (EWF) has also been... well... enhanced. We issued a QFE to allow it to work on removable media. This was a specific fix to allow it to work on Compact Flash cards, which connect through the PCMCIA bus and are marked in hardware as removable. That functionality is in the SP1 version of EWF as well. EWF Manager also allows you to commit and reboot from RAM overlays.

Additional Components

Probably the biggest addition to the available components in Windows XP Embedded with Service Pack 1 is the Microsoft® .Net Framework, which allows you to run managed code on your embedded devices. It also allows you to do remote debugging of managed code on the device from a development machine running the Microsoft® Visual Studio® .Net environment.

Since Windows XP Embedded with Service Pack 1 includes the full Windows XP Service Pack 1 set of binaries, every component that owns a file updated to Service Pack 1 has been updated as well. A complete list of these is well beyond my capabilities to present in an interesting fashion. You can tell Service Pack 1 components in two ways:

  1. They all have revision number 1507.
  2. They all contain an extended property called cmiServicePackLevel, which is an integer equal to one (1).

QFE components for Windows XP Embedded with Service Pack 1 will have higher revision numbers and include the cmiServicePackLevel property as well.

Coming Attractions

We're always working hard to add things to our current product while planning for the next version. Some of the things we're working on include:

  • Embedded Test Kit. A collection of Windows Feature Stress Tests and a test harness you can use to test your design configurations.
  • QFE's. We're always working on QFE's. The new QFE packaging will allow automatic importing of QFE components. One thing to note is that we will only be servicing Windows XP Embedded with Service Pack 1 components in the future.
  • Documentation updates. A documentation update for Windows XP Embedded with Service Pack 1 will be available in late April 2003, which will include how-to documentation, error corrections, and incorporate whitepaper content.
  • Whitepapers. Whitepapers will be written to address technical issues, advanced Windows XP Embedded with Service Pack 1 functionality, and other topics.

And as always, if you've got a tool or technique that makes your life easier, we'd love to hear about it. E-mail us or PSS, or post it on our newsgroup at news://microsoft.public.windowsxp.embedded. (I promise I'll be more visible and active there in the future. The same things that kept this article from being written the past few weeks have been keeping me out of the newsgroup.) You can also visit for updates and new information, or for other community updates.


Windows XP Embedded with Service Pack 1 is the newest version of the Windows XP Embedded tools and database. New tool features are available, as are new embedded enabling components. Every Service Pack 1 binary is reflected in an updated component, and some new components have been added to make the entire system more flexible.

Next month: Who knows? That's an entire year away!


Get Embedded

A native New Englander, Jon Fincher worked as a UNIX System Administrator and database programmer before joining Microsoft Product Support Services in 1995. In 1999 he started supporting Windows NT Embedded 4.0, and is now a Software Test Engineer for Windows XP Embedded. He can be seen year round, in all weather, riding his Harley to and from work and play.