Going Virtual

  • Article

 

Mike Hall
Microsoft Corporation

April 23, 2004

Applies to:
    Microsoft® Windows® XP Embedded

Summary: At the ESC West show, Mike Hall finds the solution to his hardware dilemma by installing Windows XP Embedded and Microsoft Virtual PC on the same machine. (9 printed pages)

Contents

The Visual Studio .NET Lab
The Hardware Issue
Setting up Virtual PC
Building the Operating System

We've been running a series of Windows Embedded Essentials (WEE) events all over the world, locations include: India, Germany, Taiwan, Korea, Japan, and China. And we've also had events in the United States: in Boston and San Jose. We were also at the recent Embedded Systems Conference (ESC West) in San Francisco. The WEE events have a number of sessions and hands-on labs covering Windows® CE .NET 4.2, Visual Studio® .NET 2003 managed application development (there's a story here … more on this later), and Windows XP Embedded. You're probably interested in getting the story about ESC West and Visual Studio .NET 2003, which is linked to Windows XP Embedded, so bear with me for a few lines.

The hands-on labs for ESC West were 'interesting'; typically we have time before an event to set up a "Master PC" with Windows XP SP1, Visual Studio .NET 2003, Windows CE .NET, and Windows XP Embedded. The Windows CE .NET and Visual Studio .NET labs both use the Windows CE Emulator as the target for the operating system and for the managed application and are therefore hardware independent. For Windows XP Embedded we dual-boot the development PC into the Windows XP Embedded image. This is of course a great experience for the delegates, but can cause some issues with setting up the machines.

For ESC West, it turns out that we had PCs running four different hardware configurations in the lab. This meant we should run Target Analyzer Probe (TAP) on each of the four "master" PCs, use Component Designer to create a new component based on the devices.pmq file, and then build and test the Windows XP Embedded operating system. We didn't have access to the lab at ESC West until the day before the event. It was early evening before we discovered that some of the lab PCs were running with different hardware, and Ghost was failing to deploy images to some of the machines in the lab (due to some of the PCs having smaller hard drives than our original master image). We had our trusty Technical Support Group (TSG) team working on fixing the Ghost issue, which gave Doug Boling and I some time to think about the Visual Studio .NET lab.

The Visual Studio .NET Lab

The lab as it currently stood was OK; delegates got to build a C# .NET Compact Framework 'scribble' application that included building a custom control. Since we had some time on our hands, we decided to upgrade the lab somewhat, meaning we drop the scribble control code and add support for XML Web services. The delegates would write a .NET C# scribble application that supports mouse down, mouse move, and mouse up. We build an array of points (if the mouse is down), and then call an XML Web service to store the list of points and the name of the 'artist.' We also had a C# Desktop application running on the lab server, which can display the scribble submitted by any of the delegates. This proved to be far more entertaining than the original scribble lab; some of the 'art' submitted by delegates was actually quite good, and I should have saved some to show in this article … perhaps next time.

The Hardware Issue

So, that brings us back to the hardware issue at ESC West. Multiple PC configurations and one Windows XP Embedded lab that needed to run across all of the machines—was there a simple solution to this issue? You bet. In fact the answer to this had been staring me in the face for quite some time … For the Windows CE labs, we use the Windows CE Emulator, which emulates a "CEPC" device. It doesn't matter what the underlying development PC hardware is, as long as the development PC is running Windows 2000 or Windows XP, you can run the Windows CE development tools and emulator. How does this help with Windows XP Embedded? Ladies and gentlemen, let me introduce you to Microsoft Virtual PC 2004. This product is able to boot and run an operating system within a Virtual PC environment—pretty cool! Virtual PC gave me the ability to build and run Windows XP Embedded hands-on labs without worrying about the underlying PC hardware. There are a number of other advantages to running Windows XP Embedded in the Virtual PC environment, more on this later …

Setting up Virtual PC

Installing Virtual PC was a snap; the installation is very clean (to check on the system requirements for Virtual PC 2004, go here. There's also a 45 day trial version of Virtual PC for you to download and try out for yourself.

Once we had Virtual PC 2004 installed, we needed to determine how to boot and run the Windows XP Embedded operating system. For this task, there are two choices.

For the first choice:

  1. Boot Virtual PC into MS-DOS.
  2. Run TA.exe to capture the underlying hardware.
  3. Pull the devices.pmq file back to our development PC.
  4. Build a Windows XP Embedded system

The issue is how to transfer the Windows XP Embedded operating system to Virtual PC and boot the image. (Network drivers for all Microsoft operating systems for the Virtual PC DEC 21140 net card are available here.)

For the second choice:

  1. Boot Virtual PC into Windows XP.
  2. Run TAP.exe to capture the underlying hardware.
  3. Pull the devices.pmq file back to the development PC.
  4. Build a Windows XP Embedded system.

We don't have an issue—booting Virtual PC into Windows XP has a number of advantages.

Using Windows XP as the host operating system for our Windows XP Embedded image provides a number of benefits: First, Windows XP has great networking support, making it possible for me to share a folder on the Virtual PC, and then drop my Windows XP Embedded image directly from my development PC onto the Virtual PC and boot the image. Second, since I don't have to reboot my development PC to test the operating system image, I also have the ability to remote-debug the Windows XP Embedded operating system and applications. And third, the shutdown/reboot cycle for Virtual PC is very fast.

I decided to install Windows XP onto Virtual PC as the 'host' operating system. I could then run TAP on Windows XP to capture the underlying hardware configuration. But how to install Windows XP onto Virtual PC? In effect the Virtual PC is a 'naked' PC box; you need to configure the size and partition information for the Virtual PC's hard drive. Virtual PC can share your desktop hardware, which means that you can boot Virtual PC from your development PC's floppy drive or from your development PC's CD-ROM. I started by booting into MS-DOS from a physical floppy drive, so that I could then run FDISK on my Virtual PC's hard drive. This gave me the ability to configure the hard-drive partition information. I opted for a 2GB primary partition (to boot and run Windows XP) and a 700MB second partition to boot and run the Windows XP Embedded operating system.

The next step was to somehow install Windows XP—the Windows XP setup program doesn't run from MS-DOS. So I decided to install Windows 98, and then run the Windows XP installer from there. It turned out that I could boot from the Windows XP setup CD-ROM without installing Windows 98. The installation process went extremely smoothly.

Here's how Windows XP SP1 looks inside Virtual PC. Notice the balloon notification for new updates to be installed … yep, it's just like running Windows XP on your desktop (and that's the whole idea, right?).

Figure 1: Windows XP SP1 Inside a Microsoft Virtual PC

<Engage the way-back-when machine>

Just for fun, and because I had a few spare minutes, I also decided to run Windows 2.03 inside Virtual PC, check this out … It's amazing to see how far things have progressed from Windows 2.03 to Windows XP.

Figure 2: Windows 2.03 Inside a Virtual PC

</Engage the way-back-when machine>

With Windows XP now set up on Virtual PC, I could next configure the rest of the device, including formatting the second 700MB partition to be NTFS and modifying boot.ini on my Virtual PC's C:\ drive.

Boot.ini is set as system and hidden. Here's how my modified 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="Windows XP Embedded" /fastdetect

Now when I boot the Virtual PC, it prompts me to select either Windows XP or Windows XP Embedded.

At this point we were ready to configure and build the Windows XP Embedded operating system image. We needed to get the hardware snapshot from the Virtual PC. This is where TAP.exe comes in. TAP.exe is installed in C:\Program Files\Windows Embedded\utilities on your development PC. Because the Virtual PC supports networking, you can create a share on the Virtual PC or create a shared folder between the development PC and the Virtual PC, drop TAP.EXE onto the Virtual PC, and run the TAP application. (Note: Using a shared folder is also the way for you to drop your Windows XP Embedded operating system on to the Virtual PC.) TAP generates the XML file devices.pmq, which contains a snapshot of the Virtual PC hardware. Once we had this file, we could create a custom component using the Component Designer tool.

You may know that you can import the devices.pmq file directly into Target Designer—this is one option. I prefer to import the PMQ file into Component Designer and then add the Selector Prototype. When the component is checked into the component database, you then have the ability to select individual hardware components from your PMQ component. Why might this be useful? You may be interested in building a "locked down" device to deny someone the ability to install applications on the device. In this case, you could switch off the CD-ROM, the floppy drive, etc. … Or, perhaps you are interested in updating the device, you could use technologies such as Device Update Agent (DUA).

Our Windows XP Embedded Virtual PC device had two partitions: the first partition (C:\) contained Windows XP, the second partition (D:\) contained the Windows XP Embedded operating system image. When configuring the target device settings in Target Designer we needed to ensure that our boot device is Drive C and our target is Drive D. We also needed to configure the Boot ARC path to be partition 2 (see Figure 3).

Figure 3: Target device configuration

I based my initial Windows XP Embedded image on the Information Appliance template (macro component). You may have noticed that a number of components displayed in Target Designer are displayed in boldface font. Bold indicates that these components are macro components, in other words they don't have any functionality in their own right, they simply pull components from the catalog into your workspace. Creating macro components is relatively easy; perhaps this can be the subject of next month's Windows XP Embedded article.

Building the Operating System

After selecting the hardware component and the Internet Appliance component (and configuring the boot parameters for the device) we were ready to build the operating system.

The first step was to run a dependency analysis. This expands all the macro components into their individual components and pulls in any dependent components from the catalog. For example, one of the components in your platform may require DCOM and DCOM as a technology relies on RPC, therefore during the dependency analysis phase, RPC would also be added to the platform.

The dependency analysis process can't resolve all features for us, because the tool doesn't know: whether we're booting from FAT or NTFS; whether we want the Explorer shell or the Taskman/CMD shell; which language(s) we're going to be using in the user interface (Windows XP Embedded supports MUI, Multi-Lingual User Interface); or whether we're going to be using NT Loader or the EWF loader. We need to resolve these issues by hand. Thankfully, Windows XP Embedded provides a handy task list to make this process easier. Here are the four items we needed to resolve for our platform.

Figure 4: The Windows XP Embedded task list

I selected the following:

  • ACPI Uniprocessor PC – NT Loader
  • Regional and Language Options – English Language Support
  • User Interface Core – NTFS Format and FAT Format
  • Windows Logon – Explorer Shell

We could now build the Windows XP Embedded operating system image to the C:\Windows Embedded images/\DriveD folder. (Our sample operating system is about 250MB.) The next step was to copy the contents of C:\Windows Embedded images/\DriveD over to the Virtual PC. Virtual PC supports networking and the ability to share folders on your development PC. I've shared C:\Windows Embedded Images as Drive Z: on the Virtual PC, and therefore I just needed to copy the files from Z:\DriveD to D:\. Then I reboot and select Windows XP Embedded as my boot target.

Figure 5: First Boot Agent (FBA)

The Windows XP Embedded operating system runs through a process known as First Boot Agent (FBA), which is responsible for configuring the hardware, registering COM objects, and a number of additional housekeeping tasks. Once FBA is complete the Virtual PC reboots. After this reboot, we could select Windows XP Embedded and boot into the final Windows XP Embedded operating system image.

Figure 6: Booting into the Windows XP Embedded operating system

Since we were booting Windows XP Embedded inside Virtual PC on the same machine as our development tools were on, we could do a number of additional (interesting) things. For example: we could set up an Internet Information Server on our development PC and work with DUA to update the remote Windows XP Embedded operating system image. There's a video on MSDN that shows this in action. We could set up Visual Studio .NET 2003 on our development PC and the Visual Studio Remote Debug components in our Windows XP Embedded image and do some remote application development and debugging (which is very cool).

That's about it for this month's Windows XP Embedded "Get Embedded" article. Perhaps next month we can delve deeper into the Virtual PC environment and take a look at remote application development and debugging.

This month we looked at using Virtual PC 2004 to host a Windows XP Embedded operating system image. Here's a couple of useful links to get you started:

Virtual PC 2004

Windows XP Embedded Evaluation Software