Bibliotecă de legături dinamice - Dynamic-link library

Acest articol este despre implementarea OS / 2 și Windows. Pentru legarea dinamică a bibliotecilor în general, consultați Dynamic linker .
Nu trebuie confundat cu biblioteca încărcată dinamic .
Bibliotecă de legături dinamice
Dll png.png
Extensie nume de fișier
.dll
Tipul media internet
application / vnd.microsoft.portable-executable
Identificator de tip uniform (UTI) com.microsoft.windows-dynamic-link-library
Număr magic MZ
Dezvoltat de Microsoft
Container pentru Biblioteca comună

Biblioteca de legături dinamice ( DLL ) este Microsoft punerea în aplicare e al bibliotecii partajate conceptul în Microsoft Windows și OS / 2 sisteme de operare . Aceste biblioteci au de obicei extensia de fișier DLL , OCX(pentru biblioteci care conțin ActiveX de control), sau DRV(pentru moștenirea drivere de sistem ). Formatele de fișiere pentru DLL-uri sunt aceleași ca și pentru fișierele Windows EXE - adică Executabil portabil (PE) pentru Windows pe 32 de biți și 64 de biți și Executabil nou (NE) pentru Windows pe 16 biți . Ca și în cazul EXE-urilor, DLL-urile pot conține cod , date și resurse , în orice combinație.

Fișierele de date cu același format de fișier ca un DLL, dar cu extensii de fișiere diferite și care conțin doar secțiuni de resurse, pot fi numite DLL-uri de resurse . Exemple de astfel de DLL-uri includ biblioteci de pictograme , care au uneori extensia ICLși fișiere de fonturi , care au extensiile FONși FOT.

fundal

Primele versiuni ale Microsoft Windows au rulat programe împreună într-un singur spațiu de adrese . Fiecare program a fost menit să coopereze prin cedarea procesorului către alte programe, astfel încât interfața grafică cu utilizatorul (GUI) să poată face mai multe sarcini și să poată răspunde maxim. Toate operațiunile la nivelul sistemului de operare au fost furnizate de sistemul de operare de bază: MS-DOS . Toate serviciile de nivel superior au fost furnizate de bibliotecile Windows „Dynamic Link Library”. API-ul de desen , interfața grafică a dispozitivului (GDI), a fost implementat într-un DLL numit GDI.EXE, interfața utilizator în USER.EXE. Aceste straturi suplimentare din partea de sus a DOS trebuiau partajate între toate programele Windows care rulează, nu doar pentru a permite Windows să funcționeze într-o mașină cu mai puțin de un megabyte de RAM, ci pentru a permite programelor să coopereze între ele. Codul din GDI era necesar pentru a traduce comenzile de desen în operații pe anumite dispozitive. Pe afișaj, a trebuit să manipuleze pixeli în buffer-ul cadrelor. Când trageți la o imprimantă, apelurile API trebuiau transformate în solicitări către o imprimantă. Deși ar fi putut fi oferit suport codificat pentru un set limitat de dispozitive (cum ar fi afișajul adaptorului grafic color , limbajul de comandă al imprimantei HP LaserJet ), Microsoft a ales o abordare diferită. GDI ar funcționa încărcând diferite bucăți de cod, numite „ drivere de dispozitiv ”, pentru a funcționa cu diferite dispozitive de ieșire.

Același concept arhitectural care a permis GDI să încarce diferite drivere de dispozitiv este acela care a permis shell-ului Windows să încarce diferite programe Windows și ca aceste programe să invoce apeluri API din bibliotecile partajate USER și GDI. Acest concept era „legarea dinamică”.

