¿Por qué seguimos necesitando un archivo de resguardo.lib cuando tenemos la implementación real de.dll?

linker implicit

Question

Me pregunto por qué los enlazadores no pueden hacer su trabajo simplemente consultando la información en los archivos .dll reales que obtuvieron el código de implementación real. Quiero decir, ¿por qué los enlazadores todavía necesitan archivos .lib para hacer enlaces implícitos?

¿No son las tablas de exportación y de direcciones relativas suficientes para dicha vinculación?

¿Hay alguna forma por la cual uno pueda hacer enlaces implícitos usando solo el .dll sin los archivos .lib stub / proxy?

Pensé que el cargador ejecutable de Windows simplemente haría llamadas a LoadLibrary / LoadLibraryEx en nombre del programa (de ahí el nombre de enlace implícito), que es la principal diferencia para el enlace explícito. si eso es cierto, entonces hacerlo explícitamente sin .lib debería indicar que es factible sin ello implícitamente, ¿verdad? o solo estoy diciendo que no tiene sentido?

Cualquier ayuda es apreciada, muchas gracias :)

geeko

Answer 1

Puedo pensar en algunas razones.

• El uso de archivos .lib significa que puede compilar para una versión diferente de una DLL de la que tiene en su sistema, siempre que tenga instalado el SDK correcto.
• Los compiladores y enlazadores deben admitir compilaciones multiplataforma: es posible que esté compilando para un destino de 64 bits en una plataforma de 32 bits y viceversa, y no tenga presente la DLL de arquitectura correcta.
• Los archivos .lib le permiten "ocultar" ciertas partes de su implementación; es posible que tenga exportaciones privadas que no se muestran en .lib pero que se pueden detectar a través de GetProcAddress. También puede realizar exportaciones ordinales, en cuyo caso no tienen un nombre descriptivo, pero tendrían un nombre descriptivo en la .lib.
• Las DLL nativas no tienen nombres fuertes, por lo que es posible que se recoja la versión incorrecta de la DLL.
• Y lo más importante, esta tecnología fue diseñada en la década de 1980. Si se diseñara hoy, probablemente estaría más cerca de lo que describe; por ejemplo, .NET, solo necesita hacer referencia al ensamblaje de destino y tiene todo lo que necesita para usarlo.

No conozco ninguna forma de hacer enlaces implícitos únicamente con la DLL. Una búsqueda rápida reveló varias herramientas, pero no he usado ninguna de ellas.

En este caso, crearía un archivo fuente separado con las funciones que necesita usar, y cargaría dinámicamente la DLL y las enlazaría según fuera necesario. Por ejemplo:

// 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();
}