Microsoft Corporation
May 1997
Microsoft® Windows® CE is a new embedded operating system for non-PC devices. It has been written from scratch to fill the need for a small, scalable, 32-bit Windows-compatible operating system that could work in a wide range of products, including handheld computers, terminals, industrial controllers, and many others. The first version of the Microsoft Windows CE operating system has already shipped in the Handheld PC, and the final release of version 1.01 will be in late April 97. The design and features of Windows CE will make it very attractive to embedded systems designers who desire an operating system similar to Windows 95 and Windows NT® Workstation, but one on a smaller scale.
The Windows CE design is based on the following goals:
Windows CE is a modular operating system composed of several major software elements. There are well-defined, Win32-compatible interfaces between the elements. Each major element comprises many small feature-level components, and the embedded system designer has the ability to include or exclude feature level components as needed. The following figure shows the elements of the Windows CE 1.01 architecture:
Starting from the bottom, the principal elements that make up the Windows CE operating system are: the hardware abstraction layer (HAL), which includes power management; device drivers and PC card services; the Windows CE kernel, USER, GDI, file systems and databases; the IRDA and TCP/IP communications protocols; the APIs; the remote connectivity; the Microsoft Internet Explorer for Windows CE; and the shell(s). Many embedded systems will not have all of these elements, of course. The following descriptions of each Windows CE module highlight the critical features of the operating system.
The HAL allows embedded systems designers to adapt Windows CE to their hardware platform and to provide hardware-specific power management functions. Windows CE does not require a standard memory map and interrupt structure, as the PC does. Instead, designers write small interrupt service routines in the Windows CE HAL that allow the operating system to run in whatever hardware configuration is best for the device. Windows CE power management functions include "instant on," allowing Windows CE devices to be powered off and then turned on instantly if the device has non-volatile (battery backed) RAM.
Windows CE–based devices can contain two types of device drivers: built-in drivers for hardware that is always present in the device—like the keyboard on a handheld PC—and run-time installable drivers for plug-in peripherals. Windows CE 1.01 directly supports many types of devices, such as keyboards, mice, touch panels, serial ports, modems, displays, PC Card slots, audio processors, speakers, parallel ports, ATA disk or flash card drives, and the like. Embedded systems designers can easily add new device types.
For all supported device drivers, Windows CE has a well-defined set of Device Driver Interfaces (DDIs) to which designers write. Device drivers run as normal processes in the system, with access to all operating system services. This allows the interrupt service routines that typically "wake up" device drivers to be very simple and fast: the driver thread does almost all the work. Windows CE provides a subset of the Windows PC Card (previously known as PCMCIA) and Socket services, allowing PC Cards such as wireless or wireline modems and flash memory cards to be used. Not only can designers use these interfaces for their own cards, but other third-party hardware and software vendors can develop new add-in PCMCIA devices or write Windows CE drivers for their existing PC Card devices. This can include anything from VGA cards to GPS. A Windows CE Device Driver Kit (DDK) is available for this purpose. Using the same PC Card interfaces, Windows CE also supports other plug-in card form factors, such as the Minicard and Compact Flash (CF) standards.
The Windows CE kernel was written specifically for non-PC devices. It implements the Win32 process, thread, and virtual memory model. Like Windows NT, it has a preemptive, priority-based scheduler, and it provides a rich variety of synchronization primitives, including semaphores, mutexes, and events. The Windows CE kernel supports execution of programs in place in ROM or RAM. It also implements demand paging for running applications that are stored compressed and/or that are stored on a media that does not support execution in place. The kernel has a low interrupt service routine and low thread latency (threads can be scheduled and switched to in less than 100 microseconds on handheld PCs running at 33 MHz). This allows Windows CE to be used in many types of real-time systems.
The USER and GDI components of Windows CE provide the basic functionality for the user interface if there is one. In Windows CE 1.01, a grayscale display is supported by GDI. Windows CE USER exports the same primary Win32 features as are provided by the Windows version of USER: overlapping windows, event management, user interface controls, dialog boxes, interprocess communication, and so on. USER also provides the functions needed for internationalization: UNICODE character manipulation and locale NLS APIs. Windows CE 1.01 is fully usable for many different language applications. GDI and USER are both very flexible in terms of componentization: for example, a designer can choose to keep the windowing system while excluding specific controls such as list views or buttons.
The Windows CE Object Store components provide persistent data and application storage. Persistent data is typically contained in non-volatile memory, such as battery-backed RAM or flash memory. When using RAM that is also used for running applications, the embedded system designer can adjust the amount of RAM used by the Object Store. (Users can also be provided the ability to do this adjustment.) The Object Store is made up of three classes of components: file systems, the registry, and databases. In Windows CE 1.01, there are three types of Windows CE file systems: a ROM-based file system, a RAM-based file system, and a FAT file system for disk drives, flash memory, and SRAM cards. These file systems all look like file systems on a Windows PC, and they are all accessed via the Win32 file system APIs. Similarly, the Windows CE registry exports the Win32 registry functions, and it is used by applications and the system to record and access run-time and other data. The Windows CE database functionality does not have a corollary on Windows NT or the Windows 95 operating system. The database provides object storage, access, and sorting. These were used initially in the HPC for such things as address books and appointments. One key feature of databases, the file system, and the registry is that they are all protected against unforeseen reset (such as caused by a main power interruption in systems like the handheld PC that have a backup battery). If a reset occurs during a write to the Object Store, Windows CE will ensure that the store is not corrupted by either completing the operation when the system restarts or by reverting to the known good state before the interruption.
Windows CE 1.01 communications protocols provides connectivity to desktop Pcs running Windows, the Internet, and other Windows CE based devices. The primary communication protocol stack used for connections is the standard Internet protocol, TCP/IP, coupled with PPP. The TCP/IP and PPP protocols are used when directly connected to a Windows-based PC through the PC's Direct Cable Connection feature, as well as when a Windows CE-based device is communicating over a modem to the Internet or a corporate network. Windows CE also includes the standard infrared stack, IrDA.
Windows CE exports a subset of the Win32 API set. This includes over 500 of the most used Win32 APIs. Many major applications for Windows CE have already been written using this subset, including the pocket Office and PIM applications that ship with the handheld PC. The subset is not extremely limiting. Along with communications protocols, Windows CE provides several of the familiar Windows communications APIs, including Windows Sockets, TAPI, and Unimodem. The Sockets API is the application interface for TCP/IP and IrDA. TAPI and Unimodem provide the dial-out functionality needed by modem-based applications, like the handheld PC Inbox and Internet Explorer.
To enable connectivity applications, Windows CE also exports a Remote Access API (RAPI) to a connected Windows-based PC over Sockets. An application on the PC, such as the handheld PC Explorer, uses RAPI to manipulate the connected Windows CE-based device's Object Store. Files can moved back and forth, databases can be updated, and the registry can be viewed and modified over the connection. By using TAPI functions to dial out, this connection can be done remotely over a phone line.
As in Windows 95 and Windows NT operating systems, Internet connectivity is a module of the Windows CE operating system. The Windows CE Internet Explorer is both an HTML control and a user interface similar to that of Windows Internet Explorer. Although primarily intended for devices with a display, components of the Microsoft Internet Explorer can be used in embedded systems that need to get information from the Internet even if "browsing" or showing WWW pages to the user is not a requirement.
Windows CE 1.01 comes with a shell component similar to that of Windows 95, as shown in the figure below (taken from the handheld PC).
However, many embedded systems that use Windows CE will not have this shell, or may have no shell at all (or even no display at all). For those systems needing a Windows look, the Windows CE shell provides a very similar experience to Windows 95 and Windows NT 4.0.
Together, the Windows CE operating system components provide a powerful Windows-compatible software platform in a small package.
At a minimum, a Windows CE device must have a supported processor, memory, and a real time clock. No other hardware is technically required by the operating system, but obviously most devices will have a number of peripherals. For processors, Windows CE 1.01 supports the NEC 4100 MIPS family, the Philips 3900 MIPS family, and the Hitachi SH3 family.
The memory needed by a Windows CE system is totally dependent on which components the designer of the system selects. For example, a low end system with just the kernel, the communications stacks, and a single non-display application would require less than one half megabyte of ROM and 256KB of RAM (depending on the application's needs, of course). The Windows CE components in the handheld PC, a full fledged Windows CE-based device using all of the components of the architecture, take up about 2MB of ROM, and the handheld PC boots up with the shell running in less than 512KB of RAM. With all of the bundled applications, a handheld PC requires 4MB of ROM and 2MB of RAM, with 1MB of that RAM defaulting to data storage. From these ranges of sizes, it can be seen that Windows CE is a small footprint, flexible operating system.
Windows CE 1.01 will be available in late April 1997. Microsoft plans to ship beta versions of Windows CE 2.0 in the second quarter of 1997 and release it in final form in the third quarter. Because many hardware systems being designed now will ship after Windows CE 2.0 is available, the 2.0 version may be more appropriate for some embedded systems designers than 1.01 is, depending on feature needs. Development of hardware, the HAL, and device drivers for systems based on Windows CE 2.0 can in most cases start with the 1.01 release or in the worst case wait for the first 2.0 beta. Here are some of the most important new features that will be supported in Windows CE 2.0:
Windows CE is ready now for embedded systems designers. To get started, check out "Developing Applications for Microsoft Windows CE: An Overview of the Windows CE SDK and Visual C++ for Windows CE," the Windows CE information on http://www.microsoft.com/windowsce/, or e-mail wceoem@microcoft.com. From those sources, designers can find out about the Windows CE 1.01 and 2.0 OEM Adaptation Kits (OAKs), the licensing procedures, and the resources available to help in the use of Windows CE. Microsoft is working with leading semiconductor companies, system integrators, and embedded systems distributors who can get an embedded system designer off to a flying start with hardware and software. There are also thousands of Windows CE Independent Software Vendors (ISVs) and Independent Hardware Vendors (IHVs) who can work with designers on custom applications and peripherals or provide already working components. This combination of Microsoft's Windows CE technology with our partner companies yields a tremendous set of resources and opportunities for the embedded system designer.