Getting Under the Hood

Many programmers are now familiar with the Windows architecture and have some knowledge of hardware used on platforms like the Intel x86. It would be wise to understand the principles of a platform before writing an application for that platform. For this reason, this section provides a brief overview of the core components that make up Windows CE. Please bear in mind that this section is not designed to be an exhaustive reference.

Supported Architectures

Microsoft's desktop and server operating systems presently support a limited number of platforms, such as Intel x86, Alpha, MIPS, and so forth. However, to target the mass electronics market, Windows CE must provide support for a vastly larger number of processors. After all, it is unlikely that a vendor using a tried and tested processor will want to change to an unfamiliar environment that might require a whole new learning curve and changes to test-bed equipment. Microsoft's commitment to Windows CE is such that even at this relatively early stage, support is already provided for CPUs from eleven manufacturers, and the list is growing! Currently support is provided for processors from the following CPU manufacturers:

• AMD

• Digital

• Hitachi

• IBM

• Intel

• LG Semiconductors

• Motorola

• NEC

• Philips

• Toshiba

• QED

At present, the Microsoft Windows CE Toolkit for Visual C++ 5 can create programs for each of these platforms; however, the Microsoft Windows CE Toolkit for Visual Basic 5 can only create applications for HPC devices. At present, Philips and Hewlett-Packard are the two largest players in the commercial HPC market, the former using the MIPS platform and the latter using the SH3 platform from Hitachi. This supported hardware list will increase over time, I imagine, according to the demand from customers. I would also expect that the platforms available for Visual Basic will increase. This degree of flexibility is one reason why the industry is taking Windows CE very seriously.

Win32 API

Microsoft estimates that there are some 4.76 million professional developers worldwide, a large number of which currently program Win32 using languages such as Visual C++ or Visual Basic. Of this number, it is estimated that around 300,000 are embedded developers (developers who write software to control hardware devices). For this reason, basing Windows CE on the Win32 API provides a sound foundation from which to build. Don't be fooled, though; if there were not such a large user base, it is feasible that Windows CE might have been based on some other API. With a development team of around 700 on Windows CE alone, Microsoft is more than capable of achieving this!

The API set for Windows CE is very much scaled down from the desktop and server operating systems. Whereas Windows NT has around 10,000 API routines, Windows CE has a mere 1200. This isn't a bad thing, because the new versions are highly optimized and the duplicated functions that exist in the Windows NT/9x operating systems have been removed. If you will be porting from an existing application to Windows CE and you use Win32 API calls in your code, I hope you will have converted to the newer calls. For example, where a function Foo and FooEx exists you should be using the newer FooEx version. If you haven't then never mind, the conversion should not be too painful, although you will need to convert because the older routines do not exist in Windows CE.

The subset of API calls should be sufficient for most tasks. Remember that Windows CE has been built with a "ground-up" approach, so the immediate requirements have been dealt with first. As the operating system's development progresses, new calls will be added as required by users.

The Object Store

The object store is the collective name for the data storage elements within the Windows CE operating system. On the HPC, physical RAM is divided into application memory space and emulated disk space. The disk portion of RAM is where the object store resides. The object store is home for such items as the Registry, Windows CE databases, user files, and applications. Applications that are built into the operating system core are actually held in ROM and cannot be accessed using the object store API calls. A default Registry is also stored in ROM and therefore it, too, cannot be accessed using the API.

An important feature within the Windows CE object store is its transaction mechanism. Microsoft stipulates that if for any reason data cannot be written to the object store, the whole operation will be canceled. This mechanism works on a record level—for example, if you are writing 10 records to a database and a power loss occurs during record 8, records 1 to 7 will have been saved, but no fields in record 8 will be. This applies to the Registry and file system in the same way.

The object store comprises three elements: the database, the Registry, and the file system. These are explained in the following sections.

The Windows CE database

The Windows CE database model provides storage for non-relational data. You can create any number of databases, each with a unique ID. Each database can contain any number of records (depending on memory). A database record can have any number of fields and these fields can be of type Integer, String, Date or Byte array (also known as Binary Large Objects, or BLOBs). Each database record has its own unique ID and this ID is unique across all databases. Database records can contain up to four index keys, which can be used for searching and sorting. In addition, a field can be indexed either in ascending or descending order.

The records held in a database need not be related; for example, you can store contact information in some records and product price details in another record within the same database. A number of API functions exist to manipulate databases—these are covered in more detail later in this chapter. Microsoft has recently released a beta version of ActiveX Data Objects, (ADO) which provides full connectivity to relational databases like Microsoft SQL Server and Microsoft Access. ADO makes it possible to manipulate data in a relational database using the standard SQL to which most Windows developers are accustomed.

Even though the standard database features might sound rather limited, you should remember the kind of application for which Windows CE is designed. If you think in terms of the OEM developing a household device, you'll see that the functionality is more than adequate.

File system

