[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.]
It is one of the classic problems in an embedded project: After the successful boot process of the device and the OS one or more applications need to be started to do something useful on the device. This can get complex, because one might have applications that need to be started only once, some need to run all the time, but only in a certain user context and some should be running even when no user is logged on, to name just a few examples.
There are several times when you may be challenged with a broken application, including:
If the application does not launch at all, mostly the cause would be a missing binary dependency which could be found with Dependency Walker's static analysis. There are times when some of the functionality within an application is broken. This is often due to the missing binary dependencies which can be a dynamic dependency or a delay loaded dependency.
Windows Embedded Standard 2011 provides a tool called Image Configuration Editor (ICE) to help developers configure the components to be installed on the run time image. The configuration is stored in XML file format and is called an answer file.
Before creating an answer file, you should gather the hardware configuration of the target device by running TAP.EXE. This will generate a PMQ file. For instructions on how to generate a PMQ file, please refer to the “How to Generate a .PMQ File Using Target Analyzer” section in ICE Help.
Let us go through how to create a simple answer file that represents the configuration to be installed on the run time image.
* Update 9/23 – added pictures
During the course of our development of Windows Embedded Standard 2011, we realized that our embedded customers have slightly different needs than Windows Client customers with regard to how devices are serviced. For instance, embedded devices can have very limited disk space, while desktop computers can have hundreds of gigabytes of free space. Embedded devices are often not connected to the internet, while most home and office computers are.
Differences like these can affect the way devices are serviced dramatically, so our team created Package Scanner to help service embedded devices more easily.
By now, hopefully you’ve read Part 1 of this article series, which introduced you to IBW and its basic concepts.
In this article, we’ll be going slightly deeper to try out the more advanced route in IBW.