Building a Reliable Windows XP Embedded Platform
Windows Embedded MVP
Microsoft® Windows® XP Embedded
This white paper is targeted at developers who are new to Microsoft® Windows® XP Embedded and who want to get a better understanding of how to build a reliable Windows XP Embedded image on their x86 client device. The paper is divided into four sections. The first section provides an overview of the Windows XP Embedded operating system (OS) explaining the origins of its inherent reliability. The second section suggests some software engineering design practices that can be adopted to improve the reliability of a Windows XP Embedded build. The third section provides tips for improving reliability at several steps of the Windows XP Embedded build process (See Figure 1 below). Finally, the fourth section outlines several handy test utilities that can play a role in quality assurance testing.
Windows XP Embedded Code Base
Both Windows XP Embedded and Windows XP are built on the same stable code base of Microsoft Windows NT® and Windows 2000. This code base offers a protected memory model and preemptive multitasking, both of which contribute to system stability. Starting from this proven code base, Windows XP Embedded is fundamentally reliable starting at the kernel level.
The difference between the Windows XP desktop operating system and the Windows XP Embedded operating system is that Windows XP Embedded is modularized into components. Understanding the componentization of Windows XP Embedded is the key to deploying a reliable Windows XP Embedded build.
The Windows XP Embedded Build Concept
The concept of a build is different for Windows XP Embedded than it is for embedded operating systems such as Windows CE .NET. With Windows XP Embedded, build means gathering the binary files, registry keys and other resources needed to support the functionality desired in the target device. For Windows CE .NET, build means actually recompiling and linking the OS and applications.
Developers can employ several software engineering design practices that can have a major impact on reliability.
A major advantage of Windows XP Embedded is that developers can use off-the-shelf x86 based hardware for their client devices. This convenience saves time and money. From a reliability standpoint, however, developers need to understand that device hardware is a key driver of device reliability. In the same vein, developers need to carefully choose third-party vendors providing other software drivers or applications. Developers should assess their vendors in five areas:
- Does the vendor hardware meet or exceed the target system requirements (that is, Intel Pentium II or higher CPU, ACPI PnP basic input/output system (BIOS) support, peripheral component interconnect (PCI) 2.0 or higher support, 5 MB of storage media, 64 MB of RAM)?
- Does the hardware vendor have a focus on quality? What is their quality process? Are they involved with Microsoft's Windows Hardware Quality Lab (WHQL) program?
- Do the software vendors warranty their software drivers or applications?
- Do the vendors offer responsive technical support?
- If a specialized piece of hardware or software has only one vendor and a technical issue arises, how responsive will the vendor be?
Following a development methodology that includes writing a software requirements document before starting indirectly contributes to the reliability of the final build. Building a Windows XP Embedded image is process of selecting and configuring components. For example, a requirements document that outlines how an end user will configure the target device will allow a developer to select the correct components to enable the correct features. A requirements document that outlines how the target device will be manufactured will assist a developer in configuring the Windows XP Embedded build to accommodate the production process.
Windows XP Embedded Technical Support
The Windows XP Embedded development tools, Embedded Studio, are easy to use but a developer will save time (and reduce late night hours) if he has a technical support network available. Microsoft supports a very strong developer community for Windows XP Embedded at this Microsoft Web site. Developers can take advantage of newsgroups, technical articles, knowledge base, and more at this site. In addition, Windows XP Embedded technical support packages can be purchased from many companies such as BSQUARE.
The Windows XP Embedded development process and tools are documented in detail on Microsoft's Web site. These steps are summarized in Figure 1 on page 1 as Analyze Hardware, Author Components, Configure Build, and Deploy Image. Rather than repeating the same information here, this section offers a specialized tip for each step that developers can use to ensure a more reliable Windows XP Embedded build.
Before Starting Tip #1: Load XP Pro and Applications
The best investment of time that a developer can make to ensure a reliable build is to initially install Windows XP Professional (the desktop operating system) on his x86 target device. Getting XP Professional and the specified applications installed and running provides a benchmark on the reliability of the hardware, drivers, and applications. This benchmarking exercise will allow a developer to eliminate the hardware, driver binaries and applications as possible sources of Windows XP Embedded build errors going forward.
Analyze Hardware Tip #2: Understanding Target Analyzer
Target Analyzer's two programs, Target Analyzer Pro (TAP.exe) and Target Analyzer (TA.exe), complement each other. TAP.exe is a Microsoft Win32® application that requires either Windows 2000 or Windows XP to be installed on the target device. If the developer cannot use TAP.exe, he has the option of running Target Analyzer (TA.exe), which runs in a DOS environment. TA.exe detects the presence only (as opposed to the presence and device) of ACPI, USB, 1394, SCSI, PCMCIA and ISA. In addition, TA.exe produces a best guess for the hardware abstraction layer (HAL) and does not detect software-enumerated devices. When using TA.exe, a developer may need additional sources for documenting the target device architecture.
Configure Build Tip #3: Saving Prototyping Time
Target Designer allows a developer to build an image of the operating system for testing purposes without licensing the operating system. The image is valid for between 90 and 180 days and then the image will "blue screen." If a development team has chosen Windows XP Embedded and is already developing prototypes for trade shows or for key customers, the team should consider using a product license. This will eliminate the need for an engineer to be called four months later to come into work on a weekend because the demo "blue screened."
Configure Build Tip #4: Visibility Settings in Target Designer
Target Designer allows a developer to set a visibility threshold that dictates whether a component will be visible during the configuration. The use of visibility levels reduces the number of components a developer must work with. Developers should be aware that when they are debugging a build and they think a component is missing, they should confirm its visibility setting.
Configure Build Tip #5: Dependency Checking in Target Designer
As a Windows XP Embedded build is configured, Target Designer continually examines long dependency chains. Each component has its own needs and dependencies. Target Designer automatically resolves dependency issues between components if the Auto-resolve dependencies check box is selected. The downside to this automation is that build may become larger than a developer wants without providing visibility into what components were added to satisfy dependencies. A developer needs to understand the tradeoff between speeding the build process and using Automated Dependency checking and minimizing the size of the image.
Deploy Image Tip #6: Using the System Cloning Tool
When a production image is being prepared that will be duplicated on multiple devices during a manufacturing process, a developer should include the System Cloning Tool Component. The cloning component is not required if each device undergoes the stand-alone First Boot Agent (FBA) process separately. However, the FBA process is time-consuming and not conducive to a manufacturing environment.
Several test utilities are available that can assist with Windows XP Embedded debugging. InCtrl5 from PC Magazine (http://www.pcmag.com) allows a developer to take a before and after snapshot of a system. FileMon is a free tool available that displays file system activity in real-time including what files a program uses including dynamic-link libraries (DLLs) and configuration files. RegMon, also available at Sysinternals (http://www.sysinternals.com), displays which applications are accessing registries. Microsoft offers dependency walker utilities in its Platform SDK, which aids a developer in ensuring that all of the required DLLs are included for an application or driver.
This white paper has reviewed four areas that a developer can focus on to ensure a more reliable Windows XP Embedded build. These include understanding the origins of Windows XP Embedded, using solid software engineering design practices, starting a project by getting Windows XP Professional running on a target device and other build tips to increase reliability, and incorporating testing using several handy test utilities into the development process. Hopefully, developers new to Windows XP Embedded can find some advice among these topics that will reduce their Windows XP Embedded learning curve and help them get a reliable product to market sooner.