Mobilize

Explore The New Features In Windows Embedded CE 6.0

Paul Yao

This article is based on a prerelease version of Windows Embedded CE 6.0. All information herein is subject to change.

Contents

Overview of Windows Embedded CE 6.0
API Deployment Scheme
Kernel-Mode Operation
Memory Architecture
Device Emulator
Cell Technologies for CE 6.0
Location-Based Programming
Security Enhancements
Development Tools
Cool Tools
Registry File Editor
Runtime Image Viewer
Shared Source and Windows CE Development
Conclusion

The first version of Windows CE shipped in 1996. Since then, many new types of portable and embedded products have emerged-enabled by myriad advances in semiconductor components. In 1994, worldwide semiconductor sales hit the $100 billion mark, according to the Semiconductor Industry Association (SIA), and that number is expected to hit $250 billion for 2006. Along the way, the Windows® CE team has kept its fingers on the pulse of developers working in the embedded space, pushing the boundaries in each generation.

Overview of Windows Embedded CE 6.0

For each of its previous five versions, Windows CE has served as the foundation for a wide range of embedded devices. The newest version, Windows Embedded CE 6.0, continues the push forward, providing a whole new set of features-some of which you need to understand, and others you may just want to be aware of. (See the sidebar "Inside Embedded Innovation at Microsoft".)

Inside Embedded Innovation at Microsoft

The process of conceiving, planning, developing, and delivering a new version of a successful product is a huge undertaking—especially when that product is an operating system, albeit a small one. In the case of Windows CE, it involves a development team with upwards of 700 individuals. When planning new features, Microsoft solicits customer feedback in several ways. The best known feedback mechanism is the beta software program, whereby prerelease software is shipped to customers. But beta programs are not the only way to get input. The design and planning phases are bolstered with customer visits and design reviews to inject customer insights into the product development process.

At the start of the product planning process, the Windows CE planning team hits the road to visit customers around the world to learn about their current and anticipated product development needs. These visits occur shortly after the previous product version ships, because innovation is an ongoing process. On the basis of these visits, a draft development plan is created and reviewed internally.

With a draft development plan in place, the next step involves validating the plan at a design review where hundreds of people from outside Microsoft gather to provide input. I participated in a design review in June of 2005 for the CE 6.0 plan. This week-long event started with participants signing non-disclosure agreements (NDA) to facilitate open and honest discussion on both sides. The actual mechanics of a design review are pretty interesting. Major feature areas are first described by members of a development team. Each presentation ends with a question and answer period, and each participant uses a wireless voting box that was provided at registration. Immediately after each vote, the results are displayed for everyone to view and discuss.

By the end of the week, each participant may have provided hundreds of opinions on how the development team should set priorities. The value of the exercise can best be measured by the new insights that development teams have gotten when they put their tough questions in front of customers who are relying on the presence of some feature in a future product version.

The specific features of interest to you will depend on the type of gadgets you are working with. If you're a designer of headless industrial controllers, it's likely you have a different set of needs from a software developer creating the next generation of sewing machine applications. Both are likely to define what's interesting in ways that might not make sense to a developer of mobile phone applications. You get the point.

While Windows CE is the foundation for many types of gadgets, you often get the impression that it's split into two camps: Windows Mobile®-powered devices and custom embedded devices (in other words, everything else). But can one platform support both standard and custom devices? Yes, Windows Mobile and custom embedded devices are linked by a vast technology portfolio that includes a small but capable multithreaded kernel, a rich family of programming APIs-Win32, MFC, and the .NET Compact Framework-and a powerful, extensible set of development tools.

Windows Embedded CE 6.0 (CE 6.0) introduces a new kernel that overcomes limitations of earlier kernels, while squeezing more performance out of those tiny CPUs. In this article I'll describe the new CE 6.0 operating system capabilities beginning with those that pertain to the new kernel: a new API deployment scheme, new use of kernel mode, and the memory architecture. I'll then cover other new features of CE 6.0.

Finally, I'll go over the new tools for configuring, building, and testing the myriad Windows CE configurations. The discussion of tools is aimed squarely at developers of embedded applications who create custom Windows CE configurations. But if you're a Windows Mobile developer and are tempted to skip this second half, I urge you to keep reading, paying special attention to the discussion of Windows CE shared source. It's a mandatory resource for anyone who wants the inside scoop on Windows CE that only the source code can provide.

