Libreria a collegamento dinamico - Dynamic-link library

Questo articolo riguarda l'implementazione di OS/2 e Windows. Per il collegamento dinamico delle librerie in generale, vedere Linker dinamico .
Da non confondere con Libreria caricata dinamicamente .
Libreria di collegamenti dinamici
Dll png.png
Estensione nome file
.dll
Tipo di media Internet
application/vnd.microsoft.portable-executable
Identificatore di tipo uniforme (UTI) com.microsoft.windows-dynamic-link-library
Numero magico MZ
Sviluppato da Microsoft
contenitore per Libreria condivisa

Libreria di collegamento dinamico ( DLL ) è Microsoft implementazione s' della libreria condivisa concetto nel Microsoft Windows e OS / 2 sistemi operativi . Queste librerie di solito hanno l' estensione file DLL , OCX(per le librerie contenenti controlli ActiveX ) o DRV(per i driver di sistema legacy ). I formati di file per le DLL sono gli stessi dei file EXE di Windows , ovvero Portable Executable (PE) per Windows a 32 e 64 bit e New Executable (NE) per Windows a 16 bit . Come con gli EXE, le DLL possono contenere codice , dati e risorse , in qualsiasi combinazione.

I file di dati con lo stesso formato di file di una DLL, ma con estensioni di file diverse e possibilmente contenenti solo sezioni di risorse, possono essere chiamati DLL di risorse . Esempi di tali DLL includono librerie di icone , a volte con estensione ICL, e file di caratteri , con estensioni FONe FOT.

Sfondo

Le prime versioni di Microsoft Windows eseguivano i programmi insieme in un unico spazio di indirizzi . Ogni programma doveva cooperare cedendo la CPU ad altri programmi in modo che l' interfaccia utente grafica (GUI) potesse multitasking ed essere massimamente reattiva. Tutte le operazioni a livello di sistema operativo sono state fornite dal sistema operativo sottostante: MS-DOS . Tutti i servizi di livello superiore sono stati forniti dalle librerie di Windows "Dynamic Link Library". L' API di disegno , Graphics Device Interface (GDI), è stata implementata in una DLL chiamata GDI.EXE, l'interfaccia utente in USER.EXE. Questi livelli aggiuntivi su DOS dovevano essere condivisi tra tutti i programmi Windows in esecuzione, non solo per consentire a Windows di funzionare in una macchina con meno di un megabyte di RAM, ma per consentire ai programmi di cooperare tra loro. Il codice in GDI doveva tradurre i comandi di disegno in operazioni su dispositivi specifici. Sul display, doveva manipolare i pixel nel frame buffer. Quando si disegna su una stampante, le chiamate API dovevano essere trasformate in richieste a una stampante. Sebbene sarebbe stato possibile fornire supporto codificato per un set limitato di dispositivi (come il display dell'adattatore grafico a colori , il linguaggio di comando della stampante HP LaserJet ), Microsoft ha scelto un approccio diverso. GDI funzionerebbe caricando diversi pezzi di codice, chiamati " driver di dispositivo ", per funzionare con diversi dispositivi di output.

Lo stesso concetto architettonico che ha consentito a GDI di caricare driver di dispositivo diversi è quello che ha consentito alla shell di Windows di caricare programmi Windows diversi e a questi programmi di invocare chiamate API dalle librerie USER e GDI condivise. Quel concetto era "collegamento dinamico".

