Introduction to Dynamic Link Library

07 juli 2021 om 10:00 by ParTech Media - Post a comment

If you have ever used Windows operating system, the chances of you seeing a DLL file are very high. DLL is, after all, responsible for most of the operations in Windows.

Additionally, when you execute a program on Windows, DLLs may have a significant role in the program's functionality. Some applications may comprise a large number of separate modules, each of which is packaged and distributed in a DLL.

With that brief introduction, let us dive deep and understand everything you need to know about Dynamic Link Library.

Table of contents

  1. What is a Dynamic Link Library?
  2. How does DLL work?
  3. Advantages of Dynamic Link Library
  4. DLL dependencies
  5. Conclusion

What is a Dynamic Link Library?

A collection of small programs that can be loaded and used simultaneously when needed by bigger programs is known as a Dynamic Link Library (DLL). The smaller programs allow the bigger program to communicate with particular devices such as printers, scanners, etc.

A DLL file is given the file format - “.dll.” DLL files are linked with the program dynamically, which uses them only during the execution of the program instead of whenever the main program is being compiled.

The following snippet of code is an example of the DLL entry-point function:

How does DLL work?

Consider two files: foo.exe, a program, and bar.dll, a dynamic link library that foo.exe needs. Now let us ask ourselves a question - When foo.exe is executed, how does the operating system connect these two files?

This is what happens -

The operating system loads the program file foo.exe first, and it finds a table of data in the file that says, "This software uses the following list of functions from the DLL - “bar.dll”. A list of imports or imported functions from the DLL bar.dll in the program foo.exe is referred to first.

The loader code then looks for the file bar.dll, and if it finds it, it loads it. Another list can be found within the bar.dll file. This list, known as the export list, contains the addresses of different functions that are accessible for other applications inside the DLL file. This is set by the DLL file.

The loader then looks through both lists and populates a table in foo.exe (a memory copy of that table) with the addresses of all the functions in bar.dll (based on where the DLL was loaded by the OS in the memory). Now, whenever a program needs to call a DLL function, it simply uses the address saved by the loader in the proper table entry.

There are two key takeaways in this - Using DLLs requires a few extra steps as compared to using regular libraries. Secondly, each DLL that a program utilizes must have its import list.

Advantages of Dynamic Link Library

Here are some of the advantages of having DLLs -

  • DLL files aren't loaded into RAM with the main program. In other words, they don't take up space unless they're needed. A DLL file is loaded and runs only when it is required. The printer DLL file, for example, is not required in RAM when a user of Microsoft Word is editing a document. However, when the user chooses to print the document, the Word application loads and runs the printer DLL file.

  • A DLL aids in the development of modular programs. This is quite useful in the creation of complex programs that require many language versions or a modular architecture. A classic example of a modular program would be an accounting program with several modules that may be dynamically loaded at run-time.

  • The deployment and installation of a DLL do not require the program to be relinked with the DLL when a function within the DLL requires an update or a patch. Furthermore, if numerous apps use the same DLL, the update or fix will benefit all of them. However, when you utilize a third-party DLL that is updated or corrected regularly, this problem may occur more frequently. If the DLL linkage is provided in the IMPORTS section of the module definition file as part of the compilation, applications and DLLs can automatically link to other DLLs. Otherwise, you can use the Windows LoadLibrary method to load them explicitly.

DLL dependencies

A dependency is generated when a program or DLL calls a DLL function in another DLL.

The software is no longer self-contained, and if the reliance is broken, the program may have problems. For example, if one of the following events occurs, the program may not run:

  • The version of a dependent DLL is updated.
  • A DLL that is dependent on another DLL gets corrected.
  • An older version of a dependent DLL is overwritten.
  • The computer's dependent DLL is uninstalled.

DLL conflicts are the name for these actions. The program may fail to execute if backward compatibility is not enforced. The modifications made in Windows 2000 and later Windows operating systems to help decrease dependency issues are described below -

  • Windows File Protection: The operating system's Windows File Protection feature prohibits unauthorized agents from updating or deleting system DLLs. Windows File Protection looks for a valid digital signature when a program tries to remove or update a DLL that is classified as a system DLL.

  • Private DLLs: You can use private DLLs to protect a program from changes made to shared DLLs. To enforce the DLL version utilized by the program, private DLLs use version-specific metadata or an empty local file. To use private DLLs, go to the program's root folder and look for them. Then, for new programs, update the DLL with version-specific information. Use an empty local file for old programs. Each approach instructs the operating system to use the program's root folder's private DLLs.


DLLs typically help to improve code modularization, code reuse, efficient memory utilization, and saving disc space. As a result, the operating system and applications load fast and consume limited disc space on your computer. When software uses a DLL, a problem known as dependency may prevent the application from running. But the use of assemblies has eliminated most challenges related to dependencies since the advent of the.NET Framework.