What does dll stand for?

Computer programs are rarely written in a one file. They often are composed of multiple files that are linked together.

When a program is run, it must be compiled from its source code, which is human readable code that the programmer writes. It's turned into an executable file, which is binary code, or machine code, that the computer can read.

The computer goes through several intermediate steps for this to occur. During those steps, multiple files are linked to one. There are two types of linking -- static and dynamic -- and two types of corresponding link libraries:

Static links. These are linked earlier in the process and are embedded into the executable. Static libraries are linked to the executable when the program is compiled. Dynamic libraries are linked later, either at runtime or at load time. Static libraries are not shared between programs because they are written into the individual executable.

Dynamic links. DLLs contain the files that a program links to. The libraries already are stored on the computer, external to the program that the user writes. They are called dynamic because they are not embedded in the executable -- they just link to it when needed.

An import library, which is a type of static library, replaces all placeholder symbols with actual links to the necessary DLL data in the main program at load time, pulling those functions from the DLL library. Programs provide the name of the library, and the OS creates a path to the link library. Different programs have their own language-specific calling conventions for linking to DLLs.

Because dynamic libraries are not written into the executable, the same shared library can be used by more than one program at the same time. They can also be modified without changing the entire program that is using it.

A dynamically linked program has a small bit of code that maps the DLL into virtual memory, where the program can access it at runtime or load time. With this setup, the dynamically linked program doesn't have to repeatedly access physical memory to access the library. Virtual memory links the same page of physical memory to different programs' virtual addresses -- also known as address space -- as different processes are run.

In the Windows operating systems, dynamic files have a ".dll" file extension, and static files have a ".lib" extension. DLL files may also have ".ocx" (ActiveX), ".cpl" (Control Panel) or ".drv" (driver) suffixes, depending on the DLL function.

Programs do not always need dynamic libraries. In some cases, static linking is preferable. However, some programs specify DLLs that are needed to run and will return an error message if they cannot be accessed.

Dynamic link library (DLL) - Windows Client | Microsoft Learn.

This article describes what a dynamic link library (DLL) is and the various issues that may occur when you use DLLs. It also describes some advanced issues that you should consider when developing your own DLLs.

Applies to:   Windows 10 - all editions Original KB number:   815065

In describing what a DLL is, this article describes dynamic linking methods, DLL dependencies, DLL entry points, exporting DLL functions, and DLL troubleshooting tools.

This article finishes with a high-level comparison of DLLs to the Microsoft .NET Framework assemblies.

For the Windows operating systems, much of the functionality of the operating system is provided by 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. So, 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.

With the introduction of the .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. Each program can use the functionality that is contained in this DLL to implement an Open dialog box. It 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 requested.

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:

The following list describes some of the advantages that are provided when a program uses a DLL:

When a program or a DLL uses a DLL function in another DLL, a dependency is created. 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:

These actions are known as DLL conflicts. If backward compatibility is not enforced, the program may not successfully run.

The following list describes the changes that have been introduced in Windows 2000 and in later Windows operating systems to help minimize dependency issues:

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 does the following checks:

By using Dependency Walker, you can document all the DLLs that a program uses. It may help prevent and correct DLL problems that may occur in the future. Dependency Walker is located in the following directory when you install Visual Studio 6.0:

drive\Program Files\Microsoft Visual Studio\Common\Tools

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:

The DLL Help database helps you locate specific versions of DLLs that are installed by Microsoft software products.

This section describes the issues and the requirements that you should consider when you develop your own 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.

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.

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 dynamic linking:

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.

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.

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: __declspec(dllexport)

To use exported DLL functions in the application, you must declare each function that you want to import with the following keyword: __declspec(dllimport)

Typically, you would use one header file that has a define statement and an ifdef statement to separate the export statement and the import statement.

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 definition file.

In Visual C++ 6.0, you can create a DLL by selecting either the Win32 Dynamic-Link Library project type or the MFC AppWizard (dll) project type.

The following code is an example of a DLL that was created in Visual C++ by using the Win32 Dynamic-Link Library project type.

The following code is an example of a Win32 Application project that calls the exported DLL function in the SampleDLL DLL.

In run-time dynamic linking, you use code that is similar to the following code to call the SampleDLL.dll exported DLL function.

When you compile and link the SampleDLL application, the Windows operating system searches for the SampleDLL DLL in the following locations in this order:

With the introduction of .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 different from a Microsoft Win32 DLL.

An assembly 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 manifest:

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 cache.

The following list describes some of the features of assemblies compared to the features of Win32 DLLs:

If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in Gather information by using TSSv2 for deployment-related issues.