In una libreria statica convenzionale non condivisa , sezioni di codice vengono semplicemente aggiunte al programma chiamante quando il suo eseguibile viene compilato in fase di "linking"; se due programmi chiamano la stessa routine, la routine è inclusa in entrambi i programmi durante la fase di collegamento dei due. Con il collegamento dinamico, il codice condiviso viene inserito in un unico file separato. I programmi che chiamano questo file sono collegati ad esso in fase di esecuzione, con il sistema operativo (o, nel caso delle prime versioni di Windows, l'estensione del sistema operativo), che esegue l'associazione.

Per quelle prime versioni di Windows (da 1.0 a 3.11), le DLL erano la base per l'intera GUI. Pertanto, i driver di visualizzazione erano semplicemente DLL con un'estensione .DRV che fornivano implementazioni personalizzate della stessa API di disegno tramite un'interfaccia unificata del driver di dispositivo (DDI) e le API di disegno (GDI) e GUI (USER) erano semplicemente le chiamate di funzione esportate da GDI e USER, DLL di sistema con estensione .EXE.

Questa nozione di creazione del sistema operativo da una raccolta di librerie caricate dinamicamente è un concetto fondamentale di Windows che persiste dal 2015. Le DLL forniscono i vantaggi standard delle librerie condivise , come la modularità . La modularità consente di apportare modifiche al codice e ai dati in un'unica DLL autonoma condivisa da più applicazioni senza alcuna modifica alle applicazioni stesse.

Un altro vantaggio della modularità è l'uso di interfacce generiche per i plug-in. È possibile sviluppare un'unica interfaccia che consente di integrare in modo trasparente moduli vecchi e nuovi in ​​fase di esecuzione in applicazioni preesistenti, senza alcuna modifica all'applicazione stessa. Questo concetto di estensibilità dinamica è portato all'estremo con il Component Object Model , alla base di ActiveX .

In Windows 1.x, 2.x e 3.x, tutte le applicazioni Windows condividevano lo stesso spazio di indirizzi e la stessa memoria. Una DLL è stata caricata solo una volta in questo spazio di indirizzi; da quel momento in poi, tutti i programmi che utilizzavano la libreria vi accedevano. I dati della biblioteca sono stati condivisi tra tutti i programmi. Questo potrebbe essere utilizzato come forma indiretta di comunicazione tra processi o potrebbe danneggiare accidentalmente i diversi programmi. Con l'introduzione delle librerie a 32 bit in Windows 95, ogni processo veniva eseguito nel proprio spazio di indirizzi. Sebbene il codice DLL possa essere condiviso, i dati sono privati, tranne quando i dati condivisi vengono richiesti esplicitamente dalla libreria. Detto questo, ampie porzioni di Windows 95 , Windows 98 e Windows Me sono state create da librerie a 16 bit, il che ha limitato le prestazioni del microprocessore Pentium Pro al momento del lancio e, in definitiva, ha limitato la stabilità e la scalabilità delle versioni di Windows basate su DOS.

Sebbene le DLL siano il cuore dell'architettura di Windows, presentano diversi inconvenienti, chiamati collettivamente " DLL hell ". A partire dal 2015 Microsoft promuove .NET Framework come una soluzione ai problemi dell'inferno DLL, sebbene ora promuovono soluzioni basate sulla virtualizzazione come Microsoft Virtual PC e Microsoft Application Virtualization , perché offrono un isolamento superiore tra le applicazioni. Una soluzione alternativa per attenuare l'inferno delle DLL è stata l'implementazione di un assembly side-by-side .

Caratteristiche

Poiché le DLL sono essenzialmente le stesse degli EXE, la scelta di quali produrre come parte del processo di collegamento è per chiarezza, poiché è possibile esportare funzioni e dati da entrambi.

Non è possibile eseguire direttamente una DLL, poiché richiede un EXE affinché il sistema operativo lo carichi attraverso un punto di ingresso , quindi l'esistenza di utilità come RUNDLL.EXE o RUNDLL32.EXE che forniscono il punto di ingresso e il framework minimo per le DLL che contengono funzionalità sufficienti per l'esecuzione senza molto supporto.

Le DLL forniscono un meccanismo per codice e dati condivisi, consentendo a uno sviluppatore di codice/dati condivisi di aggiornare le funzionalità senza richiedere il ricollegamento o la ricompilazione delle applicazioni. Dal punto di vista dello sviluppo delle applicazioni, Windows e OS/2 possono essere pensati come una raccolta di DLL che vengono aggiornate, consentendo alle applicazioni per una versione del sistema operativo di funzionare in una successiva, a condizione che il fornitore del sistema operativo abbia assicurato che le interfacce e funzionalità sono compatibili.

Le DLL vengono eseguite nello spazio di memoria del processo chiamante e con le stesse autorizzazioni di accesso, il che significa che c'è poco sovraccarico nel loro utilizzo ma anche che non c'è protezione per l'EXE chiamante se la DLL ha qualche tipo di bug.

Gestione della memoria

In API di Windows , i file DLL sono organizzati in sezioni . Ogni sezione ha il proprio set di attributi, come essere scrivibile o di sola lettura, eseguibile (per il codice) o non eseguibile (per i dati) e così via.

Il codice in una DLL è generalmente condiviso tra tutti i processi che utilizzano la DLL; cioè, occupano un unico posto nella memoria fisica e non occupano spazio nel file di paging . Windows non utilizza codice indipendente dalla posizione per le sue DLL; invece il codice subisce rilocazione man mano che viene caricato, fissando gli indirizzi per tutti i suoi punti di ingresso in posizioni che sono libere nello spazio di memoria del primo processo per caricare la DLL. Nelle versioni precedenti di Windows, in cui tutti i processi in esecuzione occupavano un unico spazio di indirizzi comune, una singola copia del codice della DLL sarebbe sempre sufficiente per tutti i processi. Tuttavia, nelle versioni più recenti di Windows che utilizzano spazi di indirizzi separati per ogni programma, è possibile utilizzare la stessa copia riposizionata della DLL in più programmi solo se ogni programma ha gli stessi indirizzi virtuali liberi per ospitare il codice della DLL. Se alcuni programmi (o la loro combinazione di DLL già caricate) non hanno questi indirizzi liberi, sarà necessario creare una copia fisica aggiuntiva del codice della DLL, utilizzando un diverso insieme di punti di ingresso riposizionati. Se la memoria fisica occupata da una sezione di codice deve essere recuperata, il suo contenuto viene scartato e successivamente ricaricato direttamente dal file DLL, se necessario.

A differenza delle sezioni di codice, le sezioni di dati di una DLL sono generalmente private; ovvero, ogni processo che utilizza la DLL ha la propria copia di tutti i dati della DLL. Facoltativamente, le sezioni di dati possono essere condivise, consentendo la comunicazione tra processi tramite questa area di memoria condivisa. Tuttavia, poiché le restrizioni dell'utente non si applicano all'utilizzo della memoria DLL condivisa, ciò crea una falla nella sicurezza ; vale a dire, un processo può corrompere i dati condivisi, il che probabilmente farà sì che tutti gli altri processi di condivisione si comportino in modo indesiderabile. Ad esempio, un processo in esecuzione con un account ospite può in questo modo danneggiare un altro processo in esecuzione con un account privilegiato. Questo è un motivo importante per evitare l'utilizzo di sezioni condivise nelle DLL.

Se una DLL viene compressa da determinati packer eseguibili (ad es. UPX ), tutte le sue sezioni di codice vengono contrassegnate come lette e scritte e non saranno condivise. Le sezioni di codice di lettura e scrittura, proprio come le sezioni di dati privati, sono private per ogni processo. Pertanto, le DLL con sezioni di dati condivise non dovrebbero essere compresse se sono destinate a essere utilizzate contemporaneamente da più programmi, poiché ogni istanza di programma dovrebbe contenere la propria copia della DLL, con conseguente aumento del consumo di memoria.

Importa librerie

Come le librerie statiche, le librerie di importazione per le DLL sono indicate dall'estensione del file .lib. Ad esempio, kernel32.dll , la libreria dinamica primaria per le funzioni di base di Windows come la creazione di file e la gestione della memoria, è collegata tramite kernel32.lib. Il modo normale per distinguere una libreria di importazione da una libreria statica appropriata è per dimensione: la libreria di importazione è molto più piccola in quanto contiene solo simboli che si riferiscono alla DLL effettiva, da elaborare al momento del collegamento. Entrambi sono comunque file in formato Unix ar .

Il collegamento a librerie dinamiche viene in genere gestito collegandosi a una libreria di importazione durante la creazione o il collegamento per creare un file eseguibile. L'eseguibile creato contiene quindi una tabella di indirizzi di importazione (IAT) in base alla quale fanno riferimento tutte le chiamate di funzione DLL (ogni funzione DLL a cui si fa riferimento contiene la propria voce nello IAT). In fase di esecuzione, lo IAT viene riempito con indirizzi appropriati che puntano direttamente a una funzione nella DLL caricata separatamente.

In Cygwin/MSYS e MinGW, alle librerie di importazione viene convenzionalmente assegnato il suffisso .dll.a, che combina sia il suffisso DLL di Windows che il suffisso Unix ar. Il formato del file è simile, ma i simboli utilizzati per contrassegnare le importazioni sono diversi (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). Sebbene la sua toolchain GNU Binutils possa generare librerie di importazione e collegarsi ad esse, è più veloce collegarsi direttamente alla DLL. Uno strumento sperimentale in MinGW chiamato genlib può essere utilizzato per generare librerie di importazione con simboli in stile MSVC.

Risoluzione dei simboli e associazione

Ogni funzione esportata da una DLL è identificata da un ordinale numerico e facoltativamente da un nome. Allo stesso modo, le funzioni possono essere importate da una DLL per ordinale o per nome. L'ordinale rappresenta la posizione del puntatore dell'indirizzo della funzione nella tabella degli indirizzi di esportazione della DLL. È comune che le funzioni interne vengano esportate solo per ordinale. Per la maggior parte delle funzioni API di Windows vengono conservati solo i nomi nelle diverse versioni di Windows; gli ordinali sono soggetti a modifiche. Pertanto, non è possibile importare in modo affidabile le funzioni API di Windows in base ai loro ordinali.

L'importazione di funzioni per ordinale fornisce prestazioni solo leggermente migliori rispetto all'importazione per nome: le tabelle di esportazione delle DLL sono ordinate per nome, quindi è possibile utilizzare una ricerca binaria per trovare una funzione. L'indice del nome trovato viene quindi utilizzato per cercare l'ordinale nella tabella Export Ordinal. In Windows a 16 bit, la tabella dei nomi non era ordinata, quindi l'overhead di ricerca del nome era molto più evidente.

È anche possibile associare un eseguibile a una versione specifica di una DLL, ovvero risolvere gli indirizzi delle funzioni importate in fase di compilazione. Per le importazioni associate, il linker salva il timestamp e il checksum della DLL a cui è associata l'importazione. In fase di esecuzione, Windows verifica se viene utilizzata la stessa versione della libreria e, in tal caso, ignora l'elaborazione delle importazioni. Altrimenti, se la libreria è diversa da quella a cui era associata, Windows elabora le importazioni in modo normale.

Gli eseguibili associati si caricano un po' più velocemente se vengono eseguiti nello stesso ambiente per cui sono stati compilati ed esattamente nello stesso tempo se vengono eseguiti in un ambiente diverso, quindi non c'è alcun inconveniente per il binding delle importazioni. Ad esempio, tutte le applicazioni Windows standard sono legate alle DLL di sistema della rispettiva versione di Windows. Una buona opportunità per associare le importazioni di un'applicazione al relativo ambiente di destinazione è durante l'installazione dell'applicazione. Ciò mantiene le librerie "vincolate" fino al prossimo aggiornamento del sistema operativo. Tuttavia, modifica il checksum dell'eseguibile, quindi non è qualcosa che può essere fatto con programmi firmati o programmi gestiti da uno strumento di gestione della configurazione che utilizza i checksum (come i checksum MD5 ) per gestire le versioni dei file. Poiché le versioni più recenti di Windows si sono allontanate dall'avere indirizzi fissi per ogni libreria caricata (per motivi di sicurezza), l'opportunità e il valore dell'associazione di un eseguibile stanno diminuendo.

Collegamento esplicito in fase di esecuzione

I file DLL possono essere caricati in modo esplicito in fase di esecuzione, un processo denominato semplicemente collegamento dinamico in fase di esecuzione da parte di Microsoft, utilizzando la funzione API LoadLibrary(o LoadLibraryEx). La GetProcAddressfunzione API viene utilizzata per cercare i simboli esportati per nome e FreeLibrary– per scaricare la DLL. Queste funzioni sono analoghe a dlopen, dlsyme dlclosenel POSIX API standard.

La procedura per il collegamento esplicito in fase di esecuzione è la stessa in qualsiasi linguaggio che supporta i puntatori a functions , poiché dipende dall'API di Windows anziché dai costrutti del linguaggio.

Caricamento ritardato

Normalmente, un'applicazione collegata alla libreria di importazione di una DLL non verrà avviata se la DLL non può essere trovata, perché Windows non eseguirà l'applicazione a meno che non riesca a trovare tutte le DLL di cui l'applicazione potrebbe aver bisogno. Tuttavia, un'applicazione può essere collegata a una libreria di importazione per consentire il caricamento ritardato della libreria dinamica. In questo caso il sistema operativo non tenterà di trovare o caricare la DLL all'avvio dell'applicazione; uno stub viene invece incluso nell'applicazione dal linker che tenterà di trovare e caricare la DLL tramite LoadLibrary e GetProcAddress quando viene chiamata una delle sue funzioni. Se la DLL non può essere trovata o caricata o la funzione chiamata non esiste, l'applicazione genererà un'eccezione , che può essere rilevata e gestita in modo appropriato. Se l'applicazione non gestisce l'eccezione, verrà rilevata dal sistema operativo, che terminerà il programma con un messaggio di errore.

Il meccanismo di caricamento ritardato fornisce anche hook di notifica , consentendo all'applicazione di eseguire ulteriori elaborazioni o gestione degli errori quando viene caricata la DLL e/o viene chiamata qualsiasi funzione della DLL.

Considerazioni sul compilatore e sul linguaggio

Delphi

In un file sorgente, libraryviene utilizzata la parola chiave al posto di program. Alla fine del file, le funzioni da esportare sono elencate nella exportsclausola.

Delphi non ha bisogno di LIBfile per importare funzioni da DLL; per collegarsi a una DLL, la externalparola chiave viene utilizzata nella dichiarazione di funzione per segnalare il nome della DLL, seguita da nameper denominare il simbolo (se diverso) o indexper identificare l'indice.

Microsoft Visual Basic

In Visual Basic (VB), è supportato solo il collegamento in fase di esecuzione; ma oltre all'utilizzo LoadLibrarye alle GetProcAddressfunzioni API, sono consentite dichiarazioni di funzioni importate.

Quando si importano funzioni DLL tramite dichiarazioni, VB genererà un errore di runtime se DLLnon è possibile trovare il file. Lo sviluppatore può rilevare l'errore e gestirlo in modo appropriato.

Quando si creano DLL in VB, l'IDE consentirà solo la creazione di DLL ActiveX, tuttavia sono stati creati metodi per consentire all'utente di indicare esplicitamente al linker di includere un file .DEF che definisce la posizione ordinale e il nome di ciascuna funzione esportata. Ciò consente all'utente di creare una DLL Windows standard utilizzando Visual Basic (versione 6 o precedente) a cui è possibile fare riferimento tramite un'istruzione "Declare".

C e C++

Microsoft Visual C++ (MSVC) fornisce diverse estensioni al C++ standard che consentono di specificare le funzioni come importate o esportate direttamente nel codice C++; questi sono stati adottati da altri compilatori Windows C e C++, incluse le versioni Windows di GCC . Queste estensioni usano l'attributo __declspecprima di una dichiarazione di funzione. Si noti che quando si accede alle funzioni C da C++, devono anche essere dichiarate come extern "C"nel codice C++, per informare il compilatore che deve essere utilizzato il collegamento C.

Oltre a specificare le funzioni importate o esportate tramite __declspecattributi, possono essere elencate nella sezione IMPORT o EXPORTS del DEFfile utilizzato dal progetto. Il DEFfile viene elaborato dal linker, piuttosto che dal compilatore, e quindi non è specifico del C++.

La compilazione della DLL produrrà sia DLLe LIBfile. Il LIBfile (libreria di importazione) viene utilizzato per collegarsi a una DLL in fase di compilazione; non è necessario per il collegamento in fase di esecuzione. A meno che la DLL non sia un server COM ( Component Object Model ), il DLLfile deve essere posizionato in una delle directory elencate nella variabile di ambiente PATH, nella directory di sistema predefinita o nella stessa directory del programma che lo utilizza. Le DLL del server COM vengono registrate utilizzando regsvr32.exe, che inserisce la posizione della DLL e il suo ID univoco globale ( GUID ) nel registro. I programmi possono quindi utilizzare la DLL cercando il relativo GUID nel Registro di sistema per trovarne la posizione o creare un'istanza dell'oggetto COM indirettamente utilizzando l'identificatore di classe e l'identificatore di interfaccia.

Esempi di programmazione

Utilizzo delle importazioni DLL

Gli esempi seguenti mostrano come utilizzare i collegamenti specifici della lingua per importare i simboli per il collegamento a una DLL in fase di compilazione.

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

Il file Example.lib deve essere incluso (presupponendo che venga generato Example.dll) nel progetto (opzione Aggiungi elemento esistente per il progetto!) prima del collegamento statico. Il file Example.lib viene generato automaticamente dal compilatore durante la compilazione della DLL. La mancata esecuzione dell'istruzione precedente causerebbe un errore di collegamento poiché il linker non saprebbe dove trovare la definizione di AddNumbers. Potrebbe anche essere necessario copiare la DLL Example.dll nella posizione in cui il file .exe verrà generato dal codice seguente. 

#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;
}