The Windows CE file system has a host of functions with which to access file-based data. The file functions that exist in the normal development environment are not supported by Windows CE; instead, new functions have been provided in the API. Most Windows CE devices presently use the FAT-based file systems. However, the operating system can support installable file systems. For most current Windows CE applications, file access will be to RAM rather than to a physical hard disk, although in terms of coding the difference is transparent.

The file system can be browsed and manipulated using the Mobile Devices application that is installed as part of the Windows CE Services. This application is rather like Windows Explorer and works in the same way. You can even copy, move, or paste files between Windows Explorer and mobile devices.

Registry

Windows CE, like Windows NT/9x, uses the Registry to store system and application configuration data. However, the Windows NT Registry consists of several files, or hives, that together form the entire Registry. Windows CE does not support hives—the entire Registry is stored as a single file. The Registry file is stored in ROM and is copied to RAM when the device is booted. You should bear in mind that a Windows CE device will probably boot only after the power supply has been connected. Normally, when the device is turned off, backup batteries retain RAM memory. This design allows a feature that Microsoft calls "Instant On"—that is, the device is immediately available when switched on. It is possible to write software that saves the Registry file to a non-volatile storage device. Given the nature of the power supply for many prospective Windows CE devices, however, user data can be lost in almost any situation. Losing the Registry should not cause too many problems for an application, because more than likely any user files will be lost as well. A good design principle to employ might be for an application to back up the Registry to non-volatile storage whenever the user chooses to backup his or her files.

The RAM copy of the Registry can be accessed using the Win32 API, or Visual Basic programmers can use the built-in Registry functions. Desktop applications written in Visual Basic often need to use the API in order to access different Registry keys; for example, global application data would probably need to be saved to HKEY_LOCAL_MACHINE, whereas user specific settings would be better located under HKEY_CURRENT_USER. For Visual Basic programmers, a COM DLL is required to access keys or paths other than the default one that Visual Basic accesses: HKEY_CURRENT_USER\Software\VB and VBA Program Settings.

ActiveSync

ActiveSync is the technology introduced with Windows CE 2 that provides an easy way to keep data synchronized between a mobile device and a desktop PC. ActiveSync allows you to keep databases synchronized between your device and the desktop PC in much the same way as replication occurs between SQL Server databases. Conflict resolution is handled for you once you set up the required configuration. The synchronization operations can be performed using the Mobile Devices folder menu options, but you can also use certain API functions to control the process. The ActiveSync API calls are listed later in this chapter in the section "Visual Basic Development".

Processes and Threads

Because Windows CE is based on the Win32 API, it has full support for processes and threads. Visual C++ (and even Visual Basic 5) programmers might already be familiar with these concepts. Essentially, a process consists of one or more threads of execution, where a thread is the smallest unit of execution. Windows CE allows a maximum of 32 processes; however, the number of threads is limited only by available memory. It is possible to create threads using Visual Basic, but this is not advisable because the Visual Basic run time is not "thread safe"— that is, if two threads within the same process were to call a Visual Basic routine at the same time, some fairly nasty things might happen. However, because I know that some of you will try it, and because it is very applicable to C++ development, the section "Visual Basic Development" later in this chapter describes the thread-handling API calls. If you have trouble remembering the difference between processes and threads, you might find the diagram in Figure 5-3 helpful.

Figure 5-3 Windows CE processes and threads

The ability to assign priorities to a thread is a major requirement, especially for an operating system that will host real-time applications. Windows CE allows a thread to be assigned one of eight priority levels, as shown in Table 5-1.

Table 5-1 Thread Priorities

Priority	Typical Usage
0 THREAD_PRIORITY_TIME_CRITICAL	Used primarily for real-time threads and processing, such as device drivers. Priority 0 threads are not preempted—once started, a thread process will continue to completion. The operating system will not interrupt the thread.
1 THREAD_PRIORITY_HIGHEST
2 THREAD_PRIORITY_ABOVE_NORMAL	Kernel threads normally run at these levels, as do normal applications.
3 THREAD_PRIORITY_NORMAL
4 THREAD_PRIORITY_BELOW_NORMAL
5 THREAD_PRIORITY_LOWEST	Used in instances in which it doesn't matter how long the functionality takes to complete. These will usually be background tasks, probably without their own user interface. An example might be of a thread that periodically checks to see if you have any new mail. Threads on these priority levels can expect to be interrupted often.
6 THREAD_PRIORITY_ABOVE_IDLE
7 THREAD_PRIORITY_IDLE

The Windows CE operating system is preemptive and as such must allocate a time slice for each thread. This is done in a "round-robin" fashion. The default time slice for a thread is 25 milliseconds, except for priority 0 threads. A priority 0 thread, once started, will retain the processor until it yields control. The scheduling mechanism uses an algorithm whereby the highest priority thread is always allocated time first. This process is better illustrated by Figure 5-4.

Figure 5-4 Thread preemption in Windows CE

Windows CE handles thread priority inheritance (a requirement of real-time systems we will discuss shortly) using a method called Priority Inversion. It is possible that a thread on a lower priority might lock a resource required by a thread on a higher priority. When this condition occurs Windows CE promotes the lower thread task to the level of the higher priority thread until the resource has been released. The Win32 API has full support for thread priority assignments. In version 2 of the Windows CE operating system the default time slice is configurable on the MIPS platform.

