Dual-booting provides some cost savings by not having to buy a separate PC as a target. What many developers run into, when developing in this fashion, is the problem of setting up the correct parameters within the XPe configuration and the boot.ini file. The XPe newsgroups are filled with questions about ARC paths, boot.ini settings, and drive letter issues. In the following, I will try to demystify the different issues:
Configuration SettingsBack in the Windows NT Embedded days, changing the ARC path in the boot.ini file of the primary active partition was the only setting requirement to dual-boot between Windows NT and Windows NT Embedded. Now, with a little more registry integration, XP and subsequently XP Embedded require the drive letter and ARC path information to be built into the registry. When Windows XP is installed on a PC, the drive letter and ARC path settings are automatically installed during setup.
For XP Embedded, you have to manually set the drive and ARC path settings in Target Designer for your custom configuration. The picture below shows a sample Target Device Settings. The OS will reside in the second partition of the first hard drive. The partition is 2MB in size.
Figure 1: Target Device Settings -- Is the drive letter correct?How do you determine these parameters? The following sections provide some tips on how to setup these parameters.
Boot.ini FileThe addition of the boot.ini file back with Windows NT allowed more than one instance of an operating system to exist on a PC. Via the boot.ini file, you can boot into different OSs such as DOS, Windows 9X, Windows 2000, Windows XP, and XPe. Typically, these different OSs reside on different hard drives or partitions on the PC. The boot.ini file contains the ARC (Advanced RISC Computing) paths that define the path to the OS installation.
When you build the XPe image, Target Designer automatically creates a boot.ini file with an ARC path based on what is set under the Target Device Settings. When it comes to dual-booting, this boot.ini along with NTLDR and NTDETECT, which are in the root of the image, are not used. A PC boots from a primary active partition. 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 is going to be used. After you build the XPe image, you will have to manually edit the boot.ini file in the 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 habit to copy the whole XPe image including the root-boot files to the partition. You will need these files when you start working with a standalone system.
ARC PathsThe ARC path provides the OS a method to determine where the installation of the OS resides. The long multi(X)disk(Y)rdisk(Z)partition(W)\
windows_dir
provides a pointer to the directory location of the OS installation. Determining X, Y, Z, and W is the real trick.
I should mention that there is also a scsi(X)disk(Y)rdisk(Z)partition(W)\
windows_dir
ARC path convention for use with SCSI drives. SCSI drives make things a little more complicated, and you might be using a mix of the two ARC paths. Since IDE (including Serial ATA) drives have improved performance and SCSI drives have faded out, we will stick to IDE discussions for this article. For more information on SCSI support, please see the MSDN ARC Path article reference in the last section. With that said, it is simple to say that X and Y are always 0 -- multi(0)disk(0). This leaves Z and W.
Z refers to the disk number, and disk numbers start with 0. The disk order is typically defined by the IDE or SATA bus and whether the disk is a primary or secondary drive. W refers to the partition number on the disk defined by Z. Partition numbers start with 1. A few examples might clarify the concept further.
Example 1: You want XPe 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 XPe 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 XPe 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 has been some confusion from developers that have been upgrading their systems since Windows NT. The old directory used to be called "\WINNT". The XPe image has all the main files in the "\WINDOWS" directory so you should also have "\WINDOWS" in the ARC path. If you accidentally used "\WINNT", you would get the following error on boot:
Windows could not start because the following file is missing or corrupt:
\System32\hal.dll.
Please re-install a copy of the above file.
Drive lettersNow that the ARC path has been discussed, what about the drive letter? The driver letter causes the most problems and can be the most elusive parameter to figure out. If you set the drive letter incorrectly, the OS will reboot over and over without ever starting FBA.
When you create a second partition, Disk Manager automatically assigns the new partition a driver letter. In the picture below, a second partition that is to be used for XPe on the primary disk was given the drive letter E, where D is the CD-ROM drive.
Figure 2: A second partition with drive letter EYou might be tempted to make the assumption that the XPe drive letter needs to be E, and you would probably setup the Target Device Settings like the Figure 1 above. This is not the case. To determine the correct drive letter, you have to think of the system as booting to DOS without a CD-ROM driver, and all the drives have the FAT file system. If you were to access each partition in DOS, the drive letters would break down as follows:
- C in XP would be C in DOS
- E in XP would be D in DOS since the CD-ROM drive is not loaded.
The correct drive letter is D. Figure 1's Target Device Settings needs to have D's instead of E's for the drive letters. It is not the most scientific method to find the drive letter, but it has worked time and time again. You may have to play with the drive letters if you have multiple hard drives in the system.
Virtual PC 2004 - The Better AlternativeI have to admit dual-booting is not my favorite method to test XPe. I prefer a separate target system; because in the end, the OEM is going to ship a system with only XPe on it. I understand the need for cost savings and first time exploring, but when you cant get the OS to boot correctly, you will be left with a bad experience that was never intended to happen. Plus, the fact that you have to shutdown access to your development system to boot into a test OS, only slows down overall development process. Virtual PC 2004 (VPC) is the better alternative to dual-booting. I have found VPC very helpful on long trips where a second target system is not possible. Best of all, I dont have to reboot my computer each time I need to run a build of XPe.
At the time of this writing, the Virtual PC 2004 had a free 45 day trial edition that you can download from the Microsoft
website. Please see the
Windows XP Embedded Toolkit for more information about using XPe with the VPC.
Reference Material -- MSDN Articles
About the author
Sean Liming is a Microsoft eMVP and is the author of three books on Windows Embedded including
Windows XP Embedded Advanced and
Window XP Embedded Supplemental Toolkit. Liming is currently the Managing Director of
SJJ Embedded Micro Solutions, which offers books, toolkits, training courses, and consulting services covering all aspects of embedded design hardware, software, manufacturing, and life-cycle management.
