Visual Basic

Building a Windows CE Device

Hardware vendors are generally very good at what they do, maybe because of the skills they need to produce a piece of equipment that meets the tough demands of consumer laws. When, for example, was the last time you bought a car with a bug in the electronic ignition system? OK, so you might not know if the car did have one, but compare that to the average software application! With this degree of technical ability, the average IHV or OEM will easily be able to build high-quality devices using Windows CE.

Windows CE is purchased as a set of files containing the operating system binaries-the exact content is decided by the purchaser. The Windows CE Kernel module is a mandatory requirement of the operating system; however, all other components are optional. For example, if you were building a control module for an alarm system, you might want to have a custom LCD display, in which case you would purchase Windows CE without the Graphics Device Interface (GDI) module and simply add your own. You get the Microsoft Windows CE Embedded Toolkit for Visual C++ 5 (ETK) along with the operating system. This toolkit allows you to build device drivers that interface your hardware to Windows CE and customize the operating system. (See Figure 5-2.)

Figure 5-2 Windows CE is available in various configurations to match the user's needs

In the early days of PC software development, a major consideration was that of processor speed and disk space. As hardware has evolved, the cost of high-speed CPUs, RAM, and disk storage has plummeted, in many cases reducing the need for programmers to spend time developing code that conserves these resources-the average corporate desktop PC will usually have adequate memory and disk space to run the application. Windows makes things even easier with its virtual memory management. However, the story is very different for OEM and IHV developers. In a custom device, physical space might well be at a premium. More importantly, hardware like CPUs, ROM, RAM, and disks all consume power, which is limited in a portable device. This makes the manufacturer's task a difficult one. For example, a color display might be a nice thing to have, but you might have to cut back elsewhere so that the poor battery will last a reasonable time. (Remember the first portable phones with their enormous battery packs?) This is the reason that the Windows CE operating system is vastly reduced in size from the PC and server operating systems, and it is also why the operating system is available in component form. By including only the required functionality, the manufacturer can keep the ROM requirement small, which allows more RAM for the user.

Having purchased the Windows CE license, you now want to build and test your device. You can select a Windows CE configuration with as many or as few components as you require. For example, if you want telephony support you might choose to purchase a license that includes the TAPI module. The more components you choose, the easier it will be to build your device because much of the work will already have been done. After selecting the operating system components, the vendor must build any drivers that will interface to the device hardware. In addition, the vendor must write any vendor-specific software. For example, not all devices need to have a video display unit (VDU)/keyboard interface; a Windows CE stereo system might have a custom plasma display with a button panel. In instances like this, the vendor might need to write his or her own components-in this case a replacement GDI module and hardware drivers. The Windows CE Embedded Toolkit for Visual C++ 5 provides all the necessary support for building and testing device drivers and customizing the operating system. Once the software is written, the next step is to burn an erasable programmable read-only memory (EPROM) chip for testing. The EPROM contains the user-configured Windows CE operating system in addition to the device's software. Having the software in ROM does not prevent additional software from being loaded into RAM, but RAM software is lost should power fail. However, an advantage to having software in RAM is that it makes upgrading a much easier task. Once the device has been tested and debugged, the "real" system CPUs can be produced for the finished device. For an OEM or IHV, producing a Windows CE device should be reasonably straightforward; in many cases, it should be an easier task than at present once the OEM or IHV has mastered the intricacies of the Win32 API and Windows CE configuration.

It is easy to draw false impressions about the capabilities of the Windows CE operating system, especially if you focus too much on devices like the HPC. Consider the screen display as a prime example. When I first started to look at Windows CE seriously, I thought the operating system was bound to a miniature device that had to have a tiny screen display. In fact, nothing could be further from the truth-the Windows CE device can be of any size and can also incorporate a screen display of virtually any size.

Peripheral devices, of which I predict a weird and wonderful selection, will be designed primarily for a specific task. Windows CE allows flexibility for this specific design; for example, the operating system can support a screen resolution of 1600 x 1200 and device drivers can be built if the default does not meet a particular requirement. If I could emphasize one Windows CE concept, it is that Windows CE is a flexible and adaptable compact operating system.

Windows CE has matured somewhat over the last year or so and, as with any good product, a whole plethora of support tools and services are now available to both the OEM and software developer.