A History of DLLs
Dynamic link libraries (DLLs) have been a curse of the Windows operating system for quite some time, dating back to Windows 3.1. Before dynamic libraries existed, programmers reused previous code by statically linking it to their application. Basically, they would copy the code to each application as they compiled it from the source. If the static libraries were changed, the application would have to be re-compiled to take advantage of the new features.
Dynamic libraries were first used in the Multics operating system in 1964. Instead of loading code at compile-time (when the code is turned into computer instructions), dynamic libraries could be loaded right before the program itself was loaded (at load-time) or only when the program requested the library (at run-time). Dynamic linking makes code reuse much simpler, as it is not necessary to re-compile an application every time the library is changed in order to take advantage of bug fixes or performance enhancements. New applications can take advantage of new features, while the library itself remains compatible with older applications. Another way to use dynamic libraries is the “plug-in” method, where there is a generic interface that can be used by multiple programs (such as skins and visualizations for media players).
Dynamic linking also saves space on the hard disk and in memory, since one library can be linked by multiple programs at a time, depending on how the operating system’s object loader works. For example, the Linux dynamic library loader is “position-independent”, meaning that it can truly load one copy of the shared library into memory for all programs to use. Windows on the other hand is position-dependent – if multiple programs use conflicting memory addresses, then copies of the DLL must be loaded.
System DLLs in pre-Windows 2000 operating systems could be overwritten by any software vendor that felt like doing it (usually because the Windows DLLs were buggy), and this practice spawned the famous DLL-hell of Windows 9x operating systems. In Windows 2000 and XP, this practice has been limited, but system DLLs can still be overwritten temporarily, and non-system DLLs can still be easily overwritten whether they are important or not.
Shared DLLs are sometimes overwritten by different applications, causing other applications to stop working correctly, or an application may be expecting a specific version of a DLL that has been upgraded (or simply isn’t a standard part of the Windows installation). However, Windows 2000 and onward allow vendors the choice of placing their custom DLLs in the application’s folder, which will ensure the right one gets loaded.
While the problem has lessened, computers are finally outpacing software in terms of processing speed, hard disk space and memory. We have almost come full circle with libraries like Microsoft’s .NET allowing for multiple versions of the same library to co-exist side by side and allowing applications to be copied from one place to another without the need to register DLLs. In short, .NET is Microsoft’s long awaited answer to DLL hell, although its overall use (even by Microsoft) is still fairly limited. Windows Vista, which was promised to run on mostly on .NET-based code, has shipped with only 4% of the libraries compiled as .NET (sometimes referred to as “managed”) code.
So while things are improving, DLLs will be with us for some time in the Windows world. Eventually I suppose we’ll get back to statically linked libraries that will once again allow clean installation and un-installation of applications, and undoubtedly, someone will discover that by sharing these code libraries we can save memory and disk space…