Basic Componentization


Microsoft Corporation

March 2009


This technical article contains information about basic componentization in Windows Embedded Standard.


Types of Components

Structure of a Component

Creating a Macro Components

Creating a Basic Shell Component



Components are the building blocks of the whole Windows Embedded Standard 2009 product. By breaking up Windows features into one or more components, you can add only those features that are needed in an operating system image. This provides more customization of the Windows operating system. A component details the files, registry keys, and other resources that make up a Windows feature or functionality.

Types of Components

There are several different kinds of components that can be found in the database:

  • Feature components
    These are components that make up each Windows feature, such as Internet Explorer, Terminal Services, TCP/IP, and Telephony. Each feature can consist of one or more components.
  • Driver components
    These are components for each driver that is included with Windows XP Pro SP3. These are by far the most numerous type of component.
  • Macro components
    Macro components represent groupings of other, related components. Macro components are displayed in bold in Target Designer. Macro components can be used to group the following kinds of components:
    • Multiple components that make up a Windows feature
      The Internet Explorer Technologies is an example of this type of macro component.
    • Components with related functionality
      TCP/IP Networking With File Sharing and Client for MS Networks is an example of this type of macro component.
    • Multiple Windows features
      These are features that are most common to a device category or purpose, such as the Design Templates in Target Designer (for example, Thin Client) or the macros used in testing and troubleshooting (for example, the Shell Application Compatibility macro).
    • Components that make up application prerequisites
      These are required for a specific application to be installed (for example, the Microsoft SQL Express 2005 macro).
  • Custom components
    These are components that are created by the user in Component Designer for their third-party driver or application.

Structure of a Component

Components are created by using Component Designer and are saved in an XML file that has the extension .sld. Components are only one of the objects that can be in an SLD file, others include repositories, repository sets, dependencies, and packages. The information in the .sld file is metadata that describes the properties of the different objects. This information is written to the various tables in the embedded database when an .sld file is imported into the database using Database Manager.

This section will focus on the structure of component objects. Components contain the following resources:

  • Group memberships
    Used for categorizing the component in Target Designer.
  • Files
    Details the files that make up the feature and where these should be bin placed on the run-time image.
  • Registry Data
    Lists the registry keys and values to be written for the feature.
  • Component or Group Dependency
    Lists the other components that this component has a dependency on. These dependent components own files that this feature requires to be included in the final run-time image to function correctly. Target Designer uses this information to add these dependent components to a configuration during a Dependency Check.
  • Build Order Dependency
    In rare cases a component may require another component to be built before it in Target Designer, during the Build phase. This means that the files and registry keys of the component that the current component has a Build Order Dependency on must be in the image before the files or registry keys of the current component are added.
  • Resources
    Custom actions that run during the setup (FBA) phase of the OS image. These include the following:
    • Component Branch
      Used only when a component is "end-of-life" because it is superseded by a newer version of a component.
    • PnP Device ID
      Adds PnP ID for a driver to the registry.
    • Service Data
      Adds service information to the run-time image.
    • RunOnce Request
      The RunOnce request lets the user set a Run, RunOnce or RunOnceEx command that runs after FBA finishes.
    • FBA Generic Command
      Executes a generic command during the FBA process, such as calling an application or executing a script. This is one of the most frequently used FBA commands.
    • FBA DLL/Com Registration
      Used for registering DLL and COM objects that use Regsrv32.exe. If all the registry keys for the application are already listed as Registry Data resources in the component, then you do not have to register DLLs (which would write that same information to the registry). Not registering DLLs during setup (FBA) also reduces the time setup takes to complete.
    • FBA OC Mgr Request
      Sets a command to be processed by the Optional Component Manager.
    • Shortcut
      Creates a shortcut link for an application.

Other properties that can also be set in a component are as follows:

  • Display name and description
  • Author, Owner, Vendor, and Copyright information
  • Association with a repository object
    This indicates where the physical files for this component are. Every component that has file resources must be associated with a repository. Usually custom components are associated with their own repository object that is created by the author in the same .sld as the component.
  • A membership on a prototype
    This will enable this component to inherit the properties of a prototype component (such as Codepage Prototype or File System Prototype).
  • Visibility
    This is usually a number between 50 and 1000, and Target Designer reads this value when it determines what components to make visible in its component browser pane.
  • Pointers to the Help text file for custom components
    If the author includes Help information for his custom component, it is displayed on right-click of the component in Target Designer. This is no longer used in the components that are included with the database by default because it is replaced by the Help documentation that is included in the product’s .chm files.
  • Pointers to DHTML and script files
    These are files that are typically used to configure different settings for some features offline (for example, the home page in Internet Explorer). The scripts specify what registry keys to write when the component is built in Target Designer so that you do not have to configure these settings after the run-time image is deployed.