Într-o bibliotecă statică convențională non-partajată , secțiuni de cod sunt pur și simplu adăugate la programul apelant atunci când executabilul său este construit în faza de „legare”; dacă două programe apelează aceeași rutină, rutina este inclusă în ambele programe în timpul etapei de conectare a celor două. Cu legarea dinamică, codul partajat este plasat într-un singur fișier separat. Programele care apelează acest fișier sunt conectate la acesta în timpul rulării, cu sistemul de operare (sau, în cazul versiunilor anterioare ale Windows, extensia OS), efectuând legarea.

Pentru acele versiuni timpurii de Windows (1.0 până la 3.11), DLL-urile au fost fundamentul pentru întreaga GUI. Ca atare, driverele de afișare erau doar DLL-uri cu o extensie .DRV care furnizau implementări personalizate ale aceluiași API de desen printr-o interfață unificată de driver de dispozitiv (DDI), iar API-urile Drawing (GDI) și GUI (USER) erau doar funcțiile apelate exportate de GDI și USER, DLL-uri de sistem cu extensie .EXE.

Această noțiune de a construi sistemul de operare dintr-o colecție de biblioteci încărcate dinamic este un concept de bază al Windows care persistă încă din 2015. DLL-urile oferă avantajele standard ale bibliotecilor partajate , cum ar fi modularitatea . Modularitatea permite modificarea codului și a datelor într-o singură DLL autonomă, partajată de mai multe aplicații, fără nicio modificare a aplicațiilor în sine.

Un alt avantaj al modularității este utilizarea interfețelor generice pentru plug-in-uri. Poate fi dezvoltată o singură interfață care să permită integrarea perfectă a modulelor vechi, precum și a celor noi, în timpul rulării, în aplicații preexistente, fără nicio modificare a aplicației în sine. Acest concept de extensibilitate dinamică este dus la extrem cu Modelul obiectelor componente , bazele ActiveX .

În Windows 1.x, 2.x și 3.x, toate aplicațiile Windows au același spațiu de adrese, precum și aceeași memorie. O DLL a fost încărcată o singură dată în acest spațiu de adrese; de atunci, toate programele care utilizează biblioteca au accesat-o. Datele bibliotecii au fost partajate între toate programele. Aceasta ar putea fi utilizată ca formă indirectă de comunicare între procese sau ar putea corupe accidental diferitele programe. Odată cu introducerea bibliotecilor pe 32 de biți în Windows 95, fiecare proces a rulat în propriul spațiu de adrese. În timp ce codul DLL poate fi partajat, datele sunt private, cu excepția cazului în care datele partajate sunt solicitate în mod explicit de bibliotecă. Acestea fiind spuse, zone mari de Windows 95 , Windows 98 și Windows Me au fost construite din biblioteci de 16 biți, ceea ce a limitat performanța microprocesorului Pentium Pro la lansare și, în cele din urmă, a limitat stabilitatea și scalabilitatea versiunilor Windows bazate pe DOS.

Deși DLL-urile sunt nucleul arhitecturii Windows, acestea au mai multe dezavantaje, denumite în mod colectiv „ DLL hell ”. Începând cu 2015, Microsoft promovează .NET Framework ca o soluție la problemele DLL infernale, deși promovează acum soluții bazate pe virtualizare, cum ar fi Microsoft Virtual PC și Microsoft Application Virtualization , deoarece oferă o izolare superioară între aplicații. O soluție alternativă de atenuare a DLL infernal a fost implementarea ansamblului side-by-side .

Caracteristici

Deoarece DLL-urile sunt în esență aceleași cu EXE-urile, alegerea pe care să o producți ca parte a procesului de conectare este pentru claritate, deoarece este posibil să exportați funcții și date din oricare dintre ele.

Nu este posibil să executați direct o DLL, deoarece necesită un EXE pentru ca sistemul de operare să o încarce printr-un punct de intrare , de unde există existența unor utilitare precum RUNDLL.EXE sau RUNDLL32.EXE care oferă punctul de intrare și cadrul minim pentru DLL-uri. care conțin suficiente funcționalități pentru a fi executate fără prea mult suport.

