Dynamic Link Library
Dynamic Link Library | |
---|---|
File extension : |
.dll, .DLL
|
MIME type : |
application / vnd.microsoft.portable-executable, application / x-msdownload, application / octet-stream |
Developed by: | Microsoft |
Type: | dynamic library |
Dynamic Link Library ( DLL ) generally refers to a dynamic program library ; however, the term mostly refers to the variant used for the Microsoft Windows and OS / 2 operating systems .
DLL files use the file format that is also used for executable EXE files, which is the New Executable Format (NE) in 16-bit programs and the Portable Executable Format (PE) in 32 and 64-bit programs . These files can contain program code ( machine code ), data and resources in any combination.
The Windows file name extension for such libraries is usually DLL
, there may be other file extensions such as OCX
(for libraries with ActiveX controls built), DRV
or CPL
(for the control panel to be).
background
The main purpose of DLL files is to reduce the amount of space required by applications on the hard drive and in main memory. Code and data that could be required by more than one application are therefore stored in a single file on the hard disk and only loaded once into main memory when several programs require the same program library.
Additional advantages
If a piece of program code is improved, it is not necessary to change all programs that use this code; it is sufficient to update it in the DLL. In this case, all programs can access the updated version. This enables software developers to issue relatively small patches for larger software packages, for example for entire operating systems. An entire package can be brought up to date by updating individual DLLs.
In the form of plug-ins , new program parts for an existing program can be created with DLLs and seamlessly integrated into them, without having to make changes to the existing program. This idea of dynamic "integration" is implemented, for example, under Windows using ActiveX .
Such a modular structure also makes it possible to simply deactivate functions that are not required.
weaknesses
A problem known as a DLL conflict in Windows occurs when multiple applications require different versions of the same DLL. If a program is missing the required version, this can lead to problems such as faulty installations. This conflict can often be resolved by copying the correct version of the program library into the program folder of the respective program. This negates the effect of saving memory, however. With Microsoft .NET it is possible to circumvent version conflicts in DLL files by allowing several versions of a program library to exist at the same time. However, this is only possible for DLL files developed with .NET.
In certain cases, DLL hijacking or malicious use of DLL injection is possible.
Handling within the operating system
Loading of DLLs at a program start
When a program is to be executed, it is loaded into memory by the loader of the operating system and the import table of the program is read out. This table contains all DLL command names or the ordinal numbers of the DLL commands that are required by this program. The loader now loads the missing DLLs into memory and inserts the entry addresses of the individual commands in the import table of the program.
DLL file structure
A DLL has (after the MZ header ) the same NE header or PE header as a normal executable file, only in the case of an NE the DWORD flag at the address 0C hex in the NE header is set to 8000 hex (Library Module flag) or the IMAGE_FILE_DLL bit is set in the characteristics value in the PE header . While both DLLs and executable files can have an export table , the latter is rarely used. This "export table" lists all the names of the functions and variables that the DLL makes available to external software. These names must be sorted alphabetically so that the loader can find them.
Calling a DLL command by a program
First the values to be transferred are stored on the stack - in the same way as with other subroutines - then an indirect jump is made to the value of the DLL address stored by the loader in the import table.
DLLs in memory
There are two different ways in which DLLs can be loaded into memory by the operating system. There are static DLLs that are only loaded once. All programs then access this one instance of the DLL. This DLL then only has a single global memory area. The Windows kernel DLLs are such static DLLs, which allow them to manage the entire system (e.g. monitor all open files). Another way of managing DLLs in memory is that every time a new program needs a DLL, a new instance of it is loaded into memory.
A further flag in the DLL's header determines whether a DLL is static or not.
DLL instance counter
Every time a DLL is loaded by a program, an internal instance counter for this DLL is incremented. The system can use this counter to recognize whether a DLL is still in use or can be unloaded. The latter happens when the instance counter reaches zero, because the last running program that used the DLL has unloaded the DLL and it no longer needs to be kept in memory.
Programming examples for 32-bit Windows
Working with DLLs in Visual C ++
Create a DLL with a function
The DLL interface is __declspec(dllexport)
defined using the export function .
This is demonstrated in the following example:
// Nur unter Microsoft Visual C++ hat das Makro "DLL" eine Funktion.
// Unter zum Beispiel Linux ist das Makro "DLL" leer.
#if defined(_MSC_VER)
#include <windows.h>
#define DLL extern "C" __declspec(dllexport)
#else
#define DLL
#endif
// Die Funktion, die anderen Programmen zur Verfügung gestellt werden soll
// (in diesem Beispiel: Addieren zweier Zahlen)
DLL double AddNumbers (double a, double b)
{
return a + b ;
}
This example creates both a DLL
and a LIB
file when compiled .
Include a DLL and call this function
DLL functions can easily be called after __declspec(dllimport)
importing them with the function .
#include <windows.h>
#include <stdio.h>
// Importieren der Funktion aus der oben erstellten DLL
extern "C" __declspec(dllimport) double AddNumbers (double a, double b) ;
int main (void)
{
// Aufrufen der externen Funktion
double result = AddNumbers (1, 2) ;
printf ("Das Ergebnis ist: %f\n", result) ;
return 0 ;
}
Please note that the linker needs the LIB file and that the DLL file should be in the same folder as the program that is to call it. The LIB file is required by the linker so that it can incorporate “placeholders” for the functions later called from the DLL.
Include a DLL at runtime and call this function
DLL libraries can be loaded into an application in two different ways: either when the program is started (as described in the examples above) or later during runtime by using the API functions LoadLibrary
, GetProcAddress
and FreeLibrary
. The way in which DLLs are to be integrated during runtime is the same in every programming language, as long as you want to import a Windows API function. The following code demonstrates this using a VC ++ example:
#include <windows.h>
#include <stdio.h>
// Definition des Types der DLL-Funktion, die verwendet werden soll
typedef double (*BinaryFunction_t) (double, double) ;
int main (void)
{
BinaryFunction_t AddNumbers ;
double result ;
BOOL fFreeResult ;
// DLL-Datei laden
HINSTANCE hinstLib = LoadLibrary ("MyDll.dll") ;
if (hinstLib != NULL)
{
// Die Einsprungadresse abfragen
AddNumbers = (BinaryFunction_t) GetProcAddress (hinstLib, "AddNumbers") ;
// Die Funktion aufrufen
if ( AddNumbers != NULL )
result = (*AddNumbers) (1, 2) ;
// Die DLL-Datei wieder entladen
fFreeResult = FreeLibrary (hinstLib) ;
}
// Das Ergebnis anzeigen
if (hinstLib == NULL || AddNumbers == NULL)
printf ("Fehler: Konnte die Funktion nicht aufrufen\n") ;
else
printf ("Das Ergebnis ist: %f\n", result) ;
return 0 ;
}
The LIB
file is not required in this case. The DLL
file must still be in a folder that the program can access.
It should also be noted that if you attempt to automatically load a non-existent DLL when the program is started, the operating system displays an error message and the program is terminated without the programmer being able to catch this error. However, when integrating DLLs during runtime, errors during loading can be caught.
Using DLLs in Object Pascal
Create a DLL
In the head of the source code the keyword must library
instead of program
used. At the end of the file, the functions to be exported are then exports
listed in the area:
library Beispiel;
// Die Funktion, die anderen Programmen zur Verfügung gestellt werden soll
// (in diesem Beispiel: Addieren zweier Zahlen)
function AddNumbers(a, b: Double): Double; cdecl;
begin
Result := a + b;
end;
// Exportieren der Funktion
exports
AddNumbers;
// In diesem Fall muss kein spezieller Initialisierungs-Quellcode angegeben werden
begin
end.
Include / call a DLL
Delphi doesn't need LIB
files to import a function correctly. Only the keyword has to be external
used to integrate a DLL :
program Beispiel;
{$APPTYPE CONSOLE}
// Importieren der Funktion aus einer externen DLL
function AddNumbers(a, b: Double): Double; cdecl; external 'Beispiel.dll';
var result: Double;
begin
result := AddNumbers(1, 2);
Writeln('Das Ergebnis ist: ', result)
end.
Use DLLs in Visual Basic Classic
From VB up to version 6 only loading of DLLs during runtime is supported. In addition to using the API functions LoadLibrary
and it GetProcAddress
is possible in Visual Basic to declare external DLL functions , which makes this work a lot easier for the developer:
Option Explicit On
Declare Function AddNumbers Lib "Example.dll" (ByVal a As Double, ByVal b As Double) As Double
Sub Main()
Dim Result As Double
Result = AddNumbers(1, 2)
Debug.Print "Das Ergebnis ist: " & Result
End Sub
If an error occurs while loading the DLL function, VB will throw a runtime error. However, this can be intercepted and treated. You must also observe the calling convention of the exported function: Visual Basic assumes that the function is _stdcall . Therefore, up to VB7, the import of _cdecl functions was only possible via an interposed wrapper DLL.
Use Win32 DLLs in .NET
In .NET DLLs are integrated using the DllImport attribute. The namespace "System.Runtime.InteropServices" is required for this. The function prototype is specified in C # as "external", which is not necessary in VB.NET , then the function can be addressed like any other:
C #
using System;
using System.Runtime.InteropServices;
namespace DllImportBeispiel
{
class Program
{
[DllImport("Example.dll")]
static extern double AddNumbers(double a, double b);
static void Main()
{
Console.WriteLine( AddNumbers( 1, 2 ) );
}
}
}
VB.NET
Imports System.Runtime.InteropServices
Class Program
<DllImport("Example.dll")> _
Private Shared Function AddNumbers(a As Double, b As Double) As Double
End Function
Private Shared Sub Main()
Console.WriteLine(AddNumbers(1, 2))
End Sub
End Class
Direct integration of DLLs in Visual Studio
However, if several methods or functions of a DLL are to be accessed, this can also be integrated directly via the Project Explorer of Visual Studio . The functions of the DLL can then be used by either specifying the complete namespace in front of the method class in the code, or by directly integrating the namespace with using (C #) or Imports (VB.Net). The System.Runtime.InteropServices namespace is not required with this approach.
The following example shows the directly integrated DLL (the namespace here corresponds to the name of the DLL):
C #
using Example;
class Program
{
static void Main()
{
Console.WriteLine(AddNumbers(1, 2));
}
}
VB.Net
Imports Example
Class Program
Private Shared Sub Main()
Console.WriteLine(AddNumbers(1, 2))
End Sub
End Class
See also
- Dependency Walker , part of Microsoft Visual Studio up to version 2005, with which functions that a program exports and imports can be displayed hierarchically.
Individual evidence
- ↑ a b K. B. Microsoft: Executable-File Header Format
Web links
- Using _declspec (dllimport) and _declspec (dllexport) with MSDN Library
- Win32 DLL - Instructions on how tocreate and call DLLsin C ++ with Visual Studio
- Description of the Windows libraries supported by graphics and videos. Static libs and DLLs.
- Creation and calling of Windows libraries, DLLs. Closer examination of the processes.