¿Cargar una DLL más de una vez?

Question

Estoy usando la función LoadLibrary para cargar una DLL en Windows. Mi pregunta es esta: si llamo a este método más de una vez para la misma DLL, ¿obtengo identificadores para diferentes instancias de la DLL, o todos se referirán a la misma instancia?

Además, ¿cómo se correlaciona este comportamiento con los archivos SO Linux, es el mismo o completamente diferente, y qué suposiciones puedo hacer al respecto? Gracias.

Answer 1

La documentación de MSDN:

El sistema mantiene un recuento de referencia por proceso en todos los módulos cargados. Llamar a LoadLibrary incrementa el recuento de referencia. Si llama al , la función FreeLibrary o FreeLibraryAndExitThread reduce el recuento de referencias . El sistema descarga un módulo cuando su recuento de referencia llega a cero o cuando el proceso finaliza (independientemente del recuento de referencias ).

Parece que cargar el módulo más de una vez (sin hacer coincidir las llamadas a FreeLibrary) devolverá el mismo identificador.

Answer 2

Si la DLL ya está cargada, LoadLibrary simplemente devolverá la dirección de la biblioteca en la memoria. Sin embargo, DllMain no se vuelve a llamar con DLL_PROCESS_ATTACH cuando se intenta la segunda carga. Los identificadores en el sentido de bibliotecas son solo ubicaciones de memoria, por lo que el valor que obtenga la segunda vez debería ser el mismo que el primero.

En cuanto a archivos SO de Linux, no veo por qué cargarían dos veces tampoco. Sin embargo, alguien más tendrá que opinar sobre esto para darle una respuesta adecuada.

Answer 3

Para Linux objetos compartidos, desde el dlopen(3) manpage:

Si la misma biblioteca se carga de nuevo con dlopen(), el mismo identificador de archivo se devuelve. La biblioteca dl mantiene el recuento de referencia para asas de la biblioteca, por lo una biblioteca dinámica no se cancela la asignación hasta dlclose() ha sido llamado en él tantas veces como dlopen() ha tenido éxito en ella . La rutina _init(), si está presente, solo se llama una vez. Pero una llamada subsiguiente con RTLD_NOW puede forzar la resolución del símbolo para una biblioteca cargada anteriormente con RTLD_LAZY.