Smart ways to create components
[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.]
Componentizing drivers or applications is always a challenge in a Windows Embedded Standard 2009 project. In some cases components are created easily with the help of the import function in Component Designer, which enables the import of the hardware detection result file (.pmq) from Target Analyzer, setup information files (.inf) used for driver installations or registry export files (.reg) created by Regedit.exe.
In these cases creating components is quite straightforward and absolutely recommended to automate the build of the system as much as possible.
Unfortunately there are a lot of occasions where this technique cannot be applied, e.g. because the drivers come as a self-contained packages, not exposing the .inf file, or because large application setups are not well documented regarding the required infrastructure and system changes they make.
Componentize only if it is reasonable!
In this situation one should step back and think whether the componentization of the targeted functionality under the given circumstances makes sense.
Applications, for example, can be a real pain to componentize, as applications are updated by developers quite often. This creates the need to change the component to include updates every now and then, as well. If an application is large, this additional effort can really be significant. Therefore, it is a good approach in a first attempt, to concentrate on the “low hanging fruit” by just componentizing all “importable” drivers or applications and to introduce a manual setup phase for the rest of the required functionality. This helps to focus on early results during OS development and avoids spending costly work cycles on things that are too complex.
And in the end, for the final operating system image, it does not make a difference if a driver has been installed during FBA or manually! The only impact a manual installation phase may have for smaller images is, that the overall footprint is increased a bit by including required infrastructure, e.g. Windows Installer Service, to accomplish manual installation tasks.
Use a manual phase for image tuning / installation
In nearly all embedded projects one can find a manual phase of fine-tuning before sealing the image, either to install functionalities that are not easily componentized, or to do tweaks and settings that change often and therefore are hard to automate. This should not be seen as a drawback, because in most cases a manual phase gives the OS developer the flexibility to react quickly to constantly changing project requirements.
Using silent setups
In the case where complete componentization is not desirable, there is a workaround that still allows you to create automated builds: silent setups. Often installation routines provide an additional command line switch to run unattended and this can be leveraged to generate a component containing the silent setup for the application or driver. The procedure is similar to the creation of a real component, but uses the FBA Generic Command additional resource:
Create a new component definition
- Add the silent setup files (e.g. setup.exe and any accompanying files)
- Create the corresponding repository
- Add an FBA Generic command entry
- Configure the Generic Command as shown below.
In the Resource Editor the FilePath property takes the complete path to the installation executable, for example “c:\MySilentApp\Setup.exe”. Any command line switches that are required are specified in the Arguments property, e.g. “/quiet”. The FBA Generic Command is executed during FBA at the FBA Phase specified by the Phase property.
It should be set higher than 8500, because after this phase the build of the underlying OS is already completed, so any infrastructure required for the silent setup is available.
Post-FBA installations
FBA is not the only location to hook in automated installation packages. Another way would be to prepare batch files to execute silent setups, as required, manually or triggered by a RunOnceRequest issued during FBA starting such an installation batch.
Advanced Techniques
Did you know that .MSI files are editable? They are not the closed up, secret packages they may appear to be. Microsoft provides an editor called Orca in the Server 2003 SDK, which can be leveraged to change entries manipulate settings inside of the .msi file. This can be helpful to transform a verbose installation into a silent one. Needless to say that you can do some harm editing a setup package, so keep an original copy in a safe place.
If one does not want to dive this deep into the inner workings of a setup package, there are tools such as Wise Installation Studio which are able to repackage existing setups, even those that do not provide a silent switch to work unattended.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009,Embedded