TECHNOLOGY IN SYSTEMS
CE Goes Multicore: Microsoft Windows Embedded Compact 7
The latest version of Microsoft’s Windows Embedded CE operating system provides significant improvements in the area of networking, user interface and the base kernel.
BY DOUGLAS BOLING, BOLING CONSULTING
Page 1 of 1
Microsoft sells two operating systems tailored to the embedded community, confusingly named Windows Embedded Standard 7 and Windows Embedded Compact 7. Windows Embedded Standard 7 (WES), or just Standard 7, is a repackaged Windows 7 operating system described elsewhere in this magazine by my colleague Sean Liming. Windows Embedded Compact 7, or Compact 7, is a purpose-built operating system designed for mobile and embedded systems. Yes, Microsoft guidelines specify the addition of “7” to the end of the name of each operating system. Apparently, “7” is the new “.NET”.
Compact 7 differs from Standard 7 in its CPU independence, as it supports ARM and MIPS, as well as x86 architectures. In addition, hardware requirements differ. Where WES 7 requires a “WinTel” compatible PC motherboard, Compact 7 simply needs a supported CPU type, some RAM, a place to store the OS, a real time-clock and a periodic interrupt for the scheduler. All other hardware decisions are left to the OEM.
Of course, Windows Embedded Compact 7 is significantly smaller than Windows Embedded Standard 7. Componentization, the ability to pick and choose various OS components to include in a build, can dramatically shrink the image size. A small “update image” of Compact 7 that contains the kernel, file system and communication stack is easily under 1 Mbyte on an x86 system. Fleshing out the OS with a GUI, shell and various basic subsystems increases that to perhaps 4 Mbyte. Of course, adding everything provided by Microsoft can balloon an image to over 20 Mbyte if that’s what is needed.
As with all previous versions, Compact 7 is accompanied by the Platform Builder 7 tool set. Platform Builder is an integrated development environment that allows componentization of the OS, the compilation of drivers and applications, and the downloading and debugging of the OS image. Improvements in Platform Builder 7 are centered on a new suite of tools used with Silverlight for Embedded.
The improvements to Compact 7 start with a rewritten kernel. Compact 7 is the first of the Windows CE line to support symmetric multiprocessing. The kernel has been written to support up to 250 cores although it runs best with eight cores or fewer. Still, the ability to run across multiple cores dramatically increases the responsiveness of the system, especially under conditions where a thread is under load.
To ensure that older applications run correctly under Compact 7, applications compiled to Windows CE 6 and before will have all their threads run on the same core. This prevents any untested thread timing problems from being exposed by the multicore kernel. Applications compiled to Compact 7 will have their threads distributed across all the available cores.
New API calls have been added to manage the multiple cores. Applications can set a thread’s affinity to a specific core, or all threads to a specific core. In addition, developers can power down cores (with the exception of the primary core) of the CPU to save power. All interrupts are handled by the primary core of the CPU.
Windows Embedded Compact 7 also has improvements in memory management. Previous versions of Windows CE supported up to 512 Megabytes of physical RAM. Additional RAM available on the system could be used as an I/O buffer, but was not managed by the kernel. Compact 7 increases the maximum supported physical RAM to 3 Gigabytes. Individual processes are still limited to the virtual space available within that process, but the increase removes a significant point of pain for complex systems where large amounts of RAM are required for image processing or data caching. This RAM is a welcome improvement that finally mirrors the improvements to the process virtual space that were made in Embedded CE 6.
Compact 7 also has a redesigned heap manager for applications. The new heap manager design reduces fragmentation by dividing the heap into various arenas designated for commonly sized allocations. Embedded applications by their nature tend to run for a long time, making them especially susceptible to fragmentation-based memory loss. This bucket-based approach was used for kernel heaps in CE 6 and now is used by the application heaps in Compact 7.
On the security front, Compact 7 adds two features that have been brought down from the Windows desktop operating system. The first of these is Address Space Randomization or ASR. ASR is a feature of the module loader in the kernel that randomizes the load address of the Dynamic Link Libraries (DLL) as they are loaded by various processes. The goal of ASR is to make it more difficult for malicious software to guess the location of code within the address space of a process. ASR is especially useful in embedded systems that—unlike desktop systems—typically boot the same software in the same sequence. In my experience with earlier versions of Windows Embedded CE, the load address of DLLs was very predictable under most conditions. ASR randomizes the load address within the 512 Mbyte range allocated to user mode DLLs. Sure, it would be possible to search for various code patterns to locate a specific DLL, but ASR does make it a bit more difficult for the hacker.
Another security feature of Embedded Compact is Data Execution Prevention (DEP), which is similar to execution prevention features on other operating systems. It flags data pages so that code cannot be executed from those pages. DEP is an optional feature that can be enabled with a simple build switch in Platform Builder. Unfortunately, DEP is only supported on Embedded Compact systems running on ARM 7 architectures.
Silverlight for Embedded
If I were to point to one feature of Windows Embedded Compact 7 that separates it from other full-featured embedded operating systems it would be Silverlight for Windows Embedded, or SWE. Silverlight is Microsoft’s cross-platform, Web development environment available on Windows desktop, Windows server and OS X operating systems among others.
Silverlight for Embedded takes the power of the Silverlight presentation engine and adapts it to the embedded market. SWE has the same Extensible Application Markup Language (XAML) user interface description language, but the “code behind it” is implemented in C++ running natively on the device. This combination of a rich design language along with native code that can directly access the hardware and is not subject to .NET “garbage collection” pauses, is ideal for creating the rich user interfaces that many modern embedded devices demand.
The key to SWE is the Silverlight rendering engine. This graphical front end essentially replaces the classing Windows GDI/User user interface API with a new class-based API that provides control and event handling back to the C++ business logic. The class library mimics the C# class library of standard Silverlight, easing the transition for Silverlight developers and providing a lifeline for embedded developers who can utilize the significant amount of literature discussing Silverlight development.
One of the features of Silverlight and SWE is the ability to bridge the gap between user interface designers and developers who write the business logic code in the core of the application. The tool used by user interface designers for Silverlight is Microsoft’s Expression Blend. Blend is a WISIWIG tool that enables designers to create elaborate user interface designs. Blend works with standard Microsoft solution files so projects created with Blend work with Visual Studio and vice versa. While it can be used as the sole tool for Silverlight development, Blend is typically used in conjunction with Visual Studio. For SWE, Blend is used with Platform Builder where the Blend-generated XAML is integrated with the C++ back-end code compiled by Platform Builder.
In Figure 1, a trivial user interface of four buttons was created using Expression Blend. The buttons are skewed and some are rotated and flipped. Each of the buttons is fully functional and could be filled with images instead of, or along with, text.
A simple user interface of four buttons created with Expression Blend.
The XAML generated by Blend for the interface above is shown in Code Example 1. Each of the buttons is described within a Grid control. The transforms that manipulate each of the buttons can be seen within the button declarations.
Code Example 1
The power of XAML is that the Grid and Buttons declared in the XAML describe classes that are also accessible programmatically through properties of the classes. For example, the first button class named “Btn1” causes the Silverlight runtime to create an instance of a button class named Btn1. The application can access the properties such as FontSize, Width and many others not initialized in the XAML declaration while the application is running.
Another powerful feature of SWE is the concept of Storyboards. Storyboards are predefined animations that can be run during application execution. Instead of having the C++ code provide the heavy lifting of manipulating the screen elements, the Silverlight rendering engine can directly play a storyboard that describes the animation. Storyboards are typically created in Blend using a timeline style animation creator.
Code Example 2 is the code for the event handler that is fired for clicking on Button 1. In the handler, a storyboard is played with a handful of calls.
Code Example 2
The click handler is auto generated by the tool that imports the Blend project into Platform Builder. The only code added was that needed to find and start the storyboard named “RotateButtons.”
Silverlight for Embedded is packaged as another Embedded Compact component that can be added during the operating system generation process in Platform Builder. Adding the SWE component doesn’t preclude applications using the standard Win32 graphics and windowing APIs. Traditional Windows CE applications can run side by side with SWE applications.
In addition, SWE applications can host conventionally built GDI-based controls in the XAML user interface. This is convenient for two reasons. First, systems that need unique custom controls that aren’t supported in SWE can be built using standard Win32 APIs and incorporated into the SWE application. Second, supporting custom controls that were built in legacy systems eases the upgrade path for OEMs wanting to leverage the user interface “bling” of Silverlight for Embedded.
Complementing the complex user interfaces created by Silverlight for Embedded, Compact 7 supports a Gesture API. This API supports single and multi-touch gestures including touch, drag, pinch and pan. The OS-provided controls can be set to recognize gestures if desired. In addition, a physics engine is provided to help with those springy, bouncy actions that users now expect.
Compact 7 has improved various parts of the communication infrastructure as well. The operating system contains a new communications infrastructure including a new WinSock stack ported from the desktop. This new stack has improved security and extensibility compared to the communication stacks in previous versions.
A new version of Internet Explorer dubbed “Internet Explorer Embedded” has also been added. This version of IE is based on the desktop IE 7 code base with selected performance improvements from IE 8 back ported into the rendering engine. IE for Embedded also includes new pan/zoom support that was added for Windows Phone’s version of IE.
The development tools for Windows Embedded Compact 7 have evolved as well with the latest edition. Platform Builder 7 now is an add-in to Visual Studio 2008 instead of VS 05 that was used for CE 6. While some may wonder why PB doesn’t use Visual Studio 2010 instead, the add-in interface for the newer Visual Studio was different enough that the effort to go to that IDE was deemed not worth any gains.
While essentially identical to the feature set of Platform Builder 6, the new version does add one or two items that are worth noting. First is the addition of “Checked” builds. Platform Builder has always supported two build types, “Debug” and “Retail.” Debug builds turn off compiler optimizations, enable numerous asserts, add arena checking for heap allocations and various other debug related features. Retail builds disable all those debug checks and enable compiler optimizations. As one might expect, Debug builds are significantly larger, up to 40% larger than Retail builds. This size difference frequently caused problems for systems with limited RAM and storage. Checked builds enable compiler optimizations while also enabling the various debug checks such as arena checking and asserts. Checked builds are therefore smaller than debug builds while retaining the useful debug checking. For those not familiar with Windows Compact, the debugger can attach to any of the (now) three build types.
Platform Builder 7 also includes improved compilers that take advantage of the newer ARM architectures. Code produced by the new compilers is both smaller and faster than the code produced by the compilers in Platform Builder 6.
The testing suite, now dubbed the “Compact Test Kit,” has been upgraded for Compact 7. This new suite has an significantly upgraded PC-based front end that can sequence tests and collect results while testing a remotely attached Compact 7 device.
The new features of Windows Embedded Compact 7 will be welcomed by experienced users of Windows Embedded CE. In addition, the upgraded kernel and the new Silverlight for Embedded feature set may just attract more than a few new developers to the OS. Check out Windows Embedded Compact 7. Despite the confusing name, it’s a powerful embedded OS.