Pourquoi avons-nous encore besoin d'un fichier stub .lib quand nous avons l'implémentation réelle .dll?

Question

Je me demande pourquoi les linkers ne peuvent pas faire leur travail simplement en consultant les informations dans les fichiers .dll réels qui ont obtenu le code d'implémentation réel? Je veux dire pourquoi les linkers ont toujours besoin de fichiers .lib pour faire des liens implicites?

ne sont pas les tables d'exportation et d'adresse relative assez pour une telle liaison?

est-il de toute façon par lequel on peut faire une liaison implicite en utilisant seulement le .dll sans les fichiers .lib stub/proxy?

Je pensais que le chargeur exécutable de Windows ferait simplement des appels LoadLibrary/LoadLibraryEx au nom du programme (d'où le nom de lien implicite) qui est la différence principale à la liaison explicite. si cela est vrai alors le faire explicitement sans .lib devrait indiquer que c'est faisable sans implicitement, n'est-ce pas? ou je dis juste le non-sens?

toute aide est appréciée, merci beaucoup :)

geeko

Answer 1

Je peux penser à quelques raisons. L'utilisation de fichiers .lib signifie que vous pouvez créer une version différente d'une DLL que celle de votre système, à condition que le SDK correct soit installé.

Compilateurs & Les lieurs doivent prendre en charge les compilations multi plates-formes - Vous pouvez créer une cible 64 bits sur une plate-forme 32 bits et inversement et ne pas avoir la DLL d'architecture correcte.

Les fichiers .lib vous permettent de "masquer" certaines parties de votre implémentation - vous pourriez avoir des exportations privées qui n'apparaissent pas dans le fichier .lib mais qui sont détectables via GetProcAddress. Vous pouvez également effectuer des exportations ordinales, auquel cas ils n'ont pas de nom convivial exporté, mais un nom convivial dans le fichier .lib. Les DLL natives n'ont pas de noms forts, il est donc possible de choisir la mauvaise version de la DLL.

Et le plus important, cette technologie a été conçue dans les années 1980. Si elle était conçue aujourd'hui, elle serait probablement plus proche de ce que vous décrivez - par exemple, .NET, vous avez juste besoin de référencer l'assemblage cible et vous avez tout ce dont vous avez besoin pour l'utiliser. Je ne connais aucun moyen de faire une liaison implicite uniquement avec la DLL - Une recherche rapide a révélé plusieurs outils, mais je n'en ai utilisé aucun.

Dans ce cas, je créerais un fichier source séparé avec les fonctions que vous devez utiliser, et charger dynamiquement la DLL et les lier si nécessaire. Par exemple:

// using global variables and no-error handling for brevity. 

HINSTANCE theDll = NULL; 
typedef void (__stdcall * FooPtr)(); 
FooPtr pfnFoo = NULL; 
INIT_ONCE initOnce; 

BOOL CALLBACK BindDLL(PINIT_ONCE initOnce, PVOID parameter, PVOID context) 
{ 
    theDll = LoadLibrary(); 
    pfnfoo = GetProcAddress(dll, "Foo"); 

    return TRUE; 
} 

// Export for foo 
void Foo() 
{ 
    // Use one-time init for thread-safe lazy initialization 
    InitOnceExecuteOnce(initOnce, BinDll, NULL, NULL) 
    pfnFoo(); 
}