Sei sulla pagina 1di 5

File di libreria di Microsoft Windows

Il sistema operativo Microsoft Windows supporta una forma di librerie condivise note come "librerie a
collegamento dinamico", che sono librerie di codice che possono essere utilizzate da più processi mentre solo
una copia viene caricata in memoria.
Questo articolo fornisce una panoramica delle librerie di base incluse in ogni installazione moderna di
Windows, in cima alle quali viene creata la maggior parte delle applicazioni Windows.

Contenuti
1 Componenti interni
1.1 HAL.DLL
1.2 NTDLL.DLL
2 API Win32
2.1 KERNEL32.DLL
2.2 GDI32.DLL
2.3 USER32.DLL
2.4 COMCTL32.DLL
2.5 COMDLG32.DLL
2.6 WS2_32.DLL
2.7 ADVAPI32.DLL
2.8 NETAPI32.DLL
2.9 OLE32.DLL
3 Altre API
3.1 SHSCRAP.DLL
3.2 WINMM.DLL
3.3 IMM32.DLL
4 Librerie runtime
4.1 MSVCRT.DLL, MSVCP * .DLL e CRTDLL.DLL
4.2 Altre librerie runtime
4.3 Librerie .NET Framework
5 Vedi anche
6 Riferimenti
7 Collegamenti esterni

Componenti interni
HAL.DLL è un file di libreria in modalità kernel e non può essere utilizzato da alcun programma in modalità
utente. NTDLL.DLL viene utilizzato solo da alcuni programmi, ma è una dipendenza della maggior parte
delle librerie Win32 utilizzate dai programmi.

HAL.DLL
Windows Hardware Abstraction Layer (HAL) è implementato in hal.dll. L'HAL implementa una serie di
funzioni che vengono implementate in modi diversi da diverse piattaforme hardware, che in questo contesto
si riferiscono principalmente al chipset. Gli altri componenti del sistema operativo possono quindi chiamare
queste funzioni allo stesso modo su tutte le piattaforme, indipendentemente dall'effettiva implementazione.
Ad esempio, la risposta a un interrupt è molto diversa su una macchina con un APIC (Advanced
Programmable Interrupt Controller) rispetto a una senza. L'HAL fornisce una singola funzione per questo
scopo che funziona con tutti i tipi di interrupt di vari chipset, in modo che gli altri componenti non debbano
preoccuparsi delle differenze.
L'HAL viene caricato nello spazio degli indirizzi del kernel e viene eseguito in modalità kernel, quindi le
routine nell'HAL non possono essere chiamate direttamente dalle applicazioni e nessuna API in modalità
utente corrisponde direttamente alle routine HAL. Al contrario, l'HAL fornisce servizi principalmente
all'esecutivo e al kernel di Windows e ai driver di dispositivo in modalità kernel. Sebbene i driver per la
maggior parte dell'hardware siano contenuti in altri file, comunemente di tipo .sys, alcuni driver principali
vengono compilati in hal.dll.
I driver di dispositivo in modalità kernel per dispositivi su bus come PCI e PCI Express chiamano
direttamente le routine nell'HAL per accedere alle porte di I / O e ai registri dei loro dispositivi. I driver
utilizzano routine HAL perché piattaforme diverse possono richiedere diverse implementazioni di queste
operazioni. L'HAL implementa le operazioni in modo appropriato per ciascuna piattaforma, quindi lo stesso
file eseguibile del driver può essere utilizzato su tutte le piattaforme utilizzando la stessa architettura della
CPU e il file sorgente del driver può essere trasferibile su tutte le architetture.

Sui sistemi x86, sono presenti diversi file HAL sul supporto di installazione. La procedura di installazione di
Windows determina quali sono appropriate per la piattaforma corrente e le copia sul disco rigido,
rinominandolo in hal.dll se necessario. Tra i criteri per questa selezione vi sono: la presenza di un BIOS
compatibile con ACPI, la presenza di un APIC e se sono presenti e abilitati più processori.
(I core multipli di una CPU multi-core, e anche i "processori logici" implementati da una CPU
hyperthreading, contano tutti come "processori" per questo scopo.)
Sulle piattaforme x86-64 e Itanium c'è solo un possibile hal.dll per ogni architettura della CPU.