DLL-urile oferă un mecanism pentru codul și datele partajate, permițând unui dezvoltator de cod / date partajate să actualizeze funcționalitatea fără a necesita re-conectarea sau recompilarea aplicațiilor. Din punctul de vedere al dezvoltării aplicațiilor, Windows și OS / 2 pot fi considerate o colecție de DLL-uri care sunt actualizate, permițând aplicațiilor pentru o versiune a sistemului de operare să funcționeze într-o versiune ulterioară, cu condiția ca furnizorul sistemului de operare să se asigure că interfețele și funcționalitatea sunt compatibile.

DLL-urile se execută în spațiul de memorie al procesului de apelare și cu aceleași permisiuni de acces, ceea ce înseamnă că există puține cheltuieli generale în utilizarea lor, dar, de asemenea, că nu există protecție pentru EXE-ul apelant dacă DLL-ul are vreun fel de eroare.

Gestionarea memoriei

În Windows API , fișierele DLL sunt organizate în secțiuni . Fiecare secțiune are propriul set de atribute, cum ar fi înscriere sau numai în citire, executabil (pentru cod) sau neexecutabil (pentru date) și așa mai departe.

Codul dintr-o DLL este de obicei partajat între toate procesele care utilizează DLL; adică ocupă un singur loc în memoria fizică și nu ocupă spațiu în fișierul paginii . Windows nu folosește cod independent de poziție pentru DLL-urile sale; în schimb, codul suferă relocare pe măsură ce este încărcat, fixând adrese pentru toate punctele sale de intrare în locații care sunt libere în spațiul de memorie al primului proces de încărcare a DLL-ului. În versiunile mai vechi de Windows, în care toate procesele care rulează ocupau un singur spațiu de adresă comun, o singură copie a codului DLL ar fi întotdeauna suficientă pentru toate procesele. Cu toate acestea, în versiunile mai noi de Windows care utilizează spații de adrese separate pentru fiecare program, este posibil să se utilizeze aceeași copie relocată a DLL în mai multe programe dacă fiecare program are aceleași adrese virtuale gratuite pentru a găzdui codul DLL. Dacă unele programe (sau combinația lor de DLL-uri deja încărcate) nu au aceste adrese gratuite, atunci va trebui creată o copie fizică suplimentară a codului DLL, utilizând un set diferit de puncte de intrare mutate. Dacă memoria fizică ocupată de o secțiune de cod urmează să fie recuperată, conținutul acesteia este eliminat și ulterior reîncărcat direct din fișierul DLL, după cum este necesar.

Spre deosebire de secțiunile de cod, secțiunile de date ale unei DLL sunt de obicei private; adică fiecare proces care utilizează DLL are propria copie a tuturor datelor DLL. Opțional, secțiunile de date pot fi partajate, permițând comunicarea inter-proces prin această zonă de memorie partajată. Cu toate acestea, deoarece restricțiile utilizatorilor nu se aplică utilizării memoriei DLL partajate, acest lucru creează o gaură de securitate ; și anume, un proces poate corupe datele partajate, ceea ce va determina probabil ca toate celelalte procese de partajare să se comporte nedorit. De exemplu, un proces care rulează sub un cont de invitat poate corupe un alt proces care rulează sub un cont privilegiat. Acesta este un motiv important pentru a evita utilizarea secțiunilor partajate în DLL-uri.

Dacă un DLL este comprimat de anumite pachete executabile (de exemplu UPX ), toate secțiunile sale de cod sunt marcate ca citite și scrise și vor fi nepartajate. Secțiunile de cod citire și scriere, la fel ca secțiunile de date private, sunt private pentru fiecare proces. Astfel, DLL-urile cu secțiuni de date partajate nu ar trebui să fie comprimate dacă sunt destinate a fi utilizate simultan de mai multe programe, deoarece fiecare instanță de program ar trebui să poarte propria copie a DLL, rezultând un consum crescut de memorie.

