Controlador de DispositivosIngeniera en Sistemas Computacionales

Salvador Gurrola Velazquez Salvador.gurrola@yahoo.com.mx

Device DriversAportacin

de la asignatura al perfil del egresado Conocer, desarrollar y administrar software para el control de dispositivos. Identificar y evaluar caractersticas para desarrollar software para los controladores

OBJETIVO

GENERAL DEL

CURSO Proporcionar los conocimientos necesarios, los cuales le permitan al

Conceptos Introductorias Escenario actual.

Device DriversArquitectura del Software ControladorDescripcin de la arquitectura. Anlisis de los requerimientos para el desarrollo del software controlador. Diseo de los requerimientos del desarrollo del software controlador. Tipos de la arquitectura. El enfoque arquitectnico. Patrones de arquitectura. (Diseo) Estilos Arquitectnicos. Planos Arquitectnicos. Desarrollar un sistema que administre un controlador de dispositivos.

Antecedentes y avances de los controladores. Definicin de controlador. Campo de aplicacin. Importancia en el mercado. Importancia de la independencia de la plataforma. Tipos de controladores. Controlador Abierto (Libre). Definicin. Aplicacin. Controlador cerrado (privado). Definicin. Aplicacin. Normas y estndares.

Tipos de controladores.

Gestin avanzada de accesos. Concurrencia. Dos o ms peticiones a la vez.

Seguridad. Acceso a datos. Acceso a recursos. Autenticacin. Administracin de la concurrencia.

Proyecto Final

Device Drivers

Agenda Semana1 Semana2 Semana3 Semana4 Semana5 Semana6 Semana7 Semana8 Semana9 Agosto -27 Septiembre -3 Septiembre- 10 Septiembre- 17 Septiembre 24 Octubre - 1 Octubre - 8 Octubre - 15 Octubre 22 Arquitectura del Software ControladorTipos de controladores.

Conceptos Introductorias

Semana10 Octubre - 29 Semana11 Noviembre- 5 Semana12 Noviembre - 12 Semana13 Noviembre - 19 Semana14 Noviembre 26 Semana15 Diciembre - 3 Semana16 Diciembre - 10 Semana17 Diciembre 17 ExtraordinariosProyecto Final

Examenes de Regularizacion y

Device DriversEvaluacin

Asistencia ExamenesEvaluacin

10% 90%

ultima unidad

Documentacin 50% Proyecto 50%

Device DriversProyecto Desarrollar un sistema que administre un controlador de dispositivos.

Device Drivers

FUENTES DE INFORMACIN

1. http://es.wikipedia.org/wiki/Controlador_de_dispositivo 2. http://www.amazings.com/ciencia/noticiasn/breves.html 3. http://www.fimee.ugto.mx/webfimee2006/temario_electric.html 4. 5. 6. 7.

http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/dv

http://www.getronics.com/NR/rdonlyres/egqe44mqr3eiwp65mn6hllxw

http://www.levelfour.com/pressreleases/2004/12/15/spanish/?PHPSES

http://www.fujitsu.com/es/services/sectors/bank/solutionsbank/mdcs.

8. http://insecure.org/tools/tools-es.html 9.

http://www.imheguia.com/izaro_2005/index_imhe.php?modulo=redac

10. http://www.smartmatic.com/noticias_2006.htm 11. http://gforge.puj.edu.co/

Libros Programming

the Microsoft Windows Driver Model / Walter Oney -- 2nd ed. ISBN 0-7356-1803-8 The Windows 2000 Device Driver Book, A Guide for Programmers, Second Edition Art Baker Jerry Lozano Publisher: Prentice Hall PTR Second Edition November 20, 2000 ISBN: 0-13-020431-5 http://www.microsoft.com/whdc/devtools /wdk/default.mspx http://msdn.microsoft.com/en-us/library

Unidad I Antecedentes y avances de los controladores. Escenario actual.

Definicin de controlador. Campo de aplicacin. Importancia en el mercado. Importancia de la independencia de la plataforma.

Controlador de dispositivo Un

controlador de dispositivo (llamado normalmente controlador, o, en ingls, driver) es un programa informtico que permite al sistema operativo interactuar con un perifrico, haciendo una abstraccin del hardware y proporcionando una interfaz posiblemente estandarizada para usarlo. Se puede esquematizar como un manual de instrucciones que le indica cmo debe controlar y comunicarse con un dispositivo en particular.

Tipos de controladoresExisten

tantos tipos de controladores como tipos de perifricos, y es comn encontrar ms de un controlador posible para el mismo dispositivo, cada uno ofreciendo un nivel distinto de funcionalidades. Por ejemplo, aparte de los oficiales (normalmente disponibles en la pgina web del fabricante), se pueden encontrar tambin los proporcionados por el sistema

Tipos de controladoresDebido

que el software de controladores de dispositivos se ejecuta como parte del sistema operativo, con acceso sin restricciones a todo el equipo, resulta esencial que slo se permitan los controladores de dispositivos autorizados. La firma y el almacenamiento provisional de los paquetes de controladores de dispositivos en los equipos cliente, mediante las

Tipos de controladores

Seguridad mejorada. Puesto que los usuarios estndar no pueden instalar controladores de dispositivos que no estn firmados o que estn firmados por un editor que no es de confianza, los administradores tendrn un control riguroso respecto a los controladores de dispositivos que pueden usarse en una organizacin. Podrn impedirse los controladores de dispositivos desconocidos, as como cualquier controlador de dispositivo

Tipos de controladores

Reduccin de los costes de soporte tcnico. Los usuarios slo podrn instalar los dispositivos que hayan sido probados y admitidos por la organizacin. En consecuencia, el sistema permite mantener la seguridad del equipo, al tiempo que se reducen las solicitudes del departamento de soporte tcnico.

Tipos de controladores

Experiencia de usuario mejorada. Un paquete de controladores firmado por un editor de confianza y almacenado provisionalmente en el almacn de controladores funciona de modo automtico, cuando el usuario conecta el dispositivo al equipo. No se requiere accin alguna por parte del usuario.

Creacin de controladores Normalmente

son los fabricantes del hardware quienes escriben sus controladores, ya que conocen mejor el funcionamiento interno de cada aparato, pero tambin se encuentran controladores libres, por ejemplo en los sistemas operativos libres. En este caso, los creadores no son de la empresa fabricante, aunque a veces hay una cooperacin con ellos, cosa que facilita el desarrollo. Si no la hay, el procedimiento necesita de ingeniera inversa y otros mtodos

Creacin de controladoresLos

controladores de dispositivo (device drivers en ingls) son programas aadidos al ncleo del sistema operativo, concebidos inicialmente para gestionar perifricos y dispositivos especiales.

Creacin de controladoresLos

controladores de dispositivo han sido tradicionalmente programas binarios puros, similares a los COM aunque ensamblados con un ORG 0, a los que se les colocaba una extensin SYS. Sin embargo, no hay razn para que ello sea as ya que un controlador de dispositivo puede estar incluido dentro de un programa EXE, con la condicin de que el cdigo del controlador sea el primer

Fallos de controladoresAl

ser una parte crtica del sistema operativo, el fallo de un controlador puede ser ms grave que otros errores de software, pudiendo bloquear la computadore o incluso daar el hardware. Debido a que el hardware es (necesariamente) indeterminista, encontrar y solucionar un fallo en un controlador es una tarea complicada ya que no slo hay que monitorear el programa, sino

Unit I Device DriverUnderstand

Driver and Operating Sy Determine Device-Specific Driver ReMake

Driver Design Decisions Build, Test, and Debug the Driver Provide a Driver Package Distribute a Driver

Device DriverDevice Hardware

Device Driver

Driver

Software

Windows Operating System

Drivers Modesrun in the non privileged processor mode User Mode Use Win32 API

run as part of the operating system can perform certain protected operations and can access system structures Kernel Mode more difficult debugging greater chance of system corruption

Overview of Windows Driver DevelopmentSteps

to develop a driver through the planning and decision-making process involved in developing a Windows device driver, starting with design and continuing through distribution. Given the wide variation among devices and the intricate nature of driver operations, no single driver design or development plan can cover every possible technology.

Overview of Windows Driver DevelopmentHowever,

any driver development project will proceed more smoothly and efficiently if you: Follow industry standards for hardware and drivers Understand important operating system and driver concepts Decide early in the design process which operating system platforms to support Test for device and driver compatibility with all Windows operating systems you plan to

Overview of Windows Driver Development Steps

in Driver Development

Step 1: Understand Driver and Operating System Basics Before starting design, you should understand the fundamentals of how drivers work in Windows operating systems. Knowing the fundamentals will help you make appropriate design decisions and streamline your development process. Step 2: Determine Device-Specific Driver Requirements Each Windows device class has specific hardware and software requirements. Devices and drivers should conform to these requirements to operate correctly with other system components. Understanding and following these requirements during hardware and software design can save you time and money. Step 3: Make Driver Design Decisions Before you

Overview of Windows Driver Development Steps

in Driver Development

