Windows Usb Device Driver Pdf

Windows Programming/Device Driver Introduction. Windows device drivers generally come in Each bus is controlled by its own root driver. There is a USB.

12 Chapter 1: An Introduction to Device Drivers to discuss the situation with your legal counsel. Chapter13 examines the API for working with USB devices.

The most downloaded USB Drivers laserjet1020.exe, and USB Mass Storage Device. CNET; REVIEWS; NEWS; DOWNLOAD; VIDEO; HOW TO; Login; Join; download; Windows.

So that you can develop USB device drivers that are interoperable with Windows. Developing Windows client drivers for USB devices. Purpose.

Developing Windows client drivers for USB devices

Windows Programming/Device Driver Introduction

Windows device drivers generally come in 2 flavors: Virtual Device Drivers VXD and Windows Driver Model WDM. VxD style drivers are older, and are less compatible, while WDM drivers are supposed to be fully code-compatible all the way back to Windows 98.

In the old days of DOS, the computer was free land where anything goes. To that end, developers wrote their own hardware drivers, conforming to no specific specification or interface, using real-mode assembly code. With the advent of Windows 3.0, the operating system began to take a more hands-on approach to application management, by creating and maintaining a variety of virtual machines, to execute different programs in different processor contexts. Drivers could no longer exist as non-conformist real-mode DOS drivers, but instead had to mitigate access between multiple programs, running more or less in parallel with each other. Windows 3.0 changed the real devices into managed resources known as virtual devices, and replaced the real-mode drivers with new virtual device drivers VDD.

The Windows NT product line existed as a separate entity from the regular windows brand. These two operating systems were completely different in almost every imaginable way, except perhaps that the shells looked similar. Windows NT was a fully-managed operating system, and unauthorized resource accesses were blocked by the NT kernel. This meant that in Windows NT, device drivers needed to interface with the computer through specific methods, while standard windows drivers Windows 3.0, 3.1, 3.11, 95, 98, Me could access hardware directly, without any sort of management. The drivers for both systems at this point, were generally written in assembly language, as well.

Realizing that the market was split between Windows and Windows NT, Microsoft saw a need to introduce a single driver model, so that device drivers could be portable between Windows and Windows NT. In addition, Microsoft knew that drivers had to be writable in a higher-level language, like C, in order to be code-compatible for different hardware systems. To meet these needs, Microsoft created the Windows Driver Model WDM. WDM drivers are compiled using the DDK, they are written in C, and they follow exacting specifications that ensure they can be executed on any windows system. This book will attempt to focus on WDM drivers, but will include notes on writing DOS TSR drivers, and VDDs as well.

Device Drivers operate in kernel mode so writing, testing, and debugging drivers can be a tricky task. Drivers should always be well tested before they are installed.

Since device drivers do not operate in user mode, the user mode libraries kernel32.dll, user32.dll, wingdi.dll, msvcrt.dll are not available to a device driver. Instead, a device driver must link directly to ntoskrnl.exe and hal.dll which provide Native API and executive services.

Device drivers are typically written in C, using the Driver Development Kit DDK. There are functional and object-oriented ways to program drivers, depending on the language chosen to write in. It is generally not possible to program a driver in Visual Basic or other high-level languages.

Because drivers operate in kernel mode, there are no restrictions on the actions that a driver may take. A driver may read and write to protected areas of memory, it may access I/O ports directly, and can generally do all sorts of very powerful things. This power makes drivers exceptionally capable of crashing an otherwise stable system.

The Windows platform DDK comes with header files, library files, and a command-line compiler that can be used to write device drivers in C or C. There is no graphical interface to the DDK compiler.

Windows implements device drivers in a highly-modular fashion, and it is important that we discuss some vocabulary before we continue the discussion of driver programming any further. The drivers necessary for any particular device are arranged in a driver stack, and are connected together internally by a singly-linked list, that starts at the bottom of the stack the root driver, and terminates at the highest level driver. Each driver must contain at least 2 modules, a root driver, and a function driver. This combination, with some optional additions, constitute the whole of what people generally call a complete device driver. Function Drivers will be the most common type of driver to be written, and will be of a primary focus in this wikibook.

Microsoft realized that certain classes of devices all behave similarly, and it would be a gigantic waste of time for every hardware manufacturer to have to write the entire driver code from scratch. To this end, Windows allows for a type of driver known as a class driver. Class drivers are themselves not complete function drivers, but class drivers can be dynamically linked to a regular function driver, and can simplify the development process quite a bit. It is possible to write your own class driver, but 3rd party programmers generally don t worry about it. In general, Microsoft will supply the class drivers, and driver developers will tap into those class drivers. This ensures that class drivers are fully microsoft tested and certified, and that they are very versatile.

Another classification of driver is the filter driver. There are two general types of filter driver, an upper filter driver, and a lower filter driver. Upper filter drivers exist in the stack above the function driver, and--as their name implies--they filter the incoming I/O requests. Lower filter drivers are placed in the stack between the function driver and the root driver. Filter drivers are generally implemented as bug fixes, or as quick hack extensions for preexisting drivers.