Import biblioteci

La fel ca bibliotecile statice, bibliotecile de import pentru DLL-uri sunt notate de extensia de fișier .lib. De exemplu, kernel32.dll , biblioteca dinamică primară pentru funcțiile de bază ale Windows, cum ar fi crearea fișierelor și gestionarea memoriei, este legată prin kernel32.lib. Modul obișnuit de a indica o bibliotecă de import dintr-o bibliotecă statică adecvată este în funcție de dimensiune: biblioteca de import este mult mai mică, deoarece conține doar simboluri referitoare la DLL-ul propriu-zis, care urmează să fie procesate la link-time. Ambele sunt totuși fișiere în format Unix ar .

Legarea la biblioteci dinamice este de obicei gestionată prin legarea la o bibliotecă de import atunci când construiți sau legați pentru a crea un fișier executabil. Executabilul creat conține apoi un tabel de adrese de import (IAT) prin care sunt referite toate apelurile funcției DLL (fiecare funcție DLL referențiată conține propria intrare în IAT). În timpul rulării, IAT este umplut cu adrese corespunzătoare care indică direct o funcție din DLL-ul încărcat separat.

În Cygwin / MSYS și MinGW, bibliotecilor de import li se oferă în mod convențional sufixul .dll.a, combinând atât sufixul Windows DLL, cât și sufixul Unix ar. Formatul fișierului este similar, dar simbolurile utilizate pentru a marca importurile sunt diferite (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). Deși lanțul său de instrumente GNU Binutils poate genera biblioteci de import și se poate conecta la acestea, este mai rapid să se conecteze direct la DLL. Un instrument experimental în MinGW numit genlib poate fi folosit pentru a genera lib-uri de import cu simboluri în stil MSVC.

Rezoluția și legarea simbolurilor

Fiecare funcție exportată de un DLL este identificată printr-un ordinal numeric și opțional un nume. La fel, funcțiile pot fi importate dintr-un DLL fie prin ordinal, fie după nume. Ordinalul reprezintă poziția indicatorului de adresă a funcției în tabelul DLL Export Address. Este obișnuit ca funcțiile interne să fie exportate numai de ordinal. Pentru majoritatea funcțiilor API Windows, numai numele sunt păstrate în diferite versiuni Windows; ordinalii pot fi modificați. Astfel, nu se pot importa în mod fiabil funcțiile API-ului Windows prin ordinale.

Importarea funcțiilor prin ordinal oferă performanțe puțin mai bune decât importarea lor după nume: tabelele de export ale DLL-urilor sunt ordonate după nume, astfel încât o căutare binară poate fi utilizată pentru a găsi o funcție. Indexul numelui găsit este apoi utilizat pentru a căuta ordinalul în tabelul Export Ordinal. În Windows pe 16 biți, tabelul de nume nu a fost sortat, astfel încât supravegherea numelui a fost mult mai vizibilă.

De asemenea, este posibil să legați un executabil la o versiune specifică a unui DLL, adică să rezolvați adresele funcțiilor importate în timpul compilării. Pentru importurile legate, linkerul salvează marca de timp și suma de verificare a DLL-ului la care este legat importul. La runtime, Windows verifică dacă se folosește aceeași versiune a bibliotecii și, dacă da, Windows ocolește procesarea importurilor. În caz contrar, dacă biblioteca este diferită de cea la care era legată, Windows procesează importurile într-un mod normal.

