windows - example - loader.dll halo ce
Vinculación: archivos.a,.lib y.def (1)
Estoy construyendo un dll del ensamblado en Windows usando los binutils de GNU.
Sé que el dll se puede cargar cuando se carga el archivo ejecutable o en tiempo de ejecución (usando la llamada API de LoadLibrary).
Para la carga en tiempo de carga, parece que solo necesito el archivo dll: no se necesita un archivo .af, .lib o .def. Me preguntaba qué representan estos formatos de archivo y para qué sirven.
Lo que sé y algunas preguntas específicas:
.a es la extensión generalmente utilizada para la biblioteca estática en Unix. .a archivos se generan con la opción --out-implib de GNU ld. Se dice que es una "biblioteca de importación", es suficiente. La pregunta es, entonces, "¿De qué sirve una biblioteca de importación si no la necesito cuando la enlace?"
.lib es la extensión utilizada para la biblioteca estática en Windows, y de acuerdo con wikipedia, también se usa como "biblioteca de importación" en Windows, así que sospecho fuertemente que son solo otro nombre para lo que los binutils llaman archivos .a. Verdadero Falso ?
Todas las páginas puedo encontrar puntos que los archivos .def enumeran el símbolo exportado de la dll. ¿No es eso algo similar a lo que se supone que debe hacer una "biblioteca de importación"?
Además, leo aquí que el uso de archivos .def es una alternativa a la especificación manual de las exportaciones en el archivo fuente (lo que hice). Pero también recuerdo haber leído (no puedo encontrar la referencia). El archivo .def proporciona un índice ( ordinal ) en los símbolos exportados, lo que permite una carga más rápida en tiempo de ejecución. Es eso así ?
Las bibliotecas estáticas en Linux tienen la extensión de archivo .a . Las bibliotecas estáticas en Windows tienen la extensión de archivo .lib . Las bibliotecas dinámicas en Windows tienen la extensión .dll ; para enlazar con un archivo DLL, se requiere una biblioteca de importación. La biblioteca de importación es una biblioteca estática. Contiene el código requerido para cargar la DLL. Ahora está usando GCC (no cl.exe ) para compilar en Windows. GCC tiene otra convención de extensión de archivos para bibliotecas de importación, "debería llamarse * .dll.a o * .a", como se explica en el documento para la --out-implib que se refiere.
Las bibliotecas de importación ( .lib con .dll.a o .dll.a con GCC) son bibliotecas estáticas: contienen el código para cargar la DLL. Tuve la misma pregunta el otro día.
Una DLL puede tener funciones que se exportan y funciones que no se exportan. Una biblioteca de importación debe saber qué funciones se exportan y cuáles no. Uno de los medios para contarlo es un archivo DEF.
Al compilar el archivo DLL, el vinculador usa el archivo .def para crear un archivo de exportación (.exp) y un archivo de biblioteca de importación (.lib). El vinculador luego usa el archivo de exportación para construir el archivo DLL. Ejecutables que se vinculan implícitamente al enlace DLL a la biblioteca de importación cuando se crean. - MSDN: Exportar desde una DLL usando archivos DEF
También vea MSDN: Exportación de funciones desde un archivo DLL por ordinal en lugar de por nombre , que juntos deben responder su última pregunta sobre la exportación por índice o número ordinal.