クロスプラットフォームアプリケーションで「脂肪バイナリ」がより広く使用されないのはなぜですか？

私の知る限り、いわゆる「ファットバイナリ」-複数のシステムのマシンコードを含む実行可能ファイル-は実際にはApple PCでのみ使用されていますが、 PowerPCからx86。

最近では多くのソフトウェアがクロスプラットフォームであり、単一のファットバイナリを作成することは、オペレーティングシステムとアーキテクチャの組み合わせごとに何十もの異なるダウンロードを追跡するよりも多くの点で簡単になるようです。彼らが望むものに顧客に。

たとえば、なぜこのアプローチが受け入れられなかったのかについて、多くの推測を思いつくことができます。

• マルチOSバイナリを実行不可能にするクロスコンパイルツールの欠如
• とにかく各OSでコードをテストする必要があるため、各OSにネイティブにコンパイルできるシステムが既に必要です。
• どうやら32ビットプログラムは既に64ビットマシンで「機能する」
• 動的リンクはOSごとに異なるため、「脂肪アプリケーション」が動作しても「脂肪ライブラリ」は動作しない場合があります

しかし、私は常にこれらのOS固有およびアーキテクチャ固有の詳細をすべて隠すライブラリまたはフレームワークを使用しているため、そのどれが本当に真実であるか、またはさらに多くの問題があるかどうかわからない約。それでは、マルチアーキテクチャソフトウェアやマルチOSソフトウェアの作成にファットバイナリが一般に使用されない実際の理由は何ですか？（アップル以外）

ファットバイナリアプローチは、次の場合に最も意味があります。

1. 両方のアーキテクチャが同じシステムに共存します
2. それ以外は、すべてのアーキテクチャでほぼ同じです

そのため、クロスプラットフォームコード（両方の基準は適用されません）や、1つのバイナリで異なるLinuxディストリビューションをサポートするために使用されません（1.は適用されません、2。はある程度適用されます）。

Linuxでは、単一のLinuxディストリビューションで32ビットと64ビットの両方をサポートする場合、両方の基準が引き続き適用されます。しかし、すでに複数のディストリビューションをサポートする必要がある場合、なぜ面倒なのでしょうか？

上のWindows、16ビットから32ビットへの移行は、多くの点で16ビットWindowsの世界から大きな偏差（仮想メモリ、マルチユーザアクセス制御、APIの変更...）であったのWindows NTの導入で最初に起こりました。これらのすべての変更により、32ビットと16ビットのワールドを分離しておく方が良いでしょう。NTはすでに「OS」という異なるOS「ペルソナ」（Win32、POSIX）をサポートする「サブシステム」の概念を持っていたため、Win16を3番目のサブシステムにすることは簡単な選択でした。

Win32からWin64への移行には、同様の大きな変更はありませんでしたが、Microsoftはとにかく同様のアプローチを使用しました。

インターネット年齢分布ロジスティクスは、次の2つの方法でファットバイナリを阻害します。

1. POSは物理的な商品を含まないため、商品が小売りの棚スペースをめぐって競合し、顧客が購入する機会が限られている場合のように、より少ないSKUを優先します。

2. 帯域幅のコストは、特定のソフトウェアパッケージに最低限必要なビットのみを配信することを支持します。ファットバイナリをネットワークに送信すると、顧客エクスペリエンスと販売者インフラストラクチャの効率が低下します。

ソフトウェアがシュリンクラップされた物理メディアの場合、ファットバイナリはより意味がありました。

ファットバイナリが成功しなかった理由の一部は、バイナリ実行可能ファイルを無効にするためのABIとプロセッサ（実際には命令セット）の仕様以上のものがあることです。多くの場合、バイナリ実行可能ファイルは、他のリソース、特に動的ライブラリ（DLLの地獄を参照）、外部サービス（PostGreSQLのようなDBMSを考える）に大きく依存します ...）、システム構成（/etc/Linux上の構成ファイルの場所など）にます。などなど。

Linux / x86-64の場合、すべてのLinuxディストリビューションで実行可能なバイナリ実行可能ファイルを作成するのは実際には困難です（多くの場合、特定のバージョンのlibcまたはに関連付けられているためlibstdc++）。FatELFは存在しますが、あまり成功していません。

明確に定義されたABIと命令セットを使用しても、最適化はさまざまなプロセッサブランドで異なります。次の-mtune=native x86最適化フラグを参照してください。 GCCを。

Appleは、コンピューティングリソースの非常に閉じたエコシステムを提供するという理由だけで、ファットバイナリを持つことに部分的に成功しました。

フリーソフトウェアは、移植性の問題を解決する別の方法です。アプリケーションがフリーソフトウェア（移植性のために慎重にコーディングされている）である場合、同様のシステムに非常に簡単に移植できます。また、元のソースコードがシステムで意図したとおりに機能しない場合でも、通常は合理的に簡単に適応（または作業を行うために誰かに支払い）できます（もちろん、特定のOSまたはABIまたはプロセッサに関連付けられたフリーソフトウェアは容易ではありません）ポート、そのための努力を払うでしょう）。また、POSIXやLinux Standard Baseなどの標準も役立ちます。

^{利用可能なソースコードを使用して（無料の）ソフトウェアを移植するように誰かに支払う（または依頼する）こともできますが、バイナリ実行可能ファイルを移植するのは非現実的です。}

最後に、Qt＆POCOなどのいくつかのオペレーティングシステム（ソースコードが提供されている場合）への移植を支援するいくつかのフレームワークが存在します。

JVMなどの適切に指定されたバイトコードを使用しても、常に移植性が保証されるわけではありません。一部のJavaアプリケーションは、移植性がないことがよく知られています。

ところで、コンピューターシステムは、おそらく1980年代または1990年代初期（またはメインフレーム時代）よりも、今日ではそれほど異質ではありません。

最後に、ファットバイナリはファットです。多くの人に関係ないかもしれない移植性の問題のために、多くのリソース（ビルド時間、帯域幅、実行可能サイズ）を費やします。「いくつかの特定のシステムに」移植されたソフトウェアはなく、移植されたソフトウェアのみであるという格言を覚えておいてください。