Windows の世界における C コンパイラ (MSVC および GCC/MinGW) の特定のケースでは、バイナリ互換性を前提として正しいです。GCC によってコンパイルされた C インターフェイス DLL を Visual Studio のプログラムにリンクできます。これは、開発者が ffmpeg のような C99 プロジェクトで Visual Studio を使用してアプリケーションを作成できるようにする方法です。DLL から Microsoft ツールチェーンにある lib.exe を使用してインポート ライブラリを作成するだけで済みます。またはその逆に、mingw.org の pexports またはより優れた mingw-w64 の gendef ツールを使用して、MSVC で生成された DLL 用の GCC インポート ライブラリを作成できます。
MSVC と GCC の ABI が異なり、互換性がない C++ インターフェイスの世界に入ると、この便利な相互運用性は崩壊します。うまくいくかもしれませんし、うまくいかないかもしれません。保証はされておらず、(現在)それを変更する努力もされていません。また、誰かが GCC で MSVC のデバッガーと互換性のあるデバッグ情報ジェネレーター/ライターを作成するまで (もちろん gdb サポートと共に)、デバッグ情報は明らかに異なります。
C99 では、関数宣言やシンボル定義での引数の扱い方に特に変更はないと思いますので、ここでも問題はないはずです。
Vijay が言ったように、まだアーキテクチャの違いがあるため、AMD64 ライブラリにリンクするときに x86 ライブラリを使用できないことに注意してください。
クローズド ソース バイナリと、利用可能なすべてのコンパイラ/アーキテクチャのバージョンの配布に関する追加の質問にも答えます。
これは、クローズド ソース バイナリを作成する方法とまったく同じです。インポート ライブラリに加えて、DLL からエクスポートを非表示にすることも非常に重要です。これにより、DLL 自体がリンクに使用できなくなります (クライアント コードでライブラリ内のプライベート関数を使用したくない場合は、たとえばdumpbin /exportsonの出力を参照してください)。 MSOffice DLL、そこにはたくさんの隠し要素があります)。などを使用して、GCCで同じことを達成できます（私は信じていますが、使用したり試したりしたことはありません）__attribute(hidden)。
コンパイラ固有のポイント:
MSVC には、/MT、/MD、および /LD を介して 4 つの (実際には、新しいバージョンでは 3 つしか残っていない) 異なるランタイム ライブラリが付属しています。さらに、互換性を確保するために、Visual Studio の各バージョン (サービス パックを含む) のビルドを提供する必要があります。しかし、それはクローズド ソース バイナリであり、Windows です...
GCC にはこの問題はありません。MinGW は常に、Windows (Windows 98 以降) によって提供される msvcrt.dll にリンクします。これは、/MD と同等です (おそらく、/MDd と同等のデバッグ ライブラリでもあります)。しかし、バイナリ互換性を保証しない MinGW の 2 つのバージョン (mingw.org と mingw-w64) があります。後者は、32 ビットと同様に 64 ビット オプションを提供するため、より完全であり、より完全なヘッダー/ライブラリ セット (DirectX および DDK のかなりの部分を含む) を提供します。