Red de conocimiento informático - Problemas con los teléfonos móviles - La diferencia entre bibliotecas de enlaces dinámicos en Windows y Unix

La diferencia entre bibliotecas de enlaces dinámicos en Windows y Unix

Hola, estaré encantado de responder a tu pregunta.

En Unix, el nombre de archivo de las bibliotecas de enlaces dinámicos generalmente termina en .so (normalmente comienza con lib). En Windows, el sufijo del archivo es .DLL. Hay algunos detalles en el manejo de DLL de Windows que se pasan por alto fácilmente

Si necesita cargar activamente una biblioteca de vínculos dinámicos en tiempo de ejecución, puede usar la API del kernel LoadLibrary (en kernel32.dll) en Windows; en Unix es Usar dlopen. Para encontrar la dirección del símbolo exportado en el dll en Windows, puede usar GetProcAddress, y Unix también tiene las API correspondientes...

Estas API correspondientes parecen indicar funciones equivalentes, pero de hecho existen diferencias. de.

DLL es en realidad lo mismo que un archivo EXE y es un archivo ejecutable en formato PE. Para hacer referencia implícita a símbolos externos, la ubicación del símbolo externo debe escribirse en el encabezado PE. El cargador de PE encontrará la tabla de símbolos dependientes en el encabezado de PE y cargará otros archivos DLL dependientes.

Sin embargo, este no es el caso en Unix. La mayoría de los archivos están en el formato de archivo ejecutable elf. Cuando requieran símbolos externos, no será necesario especificar la ubicación de estos símbolos. En otras palabras, normalmente el archivo so no sabe de qué archivos depende. Estos símbolos los proporciona el tiempo de ejecución del proceso que llama a dlopen. El archivo ejecutable en Unix expondrá sus propios símbolos de enlace estático (que pueden implementarse por sí solo o vincularse desde el archivo .a de la biblioteca estática). dlopen notificará estos símbolos al archivo .so cargado por dlopen y finalmente completará el enlace dinámico. (De hecho, dlopen también puede especificar el modo para completar operaciones más complejas)

Debido a esta diferencia, el intérprete de Lua en Unix puede vincular de forma completamente estática todas nuestras API de Lua para usos de Lua, por lo que habrá; No hay peligros ocultos en el formulario que se carga en tiempo de ejecución. En Windows, se debe generar un archivo DLL de luacore para que el intérprete de lua pueda compartir la api de lua (incluida la implementación de crt) en la biblioteca de extensiones sin problemas.

También es debido a esta diferencia que en VC hay opciones como CRT de enlace dinámico, CRT de enlace estático, biblioteca multiproceso, biblioteca de un solo subproceso, etc., que confunden a los desarrolladores novatos de Windows. Las personas que no tienen habilidades de desarrollo de Windows tendrán que tropezar con él.

Desde la perspectiva del diseño de la biblioteca de enlaces dinámicos, personalmente creo que Windows ha hecho un trabajo terrible. Esto es especialmente cierto para los desarrolladores. Al menos cuando creamos un archivo dll para que todos lo usen en Windows, también necesitamos traer un archivo .lib, mientras que en Unix, generalmente solo el archivo de encabezado correspondiente es suficiente; Para escribir un nuevo .so, los símbolos que faltan pueden permanecer allí hasta que la ejecución final del archivo combine todos los símbolos necesarios. Windows puede tener una dependencia implícita de un dll sobre otro dll; mientras que en Unix, generalmente no hay necesidad de que tal o cual tenga una dependencia implícita. Esto hace que sea mucho más difícil para nosotros reemplazar globalmente cosas como CRT y, según mi propia experiencia en programación, no hay muchos beneficios.

En Unix, debe usar ldconfig para administrar bibliotecas dinámicas. Este método se puede usar en Windows copiando la DLL al directorio actual, lo que sin duda mejora la seguridad del sistema.

Si está satisfecho, haga clic en el botón derecho para aceptar la respuesta. Si aún tiene preguntas, haga clic para preguntar.

Espero que mi respuesta le sea útil y. ¡Espero que lo aceptes!

~O(∩_∩)O~