Desktops
  Modems
  Handhelds
 Multimedia
 Scanners
 Notebooks
 Software
 Printers
 Upgrades

PC Magazine

  PC Tech

Programming for Windows CE Devices

Introduction

Toolkits

The Basic Development Cycle

The Platform Builder



X10.com - The SuperSite for Home Automation!

Click here for BuyDirect!

 
  Categories
Programming

Programming for Windows CE Devices
Microsoft Windows CE isn't a stripped-down version of Windows 9x or Windows NT; it's a totally new Windows version designed for small battery-powered notebook devices. We look at what makes the OS unique, the variety of tools available for writing Windows CE applications, and some of the subtle differences you'll encounter in coding for Windows CE compared with its bigger siblings.

By Douglas Boling

Windows CE is the "third" Windows. This new operating system isn't nearly as well known as its two larger cousins, Windows 98 and Windows NT, but that's beginning to change. Windows CE is designed for small, battery-powered devices such as personal organizers. While these devices look quite different from desktop and laptop PCs, the techniques used to program Windows CE devices are similar to those used for Windows-based PCs. We'll take a look at how to program Windows CE devices, but first it's important to understand just what Windows CE is, to separate the operating system from the individual platforms that run Windows CE.

Windows CE is a totally new version of Windows. It isn't a modified or stripped-down version of either Windows 98 or Windows NT. Instead, Windows CE was designed from the ground up as a new operating system for battery-powered devices smaller than standard PCs. Users may be more familiar with the Windows CE devices, such as hand-held PCs or Palm-size PCs, than with the operating system itself. These platforms, built by OEMs such as Hewlett Packard and Casio, bundle a version of Windows CE in their ROMs. Because of this, users never install Windows CE; it comes by default on these devices.

Windows CE supports a subset of the ubiquitous Win32 API used in Windows 98 and Windows NT. While the word subset might send chills down the spine of a Windows NT developer, rest assured that the differences in the API between the desktop Windows versions and Windows CE don't cause too many challenges. The differences mainly involve elimination of the redundant functions that exist in the Win32 API for backward compatibility with previous versions of Windows. For example, there may be three or four ways to open a file programmatically in the desktop versions of Windows; under Windows CE there is only one, CreateFile.

Other differences in the API occur in areas where Windows CE doesn't implement the entire array of functions that Windows NT does. For example, the Winsock library supported by Windows CE doesn't include most of the WSAAsync functions supported by Windows 98 and NT. There is no loss of functionality in the Windows CE version, you just have to use a more pure Berkeley version of socket programming when using sockets under Windows CE. For Windows programmers, this means you need to learn how to use basic blocking and nonblocking sockets without the helpful WSAAsync functions that, on Windows 9x and NT, notify applications when socket events occur.

The other major difference between Windows CE and its larger cousins is that it is designed to be reconfigured by OEMs to better fit specific hardware platforms. For example, the requirements for a hand-held PC professional, which is a mini-notebook that runs Windows CE, are much different than those of a Palm-size PC device. Because of this, Windows CE can be componentized to remove parts of the operating system that may not be needed on the target platform. This goes far beyond simply not including a DLL in a specific platform. Windows CE can be configured so that, for example, the cursor API that controls the look of the pointer on the screen, or even the clipboard component, can be removed if it is deemed unnecessary for the specific hardware platform.

This componentization of Windows CE is done by the OEM for vertical market platforms, or by Microsoft for the horizontal platforms. A particular componentization mix produces a specific API for that configuration of Windows CE. Thus, the API for a Casio H/PC is identical to the API for an NEC H/PC since both systems use the same configuration of Windows CE specified by Microsoft for H/PC devices. On the other hand, there are some subtle differences between the API for an H/PC and a Palm-size PC since the particular components of Windows CE differ between those two platforms. These differences should not be overstated, however. Unless you delve into the specific API functions that aren't supported on one or the other platform, you won't have any trouble writing an application that runs on both. You can always avoid the problem of platform-specific functions by explicitly linking to the functions specific to that platform using LoadLibrary and GetProcAddress.

In fact, the biggest challenge in writing an application that runs on both platforms is dealing with the different screen sizes used by the two platforms. For example, the landscape screen of the H/PC (640 by 240) requires a different layout for dialog boxes than does a Palm-size PC's portrait screen (240 by 320). A good solution in this case is to create a single dialog box procedure with separate dialog-box templates for the two screen sizes. This way, the proper template can be determined at runtime by the application.

Another challenge of programming Windows CE devices is the perpetually low memory environment in which your application must survive. While Windows CE supports demand paging, it doesn't support a paging file to save read/write data on secondary storage such as a hard disk. In other words, read-only pages, such as application code and an application's read-only data are brought into memory as needed. However, read/write data is never saved in a paging file on a hard disk. This limited demand paging decreases the time it takes to launch Windows CE applications because only the parts of the application that are necessary at start-up are loaded. But it also means that since Windows CE doesn't support a paging file to save read/write memory, applications are strictly limited to the amount of physical RAM on the device. Because of this, it's quite possible your application will run out of memory at times. You must therefore write Windows CE applications to use as little RAM as possible and to handle out-of-memory situations gracefully.

Douglas Boling is a contributing editor of PC Magazine and the author of Programming Windows CE (Microsoft Press).

Next: Toolkits

Published as PC Tech Feature in the 3/23/99 issue of PC Magazine.

Related Links
Windows CE dvs. Mini-Notebooks -- PC Labs 2/9/99
Software to Go: Palm/Windows CE Software -- PC Labs 2/9/99
PalmPilot Software Awards -- Softwar Library
Handheld PCs -- ZDProducts
The Place to Select and Buy Portable PCs -- computershopper.com

 
 SPONSORED LINKS
@Backup   Your Solid Online Backup Plan. Download Now.
Services   9c/MINUTE LONG DISTANCE, 5c/MINUTE ON SUNDAYS!
STORAGE   Quantum means non-stop business, 24 hours a day
Software   X10.com -- The SuperSite for Home Automation
Books   Bargain Books up to 90% off at barnesandnoble.com
 ZDNET FEATURED LINKS
Downloads   Check out the best new downloads in Reviewer's Raves
Bargains!   Shop the Basement for best buys on computer products
Free Help   Got computing questions? ZDHelp has all the answers!
 MAGAZINE OFFERS
Free Offer   Get a FREE SUBSCRIPTION to Inter@ctive Week

TOP
Copyright (c) 1999 Ziff-Davis Inc.