Step 4: Build, Test, and Debug the Driver Building a driver is not the same as building a user-mode application. This section gives tips on how to use the "free" and "checked" operating system builds and how to configure the build environment for a driver. Iterative testing and debugging on as many hardware configurations as possible helps to ensure a working driver. Step 5: Provide a Driver Package Exactly how a driver must be installed depends on the type of driver and device. This section helps you determine which device installation components you must provide, and outlines what Windows expects during device installation. Step 6: Distribute a Driver The final step in driver development is to distribute the driver. If your driver meets the quality standards defined for the

Understanding Driver and Operating System BasicsOverview

of System Components User-Mode Drivers and Kernel-Mode Layered Driver Architecture Device Drivers and File System DrivWindows

Driver Model (WDM) Defin Operating System Concepts for Driv

Understanding Driver and Operating System Basics

Overview of System Components for Driver Writers Windows Component Overview The figure shows, the operating system includes kernel-mode components and user-mode components. User-mode drivers and applications can use the routines defined in the Microsoft Win32 application programming interface (API. The Win32 API, in turn, calls exported driver and operating system kernel routines. Kernel-mode drivers can use support routines that are defined and exported by various components of the operating system kernel. These routines support I/O, configuration, Plug and Play, power management, memory management, and numerous other operating system features.

Understanding Driver and Operating System Basics User-Mode Drivers and Kernel-Mode Drivers Windows drivers can run in either user mode or kernel mode. User-mode drivers run in the non privileged processor mode User-mode drivers cannot gain access to system data except by calling the Win32 API which, in turn, calls system services. Kernel-mode drivers run as part of the operating system's executive. User-mode and kernel-mode drivers have different structures, different entry points,

Understanding Driver and Operating System Basics Windows Driver Model (WDM) Defined Any kernel-mode device driver that conforms to the Windows Driver Model (WDM) is called a WDM driver. WDM defines an approach to writing kernel-mode device drivers for all Windows operating systems. Any device driver that will run on Windows2000 and later operating systems must be a WDM driver. With a few special-case statements in the code, WDM drivers can be source-

Understanding Driver and Operating System Basics Layered Driver ArchitectureWindows operating systems support a layered driver architecture. Every device is serviced by a chain of drivers, typically called a driver stack. Each driver in the stack isolates some hardware-dependent features from the drivers above it. The following figure

Understanding Driver and Operating System Basics

Layered Driver Architecture Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32 API or a routine that is exposed by the usermode client driver. A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request.

Understanding Driver and Operating System Basics Layered Driver Architecture A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode. A device class and miniclass driver pair provides the bulk of the device-specific support.

Making Driver Design DecisionsAfter you determine what kind of driver your device requires, you can begin designing your driver. The following topics describe several design issues that you should consider:

Choosing a Driver Model Choosing a Programming Language Driver Design and Implementation Strategies Creating Reliable and Secure Drivers Using the WDK Samples Upgrading a Legacy Driver Writing Drivers for Multiple Platforms and Operating Planning for 64 Bits Providing Driver Localization

Making Driver Design Decisions Choosing a Driver Model Most Windows drivers are kernel-mode drivers . Drivers use a set of interfaces that enable the driver to communicate with kernelmode Windows components, such as the I/O manager and the Plug and Play (PnP) manager.

Making Driver Design Decisions Choosing a Programming Language For maximum portability, drivers should be written in a high-level language,typically C for kernel-mode drivers, and C or C++ for user-mode drivers.

Creating Reliable and Secure Drivers Validate input parameters. Validate registry contents. Use safe string functions. Provide secure device installations.

Making Driver Design Decisions

Making Driver Design Decisions Using the DDK Samples The Windows DDK includes sample source code for a variety of drivers. The samples can be useful guides for writing your own drivers. When you install the DDK, samples are installed in subdirectories of the \src directory. If you choose to base your code on one or more of the samples, keep in mind the following:

Some samples are not complete drivers, but instead provide guidelines for how such drivers could be written. For instance, samples might omit error-handling code in the interest of brevity and clarity. Make sure to use a driver sample that was written for the type of driver that you are writing. For example, if you are writing a function driver, use a sample function driver. If you are writing a storage filter driver, use a sample storage filter driver.

Making Driver Design Decisions Upgrading a Legacy DriverAlthough Microsoft Windows2000 and later versions of the operating system continue to support some legacy drivers written for WindowsNT, new drivers should be WDM drivers. The system-supplied device drivers have been modified to support WDM, which includes Plug and Play and power management.

Making Driver Design Decisions Upgrading a Legacy Driver If you choose to try to upgrade a driver, your driver will require the following types of changes: Updating or replacing the driver INF file. support for Plug and Supporting power management

Making Driver Design Decisions Planning for 64 Bits Whether you are writing a new driver or modifying an existing driver, you should consider making it compatible with 64-bit Windows. The Windows Driver Kit (WDK) includes 64-bit build environments that you can use to create 64-bit drivers. Many of the driver samples included with the WDK are designed for 64-bit compatibility, as noted in the Readme files for the individual samples.

Building, Debugging, and Testing Drivers

This

section provides basic information and guidance on building, debugging and testing drivers.

Signing Software for Use in a Driver Development Environment New uses of code-signing technology in WindowsVista include the following:

A new WindowsVista feature, User Account Control (UAC), verifies signatures and prompts users before allowing executables to run with administrator privileges or exercise administrator privileges. Installation packages and executables that are downloaded with Microsoft Internet Explorer have a default setting of "dont run" when

Signing Software for Use in a Driver Development Environment New uses of code-signing technology in WindowsVista include the following:

Windows Defender is a feature of WindowsVista that protects Windows computers against spyware and malicious code. Plug and Play (PnP) driver installation policy requires that a system administrator manually authorizes the installation of an unsigned driver. Kernel-mode code signing policy on

Signing Drivers During Development and Test On WindowsVista, you should test sign drivers during development and test with a digital signature for the following reasons: To facilitate and automate installation. If a driver is not signed, Plug and Play (PnP) driver installation policy requires that a system administrator manually authorize the installation of an unsigned driver, adding a extra step to the installation process. To be able load kernel-mode drivers on x64based editions of WindowsVista. By default, kernel-mode code signing policy for x64-based versions of WindowsVista requires that a kernel-

Building, Debugging, and Testing Drivers Building, testing, and debugging a driver is an iterative process that involves the following steps: Writing the driver code, which should include debugging routines and macros that are flagged for conditional compilation Creating a driver package to install the driver Building a checked version of the driver

Building, Debugging, and Testing Drivers

Building a production version of the driver that does not include debugging information (commonly referred to as a free version) Test signing the driver package Installing, testing, and debugging the installation of the driver on each target operating system Installing, testing, and debugging the free version of the driver on each target

Building Drivers The WDK includes an environment for building drivers that closely matches the build environment used internally at Microsoft. This environment includes various tools that are useful in developing drivers, including build utilities build.exe and nmake.exe a C compiler (cl.exe), and a linker (link.exe).

You must not build drivers by using the compiler or linker that Microsoft Visual Studio provides.

Building DriversHeader

Files in the Windows Driver Kit WDK contains all of the header files (.h files) that you need to build kernelmode and user-mode drivers. After you have installed the WDK, you can find the header files under the \inc subdirectory.

Building DriversHeader

Files in the Windows Driver Kit Starting with the WindowsVista version of the WDK, the following changes have been made to the content, structure, and organization of the header files:Header files contain version information. Including version information in header files helps to support development of drivers for multiple operating system versions.

Debugging Drivers The Microsoft Windows Driver Development Kit (DDK) includes the Debugging Tools for Windows package. Debugging kernel-mode drivers requires two computers a host computer that runs the debugger and a target computer that runs the driver. The Microsoft Visual Studio debugger can be used to debug user-mode programs on all Windows operating

Testing Drivers Windows Logo TestingMicrosoft's Windows Hardware Quality Labs (WHQL) tests drivers for compliance with the requirements of the Windows Logo Program for hardware. Through this program, device manufacturers can license the Windows logo for use on product packaging, advertising, and other marketing materials for all systems and components that pass compliance testing. Hardware and drivers must pass WHQL testing to receive a Windows logo, to

Testing Drivers Tips for Testing Drivers Run the "Designed for Windows" logo program tests for your device type, even if you do not intend to submit your device and driver for the "Designed for Windows" logo. Test your driver and device on as many different hardware configurations as you possibly can. Varying the hardware can help you find conflicts between devices and other errors in device interactions. Test your driver and device on multiprocessor systems. Race conditions and other timing problems

Testing Drivers Tips for Testing DriversTest your driver and device for specific system and hardware conditions, particularly edge conditions. For example, these conditions might include "D3 hot" and "D3 cold." Make sure your driver and device can return correctly from device power state "D3 hot" (without losing power) and "D3 cold" (when power is removed from the device).

Providing a Driver Package A driver package consists of all

the hardware and software components you must supply in order for your device to be supported under Windows. Installing a device or driver involves system-supplied and vendor-supplied components. The system provides generic installation software for all device classes.

Providing a Driver Package Components of a Driver Package

The device Driver files Installation files Other files

Providing a Driver Components of a Package Driver Package The Device If you're involved in designing and building a new device, follow industry hardware standards. Building devices that conform to industry standards can streamline your driver development process as well as reduce support costs. .

Driver Files The driver is the part of the package that provides the I/O interface for a device. Typically, a driver is a dynamic-link library with the .sys file name extension. Long file names are allowed, except for boot drivers. When a device is installed, Setup copies the .sys file to the %windir%\system32\drivers directory. The software required to support a particular device depends on the features of the device and the bus or port to which it connects. Microsoft ships drivers for many common devices and nearly all buses with the operating system.

Components of a Driver Package

Providing a Driver Package Installation Files In addition to the device and the driver, a driver package also contains one or more of the following files, which provide driver installation: A device setup information file (INF file) An INF file contains information that the system Setup components use to install support for the device. Setup copies this file to the %windir%\inf directory when it installs the device. Every device must have an INF file.

A driver catalog (.cat) fileA driver catalog file contains a cryptographic hash of each file in the driver package. Windows uses these hashes to verify that the package was not altered after it was published. To ensure that the catalog file is not altered, it should be digitally signed.

One or more co-installersA co-installer is a Microsoft Win32 DLL that assists in device

Providing a Driver PackageComponent Overview InstallationTo install a device or a driver, the operating system requires the following information at a minimum:The name and version number of each operating system on which the device or drivers are supported The device's setup class GUID and setup class Driver version information The names of the driver files along with their source and destination locations Device-specific information, including hardware ID and compatible IDs The name of a catalog (.cat) file information about how and when to load the services provided by each driver

Unit II Windows NT Operating System

API ExamplesCreateFile DeviceIOControl Memory Management Power Management Process Synchronization System Information

Windows ArchitectureSystem Processes Service Control Mgr . LSASS WinLogon User Mode Session Manager SvcHost . Exe WinMgt . Exe SpoolSv . Exe Services . Exe Task Manager Explorer User Application POSIX Subsystem DLLs Windows DLLs OS / 2 Services Applications

Environment Subsystems

Windows

System Threads Kernel Mode

NTDLL . DLL

System Service Dispatcher ( kernel mode callable interfaces ) I / O Mgr Configura tion Mgr ( registry ) Security Reference Monitor Processes & Threads Local Procedure Call Plug and Play Mgr . Virtual Memory Object Mgr . File System Cache Power Mgr . Windows USER , GDI

Device & File Sys . Drivers

Graphics Drivers

Kernel Hardware Abstraction Layer ( HAL ) hardware interfaces ( buses , I / O devices , interrupts , interval timers , DMA , memory cache control , etc ., etc .)

Windows NT Architecture User LevelLogin POSIX MS-DOS Win-32 Win-16 OS/2 Applications/ Processes Security Subsystem POSIX Subsystem Win 32 Subsystem OS/2 Subsystem

Kernel Level

Windows NT Executive Services I/O Manager Cache Mgr File System Nwork Drv.s Device Drv.s Microkernel (NT Kernel) Object Manager Security Reference Monitor Process Manager Local Procedure Call Facility Virtual Memory Manager

Hardware Abstraction Layer

MACHINE HARDWARE

Executive

The executive is the main part of the kernel layer and performs most of the traditional operating system functions. It is made up of a group of components, the main ones being: The I/O Manager, Object Manager, Security Reference Monitor, Process Manager, Local Procedure Call Facility and the Virtual Memory Manager.

The Object Manager

The Object Manager is used to define and manage objects which represent resources within the computer system. An example is where the Process Manager uses the object manager to define an object which tracks all the processes which are running. Part of the object management duties include identifying the objects corresponding to resources and tracking how many systems are accessing a resource. When no system is accessing a resource then the object representing the resource can be deleted. As most of the native system services are resource related they almost always invoke the object manager functions. The object manager can also call other executive subsystems when necessary.

Object Manager

The Windows kernel-mode object manager component manages objects. Files, devices, synchronization mechanisms, registry keys, and so on, are all represented as objects in kernel mode. Each object has a header (containing information about the object such as its name, type, and location), and a body (containing data in a format determined by each type of object). Windows has more than 25 types of objects. A few of the types are: Files Devices Threads Processes Events Mutexes Semaphores Registry keys Jobs Sections Access tokens Symbolic links

The Process Manager

The Process Manager works with the kernel, which carries out scheduling, to define the process and thread objects. It adds the process identifier (PID) to each of the kernel's process objects.

The Security Reference Monitor

The Security Reference Monitor (SRM) is closely associated with the object manager and is responsible for the strong security capabilities in Windows NT. The object manager calls the SRM to provide a security check whenever an application wishes to open an object or perform an operation on an object like a read or write. The SRM uses the NT security procedures to validate whether the operation can go ahead and whether it should be logged. The SRM uses a security model based on Security Identifiers (SID) and Discretionary Access Control Lists (DACL).

Security Reference Monitor An

increasingly important aspect of operating systems is security. Before an action can take place, the operating system must be sure that the action is not a violation of system policy. For example, a device may or may not be accessible to all requests. When creating a driver, you may want to allow some requests to succeed or fail, depending on the permission of the entity making the request. Windows uses an access control list (ACL) to determine which objects have what security. The Windows kernel-mode security reference monitor provides routines for your driver to work with access control.

The Virtual Memory Manager

The Virtual Memory Manager creates and manages memory maps for processes and controls physical memory allocation. NT can address up to 4GB of memory and this is split between user and kernel mode memory with the first 2GB going to user mode applications. The memory is managed in pages of 4kB in Intel x86 systems, different page sizes are used in other systems. The VMM allows the total memory required by an application to exceed the memory available in the computer. This is done by using physical memory such as the hard disk, and memory from a paging file when it is required by an application. The VMM allows programs to share individual files and data. When any one then wishes to write to the shared data it gets its own individual copy. The VMM also tunes the memory available to programs by allocating extra memory where it is needed and ensuring all

Memory Manager The

Windows kernel-mode memory manager component manages physical memory for the operating system. This memory is primarily in the form of RAM (Random Access Memory). The memory manager manages memory by performing the following major tasks: Managing the allocation and de-allocation of memory virtually and dynamically. Supporting the concepts of memory-mapped files, shared memory, and copy-on-write.

I/O Manager

A computer consists of various devices that provide input and output (I/O) to and from the outside world. Typical devices are keyboards, mice, audio controllers, video controllers, disk drives, networking ports, and so on. Device drivers provide the software connection between the devices and the operating system. For this reason, I/O is very important to the device driver writer. The Windows kernel-mode I/O manager manages the communication between applications and the interfaces provided by device drivers. Because devices operate at speeds that may not match the operating system, the communication between the operating system and device drivers is primarily done through I/O request packets (IRPs). These packets are similar to network packets or Windows message packets. They are passed from operating system to specific drivers and from one driver to another. The Windows I/O system provides a layered driver model called stacks. Typically IRPs go from one driver to another in the same stack to facilitate communication. For example, a joystick driver would need to communicate to a USB hub, which in turn would need to communicate to a USB host controller,

The Local Procedure Call Facility Procedure Call Facility optimises communications The Local

for applications, including the operating system environments. Communication between functions and objects in the operating system is done via messages which are passed in different ways depending on their size. Small messages of less than 256 bytes are copied directly while larger ones are transferred using shared memory. From NT 3.51 to NT 4.0 Microsoft moved the GDI (graphics device interface) out of the user mode and into the kernel to reduce to number of calls using the LPC. This led to much improved responsiveness, especially for graphics operations but at the cost of some stability.

The Kernel

The kernel contains the NT thread scheduler called the dispatcher. The dispatcher is a pre-emptive scheduler, time is divided into slices called quantums and each thread can operate for a quantum and then is pre-empted to allow another thread to run. The kernel operates more closely with hardware than the executive, and hence contains processor specific code. If the computer has multiple CPUs the kernel synchronises activity between them to optimise performance. Kernel code does not run in threads The kernel also implements synchronisation and mutual exclusion. It has it's own object types so applications can access them from user mode via the native API.

Hardware Abstraction Layer

The HAL provides NT's interface to the CPU. To make NT portable as much of the processor specific code as possible was restricted to here. So the HAL together with the kernel are dynamically replaceable between processors families. The HAL exports a common processor model which hides the differences in processor types. This common processor used by device drivers.

Processes and Threads

NT is a multithreading operating system. It runs multiple threads at once and can stop any particular thread from executing. NT views applications as processes which have to be executed. A process will consist of a virtual address space, executable instructions and a set of resources. Typically an application will consist of only one process and each process will consist of one or more threads which are the parts of an application that execute. Usually there is one thread per process though applications can have more. Multiple threads allow a program to have several parts operating at once. Deciding how to execute the threads and in what order is the job of the operating system scheduler. No distinction is made between threads from differing

Process and Thread Manager

A process is a software program that is currently running in Windows. Every process has an ID, a number that identifies it. A thread is an object that identifies which part of the program is running. Each thread has an ID, a number that identifies it. A process may have more than one thread. The purpose of a thread is to allocate processor time. On a machine with one processor, more than one thread can be allocated, but only one thread can run at a time. Each thread only runs a short time and then the execution is passed on to the next thread, giving the user the illusion that more than one thing is happening at once. On a machine with more than one processor, true multi-threading can take place. If an application has multiple threads, the threads can run simultaneously on different processors. The Windows kernel-mode process and thread manager handles the execution of all threads in a process. If threads from different processes attempt to use the same resource at the same time, problems can occur. The technique of making sure that threads from different processes don't

The NTFS File System

From the start NTFS was designed as a 32-bit file system which made it more scaleable. A key parameter for a file system is how it addresses a hard disk. FAT uses a 16 bit entry to address clusters on the disk. For a modern GigaByte size hard disks this means the clusters, which are the minimum size storage unit on the disk, have to be quite large in size. On a 4GB disk the clusters will be 64k. NT uses a different character set to FAT. Instead of the 8-bit ASCII set NTFS uses 16-bit Unicode which allows a much greater range of character types. This is particularly important for international users who wish to name files in their native languages. Microsoft also built a security system into NTFS, The model used is the same as in the operating system and uses Discretionary Access Control Lists (DACL) and System Access Control Lists (SACL). These control who can perform particular operations on a file and determine what file actions are logged when they occur.

The Remote Procedure Call

The Remote Procedure Call (RPC) functions allow applications to carry out distributed computing and access resources on other computers across a network. With the RPCs you can create distributed applications which consist of a client that presents data to the user and a server which collates data and carries out most of the computing tasks for the client. The distributed application makes procedure calls to be executed on another computer. To the application they appear the same as a local procedure call. But they invoke procedures which call the RPC library which executes the calls in the remote address space on another machine across the network.

Configuration Manager

In the earlier days of Microsoft Windows, applications and the operating system stored configuration values in "INI" (initialization) files. This provided a simple way to store state values that could be preserved from one Windows session to the next. However, as the Windows environment became more complex, a new system of storing persistent information about the operating system and applications was needed. The Windows Registry was created to store data about hardware and software. The Windows kernel-mode configuration manager manages the registry.

Kernel Transaction Manager When

you are dealing with multiple reads and writes on one or more data stores, and the operations must all atomically succeed or fail to preserve the integrity of the data, you might want to group the operations together as a single transaction. If all of the operations within the transaction succeed, the transaction can be committed so that all the changes persist as an atomic unit. If a failure occurs, the transaction can be rolled back so that the data stores are restored to their original state. The kernel transaction manager (KTM) is the Windows kernel-mode component that implements transaction processing in kernel

Power Manager

Windows uses power management technology to reduce power consumption for PCs in general and for battery-powered laptops in particular. For example, a Windows computer can be put in a sleep or hibernation state. A complex power management system for computer devices has evolved so that when the computer begins to shut down or go to lower power consumption, the attached devices can also be powered down in a proper manner so that no data is lost. But these devices need a warning that the power status in changing and they may also need to be part of a communications loop that tells the controlling device to wait until they can shut down down properly. The Windows kernel-mode power manager manages the orderly change in power status for all devices that support power state changes. If you are writing a driver that can be affected by power-state changes, you must be able to process the following types of information in your driver code:

Plug and Play Manager Plug

and Play (Pnp) is a combination of hardware technology and software techniques that enables a PC to recognize when a device is added to the system. With PnP, the system configuration can change with little or no input from the user. For example, when a USB drive is plugged in, Windows can detect the drive and add it to the file system automatically. However, to do this, the hardware must follow certain requirements and so must the driver. The PnP manager is actually a subsystem of the I/O manager.

Windows Kernel Prefixes

The abbreviated prefixes refer to the individual components of the Windows kernel-mode operating system. Each component represents a specific functionality that the operating system provides. The prefixes are a useful shorthand for quickly recognizing the basic functionality and location of each routine. This is particularly useful for reading source code. For example, if you see a routine that is prefixed Mm, you will know that it manages memory. Aux - Auxiliary Library Routines that allow access to system capabilities not available directly from the kernel

Clfs Common Log File System (CLFS) Library Routines that allow access to the CLFS library

Cc Cache Manager Routines that allow access to the Cache Manager

Cm Configuration Manager Routines that allow access to the Configuration Manager

Windows Kernel Prefixes

Ex Executive Library Routines that allow access to the system Executive library. This library provides general policy decisions not covered by other kernel-mode managers or libraries. Flt Filter Manager Routines that allow access to the filter manager Hal Hardware Abstraction Layer (HAL) Routines that allow access to the low-level Hardware Abstraction Layer Io I/O Manager Routines that allow access to the I/O Manager Ke Core Kernel Library Routines that allow access to the core Kernel Library

Windows Kernel Prefixes Mm

Memory Manager Routines that allow access to the Memory Manager Nt User-mode Native Services Routines that allow access to user-mode Native Services

Ob Object Manager Routines that allow access to the Object Manager Po Power Manager Routines that allow access to the Power Manager Ps Process and Thread Library Routines that allow access to the Process and Thread Library

Windows Kernel Prefixes

Rtl Run-Time Library Routines that allow access to the kernel-mode Run-time Library, also includes the Safe String Library FsRtl File System Run-time Library Routines that allow access to the File System Run-time Library Se Security Reference Monitor Routines that allow access to the Security Reference Monitor Wmi Windows Management Instrumentation Library Routines that allow access to the Windows Management Instrumentation Library Zw Kernel-mode wrappers for Native Services Routines that provide kernel-mode access to user-mode

Object Manager Routines InitializeObjectAttributes ObDereferenceObject ObDereferenceObjectDeferDelete ObDereferenceObjectDeferDeleteWithTa g ObDereferenceObjectWithTag ObGetObjectSecurity ObReferenceObject ObReferenceObjectWithTag ObReferenceObjectByHandle ObReferenceObjectByHandleWithTag ObReferenceObjectByPointer ObReferenceObjectByPointerWithTag ObRegisterCallbacks ObReleaseObjectSecurity ObUnRegisterCallbacks

Object Memory Routines MmAdvanceMdl MmAllocateContiguousMemory MmAllocateContiguousMemorySpecifyCache MmAllocateContiguousMemorySpecifyCacheNode MmAllocateMappingAddress MmAllocateNonCachedMemory MmAllocatePagesForMdl MmAllocatePagesForMdlEx MmBadPointer MmBuildMdlForNonPagedPool MmCreateMdl MmFreeContiguousMemory MmFreeContiguousMemorySpecifyCache MmFreeMappingAddress MmFreeNonCachedMemory MmFreePagesFromMdl MmGetMdlByteCount

Object Memory Routines MmLockPagableCodeSection MmLockPagableDataSection MmLockPagableSectionByHandle MmMapIoSpace MmMapLockedPages MmMapLockedPagesSpecifyCache MmMapLockedPagesWithReservedMapping MmPageEntireDriver MmPrepareMdlForReuse MmProbeAndLockPages MmProtectMdlSystemAddress MmQuerySystemSize MmResetDriverPaging MmSecureVirtualMemory MmSizeOfMdl MmUnlockPagableImageSection MmUnlockPages MmUnmapIoSpace MmUnmapLockedPages MmUnmapReservedMapping MmUnsecureVirtualMemory Mm64BitPhysicalAddress ADDRESS_AND_SIZE_TO_SPAN_PAGES ARGUMENT_PRESENT BYTE_OFFSET

Process and Thread Manager Routines PsCreateSystemThread PsGetCurrentProcess PsGetCurrentProcessId PsGetCurrentThread PsGetCurrentThreadId PsGetProcessCreateTimeQuadPart PsGetProcessId PsGetVersion PsInitialSystemProcess PsIsSystemThread PsRemoveCreateThreadNotifyRoutine PsRemoveLoadImageNotifyRoutine PsSetCreateProcessNotifyRoutine PsSetCreateProcessNotifyRoutineEx PsSetCreateThreadNotifyRoutine PsSetLoadImageNotifyRoutine PsTerminateSystemThread

I/O Manager Routines IoAcquireCancelSpinLock IoAcquireRemoveLock IoAcquireRemoveLockEx IoAdjustPagingPathCount IoAllocateAdapterChannel IoAllocateController IoAllocateDriverObjectExtension IoAllocateErrorLogEntry IoAllocateIrp IoAllocateMdl IoAllocateWorkItem IoAssignArcName IoAssignResources IoAttachDevice IoAttachDeviceByPointer IoAttachDeviceToDeviceStack IoBuildAsynchronousFsdRequest IoBuildDeviceIoControlRequest IoBuildPartialMdl IoBuildSynchronousFsdRequest IoCallDriver IoCancelIrp IoCheckShareAccess IoCompleteRequest IoConnectInterrupt IoConnectInterruptEx IoCopyCurrentIrpStackLocationToNext IoCreateController IoCreateDevice

I/O Manager Routines IoCreateDeviceSecure IoCreateFile IoCreateNotificationEvent IoCreateSymbolicLink IoCreateSynchronizationEvent IoCreateUnprotectedSymbolicLink IoCsqInitialize IoCsqInitializeEx IoCsqInsertIrp IoCsqInsertIrpEx IoCsqRemoveIrp IoCsqRemoveNextIrp IoDeassignArcName IoDeleteController IoDeleteDevice IoDeleteSymbolicLink IoDetachDevice

I/O Manager Routines IoFreeWorkItem IoGetAffinityInterrupt IoGetAttachedDeviceReference IoGetBootDiskInformation IoGetConfigurationInformation IoGetContainerInformation IoGetCurrentIrpStackLocation IoGetCurrentProcess IoGetDeviceInterfaceAlias IoGetDeviceInterfaces IoGetDeviceNumaNode IoGetDeviceObjectPointer IoGetDeviceProperty IoGetDevicePropertyData IoGetDeviceToVerify IoGetDmaAdapter IoGetDriverObjectExtension

I/O Manager Routines IoInitializeRemoveLock IoInitializeRemoveLockEx IoInitializeTimer IoInitializeWorkItem IoInvalidateDeviceRelations IoInvalidateDeviceState IoIs32bitProcess IoIsErrorUserInduced IoIsWdmVersionAvailable IoMakeAssociatedIrp IoMapTransfer IoMarkIrpPending IoOpenDeviceInterfaceRegistryKey IoOpenDeviceRegistryKey IoQueryDeviceDescription IoQueueWorkItem IoQueueWorkItemEx

I/O Manager Routines IoReleaseRemoveLockAndWait IoReleaseRemoveLockAndWaitEx IoReleaseRemoveLockEx IoRemoveShareAccess IoReportDetectedDevice IoReportResourceForDetection IoReportResourceUsage IoReportTargetDeviceChange IoReportTargetDeviceChangeAsynchronous IoRequestDeviceEject IoRequestDpc IoReuseIrp IoSetCancelRoutine IoSetCompletionRoutine IoSetCompletionRoutineEx IoSetDeviceInterfaceState IoSetDevicePropertyData

I/O Manager Routines IoStartTimer IoStopTimer IoUnregisterContainerNotification IoUninitializeWorkItem IoUnregisterPlugPlayNotification IoUnregisterPlugPlayNotificationEx IoUnregisterShutdownNotification IoUpdateShareAccess IoValidateDeviceIoControlAccess IoVerifyPartitionTable IoVolumeDeviceToDosName IoWithinStackLimits IoWMIAllocateInstanceIds IoWMIDeviceObjectToProviderId IoWMIDeviceObjectToInstanceName IoWMIExecuteMethod IoWMIHandleToInstanceName

Power Manager Routines PoCallDriver PoClearPowerRequest PoCreatePowerRequest PoDeletePowerRequest PoEndDeviceBusy PoGetSystemWake PoQueryWatchdogTime PoRegisterDeviceForIdleDetection PoRegisterPowerSettingCallback PoRegisterSystemState PoRequestPowerIrp PoSetDeviceBusy PoSetDeviceBusyEx PoSetPowerRequest PoSetPowerState PoSetSystemState PoSetSystemWake PoStartDeviceBusy PoStartNextPowerIrp PoUnregisterPowerSettingCallback PoUnregisterSystemState

Configuration Manager RoutinesCmCallbackGetKeyObjectID CmGetBoundTransaction CmGetCallbackVersion CmRegisterCallback CmRegisterCallbackEx CmSetCallbackObjectContext CmUnRegisterCallback

Kernel Transaction Manager (KTM) Routines Transaction Manager Object Routines Transaction Object Routines Enlistment Object Routines Resource Manager Object Routines KTM Structures KTM Enumerations

Security Reference Monitor RoutinesSeAccessCheck SeAssignSecurity SeAssignSecurityEx SeDeassignSecurity SeSinglePrivilegeCheck SeValidSecurityDescriptor

Core Kernel Library Support Routines KeAcquireSpinLockRaiseToSynch KeBreakinBreakpoint KeEnterKernelDebugger KeFlushWriteBuffer KeGetBugMessageText KeRaiseIrqlToSynchLevel KeRemoveByKeyDeviceQueueIfBusy KeSetTimeUpdateNotifyRoutine

Executive Library Support Routines ExAcquireFastMutex ExAcquireFastMutexUnsafe ExAcquireResourceExclusive ExAcquireResourceExclusiveLite ExAcquireResourceShared ExAcquireResourceSharedLite ExAcquireSharedStarveExclusive ExAcquireSharedWaitForExclusive ExAllocateFromLookasideListEx ExAllocateFromNPagedLookasideList ExAllocateFromPagedLookasideList ExAllocateFromZone ExAllocatePool ExAllocatePoolWithQuota

Run-Time Library (RTL) RoutinesFirstEntrySList InitializeListHead InsertHeadList InsertTailList IsListEmpty PopEntryList PushEntryList RemoveEntryList RemoveHeadList RemoveTailList RtlAnsiCharToUnicodeChar RtlAnsiStringToUnicodeSize RtlAnsiStringToUnicodeString RtlAppendUnicodeStringToString RtlAppendUnicodeToString

DMA Library RoutinesAllocateAdapterChannel AllocateCommonBuffer BuildMdlFromScatterGatherList BuildScatterGatherList CalculateScatterGatherList FlushAdapterBuffers FreeAdapterChannel FreeCommonBuffer FreeMapRegisters GetDmaAlignment GetScatterGatherList MapTransfer PutDmaAdapter PutScatterGatherList ReadDmaCounter

HAL Library Routines HalAllocateCommonBuffer HalAllocateHardwareCounters HalAssignSlotResources HalExamineMBR HalFreeCommonBuffer HalFreeHardwareCounters HalGetAdapter HalGetBusData HalGetBusDataByOffset HalGetDmaAlignmentRequirement HalGetInterruptVector HalReadDmaCounter HalReturnToFirmware HalSetBusData HalSetBusDataByOffset HalTranslateBusAddress READ_PORT_BUFFER_UCHAR READ_PORT_BUFFER_ULONG READ_PORT_BUFFER_USHORT READ_PORT_UCHAR READ_PORT_ULONG

HAL Library Routines READ_PORT_BUFFER_USHORT READ_PORT_UCHAR READ_PORT_ULONG READ_PORT_USHORT READ_REGISTER_BUFFER_UCHAR READ_REGISTER_BUFFER_ULONG READ_REGISTER_BUFFER_ULONG64 READ_REGISTER_BUFFER_USHORT READ_REGISTER_UCHAR READ_REGISTER_ULONG READ_REGISTER_ULONG64 READ_REGISTER_USHORT WRITE_PORT_BUFFER_UCHAR WRITE_PORT_BUFFER_ULONG WRITE_PORT_BUFFER_USHORT WRITE_PORT_UCHAR WRITE_PORT_ULONG WRITE_PORT_USHORT WRITE_REGISTER_BUFFER_UCHAR WRITE_REGISTER_BUFFER_ULONG WRITE_REGISTER_BUFFER_ULONG64 WRITE_REGISTER_BUFFER_USHORT WRITE_REGISTER_UCHAR WRITE_REGISTER_ULONG WRITE_REGISTER_ULONG64 WRITE_REGISTER_USHORT

CLFS Library RoutinesClfsAddLogContainer ClfsAddLogContainerSet ClfsAdvanceLogBase ClfsAlignReservedLog ClfsAllocReservedLog ClfsCloseAndResetLogFile ClfsCloseLogFileObject ClfsCreateLogFile ClfsCreateMarshallingArea ClfsCreateScanContext ClfsDeleteLogByPointer ClfsDeleteLogFile ClfsDeleteMarshallingArea ClfsFlushBuffers ClfsFlushToLsn ClfsGetContainerName

WMI Library Routines WmiCompleteRequest WmiFireEvent WmiQueryTraceInformation WmiSystemControl WmiTraceMessage WmiTraceMessageVa WMI Library Callback Routines

The WIN32 API

The Win32 API was developed by Microsoft as their own 32-bit API to compete with the POSIX and OS/2 APIs and has proved to be extremely successful. Win32 provides a set of functions, messages and structures to give applications access to the features of the operating system in a standard and consistent fashion. The Win32 API can be split into five general functional categories.

Windows Management GDI - Graphics Device Interface System Services Multimedia

Remote Procedure Calls

The Windows Management

The Windows Management set of functions allow applications to use the standard Windows graphic user interface features. Usually there is one window per application and this can be used for display output and user input. The API defines window classes and procedures to be used by the applications and these give the appearance and behaviour of the windows. Input from the mouse and keyboard is passed as messages by message functions to the correct application in the window and to the appropriate window procedure. The functions also provided for dialog boxes, scrolling text, entering text and all the other features used in the Windows GUI. The functions also generate the output for the windows. This is done using the GDI functions to provide the instructions to the display hardware. Some of the things involved are: applications shouldn't take all the screen and when a window is resized the API will request the application to paint the new window or window position.

The Graphics Device Interface

The Graphics Device Interface (GDI) provides functions and related structures to allow applications to generate graphical output for displays and devices like printers. The GDI functions allow lines, curves, bitmaps, text etc to be drawn and be passed to hardware devices. Applications direct output to a device by creating a 'context' for that device. A handle for the device is returned by the GDI. Handles are used by the application to identify the device and get information on it and it's capabilities. Applications use attribute functions to set selections and operating modes for the selected device. Operating modes includes things like brush types, background colours etc.

The System Services

The System Services were mentioned before but additional information on them is given here. The system services are the set of functions which give applications access to the resources of a computer, and the features of the underlying operating system, like memory, files systems and processes. An application uses the system services to manage and monitor the resources it needs to complete it's task. They support file I/O functions and provide methods for applications to share resources with other applications using Dynamic Link Libraries (DLLs). Useful procedures are put in a DLL and applications can access them with DLL functions. System information functions allow applications get information about the computer such as what input devices are present and what size the screen is.

Multimedia Functions

The range of Multimedia Functions give applications access to audio and video and provide services for file I/O, media control, joysticks and timers. The different types of multimedia functions include audio functions to play and record audio data. This is done with a variety of formats including waveform, MIDI, etc. The audio functions have the capability to use compression and decompression and sound mixing. Video functions are used to capture video, compress the clips and control payback. Playback can be done using the Media Control Interface (MCI) which is controlled with the video functions. There also are a range of file I/O functions which are used to store and retrieve the different types of multimedia files.

Windows API

The functionality provided by the Windows API can be grouped into eight categories Base Services Provide access to the fundamental resources available to a Windows system. Included are things like file systems, devices, processes and threads, and error handling. These functions reside in kernel.exe, krnl286.exe or krnl386.exe files on 16-bit Windows, and kernel32.dll on 32bit Windows. Advanced Services Provide access to functionality that is an addition on the kernel. Included are things like the Windows registry, shutdown/restart the system (or abort), start/stop/create a Windows service, manage user accounts. These functions reside in advapi32.dll on 32-bit Windows.

Windows API Graphics

Device Interface Provides functionality for outputting graphical content to monitors, printers and other output devices. It resides in gdi.exe on 16-bit Windows, and gdi32.dll on 32-bit Windows in user-mode. Kernel-mode GDI support is provided by win32k.sys which communicates directly with the graphics driver. User Interface Provides the functionality to create and manage screen windows and most basic controls, such as buttons and scrollbars, receive mouse and keyboard input, and other functionality associated with the GUI part of Windows. This functional unit resides in user.exe on 16-bit Windows, and user32.dll on 32-bit Windows.

Windows API (999)

Common Dialog Box Library Provides applications the standard dialog boxes for opening and saving files, choosing color and font, etc. The library resides in a file called commdlg.dll on 16-bit Windows, and comdlg32.dll on 32-bit Windows. It is grouped under the User Interface category of the API. Common Control Library Gives applications access to some advanced controls provided by the operating system. These include things like status bars, progress bars, toolbars and tabs. The library resides in a DLL file called commctrl.dll on 16-bit Windows, and comctl32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.

Windows API

Windows Shell Component of the Windows API allows applications to access the functionality provided by the operating system shell, as well as change and enhance it. The component resides in shell.dll on 16bit Windows, and shell32.dll on 32-bit Windows. The Shell Lightweight Utility Functions are in shlwapi.dll. It is grouped under the User Interface category of the API. Network Services Give access to the various networking capabilities of the operating system. Its sub-components include NetBIOS, Winsock, NetDDE, RPC and many others.

Windows API

Web The Internet Explorer web browser also exposes many API's that are often used by applications, and as such could be considered a part of the Windows API. Internet Explorer has been included with the operating system since Windows 98 Second Edition, and has provided web related services to applications since Windows 98. Specifically, it is used to provide: An embeddable web browser control, contained in shdocvw.dll and mshtml.dll. The URL monitor service, held in urlmon.dll, which provides COM objects to applications for resolving URLs. Applications can also provide their own URL handlers for others to use. A library for assisting with multi-language and international text support (mlang.dll). DirectX Transforms, a set of image filter components. XML support (the MSXML components, held in msxml*.dll).

Windows API

Multimedia Microsoft has provided the DirectX set of APIs as part of every Windows installation since Windows 95 OSR2. DirectX provides a loosely related set of multimedia and gaming services, including: Direct3D for access to 3D hardware accelerated graphics. DirectDraw for hardware accelerated access to the 2D frame buffer. As of DirectX 9, this component has been deprecated in favor of Direct3D, which provides more general highperformance graphics functionality (as 2D rendering is a subset of 3D rendering). DirectSound for low level hardware accelerated sound card access. DirectInput for communication with input devices such as joysticks and gamepads. DirectPlay as a multiplayer gaming infrastructure. This component has been deprecated as of DirectX 9 and Microsoft no longer recommends its use for game development. DirectShow which builds and runs generic multimedia pipelines. It is comparable to the GStreamer framework and is often used to render in-game videos and build media players ( Windows Media Player is based upon it). DirectShow is no longer recommended for game development.

Windows API

Program interaction The Windows API mostly concerns itself with the interaction between the operating system and an application. For communication between the different Windows applications among themselves, Microsoft has developed a series of technologies alongside the main Windows API. This started out with Dynamic Data Exchange (DDE), which was superseded by Object Linking and Embedding (OLE) and later by the Component Object Model (COM), Automation Objects, ActiveX controls, and the .NET Framework. There is not always a clear distinction between these technologies, and there is quite a lot of overlap.

Unit III Windows Driver Model

Introduction to WDM To

allow driver developers to write device drivers that are source-code compatible across all Microsoft Windows operating systems, the Windows Driver Model (WDM) was introduced. Kernel-mode drivers that follow WDM rules are called WDM drivers. All WDM drivers must: Include wdm.h, not ntddk.h. Be designed as a bus driver, a function driver, or a filter driver, as described in Types of WDM Drivers. Create device objects as described in WDM Device Objects and Device Stacks.

kernel-mode driversHighest-level drivers. Highest-level drivers include file system drivers (FSDs) that support file systems, such as: NTFS File allocation table (FAT) CD-ROM file system (CDFS)

Intermediate drivers, such as a virtual disk, mirror, or device-type-specific class driver. Function drivers control specific peripheral devices on an I/O bus. Filter drivers insert themselves above or below function drivers. Software bus drivers class driver

Lowest-level drivers control an I/O bus to which peripheral devices are connected. Hardware bus drivers are system-supplied and usually control dynamically configurable I/O buses. Legacy drivers that directly control a physical device are lowest-level drivers.

Types of WDM DriversThere

are three kinds of WDM drivers: Bus drivers, which drive an individual I/O bus device and provide per-slot functionality that is deviceindependent. Function drivers, which drive an individual device. Filter drivers, which filter I/O requests for a device, a class of devices, or a bus.

Types of WDM DriversUpper-level filter drivers typically provide added-value features for a device. They are optional .A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required. A function driver can service one or more devices. A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy. The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair.

Lower-level filter drivers typically modify the behavior of device hardware. There can be any number of lower-level filter drivers for a device.

A bus filter driver typically adds value to a bus and is supplied by Microsoft. There can be any number of bus filter drivers for a bus. A bus driver services a bus controller, adapter, or bridge. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine.

Bus Drivers(999)A

bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, such as PCI, PnpISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. A bus driver can service more than one bus if there is more than one bus of the same type on the machine. The primary responsibilities of a bus driver are to: Enumerate the devices on its bus.

Function DriversA

function driver is the main driver for a device . A function driver is typically written by the device vendor and is required . The PnP manager loads at most one function driver for a device. A function driver can service one or more devices. A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy. The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair. In such driver pairs, the minidriver is linked to the second driver, which is a DLL.

Filter DriversFilter

drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices. Bus Filter Drivers Bus filter drivers typically add value to a bus and are supplied by Microsoft or a system OEM. Bus filter drivers are optional. There can be any number of bus filter drivers for a bus. A bus filter driver could, for example, implement proprietary enhancements

Filter DriversLower-Level

Filter Drivers

Lower-level filter drivers typically modify the behavior of device hardware. They are typically supplied by IHVs and are optional. There can be any number of lower-level filter drivers for a device. A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications. A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level

Filter DriversUpper-Level

Filter Drivers

Upper-level filter drivers typically provide added-value features for a device. Such drivers are usually provided by IHVs and are optional. There can be any number of upperlevel filter drivers for a device. An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks. An upper-level class filter driver adds

Hardware Configuration for a USB JoystickIn this figure, the USB joystick plugs into a port on a USB hub. The USB hub in this example resides on the USB Host Controller board and is plugged into the single port on the USB host controller board. The USB host controller plugs into a PCI bus. From a PnP perspective, the USB hub, the USB host

PnP Hardware USB JoystickThe kernel-mode and user-mode HID clients and the application are not drivers but are shown for completeness.

upper-level class filter that adds a macro button feature is written by someone who needs to filter the joystick I/O The function driver, the main driver for the joystick device, is the HID class driver/HID USB miniclass driver pair. (HID represents "Human Interface Device".) The HID USB miniclass driver supports the USB-specific semantics of HID devices, relying on the HID class driver DLL for general HID support. lower-level device filter that enables the joystick to emulate a mouse device. is written by the joystick vendor. The USB hub bus driver that drives the USB hub. The USB hub driver is provided with the system by Microsoft. The bus driver for the USB host controller is implemented as a class/miniclass driver pair. The USB host controller class and miniclass drivers are provided with the system by Microsoft. A PCI driver that drives the PCI bus. This is a PnP bus driver. The PCI bus driver is provided with the system by Microsoft.

Object Based(999)Like

the operating system, drivers are also object-based. File objects represent a user-mode application's connection to a device. Device objects represent each driver's logical, virtual, or physical devices. Driver objects represent each driver's load image.

Objects Names() Drivers

use objects by calling kernel-mode support routines that the I/O manager and other system components export. Kernel-mode support routines generally have names that identify the specific object that each routine manipulates and the operation that each routine performs on that object.

PrefixOperationObject where Prefix Identifies the kernel-mode component that exports the support routine and, usually, the component that defined the object type. Most prefixes have two letters. Operation Describes what is done to the object. Object Identifies the type of object.

For

example, the I/O manager's IoCreateDevice

Device Objects create these device objects by calling an I/O support routine (IoCreateDevice)..

Device Objects For

the keyboard and mouse devices, both their respective port and class drivers create device objects. The port driver creates a physical device object (PDO) to represent the physical port. Each class driver creates its own functional device object (FDO) to represent the keyboard or mouse device as a target for I/O requests.

Each

class driver calls an I/O support routine to get a pointer to the next-lower-level driver's device object, so the class driver can chain itself above that driver, which is the port driver. Then the class driver can send I/O requests down to the port driver for the target PDO representing its physical device. An optional filter driver added to the

Device Objects and Device Stack The device objects for a device are organized into a device stack. Whenever an operation is performed on a device, the system passes an IRP data structure to the driver for the top device object in the device stack. Each driver either handles the IRP or passes it to the driver that is associated with the next-lower device object in the device stack. Device objects are represented by DEVICE_OBJECTstructures, which are

Device Objects and Device Stack The following figure illustrates therelationship between device objects and the I/O manager.

The I/O manager, Plug and Play manager, and power manager use I/O request packets (IRPs) to communicate with kernel-mode drivers, and to allow drivers to communicate with each other. The I/O manager performs the following steps: Accepts I/O requests, which usually originate from user-mode applications. Creates IRPs to represent the I/O requests. Routes the IRPs to the appropriate drivers. Tracks the IRPs until they are completed. Returns the status to the original requester of each I/O operation.

I/O request packets (IRPs)User Mode Application I/o request to IRPs Driver Track IRPs User Mode Application

Drive r Stack

File System Driver Interm.Mirror Driver Disk Driver PnP Hardware bus Driver

An IRP might be routed to more than one driver. For example, a request to

I/O request packets (IRPs) Eeach IRP has a fixed part, and I/O stack

location for each driver that controls the device: In the fixed part (or header), the I/O manager maintains information about the original request, such as thecaller's thread ID and parameters, the address of the device. I/O status block, in which drivers set information about the status of the requested I/O operation.

I/O stack location, the I/O manager sets driverspecific parameters, such asthe function code of the requested operation and the context that the corresponding driver uses to determine what it should do.

Asynchronous I/O The I/O manager provides asynchronous I/O support so that the originator of an I/O request can continue executing, rather than wait for its I/O request to be completed. Asynchronous I/O support improves both the overall system throughput and the performance of any code that makes an I/O request. With asynchronous I/O support, kernel-mode drivers do not necessarily process I/O requests in the same order in which they were sent to the I/O manager. The I/O manager, or a higher-level driver, can reorder I/O requests as they are received. A driver can split a large data transfer request

Asynchronous I/O A driver does not necessarily process each IRP to completion before it starts processing the next incoming I/O request. If the driver supports asynchronous IRP processing, it can send an IRP to the next driver, if necessary, and begin processing the next IRP without waiting for the first one to be completed. The driver can register a "completion routine when another driver has finished processing an IRP. Drivers can maintain state information about their current I/O operations in a

Basic Structure of a WDM Driver

Device DriversA

driver doesnt contain a main program. Instead, it contains a collection of subroutines that the system can call when the system thinks its time to. These subroutines can use helper subroutines in the driver, in static libraries, and in the operating system, but the driver isnt in charge of anything except its own hardware: the system is in charge of everything else, including the decisions about when to run your driver code.

How the System Finds and Loads DriversThe

system uses two slightly different methods, depending on whether the hardware is Plug and Play compatible: A Plug and Play device has an electronic signature that the system can detect. For Plug and Play devices, a system bus driver detects the existence of the hardware and reads the signature to determine what kind of hardware it is. Thereafter, an automatic process based on the registry and INF files allows the system to load the right driver.

A legacy device does not have any electronic signature, so the system cant detect it automatically. The end user must therefore initiate the detection process by invoking the Add New Hardware Wizard, which ends with the system knowing that a certain new piece of hardware exists. Thereafter, the system uses the same automatic registry-and-INF-file process thats used for Plug and Play devices to load the right driver.

How the System Finds and Loads Drivers

Plug and Play DevicesA

Plug and Play device is one that has an electronic signature that a bus driver can interrogate to learn the identity of a device. Here are some examples of these signatures: A PCI card has a configuration space that the PCI bus driver can read via dedicated memory or I/O port addresses. The configuration space contains vendor and product identification information. A USB device returns a device descriptor in response to a standardized control-pipe transaction. The device descriptor contains vendor and product identification information. A Personal Computer Memory Card International Association (PCMCIA) device has attribute memory that the PCMCIA bus driver can read in order to determine the identity of the card.

Standard Driver Routines

Device DriversHeres

a brief snapshot of how the operating system might call subroutines in your driver:

1.The user plugs in your device, so the system loads your driver executable into virtual memory and calls your DriverEntry routine. DriverEntry does a few things and returns. 2.The Plug and Play Manager (PnP Manager) calls your AddDevice routine, which does a few things and returns. 3.The PnP Manager sends you a few IRPs. Your dispatch function processes each IRP in turn and returns. 4.An application opens a handle to your device, where upon the system sends you another IRP. Your dispatch routine does a little work and returns.

Device Drivers

5.- The application tries to read some data, whereupon the system sends you an IRP. Your dispatch routine puts the IRP in a queue and returns. 6.- A previous I/O operation finishes by signaling a hardware interrupt to which your driver is connected. Your interrupt routine does a little bit of work, schedules a DPC, and returns. 7.- Your DPC routine runs. Among other things, it removes the IRP you queued at step 5 and programs your hardware to read the data. Then the DPC routine returns to the system. 8.- Time passes, during which the system makes many other brief calls into your subroutines. 9.- Eventually, the end user unplugs your device. The PnP Manager sends you some IRPs, which you process and return. The operating system calls your DriverUnload routine, which usually just does a tiny amount of work and returns. Then the system removes your driver code from virtual memory.

Drivers and Kernel-Mode Objects

Driver ObjectsDriverEntry is the only driver routine with an exported name. When the I/O Manager needs to locate other driver functions, it uses the Driver object associated with a specific device. This object is basically a catalog that contains pointers to various driver functions. The life of a driver object is explained below. 1.The I/O Manager createsa driver object whenever it loads a driver. If the driver fails during initialization, the I/O Manager deletes the object. 2.During initialization, the DriverEntry routine loads pointers to other driver functions into the driver object. 3.When an IRP is sent to a specific device, the I/O Manager uses the associated driver object to find the right Dispatch routine. 4.If a request involves an actual device operation, the I/O Manager uses the driver object to locate the driver's Start I/O routine. 5.If the driver is unloaded, the I/O Manager uses the driver object to find an Unload routine. When the Unload routine

the system. The Figure illustrates the structure of the driver object. As you can see, the driver object also contains a pointer to a linked list of devices serviced by this driver. A driver's Unload routine can use this list to locate any devices it needs to delete.

Layout of a Driver Object There is a unique driver object for each driver currently loaded in

Device ObjectsBoth the I/O Manager and a driver need to know what's going on with an I/O device at all times. Device objects make this possible by keeping information about the device's characteristics and state. There is one device object for each virtual, logical, and physical device on the system. The life cycle of a device object is shown below. 1.The DriverEntry routine creates a device object for each of its devices. For WDM drivers, the Device object is created by the AddDevice Plug and Play routine. 2.The I/O Manager uses a back-pointer in the device object to locate the corresponding driver object. 3.Various driver routines use the device object to locate the corresponding device extension.. 4.The driver's Unload routine deletes the device object when the driver is unloaded. For WDM drivers, RemoveDevice performs the task of deleting the Device object.

relationship to other structures. Although the device object contains a lot of data, much of it is the exclusive property of the I/O Manager

Layout of the Device Object The Figure illustrates the structure of the device object and its

Device Extensions

Connected to the device object is another important data structure, the device extension. The extension is simply a block of nonpaged pool that the I/O Manager automatically attaches to any device object created. The driver author specifies both the size and contents of the device extension. Typically, it is used to hold any information associated with a particular device. The device extension typically includes A back-pointer to the device object Any device state or driver context information A pointer to the interrupt object and an interrupt-expected flag A pointer to a controller object A pointer to an adapter object and a count of mapping registers

Device Extensions

Since the device extension is driver-specific, its structure must be defined in a driver header file. Although the extension's exact contents depend on what a driver does, its general layout looks something like the following:

typedef struct _DEVICE_EXTENSION {

PDEVICE_OBJECT DeviceObject; // back pointer : // other driver-specific declarations :

} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

Manipulating Device Objects The Table lists many of the I/O Manager functions that operate ondevice objects. The I/O Manager also passes a device object pointer as an argument to most of the routines in a driver.

Kernel: Controller Some

Objects peripheral adapters manage more than

one physical device using the same set of control registers. The floppy disk controller is one example of this architecture. This kind of hardware poses a synchronization dilemma. If the driver tries to perform simultaneous operations on more than one of the connected devices without first synchronizing its access to the shared register space, the control registers receive confusing values. To help with this problem, the I/O Manager provides controller objects.

Kernel: Controller

The life cycle of a typical controller object1.The DriverEntry (or AddDevice) routine creates the Controller object and usually stores its address in a field of each device's Device Extension. 2.Before it starts a device operation, the Start I/O routine asks for exclusive ownership of the controller object on behalf of a specific device. 3.When the controller object becomes available, the I/O Manager grants ownership and calls the driver's ControllerControl routine. This routine sets up the device's registers and starts the I/O operation. As long as this device owns the controller object, any further requests for ownership block at step 2 until the object is released. 4.When the device operation is finished, the driver's DpcForIsr routine releases the Controller object, making it available for use by other pending requests. 5.The driver's Unload routine deletes the controller object when the driver is unloaded.

Objects

Layout of the Controller Object relationship of a Controller object to Figure shows theother system data structures. The only externally visible field in a Controller object is the PVOID ControllerExtension field, which contains a pointer to the extension block.

Controller Extensions

Like device objects, controller objects contain a pointer to an extension structure that can be used to hold any controllerspecific data. The extension is also a place to store any information that's global to all the devices attached to a controller.

S i ce th e co n tro l e r exte n si n i d ri r-sp e ci c , i stru ctu re m u st b e n l o s ve fi ts d e fi e d i a d ri r h e a d e r fi e . A l o u g h th e exte n si n ' exa ct n n ve l th o s co n te n ts d e p e n d o n w h a t a d ri r d o e s, i g e n e ra l l yo u t l o ks ve ts a o so m e th i g l ke th i : n i styp e d e f stru ct _C O N T R O LLE R _E X T E N S I N O { // back pointer PC O N T R O LLE R _O B J C T C o n tro l e rO b j ct E l e : // other driver-specificdeclarations :

Kernel: Adapter Objects

Just as multiple devices on the same controller need to coordinate their hardware access, so it is that devices that perform DMA need an orderly way to share system DMA resources. The I/O Manager uses adapter objects to prevent arguments over DMA hardware. There is one adapter object for each DMA data transfer channel on the system. Like a controller object, an adapter object can be owned by only one device at a time. Before starting a DMA transfer, the Start I/O routine asks for ownership of the adapter object. If the hardware is free, ownership is granted. If not, the device's request is put on hold until the current owner releases the hardware. Obviously, if the device supports only programmed I/O, it has no need for an adapter object.

Kernel: Adapter Objects

The life cycle of the adapter object is described below. 1.The HAL creates Adapter objects for any DMA data channels detected at boot time. 2.The DriverEntry or AddDevice routine locates the adapter object for its device and stores that pointer in the device or controller extension. 3.The Start I/O routine requests ownership of the adapter object on behalf of a specific device. 4.When ownership is granted, the I/O Manager calls the driver's Adapter Control routine. This routine then uses the adapter object to set up a DMA transfer. 5.The driver's DpcForIsr routine may use the adapter object to perform additional operations in the case of a split transfer. 6.When a transfer is finished, DpcForIsr releases the adapter object.

Layout of an Adapter Object Figure illustrates the relationship of adapter objects to other

structures. As the diagram shows, the adapter object is completely opaque and has no externally visible fields. When working with DMA devices, the pointer to the adapter object, as well as the number of mapping registers it supports, should be stored in the device extension or controller extension structure.

Kernel: Interrupt Objects Interrupt objects simply give the kernel's interruptdispatcher a way to find the right service routine when an interrupt occurs. The life cycle of an interrupt object is described below.1.The DriverEntry or AddDevice routine creates an interrupt object for each interrupt vector supported by the device or the controller. 2.When an interrupt occurs, the kernel's interrupt dispatcher uses the Interrupt object to locate the Interrupt Service routine. 3.The Unload or RemoveDevice routine deletes the interrupt object after disabling interrupts from the device.

A driver does not interact with interrupt objects other than to create and delete them. A pointer to the interrupt object is typically stored in the device extension or controller extension.

Layout of an Interrupt Object Figure illustrates the structure of an interrupt object. Like adapter objects,they are completely opaque and have no externally visible fields.

Unit IV Driver Routines

Initialization and Cleanup Routines

DriverEntry Routine

What a DriverEntry Routine Does DriverEntry locates hardware that it will be controlling. That hardware is allocatedit is marked as under the control of this driver. The driver object is initialized by announcing other driver entry points. The announcements are accomplished by storing function pointers directly into the driver object. If the driver manages a multiunit or multifunction controller, IoCreateController is used to create a controller object. A controller extension is then initialized. IoCreateDevice is used to create a device object for each physical or logical device under the control of this driver. A device extension is then initialized. The created device is made visible to the Win32 subsystem by calling IoCreateSymbolicLink. The device is connected to an interrupt object. If the ISR requires the use of a DPC object, it is created and initialized in this step. Steps 4 to 6 are repeated for each physical or logical device controlled by this driver. If successful, DriverEntry should return STATUS_SUCCESS to the I/O Manager.

DriverEntry Routine

Announcing DriverEntry Points is able to locate the The I/O Manager

DriverEntry routine because it has a well-known name. Other driver routines don't have fixed names, so the I/O Manager needs some other way to locate them. The linkage mechanism is the driver object, which contains pointers to other driver functions. A DriverEntry routine is responsible for setting up these function pointers.

Announcing DriverEntry Points code fragment shows how a The followingDriverEntry routine initializes both kinds of function pointers.

pDO->DriverStartIo = StartIo; pDO->DriverUnload = Unload; // // Initialize the MajorFunction Dispatch table // pDO->MajorFunction[ IRP_ MJ_CREATE ] = DispatchCreate; pDO->MajorFunction[ IRP_MJ_CLOSE ] = DispatchClose;

Creating Device ObjectsOnce

hardware is identified and allocated, the next step is to create a device object for each physical or virtual device that is to be exposed to the rest of the system. Most of the work is done by the IoCreateDevice function, which takes a description of the device and returns a device object, complete with an attached device extension.

Creating Device ObjectsIoCreateDevicealso

links the new device object into the list of devices managed by this driver object. Table contains a description of this function. The DeviceType parameter of IoCreateDevice is simply a 16-bit value describing the class of device being added. Microsoft reserves the first half of this range for predefined device types. Above 32767, private device types can be defined. Beware, though, that conflict with another vendor's device is always possible. Currently, Microsoft predefines about 30 device types. The predefined device type values are given symbolic names of the form FILE_DEVICE_XXX (e.g., FILE_DEVICE_DVD).

Creating Device Objects

The following example shows how a basic kernel-mode device driver initializes itself. This first minimal driver must be manually loaded. It does not touch any hardware, but instead creates an internal device name (MINIMAL0) and a symbolic link name (MIN1). It consists of a single source module, Driver.cpp. A header file, Driver.h, declares driver-specific information about our nonhardware device, such as the DEVICE_EXTENSION.DRIVERENTRY

Code Example: Driver Initialization

In our first non-WDM driver example, the DriverEntry routine is small and straightforward. The responsibilities include Announcing other DriverEntry points. For the Minimal driver, the only other routine to announce is the driver's Unload function.

//++

// Function: DriverEntry // Description:

Code Example: DriverEntry

// Initializes the driver, locating and claiming // hardware resources. Creates the kernel objects // needed to process I/O requests. // Arguments: // pDriverObject - Passed from I/O Manager // pRegistryPath - UNICODE_STRING pointer to // registry info (service key) // for this driver // Return value: // NTSTATUS signaling success or failure // NTSTATUS DriverEntry ( IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING pRegistryPath ){ ULONG ulDevi