Windows Embedded Compact
Posted By David Campbell
Program Manager
Welcome to the “new and improved” :) Windows Embedded Compact blog! This is part of our new, consolidated Approaching Embedded Intelligently blog effort to provide updated content, consolidate existing content, feature guest bloggers and, most importantly, provide a common place to get updated information.
As a quick introduction, I’m David Campbell; I’m a Program Manager (PM) on the Windows Embedded Compact team. I’ve been involved with Windows Embedded Compact/Windows CE since Windows CE 1.0 as a PM. Over the years I’ve been responsible for a variety of technologies, and most recently I’ve been driving the overall releases.
The Windows Embedded Compact team’s mission has evolved over the years, but a large portion of our mission and goals remain the same. We continue to provide a Microsoft OS solution for high volume, small footprint, real-time devices. An OS that is stable & reliable, with a long support cycle and ideal for high availability devices. Windows Embedded Compact fits into Microsoft’s overall offerings with its APIs and tools aligning with Windows to provide a familiar development experience right out of the box.
There have been a number of great bloggers for Compact over the years and I encourage you to read them, including Olivier Bloch , Sue Loh , Steve Maillet , Mike Hall , and Doug Boling to name a few. While some of our bloggers haven’t posted in a while, much of the information remains relevant; this is a testament to the stability and longevity of the Compact product. It also shows how dispersed the information is, which is something we’ll try to improve with these articles.
If you’re reading this, I’m sure you’re pretty familiar with Windows Embedded Compact so I’ll keep the intro short and just point to some resources with more information about Compact and Windows Embedded’s vision and roadmap. I also encourage you to review our websites for Compact and Windows Embedded to learn more.
To kick things off, I’m privileged to have a guest blogger writing about a key topic for anyone working on a small footprint device – keeping the footprint small. ;) This particular article is a synopsis from one of Doug Boling’s recent webcasts , which I’d encourage you to check out. I’ll be sure to keep you informed about upcoming webcasts and events related to Compact.
As many of you know, Doug has been working for many years with Compact and Windows Embedded CE. He is an author, trainer and consultant specializing in Windows Embedded Compact and CE. He has been presenting a series of webcasts over the last 6 months. The latest one was on reducing image size. Now, on to Doug …
Optimizing Image Size in Windows Embedded Compact 7
Windows Embedded Compact is an unusually flexible system allowing OEMs to add and remove components from the core operating system as well as some of the peripheral components such as Internet Explorer for Embedded and .NET Compact Framework. This flexibility allows OEMs to create fairly small images although most don’t. The question is why?
In general, image size isn’t a problem… -until it is. The trigger is almost always the image exceeding the size of the available flash or occasionally, the need for a faster boot time. There are other reasons for shrinking the image however. Smaller images are more stable, since the smaller amount of code reduces the opportunity for bugs. In addition, a smaller system has a smaller exposure surface for security attacks.
There is a cost of shrinking the image. Shrinking the image takes engineering time. It’s simply too easy for a developer to create an image that uses the default selection of components. And, as the application developers make requests for increased features, the platform developer tends to add components without questioning why.
Smaller images also can sacrifice application compatibly. As components are removed from an image, the application programming interface (API) is modified to remove the function calls associated with that component. This is why Platform Builder can export an SDK from the current configuration. The SDK will only contain function definitions and linker information for the APIs supported in that specific build. Applications built to a different SDK can easily fail to load if they link to an API that doesn’t exist in the current build.
Still, if the image is too big for the hardware, there really isn’t a choice other than to reduce the size of the image. Fortunately, Microsoft has provided plenty of tools to help with the task.
A trivial method for reducing the image size is to pick a CPU architecture with a higher ‘code density’. This refers to the size of the machine code generated by the compiler for a given task. This isn’t just the efficiency of the compiler, the design of the CPU’s opcode set also matters. For example the x86 CPU architecture uses a byte-aligned opcode set which is more compact than the word and double word aligned opcodes used by the ARM architecture. As a result, the ARM code is approximately 1.2 to 1.5 times the size of the same code compiled for an x86 system.
One thing that has brought the image size issue to the forefront is the increase in average image size for Windows Embedded Compact 7 images vs. Windows Embedded CE 6 images. Some of this growth is due to increased function such as in the crypto-APIs. However, other areas of the growth are due to increased dependencies of some of the more popular components. For example, the Explorer shell now has dependencies on some components for Internet Explorer. Active Sync now brings in components such as the Embedded Database. Because of this, developers need to be very careful in the components they choose for their WEC 7 images. Below is a short list of some of the larger components:
| Flash | 6.1 Meg |
| Internet Explorer for Embedded | 5.3 Meg |
| Silverlight for Embedded | 4.5 Meg |
| .NET Compact Framework 3.5 | 2.6 Meg |
| SQL Compact | 2.5 Meg |
In addition to those components, there are a number of components that have a fairly large footprint that can be accidentally included if you happen to include a component that depends on them. For example, the Embedded Database component was introduced a few versions ago. The EDB provides more features than the original CE Database component but at the cost of a significant increase in footprint. While the CE Database engine is part of the standard file system component, the Embedded Database depends on the SQL Compact engine that is 496 KB in size. Many popular components such as ActiveSync, Media Library, POOM and Windows Music Player depend on the EDB.
Fortunately, Platform Builder provides a fairly easy way to track what is in a build and what caused a particular component to be included. Figure 1 below shows the Platform Builder catalog window.
Figure 1. The Platform Builder Catalog Window
As shown in the figure above, items explicitly included because either they were part of the initial configuration or because the developer selected them are marked with a check mark. Items brought into the build because another included component depends on them have a solid square in the check box.
Right clicking on an item in the catalog will display a context menu that allows the developer to learn why an item is included. The dialog that is displayed is shown below.
Figure 2. The dependency dialog in Platform Builder
Another way a component can be added is through the Board Support Package CEBASECESYSGEN.BAT file located in the root of the BSP directory. This file allows the BSP to set and clear SYSGEN_xxx environment variables that drive the componentization process. Using this BAT file should be avoided at all costs as it breaks the independence between the operating system configuration and the board support package. Unfortunately, some silicon vendors use this file to force components into a demonstration build because their drivers are written to utilize those components. I’m of the opinion that the BSP ought to detect that those components are not present and auto-configure to not build the dependent drivers. Regardless of the motive, be sure to verify that the CEBASECESYSGEN.BAT file is not including any unwanted components. If a design needs components they should be included by the project configuration, not the BSP.
Knowing what files are in a build can be the first step in understanding what needs to be removed. Platform Builder can be used to open a .BIN file such as NK.BIN to view the files in the image as well as the contents of the default registry. When using this feature, be sure to open the .BIN file as a ‘file’ and not as a ‘Project’. Opening a .BIN file as a Project results in PB attempting to download that file to the target hardware.
To see why a particular file was included, open the CE.BIB file in the release directory. There will be CESYSGEN_xxx tags around the line adding the file. That tag will point to the component the file belongs to. In addition, the file COREDLL_COMMON.DEF in the \wince700\private\winceos\coreos\core\dll directory contains the list of functions exported from coredll. This file is parsed by the sysgen process and therefore also contains the SYSGEN_xxx tags that can point to the component that supports those functions. There are other DLLs, such as winsock.dll and ws2.dll that also export operating system functions, but COREDLL is by far the largest and most important.
While it is all well and good to shrink an image to as small as possible, developers must be aware of the possibility of creating an operating system image that is incompatible with the software for the device. When developing applications, be sure to provide the application developers with up-to-date Software Development Kits (SDKs) created from the current image componentization. It is critical to use a matching SDK so that developers will get feedback at compile time as to the availability of specific APIs.
There are solutions to the image size problem other than simply shrinking the image. If the reason for the image reduction is to reduce boot times, another solution would be to divide the image into multiple .BIN files with the basic NK.BIN only containing the basic operating system and driver files. Other files could be provided on a mountable file system or in a separate .BIN file loaded with the BINFS file system. This speeds boot time by having the bootloader only read the smaller NK.BIN into memory before launching the operating system.
If the reason is that debug builds won’t fit into the system, a standard solution is to mix debug and retail modules together. Under this scenario, a standard retail image is used with selected debug components for the area that is currently being debugged. Windows Embedded Compact also includes a ‘checked’ build that contains all the debugging messages and memory heap checking of a debug build but optimizes the code like a retail build. Checked builds are only a bit larger than retail builds. Check builds are new to Windows Embedded Compact and are a very welcome addition.
To fight image bloat, its best to avoid including the Explorer shell or the Active Sync components. These components are quite handy for debugging but are typically not necessary for a finished product. They are large and tend to depend on an even larger set of additional components. It’s also good to review the catalog, item by item to see what is being included and why; doing this can reveal unnecessary components that can be removed painlessly. Just be sure to provide the revised SDK to the application developers to keep them on the same page as the OS team. Good luck.
I’d like to thank Doug for his great insights and I look forward to future webcasts and blog entries. You can learn more about Doug by visiting his website at www.bolingconsulting.com . Here are the details for Doug’s next webinar, check it out.
When: Tuesday May 15, 2012 from 9:00 AM - 10:00 AM PT
Title: Maximizing the Capabilities of Internet Explorer For Embedded in Windows Embedded Compact 7
Overview: An often overlooked feature of Windows Embedded Compact 7 is the extensive capabilities and configurability of Internet Explorer For Embedded. Our version of IE has changeable “chrome” to fit in almost any user interface. As on the Desktop, our version of IE can be embedded into applications as a control. Updated to support some of the latest HTML standards, Internet Explorer For Embedded is a power tool that can be used to create great user interfaces. Learn more about Internet Explorer For Embedded in this month’s webcast.
Registration link: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032511331&Culture=en-US
Link for previous webinar recordings: https://www.microsoft.com/windowsembedded/en-us/develop/windows-embedded-compact-7-developer-classroom.aspx
-David