Ответ вычеркнут из раздела «Часто задаваемые вопросы по MetaWINDOW - формат файла OMF vs COFF Formats.htm»
С момента зарождения ПК-цивилизации и до того времени, когда появились инструменты программирования Microsoft Win32, почти все компиляторы ПК создавали объектные файлы, используя стандарт Intel Object Module Format (OMF). Позже Intel представила 386 процессоров и 32-битный защищенный режим, после чего они также расширили спецификацию OMF для 32-битных систем, что привело к появлению "OMF-386", который стал стандартом для большинства сред защищенных режимов ПК. Примерно в это же время команда разработчиков Windows NT также занималась разработкой кода не только для процессоров Intel, но и для поддержки процессоров других производителей. Команда Microsoft NT выбрала более переносимый формат объектных модулей, известный как Common Object File Format (COFF), полученный из официального формата объектного кода для UNIX System V. Объектные модули COFF позже стали стандартом де-факто для всех инструментов разработки Microsoft Win32 и получили преимущество в том, что он гораздо ближе по формату к переносимым исполняемым файлам - собственный исполняемый формат для Win32 (у компоновщика в формате COFF гораздо меньше работы по созданию 32-битного EXE или DLL из файла COFF, чем из файла формата OMF).
Так же, как существуют объектные файлы в формате OMF и COFF (.obj), существуют также файлы библиотек в формате OMF и COFF (.lib). К счастью, библиотеки - это просто набор объектных файлов вместе с некоторой информацией заголовка, которая позволяет компоновщику определить, какие объектные файлы использовать из библиотеки. Однако, чтобы усложнить задачу, и OMF, и COFF используют одинаковые расширения имен файлов .obj и .lib для ссылки на два разных типа форматов файлов объектов и библиотек (из-за этого нельзя просто посмотреть на расширение имени файла сказать, является ли объектный модуль или файл библиотеки OMF или COFF).
Проблема смешивания объектных файлов и библиотечных файлов от разных поставщиков компиляторов заключается в том, что некоторые поставщики поддерживают COFF, другие используют OMF, а некоторые могут обрабатывать оба. Например, Borland по-прежнему использует объектные файлы и библиотеки OMF, а 32-разрядные компиляторы Microsoft создают файлы в формате COFF. Watcom C / C ++ v11.0, по-видимому, предпочитает COFF при компиляции и компоновке приложений Windows, но генерирует объектные файлы OMF для использования со своим DOS-расширителем DOS4GW с 32-разрядным защищенным режимом. Наряду с этим Microsoft MASM 6.13 по умолчанию создает файлы OMF, но с помощью переключателя / coff может выдавать объектные файлы COFF.
Когда приходит время связывать файлы в разных форматах, разные линкеры делают разные вещи. Например, компоновщик Microsoft Visual C / C ++ предназначен для объектных файлов и библиотек формата COFF, но при необходимости попытается преобразовать объектные файлы OMF в файлы COFF. В некоторых случаях это работает, но, к сожалению, Microsoft LINK не поддерживает все типы записей OMF, поэтому во многих ситуациях компоновщик может все же выйти из строя при задании объектных файлов формата OMF. Кроме того, хотя Microsoft LINK пытается поддерживать объектные файлы OMF, она отказывается обрабатывать любые библиотеки формата OMF. Другие компоновщики, такие как Borland TLINK, предназначены для объектных файлов OMF и аналогичным образом откажутся работать с объектными или библиотечными файлами в формате COFF. Некоторые поставщики расширений DOS и встраиваемых систем, такие как Phar Lap, предоставляют свои собственные компоновщики, которые поддерживают OMF и COFF, предоставляя вам выбор.
Суть в том, что смешивание объектов объектов OMF и COFF и типов библиотечных файлов может привести к путанице (плюс загадочные сообщения об ошибках от компоновщиков не помогают). Если ваш компоновщик не поддерживает его специально, вам следует придерживаться рекомендуемого формата объекта и библиотеки для вашего компилятора / компоновщика / платформы и избегать смешивания файлов OMF и COFF.