Drivers and Devices

A driver can be viewed as a kind of dynamic-link library, rather as an executable program. It lives in the kernel memory which is shared by all running applications and is mapped to the upper portion of their address space. The applications cannot access that portion, since processor treats them as a set unprivileged code. On the other hand, drivers can access the lower portion of the address space, private to the application.

Unlike executable programs, drivers have nothing like main function or main thread. They can be also viewed as a set of callback routines that are invoked by the kernel when needed. Each driver has a routine called DriverEntry that is invoked when the driver is loaded into the memory and the purpose of which is to perform necessary initialization. So, its purpose is very similar to the DLLMain routine in the world of dynamic-link libraries.

It is not possible to communicate with a driver directly, it cannot be specified as a target of a message (a request). However, a driver can create one or more devices, entities suited exactly for receiving requests from user applications or other kernel components. When a request arrives to certain device, the kernel searches for its driver and call one of driver's callback routines to process the request. The resulting error code, together with the output parameters, is then returned to the originator of the request.

From application perspective, devices are viewed as special files. The application can open them, access them (read, write, send IOCTL...) and close them when finished. The abstraction is similar to Unix-based systems. The difference is that the devices are not stored inside a file system directory tree together with other files and directories. Instead, they are placed in the namespace of a kernel component called Object Manager. For example, when an application attempts to open a file named

C:\Windows\system32\kernel32.dll

the kernel goes through the Object Manager namespace (which is actually similar to a directory tree, it is just required to use special API to work with it) and sees that the C: portion is actually a symbolic link to object (file) named \Device\harddiskVolume1 which is a device representing a volume ("partition") with mounted file system. The kernel sends a request to open object named \Windows\system32\kernel32.dll to a device representing the file system mounted on the \Device\harddiskVolume1 device. in case the device is not a volume, the open request would be sent to the \Device\harddiskVolume1 instead.