error - dll-files.com client
Diferencia entre el enlace dinámico de tiempo de carga y el enlace dinámico de tiempo de ejecución (4)
Aiden Bell cubrió los fundamentos, pero agregaré:
La vinculación dinámica del tiempo de carga generalmente se logra al vincular estáticamente su aplicación a un archivo .lib o .a que contiene el código para establecer automáticamente los enlaces de tiempo de ejecución a los símbolos que se encuentran en los archivos .dll o .so al inicio del programa. Por lo general, se trata de una funcionalidad fija (es decir, la biblioteca en tiempo de ejecución de C, etc.) y le permite a su programa obtener los beneficios de las correcciones de errores en las bibliotecas mientras mantiene el tamaño del archivo ejecutable pequeño (factorizando el código común en una sola biblioteca).
El enlace en tiempo de ejecución se utiliza para una funcionalidad más dinámica, como la carga de complementos. Como dijo Aiden, usa LoadLibrary() o el equivalente para conectar activamente módulos a su programa en tiempo de ejecución, tal vez interrogando un directorio que contiene DLL de complementos, cargando cada uno de ellos y hablando con un API de complementos de cosecha propia. Al hacerlo, su programa puede cargar módulos que ni siquiera existían cuando su aplicación fue compilada / vinculada, y por lo tanto puede crecer orgánicamente después de la implementación.
Fundamentalmente, ambos métodos terminan invocando la API LoadLibrary() , pero usando un conjunto fijo de símbolos y bibliotecas en el primer caso y un conjunto más dinámico en el segundo.
Al cargar programas en la memoria, ¿cuál es la diferencia entre el enlace dinámico de tiempo de carga y el enlace dinámico de tiempo de ejecución?
En el tiempo de carga, el archivo ejecutable de enlace está vinculado a la biblioteca DLL, mientras que en el tiempo de ejecución el enlace dinámico no se ha vinculado ningún archivo ejecutable ni ningún archivo DLL.
El enlace dinámico en tiempo de ejecución es preferible cuando el rendimiento de inicio de la aplicación es importante
Ha pasado mucho tiempo desde que se hizo la pregunta. Y las respuestas de Aiden y Drew cubrieron la mayor parte de la esencia. Solo quiero agregar algunas cosas desde la perspectiva de un programador.
Si utiliza el enlace dinámico de tiempo de carga, debemos vincularlo al archivo LIB. Y luego en el código, podemos llamar al método tan explícitamente como de costumbre. (Consulte Uso del enlace dinámico de tiempo de carga para el ejemplo de código)
Si utiliza el enlace dinámico en tiempo de ejecución, debe administrar la carga / liberación de DLL y la búsqueda de funciones usted mismo. (Consulte Uso del enlace dinámico en tiempo de ejecución para el ejemplo de código)
Para elegir entre las 2 opciones, marque Determinar qué método de enlace usar .
Entonces, creo que el enlace dinámico de tiempo de carga es solo otra forma de ahorrar el esfuerzo de los programadores. Pero viene al precio de alguna extensibilidad. Solo puede usar la DLL correspondiente a los archivos LIB que usa como biblioteca de importación.
Fundamentalmente, ambos enfoques de enlace utilizan la API LoadLibrary () en la plataforma Windows.
la vinculación en tiempo de carga es cuando los símbolos en la biblioteca, a los que hace referencia el ejecutable (u otra biblioteca) se manejan cuando el ejecutable / biblioteca se carga en la memoria, mediante el sistema operativo.
La vinculación en tiempo de ejecución es cuando utiliza una API proporcionada por el sistema operativo o a través de una biblioteca para cargar una DLL o DSO cuando la necesita, y luego realiza la resolución del símbolo.
Sé más sobre los DSO de Linux que sobre los DLL de Windows, pero el principio debería ser el mismo. Las bibliotecas .NET pueden diferir.
En Linux, las arquitecturas de plugin se hacen de esta manera. Su programa utilizará el enlace de tiempo de ejecución para cargar una biblioteca y llamar a algunas funciones. Entonces tal vez descargarlo. También permite que se carguen múltiples bibliotecas con los mismos símbolos exportados sin conflicto. Creo que los DLL funcionarán de la misma manera.
Los ejecutables tienen "espacios en blanco" en sus tablas de símbolos que necesitan ser llenados por alguna biblioteca. Estos espacios en blanco generalmente se completan en tiempo de carga o tiempo de compilación. Puede negar la necesidad de "espacios en blanco" en la tabla de símbolos utilizando el enlace en tiempo de ejecución.
Otro escenario en el que la vinculación en tiempo de ejecución es útil es para la depuración de bibliotecas, o la selección de múltiples bibliotecas compatibles con ABI / API en tiempo de ejecución. A menudo tengo una biblioteca, digo "foo" y una llamada "foo_unstable" y tengo una aplicación de prueba que cambia entre 2 y hace algunas pruebas.
Bajo Linux, para ver a qué bibliotecas se vincula un ejecutable en el momento de la carga, ejecuta el comando ldd y obtiene resultados como (en / bin / ls):
linux-vdso.so.1 => (0x00007fff139ff000)
librt.so.1 => /lib64/librt.so.1 (0x0000003c4f200000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003c4fa00000)
libcap.so.2 => /lib64/libcap.so.2 (0x0000003c53a00000)
libacl.so.1 => /lib64/libacl.so.1 (0x0000003c58e0000
El sistema operativo intentará cargar las bibliotecas (los archivos .so) en tiempo de carga. Puede que ya tenga la biblioteca en memoria.