For the Microsoft Windows operating systems that are listed
in the "Applies to" section, much of the functionality of the operating system
is provided by dynamic link libraries (DLL). Additionally, when you run a
program on one of these Windows operating systems, much of the functionality of
the program may be provided by DLLs. For example, some programs may contain
many different modules, and each module of the program is contained and
distributed in DLLs.
The use of DLLs helps promote modularization of
code, code reuse, efficient memory usage, and reduced disk space. Therefore,
the operating system and the programs load faster, run faster, and take less
disk space on the computer.
When a program uses a DLL, an issue that
is called dependency may cause the program not to run. When a program uses a
DLL, a dependency is created. If another program overwrites and breaks this
dependency, the original program may not successfully run.
introduction of the Microsoft .NET Framework, most dependency problems have
been eliminated by using assemblies.
A DLL is a library that contains code and data that can be used by
more than one program at the same time. For example, in Windows operating
systems, the Comdlg32 DLL performs common dialog box related functions.
Therefore, each program can use the functionality that is contained in this DLL
to implement an Open
dialog box. This helps promote code reuse
and efficient memory usage.
By using a DLL, a program can be
modularized into separate components. For example, an accounting program may be
sold by module. Each module can be loaded into the main program at run time if
that module is installed. Because the modules are separate, the load time of
the program is faster, and a module is only loaded when that functionality is
Additionally, updates are easier to apply to each module
without affecting other parts of the program. For example, you may have a
payroll program, and the tax rates change each year. When these changes are
isolated to a DLL, you can apply an update without needing to build or install
the whole program again.
The following list describes some of the
files that are implemented as DLLs in Windows operating systems:
- ActiveX Controls (.ocx) files
An example of an ActiveX control is a calendar control that
lets you select a date from a calendar.
- Control Panel (.cpl) files
An example of a .cpl file is an item that is located in
Control Panel. Each item is a specialized DLL.
- Device driver (.drv) files
An example of a device driver is a printer driver that
controls the printing to a printer.
The following list describes some of the advantages that are
provided when a program uses a DLL:
- Uses fewer resources
When multiple programs use the same library of functions, a
DLL can reduce the duplication of code that is loaded on the disk and in
physical memory. This can greatly influence the performance of not just the
program that is running in the foreground, but also other programs that are
running on the Windows operating system.
- Promotes modular architecture
A DLL helps promote developing modular programs. This helps
you develop large programs that require multiple language versions or a program
that requires modular architecture. An example of a modular program is an
accounting program that has many modules that can be dynamically loaded at run
- Eases deployment and installation
When a function within a DLL needs an update or a fix, the
deployment and installation of the DLL does not require the program to be
relinked with the DLL. Additionally, if multiple programs use the same DLL, the
multiple programs will all benefit from the update or the fix. This issue may
more frequently occur when you use a third-party DLL that is regularly updated
When a program or a DLL uses a DLL function in another DLL, a
dependency is created. Therefore, the program is no longer self-contained, and
the program may experience problems if the dependency is broken. For example,
the program may not run if one of the following actions occurs:
- A dependent DLL is upgraded to a new version.
- A dependent DLL is fixed.
- A dependent DLL is overwritten with an earlier
- A dependent DLL is removed from the computer.
These actions are generally known as DLL conflicts. If backward
compatibility is not enforced, the program may not successfully
The following list describes the changes that have been
introduced in Microsoft Windows 2000 and in later Windows operating systems to
help minimize dependency issues:
- Windows File Protection
In Windows File Protection, the operating system prevents
system DLLs from being updated or deleted by an unauthorized agent. Therefore,
when a program installation tries to remove or update a DLL that is defined as
a system DLL, Windows File Protection will look for a valid digital
- Private DLLs
Private DLLs let you isolate a program from changes that are
made to shared DLLs. Private DLLs use version-specific information or an empty
.local file to enforce the version of the DLL that is used by the program. To
use private DLLs, locate your DLLs in the program root folder. Then, for new
programs, add version-specific information to the DLL. For old programs, use an
empty .local file. Each method tells the operating system to use the private
DLLs that are located in the program root folder.
DLL troubleshooting tools
Several tools are available to help you troubleshoot DLL problems.
The following tools are some of these tools.
The Dependency Walker tool can recursively scan for all dependent
DLLs that are used by a program. When you open a program in Dependency Walker,
Dependency Walker performs the following checks:
- Dependency Walker checks for missing DLLs.
- Dependency Walker checks for program files or DLLs that are
- Dependency Walker checks that import functions and export
- Dependency Walker checks for circular dependency
- Dependency Walker checks for modules that are not valid
because the modules are for a different operating system.
By using Dependency Walker, you can document all the DLLs that a
program uses. This may help prevent and correct DLL problems that may occur in
the future. Dependency Walker is located in the following directory when you
install Microsoft Visual Studio 6.0:
drive\Program Files\Microsoft Visual Studio\Common\Tools
DLL Universal Problem Solver
The DLL Universal Problem Solver (DUPS) tool is used to audit,
compare, document, and display DLL information. The following list describes
the utilities that make up the DUPS tool:
This utility enumerates all the DLLs on the computer and logs
the information to a text file or to a database file.
This utility compares the DLLs that are listed in two text
files and produces a third text file that contains the differences.
This utility loads the text files that are created by using
the Dlister.exe utility and the Dcomp.exe utility into the dllHell
This utility provides a graphical user interface (GUI)
version of the Dtxt2DB.exe utility.
more information about the DUPS tool, click the following article number to
view the article in the Microsoft Knowledge Base:
Using DUPS.exe to resolve DLL compatibility problems
DLL Help database
The DLL Help database helps you locate specific versions of DLLs
that are installed by Microsoft software products. For more information about
the DLL Help database, visit the following Microsoft Web site:
This section describes the issues and the requirements that you
should consider when you develop your own DLLs.
Types of DLLs
When you load a DLL in an application, two methods of linking let
you call the exported DLL functions. The two methods of linking are load-time
dynamic linking and run-time dynamic linking.
Load-time dynamic linking
In load-time dynamic linking, an application makes explicit calls
to exported DLL functions like local functions. To use load-time dynamic
linking, provide a header (.h) file and an import library (.lib) file when you
compile and link the application. When you do this, the linker will provide the
system with the information that is required to load the DLL and resolve the
exported DLL function locations at load time.
Run-time dynamic linking
In run-time dynamic linking, an application calls either the LoadLibrary
function or the LoadLibraryEx
function to load the DLL at run time. After the DLL is
successfully loaded, you use the GetProcAddress
function to obtain the address of the exported DLL function that
you want to call. When you use run-time dynamic linking, you do not need an
import library file.
The following list describes the application
criteria for when to use load-time dynamic linking and when to use run-time
- Startup performance
If the initial startup performance of the application is
important, you should use run-time dynamic linking.
- Ease of use
In load-time dynamic linking, the exported DLL functions are
like local functions. This makes it easy for you to call these
- Application logic
In run-time dynamic linking, an application can branch to
load different modules as required. This is important when you develop
The DLL entry point
When you create a DLL, you can optionally specify an entry point
function. The entry point function is called when processes or threads attach
themselves to the DLL or detached themselves from the DLL. You can use the
entry point function to initialize data structures or to destroy data
structures as required by the DLL. Additionally, if the application is
multithreaded, you can use thread local storage (TLS) to allocate memory that
is private to each thread in the entry point function. The following code is an
example of the DLL entry point function.
BOOL APIENTRY DllMain(
HANDLE hModule, // Handle to DLL module
DWORD ul_reason_for_call, // Reason for calling function
LPVOID lpReserved ) // Reserved
switch ( ul_reason_for_call )
// A process is loading the DLL.
// A process is creating a new thread.
// A thread exits normally.
// A process unloads the DLL.
When the entry point function returns a FALSE
value, the application will not start if you are using load-time
dynamic linking. If you are using run-time dynamic linking, only the individual
DLL will not load.
The entry point function should only perform simple
initialization tasks and should not call any other DLL loading or termination
functions. For example, in the entry point function, you should not directly or
indirectly call the LoadLibrary
function or the LoadLibraryEx
function. Additionally, you should not call the FreeLibrary
function when the process is terminating.Note
In multithreaded applications, make sure that access to the DLL
global data is synchronized (thread safe) to avoid possible data corruption. To
do this, use TLS to provide unique data for each thread.
Exporting DLL functions
To export DLL functions, you can either add a function keyword to
the exported DLL functions or create a module definition (.def) file that lists
the exported DLL functions.
To use a function keyword, you must
declare each function that you want to export with the following keyword:
To use exported DLL functions in the application, you
must declare each function that you want to import with the following keyword:
Typically, you would use one header file that has a define
statement and an ifdef
statement to separate the export statement and the import
You can also use a module definition file to declare
exported DLL functions. When you use a module definition file, you do not have
to add the function keyword to the exported DLL functions. In the module
definition file, you declare the LIBRARY
statement and the EXPORTS
statement for the DLL. The following code is an example of a
Sample DLL and application
In Microsoft Visual C++ 6.0, you can create a DLL by selecting
either the Win32 Dynamic-Link Library
project type or the
MFC AppWizard (dll)
The following code
is an example of a DLL that was created in Visual C++ by using the
Win32 Dynamic-Link Library
BOOL APIENTRY DllMain( HANDLE hModule,
MessageBox( NULL, TEXT("Hello World"), TEXT("In a DLL"), MB_OK);
// File: SampleDLL.h
extern __declspec(dllexport) void HelloWorld() ;
extern __declspec(dllimport) void HelloWorld() ;
The following code is an example of a Win32
project that calls the exported DLL function in the
int APIENTRY WinMain(HINSTANCE hInstance,
In load-time dynamic linking, you must link the SampleDLL.lib
import library that is created when you build the SampleDLL
In run-time dynamic linking, you use code that is similar to
the following code to call the SampleDLL.dll exported DLL function.
typedef VOID (*DLLPROC) (LPTSTR);
hinstDLL = LoadLibrary("sampleDLL.dll");
if (hinstDLL != NULL)
HelloWorld = (DLLPROC) GetProcAddress(hinstDLL, "HelloWorld");
if (HelloWorld != NULL)
fFreeDLL = FreeLibrary(hinstDLL);
When you compile and link the SampleDLL application, the Windows
operating system searches for the SampleDLL DLL in the following locations in
- The application folder
- The current folder
- The Windows system folder
Note The GetSystemDirectory function returns the path of the Windows system
- The Windows folder
Note The GetWindowsDirectory function returns the path of the Windows folder.
The .NET Framework assembly
With the introduction of Microsoft .NET and the .NET Framework,
most of the problems that are associated with DLLs have been eliminated by
using assemblies. An assembly is a logical unit of functionality that runs
under the control of the .NET common language runtime (CLR). An assembly
physically exists as a .dll file or as an .exe file. However, internally an
assembly is very different from a Microsoft Win32 DLL.
file contains an assembly manifest, type metadata, Microsoft intermediate
language (MSIL) code, and other resources. The assembly manifest contains the
assembly metadata that provides all the information that is required for an
assembly to be self-describing. The following information is included in the
- Assembly name
- Version information
- Culture information
- Strong name information
- The assembly list of files
- Type reference information
- Referenced and dependent assembly information
The MSIL code that is contained in the assembly cannot be
directly executed. Instead, MSIL code execution is managed through the CLR. By
default, when you create an assembly, the assembly is private to the
application. To create a shared assembly requires that you assign a strong name
to the assembly and then publish the assembly in the global assembly
The following list describes some of the features of assemblies
compared to the features of Win32 DLLs:
When you create an assembly, all the information that is
required for the CLR to run the assembly is contained in the assembly manifest.
The assembly manifest contains a list of the dependent assemblies. Therefore,
the CLR can maintain a consistent set of assemblies that are used in the
application. In Win32 DLLs, you cannot maintain consistency between a set of
DLLs that are used in an application when you use shared DLLs.
In an assembly manifest, version information is recorded and
enforced by the CLR. Additionally, version policies let you enforce
version-specific usage. In Win32 DLLs, versioning cannot be enforced by the
operating system. Instead, you must make sure that DLLs are backward
- Side-by-side deployment
Assemblies support side-by-side deployment. One application
can use one version of an assembly, and another application can use a different
version of an assembly. Starting in Windows 2000, side-by-side deployment is
supported by locating DLLs in the application folder. Additionally, Windows
File Protection prevents system DLLs from being overwritten or replaced by an
- Self-containment and isolation
An application that is developed by using an assembly can be
self-contained and isolated from other applications that are running on the
computer. This feature helps you create zero-impact installations.
An assembly is run under the security permissions that are
supplied in the assembly manifest and that are controlled by the
- Language independent
An assembly can be developed by using any one of the
supported .NET languages. For example, you can develop an assembly in Microsoft
Visual C#, and then use the assembly in a Microsoft Visual Basic .NET