Here is a general diagram of a driver stack:

Buses and Physical Devices edit

For simplification, let us use the term bus to refer to any place on your computer where information can travel from one place to another. This is a very broad definition, and rightfully so: the term bus needs to account for everything from USB, Serial ports, PCI cards, Video outputs, etc. Each bus is controlled by its own root driver. There is a USB root driver, a PCI root driver, and so on.

Let s now consider a mythical construct known as the root bus, a structure that all other buses connect into. A root bus object doesn t actually physically exist in your computer, but it is handy to think about it. Plus, the root bus has its own driver. The root bus driver object is responsible for keeping track of the devices connected on any bus in your entire computer, and ensuring that the data gets to where it is all going.

Plug-n-Play PnP is a technology that allows for the hardware on the computer to be changed dynamically, and the PnP software will automatically detect changes, and allocate important system resources. PnP gets its own root driver, that communicates closely with the Root bus driver, to keep track of the devices in your system.

Device Namespace, and Named Devices edit

Drivers execute in the context of whatever thread was running when windows accessed the driver. To this end, we say that drivers execute in an arbitrary context. Therefore, it is not good practice for a driver programmer to make any assumptions about the state of the processor at the entry point to a driver. There are a few issues that arise with this, so we will discuss them here.

Floating Point Arithmetic edit

Drivers that want to use MMX or floating point arithmetic may find they are in for some undue difficulty. Because a driver may be entered in any context, at any time, the floating point unit may contain partial results and unhandled exceptions from the user mode program that was interrupted to call the driver. It is not enough to simply save the context and then to restore it, because any unhandled exceptions may become unhandleable, and raise a system error or a bug check. There are only certain times when Microsoft recommends using floating point arithmetic, and we will discuss them later.

Install a USB device. that plugs into a universal serial bus USB port, Windows automatically If Windows is able to install a device driver.

This section describes Universal Serial Bus USB support in the Windows operating system, so that you can develop USB device drivers that are interoperable with Windows.

USB devices are peripherals, such as mouse devices and keyboards, that are connected to a computer through a single port.

A USB client driver is the software installed on the computer that communicates with the hardware to make the device function. If the device belongs to a device class supported by Microsoft, Windows loads one of the Microsoft-provided USB drivers in-box class drivers for the device. Otherwise, a custom client driver must be provided by the hardware manufacturer or a third party vendor. The user installs the client driver for the device when the device is first detected by Windows. After successful installation, Windows loads the client driver every time the device is attached and unloads the driver when the device is detached from the host computer.

You can develop a custom client driver for a USB device by using the Windows Driver Frameworks WDF or the Windows Driver Model WDM. Instead of communicating with the hardware directly, most client drivers send their requests to the Microsoft-provided USB driver stack that makes hardware abstraction layer HAL function calls to send the client driver s request to the hardware. The topics in this section describe the typical requests that a client driver can send and the device driver interfaces DDIs that the client driver must call to create those requests.

A client driver for a USB device is a WDF or WDM driver that communicates with the device through DDIs exposed by the USB driver stack. This section is intended for use by C/C programmers who are familiar with WDM. Before you use this section, you should understand basic driver development. For more information, see Getting Started with Windows Drivers. For WDF drivers, the client driver can use Kernel-Mode Driver Framework KMDF or User-Mode Driver Framework UMDF interfaces designed specifically to work with USB targets. For more information about the USB-specific interfaces, see Framework USB Reference and UMDF USB I/O Target Interfaces.

The Windows Driver Kit WDK contains resources that are required for driver development, such as headers, libraries, tools, and samples.

Download kits and tools for Windows

Gives specifications for I/O requests, support routines, structures, and interfaces used by USB client drivers. Those routines and related data structures are defined in the WDK headers.

Use these samples to get started with USB client driver programming.

Related standards and specifications

You can download official USB specifications from the Universal Serial Bus Documents website. This website contains links to the Universal Serial Bus Revision 3.0 Specification and the Universal Serial Bus Revision 2.0 specification.

Getting started with USB client driver development

Introduces you to USB driver development. Provides information about choosing the most appropriate model for providing a USB driver for your device.

Write, build, and install your first skeleton user-mode and kernel-mode USB drivers by using the USB templates included with Microsoft Visual Studio.

USB host-side drivers in Windows

Provides an overview of the USB driver stack architecture.

Learn how a client driver builds a variable-length data structure called a USB Request Block URB to submit requests to the USB driver stack.

Selecting a USB configuration in USB drivers

Device configuration refers to the tasks that the client driver performs to select a USB configuration and an alternate interface in each interface. The section shows the methods calls required to select a USB configuration.

Sending USB data transfers in USB client drivers

Implementing power management in USB client drivers

Use the power management abilities of USB devices that comply with the Universal Serial Bus USB specification have a rich and complex set of power management features.

Send comments about this topic to Microsoft