Creating the virtual hardware component is pretty straightforward, and follows the same general process as my previous guide.  For your convenience, I’ve uploaded my component that I created running XP on ESX.

vmware4.sld

However, just the component isn’t enough for ESX.  ESX 3.x doesn’t support virtual IDE hard drives.  Likewise, Windows XPe doesn’t support SCSI drives.  So, you’ll have to install the VMware SCSI driver.  During a normal XP installation, you can do this by pressing F6 during installation and loading the drivers from a floppy, but because you build XPe rather than installing it, you have to componetize the driver.  Again, I’ve already done this for you.

vmscsi.zip

If this doesn’t work for you, you can download the floppy image containing the driver from VMware.com, extract it, and then import the vmscsi.inf file into the XPe Component Designer.

Once you have both the vmware4 and vmscsi components added to your XPe profile, run dependency checks to pull in the required components and build the image like you did in the last guide.  After that, move the Virtual Machine onto your ESX box (assuming you didn’t create it there) and fire it up.

For the moment, I accomplish this by having the component run the installer at first boot, but I’m hoping to come up with a more elegant solution in the next couple of days.

Component design is another aspect of XPe Tools that could use some work.  With most software for Windows being distributed in exe or msi form, I was suprised that there was no utility to build a component from one of those files.  Instead, the best way to accomplish that would be to use a third party tool, such as InCtrl5, that will monitor changes to the filesystem and registry during the installation of any given piece of software.

Another odd thing I noticed today is that the Target Designer seemed to be crashing on me every few minutes.  I just upgraded it to SP2, and I’m wondering if that’s the problem.

XP Embedded Studio isn’t actually a horrible application at it’s core.  Now, the user interface and documentation are God-awful, which is why I’m writing this post.  As you saw in my last two entries, I’ve been working with XPe for the last few days, and there has been plenty of frustration to go along with it.  What should have been a fifteen minute task wound up taking several days.  However, one week and a few dozen BSODs later, I present this how to:

The idea here is to use VMware to not only run, but create your XPe images, though you could easily do the development in your host environment with only minor changes to these directions.

Step 1: Prepare your development environment

First, let’s get the virtual machines set up.  You’ll need at least two, one for doing the development, and another to test the image.  The first image is just a regular Windows XP virtual machine.  I already had a Windows XP Pro virtual machine that I use on a daily basis, so I just used that.  You’ll need to set up the Windows XP Embedded development environment.  If you don’t already have it, you can download a 30 day evaluation copy from Microsoft.

Now, go ahead and create the second virtual machine, which you will use to run your XPe image.  Create a new VM in VMware and choose Windows XP Professional as the Guest OS. (Note: If you are using WS 6.5 or later, you don’t want to use easy install.  Choose to install the guest OS later.)  I selected some pretty basic specs for the VM:

• Memory: 256MB
• Processors: 1
• Hard Disk (IDE 0:0): 512MB

It doesn’t take much to run XPe, and those listed specs should be fine unless you’ll be putting a lot of data on the image.

Now that your VM is created, you need to add it’s hard drive to your original XP VM.  Make sure your XP VM is shut down, then open the Virtual Machine Settings dialog and click Add.  Choose to add a new Hard Disk, and when prompted, choose to add an existing virtual disk.  Navigate to your XP Embedded Virtual Machine and choose the vmdk associated with it.  After it has been added, open the Advanced properties for that disk and make it Independent and Persistent.

Step 2: Load a profile of your virtual hardware

This was the part that gave me grief.  Fortunately for you, you can benefit from my experience.  You need a profile of the hardware you will be running XPe on so that XPe knows which drivers to load.

Step 2a: The easy way

I have prepared a component for Windows XPe that will automatically load in a set of generic drivers that are capable of running on VMware virtual hardware version 6, which is the version used in Workstation 6.0.  If you are using Workstation 6.5, it uses version 7 of VMware’s virtual hardware.  Chances are you’ll still be able to use my component, and you should definately try it.

Download my XPe VMware Component

You’ll need to install the .sld file using the Component Database Manager.

If you ultimately wind up with an unbootable XPe image, you’ll want to come back and perform the steps in 2b, but for now, proceed to step 3.

Step 2b: The not-so-easy way

So, you need to create your own profile for your virtual machine.  First, you’ll want to create a third VM.  Again, it should be Windows XP Professional, and the hardware should be as similar to your XPe VM as possible, though you’ll need more hard drive space.  I wound up needing about 1.5GB of disk space for this step, but it wouldn’t be a bad idea to allocate more just in case.

Install Windows XP Professional (Professional is important here) on the new virtual machine.  It’s very important that you DO NOT install VMware tools on this VM (This gave me trouble during my experimenting).  This means that if you’re using VMware 6.5 or later, you need to install the OS manually and not use Easy Install. (Note: You don’t need to bother activating this VM if you don’t want to, you’ll only need it for a minute.)

Once you have a vanilla installation of XP Pro up and running, you’ll need some of the XPe tools.  Go back to that link I posted near the beginning of this post and download and run the XPe downloader again.  This time, you only need the Windows XP Embedded SP1 Tools package, which is around 7 MB.

Let that download and start(You may get a warning, ignore it), then choose to Browse the CD.  Open the fodler named XPE and look for a file named TAP.EXE (Or probably just TAP, as XP will hide the file extensions by default).  Double-click it and it will run, leaving behind a file named devices.pmq in that same directory.  Now you need to get that pmq file back to your original XP VM where you’re doing the XPe development.  I just opened Internet Explorer and Gmailed it to myself.  Once you have the pmq file, you don’t need this extra VM anymore and you can delete it.

