Getting to Know Windows NT Embedded and Windows XP Embedded
Jon Fincher
Microsoft Corporation
November 20, 2001
Welcome to the Microsoft® Windows® XP Embedded portion of our Get Embedded column. We're hoping you will become as jazzed on our NT- and XP- based embedded technologies as we are, as we get into a great line up of articles. To start off, I'll cover some of the history and the future direction of these tools. In upcoming articles, we'll dive into much more technical depth. Naturally, we'll be passing along some tips and tricks along the way, so if there's anything specific you want to hear about, or questions you want answered, pass them on—we'd love to hear them. OK, moving on…
What We Will Cover
As Mike and Steve said in the last article, there are three main Microsoft embedded operating systems, with Windows CE, Windows NT Embedded, and Windows XP Embedded being the most visible. I'll be handling Windows NT Embedded and Windows XP Embedded in this column, leaving the inner workings of Windows CE to my learned friend, Mike Hall, from across the Pond (the Atlantic Ocean, that is), and his compatriot, Steve Maillet.
Application development for Windows NT Embedded and Windows XP Embedded will not be covered, but as we'll see in upcoming columns, this isn't a problem—application development for these requires no magic incantation, no secret handshakes, and no arcane maneuvers (I promise!). You write applications for the Windows NT or Windows XP platform, and (with a little repackaging) they work in the embedded world.
Now, for a quick review of how we got here...
A Brief History of Windows XP Embedded
Windows NT Embedded 4.0 got its start in 1998 with a small team of developers at Microsoft. This project, known within Microsoft as Impala, was released in 1999 as what we now call Windows NT Embedded 4.0—a set of tools and a database of approximately 250 components that allowed developers to put together small Windows NT 4.0 run-time images for embedded devices. The tools allowed OEM's and embedded developers to create components encapsulating their binaries, and to add them seamlessly into Windows NT Embedded runtimes containing limited functionality and devices. Minimum run-time images were as small as 9 MB for a system featuring the full Win32 API.
Shortly after release, the team set their sights on the next version. A decision was made to bypass Windows 2000, and go right to a Windows XP Embedded product (then called Whistler). Plans were drawn up, the team was expanded, and work started on Whistler Embedded, codenamed Mantis (no, not the bug; rather, a very fast, very voracious salt-water shrimp). The component count has risen from 250 to over 10,000—most of them device-driver components. The feature set of the embedded tools was enriched to include things like basic version control, component scripting, and expandability. Tools were also added to make it easier to start with a blank slab of hardware and to deploy an embedded OS on it quickly and easily. On August 26, 2001, Beta 2 of Windows XP Embedded was released, with a full release planned for later that year.
What's New in Windows XP Embedded
If you're at all familiar with Windows NT Embedded, you'll be very pleased with the new features of Windows XP Embedded. Here's an overview:
Architecture
There's a completely new architecture underlying Windows XP Embedded. Where Windows NT Embedded used a simple Jet database to store both components and configurations, Windows XP Embedded uses Microsoft® SQL Server to store its data. Configurations are no longer part of the database, but are separate files that can be archived and shared between users. Components are still authored as separate files and imported into the database, but the process of importing has sped up immensely.
Some other features of the new architecture include:
Object Model. The heart of the new architecture is the CMI, or Component Management Interface. This COM object sits on every machine running our tools, managing the interface between tools and database. It also exposes a rich object model to be used by the tools for dependency checking, component management, and runtime building.
Component Versioning. Each component you create has version and revision information in it, which allows you to update components in the database and selectively upgrade them in configurations. Simple version control mechanisms like end-of-life and branching are taken care of as well.
Separation of Tools and Database. You can install and maintain a Windows XP Embedded database on a completely separate server on your network, rather than have it reside on the same machine as your tools. This lets you maintain one central source of components and updates for everyone in your organization to use. You can even maintain multiple databases for your company to use, switching between them as needed.
Standard Use of XML. Every file created by the tools is written in standard XML format, using custom-made Document Type Definitions (DTDs) to provide data validation. Using an industry standard data storage format allows us flexibility.
Scripting. All components in Windows XP Embedded can be scripted, using the standard Microsoft® VBScript language. Your script can interact with the underlying object model for the configuration, respond to events, and take actions as necessary.
Configurability. Every component can also carry configuration DHTML, which allows you to set properties and tailor the action of your component in its configuration. Examples of this include specifying page file sizes, video settings, TCP/IP addresses, and user interface elements you want present on the system.
Standard and Advanced Properties. Every object in our new architecture carries a standard set of properties, as well as a customizable and expandable set of advanced properties. You can use DHTML to provide a convenient UI to change properties, and then react to those properties in your component script.
Tools
Your old friends, Target Designer and Component Designer, are still here, but they've been completely rewritten to take advantage of the new architecture. Both tools interface with the database to provide up-to-the-minute accuracy when defining configuration or component dependencies. To top it off, they also write industry standard XML files, making their use quick and easy. More feature enhancements include customizable standard and advanced properties for every object, release- and debug-specific build options, per-component repositories, database filtering, macro components, and more.
Component Database Manager (CDBM) is where everything starts to come together. By providing one dedicated interface to the database, we've turned CDBM into a one-stop shop for everything related to the database—from importing components to managing repositories, you'll find everything you need to maintain and interact with the database.
One of the biggest challenges confronting Windows NT Embedded developers was finding out what components they needed to add to make their systems work properly. That problem has been solved by Target Analyzer, which is actually two tools in one. The first part, the Target Analyzer Probe, discovers and reports the hardware in your system, creating a standard XML output file. The second part of the tool, the Target Analyzer Importer, is present in Target Designer and Component Designer to allow you to create components or configurations that include all the hardware the probe found.
We've also included a number of standard design templates in our database—components containing everything you need to create a point-of-sale system, gaming consoles, information appliances, and home gateways (to name a few). Couple a design template with a hardware component created by the Target Analyzer Importer, and you've got a full Windows XP Embedded runtime using only two components!
As I mentioned before, we won't talk about application programming here, because we don't need to—Windows XP Embedded uses the exact same files as Windows XP, which means we're 100% compatible. You're application will run on Windows XP Embedded just as it does on Windows XP, without modification, recompilation, or hesitation. And if you don't need the full Win32 API for your application, no problem—we can create a kernel-only image that resides in about 4 MB of RAM.
For your custom hardware builders who want to include your newest driver in a runtime, don't worry, as importing isn't limited to just target-analyzer generated files. We also have the facilities to import INF files, so you can componentize your drivers without having to manually create everything.
There are also many other utilities we've created to make life a little easier on our developers. From BootPrep (to aid in preparing Windows XP bootable media) to SDI (which provides a file-based disk image to test and deploy on), there are a host of tools we'll talk about in future articles.
And in case you thought we might have forgotten, we still have the embedded enabling features we had in Windows NT Embedded, including El Torito (booting from a CD-ROM), support for Compact Flash and DiskOnChip, Enhanced Write Filter(to support El Torito volumes and to protect system volumes), remote administration, and headless support.
Help
A lot of time and effort has gone into the help system for the new tools and architecture. Every tool has extensive help available that provides ample information on the tool and feature requested. A complete system design guide accompanies the context-sensitive help system to provide more in-depth coverage of key concepts and procedures. And to top it off, separate training materials are being developed to provide more hands-on training for our customers.
How Does Windows NT Embedded and Windows XP Embedded Compare to Windows CE?
Windows NT Embedded, Windows XP Embedded, and Windows CE .NET are all part of the same Windows Embedded family of products, but are aimed at different hardware sets.
Windows CE is very well adapted for non-x86 platforms, including the Pocket PC platform. It has a very small footprint, although the smaller the footprint gets, the less functionality available. It supports many different processors and architecture types, but carries with it a need to recompile the entire OS for each different machine it will run on.
Windows NT Embedded has a much larger initial footprint, and includes the full Win32 API. It is aimed at bigger and more robust embedded devices, such as printers, copiers, PBXs, industrial controls, routers, and so on. The driver model for Windows NT Embedded is very mature, although the drivers that ship in the box are rather limited. Windows NT Embedded doesn't support newer technologies, like USB, Plug and Play, ACPI, or 1394 (FireWire).
Windows XP Embedded expands on Windows NT Embedded with a set of basic footprints (kernel mode, Win32 limited, and Win32 Full), and a set of design templates, including information appliances, digital set-top boxes for video, point-of-sales systems, Windows-based terminal thin-clients, and home Internet gateways. It includes the full Windows XP driver set, the same mature development model, as well as all of the latest features we've come to expect from a Microsoft operating system.
All of these embedded operating systems work together to provide cohesive embedded solutions across the embedded space for our customers.
The Future
In our next article, we'll discuss the Windows XP Embedded architecture by walking through a normal build cycle, pointing out the whys and wherefores along the way. After that, we'll go through the process a little more slowly. We'll continue by looking at Component Designer, picking apart its function by examining a Windows XP Embedded component in detail.
Next, we'll tackle Component Database Manager, as we import our newly created component, and find out where it all goes. Target Designer comes next, as we bring all our previous work together to create a working runtime. We'll discuss the different embedded enabling features that are available, and when and how to use them.
We'll also examine the other tools, as we make a bootable target device with our new runtime—as well as touch upon some troubleshooting steps and testing hints for your new Windows XP Embedded device. And throughout the whole process, I'll be answering your questions and introducing you to new features, updates, and news as I get it. I'm hoping you'll stick around for a year's worth of information.
Get Embedded
A native New Englander, Jon Fincher worked as a UNIX System Administrator and database programmer before joining Microsoft Product Support Services in 1995. In 1999 he started supporting Windows NT Embedded 4.0, and is now a Software Test Engineer for Windows XP Embedded. He can be seen year round, in all weather, riding his Harley to and from work and play.