Dual-Booting Tips for Windows XP Embedded

by Sean D. Liming
Microsoft Embedded MVP
Managing Director, SJJ Embedded Micro Solutions

March 2005
Applies to Microsoft® Windows® XP Embedded

Summary

Dual-booting is one of the most popular target methods when getting familiar with Windows XP Embedded. This article discusses some of the tricks to use to solve dual-boot configuration issues.

Contents

Configuration Settings

Boot.ini File

ARC Paths

Drive Letters

Virtual PC 2004 - Better Alternative

Introduction

Many first-time Windows® XP Embedded developers choose their own development system as a Windows XP Embedded target platform. Known as dual-booting, this allows the developer to build the Windows XP Embedded operating system in Windows XP Professional, download the operating system to a separate partition or hard drive, and then reboot the machine into Windows XP Embedded. Dual-booting saves money, because it is no longer necessary to buy a separate computer as a target.

One problem for developers programming in this environment is setting up the correct parameters within the Windows XP Embedded configuration and the boot.ini file. The Windows XP Embedded newsgroups are filled with questions about Advanced RISC Computing (ARC) paths, boot.ini settings, and drive letter issues. In the following sections, I will try to demystify the different issues.

Configuration Settings

In the Windows NT Embedded days, the only setting requirement to dual-boot between Windows NT and Windows NT Embedded was changing the ARC path in the boot.ini file of the primary active partition. Now, however, the registry is more integrated. As a result, Windows XP and, subsequently, Windows XP Embedded require the drive letter and ARC path information to be built into the registry. When you install Windows XP on a computer the drive letter and ARC path settings are automatically installed during setup.

For Windows XP Embedded, you must manually set the drive and ARC path settings in Target Designer for your custom configuration. Figure 1 shows a sample Target Device Settings section. The operating system will reside in the second partition of the first hard drive. The partition is 2MB in size.

Target Device Settings – Is the drive letter correct?

Is this drive E letter correct? How do you determine these parameters? The following sections provide tips on how to setup these parameters.

Boot.ini File

The addition of the boot.ini file with Windows NT allowed more than one instance of an operating system to exist on a computer. Using the boot.ini file, you can boot into different operating systems such as DOS, Windows 9X, Windows 2000, Windows XP, and Windows XP Embedded. Typically, these different operating systems reside on different hard drives or partitions on the computer. The boot.ini file contains the ARC paths that define the path to the operating system installation.

When you build the Windows XP Embedded image, Target Designer automatically creates a boot.ini file with an ARC path based on the value in the Target Device Settings. In a dual boot scenario the image's boot.ini file is not used. Neither are the NTLDR and NTDETECT files, which are in the root of the image.

When a computer boots, the BIOS post runs and configures the chipset to boot the operating system. After the system BIOS completes the ROM scan operation, it then looks for a boot device such as floppy, CD-ROM, USB flash, PXE client, or hard drive. On a hard drive, the BIOS looks inside the first few sectors also known as the Master Boot Record (MBR). The MBR has all the partition and track information that tell the BIOS where to locate the primary active partition. There must be one primary active partition in the system.

In the dual-boot scenario, Windows XP Pro resides in the primary active partition, and only the boot.ini file (as well as NTLDR and NTDETECT) in the primary active partition will be used. Once you build the Windows XP Embedded image, you will have to manually edit the boot.ini file in the Windows XP Pro partition to add the second ARC path selection. Here is an example:

