PL  |  NL  |  FR  |  ES  |  PT  |  IT  |  DE  |  DK  |  NO  |  SE  |  FI  |  GR  |  JP  |  CN  |  KR  |  RU  |  AE

  Report this article

More information

Building a Malware Analysis Laboratory

Establishing Desktop Lockdown

Network Auditing and Monitoring Software

Antivirus Software

The Coming Superworms

Types of Software Protection: Time Limited Programs

Types of Software Protection: Registration Number (Serial Number) Protection

Worm Components

Types of Software Protection: Registration File (KEY File) Protection

Infecting Document Files

Infecting Executable Files

Cracking Tools

Types of Software Protection: Hardware Key (Dongle) Protection

Device drivers have exactly the same purpose as the hardware interface in the BIOS code. They link your system to another device by giving your PC a handy set of control functions. Drivers simply take care of devices not in the repertory of the BIOS. Rather than being permanently encoded in the memory of your PC, drivers are software that must be loaded into your PC's memory. As with the BIOS links, the external device driver provides a library of programs that it can easily call to carry out a complex function of the target hardware or software device.

All device drivers have to link with your existing software somehow. The means of making that link varies with your operating system. As you should expect, the fundamental device driver architecture is that used by DOS. Drivers that work with DOS are straightforward, single-minded, and sometimes dangerous. Advanced operating systems like Windows and OS/2 have built-in hooks for device drivers that make them more cooperative and easier to manage.

You need to tangle with device drivers because no programmer has an unlimited imagination. No programmer can possibly conceive of every device that you'd want to link to your PC. In fact, programmers are hard pressed to figure out everything you'd want to do with your PC-otherwise they'd write perfect programs that would do exactly everything that you want.

Thanks to an industry with a heritage of inter-company cooperation only approximated by a good pie fight, hardware designer tend to go their own directions when creating the control systems for their products. For example, the command one printer designer might pick for printing graphics dots may instruct a printer of a different brand to advance to the next sheet of paper. Confuse the codes, and your office floor will soon look like the training ground for housebreaking a new puppy.

Just about every class of peripheral has some special function shared with no other device. Printers need to switch ribbon colors; graphics boards need to put dots on screen at high resolution; sound boards need to blast fortissimo arpeggios; video capture boards must grab frames; and mice have to do whatever mice do. Different manufacturers often have widely different ideas about the best way to handle even the most fundamental functions. No programmer or even collaborative program can ever hope to know all the possibilities. It's even unlikely that you could fit all the possibilities into a BIOS with fewer chips than a Las Vegas casino or operating system with code that would fit onto a stack of disks you could carry. There are just too many possibilities.

Drivers let you customize. Instead of packing every control or command you might potentially need, the driver packages only those that are appropriate for a particular product. If all you want is to install a sound board, your operating system doesn't need to know how to capture a video frame. The driver contains only the command specific to the type, brand, and model of a product that you actually connect to your PC.

Device drivers give you a further advantage. You can change them almost as often as you change your mind. If you discover a bug in one driver-say sending an upper case F to your printer causes it to form feed through a full ream of paper before coming to a panting stop-you can slide in an updated driver that fixes the problem. In some cases, new drivers extend the features of your existing peripherals because programmers didn't have enough time or inspiration to add everything to the initial release.

The way you and your system handle drivers depends on your operating system. DOS, 16-bit versions of Windows, Windows 95, and OS/2 each treat drivers somewhat differently. All start with the model set by DOS, then add their own innovations. All 16-bit versions of Windows run under DOS, so require that you understand (and use) some DOS drivers. In addition, these versions of Windows add their own method of installing drivers as well as several new types of drivers. Windows 95 accommodates both DOS and 16-bit Windows drivers to assure you of compatibility with your old hardware and software. In addition, Windows 95 brings its own 32-bit protected-mode drivers and a dynamic installation scheme. OS/2 also follows the pattern set by DOS but adds its own variations as well.

Driver software matches the resource needs of your hardware to your software applications. The match is easy when a product doesn't allow you to select among resource values; the proper addresses can be written right into the driver. When you can make alternate resource allocations, however, the driver software needs to know which values you've chosen. In most cases, you make your choices known to the driver by adding options to the command that loads the driver (typically in your PC's CONFIG.SYS) or through configuration files. Most new add-in devices include an installation program that indicates the proper options to the driver by adding the values to the load command or configuration file, though you can almost always alter the options with a text-based editor.

This complex setup system gives you several places to make errors that will cause the add-in device, or your entire PC, to operate erratically or fail altogether. You might make duplicate resource assignments, mismatch drivers and options, or forget to install the drivers at all. Because multimedia PCs use so many add-in devices, they are particularly prone to such problems. Sound boards in particular pose installation problems because they usually incorporate several separate hardware devices (the sound system proper, a MIDI interface, and often a CD ROM interface) each of which has its own resource demands.