Editing DLL hell (section)

===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>