问题描述
最近我一直在维护一个用 VC++ 6.0 编写的遗留项目.代码使用了该编译器的许多独特特性，以至于将其移植到更新的标准编译器已被证明是一项艰巨的任务.
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.
在项目的数千行代码中，有四个汇编文件.出于某种原因，我不明白，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 FAQ - OMF vs COFF Object File 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 开发团队也在设计代码，不仅适用于 Intel 处理器，还支持其他供应商的处理器.Microsoft NT 团队选择了一种更便携的对象模块格式，称为通用对象文件格式 (COFF)，该格式源自 UNIX System V 的官方对象代码格式. COFF 对象模块后来成为所有 Microsoft Win32 开发工具的事实上的标准，并获得了在格式上更接近可移植可执行文件的优势 - Win32 的本机可执行格式(COFF 格式链接器从 COFF 文件创建 32 位 EXE 或 DLL 的工作比从 OMF 格式文件创建的工作少得多).
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's) 一样，也有 OMF 和 COFF 格式的库文件 (.lib's).幸运的是，这些库基本上只是目标文件的集合，以及一些让链接器确定要使用库中的目标文件的头信息.然而，让事情变得困难的是，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 目标文件和库，而 Microsoft 的 32 位编译器生成 COFF 格式的文件.Watcom C/C++ v11.0 在编译和链接 Windows 应用程序时似乎更喜欢 COFF，但会生成 OMF 对象文件以用于其 DOS4GW 32 位保护模式 DOS 扩展程序.与此同时，Microsoft 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.
当需要链接不同格式的文件时，不同的链接器会做不同的事情.例如，Microsoft Visual C/C++ 链接器专为 COFF 格式的目标文件和库而设计，但会在必要时尝试将 OMF 目标文件转换为 COFF 文件.这在某些情况下有效，但遗憾的是 Microsoft LINK 不支持所有 OMF 记录类型，因此在许多情况下，当给定 OMF 格式的目标文件时，链接器可能仍会失败.此外，虽然 Microsoft LINK 尝试对 OMF 对象文件提供一些支持，但它会拒绝处理任何 OMF 格式库.其他链接器，例如 Borland 的 TLINK，是为 OMF 目标文件设计的，并且同样拒绝使用 COFF 格式的目标文件或库文件.一些 DOS 扩展器和嵌入式系统供应商，如 Phar Lap，提供他们自己的链接器，支持 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 格式有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！