amila4341
2012-02-13, 10:49 AM
PREFACE
This book provides the technical guidance and understanding needed to
write device drivers for the new Windows 7 Operating System. It takes this
very complex programming development, and shows how the Windows
Driver Framework has greatly simplified this undertaking. It explains the
hardware and software architecture you must understand as a driver developer.
However, it focuses this around the actual development steps one
must take to develop one or the other of the two types of drivers. Thus, this
book’s approach is a very pragmatic one in that it explains the various software
APIs and computer and device hardware based upon our actual
device handler development.
There has been great progress in the art of creating and debugging
device drivers. There is now a great deal of object-oriented design techniques
associated with the driver frameworks that are available to the
device driver developer. Much of the previous grunt work, thank goodness,
is now being handled by the latest device development framework
Windows Driver Foundation (WDF). We will be covering both the user
mode and kernel mode of device driver development. WDF has excellent
submodels contained within it, called the User Mode Driver Framework
and the Kernel Mode Driver Framework.
It is really great to see a Windows Driver Framework involved in the
creation of Windows Device Drivers. I started working with Windows in
1990 and we primarily used the Win32 System APIs to communicate and
control the Windows Operating System for our applications. We used the
Device Driver Kit (DDK) to create the Windows drivers. Because I had
my own company to create application software, I obviously was very concerned
about the time it took to develop application software, and the
robustness of the application. There were more than 2,000 Win32 APIs to
be used for this task.
Then in about 1992, Microsoft came out with the Microsoft
Framework Classes (MFC). In these 600+ classes, most of the Win32
APIs were encapsulated. Of course, prior to this, around 1988, the C++
compiler came out, and Object Oriented Programming started to come
into its own. By using the MFC Framework, we could produce more application
software faster and with better quality. My return on investment
(ROI) went up, and I made more money. This sure made a believer of me
in the use of frameworks. I used MFC until the .NET Framework came
out, and for the last nine years I have been using this great collection of
classes. All along, Microsoft was working to bring this same kind of software
development improvements to developing device drivers. We came
from the DDK, to the Windows Driver Model, to the Windows Driver
Foundation Framework.
Therefore, this book shows how to create Windows 7 Device Drivers
using the Windows Driver Foundation Framework. This should give us
driver developers a little more sanity when meeting our deadlines.
The book is broken into three major parts as follows:
■ Part I, “Device Driver Architecture Overview”—This part lays
out the architecture involved in both software and hardware for
device handler development. It also covers the driver development
environment needed for driver development, for both types of drivers
that are normally developed—that is, User Mode and Drivers.
This section also covers the two Windows driver frameworks that are
most commonly used for driver device development today, which
are part of the Windows Driver Framework (WDF). These two
Windows Driver Frameworks are the User Mode Driver Framework
(UMDF) and the Kernel Mode Driver Framework (KMDF).
■ Part II, “User Mode Drivers”—This part outlines the approach,
design, development, and debug of User Mode Drivers. This part
takes the driver programmer from start to finish in developing User
Mode Drivers. We primarily use the User Mode Driver Framework
for all of this work. The code is done in C++ because it is the best way
to develop these types of drivers. Discussions are based on a USB
User Mode Driver that we will develop using the UMDF. We will use
a USB hardware learning kit from Open Systems Resources,
Inc. (OSR). This provides a hardware simulation to test our User
Mode Drivers. This part is primarily stand-alone and could be read
and used without reading any other parts of the book. However,
you will probably want to read Part I to get a feel for what we are using.
Part III, “Kernel Mode Drivers”—This part outlines the
approach, design, development, and debug of Kernel Mode
Drivers. The intent again is to take the driver programmer from
start to finish in developing Kernel Mode Drivers. For this section,
we primarily use the Kernel Mode Driver Framework for all of this
work. The code is done in C because this is the best way to develop
these types of drivers. Discussions are based on a Kernel Mode
Driver that we develop using the KMDF. We use a Peripheral
Component Interconnect (PCI) hardware learning kit from OSR.
This provides a hardware simulation to test our Kernel Mode
Drivers. The section is also primarily stand-alone and could be read
and used without reading any other parts of the book. Again, you
will probably want to read Part I to get a feel for what we are using.
This book provides the technical guidance and understanding needed to
write device drivers for the new Windows 7 Operating System. It takes this
very complex programming development, and shows how the Windows
Driver Framework has greatly simplified this undertaking. It explains the
hardware and software architecture you must understand as a driver developer.
However, it focuses this around the actual development steps one
must take to develop one or the other of the two types of drivers. Thus, this
book’s approach is a very pragmatic one in that it explains the various software
APIs and computer and device hardware based upon our actual
device handler development.
There has been great progress in the art of creating and debugging
device drivers. There is now a great deal of object-oriented design techniques
associated with the driver frameworks that are available to the
device driver developer. Much of the previous grunt work, thank goodness,
is now being handled by the latest device development framework
Windows Driver Foundation (WDF). We will be covering both the user
mode and kernel mode of device driver development. WDF has excellent
submodels contained within it, called the User Mode Driver Framework
and the Kernel Mode Driver Framework.
It is really great to see a Windows Driver Framework involved in the
creation of Windows Device Drivers. I started working with Windows in
1990 and we primarily used the Win32 System APIs to communicate and
control the Windows Operating System for our applications. We used the
Device Driver Kit (DDK) to create the Windows drivers. Because I had
my own company to create application software, I obviously was very concerned
about the time it took to develop application software, and the
robustness of the application. There were more than 2,000 Win32 APIs to
be used for this task.
Then in about 1992, Microsoft came out with the Microsoft
Framework Classes (MFC). In these 600+ classes, most of the Win32
APIs were encapsulated. Of course, prior to this, around 1988, the C++
compiler came out, and Object Oriented Programming started to come
into its own. By using the MFC Framework, we could produce more application
software faster and with better quality. My return on investment
(ROI) went up, and I made more money. This sure made a believer of me
in the use of frameworks. I used MFC until the .NET Framework came
out, and for the last nine years I have been using this great collection of
classes. All along, Microsoft was working to bring this same kind of software
development improvements to developing device drivers. We came
from the DDK, to the Windows Driver Model, to the Windows Driver
Foundation Framework.
Therefore, this book shows how to create Windows 7 Device Drivers
using the Windows Driver Foundation Framework. This should give us
driver developers a little more sanity when meeting our deadlines.
The book is broken into three major parts as follows:
■ Part I, “Device Driver Architecture Overview”—This part lays
out the architecture involved in both software and hardware for
device handler development. It also covers the driver development
environment needed for driver development, for both types of drivers
that are normally developed—that is, User Mode and Drivers.
This section also covers the two Windows driver frameworks that are
most commonly used for driver device development today, which
are part of the Windows Driver Framework (WDF). These two
Windows Driver Frameworks are the User Mode Driver Framework
(UMDF) and the Kernel Mode Driver Framework (KMDF).
■ Part II, “User Mode Drivers”—This part outlines the approach,
design, development, and debug of User Mode Drivers. This part
takes the driver programmer from start to finish in developing User
Mode Drivers. We primarily use the User Mode Driver Framework
for all of this work. The code is done in C++ because it is the best way
to develop these types of drivers. Discussions are based on a USB
User Mode Driver that we will develop using the UMDF. We will use
a USB hardware learning kit from Open Systems Resources,
Inc. (OSR). This provides a hardware simulation to test our User
Mode Drivers. This part is primarily stand-alone and could be read
and used without reading any other parts of the book. However,
you will probably want to read Part I to get a feel for what we are using.
Part III, “Kernel Mode Drivers”—This part outlines the
approach, design, development, and debug of Kernel Mode
Drivers. The intent again is to take the driver programmer from
start to finish in developing Kernel Mode Drivers. For this section,
we primarily use the Kernel Mode Driver Framework for all of this
work. The code is done in C because this is the best way to develop
these types of drivers. Discussions are based on a Kernel Mode
Driver that we develop using the KMDF. We use a Peripheral
Component Interconnect (PCI) hardware learning kit from OSR.
This provides a hardware simulation to test our Kernel Mode
Drivers. The section is also primarily stand-alone and could be read
and used without reading any other parts of the book. Again, you
will probably want to read Part I to get a feel for what we are using.