重要なことを 1 つ忘れています。それは、何か興味深いことを行うには、プログラムがオペレーティング システムと対話する必要があるということです。
Linux と OS X では規則が異なるため、同じバイナリをそのまま実行することはできません。基本的に、オペレーティング システムに依存するコードのチャンクを操作できるようにする必要があります。これらの多くは、ライブラリを介して提供され、次にリンクする必要があります。つまり、プログラムはリンク可能である必要があり、リンクも 2 つのシステム間で異なります。
そして、それは何度も続きます。表面上は同じことをしているように見えますが、実際の詳細は大きく異なります。
誰かがそれを実現するのに十分な時間を費やしたい場合、これは実行可能です。 Darling プロジェクトはこれを試みていますが、この記事を書いている時点ではかなり原始的な状態です。
以前は他のプラットフォームで成功していました:
-
Solaris および UnixWare には、
lxrunというヘルパー プログラムが含まれています。sudoのように動作します :実行可能ファイルの名前とパラメーターをヘルパーに渡すと、実行可能ファイルが OS と通信できるように動的に修正されます。公式サイト (ダウン、アーカイブ リンク) によると、bitrotted です。 -
Linux のカーネルにはかつて iBCS と呼ばれる逆の機能がありましたが、カーネルが「外部」バイナリを直接認識したため、ヘルパーは必要ありませんでした。カーネル 2.3 の開発シリーズ中に荒廃したのは、2.4 が登場した時点で小規模な Unix サーバーの戦いが本質的に終わったためと考えられます。
-
FreeBSD のカーネルは、Linux バイナリを認識し、ネイティブであるかのように実行するように構成できます。この機能は、上記の 2 つよりも優れているようです。
OpenBSD と NetBSD には同様の機能があります。
OS X には多くの FreeBSD が含まれているため、Linux サポートの移植は簡単かもしれません。
私は皆さんの意見にほぼ同意しますが、これにはかなりの時間と労力がかかりますが、Wine の開発にかかったほどではないことを付け加えたいと思います。
Wine 開発における困難の多くは、クローズド ソースのオペレーティング システムからバイナリ形式を移植していることと、多くのシステム コールが文書化されていないことです。彼らは基本的にオペレーティング システムをリバース エンジニアリングする必要がありました。
あるオープン OS から別のオープン OS にこれを行う場合、1/10 の時間で完了する可能性があります。これは、同等のネイティブ システム コールが実行された場合、互換性レイヤーが他の OS からコピー/貼り付けされる可能性が非常に高いためです。存在しません。もちろん、POSIX の世界ではほとんどの場合、ネイティブ コールが利用可能です。
もう 1 つの注目すべきプロジェクトは ReactOS です。このプロジェクトでは、基本的に Windows の完全なバイナリ互換バージョンを作成しています... Wine は必要ありません。