Part I of this two-part series appeared in the May 29 issue, p. 103—ED
Windows CE was designed to accommodate a wide variety of intelligent computing devices. Thus, it's a highly configurable operating system. But, all Windows CE deployments don't include the same OS components. These OS components represent a range of functionality.
In some cases, differences are directly related to hardware. To give one small example, many Windows CE devices have a touch screen, but lack a mouse. The OS on such devices usually includes the cursor component, which supplies support for a simple wait cursor at the center of the screen. But the mcursor component, which provides support for mouse cursors and the associated API, may not be present.
In other cases, an OS configuration might simply not be intended to support certain functionality, like that provided by the CE IE4 browser components. Actually, in some instances the entire Windows GDI may be missing. The component that supplies the GDI, gwes, is by no means necessary to boot Windows CE.
There are various licensing levels for Windows CE. Higher levels, with more components, cost OEMs more money. So, it makes sense that not all components will be present on all devices.
Therefore, you must ask which configuration you will be targeting. That of course depends on your application and intended audience. A large number of applications aim Handheld PC or pocket PC/Palm-size devices. Each comprises a fairly concise environment, and includes the same basic components within the whole family of devices. (The GDI will certainly be there.) Be aware, however, that different HPC and Pocket PC releases may have different support. If you are targeting HPC 2.12 beyond, you can use IE4, for example. But, don't expect your project to build for 2.11 or 2.10, if you decide to also target earlier devices at a later date.
On the other hand, many OEMs manufacture devices that have their own custom configuration of Windows CE. If you're targeting one of these devices, you will need to find out what support is present in the OS and plan accordingly. Also, it's likely that you will have to link to the libraries provided by the OEM for that OS configuration.
The toolkits providing the Handheld PC and Palm-size PC (now Pocket PC) configurations are available at www.msdn.microsoft.com/cetools/default.asp. A new Auto PC SDK, which targets Windows CE configurations for in-car computing devices, has recently been made available from Microsoft. Check it out at www.msdn.microsoft.com/cetools/platform/autopc.asp.
Often, Windows CE devices have small display sizes. For example, the Palm-size PC is 320 by 240pixels, whereas a handheld medical device might have a standard VGA display. To maximize the use of the screen real estate, Windows CE applications usually use a full-screen window, without a title bar or maximize/minimize buttons. Typically, the window also doesn't have a border and isn't sizeable.
The Multiple Document Interface (MDI) is commonly used in desktop applications, but not in Windows CE products. For example, when you open multiple files in Pocket Word, the various documents are displayed in different top-level windows, rather than in the child windows of Word's main window. Because windows are supposed to be full screen in Windows CE, you generally can't plan on using MDI when designing your application.
New Multipurpose Control Another difference is that Windows CE has a new control called CommandBand. This is a compact, efficient visual control that serves multiple purposes, like providing a location for menus, toolbars, and help/close buttons, without consuming too much valuable screen real estate (see the figure).
The Microsoft Developer Network (MSDN) has an article describing how to use the CommandBand control (www.msdn.microsoft.com/library/techart/commandband.htm).
It's especially important to pay attention to details while using the CommandBand control. The CommandBand is a common control, so make sure that you call InitCommonControls Ex() before using it. Plus, it's very common to save the CommandBand settings in the registry when the program exits. This way the CommandBand settings can be restored when the program is next executed. Use the CommandBands_GetRestoreInformation() function to retrieve the settings and write them to the registry.
Additionally, on some Windows CE devices, such as the Palm-size PC, only one instance of an application should be run at a time. Unlike desktop Windows, the hPrevInstance parameter to WinMain() isn't set on Windows CE. So, it cannot be used to check for a running instance of your application. An alternative method is to use a Mutex (Listing 1).
A single-instance application intended to run on a Palm-size PC usually does't have an exit button (the "cross" button on the upper left corner), or an exit command under a menu.
As noted, Windows CE devices also vary in display size. For example, some HPC devices are 480 by 240 pixels, some are 640 by 240 pixels, and Palm-size PCs are 240 by 320 pixels. Because CE applications are supposed to have a full-screen window, it's a good idea to use the CW_USEDEFAULT flag when creating your main window (Listing 2).
Though application windows are full-screen in Windows CE, dialog boxes can be any size. One easy way to deal with the issue of different screen sizes is to make certain that all of the dialog boxes fit in the smallest possible screen size. A better way to handle this is to resize the dialog box at run time (Listing 3)
These techniques will work when the dialog boxes are created in your program, but what if they are from the OS, like the file-open dialog box that you get when you call GetOpenFileName() or GetSaveFileName()? Also, what about all the dialog boxes used by the Control Panel applets?
Windows CE provides two different implementations for most of these dialog boxes: one designed to fit on a display that's 480 by 240 pixels or larger, the other designed to fit on a 240- by 320- or Palm-size display. If neither of these fits the display you're working on, you will have to implement them yourself. The Windows CE Platform Builder 2.12 provides the source code for the Control Panel applets (\Wince212\ Public\Wceshell\Ctlpnl). You should be able to resize and change the dialogs and rebuild the applets. These are built into .DLLs renamed to .CPL.
But overwriting GetOpenFileName() and GetSaveFileName() is much more complicated. Basically, you will have to implement your own custom shell. For more information on how to implement a custom shell on CE, see www.msdn.microsoft.com/library/techart/customshell.htm.
The RAM on a Windows CE device is divided into two sections—one for storage memory, and one for program memory. The program memory is the memory that's used to execute programs, and the storage memory is for saving files very much like the hard drive on a PC. The amount of memory allocated for storage and programs can be adjusted by using the System Properties Control Panel Applet, or programmatically via Get/SetSystemMemoryDivision API methods. Because the memory available on CE devices generally is a lot less than on PCs, it's important to make your programs both smaller in size, and more efficient in memory usage.
Reduce Library Overhead Application libraries, like MFC or ATL, are a very popular way to write programs for desktop PCs. While both are available on CE, they greatly increase the size of your program. For example, the MFC libraries are about half a megabyte in size. Unless you know that the platforms you are targeting have these libraries in ROM, you may want to think twice about writing your program using these libraries. If you do expect those libraries to be in ROM, and you link your application to them dynamically, the overhead will be significantly reduced.Several interpreted languages, like Visual Basic and Java, are very popular for writing applications on desktop PCs. They also are available for use with Windows CE. Make sure that the interpreters for these languages are in ROM, because they are normally very large. Also, be careful about performance. As you might expect, these smart devices have less program memory available than desktop computers. Therefore, you want to be certain that the limited memory available to these languages doesn't slow things down too much.
There are many ways to save program memory in your applications. One way is to allocate memory only when you need it, then delete it as soon as you no longer need it. A few objects that require a lot of memory are bitmap images and icons. Another way to save memory is to load these objects only when they are displayed. The ListView control is often used to display icons. Make sure you use a virtual ListView in Windows CE. The advantage is that only the icons currently displayed will be loaded. You can find more information on how to use a virtual ListView at www.msdn.microsoft.com/library/devprods/vs6/visualc/vcsample/vcspvlistvw.htm.
You Have To Make The Adjustment One challenge facing Windows developers is the adjustment to Windows CE versions of the tools they are accustomed to using for desktop Windows applications. MFC is available on Windows CE, as was mentioned earlier. In addition, IE4, COM, ATL, and VB are available. Support for more tools is being added all the time. But these tools often feature less functionality than their desktop counterparts. Compared to the desktop Windows version of MFC, for instance, some MFC classes aren't supported.Further, the CE COM library doesn't include support for out-of-proc servers, etc., as does the desktop version. Ultimately, if you expect to rely heavily on one of these tools, or if you are porting a desktop Windows application that does so, it's best to investigate the available level of support on Windows CE early on in order to avoid any unfulfilled expectations down the road.
Developers of system software for desktop Windows sometimes need to debug their software remotely. But for Windows CE developers, remote debugging is the rule, not the exception. Fortunately, Microsoft's Windows CE development tools, like the Windows CE Toolkit for Visual C++ 6.0, include a variety of debugging options. These make debugging a CE application almost as easy as debugging a desktop application. With the Windows CE Toolkit, you can debug over a serial connection using the TCP/IP transport. Or for much faster debugging, you can do so over an Ethernet connection.
For debugging H-PC and Pocket PC applications, Microsoft's H-PC and Pocket PC emulation environments provide an alternative to remote debugging. Build your application against the emulation libraries, and then it can be run and debugged on your Windows desktop computer.
Developing software for Windows CE is similar to developing software for other Windows operating systems. The basic programming model is identical, and the tools are very similar. The much wider range of CE platforms, though, can introduce a desktop developer to the more diverse environments of embedded devices, even as his or her prior experience in programming for Windows constitutes excellent preparation for the nuts and bolts of Windows CE application programming. Conversely, the well supported Windows development model and tools make it easy for anyone wishing to write an embedded application to do so for Windows CE. Developers interested in receiving Windows CE training can find information at www.microsoft.com/windowsce/Embedded/news/training.asp or www.bsquare.com.