Dynamic Link Library (DLL)

[sukishan]

Dynamic Link Library (DLL)

Dynamic Link Library (DLL) is a collection of software routines programmed in a language such as C or Pascal, which has been packaged especially for use from another program. For example, a C programmer might write a routine that accesses a laser disc player. By compiling this as a DLL, it might be usable by an author of a Windows Help hyper book, without them having to know anything about the programming. In windows programming DLL plays an important part. Windows provides function calls to implement its user interface and display text and graphics on the video display. These functions are implemented in DLL. These are files with extension .DLL or .EXE.

The original idea for the DLL system was that there would be a central repository of code. Here are the advantages:

1. Applications would link to this code library, thus saving greatly on duplication of effort and storage space.
2. Applications that used the DLL system would behave exactly the same as all other applications that used it.
3. 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:

1. The DLL was newer and/or better than the ones already there.
2. The DLL was uniquely named, i.e. did not conflict with a DLL for another purpose with the same name.
3. 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.

1. On several occasions Microsoft has created and distributed DLL files that instantaneously broke every Windows application in the world.
2. 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.
3. 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. 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.