2009-06-08 34 views
12

Recientemente he estado manteniendo un proyecto heredado escrito en VC++ 6.0. El código usa tantas características únicas de este compilador que portarlo a un compilador estándar más reciente ha demostrado ser una tarea hercúlea.¿Cuál es la diferencia entre el formato OMF y COFF?

Entre las miles de líneas de código en el proyecto, hay cuatro archivos de ensamblador. Por alguna razón no entiendo, ni MASM615 ni TASM pueden compilarlos (envían errores), sin embargo tengo los archivos de objeto. Sin embargo, cuando enlazo la biblioteca consigo un mensaje

LNK4033 de advertencia: la conversión de formato de objeto de OMF a COFF

funciona la biblioteca como se esperaba, pero he estado preguntando ¿cuál es la diferencia entre estos binaria formatos, o si debería esperar algo feo de esta conversión.

+1

Eche un vistazo a http://www.iecc.com/linker/linker03.html. – avakar

+0

@avakar: ¿por qué no viertes ese enlace en una respuesta correcta? – xtofl

Respuesta

14

respuesta mellado de "MetaWINDOW FAQ - OMF vs COFF Formats.htm objeto de archivo"

Desde los albores de la civilización PC hasta el momento sobre las herramientas de programación Microsoft Win32 llegó, casi todos los compiladores de PC producidos archivos de objetos utilizando el estándar Intel Object Module Format (OMF). Más tarde, Intel introdujo 386 procesadores y modo protegido de 32 bits y, en ese punto, también ampliaron la especificación OMF para 32 bits, lo que llevó al "OMF-386" que se convirtió en el estándar para la mayoría de los entornos de modo protegido de PC. Alrededor de esta misma época, el equipo de desarrollo original de Windows NT también estaba diseñando código, no solo para procesadores Intel, sino también para admitir procesadores de otros proveedores. El equipo de Microsoft NT seleccionó un formato de objeto más portátil conocido como Formato de archivo de objeto común (COFF) derivado del formato oficial de código objeto para UNIX System V. Los módulos de objeto COFF luego se convirtieron en el estándar de hecho para todas las herramientas de desarrollo de Microsoft Win32 y obtuvieron una ventaja al estar mucho más cerca en formato de archivos ejecutables portátiles: el formato ejecutable nativo para Win32 (un enlazador de formato COFF tiene mucho menos trabajo para crear un archivo EXE o DLL de 32 bits de un archivo COFF que de un archivo de formato OMF).

Al igual que existen los archivos de objeto de formato OMF y COFF (.obj), también hay archivos de biblioteca de formato OMF y COFF (.lib). Las bibliotecas, afortunadamente, son básicamente solo una colección de los archivos objeto, junto con cierta información del encabezado que permite al vinculador determinar qué archivos objeto usar de la biblioteca. Sin embargo, para dificultar las cosas, tanto OMF como COFF usan las mismas extensiones de nombre de archivo, .obj y .lib, para hacer referencia a los dos tipos diferentes de formatos de archivo de biblioteca y objeto (debido a esto no se puede simplemente mirar la extensión de nombre de archivo) para saber si el módulo de objeto o el archivo de la biblioteca es OMF o COFF).

El problema con la mezcla de archivos de objetos y archivos de biblioteca de diferentes proveedores de compiladores es que algunos proveedores admiten COFF, otros proveedores usan OMF y algunos pueden manejar ambos. Borland, por ejemplo, todavía usa archivos y bibliotecas de objetos OMF, mientras que los compiladores de 32 bits de Microsoft producen archivos de formato COFF. Watcom C/C++ v11.0 parece preferir COFF al compilar y vincular aplicaciones de Windows, pero genera archivos de objetos OMF para su uso con DOS-extensor DOS4GW de modo protegido de 32 bits. Junto con esto, Microsoft MASM 6.13 produce archivos OMF por defecto, pero con el modificador/coff puede emitir archivos de objeto COFF en su lugar.

Cuando llega el momento de vincular archivos con diferentes formatos, diferentes enlazadores hacen cosas diferentes. Por ejemplo, el enlazador de Microsoft Visual C/C++ está diseñado para bibliotecas y archivos de objetos de formato COFF, pero intentará convertir archivos de objetos OMF en archivos COFF si es necesario. Esto funciona en algunos casos, pero desafortunadamente Microsoft LINK no admite todos los tipos de registros OMF, por lo que en muchas situaciones el enlazador puede fallar aún cuando se le den archivos de objetos con formato OMF. Además, mientras que Microsoft LINK intenta dar soporte a los archivos de objetos OMF, se negará a procesar cualquier biblioteca de formatos OMF.Otros enlazadores, como TLINK de Borland, están diseñados para archivos de objeto OMF y se negarán de manera similar a trabajar con objetos de formato COFF o archivos de biblioteca. Algunos proveedores de sistemas integradores y extensores de DOS, como Phar Lap, proporcionan sus propios enlazadores que admiten tanto OMF como COFF, lo que le permite elegir.

La conclusión es que mezclar objetos OMF y COFF y tipos de archivos de biblioteca puede ser un desastre (además de los mensajes de error crípticos de los vinculadores no ayudan). A menos que su enlazador lo soporte específicamente, debe seguir con el formato de biblioteca y objeto recomendado para su compilador/enlazador/plataforma, y ​​evitar mezclar los archivos OMF y COFF.

+0

La línea de fondo parece que _his_ linker hace la conversión. No genera un error. – xtofl

+0

Pero no todas las conversiones funcionan sin problemas. Si hay errores en el tiempo de ejecución o fallas en las funciones, busque en esta lib u obj u obj dentro de una lib frist. O, por supuesto, todo podría estar bien. – kingchris

+0

¿Todos los enlazadores tienen que crear un ejecutable PE-COFF al final para que se ejecute en una plataforma de Windows? Es decir, después del proceso de enlace, el ejecutable final producido puede contener datos y una estructura específica de otro formato de objeto, por ejemplo. OMF? Y si es así, ¿cómo funciona eso? (¿o cómo * puede * funcionar?) – greatwolf

Cuestiones relacionadas