回答Intel Object Module Format（OMF）標準を使用しています。その後Intelは386プロセッサと32ビット保護モードを導入し、その時点で32ビットのOMF仕様を拡張し、ほとんどのPC保護モード環境の標準となった「OMF-386」に導いた。同時期に、元のWindows NT開発チームは、Intelプロセッサだけでなく、他のベンダのプロセッサもサポートするようにコードを設計していました。 Microsoft NTチームは、UNIX System Vの公式のオブジェクトコード形式から派生したCOFF（Common Object File Format）というより移植性の高いオブジェクトモジュール形式を選択しました。COFFオブジェクトモジュールは、後ですべてのMicrosoft Win32開発ツールの標準規格となり、 Win32用のネイティブの実行可能形式（COFF形式のリンカーは、OMF形式のファイルよりもCOFFファイルから32ビットのEXEまたはDLLを作成する作業がはるかに少なくなっています）のPortable Executableファイルに近い形式の利点があります。
OMFおよびCOFF形式のオブジェクトファイル（.obj）と同様に、OMFおよびCOFF形式ライブラリファイル（.lib）もあります。幸いにも、ライブラリは基本的に単なるオブジェクトファイルのコレクションであり、リンカがライブラリからどのオブジェクトファイルを使用するかを決定するためのヘッダー情報もあります。ただし、OMFとCOFFの両方で同じファイル名拡張子.objと.libを使用すると、2つの異なるタイプのオブジェクトとライブラリファイル形式を参照することができます（このため、ファイル名拡張子オブジェクトモジュールまたはライブラリファイルがOMFかCOFFかどうかを知るため）。
異なるコンパイラベンダーのオブジェクトファイルとライブラリファイルを混在させると、一部のベンダーがCOFFをサポートし、他のベンダーはOMFを使用し、いくつかは両方を処理できます。たとえば、BorlandはOMFオブジェクトファイルとライブラリを使用していますが、Microsoftの32ビットコンパイラはCOFF形式のファイルを生成します。 Watcom C/C++ v11.0は、Windowsアプリケーションのコンパイルとリンク時にはCOFFを優先しますが、DOS4GWの32ビット保護モードDOSエクステンダで使用するOMFオブジェクトファイルを生成します。これに伴い、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形式のオブジェクトまたはライブラリファイルでの動作を拒否します。 Phar Lapなどの一部のDOSエクステンダと組み込みシステムのベンダーは、OMFとCOFFの両方をサポートする独自のリンカを提供しています。
結論は、OMFとCOFFオブジェクトを混在させ、ライブラリファイルの種類が混乱している可能性があることです（リンカのエラーメッセージは役に立ちません）。リンカが特別にサポートしていない限り、コンパイラ/リンカ/プラットフォームの推奨オブジェクトおよびライブラリ形式に固執し、OMFおよびCOFFファイルの混在を避ける必要があります。
http://www.iecc.com/linker/linker03.htmlをご覧ください。 – avakar
@avakar：そのリンクを適切な答えに入れてみませんか？ – xtofl