API Deployment Scheme

One of the strengths of Windows CE is that its development benefitted from the features and optimizations of the desktop versions of Windows. Starting with the first version of Windows CE and including every version up to Windows CE 5.0, the Win32® APIs were deployed using client/server architecture similar to that found in early versions of Windows NT®.

In Windows NT 3.5, for example, all GUI functions reside in a single process: csrss.exe, the client-server runtime subsystem. When functions like CreateWindow or TextOut are called, the CSRSS process is triggered through an interprocess communication mechanism called local-procedure calls (LPCs). Owing to performance penalties of so many context switches between the heavyweight Windows NT processes, this architecture was formally abandoned in Windows NT 4.0 (released in 1996). At the time, all the formerly user-mode API libraries were transferred into kernel mode.

A similar change is taking place with the release of Windows Embedded CE 6.0. For all previous versions, Windows CE also used a client/server mechanism to connect a caller to the target Win32 function. There are similarities, but it is important to note the differences between the Windows CE implementation and the one on Windows NT. One difference is that Windows CE used a much more lightweight process than Windows NT, and so the performance cost was not as high. Unlike Windows NT, Windows CE was designed to be configurable. And the use of processes to deploy system APIs allowed the demands for ROM and RAM to be gated by how much of the overall operating system was needed for a specific device. For example, a device could be configured to run with just one API process, the system kernel (nk.exe). Other devices that need GUI support would also need to run the GUI (gwes.exe) process.

Although the new model does provide some performance improvements, the real motivating factor for making the change is to remove limitations that could bottleneck development on the next generation of devices. Those limitations, which are well known to Windows CE programmers, include the limit on total number of processes (32), and the small virtual address space (32MB) of previous generations of Windows CE kernels.

Many things have changed in the decade since the first kernel was deployed. Devices today can have more capable hardware: faster CPUs, more storage, a color LCD display screen, and so on. Today's designs don't need the tiny memory footprint of yesterday's models, and so a redesign was in order. With CE 6.0, system APIs are moved out of their own user-mode processes and are placed into kernel-mode DLLs instead. Figure 1 summarizes the changes between Windows CE 5.0 and CE 6.0.

Figure 1 Changes to Major Modules in Windows Embedded CE 6.0

While this reorganization of the operating system was underway, another important change was made: OEM code was separated from operating system code. Previously, a hardware designer created a low-level set of routines called the OEM Adaptation Layer (OAL), and that component was statically linked to the operating system kernel. The OAL and the kernel appeared as a single executable, nk.exe. In CE 6.0, these two components are now built into two separate modules: the kernel (kernel.dll) and the OEM Adaptation Layer (nk.exe).

Kernel-Mode Operation

To run Windows CE, a CPU must support two privilege levels. The higher privilege level is referred to as kernel mode; the lower privilege level is known as user mode. Any memory that is allocated for either code or data is assigned to one of these two modes. Putting code in user mode helps the overall environment run more robustly and more securely. However, these benefits are not free, because mixing user-mode and kernel-mode code is generally slower than running the system entirely in kernel mode.

In previous versions, Windows CE could be configured for all kernel-mode operation, or for mixed-mode operation using both kernel mode and user mode. With CE 6.0, only the mixed operating mode is supported with all applications being loaded into user-mode memory, and all OS components loaded into kernel-mode memory. As shown in Figure 2, some components have both a user-mode and a kernel-mode incarnation. This deployment helps minimize the cost of calling across the privilege boundary, at the expense of a larger operating system image.

Figure 2 User-Mode and Kernel-Mode System Libraries

Memory Architecture