Several other properties, listed as check boxes in the Component Properties pane, are available but are rarely used:

  • Component instances are editable
    This specifies whether an instance of this component will be editable in Target Designer after it is added to a configuration.
  • Enable multiple instances
    There is rarely a need for more than one instance of a component in a configuration. An example of where this would be desirable is the User Account component that can be added for each user.
  • Opaque
    Checking this box will hide all the component resources from view.

The Macro component check box is used frequently. If this is selected, the component name will change to bold text and you will be unable to add any resources to the component other than Component Dependencies. This is because, as we have stated, macro components are merely a collection of other components.

All components have two GUIDS that identify them, a VSGUID and a VIGUID. These are visible in Component Designer if you click the Advanced button in Component Properties. Each new component is assigned a new VIGUID. This does not change if the component is copied or updated. This enables components to be updated to a newer version and be upgraded in a configuration. The VSGUID does change when a component is updated, as each change represents a new instance of the component.

Also visible in the Advanced properties, in both Component Designer and Target Designer, are the properties that make up the configurable settings for the feature, if any are specified through the component scripts and DHTML.

Creating a Macro Components

One of the first steps in building an image is to run the Target Analyzer utility to analyze the drivers and peripherals on your target device hardware, and then use that output (.pmq) as the basis for your configuration. Importing this .pmq file into Component Designer will automatically create a macro component.

You will see that this component only has Component Dependencies on all the driver components that were identified as being part of your target device hardware. To make this macro more useful you can add functionality that will enable the components in your macro to be selectable.

To do this:

  • Add a membership on a prototype by clicking the Browse button next to the Prototype text box in the Component Properties pane.
  • Locate the Selector Prototype component and select the one with the highest revision number (Rxxxx).
  • Click OK.

Save the .sld file, import it into the database, and search for it in Target Designer to add to a configuration. As soon as it is added, click Settings node. You will see the driver components listed, each with a check box that you can select or clear, to add or not add that component to the configuration.

Creating a Basic Shell Component

Shell components are a useful way to provide a specific appearance and behavior to the device, or as a security tool that restricts the user to only those functionalities and applications exposed by a shell. Different shells can be exposed, depending on the permission level of the user logging in. Frequently, the line-of-business application is used as the shell. This section will step through the basics of creating a shell component that starts an application (in this instance Notepad.exe).

  • In Component Designer create a new .sld and a new component.
  • Give your component a name and description.
  • Add a membership on the latest version of the Shell Prototype component (in the same manner you added a prototype membership in the macro component). This means that the custom component will inherit all the properties of a shell.
  • Add a Group Membership on the Shell category (Software\System\User Interface\Shells) in order to make searching for your custom component easier in Target Designer.
  • The most important step is to add the application that you want to be the shell for your device.
    To do this:
    • Click the Advanced button in the Component Properties pane.
    • Click Add in the Advanced Properties.
    • In the Extended Properties dialog give the property a name (such as MyShell).
    • Enter the path and name of your application in the Value field (such as %SystemRoot\Notepad.exe).
    • Save the .sld file.

Of course, the application and all its dependencies must exist on the run-time image for this shell component to work. That means that the application should already be part of a component that is already added to the configuration when the shell component is added. With a third-party application this would have to be componentized in its own custom component, imported into the database, and added to the configuration. In this example with Notepad, we make sure that the component that owns Notepad.exe (Windows Accessories) is included in the configuration. We can manually add this component, or we can make sure that the component is added automatically together with the shell component by including a Component or Group Dependency resource for the Windows Accessories component in our shell component.

The basic technique of creating any component is very simple. However, the overall process of turning an application into a component and to make sure all its files and dependencies are present in the run-time image can be complex and is covered in more advanced topics.


What you have learned

By using the information in this article, you should now have a better understanding of Windows Embedded Standard componentization.