Executabilele legate se încarcă ceva mai repede dacă sunt rulate în același mediu pentru care au fost compilate și exact în același timp dacă sunt rulate într-un mediu diferit, deci nu există nicio neajuns pentru legarea importurilor. De exemplu, toate aplicațiile Windows standard sunt legate de DLL-urile de sistem ale versiunii lor Windows respective. O bună oportunitate de a lega importurile unei aplicații de mediul său țintă este în timpul instalării aplicației. Acest lucru menține bibliotecile „legate” până la următoarea actualizare a sistemului de operare. Cu toate acestea, modifică suma de verificare a executabilului, deci nu este ceva ce poate fi făcut cu programe semnate sau programe care sunt gestionate de un instrument de gestionare a configurației care utilizează sumele de verificare (cum ar fi sumele de verificare MD5 ) pentru a gestiona versiunile de fișiere. Pe măsură ce versiunile Windows mai recente s-au îndepărtat de a avea adrese fixe pentru fiecare bibliotecă încărcată (din motive de securitate), oportunitatea și valoarea legării unui executabil scad.

Conectare explicită în timp de execuție

Fișierele DLL pot fi încărcate în mod explicit în timpul rulării, un proces denumit pur și simplu ca legătură dinamică în timpul rulării de către Microsoft, utilizând funcția API LoadLibrary(sau LoadLibraryEx). Funcția GetProcAddressAPI este utilizată pentru a căuta simbolurile exportate după nume și FreeLibrary- pentru a descărca DLL-ul. Aceste funcții sunt analoge dlopen, dlsymși dlcloseîn POSIX API standardul.

Procedura pentru legarea explicită în timp de execuție este aceeași în orice limbă care acceptă indicii către funcții , deoarece depinde mai degrabă de API-ul Windows decât de construcțiile de limbă.

Încărcare întârziată

În mod normal, o aplicație legată de biblioteca de import a unei DLL nu va porni dacă DLL nu poate fi găsit, deoarece Windows nu va rula aplicația decât dacă poate găsi toate DLL-urile de care ar putea avea nevoie aplicația. Cu toate acestea, o aplicație poate fi legată de o bibliotecă de import pentru a permite încărcarea întârziată a bibliotecii dinamice. În acest caz, sistemul de operare nu va încerca să găsească sau să încarce DLL la pornirea aplicației; în schimb, un link este inclus în aplicație de către linker, care va încerca să găsească și să încarce DLL prin LoadLibrary și GetProcAddress atunci când se apelează una dintre funcțiile sale. Dacă DLL-ul nu poate fi găsit sau încărcat sau funcția apelată nu există, aplicația va genera o excepție , care poate fi prinsă și tratată corespunzător. Dacă aplicația nu gestionează excepția, va fi capturată de sistemul de operare, care va încheia programul cu un mesaj de eroare.

Mecanismul de încărcare cu întârziere oferă, de asemenea, cârlige de notificare , permițând aplicației să efectueze procesare suplimentară sau tratarea erorilor atunci când DLL este încărcat și / sau orice funcție DLL este apelată.

Considerente privind compilatorul și limbajul

Delphi

Într-un fișier sursă, cuvântul cheie libraryeste folosit în loc de program. La sfârșitul fișierului, funcțiile care trebuie exportate sunt enumerate în exportsclauză.

Delphi nu are nevoie de LIBfișiere pentru a importa funcții din DLL-uri; pentru a face legătura cu o DLL, externalcuvântul cheie este utilizat în declarația funcției pentru a semnaliza numele DLL, urmat de namepentru a denumi simbolul (dacă este diferit) sau indexpentru a identifica indexul.

Microsoft Visual Basic

În Visual Basic (VB), este acceptată doar conectarea în timp de execuție; dar pe lângă utilizarea LoadLibraryși GetProcAddressfuncțiile API, sunt permise declarațiile despre funcțiile importate.

La importul funcțiilor DLL prin declarații, VB va genera o eroare în timpul rulării dacă DLLfișierul nu poate fi găsit. Dezvoltatorul poate detecta eroarea și o poate gestiona corespunzător.

Când creați DLL-uri în VB, IDE-ul va permite numai crearea de DLL-uri ActiveX, totuși au fost create metode pentru a permite utilizatorului să spună în mod explicit linkerului să includă un fișier .DEF care definește poziția ordinală și numele fiecărei funcții exportate. Acest lucru permite utilizatorului să creeze un DLL Windows standard utilizând Visual Basic (versiunea 6 sau o versiune inferioară) la care se poate face referire printr-o declarație „Declarați”.

