问题描述
最近，我一直保持着写在VC ++ 6.0的遗产项目。在code使用该编译器，将它移植到更近的标准编译器已被证明是一个艰巨的任务那么多独特的特点。
Recently I've been maintaining a legacy project written in VC++ 6.0. The code uses so many unique characteristics of this compiler that porting it to a more recent standard compiler has proved to be an herculean task.
其中在项目code的千行，有四个汇编文件。出于某种原因，我不明白，也不MASM615也不TASM能够编译它们（他们发送错误），不过我有对象文件。然而，当我链接库我得到一个消息
Among the thousands lines of code in the project, there are four assembler files. For some reason I don't understand, nor MASM615 nor TASM are able to compile them (they send errors), nevertheless I have the object files. However when I link the library I get a message
警告LNK4033：从OMF转换对象格式COFF
该库按预期工作，但我一直在想，什么是这些二进制格式之间的差异，或者我应该期待什么，从这种转换丑陋的。
The library works as expected, but I've been wondering what's the differences between these binary formats, or if I should expect something ugly from this conversion.
推荐答案
答缺口走出MetaWINDOW常见问题 - OMF VS COFF目标文件Formats.htm
Answer nicked out of "MetaWINDOW FAQ - OMF vs COFF Object File Formats.htm"
由于PC文明直到大约时间的Microsoft Win32编程工具黎明来了，几乎所有的PC编译器生成使用英特尔对象模块格式（OMF）标准的对象文件。后来，Intel推出386处理器和32位保护模式在这一点上，他们还扩大了32位OMF规范，导致OMF-386，这成为大多数PC保护模式的环境标准。大约在这个同时，原始Windows NT开发团队也设计code，不仅为英特尔处理器，而且还支持其他厂商的处理器。微软NT团队选择被称为通用对象文件格式（COFF）从UNIX系统V COFF对象模块官方对象 - code格式导出一个更便携的目标模块格式后来成为所有Microsoft Win32开发工具的事实标准，并获得了正在格式更接近移植的可执行文件，一个优势 - 为Win32本机的可执行文件格式（COFF格式的连接要少得多的工作，以创建比从OMF格式COFF文件中的32位的EXE或DLL文件）。
Since the dawn of PC civilization up until about the time Microsoft Win32 programming tools came along, almost all PC compilers produced object files using the Intel Object Module Format (OMF) standard. Later, Intel introduced 386 processors and 32-bit protected-mode at which point they also expanded the OMF specification for 32-bits, leading to "OMF-386" which became the standard for most PC protected-mode environments. Around this same time, the original Windows NT development team was also designing code, not only for Intel processors, but also to support processors from other vendors. The Microsoft NT team selected a more portable object module format known as Common Object File Format (COFF) derived from the official object-code format for UNIX System V. COFF object modules later became the defacto standard for all Microsoft Win32 development tools, and gained an advantage in being much closer in format to Portable Executable files - the native executable format for Win32 (a COFF-format linker has much less work to create a 32-bit EXE or DLL from a COFF file than from an OMF format file).
正如有OMF-和COFF格式的目标文件（.OBJ的），还有OMF和COFF格式库文件（.LIB的）。在图书馆，幸运的是，基本上只是一个目标文件集合，一些头信息，让链接器确定哪些对象文件从库一起使用。为了刁难然而，无论OMF和COFF使用相同的文件扩展名，.OBJ和.LIB，引用两种不同类型的对象和库文件格式（因为这个你不能光看文件扩展名告诉如果对象模块或库文件是OMF或COFF）。
Just as there are OMF- and COFF-format object files (.obj's), there are also OMF and COFF format library files (.lib's). The libraries, fortunately, are basically just a collection of the object files, along with some header information that lets the linker determine which object files to use from the library. To make things difficult however, both OMF and COFF use the same file name extensions, .obj and .lib, to reference the two different types of object and library file formats (because of this you can't just look at the file name extension to tell if the object module or library file is OMF or COFF).
从不同的编译器厂商混合的目标文件和库文件的问题是有些供应商支持COFF，其他供应商使用OMF，和几个可以处理。 Borland公司，例如，仍然使用OMF对象文件和库而微软的32位编译器产生COFF格式文件。编译和链接Windows应用程序时，在Watcom C / C ++ V11.0似乎preFER COFF，但会产生OMF对象文件与他们DOS4GW 32位保护模式DOS扩展使用。与此同时，微软MASM 6.13默认情况下会产生OMF文件，但与/ COFF开关可以发出COFF对象文件来代替。
The problem with mixing object files and library files from different compiler vendors is that some vendors support COFF, other vendors use OMF, and a few can handle both. Borland, for example, still uses OMF object files and libraries, while Microsoft's 32-bit compilers produce COFF format files. Watcom C/C++ v11.0 seems to prefer COFF when compiling and linking Windows applications, but generates OMF object files for use with their DOS4GW 32-bit protected-mode DOS-extender. Along with this, Microsoft MASM 6.13 produces OMF files by default, but with the /coff switch can emit COFF object files instead.
当谈到时间不同格式的链接文件，链接器的不同做不同的事情。例如，微软的Visual C / C ++连接器是专为COFF格式对象文件和库，但会尝试OMF对象文件转换为COFF文件，如果必要的。这在某些情况下，但不幸的是微软LINK不支持所有OMF记录类型，因此在很多情况下，给定的OMF格式的目标文件时，链接器可能仍会失败。另外虽然微软试图LINK为OMF对象文件的一些支持，它会拒绝处理任何OMF格式库。其它接头，例如Borland的TLINK，是专为OMF目标文件和将同样拒绝与COFF格式的对象或库文件的工作。一些DOS扩展和嵌入式系统供应商，如Phar膝，提供自己的链接器支持两种OMF和COFF，给你一个选择。
When it comes time to link files with different formats, different linkers do differnt things. For example, the Microsoft Visual C/C++ linker is designed for COFF format object files and libraries, but will try to convert OMF object files into COFF files if necessary. This works in some cases, but unfortunately Microsoft LINK does not support all OMF record types, so in many situations the linker may still fail when given OMF format object files. Also while Microsoft LINK attempts some support for OMF object files, it will refuse to process any OMF format libraries. Other linkers, such as Borland's TLINK, are designed for OMF object files and will similarly refuse to work with COFF-format object or library files. Some DOS extender and embedded system vendors, such as Phar Lap, provide their own linkers which support both OMF and COFF, giving you a choice.
的底线是混合OMF和COFF对象和库文件类型可以是一团糟（加上由接头的神秘的错误消息不帮助）。除非你的链接器专门支持它，你应该坚持推荐的对象和库格式为您编译器/连接/平台，避免混合OMF和COFF文件。
The bottom line is that mixing OMF and COFF object and library file types can be a mess (plus the cryptic error messages from the linkers don't help). Unless your linker specifically supports it, you should stick with recommended object and library format for your compiler/linker/platform, and avoid mixing OMF and COFF files.
这篇关于什么是OMF和COFF格式之间的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！