Editing DLL hell (section)

== Problems ==
DLLs are Microsoft's implementation of [[shared libraries]]. Shared libraries allow common code to be bundled into a wrapper, the DLL, which is used by any application software on the system without loading multiple copies into memory. A simple example might be the [[GUI]] text editor, which is widely used by many programs. By placing this code in a DLL, all the applications on the system can use it without using more memory. This contrasts with [[static libraries]], which are functionally similar but copy the code directly into the application. In this case, every application grows by the size of all the libraries it uses, and this can be quite large for modern programs.

The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created. DLLs have no built-in mechanism for backward compatibility, and even minor changes to the DLL can render its internal structure so different from previous versions that attempting to use them will generally cause the application to crash. Static libraries avoid this problem because the version that was used to build the application is included inside it, so even if a newer version exists elsewhere on the system, this does not affect the application.

A key reason for the version incompatibility is the structure of the DLL file. The file contains a directory of the individual methods (procedures, routines, etc.) contained within the DLL and the types of data they take and return. Even minor changes to the DLL code can cause this directory to be re-arranged, in which case an application that calls a particular method believing it to be the 4th item in the directory might end up calling an entirely different and incompatible routine, which would normally cause the application to crash.

There are several problems commonly encountered with DLLs, especially after numerous applications have been installed and uninstalled on a system. The difficulties include conflicts between DLL versions, difficulty in obtaining required DLLs, and having many unnecessary DLL copies.

Solutions to these problems were known even while Microsoft was writing the DLL system.{{Citation needed|date=November 2021}} These have been incorporated into the [[.NET Framework|.NET]] replacement, "Assemblies".

===Incompatible versions===
A particular version of a library can be compatible with some programs that use it and incompatible with others. Windows has been particularly vulnerable to this because of its emphasis on dynamic linking of C++ libraries and [[Object Linking and Embedding]] (OLE) objects. C++ classes export many methods, and a single change to the class, such as a new virtual method, can make it incompatible with programs that were built against an earlier version. Object Linking and Embedding has very strict rules to prevent this: interfaces are required to be stable, and memory managers are not shared. This is insufficient, however, because the semantics of a class can change. A bug fix for one application may result in the removal of a feature from another. Before [[Windows 2000]], Windows was vulnerable to this because the [[Component Object Model|COM]] class table was shared across all users and processes. Only one COM object in one DLL/EXE could be declared as having a specific global COM Class ID on a system. If any program needed to create an instance of that class, it got whatever was the current centrally registered implementation. As a result, an installation of a program that installed a new version of a common object might inadvertently break other programs that were previously installed.

===DLL stomping===
A common and troublesome problem occurs when a newly installed program overwrites a working system DLL with an earlier, incompatible version. Early examples of this were the <code>ctl3d.dll</code> and <code>ctl3dv2.dll</code> libraries for [[Windows 3.1]]: Microsoft-created libraries that third-party publishers would distribute with their software, but each distributing the version they developed with rather than the most recent version.<ref name=Ctl3D>{{cite web |url=http://support.microsoft.com/search/default.aspx?query=CTL3Dv2.DLL |title=A summary of CTL3D.DLL articles in Microsoft Support Knowledge Base |publisher=Microsoft}}</ref> DLL stomping occurs because:
* Microsoft in the past distributed runtime DLLs as shared system components<ref>[http://support.microsoft.com/kb/326922 Redistribution of the shared C runtime component in Visual C++ 2005 and in Visual C++ .NET].</ref> (originally C:\WINDOWS and C:\WINDOWS\SYSTEM), as a way of efficiently sharing code in a shared-memory OS with limited RAM and disk space. Consequently, third-party developers also distributed these in such a manner.
* Application installers are typically executed in a privileged security context that has access to install DLLs into the system directories and to edit the system registry to register new DLLs as [[Component Object Model|COM]] objects. A poorly written or misconfigured installer can therefore downgrade a system library on legacy versions of Windows, on which [[Windows File Protection]] or [[Windows Resource Protection]] does not roll back the change. On Windows Vista and later, only the "trusted installer" account can make changes to core operating-system libraries.
* Windows applications were permitted to include OS updates in their own installation programs. That is, many Microsoft DLLs are ''redistributable'', meaning that the applications can include them if they need the services of the particular libraries.
* Before [[Windows Installer]], Windows installers historically were commercial products; many people attempted to write their own installers, overlooking or mishandling versioning problems in the process.{{Citation needed|date=August 2008}}
* Some development environments did not automatically add a version resource in their compiled libraries, so many developers overlooked this aspect. Checking file dates, overwriting existing files or skipping the copy operation if the DLL was already installed were the only options available instead of correct versioning.{{Citation needed|date=June 2010}}
* Sometimes, the OS itself removed or replaced DLLs with older or obsolete versions. For example, Windows 2000 would install black-and-white printer DLLs on top of color-aware DLLs, if a black-and-white printer was installed after the color printer.<ref>[http://support.microsoft.com/kb/830490 KB 830490: HP Color LaserJet printer prints only in grayscale or in black-and-white on your Windows 2000 SP4-based computer<!-- Bot generated title -->].</ref>

===Incorrect COM registration===
In [[Component Object Model|COM]] and other parts of Windows, prior to the introduction of [[Side-by-side assembly|side-by-side]] registry-free assemblies,<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/ms973913.aspx |title=Registration-Free Activation of COM Components: A Walkthrough |publisher=[[Microsoft]] |author1=Leslie Muller |author2=Steve White |date=July 2005}}</ref> the [[Windows Registry|Registry]] was used for determining which underlying DLL to use. If a different version of a module was registered, this DLL would be loaded instead of the expected one. This scenario could be caused by conflicting installations that register different versions of the same libraries, in which case the last installation would prevail.

===Shared in-memory modules===
16-bit versions of Windows (and [[Windows on Windows]]) load only one instance of any given DLL; all applications reference the same in-memory copy, until no applications are using it and it is unloaded from memory. (For 32-bit and 64-bit versions of Windows, inter-process sharing occurs only where different executables load a module from exactly the same directory; the code but not the [[Stack (data structure)|stack]] is shared between processes through a process called "memory mapping".)  Thus, even when the desired DLL is located in a directory where it can be expected to be found, such as in the system directory or the application directory, neither of these instances will be used if another application has started with an incompatible version from a third directory.  This issue can manifest itself as a 16-bit application error that occurs only when applications are started in a specific order.

===Lack of serviceability===
In direct conflict with the DLL stomping problem: If updates to a DLL do not affect all applications that use it, then it becomes ''much'' harder to "service" the DLL – that is, to eliminate problems that exist in the current versions of the DLL. (Security fixes are a particularly compelling and painful case.) Instead of fixing just the latest version of the DLL, the implementor must ideally make their fixes and test them for compatibility on every released version of the DLL.