A device driver , often just called a driver , is a computer program or software module that controls the interaction with connected, built-in ( hardware ) or virtual devices. To this end, the driver usually communicates directly with the device on the one hand and exchanges control signals and data with the device via the communication bus (hardware interface ) or a basic communication system of the operating system . On the other hand, the driver offers the operating system and / or application software a standardized interface so that this specific device can be addressed in the same way as similar devices from other manufacturers.
Due to their function, device drivers are highly hardware and operating system dependent.
The term driver is also used more generally for software that implements an interface to another computer system, i.e. to a combination of hardware and software (such as JDBC drivers , protocol drivers). Here, too, the driver enables standardized communication with various systems.
The main task of device drivers is to provide hardware-related functions through the hardware abstraction layer . All types of devices are different, even devices that serve the same purpose. Even the different models of a device from the same manufacturer that promise new functions or more performance, for example, are often controlled completely differently.
Computers and their operating systems cannot be expected to handle all of these different types, much less future devices. To solve this problem, the operating system specifies how a class of devices should be addressed . The device drivers then take care of the translation of these function calls of the operating system into device-specific control signals. Theoretically, a completely new device with a completely new control should also work without any problems as soon as a driver for this device is available. The operating system should be able to address it with the same function calls as any other device.
Often there are many different variants of a driver, primarily depending on the supported hardware, often also in different (development) versions. In addition, there must be a variant for each supported operating system, as the interfaces for this, for example with Microsoft Windows or Linux , are very different. There is also a dependency on the basic architecture of the computer and the operating system, also on the processing bandwidth. If there is no driver for a specific operating system or architecture, a corresponding environment can be emulated under certain circumstances , i.e. further abstraction layers can be added.
Without a suitable driver, a hardware component is useless if it does not work autonomously and is dependent on software support.
Comprehensive interface model
If the interface standard follows an overarching standardized model, it offers the operating system or application software the option of addressing devices of completely different types in an orderly manner; For example, software for playing a piece of music could then not only use a sound card driver, but also send the sound data via a network driver, since this can also accept a data stream. A special adaptation of the application to this scenario is no longer necessary. The overarching interface model facilitates the programming of the application software and enables more universal use, even with future device types that are still unknown. Some earlier operating systems, such as MS-DOS , did not include this abstraction.
Programming a device driver is a challenge in most cases as it requires a thorough understanding of how a platform works, both on the hardware and software side.
Unlike most other types of software that can be stopped by using a modern operating system at any time without affecting the rest of the system means a bug in a device driver in many cases that the system may collapse completely, resulting in the loss of Data or (in extreme cases) even the destruction of hardware parts. Also, troubleshooting device drivers is difficult because it often means monitoring the hardware itself. Therefore, the system under test is usually connected to another computer via the serial interface. The test system can be controlled remotely and the status can be queried at any time.
Device drivers are therefore usually written by the hardware manufacturers themselves, since only they know the exact design of the hardware. It is also in the interests of hardware manufacturers that customers can get the most out of their product.
Nevertheless, numerous device drivers have been developed by outsiders in recent years, mainly for free operating systems. But here, too, the cooperation of the manufacturer is important, since reverse engineering (finding out how it works) is much more difficult with hardware than with software. Without this cooperation it is almost impossible to program driver software.
So-called class drivers (also called generic drivers ) are largely manufacturer-independent. Often cited examples of this are class drivers for printers or for the device classes that can be connected to the universal serial bus , with mass storage devices playing a pioneering role here.
Older computers in particular often no longer have the necessary data carriers with the device drivers. Since some components of the computer are only inadequately marked or labeled, it is often not possible to obtain a suitable driver without professional help, as the manufacturer of the component is not known. This can lead to problems in particular if the device drivers are required, for example after reinstalling the operating system. In such cases, system information programs , which are often offered as freeware , can help. These usually show the manufacturer and model names after a system test so that the necessary driver can be obtained. There are also programs that can extract drivers from a system that is still running so that they can be integrated on the other system.
Another problem is the manufacturer's dependency on proprietary drivers. Drivers often only run on a few operating systems and operating system versions. If the user wants to use a new operating system version, he depends on the manufacturer's device drivers. Functional hardware components with proprietary drivers often cannot run with newer operating systems. This is often related to the commercial interests of hardware manufacturers looking to sell new hardware. This disadvantage is mitigated with open source drivers. The drivers also have to be adapted to the newer system, but the user can contribute to the development himself or suggest changes.
- Walter Oney: Programming the Microsoft Windows Driver Model , ISBN 0-7356-1803-8
- Art Baker: Windows 2000 Device Driver Book , ISBN 0-13-020431-5
- Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman: Linux Device Drivers, Third Edition , ISBN 0-596-00590-3 (readable online at lwn.net )
- Status report from Greg Kroah-Hartman, the founder and head of the Linux driver project, in Linux magazine 08 2008 (cover topic Linux driver)
- Microsoft: Windows 8 Consumer Preview is available for download - Article at Golem.de , February 29, 2012 (Accessed: March 1, 2012)
- computerwissen.de: How to backup drivers in Windows 10?
- C't: Before the starting shot; Adjust Windows installation in advance (Win 10), edition 1/2019, p. 164ff