NTDLL.DLL
NTDLL.DLL esporta l'API nativo di Windows. L'API nativa è l'interfaccia utilizzata dai componenti in
modalità utente del sistema operativo che devono essere eseguiti senza il supporto di Win32 o di altri
sottosistemi API.
La maggior parte di questa API è implementata in NTDLL.DLL e sul bordo superiore di ntoskrnl.exe (e delle
sue varianti) e la maggior parte dei simboli esportati all'interno di queste librerie ha il prefisso Nt, ad
esempio NtDisplayString. Le API native vengono utilizzate anche per implementare molte delle "API del
kernel" o "API di base" esportate da KERNEL32.DLL.
La maggior parte delle applicazioni Windows non chiama direttamente NTDLL.DLL.
Si dice che le applicazioni collegate direttamente a questa libreria utilizzino il sottosistema nativo; il motivo
principale della loro esistenza è eseguire attività che devono essere eseguite all'inizio della sequenza di avvio
del sistema prima che il sottosistema Win32 sia disponibile. Un esempio ovvio ma importante è la creazione
del processo del sottosistema Win32, csrss.exe.
Prima che esista il processo csrss.exe, non è possibile creare processi Win32, pertanto il processo che lo Si
dice che le applicazioni collegate direttamente a questa libreria utilizzino il sottosistema nativo; il motivo
principale della loro esistenza è eseguire attività che devono essere eseguite all'inizio della sequenza di avvio
del sistema prima che il sottosistema Win32 sia disponibile.
Un esempio ovvio ma importante è la creazione del processo del sottosistema Win32, csrss.exe.
Prima che esista il processo csrss.exe, non è possibile creare processi Win32, pertanto il processo che lo crea
(Smss.exe, il "gestore sessioni") deve utilizzare il sottosistema nativo. csrss.exe stesso è un'applicazione di
questo tipo.
Nonostante abbiano un'estensione di file ".exe", le applicazioni native non possono essere eseguite
dall'utente (o qualsiasi programma in Win32 o altri sottosistemi).
Un esempio è il binario autochk.exe che esegue chkdsk durante l'inizializzazione del sistema "Blue Screen".
Altri esempi importanti sono i servizi che implementano i vari sottosistemi, come csrss.exe.
A differenza delle applicazioni Win32, le applicazioni native creano un'istanza all'interno del codice runtime
del kernel (ntoskrnl.exe) e quindi devono avere un punto di ingresso diverso (NtProcessStartup, piuttosto che
(w) (Win) MainCRTStartup come si trova in un'applicazione Win32), ottenere il loro comando -line
argomenti tramite un puntatore a una struttura in memoria, gestire la propria memoria utilizzando l'API di
heap Rtl, (che le API di heap Win32 sono solo wrapper - nessuna differenza reale lì) e restituire l'esecuzione
con una chiamata a NtTerminateProcess (al contrario a ExitProcess).
Una libreria comune collegata alle applicazioni native è nt.lib, che contiene il codice di avvio per le
applicazioni native, simile a come il runtime C fornisce il codice di avvio per le app Win32.
Sebbene la maggior parte dell'API non sia documentata, è possibile creare applicazioni native utilizzando
Windows Driver Development Kit; molti software antivirus e altri fornitori di software di utilità hanno
incorporato applicazioni native nei loro prodotti, di solito per eseguire alcune attività all'avvio che non
possono essere eseguite nello spazio utente.
API Win32

KERNEL32.DLL
KERNEL32.DLL espone alle applicazioni la maggior parte delle API di base Win32, come la gestione della
memoria, le operazioni di input / output (I / O), la creazione di processi e thread e le funzioni di
sincronizzazione. Molti di questi vengono implementati all'interno di KERNEL32.DLL chiamando le
funzioni corrispondenti nell'API nativa, esposte da NTDLL.DLL.

GDI32.LLD
GDI32.DLL esporta le funzioni GDI (Graphics Device Interface) che eseguono funzioni di disegno primitive
per l'output su schermi video e stampanti. Viene utilizzato, ad esempio, nella versione XP di Paint. Le
applicazioni chiamano le funzioni GDI direttamente per eseguire il disegno di basso livello (linea, rettangolo,
ellisse), output di testo, gestione dei caratteri e funzioni simili.
Inizialmente, GDI supportava schede video EGA / VGA a 16 e 256 colori e stampanti monocromatiche. La
funzionalità si è ampliata nel corso degli anni e ora include il supporto per cose come i caratteri TrueType, i
canali alfa e più monitor.

USER32.DLL
USER32.DLL implementa il componente USER di Windows che crea e manipola gli elementi standard
dell'interfaccia utente di Windows, come desktop, finestre e menu.
Consente quindi ai programmi di implementare un'interfaccia utente grafica (GUI) che corrisponda
all'aspetto di Windows.
I programmi chiamano funzioni da Windows USER per eseguire operazioni come la creazione e la gestione
di finestre, la ricezione di messaggi di finestra (che sono principalmente input dell'utente come eventi del
mouse e della tastiera, ma anche notifiche dal sistema operativo), la visualizzazione di testo in una finestra e
la visualizzazione di messaggi scatole.
Molte delle funzioni in USER32.DLL chiamano le funzioni GDI esportate da GDI32.DLL per eseguire il
rendering effettivo dei vari elementi dell'interfaccia utente.
Alcuni tipi di programmi chiameranno anche le funzioni GDI direttamente per eseguire operazioni di
disegno di livello inferiore all'interno di una finestra creata in precedenza tramite le funzioni USER32.

COMCTL32.DLL
COMCTL32.DLL implementa un'ampia varietà di controlli Windows standard, come le finestre di dialogo
Apri file, Salva e Salva con nome, barre di avanzamento e visualizzazioni elenco.
Chiama funzioni sia da USER32.DLL che da GDI32.DLL per creare e gestire le finestre per questi elementi
dell'interfaccia utente, inserire vari elementi grafici al loro interno e raccogliere l'input dell'utente.

COMDLG32.DLL
COMDLG32.DLL, la libreria di finestre di dialogo comuni, implementa un'ampia varietà di finestre di
dialogo di Windows destinate a eseguire ciò che Microsoft considera "attività comuni delle applicazioni".
A partire dal rilascio di Windows Vista, Microsoft considera le finestre di dialogo "Apri" e "Salva con nome"
fornite da questa libreria come deprecate e sostituite dalla "API di dialogo elemento comune".

WS2_32.DLL
WS2_32.DLL implementa l'API Winsock, che fornisce funzioni di rete TCP / IP e fornisce compatibilità
parziale e interrotta con altre API di rete. wsock.dll e wsock32.dll sono versioni precedenti per la
compatibilità Win3.11 e Win95.

ADVAPI32.DLL
ADVAPI32.DLL fornisce chiamate di sicurezza e funzioni per la manipolazione del registro di Windows.
NETAPI32.DLL
NETAPI32.DLL fornisce funzioni per l'interrogazione e la gestione delle interfacce di rete.

OLE32.DLL
OLE32.DLL fornisce il Component Object Model, nonché Object Linking and Embedding.

Altre API

SHSCRAP.DLL
SHSCRAP.DLL fa parte del meccanismo OLE (Object Linking and Embedding).
Implementa il supporto per i file scrap della shell, che vengono creati automaticamente quando si trascina
il contenuto selezionato da un'applicazione compatibile con OLE in una finestra di Esplora risorse o in un
desktop, ma è anche possibile utilizzare Object Packager per crearli.
Possono quindi essere trascinati in un'altra applicazione compatibile con OLE.
Questa funzionalità è stata rimossa da Windows Vista (e quindi dalle versioni successive) per migliorare la
sicurezza e liberare il sistema operativo dalle funzionalità generalmente inutilizzate.
I file di scarto (.shs) sono stati utilizzati dai virus perché possono contenere un'ampia varietà di file (incluso
il codice eseguibile) e l'estensione del file non viene visualizzata anche quando "Nascondi le estensioni dei
file dai tipi di file conosciuti" è disabilitato.
La funzionalità può essere ripristinata copiando le voci di registro e la DLL da un sistema Windows XP.