Back in your original VM, grab your devices.pmq file and put it somewhere on the hard drive.  Now open Microsoft Component Designer and choose File > Import and open devices.pmq.  Go through the import process, then if you want you can give your component a name and other info.  Finally, save the component as a *.sld file and then import that sld using the Component Database Manager.  Now your component should be available when building XPe images.

Step 3: Create the Image

Open the XPe Target Designer and start a new project.  On the left hand side of the window, you should see a list of components, including the VMware hardware profile that you either downloaded from me or created yourself.  Double click it to add it to the project.

Now, press F5 to perform a dependency check.  It will run through and automatically add most of the needed components, but it will need your input on a few of them.  If you are using my profile, you should wind up with 6 errors, which will be displayed at the bottom of the screen.  For each item, double click the icon next to it to see the list of available components that will satisfy that dependency.  Choose the components that best suit your need, but for a standard set up, I recommend using the following whenever they come up as options:

• NT Loader
• FAT
• Windows Logon

After all of the dependencies are taken care of, it’s time to… run another dependency check!  For some reason, Microsoft doesn’t do recursive dependency checking here.  Press F5 again, and wait for it to finish.  At this point there should be one more error, the shell.  Handle this one just like the last set.  For a standard set up, I’d recommend just using the Explorer Shell.

Continue to run dependency checks until it comes back with no errors.

You’re almost there.  At this point, it’s a good idea to save your work.

Step 4: Prepare the virtual disk

Open up XP’s built in disk manager and find your XPe VM’s hard drive that you attached to your original XP VM.  Make sure it is initialized, then partition and format the entire disk as FAT32.

You’ll also need to make sure that the partition is marked as bootable.  You can do this however you like, I booted the VM to an Ubuntu Live CD and used the built in partition editor.

Step 5: Build XP Embedded

Back in the Target Designer, you need to build the XPe image.  To do this, press F7.  For build type, choose Release.  For Destination, enter the path where your XPe VM’s is mounted, for example, D: or E:.  Note that it will be mounted at C: in XPe.  Finally, press Build.  If all goes well, you will get no errors, and maybe a warning or two.

Step 6: Run it

Only one VM can access a particular vmdk at a time, so you’ll want to suspend your XP VM now.  Once that’s done, switch over to your XPe VM and power it on.  If you’ve done everything correctly, you should be a Windows XP Embedded loading screen, then the First Boot Assistant, after which it will boot into your embedded environment.

Congratulations! You now have a minimal XPe system that is capable of running on virtual hardware.  In order to add additional components to your XPe image, shut down the VM and resume your original XP VM.  Modify the image as you see fit, then reformat the target disk and build again.  There shouldn’t be a need to mark the partition as bootable again.

If your XPe image crashed, you’ll need to do some debugging.  If you were using my pre-made profile, go back to Step 2b and create a profile yourself.  This should be guaranteed to work, but if not, I’d start by checking for information on MSDN.  If your image is crashing with a BSOD, try Googling the error number and seeing what you get.

During some of my sporadic downtime when Windows was crashed, loading, or rebooting, I took a look at the iPhone SDK and emulator.  Some of the webapps for the iPhone are really impressive, notably Facebook and Meebo.  I even found a plugin/theme for WordPress to make a site more iPhone friendly and set it up for Collegegeek.org.  I haven’t started coding anything yet, but the first step will be to start learning some Objective C.

*Shudders*

Microsoft has made some lousy products in the past, but the Embedded SDK has to be one of the worst.  The application isn’t remotely intuitive to use, and even once you’ve learned what you’re doing, it’s not easy.  The task I had was simple: create an XPe image to test a particular program with.  However, this was far more difficult than it needed to be.  Even though I had a list of the DLLs that I needed, there was no easy way to find those DLLs in the XPe tools.  Each time that I wanted to load a DLL, I had to manually create a new filter for “Contains” and the name of the DLL, rather than use the integrated search box.  For some reason, the search box would not look at the names of the DLL files themselves, just the name of the packages they were in.  Even creating a filter didn’t work 100% of the time (actually, I don’t think it even found 10% of the files I needed).

Secondly, the built in dependency generation was a joke.  When you clicked on “Build,” it would ask you if you wanted to automatically fulfill dependencies.  You click yes, and it does that, but it’s not recursive.  Whast I mean, is after it’s done, and you click “Build” again, you know have X number of new components that need to have their dependencies checked, and so XPe will go on to scan every component again.  It took 5 or 6 rounds of dependency checking before it was finally happy for me.  Then, I got to build the image.  The software did some hocus pocus, and then spat out a standard looking C: filetree in a directory on my hard drive.  Now what?  I had Program Files, Documents and Settings, and WINDOWS, but no idea what to do with them.  I tried putting them on a virtual 512MB hard disk and creating a virtual machine to boot to it, but no luck, there was no MBR on the disk.  After 30 minutes or so of reading documentation on the matter, I called it quits for the day and went on to work on other things.

I know it’s not an impossible issue to overcome, and I’m sure I’ll get past it tomorrow, but creating an embedded image was far more difficult than it needed to be, and in my opinion, should be handled something like this:

1. Start a new Embedded project.
2. Load any number of executables that you need your system to run into the project.  The software scans the EXEs to determine which libraries they are linked against, and copies those files into the project as well. (Visual Studio has a tool to scan an EXE and determine it’s dependencies, so this should be possible.) The included EXEs will be copied into Program Files when the image is created.
3. Create a profile of the hardware that the image needs to run on, and load the appropriate drivers.  For more common hardware, this could be done automatically, otherwise, the user could manually download and add the needed drivers.
4. Now, perform a single, recursive, dependency check to satisfy all of the previously included components.
5. Finally, export the image to a specified format, such as a CD ISO for installing the image, or a bootable USB jump drive.

That’s just a rough outline, but I think that it’s relatively feasible and that creation of embedded systems could be much easier.