Native and stream drivers only differ in terms of the APIs they expose. You can load both types of drivers during system startup or on demand, and both types can use a monolithic or layered design, as illustrated in Figure 6-1.
Figure 6-1 Monolithic and layered driver architectures
Monolithic Drivers
A monolithic driver relies on a single DLL to implement both the interface to the operating system and applications, and the logic to the hardware. The development costs for monolithic drivers are generally higher than for layered drivers, yet despite this disadvantage, monolithic drivers also have advantages. The primary advantage is a performance gain by avoiding additional function calls between separate layers in the driver architecture. Memory requirements are also slightly lower in comparison to layered drivers. A monolithic driver might also be the right choice for uncommon, custom hardware. If no layered driver code exists that you could reuse, and if this is a unique driver project, you might find it advantageous to implement a driver in a monolithic architecture. This is especially true if reusable monolithic source code is available.
Layered Drivers
In order to facilitate code reuse and lower development overhead and costs, Windows Embedded CE supports a layered driver architecture based on model device driver (MDD) and platform device driver (PDD). MDD and PDD provide an additional abstraction layer for driver updates and to accelerate the development of device drivers for new hardware. The MDD layer contains the interface to the operating system and the applications. On the hardware side, MDD interfaces with the PDD layer. The PDD layer implements the actual functions to communicate with the hardware.
When porting a layered driver to new hardware, you generally do not need to modify the code in the MDD layer. It is also less complicated to duplicate an existing layered driver and add or remove functionality than to create a new driver from scratch. Many of the drivers included in Windows Embedded CE take advantage of the layered driver architecture.
The MDD/PDD architecture can help driver developers save time during the development of driver updates, such as providing quick fix engineering (QFE) fixes to customers. Restricting modifications to the PDD layer increases development efficiencies.
Lesson Summary
Windows Embedded CE supports native and stream drivers. Native drivers are the best choice for any devices that are not stream devices. For example, a display device driver must be able to process data in arbitrary patterns and is therefore a good candidate for a native driver. Other devices, such as storage hardware and serial ports, are good candidates for stream drivers because these devices handle data primarily in the form of ordered streams of bytes as if they were files. Both native and stream drivers can use either the monolithic or layered driver design. In general, it is advantageous to use the layered architecture based on MDD and PDD because it facilitates code reuse and the development of driver updates. Monolithic drivers might be the right choice if you want to avoid the additional function calls between MDD and PDD for performance reasons.
Lesson 2: Implementing a Stream Interface Driver
On Windows Embedded CE, a stream driver is a device driver that implements the stream interface API. Regardless of hardware specifics, all CE stream drivers expose the stream interface functions to the operating system so the Device Manager of Windows Embedded CE can load and manage these drivers. As the name implies, stream drivers are suitable for I/O devices that act as sources or sinks of streams of data, such as integrated hardware components and peripheral devices. It is also possible for a stream driver to access other drivers to provide applications with more convenient access to the underlying hardware. In any case, you need to know the stream interface functions and how to implement them if you want to develop a fully functional and reliable stream driver.
After this lesson, you will be able to:
¦ Understand the purpose of Device Manager.
¦ Identify stream driver requirements.
¦ Implement and use a stream driver.
Estimated lesson time: 40 minutes.
Device Manager
The Windows Embedded CE Device Manager is the OS component that manages the stream device drivers on the system. The OAL (Oal.exe) loads the kernel (Kernel.dll), and the kernel loads Device Manager during the boot process. Specifically, the kernel loads the Device Manager shell (Device.dll), which in turn loads the actual core Device Manager code (Devmgr.dll), which again is in charge of loading, unloading, and interfacing with stream drivers, as illustrated in Figure 6-2.
Figure 6-2 The Device Manager in Windows Embedded CE 6.0
Stream drivers can be loaded as part of the operating system at boot time or on demand when the corresponding hardware is connected in a Plug and Play fashion. User applications can then use the stream drivers through file system APIs, such as ReadFile and WriteFile, or by means of DeviceIoControl calls. Stream drivers that Device Manager exposes through the file system appear to applications as regular file resources with special file names. The DeviceIoControl function, on the other hand, enables applications to perform direct input and output operations. However, applications interact with the stream drivers indirectly through Device Manager in both cases.
