Image Configuration Strategies
[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.]
If one is building just a single device, it is certainly not necessary to think about configuration strategies. However, when the device gets rolled out in different versions or if your device is part of a device family, a well designed configuration strategy can help overcome versioning obstacles and save a lot of time.
Separate hardware and software
The simplest image configuration strategy is to separate the hardware and software related parts of the Windows Embedded Standard image. Ideally this is done with the help of macro components. In this case there would be one macro component containing components such as generated by TA/TAP and drivers. All other components, which are not related to accessing hardware, should be placed in a software macro component.
This approach is especially beneficial if you want to have the same image infrastructure configuration across different hardware boards requiring different drivers and HALs.
The dream of a global embedded image
Just a minute – one could say, why not instead create an “Über-Image” that contains all available drivers and HALs? It would be slightly larger than a standalone one, but this would be no problem from a footprint standpoint if you think of the price of storage today. The benefits of maintaining a single image would easily outweigh this footprint drawback.
HAL – the lonesome component
Well, “Über-Images” are possible, but only if all targeted devices support the same HAL. There cannot be more than a single HAL in an image configuration. In reality it is a lucky accident if all target devices support the same HAL. And even then, there is a good chance that a new round of HW evolution will break this. Therefore, having different HW macros for different systems cannot be avoided in most cases.It is also common that different boards require completely different drivers and therefore HAL and drivers can be grouped together in their own macro component.
Drivers, apart from the HAL, on the other hand, should not pose any problems if you do decide to keep all an “Uber-image” that contains them. During FBA the Plug and Play process installs only the required drivers from the offerings available in the raw image. Surplus drivers stay on the disk, but are not installed into the run-time.
Grouping software components
If you take the simple approach described above for drivers, namely creating an “Uber-Image” for software, you would be left with one monolithic software macro component. If a device family gets more sophisticated, there might be the need to take a more flexible approach, as well. The software macro component could be broken e.g. in a component containing OS facilities and one containing the application or applications.
This idea could be further developed by encapsulating certain functionality or application blocks. Quite often macro components Microsoft already has built can be reused for certain infrastructure parts such as networking, multimedia, WMI, Active Directory, Group Policies, etc.
To find an ideal approach certainly is not easy, and is also directly related to an OEM’s device requirements. The resulting custom functionality macros should also not be too granular, because maintaining them could become quite some work over time, as well.
Selector Prototype Component
A way to add more flexibility to a custom macro component is to add a membership to the Selector Prototype Component, which generates a list of the component dependencies that can be selected or de-selected during image configuration in Target Designer. This enables OS developers to choose which components of this macro to include in a configuration-specific way. When creating the macro component in Component Designer, the Selector Prototype Component can be configured in the components meta-data.
The component is located in the Software\Test & Development node of the catalog. There are more components available in the node, but only the one with the highest version number should be chosen. The reason for this is that outdated components are not deleted from the database, to enable the building of older image configurations if necessary.
If the Selector prototype has been added in a macro, continue to add the component dependency resources you need in the macro as for any other macro component Afterwards import the component into the database.
If a macro component with a membership on the Selector Prototype component is added to an image configuration in Target Designer, included components are shown in a select list similar to the one below (select list implemented by the WMI macro component):
Divide and conquer
With a meaningful segmentation of functionality, and flexible macro components, even complex device family scenarios can be handled. The skill here is to set the right level of functionality boundaries to offer proper choices when device requirements are considered, while having not too many macros to maintain.
In addition, component configuration files (SLDs) should be stored in a source code repository to enable better collaboration, handling and versioning.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009