Device driver

A device driver, often abbreviated to only driver is a computer program or software module with connected, built-in (hardware) controls the interaction or virtual devices. To the driver on one side usually communicate directly with the device, and exchanges control signals or data from the device, via the communication bus ( hardware interface ) or a basic communication system of the operating system. On the other hand, the driver tells the operating system and / or application software provides the standard interface, so that this particular device can be addressed in the same way as similar devices from other manufacturers.

Due to their function device drivers are strongly hardware- and operating system- dependent.

The term driver is also used more generally for software that implements an interface to another computer system, ie a combination of hardware and software (such as JDBC driver, protocol driver). Again, the driver allows transparent communication with disparate systems.

Task

The main task of device drivers is to provide hardware-related functions by the hardware abstraction layer. All kinds of equipment are different, even devices that fulfill the same purpose. Even the different models of a device from the same manufacturer that promise as new features or better performance, are often driven completely different.

From computers and their operating systems can not be expected to deal with all these different types, and certainly not with future devices. To solve this problem, the operating system specifies, as a class of devices should be addressed. The device driver then take care of the translation of these function calls to the operating system in the device-specific control signals. Theoretically, this should work just as well a completely new device with a completely new driving problems as soon as a driver for this device is present. The operating system should be able to address it with the same function calls like any other device as well.

Often there are many different variations of a driver, primarily depending on the supported hardware, often in different (development) versions. In addition, a variant must exist for each supported operating system, because the interfaces for example, Microsoft Windows or Linux are very different at the moment. There is still a function of the basic architecture of the computer and the operating system, by the processing bandwidth. If there is no driver for a particular operating system or architecture available, under certain circumstances a proper environment can emulate, so further abstraction layers are added.

Without proper driver a piece of hardware is useless if it does not work autonomously and is dependent on support by software.

Cross- interface model

Follows the interface standard an overarching standard model, it provides the operating system or application software the possibility of an entirely different type devices also ordered to speak; For example, a software could then not only use a sound card driver to play a piece of music, but also send the audio data over a network driver, as it can also accept a data stream. A special adaptation of the application of this scenario is thus no longer necessary. The overall interface model facilitates the programming of the application software and enables a more universal use, with as yet unknown future device types. Some earlier operating systems such as MS- DOS, this abstraction is not contained.

Development

To program a device driver is considered in most cases as a challenge, as it requires a thorough understanding of the functioning of a platform, both on the hardware as the software side.

In contrast to most other types of software can be stopped when a new operating system at any time, without affecting the rest of the system, this means a program error 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 can result. In addition, the debugging device drivers is difficult, as this often means to monitor the hardware itself. Therefore, normally the system under test via the serial interface to another computer is connected. Thus, the test system remotely and the status can be queried at any time.

Normally device drivers are therefore written by the hardware manufacturers themselves, because only they know the exact design of the hardware. Moreover, it is in the interest of the hardware manufacturers that customers can use your product perfectly.

Nevertheless, numerous device drivers were developed by outsiders, mostly for free operating systems in recent years. But even here the manufacturer's employees is important because reverse engineering ( finding out the operation ) in hardware is much more difficult than in software. Without this cooperation, it is almost impossible to program driver software.

So-called class driver (also known as generic drivers ) are largely independent of the manufacturer. Often mentioned examples are class driver for printer or for classes of devices that can be connected to the Universal Serial Bus, which play here the mass storage, a pioneering role.

Problem

Especially with older computers are often the necessary storage with the device drivers no longer exists. Since some components of the computer are marked or labeled only inadequate, it is often not possible without professional help to procure a suitable driver, as the manufacturer of the component is not known. This particular can lead to problems if the device drivers are needed, for example after a new installation of the operating system. In such cases, system information programs, which are often offered as freeware, help. These usually show the manufacturer and model designations after a system test, so that the necessary drivers can be procured.

Another problem is the vendor lock- in proprietary drivers dar. drivers are often on only a few operating systems and operating system versions to run. If the user wants to use a new operating system version, it depends on device drivers from the manufacturer. Often functional hardware components with proprietary drivers with newer operating systems can not run. This is often connected with the commercial interests of hardware manufacturers who want to sell new hardware. For open source drivers, this disadvantage is mitigated. The driver must also be adapted to the newer system, but the user can participate in the development or suggest changes.