Windows CE — Not Quite a New Game

By Everett Kaser

Just when you think you know everything (well, at least about programming), they change the game on you once again. The new family of H/PCs brings us YAWA (Yet Another Windows API): the Windows CE operating system. If you wish to develop programs for the Handheld PCs (or port your Win32 programs to the H/PC's) you will need to become familiar with the Windows CE environment, and how it differs from previous versions of Windows. Fortunately, the major differences are pretty obvious and reasonably small. Unfortunately, the minor differences are many, and may cause you hours of "challenge."

Get the right tools

The first step is to acquire the tools needed:

1. The Windows CE development environment ONLY runs on the Windows NT 4.0 operating system, so you will need to have a platform running Windows NT 4.0.
2. You will need Microsoft Visual C++ version 5.0.
3. You will also need Microsoft Visual C++ for Windows CE. This product is separate from, and loaded on top of, the regular Visual C++. It only works with version 5.0 or later.
4. Finally, you'll need the Microsoft Windows CE Software Developers Kit (SDK/DDK).

The first three above you'll need to purchase from Microsoft. Graciously, the fourth item (the Software Developers Kit) will be available for free from Microsoft ‘s web site (www.microsoft.com/windowsce/developer). It will also be included with the MSDN CD-ROMs, as well as being included with Visual C++ for Windows CE.

The same, but different

Programming for Windows CE is very similar to programming for Win32 for Windows 95 and Windows NT. However, there are important differences. To properly document all of them would fill a large book (and will, no doubt, fill MANY large books at your local bookstore over the coming years). The remainder of this article will mention some of the more significant things a Win32 programmer will need to be aware of when programming for Windows CE.

Windows CE is a subset of Win32, containing about one half of the functions. The current version (1.0) does NOT support ActiveX, DDE, Multimedia, ODBC, OLE, COM, printing, or MDI (talk about alphabet soup!). There are keys missing from the keyboard (Insert, Delete, ScrollLock, Pause, NumLock, PrintScreen, and the function keys). There's no mouse (but it's mostly replaced by the stylus and touchscreen display). There's no color on the display (just four shades of gray) and no custom palettes, no TrueType fonts, and no coordinate space transformations. There's no Metafiles and no concept of the "current point" (so most line drawing functions are not supported; PolyLine must be used instead). There's no Arc or Pie (use Ellipse), and no user-defined cursors (only an alternate predefined "hourglass" cursor may be selected). Bit blitting is limited to the BitBlt function. There's no concept of a "current directory" (each application is responsible for keeping track of the path to its own files and a "current directory" if it wants to have one). There are no cascading (or hierarchical) menus. There are no "top-most" windows, no maximize/minimize buttons, and the window size is fixed when it is created and may not be modified while in use. Windows CE uses Unicode strings, not ASCII, although ASCII is supported for exchanging text files with other environments.

Some functions have modified parameter values, and some structures have been changed (like WINCLASS and CREATESTRUCT). An application's title, menu, and tool bar are integrated into a single "command bar," and the system "task bar" ALWAYS shows there's no "auto hide." The only common file dialog boxes that are supported are Open and SaveAs. Windows CE is multi-threaded, but only supports Critical Sections and Events. If you use mutex or semaphores in your Win 95 or Win NT application, you will need to modify those to use Critical Sections instead.

Be frugal with the systems

Windows CE help files are written in HTML, a direction that Microsoft seems to be going with virtually everything these days. The HTML gets "compiled" into a compressed help file. However, help files should be VERY restricted in size, due to the ever-present memory limitations in H/PCs. Only include the REALLY important (and non-obvious) information in the help file. Always be nice to your customers. Remember that many of them won't have the top of the line machine with maximum RAM that you, as a developer, probably have.

Another area where you should be cautious about over-using resources is the Registry (which, of course, must be stored in RAM). Keep your Registry entries few and small. Also be very careful using the PeekMessage function. It never blocks, which prevents the CPU from going into "idle." This drains your customers' batteries very quickly, and your customers WON'T be happy about THAT!

A very capable environment

Even with all of that said, the Windows CE environment is still a very capable one. It has been carefully tailored for the small, handheld, battery-powered platforms upon which it's intended to run. Most of the removed functionality concerns things that won't work well on the limited resources of a handheld computer. The initial H/PC design specified a minimum of 2 Mb of RAM, and that's the amount contained in most of the machines currently on the market, although there are upgrade options on some of them to 4 and 6 Mb. This memory size is even more restrictive than at first it seems, as there is no hard disk. This RAM must hold the long-term program and data storage, as well as provide data space memory for the OS (which executes out of ROM) and execution and data space for RAM-based applications. Because of this, Windows CE developers will have to acquire a different attitude and a new set of skills targeted at small footprint applications. On a 2 Mb machine, the typical user will probably have about 1 Mb set aside for storage. This leaves 1 Mb for program memory, of which about 400 Kb is used by Windows CE and the shell. According to Microsoft, "Typically, 600 Kb is plenty of stack and heap space for running all of the built-in Windows CE applications, even simultaneously. This amount will usually suffice for running additional ISV applications as well." This may be true, but you should still pay VERY close attention to the available resources during the design phase of your project, BEFORE you start coding that first line.

Screen sizes are initially 480x240 with four shades of gray. Expect these to get "bigger" (as the initial Hewlett-Packard machine already is), but design with the smallest one in mind. Here's a pointer regarding screen size: you can figure out the maximum allowable size for your window by calling GetSystem Metrics to get the screen size and the height of the command bar (SM_CYMENU), and subtract the command bar height from the screen height. Most "normal" applications will run full-screen on a Windows CE platform (minus the system task bar at the bottom), unless the application is specifically intended to run in a small window (like a clock or calculator application).

Microsoft says that, because of the strong similarities between Windows CE and Win32, porting a Win32 application to Windows CE should be easier than starting over, but that the hardware limitations may require significant redesign. That is probably overly optimistic, as very few Windows applications of any significance are small enough to not totally trash the available resources on an H/PC platform. Certainly, some code segments may be pasted from your Win32 application code into your Win CE project, but I strongly recommend that you look at the resource limitations of an H/PC before starting work on your project, and then begin a fresh design targeted at the new platform. Once that design is done, then you can "steal" a few code snippets from your full scale application as you begin implementing the H/PC version.

Another notable difference between previous Windows platforms (excepting NT) and the H/PCs is the use of non-Intel CPUs and architectures. The first machines on the market use either the Hitachi SH3 or the MIPS processors. The Windows CE Visual C++ product comes with cross-compilers for both of these platforms, and Microsoft has announced plans to support Intel x86, Motorola PowerPC, ARM, and the AMD ElanSC400 processors as well. Because of these different CPUs, you will need to recompile your application for each CPU that you want to target and distribute multiple copies of the executable, one for each CPU.

That's a brief overview of some of the things you will encounter when you try to develop an application for Windows CE. It's not a job for the feint of heart, but experienced Windows programmers should be able to adapt to the new environment very quickly.