Franklin Fite Jr., Windows CE Product Unit Director
Randy Kath, Windows CE Product Unit Group Manager
Microsoft Corporation
September 1997
Microsoft® Windows® CE version 2.0 and supporting development tools enable a collaborative business model that can help embedded-systems vendors and OEMs reduce their time to market.
With the release of Windows CE version 2.0, embedded developers and OEMs can build new classes of embedded devices using a comprehensive set of system features for the popular 32-bit CPU families. They can take advantage of a large third-party developer infrastructure and use industry-leading development technology that adds new embedded development tools to the Microsoft desktop developer investment.
The Windows CE operating system is a 32-bit, preemptive, multitasking operating system designed from the ground up to support embedded development. This article describes the modular architecture that makes Windows CE suitable for embedded systems. It summarizes the improvements and new features that are offered in version 2.0. These include the enhancements to the kernel to support some real-time applications, and the addition of support for new microprocessors.
This article also introduces the new suite of embedded development tools and technology as well as the third-party resources that are available to help OEMs and embedded developers build new devices based on Windows CE.
During the design of a new, 32-bit, preemptive, multitasking, ROM-able, Windows operating system, three important goals for Windows CE included: providing the right system for many different devices, minimizing system RAM requirements, and preserving the Microsoft Win32® development paradigm to extend the knowledge and technology investment from Windows to Windows CE.
Windows CE met these goals by providing a modular Win32-compatible operating system. This design allows embedded developers and OEMs to select from a set of modules and components to build a custom version of the operating system for their products.
This "componentization" lets a system designer pick and choose features at a very low level. For example, Windows CE systems can be built with a minimum kernel and no display, or with an alphanumeric LCD, or with a video graphics adapter (VGA) monitor, with exactly the right amount of operating-system support for each. The nondisplay system will be much smaller than the VGA system, all other things being equal.
This design allows embedded systems designers to mix and match the same Windows CE 2.0 code base for use in Handheld PCs (H/PCs) and other mobile devices, and will allow future releases to be used for other device categories, such as smart phones, multimedia and entertainment systems.
Figure 1 describes the key modules in the system. These include: the OEM abstraction layer (OAL), which adapts the kernel to a specific hardware platform; the kernel; the graphics, windowing, and event subsystem (GWES); the object store (including the registry, file system, and databases); the Device Manager; the communications stack; and the shell.
Figure 1. The Windows CE architecture. The OEM develops the OAL; other developers can develop the built-in drivers, installable drivers, and applications that run on the embedded device.
The OEM abstraction layer (OAL), also called the hardware abstraction layer (HAL), is a thin layer of code that provides the interface between the kernel and the device hardware. The OEM receives a version of the kernel tailored for a specific microprocessor and implements hardware-specific power management, serial and parallel port, interval timer, real-time clock, and interrupt-handling functions.
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.
The highly componentized GWES module provides the basic functionality for the graphics, windowing, and events subsystem. It includes all functionality for the user interface (if there is one). Windows CE 2.0 supports up to full 24-bit color, greatly expanding the grayscale-only support offered in versions 1.0 and 1.01.
The Windows CE GWES module exports the primary Win32 user-interface features: overlapping windows, event management, user-interface controls, dialog boxes, interprocess communication, and so on. These components also provide the functions needed for internationalization: UNICODE character manipulation and locale national language support (NLS) functions. Version 2.0 adds support for cascading menu, mouse, and cursor functions.
The Windows CE version 2.0 graphics device interface (GDI) components within the GWES module support bit-depth independence and a new palette model in which the foreground application controls the system palette. These components allow blitting between 1-, 4-, 8-, 16-, 24-, and 32-bit-per-pixel Windows-format bitmaps. They support fully scalable and rotatable TrueType fonts, improved printing functionality, and additional controls. Version 2.0 also adds full support for all standard raster operation (ROP) codes, increasing the bitmap manipulation capabilities.
The Windows CE object store components provide persistent data and application storage. The object store can include file systems, the registry, and databases.
Windows CE offers three types of file systems: a ROM-based file system, a RAM-based file system, and a file-allocation-table (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 functions.
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. For 2.0 systems, the registry is used for system initialization and must always be present.
The Windows CE database functionality is optimized for non-PC devices and does not have a corollary on Microsoft Windows NT® or Microsoft Windows 95. The database provides object storage, access, and sorting. Databases were used initially in the H/PC for such things as address books and appointments.
All data in the object store is protected against unforeseen reset, such as that caused by a main power interruption in systems like the H/PC that have a backup battery. If a reset occurs during a write to the object store, Windows CE ensures that the store is not corrupted by either completing the operation when the system restarts or by reverting to the last known good state before the interruption.
Windows CE directly supports many kinds of devices, such as keyboards, mouse devices, touch panels, serial ports, modems, displays, PC Card slots, audio processors, speakers, parallel ports, and Advanced Technology Attachment (ATA) disk or flash card drives. 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 PC Cards or write Windows CE drivers for their existing PC Card devices. This can include anything from VGA cards to Global Positioning Systems (GPS).
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.
Windows CE offers multiple communications options to allow the Windows CE device to communicate with the Internet, a local area network (LAN), a desktop Windows computer, other Windows CE devices, and with infrared devices such as printers.
These options include the standard Win32 Windows networking (WNet) functions; Win32 serial functions, the Win32 telephony application programming interface (TAPI), the Remote Access Service (RAS), and Windows Sockets functions. Also available are extensions to Windows Sockets to access IRLPT, IRComm, and IRSock interfaces that facilitate communications with a variety of infrared devices.
Version 2.0 supports the WinINET API for Hypertext Transfer Protocol (HTTP) and (File Transfer Protocol (FTP) support, and Serial Line Interface Protocol (SLIP) as well as Poin-t-Point Protocol (PPP) for serial networking. It supports the Internet Control Message Protocol (ICMP) functions to allow applications to perform remote ping operations programatically. The ability to establish secure communication is provided via Secure Socket Layer (SSL) 2.0 and 3.0 and Private Communication Technology (PCT) 1.0 protocols.
Version 2.0 supports a server message block (SMB) redirector to access remote files and includes an network driver interface specification (NDIS) 4.0 wrapper to support Ethernet miniport drivers for LAN connectivity (note: the redirector and NDIS are independent of each other). It also provides Plug and Play support for network PC Cards. Finally, this release also offers improvements to the desktop synchronization model.
Windows CE offers an optional Windows-like shell component. For those systems needing a Windows look and feel, the shell provides a very similar experience to Windows desktop systems. The Windows CE shell will be available in English. Other localized versions of the shell will be available in French, German, Italian, Portuguese, and Spanish. Version 2.0 development kits also offer a handwriting recognition engine for the English language.
To summarize, the enhancements and new features for version 2.0 include the following:
In preserving the Win32 development paradigm, many of the programming interfaces offered with Windows CE 2.0 are Win32 and industry standards. In some cases, the Windows CE implementations represent subsets of these standards, in keeping with the Windows CE mission of providing the greatest possible functionality with the smallest possible memory footprint.
Microsoft has been working closely with the leading CPU manufacturers to ensure broad support for the industry's leading 32-bit CPUs. With version 2.0, the Windows CE kernel has been ported to more microprocessors.
Windows CE now supports the following CPU families: the AMD ElanSC400; Hitachi SH3; Intel 486DX and Pentium; Motorola PowerPC 821; NEC VR4101, VR4102, and VR4300; Philips PR31500; and Toshiba TX3912. Additional members of these CPU families may also run Windows CE but have not yet been certified in Microsoft test labs.
Future releases of Windows CE will support the DEC SA1100 StrongArm, IBM PPC 403GC(X), Motorola 860, and future Hitachi SuperH processors.
In addition to the other enhancements and new features, Windows CE version 2.0 offers improved kernel performance. Windows CE can now be used in some embedded real-time systems, including instrumentation, manufacturing process controls, high-speed data acquisition devices, and telecommunications switching equipment.
Real-time systems must respond to external events or interrupts within a specified time interval. Windows CE offers bounded interrupt latency times that will be suitable for many real-time applications. Note that the term interrupt latency here refers primarily to the software interrupt-handling latencies; that is, from the time that an external interrupt arrives at the processor until the interrupt processing begins.
Windows CE splits interrupt processing into two steps: an interrupt service routine (ISR) and an interrupt service thread (IST).
Each hardware interrupt request line (IRQ) is associated with one ISR. When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt line. The ISR, the kernel-mode portion of interrupt processing, is kept as short as possible. Its primary responsibility is to direct the kernel to launch the appropriate IST.
Most interrupt handling occurs within the IST. The two highest thread priority levels can be assigned to real-time ISTs, ensuring that these threads run as quickly as possible. At the highest priority level, ISTs are not preempted by any other threads. These threads continue execution until they either yield or are blocked.
Windows CE interrupt latency times are bounded. This makes it possible to calculate the worst-case latencies—the total times to the start of the ISR and to the start of the IST.
In tests to date on the Hitachi D9000 SH3 reference platform (at 58.98 megahertz [MHz] internal and 14.745 MHz external frequency) with a standard H/PC configuration that includes all Windows CE modules and components, the range of ISR latency times was 1.3 to 7.2 microseconds, and the range of IST latency times was 80 to 193 microseconds. The Windows CE development team, based on observed worst-case studies, calculates that the worst-case start of IST time is about 500 microseconds.
The general formula for ISR latency is defined as follows:
Start of ISR = value1 + dISR_Current + sum(dISR_Higher)
value1 = Latency value due to processing within the kernel.
dISR_Current = The duration of an ISR in progress at the time the interrupt arrives. This value can range from 0 to the duration of longest ISR in the system.
sum(dISR_Higher) = The sum of the durations of all higher-priority ISRs that arrive before this ISR starts; that is, interrupts that arrive during the time value1 + dISR_Current.
The general formula for IST latency is defined as follows:
Start of IST = value2 + sum(dIST) + sum(dISR)
value2 = Latency value due to processing within the kernel.
sum(dIST) = The sum of the durations of all higher priority ISTs and thread context switch times that occur between this ISR and its start of IST.
sum(dISR) = The sum of the durations of all other ISRs that run between this interrupt's ISR and its IST.
Two different approaches are being used to validate Windows CE performance:
The Microsoft tools will be provided to embedded developers to validate the timing performance of their customized versions of Windows CE. Additional information can be found in the article "Real-Time Systems with Microsoft Windows CE."
In addition to an operating system that meets the demands of embedded developers and OEMs, Microsoft also delivers a comprehensive set of tools to support embedded development and applications for Windows CE–based devices.
Leading the way for embedded developers is the Microsoft Windows CE Embedded Toolkit for Visual C++® 5.0. This new product combines an integrated development environment (IDE) with a rich set of Win32 programming interfaces and cross-compilers for the supported CPU families. The Developer Studio environment consists of an integrated set of windows, menus, toolbars, directories and tools. You can access your source-text editor, resource editors, project build facilities, compiler, incremental linker, source-code browser, integrated debugger, and online documentation all from within a single IDE.
Bundled with the Windows CE Embedded Toolkit for Visual C++ 5.0 are the development technologies to develop all the software needed for an embedded platform. This includes the OEM adaptation layer, built-in device drivers, installable device drivers, Windows CE applications targeted for that platform and market, and ROM images. The header files, libraries, documentation, and sample programs are also made available to third-party tools vendors for inclusion in their development tool products.
Remote tools increase productivity by providing visual tools in the host environment that operate on the remote target. These include:
These tools are accompanied by comprehensive documentation with step-by-step how-to descriptions. For example, the online help for the Windows CE operating system build process includes instructions on how to create ROM images and how to download and debug them on your development platform. The toolkit also offers several sample configurations of the operating system that you can build to gain hands-on experience.
As shown in Figure 2, this integrated toolkit means that embedded developers can now obtain one product to perform all of their development tasks.
Figure 2. Microsoft Windows Embedded Toolkit for Visual C++ 5.0 contains components previously packaged separately in the Windows CE OAK, DDK, and SDK.
The Windows CE Embedded Toolkit for Visual C++ 5.0 will contain the OEM-supplied OAL layers for some common platforms. Embedded developers can also obtain additional OAL layers for a specific target platform from OEMs and other vendors. The first release will present the componentization and ROM image tools as applications that are run from the command line. Future releases will offer enhanced integration of these tools with the Developer Studio IDE.
Early in the cycle, when prototype hardware is not yet available, you can start system software development using one of several reference platforms that operate with the embedded toolkit. These development platforms, such as the Hitachi D9000 development system, are configurable so that developers can simulate different target platform capabilities. The Windows CE kernel and a special Windows CE system generation tool build the operating system for the target platform. (Note that the Windows CE operating system software is provided for development purposes only and cannot be redistributed without permission.)
Finally, the relatively low price for the Microsoft Windows CE Embedded Toolkit for Visual C++ 5.0 allows its purchase for evaluation as well as for development.
Microsoft also offers the Windows CE Toolkit for Visual J++™ 1.1 for developing embeddable Java applications and the Windows CE Toolkit for Visual Basic® 5.0 for ease in designing user interfaces. These rapid application development environments can now be used to quickly create Windows CE applications.
The introduction of the Windows CE Embedded Toolkit for Visual C++ provides an enormous business opportunity for embedded development products and services.
A number of applications, tools, third-party controls, services, and certified Windows professionals are already available. Many experienced Windows developers, their applications already running on Windows 95 and Windows NT desktops, can directly apply their expertise to Windows CE products. The availability of new debugging and tool-related API sets in Windows CE version 2.0 will enable tools vendors to port their existing Win32 offerings to Windows CE, increasing both the value of their products and increasing the performance and reliability of Windows CE solutions.
A growing number of system integrators are already in place to meet the special service requirements of the embedded market. These vendors offer Windows CE integration products and services, such as adapting Windows CE to embedded applications, creating custom application interfaces, and training clients on Windows CE internals. System integrators can help OEMs that do not have their own in-house engineering resources. Others, specializing in specific vertical markets, provide complete turn-key solutions for their clients.
In addition to software products, there are opportunities for hardware products as well.
Microsoft has already established partnerships with many semiconductor companies and system integrators. A list of these companies is available at the Microsoft Windows CE Web site (http://www.microsoft.com/windowsce/hpc/partners/showcase.htm).
The Microsoft vision of Windows CE is to provide a powerful, modular operating system and tools for embedded development that use familiar environments and programming interfaces while supporting a wide range of microprocessors. These tools are reasonably priced to reach a mass market of developers and are already supported by a number of third-party books and training programs.
By creating an accessible and powerful toolkit, a broad base of qualified engineers will be available to work on the different technical areas involved in creating a new embedded device. This widespread expertise will enable collaboration among different companies.
This collaborative business model represents an improvement over an environment where developers must learn new tools, or where the high cost of a proprietary system would limit development to one company.
For the Microsoft Windows CE Embedded Toolkit for Visual C++ 5.0, see the Microsoft Windows CE Web site (http://www.microsoft.com/windowsce/developer/prodinfo/vcceembed.htm). The toolkit will also be available to Universal Subscribers of the MSDN Library.
Also, be sure to take a look at the following articles, all available in the MSDN Library.
"Introducing the Windows CE Embedded Toolkit for Visual C++ 5.0," by David Pellerin.
"Microsoft Windows CE Display Drivers and Hardware," by Jason Black and Jon Christiansen.
"Microsoft Windows CE Graphics Features," by Jon Christiansen.
"Microsoft Windows CE Memory Use," by John Murray.
"The Microsoft Windows CE Communications Model," by Guy Smith.
"Real-Time Systems with Microsoft Windows CE," by John Murray.
"The Win32 Programming Model: A Primer for Embedded Software Developers," by David Pellerin.
Send e-mail inquiries, such as questions about the latest microprocessor support, to wceoem@microsoft.com.