Editing DLL hell (section)

==Solutions==
Various forms of DLL hell have been solved or mitigated over the years.

===Static linking===
A simple solution to DLL hell in an application is to [[Static library|statically link]] all the libraries, i.e. to include the library version required in the program, instead of picking up a system library with a specified name.<ref name="threatormenace"/> This is common in C/C++ applications, where, instead of having to worry about which version of <code>MFC42.DLL</code> is installed, the application is compiled to be statically linked against the same libraries. This eliminates the DLLs entirely and is possible in standalone applications using only libraries that offer a static option, as [[Microsoft Foundation Class Library]] does. However, the main purpose of DLLs – runtime library sharing between programs to reduce memory overhead – is sacrificed; duplicating library code in several programs creates [[software bloat]] and complicates the deployment of security fixes or newer versions of dependent software.

===Windows File Protection===
The DLL overwriting problem (referred to as ''DLL Stomping'' by Microsoft) was somewhat reduced with [[Windows File Protection]] (WFP),<ref>[http://www.microsoft.com/whdc/winlogo/drvsign/wfp.mspx Windows File Protection and Windows].</ref> which was introduced in [[Windows 2000]].<ref name="endofdllhell"/> This prevents unauthorized applications from overwriting system DLLs, unless they use the specific [[Windows API]]s that permit this. There may still be a risk that updates from Microsoft are incompatible with existing applications, but this risk is typically reduced in current versions of Windows through the use of [[Side-by-side assembly|side-by-side assemblies]].

Third-party applications cannot stomp on OS files unless they bundle legitimate Windows updates with their installer, or if they disable the [[Windows File Protection]] service during installation, and on Windows Vista or later also take ownership of system files and grant themselves access.  The [[System File Checker|SFC]] utility could revert these changes at any time.

===Running conflicting DLLs simultaneously===
The solutions here consist of having different copies of the same DLLs for each application, both on disk and in memory.

An easy manual solution to conflicts was placing the different versions of the problem DLL into the applications' folders, rather than a common system-wide folder. This works in general as long as the application is 32-bit or 64-bit, and that the DLL does not use shared memory.  In the case of 16-bit applications, the two applications cannot be executed simultaneously on a 16-bit platform, or in the same 16-bit virtual machine under a 32-bit operating system.  [[Object Linking and Embedding|OLE]] prevented this before Windows 98 SE/2000, because earlier versions of Windows had a single registry of COM objects for all applications.

Windows 98 SE/2000 introduced a solution called ''[[side-by-side assembly]]'',<ref>{{Cite web |url=http://msdn2.microsoft.com/en-us/library/ms811700.aspx |title=Implementing Side-by-Side Component Sharing in Applications (Expanded) |publisher=Microsoft |access-date=3 January 2013 |archive-url=https://web.archive.org/web/20061210042506/http://msdn2.microsoft.com/en-us/library/ms811700.aspx |archive-date=10 December 2006}}</ref> which loads separate copies of DLLs for each application that requires them (and thus allows applications that require conflicting DLLs to run simultaneously).  This approach eliminates conflicts by allowing applications to load unique versions of a module into their address space, while preserving the primary benefit of sharing DLLs between applications (i.e. reducing memory use) by using memory mapping techniques to share common code between different processes that do still use the same module. Yet DLLs using shared data between multiple processes cannot take this approach.<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/h90dkhs0(VS.71).aspx |title=How do I share data in my DLL with an application or with other DLLs? |publisher=[[Microsoft]] |access-date=2008-11-11}}</ref>  One negative side effect is that orphaned instances of DLLs may not be updated during automated processes.

===Portable applications===
Depending on the application architecture and runtime environment, [[portable applications]] may be an effective way to reduce some DLL problems, since every program bundles its own private copies of any DLLs it requires.<ref name="endofdllhell"/>  The mechanism relies on applications not fully qualifying the paths to dependent DLLs when loading them, and the operating system searching the executable directory before any shared location.<ref name="sharedlibpolicy"/>  However this technique can also be exploited by malware,<ref>{{cite web|url=http://support.microsoft.com/kb/2389418|title=Secure loading of libraries to prevent DLL preloading attacks|publisher=Microsoft|access-date=16 Feb 2013}}</ref> and the increased flexibility may also come at the expense of security if the private DLLs are not kept up to date with security patches in the same way that the shared ones are.

[[Application virtualization]] can also allow applications to run in a "bubble", which avoids installing DLL files directly into the operating system.

=== Other countermeasures ===
There are other countermeasures to avoid DLL hell, some of which may have to be used simultaneously;
some other features that help to mitigate the problem are:
* Installation tools are now bundled into [[Microsoft Visual Studio]], one of the main environments for Windows development. These tools perform version checking before DLL installation, and can include predefined installation packages in a .MSI installation. This allows third party applications to integrate OS component updates without having to write their own installers for these components.
* [[System Restore]] can recover a system from a bad installation, including registry damage. Although this does not prevent the problem, it facilitates recovery therefrom.
* WinSxS ([[Side-by-side assembly|Windows Side-by-Side]]) directory, which allows multiple versions of the same libraries to co-exist.
* Run 16-bit applications in a separate memory space under a 32-bit version of Windows to allow two applications to use conflicting versions of the same DLL at the same time.
* Use a version of Windows that includes [[Windows File Protection]].  [[Windows Me]] and [[Windows 2000]], both released in 2000, support this form of system file protection, as do [[Windows XP]] and [[Windows Server 2003]].  Its replacement, [[Windows Resource Protection]], was introduced in Windows Vista and Windows Server 2008, and uses a different method of protecting system files from being changed.
* Registration-free COM: [[Windows XP]] introduced a new mode of COM object registration called "''Registration-free COM''". This feature makes it possible for applications that need to install COM objects to store all the required COM registry information in the application's own directory, instead of in the global system registry. Thus, it provides a mechanism for multiple versions of the same DLL to be registered at the same time by multiple applications (Microsoft calls this "[[Side-by-Side Assembly]]"<ref>[http://msdn2.microsoft.com/en-us/library/aa376307.aspx Side-by-side Assemblies (Windows)]</ref>). DLL hell can be substantially avoided using Registration-free COM, the only limitation being it requires at least [[Windows XP]] or later Windows versions and that it must not be used for EXE COM servers or system-wide components such as [[Microsoft Data Access Components|MDAC]], [[MSXML]], [[DirectX]] or [[Internet Explorer]].
* Shipping the operating system with a capable [[package management system]] that is able to track the DLL dependencies, encouraging the use of the package manager and discouraging manual installation of DLLs.  [[Windows Installer]], included with [[Windows Me]], [[Windows 2000]] and all later versions provides this functionality.
* Having a central database or authority for DLL conflict resolution and software distribution. Changes to a library can be submitted to this authority; thus, it can make sure compatibility is preserved in the developed branches. If some older software is incompatible with the current library, the authority can provide a compatibility interface for it, or bundle the old version as a distinct package.
* If software developers need to customize a library, and if the main library release is unlikely to incorporate the changes that they need, they can ship the customized DLL for the program's private use (commonly by placing it in the program's private directory) or statically link the program against the customized library.
* While DLLs are best for modularizing applications and the system's components and as third-party libraries, their usage is not imperative in all cases on modern systems where memory is no longer a constraint. For example, if an application needs a library that will not be used anywhere else, it can be linked statically, with no space penalty and with a speed gain.
* Windows Vista and later use a special ''TrustedInstaller'' service to install operating system files.  Other user accounts, including the SYSTEM, have no access to overwrite core system binaries.  Windows 7 expands this functionality to some critical parts of the Registry.