Back in May I worked through a Microsoft Virtual Lab online that created a test target environment for a Windows XPe device.
Today, I’m attempting to build my own version of a target device using Microsoft Virtual PC, following instructions from MSDN, How to Demonstrate Windows XP Embedded.

Continuing with the “virtual” theme, I was pleased to see instruction for creating an image on a Microsoft Virtual PC.
If you have never used this, it is available now as a free download, and it is great for trying things out without trying to scrounge another PC someplace. An essential developer’s tool, Virtual PC can be used to try different operating systems, (including non-Microsoft O/S’s), program builds, simulated client environments, virtual networks with multiple workstations, you name it.

But back to Windows XPe. I’m a newbie, so there were several non-obvious issues that I noted in the MSDN instructions.

The procedure describes using the Windows Preinstallation Environment. This is the equivalent of a DOS boot disk with a bunch of command-line utilities that you can use to prepare disk drives, copy drivers, and so forth. Windows PE has been around awhile, it appears to have been initially designed for use by “white box” computer system builders who wanted to configure hardware before installing Windows. So, essentially what you are doing to prepare the virtual PC is the following:

1. Create a new virtual PC and virtual hard drive for the embedded XP application.
Be sure the networking setting is set for “shared networking”.

2. Boot this new virtual PC using the first CD from the Windows XPe Evaluation Kit. This CD 1 contains the boot image for Windows PE. It will boot up the virtual PC and come to a command line with X: as the drive letter. The X:, in this case refers to the CD drive NOT the disk drive that you created for the virtual PC. This is because…you have to partition and format the virtual drive, per the instructions above in the MSDN article.

3. The article then describes the process of running TAP, the “Target Analyzer Tool” which captures the configuraton of the hardware that you are running on. This creates a file called devices.pmq

4. You need to get the devices.pmq to your host machine, either by running TAP with the output switch or copying the file to a share. This is a little confusing in the instructions; here is how I interpreted it.

a. Create a folder on the host machine called C:\Windows Embedded Images”

MD "C:\Windows Embedded Images"

b. Share this folder with a name XPe

NET SHARE XPe="C:\Windows Embedded Images"

c. On the virtual machine, Map the Z: drive to the shared folder using the IP address of the host machine as the server name.

NET USE Z: \\192.168.0.102\XPe

You may have to supply a name and password for this, (actually, this is a good thing..); I had to use my admin name and password to get in.

d. On the virtual machine drive C:, copy the devices.pmq to the shared folder

COPY  C:\ devices.pmq Z:

After completing this portion of the instructions, I continued on with the discussion of the compnent designer. This is one of the tools included in the Microsoft Windows Embedded Studio

1. Go to File Import, and choose the devices.pmq

The import function takes a few minutes to run. (10 or more). Once it is completed and you close the import dialog, you’ll get a first look at the component tree with the imported devices shown on the right.

Photo: c:\componentdesigner.png

2. Ok, moving right along the next step is to “finalize” the component.

This screen shot matches the one in the MSDN article.

3. Saving this file (from File|Save) creates an sld file.

4. Now the sld file needs to be imported into the Windows XPe component database using the Component Database Manager. This step is described in the MSDN document.

Finally, you get to build the Windows XP image using the Target Designer. This is where the components are chosen for the Windows image. Of course, the componet that you’ve just created needs to be added, as it contains all of the information about the target hardware.

The instructions say you should update the User Interface Core Component, but as this wasn’t added yet, I first added this manually. My guess is this would get added if you updated the dependencies before this step. By changing these, you have the opportunity to manipulate the user environment, similarly to the way you can set options using group policies.

Then, when you do the Dependency check, hundreds of components will be added. This step takes several minutes. When it completed, it showed that there were 10430 components included.

When all dependencies are resolved, you then build the run-time image. This took about 3 minutes, resulting with an image of 129.0 mb compressed, and an estimated uncompressed size of 179 megs. Not something that will fit on a floppy disk!

Doesn’t this look familiar?

As part of the process of installing this on to the virtual machine, the instructions call for using the Microsoft Resource Kit utility RoboCopy. This is XCOPY on steroids. Not only does it copy files and directories, but it preserves any attributes and settings on the files and directories. I did the copy. Occasionally it would stop because it claimed the network connection was down. I don’t think think so….as it copied from the the same physical machine. But in the end it looked OK.

This shows the result of the copy operation, and the root directory of the target machine. Recall that this is a command window within the Windows PE Environment (the graphic backround image), appearing in a virtual PC (the title bar and toolbar). Let’s see if the XPe image will boot!

The first boot agent starts. This writes the registry, installs system security, registers components, registers class installers, installs hardware devices, in short, completes the process of installation. Once configured, it forces a reboot again, and Voila! We’re into a session of XP embedded.