Come funzionano le librerie di importazione e perché MinGW non ne ha bisogno?

Question

An In-Depth Look into the Win32 Portable Executable File Format

Spiega che il linker ha bisogno di una libreria di importazione perché il compilatore non può distinguere tra chiamate di funzioni normali e chiamate di funzioni API. Ma dicono anche che __declspec (dllimport) specifica una chiamata di funzione per essere una API-Call in modo che il linker rimandi a __imp_[function-name]. Ma con il compilatore dovrebbe sapere che questa è una chiamata a una funzione API.

Perché il linker necessita ancora di una libreria di importazione? Il compilatore potrebbe contrassegnare questo simbolo come importato anteponendo __imp_ al nome della funzione e potrebbe effettuare una chiamata a un puntatore a funzione (che è ancora un simbolo non risolto) e il linker potrebbe sostituire questo simbolo (poiché vede che questa è una chiamata API) con l'indirizzo della voce IAT.

E perché il minGW-linker utilizza "MinGW-DLL" direttamente ma il linker di Visual-Studio necessita di una libreria di importazione?

Mentre ho letto il post, sono state sollevate anche altre domande. In che modo il "dlltool (o linker)" (a seconda di quale crea la libreria di importazione) conosce la posizione di una voce IAT prima che sia stato effettuato il collegamento con l'eseguibile finale? Ho pensato che le voci IAT sarebbero state costruite in fase di collegamento con l'eseguibile finale. Il post diceva che ogni Call API ha una posizione fissa nella tabella IAT, senza preoccuparsi di quante DLL saranno collegate. Non riesco a immaginare come possa essere raggiunto.

Answer 1

È possibile eseguire il collegamento alla DLL senza una libreria di importazione come dimostra chiaramente MinGW. Quindi la domanda è perché MSVC ha deciso di omettere questa funzione.

Le ragioni sono principalmente storiche.

All'epoca, nel 1983, quando Windows veniva creato e le DLL erano progettate, c'erano molti toolchain (compilatori, linker) di diversi fornitori. Uscire chiedendo ai produttori di implementare il supporto per il collegamento di "DLL" per un sistema operativo di minoranza non era chiaramente un'opzione.

Quindi hanno preso la decisione di scrivere uno strumento per generare una libreria e il loro cane potrebbe collegarsi anche se un linker non aveva assolutamente idea delle DLL.

Oltre alle librerie di importazione offrono alcune funzionalità che erano vitali 3 decenni fa ma che sono ormai obsolete. La prima è la possibilità di importare un simbolo da ordinale - cioè la DLL ha un'opzione per non offrire alcun nome solo a un elenco di indirizzi; l'ordinale è un indice in questa lista. Fatto quando la quantità di RAM è stata gravemente limitata.

Secondo è il supporto per diversi schemi di manomissione del nome. Anche in C esiste uno schema di manomissione del nome, ad esempio FooBar può diventare _FooBar @ 4 (dipende dalla piattaforma e dalla convenzione di chiamata). Era perfettamente logico che una DLL esportasse "FooBar" su ogni piattaforma supportata per coerenza (e semplifica la vita dell'utente GetProcAddress()). La libreria di importazione implementa il mapping da _FooBar @ 4 a FooBar.

Questo è basato sul blog (1, 2) di Raimond Chen, l'uomo che è stato coinvolto nello sviluppo di Windows fin dall'inizio.