Programming Microsoft Windows Ce Net 3Rd [Electronic resources] نسخه متنی

What Is Different About Windows CE

Windows CE has a number of unique characteristics that make it different from other Windows platforms. First of all, the systems running Windows CE are most likely not using an Intel x86–compatible microprocessor. Instead, Windows CE runs on 4 different CPU families, SHx, MIPS, ARM, and x86. Fortunately, the development environment isolates the programmer from almost all of the differences among the various CPUs.

Nor can a Windows CE program be assured of a screen or a keyboard. Pocket PC devices have a 240-by-320-pixel portrait-style screen, while other systems might have screens with more traditional landscape orientations in 480by240, 640-by-240, or 640-by-480-pixel resolution. An embedded device might not have a display at all. The target devices might not support color. And, instead of a mouse, most Windows CE devices have a touch screen. On a touch-screen device, left mouse button clicks are achieved by means of a tap on the screen, but no obvious method exists for delivering right mouse button clicks. To give you some method of delivering a right click, the Windows CE convention is to hold down the Alt key while tapping. It's up to the Windows CE application to interpret this sequence as a right mouse click.

Fewer Resources in Windows CE Devices

The resources of the target devices vary radically across systems that run Windows CE. When writing a standard Windows program, the programmer can make a number of assumptions about the target device, almost always an IBM-compatible PC. The target device will have a hard disk for mass storage and a virtual memory system that uses the hard disk as a swap device to emulate an almost unlimited amount of (virtual) RAM. The programmer knows that the user has a keyboard, a two-button mouse, and a monitor that these days almost assuredly supports 256 colors and a screen resolution of at least 800 by 600 pixels.

Windows CE programs run on devices that almost never have hard disks for mass storage. The absence of a hard disk means more than just not having a place to store large files. Without a hard disk, virtual RAM can't be created by swapping data to the disk. So Windows CE programs are almost always run in a low-memory environment. Memory allocations can, and often do, fail because of the lack of resources. Windows CE might terminate a program automatically when free memory reaches a critically low level. This RAM limitation has a surprisingly large impact on Windows CE programs and is one of the main challenges involved in porting existing Windows applications to Windows CE.

Unicode

One characteristic that a programmer can count on when writing Windows CE applications is Unicode. Unicode is a standard for representing a character as a 16-bit value as opposed to the ASCII standard of encoding a character into a single 8-bit value. Unicode allows for fairly simple porting of programs to different international markets because all the world's known characters can be represented in one of the 65,536 available Unicode values. Dealing with Unicode is relatively painless as long as you avoid the dual assumptions made by most programmers that strings are represented in ASCII and that characters are stored in single bytes.

A consequence of a program using Unicode is that with each character taking up two bytes instead of one, strings are now twice as long. A programmer must be careful making assumptions about buffer length and string length. No longer should you assume that a 260-byte buffer can hold 259 characters and a terminating zero. Instead of the standard char data type, you should use the TCHAR data type. TCHAR is defined to be char for Microsoft Windows 95 and Microsoft Windows 98 development and unsigned short for Unicode-enabled applications for Microsoft Windows 2000, Windows XP, and Windows CE development. These types of definitions allow source-level compatibility across ASCII- and Unicode-based operating systems.

New Controls

Windows CE includes a number of new Windows controls designed for specific environments. New controls include the command bar and menu bar controls that provide menu- and toolbar-like functions all on one space-saving line, critical on the smaller screens of Windows CE devices. Other controls have been enhanced for Windows CE. A version of the edit control in Windows CE can be set to automatically capitalize the first letter of a word, great for the keyboardless design of a PDA. Windows CE also supports most of the controls available on desktop versions of Windows. Some of these controls are even more at home on Windows CE devices than on the desktop. For example, the date and time picker control and calendar control assist calendar and organizer applications suitable for handheld devices, such as the Handheld PC (H/PC) and the Pocket PC. Other standard Windows controls have reduced function, reflecting the compact nature of Windows CE hardware-specific OS configurations.

Componentization

Another aspect of Windows CE programming to be aware of is that Windows CE can be broken up and reconfigured by Microsoft or by OEMs so that it can be better adapted to a target market or device. Windows programmers usually just check the version of Windows to see whether it is from the Microsoft Windows 95, 98, or Me line or Windows 2000, XP line; by knowing the version they can determine what API functions are available to them. Windows CE, however, can be configured in countless ways.

By far, the most popular configuration of Windows CE today is the Pocket PC. Microsoft defines the specific set of Windows CE components that are present in all Pocket PC–branded devices. However, some OEMs produce PDA devices that use Windows CE but are not branded as Pocket PCs. These devices have a subtly different API from that of the Pocket PC devices. If you are unaware of this, you can easily write a program that works on one platform but not on another. In embedded platforms, the OEM decides the components to include and can create a Software Development Kit (an SDK) specialized for its specific platform. If the OEM is interested in third-party development, it can make available a customized SDK for its device. New platforms are continually being released, with much in common but also with many differences among them. Programmers need to understand the target platform and to have their programs check what functions are available on that particular platform before trying to use a set of functions that might not be supported on that device.

Win32 Subset

Finally, because Windows CE is so much smaller than Windows XP, it simply can't support all the function calls that its larger cousins do. While you'd expect an operating system that didn't support printing, such as Windows CE on the original models, not to have any calls to printing functions, Windows CE also removes some redundant functions supported by its larger cousins. If Windows CE doesn't support your favorite function, a different function or set of functions will probably work just as well. Sometimes Windows CE programming seems to consist mainly of figuring out ways to implement a feature using the sparse API of Windows CE. If thousands of functions can be called sparse.