[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="Microsoft Windows XP Embedded" /fastdetect

Whether the files are used or not, it is still a good idea to copy the entire Windows XP Embedded image, including the root-boot files, to the partition. You will need these files when you start working with a stand-alone system.

ARC Paths

The operating system uses the ARC path to determine where the operating system resides. The path multi(X)disk(Y)rdisk(Z)partition(W)\<windows_dir> provides a pointer to the device location of the operating system. Determining the values for X, Y, Z, and W, however, can be problematic.

There is also a scsi(X)disk(Y)rdisk(Z)partition(W)\<windows_dir> ARC path convention that is used with SCSI drives. SCSI drives are more complicated, since you might be using a mix of the two ARC path types. Because IDE (including Serial ATA) drives have improved performance, and SCSI drives are less popular, we will use IDE ARC path types as examples in this article. For more information on SCSI support, please see the MSDN ARC Path article reference in the References section. For this reason, we can say that the X and Y values are always 0 – multi(0)disk(0). This leaves only the Z and W values.

The Z value refers to the disk number, which start with 0. The disk order is typically defined by the IDE or SATA bus (IDE 0 or IDE 1 and SATA 0 or SATA 1) and whether the disk is a primary or secondary drive..

The W value refers to the partition number on the disk defined by the Z value. Partition numbers start with 1.

Here are a few examples will clarify this Z and W concept.

Example 1: You want Windows XP Embedded to boot from the 2nd partition on the 2nd IDE disk (IDE0 secondary drive). The ARC path would be the following:

multi(0)disk(0)rdisk(1)partition(2)\WINDOWS="Microsoft Windows XP Embedded" /fastdetect

Example 2: You want Windows XP Embedded to boot from 3rd partition on the 4th IDE disk (IDE1 secondary drive). The ARC path would be the following:

multi(0)disk(0)rdisk(3)partition(3)\WINDOWS="Microsoft Windows XP Embedded" /fastdetect

Example 3: You want Windows XP Embedded to boot from 2nd partition on the 1st IDE disk (IDE0 primary drive) The ARC path would be the following:

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Embedded" /fastdetect

Notice that the ARC paths end with \WINDOWS. There is some confusion from developers who have been upgrading their systems from Windows NT. The old directory was called \WINNT. The Windows XP Embedded image has all the main files in the \WINDOWS directory, so you should also have \WINDOWS in the ARC path. If you used \WINNT instead, you would get the following error on boot:

Windows could not start because the following file is missing
or corrupt:
<Windows root>\System32\hal.dll.
Please re-install a copy of the above file.

Drive Letters

The driver letter causes the most problems and can be the most difficult parameter to figure out. If you set the drive letter incorrectly, the operating system will reboot over and over without ever starting the Microsoft Windows XP Embedded First Boot Agent (FBA).

When you create a second partition, Disk Manager automatically assigns the new partition a drive letter. In Figure 2, a second partition that is to be used for Windows XP Embedded on the primary disk was assigned the drive letter E by Disk Manager. The CD-ROM drive uses the drive letter D.

Fig 2 A Second Partition With Drive Letter E

It's tempting to assume that the Windows XP Embedded drive letter must be E, and therefore you would probably set up the Target Device Settings like the first illustration. However, this is NOT the case.

To determine the correct drive letter, assume the system boots to DOS without a CD-ROM driver, and that all drives have the File Allocation Table (FAT) file system. If you were to access each partition in DOS, then, the drive letters would break down as follows:

• C in Windows XP Embedded would be C in DOS.
• E in Windows XP Embedded would be D in DOS, since the CD-ROM drive is not loaded.

The correct drive letter, then, is D. In Fig 1, the Target Device Settings needs to use the D drive letter, rather than E. While this is not the most scientific method to find the drive letter, it has worked time and time again.

Be aware that you may have to play with the drive letters if your system has multiple hard drives.

Virtual PC 2004 - The Better Alternative

I have to admit, dual-booting is not my favorite method to test Windows XP Embedded. I prefer a separate target system; because the original equipment manufacturer (OEM) is going to ship a system that uses only Windows XP Embedded.

It's natural to want to save money and to explore options for the first time. If you're then unable to boot the operating system, though, the result is a bad experience that could have been avoided. And there is another drawback. You must shut down access to your development system to boot into a test operating system, which slows the overall development process.

For these reasons, Virtual PC 2004 (VPC) is superior to dual-booting. I have found VPC very helpful on long trips where a second target system is not possible. Best of all, I don't have to reboot my computer each time I need to run a build of Windows XP Embedded.

As of this writing, Virtual PC 2004 had a free 45 day trial edition that you can download from this Microsoft website. Please see the Windows XP Embedded Toolkit at www.sjjmicro.com for more information about using Windows XP Embedded with the VPC.

Conclusion

Dual-booting a development machine to test Windows XP Embedded is a quick way to get familiar with the tools. A thorough understanding of ARC paths and drive letters will help you succeed in the long run.

SJJ Embedded Micro Solutions

Developing an embedded system is more than just picking a few components and building an image. Developers have to take into account how the system is used, manufactured, and supported in the field. At SJJ Embedded Micro Solutions, we take an architectural approach to delivering the right solution for your product. We have experience in a variety of markets. Our previous Windows Embedded projects have included: Thin clients, Gaming Consoles, Industrial Controls, Voice-over IP Systems, Test Equipment, Consumer Electronics, and Automotive.

If you are looking for support for your Windows XP Embedded project, please contact us at sales@sjjmicro.com or see us on the web at: www.sjjmicro.com.

Looking for help with Windows XP Embedded SP2? Check out the new Windows XP Embedded Supplemental Toolkit that covers Windows XP Embedded Service Pack 2.

For More Information

For more information about Windows XP Embedded, see the Windows Embedded Web site.

For online documentation and context-sensitive Help included with Windows XP Embedded, see the Windows XP Embedded product documentation.

Additional Resources

FBA Reboots Repeatedly

BOOT.INI and ARC Path Naming Conventions and Usage

How Windows 2000 Assigns, Reserves, and Stores Drive Letters