A thorough understanding of Windows CE programming requires a firm grasp of the fundamentals. We therefore begin our exploration of Windows CE application programming with a discussion of the core Windows CE topics.
We start with a brief look at the overall architecture of the Windows CE operating system. We continue with the anatomy of a typical Windows CE application. Next, programming application building blocks such as Windows CE controls and dialog boxes are covered.
Part I continues with a look at how menus are included in Windows CE applications. We will see that this is very different from how menus are added to Windows 98 or Windows NT applications. The Windows CE command bar control is presented in this discussion. Part I closes with a description of programming Windows CE common controls.
After completing the chapters in Part I, you will have a solid understanding of the basic principles required to write more complex Windows CE application programming.
In this chapter we take a brief look at the architecture of the Windows CE operating system. We also discuss some of the software development tools available to help you write Windows CE applications.
Windows CE is a compact, modular 32-bit operating system designed for use on devices with small memory requirements. Windows CE is very similar in design to its larger desktop cousin, Windows NT. Windows CE is a multitasking, multithreaded operating system like Windows NT. It includes most of the user interface features of Windows NT so that software developers can take advantage of most users’ familiarity with Windows applications.
Storage on Windows CE devices is a combination of random access memory (RAM) and read-only memory (ROM). Devices can also include expansion flash memory storage cards for additional storage space. PCMCIA cards can be added to many devices, and Windows CE provides full support for such cards.
Since storage is all memory based, the contents of the Windows CE file system is stored in RAM. The operating system and all applications which ship with Windows CE devices are in ROM. The ROM software components are run in place, instead of being paged into RAM, so that they run faster.
Windows CE application programmers get a huge productivity boost because Windows CE is based on the Win32 API. This means that programmers who are familiar with programming for traditional Windows platforms like Windows NT can begin programming Windows CE applications with very little additional training. Certainly there are features that are unique to Windows CE. But understanding traditional Windows programming is a big advantage when moving to the Windows CE operating system.
Architectural Considerations
Windows CE consists of seven subsystems. Each of these subsystems is further broken down into smaller components. The GWE subsystem, for example, consists of smaller components including the window manager and the dialog manager. The seven Windows CE subsystems are:
The Kernel
The Windows CE kernel is similar to the kernel in Windows NT. It uses the same thread and process model as Windows NT. It supports the same file formats as Windows NT. Additionally, Windows CE uses a virtual memory model similar to Windows NT. You can write Windows CE applications that share memory across multiple processes using memory mapped files.
The Windows CE kernel also implements the object manager. As is the case with Windows NT, windows, GDI objects such as brushes and bitmaps, files, and all other such objects are manipulated by applications through object handles. The handles, as well as the underlying objects they correspond to, are managed by the object manager.
The Graphics, Windowing, and Event Subsystem
Windows CE has combined the user and GDI components into one subsystem. This subsystem, the Graphics, Windowing, and Event Subsystem, is sometimes abbreviated as GWES, or even GWE.
Windows CE behavior such as creating a window, painting a window, or loading a string resource is handled somewhere within the code of this subsystem. All of the Windows CE child controls, such as buttons, list boxes, and the like, are implemented in GWES.
GWES also contains the event manager. This is where the Windows CE messaging capabilities are implemented.
The Object Store
Random access memory in a Windows CE device is divided into two sections. The first is program memory. The other part contains the Windows CE object store. The object store contains the Windows CE file system and the registry. The object store also contains Windows CE databases such as the Contacts database and custom databases created by applications.
The OEM Adaptation Layer
The OEM adaptation layer, or OAL, consists of all of the pieces of software that an original equipment manufacturer (OEM) must implement to port Windows CE to new hardware.
If you are interested in creating a new class of Windows CE products, such as a point-of-sale terminal for ordering parts at the local auto repair shop, you need to get Windows CE to run on your custom hardware. The OAL is where you customize the interrupt service routines and hardware interfaces that allow hardware to communicate with Windows CE.
Programming the OEM adaptation layer is one of the many aspects of Windows CE embedded systems programming. As this subject deserves an entire book of its own, it is not covered in this book, which is devoted to application programming.
The Device Driver Layer
This layer of the Windows CE operating system contains all of the drivers for peripherals that are included with a particular device. These might include flash memory card drivers, video drivers, and keyboard drivers. Detailed coverage of this subject, like the OAL, belongs in an embedded systems programming book.
The Communication APIs
Windows CE includes many of the communication APIs that you might be familiar with from Windows NT. For example, sockets, serial communication, TAPI, and the WinINet APIs are all supported under Windows CE.
One of the most important features of many Windows CE devices is their ability to share data with a desktop PC. Windows CE therefore supports ActiveSync technology. ActiveSync allows application programmers to write service providers for synchronizing application-specific data between Windows CE devices and desktop computers. Additionally, there is file filter support for transferring files between platforms.
Custom Shells and the Internet Explorer
OEMs can use the Windows CE shell component to write their own custom shells for their devices. For example, if you do not want the standard Handheld PC shell, you can write your own.
Windows CE also supports a version of the Internet Explorer.
Windows CE Modularity
One of the nicest features of Windows CE from the OEM point of view is the modularity of the operating system. Each of the various subsystem components can be added or removed as needed. If you are designing a product that does not need any of the Windows CE child controls, for example, you can remove them from the ROM operating system image that runs on your hardware. This allows OEMs to shrink the memory footprint of the operating system by removing any components that are not needed for a particular product.
The SYSGEN tool that ships with the Windows CE Platform Builder makes this possible. When OEMs license Windows CE, they get all of the operating system component libraries. They must, however, build their own operating system image.
Part of this process involves writing a file, called CESYSGEN.BAT, that specifies which component libraries to include in the image. The SYSGEN tool then links those pre-compiled libraries into the operating system image.
Microsoft designed Windows CE with existing Windows programmers in mind. We have already discussed how Windows CE is based on the Win32 API. Programmers can also use many of the same programming tools that they are already familiar with.
This is because Microsoft Developer Studio can be used for writing and debugging Windows CE applications. Emulators for the various Windows CE platforms allow developers to write and debug applications on a desktop PC. The Windows CE Toolkit includes utilities for allowing the Microsoft Developer Studio debuggers to remotely debug applications running on Windows CE hardware. Developers can therefore begin writing and debugging Windows CE applications without learning a new set of development tools.
A Sample Session
To demonstrate the Windows CE programming tools, let’s see how to build a sample Windows CE application. We will build the TEMPLATE.EXE application for the Handheld PC emulation environment. Then we will see how to build the same application for real HandheldPC hardware and download it to a device. The project files for this application can be found on the companion CD under \Samples\ template.
"Essential Windows CE Application Programming" by Robert Burdick: http://zabud.chat.ru/text/ewcap.zip