|
|
Celtica's
Computer Club > Driverman
DriverMan
Finding Drivers, DLLs, and
other Components for Windows
|
WHAT
ARE DRIVERS?
Don't just tear your hair out when you can't run an interesting programme or favourite game because of missing
DLL file error! Sometimes it's necessary to get hold of an updated system file.
A driver is a programme for controlling a device. Every device, whether
it be a printer, disk drive, or keyboard, must have a driver programme.
Many drivers, such as the keyboard driver, come along with the operating
system. For other devices, you may need to load a new driver when you connect
the device to your computer. In Windows environments, drivers often have
.DLL, .OCX, or .DRV extensions. In DOS systems, drivers are files
with a .SYS extension.
A driver acts like a translator between the device and programmes that
use the device. Each device has its own set of specialized commands that
only its driver knows. In contrast, most programmes access devices by using
generic commands. The driver, therefore, accepts generic commands from
a program and then translates them into specialized commands for the device.
DYNAMIC
LINK LIBRARIES (DLLs)
The original idea for the DLL
system was that there would be a central repository of code. Here are the
advantages:
Applications would link
to this code library, thus saving greatly on duplication of effort and
storage space.
Applications that used the DLL
system would behave exactly the same as all other applications that used
it.
If a problem arose, or a new feature
was desired, it could be written once and all would benefit. In this sense,
the DLL system is a weak version of the object-programming paradigm.
Naturally enough, along with these
advantages came some responsibilities. An application should only place
a DLL in the central repository if:
The DLL was newer and/or better
than the ones already there.
The DLL was uniquely named, i.e.
did not conflict with a DLL for another purpose with the same name.
If the DLL replaced another with
the same name, then the code in the DLL would be exhaustively tested, so
that on replacement, other applications could use it in the same way as
its predecessor.
In time, all these rules have been
broken, even by Microsoft itself, the originator of the idea.
On several occasions Microsoft
has created and distributed DLL files that instantaneously broke every
Windows application in the world. Regularly, end users will install an
application that has a DLL with the same name as a "system" DLL, thus mysteriously
bringing down the system until an expert can sort it out. Over time, the
"synchronization" problem becomes more severe. In this scenario, a DLL
is replaced that brings it into conflict with other DLLs it must work with.
The service pack problem is becoming
severe. In this scenario, Microsoft releases a service pack that updates
all key system DLLs. All the elements of the service pack must simultaneously
be present in their most recent form or the system will crash. Then the
user installs an application that blithely replaces one or more of the
DLLs from the service pack. Result - system failure, even on Windows NT
4.0, which, notwithstanding its reputation for stability and resilience,
will fail utterly and completely.
This is an example of a collision
between an idea and reality, a key element in the human drama. The idea
was sound, but it failed to take into account the imperfections in the
human character, in particular those imperfections that influence the creation
and operation of computer programs.
The reality is that Microsoft and any number of software vendors regularly
risk the stability and security of the end user's machine by writing DLL
code as though it were normal programming. It isn't. To write a DLL, you
must imagine the effect of your changes and additions on every computer
program that uses it. This is obviously impossible.
Conclusion
The solution to these problems
is to go back to the system that preceded the DLL system. Every application
should place as many DLL files as possible in its own directory (some DLL
files are part of Windows itself, these must be accessed in common). No
application should assume that it can copy DLLs into the system directory
or that its newer version of a system DLL is safe to copy solely because
it is newer. Many applications (including Microsoft's own) have rendered
systems unstable or unusable through this reasoning.
The majority of customer problems are probably related to DLLs. If a programme
was created assuming that standard Windows system DLLs would be present,
and those DLLs were not present, or would not be current, then that application
would fail.
This is mystifying to some - why should a copy of mfc42.dll with a version
number of 4.2.6256 fail an application when a version released just four
months later (4.21.7022) runs it perfectly? Aren't these DLL versions just
cosmetic improvements, bug fixes and so forth? No, they are not. The new
DLL version has routines that (1) are required by a particular programme,
and (2) do not exist in the earlier versions.
Remedy
Always download the required current
DLLs. Do not assume that, because your system has a copy of a DLL with
the same name, that it is the same DLL.
Never copy a DLL into the system directory as so many applications do –
unless you also smoke cigarettes, drink heavily, eat peas with a knife,
maltreat your dogs and believe they speak Latin in Latin America. Place
the downloaded DLL files only in the same directory as the application
that needs them. This allows the application to "see" the DLLs but hides
them from the rest of the system.
How
to add .dll or .ocx files
To add .ocx and certain .dll files,
run WINDOWS/SYSTEM/REGSVR32.EXE from the command line. The following is
the run command you will need:-
regsvr32
dll name or ocx name (Example:
regsvr32 msvcp60.dll)
Links
to Drivers and Further Information
There's lots
of stuff on the Web to help you organize your machine. Here are a number
of useful links.
|