WINMM.DLL
WINMM.DLL fornisce l'accesso all'API audio WinMM originale.

IMM32.DLL
IMM32 è responsabile del richiamo e dell'interazione con Input Method Editor.

Librerie runtime
MSVCRT.DLL, MSVCP * .DLL e CRTDLL.DLL
MSVCRT.DLL è la libreria standard C per il compilatore Visual C ++ (MSVC) dalla versione 4.2 alla 6.0.
Fornisce programmi compilati da queste versioni di MSVC con la maggior parte delle funzioni di libreria C
standard.
Questi includono la manipolazione delle stringhe, l'allocazione della memoria, le chiamate di input / output
in stile C e altri. MSVCP * .DLL è la libreria C ++ corrispondente.
È stato fornito con le versioni di Windows a partire da Windows 95 OSR2.5 per essere utilizzato da altri
componenti di Windows; invece le versioni precedenti erano fornite con la libreria CRTDLL.DLL.
Nelle versioni precedenti di Windows, i programmi che si collegavano a MSVCRT.DLL dovevano installare
una copia compatibile nella cartella System32, ma questo ha contribuito a DLL Hell perché molti installatori
non sono riusciti a verificare la versione della libreria rispetto alla versione installata prima di sostituirla.
Le versioni di MSVC precedenti alla 4.0 e dalla 7.0 alla 13.0 utilizzavano DLL con nomi diversi per
ciascuna versione (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL e così via).
Le applicazioni sono necessarie per installare la versione appropriata e Microsoft offre pacchetti
ridistribuibili di Visual C ++ per questo scopo, sebbene Windows in genere venga fornito con una
versione già installata.
Con la versione 14.0, la maggior parte del runtime C / C ++ è stata spostata in una nuova DLL,
UCRTBASE.DLL. Tuttavia, i programmi C / C ++ che utilizzano UCRTBASE.DLL sono costretti a
collegarsi a un'altra nuova DLL, il VCRuntime, il cui nome continua a cambiare con ogni versione di
MSVC (ad esempio VCRUNTIME140.DLL).
Il codice sorgente per le librerie di runtime è incluso in Visual C ++ per riferimento e debug (ad esempio in
C: \ Programmi \ Microsoft Visual Studio 11.0 \ VC \ crt \ src). Ora il codice è disponibile su GitHub.
Questa libreria runtime viene utilizzata da programmi scritti in Visual C ++ e alcuni altri compilatori (ad
esempio MinGW). Alcuni compilatori hanno le proprie librerie di runtime.

Altre librerie di runtime


ATL * .DLL - Libreria di modelli attiva
MFC * .DLL - Microsoft Foundation Classes
MSVBVM60.DLL - Macchina virtuale di Visual Basic 6.0 (i programmi Visual Basic.NET richiedono
invece .NET Framework)
VCOMP * .DLL - Runtime di Microsoft OpenMP
VCRUNTIME * .DLL - Microsoft VCRuntime, per MSVC 14.0+
MSVCIRT.DLL - Libreria Microsoft C ++, contiene le classi C ++ deprecate da <iostream.h> (notare
l'estensione del file) per MS C 9 e 10 (MSVC 2.x, 4.x) (all'epoca, la bozza della libreria standard C ++ è
stato integrato in MSVCRT.DLL. È stato suddiviso con il rilascio di Visual C ++ 5.0)

Librerie .NET Framework


I programmi scritti in C #, Visual Basic.NET, C ++ / CLI e altri linguaggi .NET richiedono .NET
Framework. Ha molte librerie (una di queste è mscorlib.dll - Multilanguage Standard Common Object
Runtime Library, precedentemente Microsoft Common Object Runtime Library) e i cosiddetti assembly
(ad esempio System.Windows.Forms.dll).

Potrebbero piacerti anche