Al cargar programas en la memoria, ¿cuál es la diferencia entre el enlace dinámico en tiempo de carga y el enlace dinámico en tiempo de ejecución?Diferencia entre el enlace dinámico en tiempo de carga y el enlace dinámico en tiempo de ejecución
La vinculación en tiempo de carga es cuando el sistema operativo maneja los símbolos en la biblioteca, a los que hace referencia el archivo ejecutable (u otra biblioteca) cuando el archivo ejecutable/biblioteca se carga en la memoria.
La vinculación en tiempo de ejecución es cuando utiliza una API proporcionada por el sistema operativo oa través de una biblioteca para cargar un archivo DLL o DSO cuando lo necesita y luego ejecuta la resolución del símbolo.
Conozco más acerca de los DSO de Linux que de las DLL de Windows, pero el principio debería ser el mismo. Las bibliotecas .NET pueden diferir.
En Linux, las arquitecturas de plugins se hacen de esta manera. Su programa usará enlaces de tiempo de ejecución para cargar una biblioteca y llamar a algunas funciones. Entonces tal vez descargarlo. También permite que múltiples bibliotecas con los mismos símbolos exportados se carguen sin chocar. Creo que las DLL funcionarán de la misma manera.
Los archivos ejecutables tienen "espacios en blanco" en sus tablas de símbolos que deben rellenarse en 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 mediante el uso de enlaces de tiempo de ejecución.
Otro escenario donde el enlace de tiempo de ejecución es útil es para depurar bibliotecas, o seleccionar de múltiples bibliotecas compatibles con ABI/API en tiempo de ejecución. A menudo tengo una biblioteca, digo "foo" y otra llamada "foo_unstable" y tengo una aplicación de prueba que cambia entre los 2 y realiza algunas pruebas.
bajo Linux, para ver lo que las bibliotecas una enlaces ejecutables para a carga en tiempo de ejecutar el comando ldd y obtener la salida 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á cargue las bibliotecas (los archivos .so) en tiempo de carga. Es posible que ya tenga la biblioteca en la memoria.
Aiden Campana cubierto los fundamentos, pero voy a añadir:
vinculación dinámica en tiempo de carga se logra generalmente mediante la vinculación estática de su aplicación a un archivo o .lib.a que contiene el código para establecer automáticamente los enlaces de tiempo de ejecución de símbolos para se puede encontrar en .dll o .so al iniciar el programa. Esto es generalmente para la funcionalidad fija (es decir, la biblioteca de tiempo de ejecución de C, etc.) y permite que su programa obtenga los beneficios de las correcciones de errores en las bibliotecas al tiempo que mantiene el tamaño 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, utilizas LoadLibrary() o el equivalente para conectar activamente módulos a tu programa en tiempo de ejecución, tal vez interrogando a un directorio que contiene archivos DLL de complementos, cargándolos uno por uno y hablando con un API de complemento creado internamente. 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 utilizando un conjunto fijo de símbolos y bibliotecas en el primer caso y un conjunto más dinámico en el segundo.
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, tenemos que vincular al archivo LIB. Y luego en el código, podemos llamar al método tan explícitamente como de costumbre. (Consulte Using Load-Time Dynamic Linking para ver 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 buscar usted mismo la función. (Consulte Using Run-Time Dynamic Linking para ver el código)
Para elegir entre las 2 opciones, marque Determining Which Linking Method to Use.
Por lo tanto, creo que la vinculación dinámica en tiempo de carga es solo otra forma de ahorrar el esfuerzo de los programadores. Pero se trata de una extensión. 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 de Windows.
En tiempo de carga, el archivo ejecutable de enlace dinámico está vinculado a la biblioteca DLL mientras que en el enlace dinámico en tiempo de ejecución no se ha vinculado ningún archivo ejecutable a ningún archivo DLL.
Enlace dinámico de tiempo de ejecución es preferible cuando el rendimiento de inicio de la aplicación es importante
+1 para ventajas de desarrollo/crecimiento. La arquitectura modular es genial. –
Información adicional para ejecutables de .Net: utilizan enlaces dinámicos en tiempo de ejecución. Si abre .NET DLL en "Dependency Walker", puede ver que solo cargan el enlace dinámico de tiempo con MSCOREE.DLL. Más información relacionada con esto está aquí: http://stackoverflow.com/questions/9545603/is-mscorlib-dll-mscoree-dll-loaded-when-net-application-runs Si hace referencia, pero no utiliza una DLL y el DLL falta, entonces su aplicación no tendrá errores. Puede ver las DLL cargadas actualmente en Debug> Windows> Modules. –