Archivos DLL y LIB: ¿qué y por qué?


214

Sé muy poco acerca de las DLL y las LIB además de que contienen el código vital requerido para que un programa se ejecute correctamente: las bibliotecas. Pero, ¿por qué los compiladores los generan? ¿No sería más fácil incluir todo el código en un solo ejecutable? ¿Y cuál es la diferencia entre DLL y LIB?


Respuestas:


299

Hay bibliotecas estáticas (LIB) y bibliotecas dinámicas (DLL), pero tenga en cuenta que los archivos .LIB pueden ser bibliotecas estáticas (que contienen archivos de objetos) o bibliotecas de importación (que contienen símbolos para permitir que el vinculador se vincule a una DLL).

Las bibliotecas se usan porque puede tener el código que desea usar en muchos programas. Por ejemplo, si escribe una función que cuenta el número de caracteres en una cadena, esa función será útil en muchos programas. Una vez que haga que la función funcione correctamente, no querrá tener que volver a compilar el código cada vez que la use, por lo que coloca el código ejecutable para esa función en una biblioteca, y el enlazador puede extraer e insertar el código compilado en su programa . Las bibliotecas estáticas a veces se denominan 'archivos' por este motivo.

Las bibliotecas dinámicas llevan esto un paso más allá. Parece un desperdicio tener múltiples copias de las funciones de la biblioteca ocupando espacio en cada uno de los programas. ¿Por qué no pueden todos compartir una copia de la función? Para eso están las bibliotecas dinámicas. En lugar de compilar el código de la biblioteca en su programa cuando se compila, se puede ejecutar asignándolo a su programa a medida que se carga en la memoria. Varios programas que se ejecutan al mismo tiempo y usan las mismas funciones pueden compartir una copia, ahorrando memoria. De hecho, puede cargar bibliotecas dinámicas solo según sea necesario, dependiendo de la ruta a través de su código. No tiene sentido que las rutinas de la impresora tomen memoria si no está imprimiendo. Por otro lado, esto significa que debe tener una copia de la biblioteca dinámica instalada en cada máquina en la que se ejecuta su programa.

Como ejemplo, casi todos los programas escritos en 'C' necesitarán funciones de una biblioteca llamada 'biblioteca de tiempo de ejecución C, aunque pocos programas necesitarán todas las funciones. El tiempo de ejecución C viene en versiones estáticas y dinámicas, por lo que puede determinar qué versión usa su programa dependiendo de las necesidades particulares.


81
Resulta que los .LIBarchivos pueden ser bibliotecas estáticas (que contienen archivos de objetos) o bibliotecas de importación (que contienen símbolos para permitir que el vinculador se vincule a una DLL). Me pregunto por qué es así.
Lumi

2
¡buena explicación! El código se comparte y los datos (por defecto) no se comparten entre las aplicaciones que consumen un Dll.
mox

44
@ Lumi: Buen punto. En términos de DLL, tenemos dos tipos de enlaces. Enlace implícito , cuando tenemos un .libarchivo proporcionado por el creador de DLL junto con los encabezados apropiados; esto .libes simplemente un descriptor de la DLL de destino, contiene direcciones, puntos de entrada, etc. pero no tiene código. Esto .libdebe pasarse al vinculador. El segundo es el enlace explícito cuando usamos la DLL cargándola manualmente con la LoadLibraryfunción. En este tipo no necesitamos ese .libarchivo, pero debemos poner un poco de esfuerzo para encontrar exportaciones de DLL, sus direcciones y llamar a estas funciones a través de punteros.
itachi

37

Otro aspecto es la seguridad (ofuscación). Una vez que se extrae un fragmento de código de la aplicación principal y se coloca en una Biblioteca de Enlace Dinámico "separada", es más fácil atacar, analizar (aplicar ingeniería inversa) al código, ya que se ha aislado. Cuando el mismo fragmento de código se guarda en una biblioteca LIB, forma parte de la aplicación de destino compilada (vinculada), y esto es más difícil de aislar (diferenciar) ese fragmento de código del resto de los binarios de destino.


El aspecto de seguridad era nuevo para mí. ¿El razonamiento anterior es válido en el caso de una aplicación C # que llama a un dll C ++ no administrado nativo?
Martin

1
Pero el LIB también está aislado, ¿no? Entonces un atacante podría simplemente analizar la LIB. ¿O es un escenario común que el LIB no sea accesible al público?
Nick Russler

8
el LIB también está "aislado", en lo que respecta al proceso del compilador, pero una vez que el enlazador reúne las partes, el LIB forma parte del EXE y no se puede diferenciar de su propio código.
mox

17

Una razón importante para crear una DLL / LIB en lugar de simplemente compilar el código en un ejecutable es la reutilización y la reubicación. La aplicación promedio de Java o .NET (por ejemplo) probablemente usará varias bibliotecas de terceros (o framework). Es mucho más fácil y rápido compilar en una biblioteca precompilada, en lugar de tener que compilar todo el código de terceros en su aplicación. Compilar su código en bibliotecas también fomenta las buenas prácticas de diseño, por ejemplo, diseñar sus clases para usarlas en diferentes tipos de aplicaciones.


7

Una DLL es una biblioteca de funciones que se comparten entre otros programas ejecutables. Simplemente busque en su directorio windows / system32 y encontrará docenas de ellos. Cuando su programa crea una DLL, normalmente también crea un archivo lib para que la aplicación * .exe pueda resolver los símbolos que se declaran en la DLL.

Un .lib es una biblioteca de funciones que están vinculadas estáticamente a un programa; otros programas NO las comparten. Cada programa que se vincula con un archivo * .lib tiene todo el código en ese archivo. Si tiene dos programas, A.exe y B.exe, que se vinculan con C.lib, cada A y B contendrán el código en C.lib.

La forma de crear archivos DLL y bibliotecas depende del compilador que utilice. Cada compilador lo hace de manera diferente.


4

Otra diferencia radica en el rendimiento.

Como el .exe (s) carga el DLL en tiempo de ejecución, el .exe (s) y el DLL funcionan con el concepto de memoria compartida y, por lo tanto, el rendimiento es bajo en relación con la vinculación estática.

Por otro lado, un .lib es un código que está vinculado estáticamente en tiempo de compilación en cada proceso que lo solicita. Por lo tanto, los archivos .exe tendrán memoria única, lo que aumentará el rendimiento del proceso.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.