The new kernel brings a completely new memory architecture that eliminates the previous limits on available processes and address space size. Previous kernels supported a maximum of 32 processes, each of which occupied its own process slot. CE 6.0 raises the limit on the number of processes to 32K. (This is a theoretical maximum, based on a limit on the storage of kernel handles. CE 6.0 can accommodate a maximum of 64K kernel handles, and a process requires a minimum of two handles-one for the process itself, and one for the process's thread. The practical maximum is lower because other types of kernel objects occupy space in the kernel handle table.)

Prior to CE 6.0, each Windows CE process had a 32MB virtual memory address space. With CE 6.0, each process has a 2GB address space. In addition to having a larger address space, the structure of process address spaces is different. Prior to CE 6.0, a single virtual address space was divided into the 32 slots, with no overlap between process address spaces. With CE 6.0, each process gets its own, truly private process address space. This change makes the CE 6.0 process address space appear very similar to the process address space in desktop versions of Windows (such as Windows XP).

No doubt you're wondering what impact the new memory architecture will have on existing software. Generally speaking, most changes are limited to device drivers. While the size of the process address space is much larger, well-behaved applications shouldn't notice, since memory is allocated using the same allocation APIs, and data is still stored using 32-bit virtual memory pointers. The new memory architecture does make some things easier, particularly for applications that needed to allocate very large blocks of memory-greater than 10MB, for example-such as might be needed to hold a high-resolution image read in from a digital camera sensor. Previously the need for large data blocks had to be satisfied by allocating with the shared memory allocation functions (MapViewOfFile, for example). Starting with CE 6.0, large allocations can just as easily be satisfied with a call to VirtualAlloc.

Aside from the increase in size of the process address space, the other change introduced with this memory architecture is the truly private process address space. Prior to CE 6.0, it was generally quite easy for one process to look into the address space of another process. In the now defunct slotted address scheme, the currently running process is mapped into slot zero. This was done by fixing up all pointers to reference memory in the range of zero to 32MB. By calling a function like MapPtrProcess, the currently running process can take a pointer from another process and access that memory directly in the process slot (in the range 32MB-64MB for slot 1, 64MB-96MB for slot 2, and so forth). With the implementation of a private process address space, no application process can look into the address space of any other application process. Instead, you will need to use the standard Win32 shared memory APIs to enable two processes to read and write to the same memory.

One reason that this new architecture is likely to have the biggest impact on device drivers is that existing Windows CE device drivers often use functions like MapPtrProcess to read or write directly in an application's address space. In CE 6.0, drivers that still need to access data in an application's address space need to run in kernel mode. This is accomplished by linking to the appropriate set of kernel libraries (k.coredll.dll) instead of their user-mode counterparts.

In some cases, it might be necessary for a device driver to run in user mode instead of in kernel mode. For example, there might be a driver for which you don't want to grant full kernel mode privileges. Such a driver can be run in CE 6.0 through the use of a user-mode device driver process-udevice.exe.

Now let's take a look at some of new features that are available with CE 6.0. Some are developer tool enhancements, while others are new features that you can include in custom embedded devices that you create.

Device Emulator

Many stories told by science fiction authors describe machines that behave like humans. And yet, stories are seldom written to extol the glory of machines that mimic other machines. Isn't there something miraculous about a desktop system being able to simulate the behavior of a mobile phone?

Such impersonation is actually nothing new. In fact, it is almost as old as computers themselves. In the 1960s, the then-new IBM 360 could emulate its predecessor, the IBM 1401. In the 1970s, a DEC-10 emulated a MITS Altair to debug the first Microsoft BASIC interpreter. Today, of course, there's the Microsoft Virtual PC, where emulation becomes virtualization.

Windows CE has seen three generations of emulators. The first supported Windows CE by directly calling the roughly equivalent Windows NT functions. It was a good first start, but left much to be desired. The second generation emerged as a custom embedded platform using hardware virtualization, running the same low-level instructions as a real device. It was a very capable emulator, but had a drawback for developers who were focused on deploying to non-x86 processors since it was built using the I86 instruction set. A third-generation emulator, which ships with CE 6.0, provides instruction-level emulation of the ARM V4I instruction set. This emulator ships with the CE 6.0 Platform Builder as the Device Emulator.

This newest generation supports the ARM V4I instruction set. While the x86 instruction set dominates on the desktop, it has not made the same inroads in the embedded world. That honor belongs to the instruction sets designed and licensed by ARM Holdings, Ltd. of the UK. The benefit of emulation at the machine instruction set level is binary compatibility. Instead of building the x86 executable files for the emulator and a second set of ARM executables for actual devices, you can create a single set of binaries and run them both. In addition to being more convenient, it also enables a higher degree of testing confidence because you test everywhere with the same executables without worrying about errors in your setup scripts, or compiler or linker bugs.

Cell Technologies for CE 6.0

To enable machine-to-machine communication, CE 6.0 includes the interfaces needed to connect to mobile phone networks. Previously, Windows CE did not provide support for making phone calls and sending SMS (text) messages. With CE 6.0, Microsoft has made available a select set of the components for connecting to mobile phone networks.

CE 6.0 provides cellcore.dll, which extends the Win32 API to support a variety of mobile phone services such as initiating a data connection, sending an SMS message, and so on. Another key component provided with CE 6.0 is ril.dll, the driver for the Radio Interface Layer (RIL). This component provides the low-level interface for connecting an application layer to the mobile phone hardware. Previously, to build a mobile phone on Windows CE, you had to develop your own interface layer. This is not an easy thing to do, but something that a few stalwart pioneers have done.

Among the other supporting elements in CE 6.0 are the low-level components for the Wireless Application Protocol (WAP), including a kernel-mode driver (wapdrv.dll) and a user-mode API (wap.dll). You should note that the browsers provided with CE 6.0 do not support WAP browsing, but instead are HTML-only browsers. The Pocket Internet Explorer® that ships on Windows Mobile-powered devices (which does support WAP) is different from the HTML-only version that ships with CE 6.0.

To enable the creation of such wireless data terminals, there is rich support for SMS messaging. This is important because the mobile phone network uses SMS to send notifications for services like voice mail, fax, and e-mail. And so CE 6.0 provides a rich set of SMS service providers to enable the receipt of SMS broadcast messages, notification messages, and status messages.

Location-Based Programming

Before computers became mobile, there was little interest in figuring out the computer's location. Once delivered to its air-conditioned vault, a mainframe computer never needed to figure out where it was. With today's pocket-size systems and onboard automobile computers, the subject of location is suddenly much more interesting.

Microsoft introduced support for Global Positioning System (GPS) APIs with Windows Mobile 5.0. Those same APIs, and the drivers to support them, are now available with CE 6.0.

Security Enhancements

A major theme of the past few years has been finding ways to improve security of all computer systems. Security is one of the main themes of Windows Vista™, after all. And the CE 6.0 team has also made security an important aspect of their work.

Before discussing improvements that have been made with CE 6.0, it's worth pointing out the security features that already exist in Windows CE. The centerpiece of Windows CE security is provided by the ability for a Windows CE-powered device to maintain tight control over which applications and DLLs are allowed to load and run. Through the OEMCertifyModule function, a device can prevent any unauthorized code from running. A common method for identifying authorized modules is through the use of digital certificates. Device security can be set up in a variety of different configurations. For example, in one configuration any unknown modules-those without valid certificates-can be denied any system access. Alternatively, this mechanism can be turned off so that all modules have complete access to all system services.

Another core security feature is the Cryptographic API, which allows applications to encrypt and decrypt blocks of data using a variety of encryption algorithms. Encryption algorithms are identified by symbolic names with the prefix CALG_, such as CALG_DES and CALG_AES. A second is support for secure sockets layer (SSL), which provides secure HTTP connections. In addition, Virtual Private Networking (VPN) is supported through the point-to-point tunneling protocol (PPTP). And to enable secure connections with server systems, Windows CE provides support for a variety of authentication mechanisms, including the Windows NT LAN Manager protocol and the more robust Kerberos authentication protocol.

Other features from previous versions of Windows CE include the Credential Manager, support for Smart Cards, the Data Protection API (DPAPI), support for public key certificates (PKI), and also the Local Authentication Subsystem (LASS). So what are the new security features with CE 6.0?

As I discussed earlier in this article, there is strict separation of user-mode code from kernel-mode code. In CE 6.0, enhanced validation checks of the Protected Server Library (PSL) and I/O Control's (IOCTL) parameters that are passed from user mode to kernel mode are performed, improving kernel mode security and stability.

The perimeter security of a system can be vastly improved by supporting a secure loader. A secure loader ensures that only trusted code gets to run on a system. In Windows CE 5.0, the operating system provided a loader hook but OEMs had to write their own secure loader. CE 6.0, in contrast, ships with a built-in secure loader. The trust decisions of the loader are certificate-based-this means that all code that runs on the system has to be signed. The secure loader, if enabled, inspects the code signature and if the signature is signed by a trusted certificate then that code is allowed to run. If not, the module load fails. The OEM has control over what certificates are trusted and thus has control over the code that gets to run on the system.

Another area in which security improvements have been made is in the Windows CE OS Design (or the New Platform) Wizard. When a platform is configured with a feature that may compromise the security of the device, a security warning is issued. For example, Figure 3 shows the notification displayed when the Object Exchange (OBEX) Protocol is included in a platform. Details of the potential compromise are provided, to help platform developers address the potential problems early in the platform development process.

Figure 3** A Security Warning from the Design Wizard **(Click the image for a larger view)

A final feature that was added to CE 6.0 security is support for a secure boot loader. This feature ensures that downloaded operating system (NK.BIN) images contain valid digital signatures before allowing the OS images to be installed and run on a system.

Development Tools

Prior to CE 6.0, the Windows CE team shipped a standalone product called Platform Builder. With CE 6.0, the platform development tools are integrated into Visual Studio® 2005. Visual Studio is, of course, the premier development tool for both client and Web development; now this same tool is available to support Windows CE. Features that have benefited application developers-like IntelliSense®, syntax checking, syntax highlighting, outline view, and function completion-can be used in the development of custom Windows CE platforms.

Some Platform Builder terms have changed to better fit into the Visual Studio paradigm. A Windows CE 5.0 Workspace is now a Solution in CE 6.0. A Windows CE 5.0 Project (an IDE-defined application or DLL) is now a Subproject in CE 6.0.

It was strange at first to start Visual Studio 2005 when I wanted to configure and build a new CE 6.0 platform, but I quickly learned how Windows CE 5.0 settings and commands mapped to Visual Studio. The command to create a new Windows CE platform is similar in the two versions. For Windows CE 5.0, you would select the File | New Platform... menu item. For CE 6.0, you select the File | New | Project... menu. With CE 6.0 tools installed, a new project type gets added to the Visual Studio New Project window. The project type is named "Platform Builder." Figure 4 shows this change, along with a new project template for "OS Design."

Figure 4** New Project Window with the Platform Builder Project Type **(Click the image for a larger view)

By selecting the project's location and name and clicking OK, you summon the Windows CE OS Design Wizard. Aside from the new name for what is being created-an "OS Design" instead of "Platform Builder Workspace"-the new CE 6.0 wizard is identical to the old Windows CE 5.0 wizard.

Apart from a few refinements, the remainder of the OS Design Wizard will be familiar to anyone with experience with the Windows CE 5.0 Platform Builder. As in the earlier version, the first step in defining a new platform is the selection of one or more Board Support Packages (BSPs). After that, the wizard prompts for a design template, which serves as a platform's initial configuration. Some of the Windows CE 5.0 design templates have been renamed; in some cases older design templates appear as design template variants. What was known as Tiny Kernel in Windows CE 5.0 has been renamed Small Footprint Device in CE 6.0, but otherwise it represents a minimum set of operating system features for a headless Windows CE-powered platform.

The Windows CE OS Design Wizard creates an OS Design (.pbxml), which is a Visual Studio project. The OS Design is added to a solution (.sln) file. After the wizard finishes, the newly created solution file is opened. When a Windows CE design solution is open, Visual Studio changes its menus to display the familiar Platform Builder menus: Build and Debug (see Figures 5 and 6). Changes are also made to the Target menu.

Figure 5** Build Menu **

Figure 6** Debug Menu **

If you are new to Visual Studio, here are two tips to help get you started: the Solutions Explorer window plays a key role; if it is not open, summon it with View | Solution Explorer. Many configuration details are available by drilling into the contents of this window.

Context (or popup) menus also play a key role in Visual Studio; summon these menus by selecting and clicking the right mouse button. For example, you can open an OS configuration window by selecting an OS Design solution from the Solution Explorer window and selecting the Properties menu item.

Cool Tools

The most constrained resource in the world of software development is people time. And because better tools make for more productive people, the investment in development tools never ends. Now that the Windows CE Platform Builder-the centerpiece of embedded development-has been integrated into Visual Studio 2005, the Platform Builder team will be able to focus more efforts on adding cool new tools instead of on maintaining the IDE, since Visual Studio has its own dedicated development team.

You can already get a taste of the cool future tools that will come out of this group with two new capabilities being introduced with CE 6.0. One is a graphical registry file editor, which makes it easier to edit and also add new registry keys and registry values into .reg files. A second cool tool is the runtime image viewer for peeking inside nk.bin files. This tool even allows you to compare two different nk.bin files against each other. And finally, there is shared source. While technically not a tool, the phenomenon of open source that benefits Windows CE developers is something I'm very excited about.

Registry File Editor

An important aspect of configuring Windows CE components involves creating settings for the system registry. Previously, registry (.reg) files had to be edited in their raw text form, like the one in Figure 7. Visual Studio provides a new registry file editor, as shown in Figure 8, which is a lot more pleasant to use. When necessary, you can still edit the plain-text version of the registry file by clicking on the Source button at the bottom of the registry editing window. But the default editing mode resembles the familiar registry editing tools used by developers.

Figure 7 Typical Registry Files for a Windows CE Component

IF BSP_NONLED ! ; HIVE BOOT SECTION [HKEY_LOCAL_MACHINE\System\Events] "SYSTEM/NLedAPIsReady"="Notification LED APIs" ; END HIVE BOOT SECTION [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\NLed] "Prefix"="NLD" "Dll"="nleddrvr.dll" "Flags"=dword:8 ; DEVFLAGS_NAKEDENTRIES "Order"=dword:0 "IClass"="{CBB4F234-F35F-485b-A490-ADC7804A4EF3}" ENDIF BSP_NONLED !

Figure 8** Visual Studio Registry File Editor **(Click the image for a larger view)

Runtime Image Viewer

Another nice development feature is the runtime image viewer. By convention, a Windows CE image is written to the nk.bin file. In the past, it was difficult to know exactly what was in a given nk.bin file. And it was just about impossible to compare the contents of one nk.bin to a second, leaving a lot of troubleshooting to the realm of trial-and-error, guesswork, and wracking your memory for the details of long-forgotten changes. The image viewer provides help for these kinds of problems.

Figure 9 shows the contents of a Windows CE image that was built using the Device Emulator BSP and the Small Footprint Device design template. You can view header information for any executable module (*.exe and *.dll) file by selecting the module and viewing the results in the Visual Studio Properties window. The image viewer allows you view the contents of any file included in the FILES section of a .bib file.

Figure 9** Using the Runtime Image Viewer to See nk.bin **(Click the image for a larger view)

Shared Source and Windows CE Development

With CE 6.0, Microsoft continues a program that began with Windows CE 3.0-the shared source program. Taking a cue from the open source movement, Microsoft began by making available a significant portion of the source code for Windows CE to anyone willing to download the Evaluation edition of the Windows CE Platform Builder.

Developers who build applications to run on Windows CE have gotten tangible benefits from other open source projects. Perhaps the best known is the OpenNETCF project, an extension to the .NET Compact Framework.

Microsoft has directly sponsored several source code projects such as the Bluetooth project, which provides managed code classes to simplify the use of Bluetooth in Windows CE-based applications. Another is the webcam driver used to kick-start designs with webcams when no drivers were publicly available. A third project sponsored by Microsoft is the digital video recorder (DVR) project, to support the creation of Windows CE-powered video recorders.

Conclusion

The world of Windows CE development keeps getting better. Whether your interest is application development and Windows Mobile-powered devices, device-driver development or low-level BSP programming, you'll keep finding innovations that make your development life easier and more efficient. A new kernel has eliminated some nagging limitations on available processes and process address space. Integration with Visual Studio has opened up all of the productivity enhancements that have been baked into Visual Studio 2005.

If you liked Windows CE before, you're going to love it now. If you are new to the world of Windows CE, you've probably guessed by now that there's a lot of potential waiting for you to tap into. And if you want to join a discussion of the possibilities, check out the Windows Embedded Developer Interest Group.

Paul Yao is a Business Alliance Manager with Utimaco Safeware, The Data Security Company. Paul is a contributing editor to MSDN Magazine, and coauthor of eight books including the first book published on Windows programming. Paul is founder of the Windows Embedded Developers Interest Group (WE-DIG), and founder of The Paul Yao Company.