An additional requirement currently being developed is to increase the number of priority bands, possibly to as many as 256. This has been a frequent request from OEMs and IHVs in order to enhance real-time flexibility. Because of the way in which the preemptive multitasking works in Windows CE, it is possible to guarantee the time it will take for a thread to execute on the highest priority, an important factor in a real-time system.

Real-Time Capabilities

The ability for Windows CE to perform real-time processing is an essential element when it comes to control and monitoring systems. There is some debate as to whether the operating system currently allows "true" real-time processing. The Internet newsgroup comp.realtime gives this standard definition of a real-time system: "A real-time system is one in which the correctness of the computations not only depends on the logical correctness of the computation, but also on the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred." In addition, this newsgroup states that a real-time operating system must also meet the following requirements:

• The operating system must be multithreaded and preemptive.

• The operating system must support thread priority.

• A system of priority inheritance must exist.

• The operating system must support predictable thread synchronization mechanisms.

• The maximum time during which an interrupt can be disabled by the operating system or device drivers must be known.

• The time it takes the interrupt to run (interrupt latency) must be within the requirements of the application.

The Windows CE operating system meets the criteria to be classed as a real-time operating system, but in its current implementation the architecture does not achieve these goals in a way that would promote the level of integrity required to host a mission critical application. To help you understand this better I should perhaps explain how the interrupt processing is performed. Interrupts are events triggered by external components to announce that an event has occurred. Because I know a little about aircraft, I shall use an aircraft warning system to draw an analogy—note that the examples are not strictly accurate but are simply designed to illustrate the point. Imagine an autopilot that is equipped with a collision avoidance system. In the event of a collision warning, the collision avoidance device should notify the autopilot, which in turn must take corrective action. This might be in the form of an audible warning and also might automatically adjust the aircraft controls to miss the obstacle. In a real-time system you would expect that once the warning (or interrupt) has occurred the autopilot will react and perform the required actions within a stipulated time. Figure 5-5 shows a simplified diagram of how such functionality might be handled by the Windows CE operating system.

Figure 5-5 Real-time processing in Windows CE

An external device notifies the operating system of an event by way of an interrupt, or more correctly, an interrupt request line (IRQ). Each IRQ has an associated interrupt service routine (ISR). When an interrupt occurs the Kernel calls the associated ISR, which returns the ID of the interrupt service thread (IST) for the IRQ. Once the Kernel has the thread ID it notifies the IST, which starts the required processing. There are a couple of reasons why you might not want this system in a Boeing 777 on final approach. First, interrupts cannot be nested—that is, once an interrupt has occurred no further interrupts can be processed until the IST has started for the previous interrupt. Second, imagine the scenario where there are multiple ISTs each on 0, the highest priority. Because critical threads are not preempted any further IST will not be able to run until the first IST has finished. So, in the case of our 777, whose computer also handles the fire extinguisher, we could deal with the collision warning, but we could not deal with a fire until the collision warning's IST completed. Microsoft is working hard to cater to these demanding requirements of real-time mission critical applications. Version 3 of the Windows CE operating system will be able to handle nested interrupts and will have interrupt latencies of less than 50 milliseconds.

Development Environments

One of the attractions of the Windows CE operating system is that it is possible to build software applications using industry-standard programming languages. For the OEM and IHV developers, the choice of programming language will no doubt be the ETK because of their need to write low-level device drivers. For the rest of the industry, Windows CE also provides support for C++, MFC, ActiveX Template Library (ATL), Visual Basic, and Java applications. The Visual Basic language might prove very appealing because it is so well known, but note that you cannot use the Windows CE Toolkit for Visual Basic with any version other than Visual Basic 5 at the moment—the toolkit is hard-coded to recognize only this version. Other higher-level applications, especially Web-enabled ones, can be written using Visual J++.

Whichever tool you use to write Windows CE applications, you must bear in mind that they are subsets of their respective "parents." When we discuss Visual Basic development later in this chapter, you will notice a marked reduction in the number of routines and statements available. Obviously, the scaled-down nature of the operating system means that certain functionality is not needed because Windows CE cannot support it. The other reason for some omissions is that Microsoft has included what they believe to be the most needed features for this platform—don't worry, the feature list will grow with demand. Currently four main markets exist for Windows CE (although this is growing). These are:

• Auto PC (in-vehicle computing)

• Handheld PC

• Palm-sized PC

• Embedded systems

The language you choose depends largely on which of these platforms you will be developing for. Figure 5-6 shows the various development tools available for each platform. The long-term strategy, as far as development tools is concerned, is for each toolkit to provide support for each platform. As the tools are more finely honed and expanded, the software development scene will change somewhat, presenting exciting opportunities. I personally look forward to the possibility of projects including mission-critical systems and real-time systems in the future.

Figure 5-6 Choosing the right development tool for the job