DLL, or dynamic-link library, is a file containing executable routines that can be loaded on demand by an application.
What is a DLL?
A DLL (Dynamic Link Library) is a file that contains compiled code and resources that can be used by multiple programs at the same time. DLLs are often used to provide common functionality that multiple programs can use, such as networking functions, graphics routines, or mathematics libraries.
One advantage of using DLLs is that they can be shared among multiple programs, which can reduce the amount of storage space required on a device. It can also make it easier to update and maintain the code because a change to a DLL can be applied to all the programs that use it.
DLLs are commonly used in the Windows operating system, but they can also be used on other platforms. They are typically stored in a specific location on the computer and are loaded into memory when a program that uses them is run.
The file formats for DLLs are the same as for Windows EXE files – that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.
DLLs are loaded into RAM only when needed by the calling application, which reduces the memory requirements of large applications. DLLs are files that have the extension .dll.
Before DLL
The first versions of Microsoft Windows ran programs together in a single address space. Every program was meant to co-operate by yielding the CPU to other programs so that the graphical user interface (GUI) could multitask and be maximally responsive. All operating-system level operations were provided by the underlying operating system: MS-DOS. All higher-level services were provided by Windows Libraries “Dynamic Link Library”.
The Drawing API, Graphics Device Interface (GDI), was implemented in a DLL called GDI.EXE, the user interface in USER.EXE. These extra layers on top of DOS had to be shared across all running Windows programs, not just to enable Windows to work in a machine with less than a megabyte of RAM, but to enable the programs to co-operate with each other.
The code in GDI needed to translate drawing commands to operations on specific devices. On the display, it had to manipulate pixels in the frame buffer. When drawing to a printer, the API calls had to be transformed into requests to a printer. Although it could have been possible to provide hard-coded support for a limited set of devices (like the Color Graphics Adapter display, and the HP LaserJet Printer Command Language), Microsoft chose a different approach. GDI would work by loading different pieces of code, called “device drivers”, to work with different output devices.
The same architectural concept that allowed GDI to load different device drivers is that which allowed the Windows shell to load different Windows programs, and for these programs to invoke API calls from the shared USER and GDI libraries. That concept was “dynamic linking“