[〜＃〜] abi [〜＃〜] 全体は、sepp2kで述べたバイナリ形式（Mach-OとELF）だけではなく、異なります。
たとえば、LinuxとDarwin/XNU（OS Xのカーネル）の両方がPowerPCでscを使用し、int 0x80/sysenter/syscall x86のsyscallエントリの場合、それ以降はそれほど一般的なことはありません。
DarwinはMachマイクロカーネルに負のsyscall番号を、BSDモノリシックカーネルに正のsyscall番号を指示します— xnu/osfmk/mach/syscall_sw.h および xnu/bsd/kern/syscalls.masterを参照） 。 Linuxのsyscall番号はアーキテクチャによって異なります— linux/Arch/powerpc/include/asm/unistd.h 、 linux/Arch/x86/include/asm/unistd_32.h を参照してください。および linux/Arch/x86/include/asm/unistd_64.h —ただし、すべて負ではありません。したがって、明らかに、syscall番号、syscall引数、およびthissyscallが存在する場合でも異なります。
標準のCランタイムライブラリも異なります。ダーウィンは主にFreeBSDのlibcを継承しますが、Linuxは通常glibcを使用します（ただし、eglibc、dietlibc、uclibc、Bionicなどの代替手段があります）。
グラフィックススタック全体が異なることは言うまでもありません。 Cocoa Objective-Cライブラリ全体を無視すると、OS XのGUIプログラムはMachポートを介してWindowServerと通信しますが、Linuxの場合、GUIプログラムは通常、X11プロトコルを使用してUNIXドメインソケットを介してXサーバーと通信します。もちろん例外はあります。 DarwinでXを実行したり、LinuxでXをバイパスしたりできますが、OS Xアプリケーションは確実にXを話しません。
Wineのように、誰かがその作業を
- mach-Oのバイナリローダーの実装
- すべてのXNUシステムコールをトラップし、適切なLinuxシステムコールに変換する
- 必要に応じてCoreFoundationのようなOS Xライブラリの代替を書く
- 必要に応じてWindowServerなどのOS Xサービスの代替を作成する
その後、Linuxで「ネイティブに」OS Xプログラムを実行することが可能になる可能性があります。数年前、Kyle Moffetが最初の項目にいくつかの作業を行い、Linux用のプロトタイプ binfmt_mach-o を作成しましたが、完成することはなく、他に同様のプロジェクトはありません。
（理論的にはこれはかなり可能であり、同様の取り組みが何度も行われています。Wineに加えて、Linux自体がHP-UXやTru64などの他のUNIXからのバイナリの実行をサポートしています Glendix プロジェクトLinuxにPlan 9の互換性をもたらすことを目的としています。）
誰かhasがLinux用のMach-OバイナリローダーとAPIトランスレータを実装するための努力をしました！
shinh/maloader-GitHub は、Wineに似たアプローチでバイナリをロードし、ユーザー空間ですべてのライブラリ呼び出しをトラップ/変換します。 syscallsとすべてのグラフィック関連ライブラリを完全に無視しますが、多くのコンソールプログラムを動作させるには十分です。
Darling maloaderに基づいて構築され、ライブラリとその他のサポートランタイムビットを追加します。
OSXアプリケーションがLinuxでネイティブに実行されない理由：
まず、OSXはLinuxとは異なるバイナリ形式を使用するため、LinuxはOSX用にコンパイルされたバイナリを実行できません（WindowsまたはBSD用にコンパイルされたバイナリを実行できないのと同じ方法）。
第二に、GUIアプリケーションについて話している場合、AppleのGUIツールキットCocoaは、a）OSXでのみ利用可能であり、b）X11上で実行されません。
OSXアプリケーションにwineに相当するものがない理由：
ワインが半分も使えるようになる前に、多くの作業を行わなければなりませんでした。 OSXに相当するものに対する需要はそれほど多くないため、そのようなプロジェクトにこれほどの労力を費やした人はまだいません。
OS XアプリがLinuxで実行されない最も重要な理由は、それらのOSが異なるシステムコールを使用したためです。
以前のいくつかの回答ではライブラリについて言及しましたが、一般的にはそうではありません-Core Foundationは、主にAppleという名前でCFLiteの名前でオープンソース化されており、任意のプラットフォームに容易に移植できます（iTunesのWindowsバージョンは実際にはCore FoundationのWindowsへの移植、およびいくつかのコンパイラの調整により、Linuxディストリビューションでclangを使用してCFLiteを直接作成できます）また、Objective-C環境、主にFoundationとAppKitをLinux、特にGNUstepに移植するオープンソースの取り組みもあります。 、GNU OpenStepの実装。これはAppleのCocoaよりも前の日付です（NeXT Computer社がまだあったときに始まりました）。
誰かが決まったら、すべてのMach-O syscallをキャプチャして対応するLinux syscallに変換するローダーを設計し、それらのオープンソースライブラリの「カウンターパート」を適切なABI変換でバイナリに動的にリンクできます。
また、参考までに、Mach-Oアプリケーションのソースコードを入手できる場合は、それを移植することを検討すると、非常に簡単になる場合があります。例として、OS X 10.6にバンドルされているTextEditアプリは、数行の（重要でない）CFコードを取り除いた後、GNUstepにリンクして直接再コンパイルできるため、Linuxですぐに利用できます（GNUstepに付属するTextEditは実際にはOS Xの前身であるNeXTSTEPのTextEditアプリを直接再コンパイルし、「©1995 NeXT」ラベルも保持します）。 TextEditはBSDライセンスの下にあります。
2012年12月8日、ダーリンという新しいプロジェクトが開始されました。