C și C ++

Microsoft Visual C ++ (MSVC) oferă mai multe extensii la C ++ standard care permit specificarea funcțiilor ca importate sau exportate direct în codul C ++; acestea au fost adoptate de alte compilatoare Windows C și C ++, inclusiv versiunile Windows ale GCC . Aceste extensii utilizează atributul __declspecînainte de o declarație de funcție. Rețineți că, atunci când funcțiile C sunt accesate din C ++, acestea trebuie, de asemenea, declarate ca extern "C"în codul C ++, pentru a informa compilatorul că legătura C ar trebui utilizată.

Pe lângă specificarea funcțiilor importate sau exportate folosind __declspecatribute, acestea pot fi listate în secțiunea IMPORT sau EXPORTURI a DEFfișierului utilizat de proiect. DEFFișierul este procesat de linker - ul, mai degrabă decât compilator, și , astfel , nu este specific C ++.

Compilația DLL va produce atât fișiere, cât DLLși LIBfișiere. LIBFișier (biblioteca de import) este folosit pentru a lega împotriva unui DLL în timpul compilării; nu este necesar pentru conectarea în timp de execuție. Cu excepția cazului în care DLL este un server Component Object Model (COM), DLLfișierul trebuie plasat într-unul din directoarele listate în variabila de mediu PATH, în directorul de sistem implicit sau în același director cu programul care îl folosește. DLL-urile serverului COM sunt înregistrate utilizând regsvr32.exe, care plasează locația DLL-ului și ID-ul său unic global ( GUID ) în registru. Programele pot utiliza apoi DLL căutând GUID-ul său în registru pentru a-și găsi locația sau pentru a crea indirect o instanță a obiectului COM folosind identificatorul său de clasă și identificatorul de interfață.

Exemple de programare

Utilizarea importurilor DLL

Următoarele exemple arată cum să utilizați legături specifice limbii pentru a importa simboluri pentru conectarea la o DLL în timpul compilării.

Delphi 

{$APPTYPE CONSOLE}

program Example;

// import function that adds two numbers
function AddNumbers(a, b : Double): Double; StdCall; external 'Example.dll';

// main program
var
   R: Double;

begin
  R := AddNumbers(1, 2);
  Writeln('The result was: ', R);
end.

C

Fișierul Example.lib trebuie inclus (presupunând că este generat Example.dll) în proiect (opțiunea Adăugare element existent pentru proiect!) Înainte de legarea statică. Fișierul Example.lib este generat automat de compilator la compilarea DLL. Nerespectarea declarației de mai sus ar cauza erori de legătură, deoarece linker-ul nu ar ști unde să găsească definiția numărului de adaos. Este posibil ca DLL Example.dll să fie copiat și în locația în care fișierul .exe ar fi generat de următorul cod. 

#include <windows.h>
#include <stdio.h>

// Import function that adds two numbers
extern "C" __declspec(dllimport) double AddNumbers(double a, double b);

int main(int argc, char *argv[])
{
    double result = AddNumbers(1, 2);
    printf("The result was: %f\n", result);
    return 0;
}

Folosirea legăturilor explicite în timp de execuție

Următoarele exemple arată cum să utilizați facilitățile de încărcare și conectare în timp de execuție utilizând legări API Windows specifice limbii.

Rețineți că toate cele patru eșantioane sunt vulnerabile la atacurile de preîncărcare a DLL , deoarece example.dll poate fi rezolvat într-un loc neintenționat de autor (directorul de lucru curent merge înainte de locațiile bibliotecii de sistem) și, astfel, la o versiune dăunătoare a bibliotecii. A se vedea referința pentru orientare Microsoft la încărcare bibliotecă în condiții de siguranță: unul ar trebui să utilizeze SetDllDirectoryWîn kernel32pentru a elimina cautartea curent-director înainte de orice biblioteci sunt încărcate.