Utilizzo del collegamento esplicito in fase di esecuzione

Gli esempi seguenti mostrano come utilizzare le funzionalità di caricamento e collegamento in fase di esecuzione utilizzando i binding API di Windows specifici della lingua.

Si noti che tutti e quattro gli esempi sono vulnerabili agli attacchi di precaricamento delle DLL , poiché esempio.dll può essere risolto in una posizione non voluta dall'autore (la directory di lavoro corrente va prima delle posizioni della libreria di sistema) e quindi a una versione dannosa della libreria. Vedere il riferimento per la guida di Microsoft sul caricamento sicuro delle librerie: si dovrebbe usare SetDllDirectoryWin kernel32per rimuovere la ricerca nella directory corrente prima che vengano caricate le librerie.

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;
}

Pitone

L'associazione ctype di Python utilizzerà l'API POSIX sui sistemi 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)

Modello oggetto componente

Il Component Object Model (COM) definisce uno standard binario per ospitare l'implementazione di oggetti nei file DLL ed EXE. Fornisce meccanismi per individuare e versione di tali file, nonché una descrizione dell'interfaccia indipendente dalla lingua e leggibile dalla macchina. L'hosting di oggetti COM in una DLL è più leggero e consente loro di condividere risorse con il processo client. Ciò consente agli oggetti COM di implementare potenti back-end per semplici front-end GUI come Visual Basic e ASP. Possono anche essere programmati da linguaggi di scripting.

Dirottamento della DLL

A causa di una vulnerabilità comunemente nota come dirottamento DLL, spoofing DLL, precaricamento DLL o impianto binario, molti programmi caricheranno ed eseguiranno una DLL dannosa contenuta nella stessa cartella di un file di dati aperto da questi programmi. La vulnerabilità è stata scoperta da Georgi Guninski nel 2000. Nell'agosto 2010 ha ottenuto pubblicità in tutto il mondo dopo che ACROS Security l'ha riscoperta e molte centinaia di programmi sono stati trovati vulnerabili. I programmi eseguiti da posizioni non sicure, ad esempio cartelle scrivibili dall'utente come la directory Download o Temp , sono quasi sempre soggetti a questa vulnerabilità.

Guarda anche

Riferimenti

  • Hart, Johnson. Programmazione di sistema Windows Terza edizione . Addison-Wesley, 2005. ISBN  0-321-25619-0 .
  • Rettore, Brent et al. Programmazione Win32 . Addison-Wesley Developers Press, 1997. ISBN  0-201-63492-9 .

link esterno