Running Free: Runtime Basics
September 26, 2002
Summary: Jon Fincher shows how to deploy the run-time image created by the Microsoft Windows XP Embedded tool, Target Designer, on your target device. (8 printed pages)
I'm back, with another installment of Microsoft® Windows® XP Embedded lore and lyricism to entertain you with. Last month we talked about the basics of Target Designer. This month we'll discuss how to take the image Target Designer creates and get it up and running on your target device. And now for something completely different...
Target Device Hardware
Simply adding a series of software components to a blank configuration, checking dependencies, and building it aren't going to get you very far very fast. Software needs hardware to run on, and Windows XP needs to know what hardware you have, so it can load the correct drivers. In the retail system, there's a sophisticated hardware discovery mechanism that occurs during setup. For Windows XP Embedded, there's Target Analyzer.
Target Analyzer: Two Great Flavors!
There are two flavors of Target Analyzer, one for a full or limited Win32 system (called TAP.EXE), and one for DOS systems (called TA.EXE). You can run TAP.EXE on Windows XP, Windows 2000, or a WinPE (Preinstall Environment) CD system. TA.EXE runs best under DOS, or a Win9X boot disk command prompt. If you can boot your device to Windows XP or Windows 2000, then TAP.EXE is your best bet. TA.EXE is a stopgap program, and should only be used if you absolutely cannot install or boot a full Win32 environment on your device. Why is this?
TAP.EXE gets its hardware information directly from the Win32 registry—everything discovered by the sophisticated hardware discovery mechanism I talked about above is read directly from the registry. All TAP.EXE does is read the registry, massage the output, and create an output file. TA.EXE has to query the hardware directly, and in 16-bit mode as well, so it's limited to asking the BIOS for the hardware list. This limits us to devices the BIOS knows about, which means we can't enumerate IDE, SCSI, PCI, or other device busses. We're limited mostly to PnP IDs, and certain devices that the BIOS can pick up. Output files generated by TA.EXE are almost always less complete than TAP.EXE generated output files, but they make a good start to generating the complete hardware list.
The output files TA.EXE and TAP.EXE create have identical formats. They're both XML files following the devices.dtd DTD defined in \Program Files\Windows Embedded\dtd. The files created are suffixed with the PMQ extension (read as "pumpkin," because the inner workings of the file are, like a pumpkin, gooey, messy, and full of seeds).
Once you've got a PMQ file generated for your hardware, you need to import it into the tools. We recommend you import it into Component Designer and create a component out of it—a hardware component is easier to create, maintain, and update than simply having all the instances in a configuration. Once the hardware component is created (in Component Designer, on the File menu, click Import, and find your PMQ file), name it, release it, save it, and import the Source Level Definition (SLD) to the database using Component Database Manager. You can add your hardware component to a blank configuration, add a Design Template, check dependencies, and build. You can, if you wish, import the PMQ into Target Designer. Instead of a dependency for each piece of hardware, you'll get an actual instance created for each one.
We're Slashing Prices to the Ground!
One of the main reasons to import the PMQ file into Component Designer is to allow you to remove hardware that may be causing footprint issues. Creating a SLD makes it easier to delete or disable dependencies; then rebuild and retest the component. Removing hardware from the SLD reduces the footprint of the eventual runtime. Now, how do we start removing hardware?
If you've run TAP.EXE on your device, then you already have Windows XP installed on it. Open Device Manager on the device. From the View menu, click View Devices by Connection, then View, and then View Hidden Devices. These two options let you see most devices on your machine, and the connections between them. It's important to note that the tree structure shown imparts a parent-child relationship between devices—remove the parent and the children will go away as well. In Windows XP Embedded, removing the parent device from the component won't remove the children, but they won't work properly in the runtime. In effect, you'll have orphaned them in the runtime. They'll be taking up footprint and RAM space, but be completely inert otherwise. Keep this in mind when pruning the devices in your hardware component.
Some components lend themselves to easy pruning. Sound devices are the biggest and best of these, so unless your device needs sound, remove anything sound related in the hardware component. This list includes things such as:
- Audio codecs
- Legacy audio drivers
- Media control devices
- Microsoft® Kernel Audio Splitter
- Microsoft Kernel Acoustic Echo Canceller
- Microsoft Kernel GS Wavetable Synthesizer
- Microsoft Kernel DLS Synthesizer
- Microsoft Streaming Service Proxy
- Microsoft Streaming Clock Proxy
- Microsoft Kernel System Audio Device
- Microsoft Kernel Wave Audio Mixer
- Microsoft WINMM WDM Audio Compatibility Driver
- Microsoft Kernel DRM Audio Descrambler
- Audio card (specific to your hardware)
- Game port audio card
Disabling all these devices saves you quite a bit in footprint, and completely disables sound in your runtime.
Quality of Service (QOS) components can usually be removed from the component as well. The QOS components include the Microsoft Streaming Quality Manager Proxy and the Packet Scheduler Miniport components. The same goes for Terminal Services—if you ain't gonna use 'em, get rid of 'em! Anything dealing with Terminal Services or Terminal Server can be removed.
You can also get rid of the entire USB subsystem, if you wish, by removing your USB controller and the following devices:
- Generic USB hub
- HID keyboard device
- HID-compliant consumer control device
- USB composite device
- USB human interface device
- USB root hub
- USB open host controller (chip-set specific in most cases)
- USB universal host controller (chip-set specific in most cases)
The Logical Disk Manager and Volume Manager are unnecessary if you don't need to dynamically manage the disks during runtime. You can remove them to decrease footprint even further. The same goes for WAN miniports and RAS. Again, if they're not being used, jettison them before they contribute to footprint bloat.
I mentioned you could disable the entire USB system. However, as Windows XP and Windows XP Embedded both support legacy-free systems, you might want to get rid of the legacy devices instead. Here's a list of common legacy devices you might want to nix:
- Communications port
- Printer port
- ECP printer port
- Direct parallel
- Printer port logical interface
- Standard 101/102-key or Microsoft Natural® PS/2 keyboard
- Microsoft® PS/2 mouse
- Floppy disk drive
- Standard floppy disk controller
- PCI to ISA bridge (chip-set specific in most cases)
- ISAPNP read data port
The following devices should still be in your system. Consider these "Verboten!" to disable. The footprint savings aren't worth the runtime headaches you'll experience without them:
- System timer
- Direct memory access controller
- System CMOS/real-time clock
- System board
- Numeric data processor
- Programmable interrupt controller
- "Processor" component
- Microcode update device
One last device to think about is your HAL. Through some experimentation, we've found that the Advanced Configuration and Power Interface (ACPI) PC component leads to a smaller footprint than the Standard PC component. If you've got a choice, go with ACPI. ACPI makes lots of sense for embedded devices anyway.
Some caveats bear mentioning. TAP.EXE is very VERY good at what it does; sometimes it's too good. TAP.EXE can pick-up ghost devices—devices that have been previously, but are not currently, installed on the system. Usually these are USB devices. Make sure all the hardware in the component is current and valid. If you have doubts, run TAP.EXE on a clean install of Windows XP or Windows 2000. Lastly, devices gathered from a Windows 2000 system may have different names in Windows XP Embedded. You'll have to use your own intuition to find out what the new devices are if you want to disable them from the Device Manager list.
Configuring the Runtime
Given a hardware SLD, you can generate a basic Windows XP Embedded runtime by checking dependencies, then building the system. It won't do much, but it's a good first step; it will tell you what works and what doesn't. But before you can do that, you need to configure the runtime properly.
Last month, we talked about configuring instances and configurations using the Settings tabs. There are a few settings that might not be as easy to find or manipulate as you think they should be (we're working on it). For now, here are some configuration options you should know about.
Setting a pagefile is easy—when you know where to look. In every configuration, there is an instance from the Hardware : Devices : Computers category. These seven instances contain the settings for pagefiles. Find the instance, click Settings, and you'll see the pagefile settings in the right-hand Details pane.
Windows Desktop Settings
Settings for the Windows desktop allows you to choose items to show on the Start menu, whether to show desktop icons for Microsoft® Internet Explorer and Microsoft Outlook® Express, and set how the Task bar behaves. All this and more can be yours if the price is right—and you look at the User Interface Core Component settings.
All the design templates have settings that allow you to select and deselect the components they depend on. For example, the Advanced Set Top Box template allows you to select or deselect components such as Analog TV, Digital TV Support, and Internet Explorer Technologies.
As we mentioned last month, there are a few settings for the configuration that you need to inspect and set. The most important of these are under the Target Device Settings section of the configuration's Settings details. I won't discuss them again, except to say that these are critical if your runtime is going to boot properly.
The Final Countdown
Okay, by now you've properly specified your configuration and instance settings, you've done a full dependency check with no errors, and built your runtime. Now what?
Well, let's take a look at the folder your image was built to. You should see something like this:
In this case, my default build folder is Windows Embedded Images. I built the image to Windows Embedded Images\MSDN-Test. As part of the settings, I told Target Designer I would boot from drive D:, so it created a DriveD folder, which contains my system folders. The MSDN-Test folder contains the following files:
Notice the three Windows XP boot files are present (boot.ini, NTDETECT.COM, and ntldr). WERUNTIME.INI is used for Windows XP Embedded runtime licensing and to hold static OEM information—it's necessary to have on the boot volume.
Why were these four files split from the rest of the files on D:? Since my machine boots from the C: drive (as most systems do), the boot files need to be there. However, I want the rest of the system files (Windows folder and the like) to be on D:. The physical separation of these files in the build folder makes it easier to split the files on the embedded device.
Now that we know what's where and why, we need to actually get these files onto the embedded device. In my case, my embedded device is a normal PC on our network, so I can simply copy the files over the network. If I had a device that wasn't network capable, I'd install the boot media into my development machine and copy the files locally. (Next month we'll get into what to do if you can't do either of the above, when we cover SDI and some of the other embedded enabling features).
In lieu of a big production number on what to do if you can't shoot the files over the network or copy them locally, let's make a huge assumptive leap and say that's already done. You try to boot the device, and get an error about missing boot files. Huh? What's up?
Boot Sectors—Not Just for Breakfast
Back in the day when DOS was the game and we were all players, there was a little tool called SYS.COM. SYS.COM did a wondrous thing. It turned normally inert disks and diskettes (remember diskettes?) into magic wands, imbuing them with the ability to load and run the operating system. It was a necessary tool for creating boot disks back then, because your average run-of-the-mill formatted Elephant (remember Elephant 5 ¼" floppies?) couldn't boot on a bet. Why not?
Okay, ancient history: PC architecture specified that, when booting from a disk, it would read the first sector on the disk (track 0, sector 0, and in the case of hard disks, partition 0), load that sector into memory, and then start running whatever was there. The first sector on any disk is called a boot sector in honor of this architectural process. The boot sector code was very specific to the operating system being booted. In the case of DOS, the boot sector code read the files IO.SYS and MSDOS.SYS, and ran the code there. That code then read and processed CONFIG.SYS and AUTOEXEC.BAT, and started COMMAND.COM, the DOS command interpreter.
For Windows NT, new boot code was needed, so a new boot sector was created. This code read and processed the files ntldr, NTDETECT.COM, and boot.ini, which in turn loaded and ran the Windows NT system. These files and the boot sector code have been with us, with some changes and updates, since the early days of Windows NT.
I hear you—great, wonderful, fantastic, impressive command of meaningless history. Now, what does this have to do with the price of corn in Iowa or why my target device won't boot?
Simple. You don't have the right boot sector code. And I can also tell that you're running on a FAT16 or FAT32 partition as well. How do I know that? Because every partition formatted with NTFS already has a boot sector in it—it's part of the file system.
In short, if you build your target device on an NTFS boot volume (the system volume can be any file system), you should be able to boot your device with no worries. If you boot from a FAT partition, you need to put a boot sector on the machine. There are two ways to do this: ask Windows XP to create the boot sector for you using Disk Management (assuming you can mount the volume in Windows XP), or use BootPrep.
Those of you with Windows NT 4.0 Embedded experience will remember the NTBOOT disk we shipped. Basically, it was a DOS 5 boot disk with a little DEBUG script on it. That script would read raw data from the boot disk and blast it onto Track 0, Sector 0 of whatever was in the C: drive. This raw data was the Windows NT 4.0 boot sector code, and it enabled FAT volumes to be booted to Windows NT 4.0 Embedded.
Now that functionality is contained in the BootPrep tool, which is installed as part of the Windows XP Embedded tools, look for it in the \Program Files\Windows Embedded\utilities folder. You can get a listing of switches and options by typing "bootprep /?" at a command prompt. Some of the better features include being able to specify which disk to write to, where to get the boot sector data from, and files to backup whatever is already there.
Well, that's the basics of getting a runtime up and working. Next month, we go over embedded enabling features (EEF's).