Microsoft Visual Basic

Option Explicit
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 "The result was: " & Result
End Sub

Delphi

program Example;
  {$APPTYPE CONSOLE}
  uses Windows;
  var
  AddNumbers:function (a, b: integer): Double; StdCall;
  LibHandle:HMODULE;
begin
  LibHandle := LoadLibrary('example.dll');
  if LibHandle <> 0 then
    AddNumbers := GetProcAddress(LibHandle, 'AddNumbers');
  if Assigned(AddNumbers) then
    Writeln( '1 + 2 = ', AddNumbers( 1, 2 ) );
  Readln;
end.

C

#include <windows.h>
#include <stdio.h>

// DLL function signature
typedef double (*importFunction)(double, double);

int main(int argc, char **argv)
{
	importFunction addNumbers;
	double result;
	HINSTANCE hinstLib;

	// Load DLL file
	hinstLib = LoadLibrary(TEXT("Example.dll"));
	if (hinstLib == NULL) {
		printf("ERROR: unable to load DLL\n");
		return 1;
	}

	// Get function pointer
	addNumbers = (importFunction) GetProcAddress(hinstLib, "AddNumbers");
	if (addNumbers == NULL) {
		printf("ERROR: unable to find DLL function\n");
		FreeLibrary(hinstLib);
		return 1;
	}

	// Call function.
	result = addNumbers(1, 3);

	// Unload DLL file
	FreeLibrary(hinstLib);

	// Display result
	printf("The result was: %f\n", result);

	return 0;
}

Piton

Legarea ctypes-urilor Python va utiliza POSIX API pe sistemele POSIX. 

import ctypes

my_dll = ctypes.cdll.LoadLibrary("Example.dll")

# The following "restype" method specification is needed to make
# Python understand what type is returned by the function.
my_dll.AddNumbers.restype = ctypes.c_double

p = my_dll.AddNumbers(ctypes.c_double(1.0), ctypes.c_double(2.0))

print("The result was:", p)

Modelul obiectelor componente

Obiectul Component model (COM) definește un standard binar pentru a găzdui punerea în aplicare a obiectelor în fișiere DLL și EXE. Oferă mecanisme pentru localizarea și versiunea acestor fișiere, precum și o descriere a interfeței independentă de limbă și care poate fi citită de mașină. Găzduirea obiectelor COM într-un DLL este mai ușoară și le permite să partajeze resursele cu procesul clientului. Acest lucru permite obiectelor COM să implementeze back-end-uri puternice la front-end-uri GUI simple, cum ar fi Visual Basic și ASP. De asemenea, pot fi programate din limbaje de script.

Deturnarea DLL

Datorită unei vulnerabilități cunoscute în mod obișnuit sub numele de hijacking DLL, spoofing DLL, preîncărcare DLL sau plantare binară, multe programe vor încărca și executa o DLL rău intenționată conținută în același folder ca un fișier de date deschis de aceste programe. Vulnerabilitatea a fost descoperită de Georgi Guninski în 2000. În august 2010 a câștigat publicitate la nivel mondial după ce ACROS Security a redescoperit-o din nou și multe sute de programe au fost găsite vulnerabile. Programele care sunt rulate din locații nesigure, adică foldere care pot fi scrise de utilizator, cum ar fi Descărcările sau directorul Temp , sunt aproape întotdeauna susceptibile la această vulnerabilitate.

Vezi si

Referințe

  • Hart, Johnson. Programarea sistemului Windows Ediția a treia . Addison-Wesley, 2005. ISBN  0-321-25619-0 .
  • Rector, Brent și colab. Programare Win32 . Addison-Wesley Developers Press, 1997. ISBN  0-201-63492-9 .

linkuri externe