Using Compatibility Macros
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
OS developers that have been using XP Embedded from the very early beginnings may remember the times when it was quite a challenge to reproduce standard XP Professional behavior for certain functionality in an embedded image. Of course, it always has been possible because the desktop as well as the embedded OS are have always used exactly the same binaries, but at times it was not always clear which components were needed to get the desired result in an embedded configuration. Since then, we have come a long way and fortunately the Windows Embedded team kept up the great work to improve this experience by adding so-called compatibility macros. A lot of them can be found in the Software\Test & Development folder of the component database.
Macros, or macro components, are components that do not contain any binaries, resources or registry keys themselves. Instead, a macro can be thought of as a container for a group of “real” OS components. A macro component just contains dependencies on these other components, which are then pulled into an image configuration during dependency. Macro components are always displayed in bold type and therefore easy to recognize. The components included in a macro normally do contain binaries and settings, but it is also possible to include a dependency from one macro on another, building a tree hierarchy.
Windows Embedded Standard provides developers these compatibility macro components as configuration templates that describe dedicated blocks of OS functionality. A very good example for this is the Networking Application Compatibility macro component, which pulls in the infrastructure required to achieve the best networking compatibility for an embedded image.
Compatibility macros “really” try to make the overall functional area that they are targeting (like networking) work in an image, which in many scenarios means including a lot of components. This is not always desirable for an embedded device because of image footprint. At the same time all the components may not be required by the applications running on the device. Due to this, it is a best practice to disable some of the offered features, once it is established that they are not needed, via the settings dialog of the component. Not all compatibility macros offer this configurable option. For example, in the networking macro shown above, it is perfectly fine to disable Client Services for Netware, the IPX/SPX protocol or Message queuing components, if the applications that run on the device do not leverage this infrastructure. By systematically doing this, significant footprint reductions can be achieved.
It is important that the removal of components from a macro component should take place before dependency check is run. It is not possible to delete components from the configuration by un-checking them in the compatibility macro later. In this case, these components need to be deleted manually. The reason for this behavior is that components may be referenced by more than one component. Therefore a single (in this case macro-) component deleting a dependent component would break the dependencies for any other dependent component in the image.
Here is a closer look at some important compatibility macros:
Class Installer / Hardware Compatibility
Pulls in all class installers required for Plug and Play. This provides support for images with rich functionality, or it can be used to troubleshoot images when drivers and peripherals are not detected by Target Analyzer.
Enterprise Features
Brings in enterprise functionality such as Active Directory support, WSUS, Smartcard support, etc. and can be used by any embedded device that participates in a corporate network, such as thin client scenarios.
Networking Application Compatibility
A very helpful component to integrate network applications, but needs to be treated with caution. It pulls in all available network functionality including IIS, TAPI, Message Queuing and much more, leading to high footprint as well as a lot of unwanted functionality in the image.
Multimedia Application Compatibility
Should be treated as “pick and choose”, as well. It includes only Windows Media Player 6.4! If higher versions of WMP are desired, they need to be added to the image manually.
Shell Application compatibility
This macro can be used to achieve the same look and feel running explorer shell as with XP Pro. Recommended for images that need to have similar application compatibility capability as Windows XP Professional.
Windows Application Compatibility
Takes care that most of the common application APIs are included into the image. Again, pick and choose the required ones, to keep footprint as well as attack surface (security!) low.
Windows Management Instrumentation
This is a very important infrastructure macro for configuration and maintenance tasks: A must for images with rich functionality.
There are a lot more of these components including macros for SQL Server version, Virtual PC, SCCM Advanced client, etc.. Just check them out!Compatibility macro components are great companions to get a system / application running and to achieve fast as well as robust results.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009