Windows XP Embedded Architecture Basics
Jon Fincher
Microsoft Corporation
December 18, 2001
Welcome back to the Microsoft® Windows® XP Embedded portion of our column. We celebrated the release of Windows XP Embedded at Devcon in Las Vegas at the end of November, and the excitement over the product was very visible. All our talks were full (in fact, some were overcrowded SRO affairs), and the hands-on tutorials were equally popular. I had the chance to talk to and work with a lot of our customers, and I was impressed with the number and level of questions I was asked. Thanks to everyone who attended for a great event!
Before we get started, let me clarify one minor point: the picture on the main Columns page is of my comrade Mike Hall (on the left) and me. A number of people at Devcon recognized my face, but assumed I was Steve Maillet, since Steve and Mike wrote the first article. As a result, I now answer not only to my name, but to the name "Not Steve."
In our last article, I promised a look at the Windows XP Embedded architecture, walking through a normal build process to point out the whys and wherefores. The architecture of Windows XP Embedded is a complicated beast, too long for any one article. Instead, I'll focus on the architecture behind the individual tools in a structured manner. First, however, I need to describe a part of the tools that is usually never seen or heard from—the CMI.
The CMI: The Heart of the Matter
As you already know from my last article (as well as all the press), Windows XP Embedded uses a SQL-based database to hold all components. This database can be a local or remote Microsoft® SQL Server installation, or a local Microsoft® Data Engine (MSDE) installation (which is provided on the Windows XP Embedded CD). In contrast, Windows NT Embedded 4.0 used a single local Jet database .mdb file to hold all components and configurations.
In order to seamlessly provide access to both local and remote databases from one set of tools, as well as provide for switching databases on the fly, a database communications layer was called for in the overall architecture. This layer is called the CMI, or Component Management Interface. Its primary purpose in life is to provide a standard interface between the Windows XP Embedded tools (Target Designer, Component Designer, and Component Database Manager) and the component database, wherever it resides (local or remote, SQL Server or MSDE). If it's related to anything in the component database, the CMI will be involved.
Since all the tools rely on an active database connection to do any useful work, the first thing any of the tools do is to ask the CMI to provide an active database connection. If no database connection is possible, the CMI returns a failure and the tool reports an error. In short, there is no way to do any meaningful work in Windows XP Embedded without a database connection.
The CMI also provides for some level of asynchronous database access, which is highly likely with a remote SQL Server database and multiple clients. All operations involving database changes are fully transacted in SQL, providing rollback capabilities in the event of a failed operation. The CMI also distinguishes between Read-Only and Exclusive access modes. If any tool wants to delete information from the database (currently only Component Database Manager), it first needs Exclusive access, and it can't get that if any tool has the database open. On the flip side, if Exclusive access is granted, no other tool can gain access to the database until Exclusive access is released.
Here an Object, There an Object
**Note **The following discussion uses two terms that are easily confused—component and instance. Simply put, a component is only a set of resources and properties that resides in the database. When a component is added to a configuration, it is called an instance, and can then be modified, acted upon, and built. Think of the component as the cookie pattern, and the instance as the actual cookie created from the pattern—you can't easily change the cookie cutter pattern, but you can do what you wish to the cookie once it's cut. This distinction between a component and an instance is important to keep straight, as you'll see in this and future articles.
Because the CMI is a COM server for the tools, it enforces one of the basics of the Windows XP Embedded architecture—everything is an object. Configurations, components, instances, resources, files, registry entries, repositories—they're all objects under the hood. Because of this, the Windows XP Embedded architecture embodies the three principles of the object-orientation (OO) philosophy: encapsulation, inheritance, and polymorphism. While we won't discuss the finer points of OO design, some explanation of these points in relation to Windows XP Embedded architecture is called for. We'll concentrate on components for this discussion, but the concepts extend to all Windows XP Embedded objects.
Each Windows XP Embedded object is a self-contained unit. Components carry with them their own properties and internal code, thus encapsulating them and keeping them separate from other objects.
Components can also inherit properties from other components. As an example, let's hypothesize a set of devices all based on the same chipset—let's say it's a sound card driver, using the fictitious SoundExplosion 1A chipset. You have three sound cards that use this chipset, but expose other functionality—one with a game port, one with a MIDI port, and one with a SCSI interface. Rather than author three components that are all fundamentally the same with some minor changes to accommodate the differences, you author one component that encapsulates the basic functionality. You then author three components for the three variations, listing the base functionality component as the "prototype." The three components will then inherit the properties and resources associated with the prototype, but also add their own resources.
Polymorphism in Windows XP Embedded objects is usually handled with DHTML configuration and build script. DHTML configuration script allows end-users of the component to dynamically set properties in the component instance. These properties can then be inspected and reacted to in build script. This allows you to change the behavior of your components during configuration build time to suit the needs of your developer end-users.
This last part brings up a further consequence of the object orientation provided by the CMI: Each object in Windows XP Embedded carries with it a set of properties and methods, and some objects can even react to events. The properties can be classified as Standard (such as Component Name, Component Author, and Copyright) and Advanced (cmiNoHelpFiles is a common Advanced property for components). The methods of an object may be simply inherited from the Base Component (for example, basic building behavior), but can also be specific to the component (such as the User Interface Core component, which contains DHTML configuration script, as well as build script, to implement different UI features). Events are fired during the build process and can be reacted to by component script.
Certain Advanced properties are predefined for you. The most common for components are cmiNoHelpFiles (used by build script to remove Help files from the build), cmiLangEnableMUI (used by build script to enable Multilingual User Interface [MUI] support for your component), and cmiProtPropList (used by Target Designer to protect predefined properties). You can inspect the advanced properties of a component by adding the component to a configuration in Target Designer, clicking on the component in Configuration Editor, and clicking Advanced.
Extending the Object Model
The object characteristics and CMI intervention of Windows XP Embedded aren't limited to components and instances. Configurations are also handled as objects by the CMI. Standard properties for configurations include the name of the configuration, owner and author, and copyright. Advanced configuration properties include settings for the target boot drive, boot ARC path, and help file inclusion. These properties can be inspected in Target Designer by selecting the configuration name in Configuration Editor, then clicking Advanced in the Details pane.
Just as components and instances are objects, so are their constituent parts. Every file, registry, or other resource in a component is an object with its own set of properties. You can inspect those properties in Configuration Editor by expanding the instance, then the Files, Registry Data, or Resources item. Right-clicking on the desired resource in the details pane will show the standard resource properties, while the Advanced button will display, oddly enough, the advanced properties. This also works for Extra Files, Extra Registry Data, and Extra Resources associated with the configuration. And to complete the picture, every group, package, repository, and repository set is also treated as an object, with their own set of Standard and Advanced properties.
CMI in Action
Let's presume we have an application we want to include in a run-time image. The normal procedure for doing so would be to author a component for the application, import the component into the database, include the component in a configuration, then build the run-time image. Let's see where CMI interacts in this process. (I'll be going over component authoring in depth in the next two articles, so we'll be blowing through here a little quickly).
When you start Component Designer, the CMI first makes sure it has a database connection. The act of creating a new component directs the CMI to create a new component object. Component Designer then uses that object as the storage location for all the component information you define. The basic authoring process includes defining the name of the component, specifying which files to copy and where to put them in the run-time image, and specifying which registry keys to use and where to put them. The name is a Standard component property, and so is included in the Component object. The files and registry entries you specify are objects that the CMI creates and attaches to the component object.
When you're ready to import your component, start Component Database Manager. Its first job is to call the CMI to connect to the database you specified during install. If the CMI can do that, you'll be allowed to import SLDs into the database. (SLD stands for Source Level Definition, and is pronounced "slide." It's the output of Component Designer.) Again, all Component Database Manager does is to pass the SLD on to the CMI for processing. Browsing the database, deleting packages and components, and inspecting object properties are all handled by the CMI, with CDM acting as the UI for the underlying COM object layer.
When you're finally ready to build your run-time image, the CMI verifies the database connection again. (See a pattern here?) Creating a new configuration relies on the CMI to create the object, as does populating the Component Browser. Adding a component to the configuration requires that the CMI first create an instance based on the selected component, and then attach it to the open configuration. Resource objects are also created for the file, registry, and other resources of the instance. During the dependency check, the CMI is responsible for identifying dependencies and creating the component lists required for dependency resolution. During the build, the CMI is called upon to access the actual files to copy, as well as to provide detailed property information to handle build ordering.
Summary—and a Look Ahead
We've gotten a brief introduction to the underlying architecture of Windows XP Embedded. The CMI is the heart of this architecture, implementing a COM server to provide standard access for the Windows XP Embedded tools to access the component database. The CMI also enforces the object-oriented nature of the architecture, creating objects for everything needed through the run-time development cycle.
So, where do we go from here? Well, this was hardly an exhaustive overview of the Windows XP Embedded architecture. I hope it helped to lay some foundation for our future articles, which will examine each tool and the architecture decisions that are evident (and not so evident) in the UI for each. As we discuss each tool (the next two articles are planned to be on Component Designer), we'll try to give the complete picture from UI to underlying architecture. As always, keep an eye on the Windows XP Embedded Web site at https://microsoft.com/windows/embedded/xp/default.asp for new developments. Until January, happy holidays, and I'll see you in the newsgroups.
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.