I am reminding myself of how disk partitions work, and how they can be manipulated. The impetus for this is an attempt to load Windows XP Embedded (XPe) on my target machine, an ASUS Pundit. Using Acronis Disk Director Suite, ($49.00) I created a separate small partition for the XPe installation. The problem then was trying to figure out how to boot the extra partition.

Partitions can be marked several ways
a. Active Primary – this is the boot partition. There can only be one of these on a disk.
b. Primary – This can be either a bootable partition, or not.
c. Extended – A physical partition that can be further subdivided into other partitions.
d. Logical – A subdivision of an extended partition.

The upshot for the test machine is that I want to have two partitions; one for the original Windows and software installation, that includes all of the necessary application software and a second testing partition for the Windows XPe image which contains all the applications and drivers already burnt into the XPe image.

Also, I need to be able to designate one partion or the other as the boot partition. This is done by marking the partiion as “Active”, and insuring that the boot drive letter is designated drive C:. The first part, designating the partition as the boot partition, seems to work fine within the Acronis program. Changing the drive letter, on the other hand, does not seem to be so intuitive as it involves a registry edit.

The drive letter desgination is important, because many programs rely on the designated drive letter to find their own executables and data.

To boot the XPe partition, I changed it to the “active” partition, and then renamed the drive letter to C: A final change involved changing the Boot.ini file which is present in the root directory of the partition. This file looks like this:

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

and it gets modified to change partition(1) to partition(2) in both instances, so that the boot designated boot partition is indeed the 2nd partition on the drive. I recall from my distant MCP days, that although disk drives are numbered beginning with 0, the partitions are numbered beginning with 1. The diagnostic for this is that if you have already designated the second partition as active, but still boot into the “wrong” partition, it means that the OS files that are loaded are the ones that are pointed to be the boot.ini. To make this even more confusing, there is the notion of the “system” partition and the “boot” partition. This is a distinction which I think is only talked about when dealing with Microsoft operating systems. Perversly, the names seem to be reversed….it is the “system” partition which contains NTLDR and boot.ini. and the “boot” partition which contains \Windows, and \Windows\System32, and all the operating system binary files.

In 99% of the cases, of course these files are are all on the same partition and in most cases there is a single partition on a drive anyway.

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.