Mengapa "binary gemuk" tidak lebih banyak digunakan untuk aplikasi lintas platform?

Sejauh yang saya tahu, apa yang disebut "fat binaries" - file yang dapat dieksekusi yang berisi kode mesin untuk beberapa sistem - hanya benar-benar digunakan pada PC Apple, dan bahkan di sana sepertinya mereka hanya menggunakannya karena mereka perlu beralih dari PowerPC ke x86.

Saat ini banyak perangkat lunak yang bersifat cross-platform, dan sepertinya membuat satu biner gemuk akan lebih mudah daripada melacak selusin unduhan yang berbeda untuk setiap kombinasi sistem operasi dan arsitektur, belum lagi dengan cara apa pun menyampaikan ke pelanggan mana yang mereka inginkan.

Saya bisa membuat banyak dugaan mengapa pendekatan ini tidak pernah berhasil, misalnya:

• Kurangnya alat kompilasi silang membuat binari multi-OS tidak layak
• Anda harus menguji kode pada setiap OS, jadi Anda harus memiliki sistem yang dapat mengkompilasi secara native untuk setiap OS
• Rupanya program 32-bit "hanya berfungsi" pada mesin 64-bit
• Tautan dinamis berfungsi berbeda pada setiap OS, jadi "pustaka gemuk" mungkin tidak berfungsi bahkan jika "aplikasi gemuk" akan melakukannya

Tetapi karena saya selalu bekerja dengan perpustakaan atau kerangka kerja yang menyembunyikan semua detail khusus OS dan arsitektur ini dari saya, saya tidak tahu seberapa benar semua itu, atau jika ada lebih banyak masalah yang saya tidak tahu tentang. Jadi, apa alasan sebenarnya mengapa binary gemuk umumnya tidak digunakan untuk membuat perangkat lunak multi-arsitektur dan / atau multi-OS? (di luar Apple)

Pendekatan biner lemak paling masuk akal jika:

1. Kedua arsitektur hidup berdampingan pada sistem yang sama
2. Segala sesuatu yang lain kurang lebih sama untuk semua arsitektur

Itu sebabnya mereka tidak digunakan untuk kode lintas platform (kedua kriteria tidak berlaku), atau untuk mendukung distribusi Linux yang berbeda dengan satu biner (1. tidak berlaku, 2. berlaku pada tingkat tertentu).

Di Linux, kedua kriteria akan tetap berlaku jika Anda ingin mendukung 32 dan 64 bit pada satu distribusi Linux . Tetapi mengapa repot, jika Anda sudah harus mendukung banyak distribusi?

Di Windows , transisi dari 16 bit ke 32 bit awalnya terjadi dengan diperkenalkannya Windows NT, yang merupakan penyimpangan utama dari dunia 16 bit Windows dalam banyak hal (memori virtual, kontrol akses multi-pengguna, perubahan API ...). Dengan semua perubahan ini, lebih baik memisahkan dunia 32 dan 16 bit. NT sudah memiliki konsep "subsistem" yang mendukung berbagai OS "personae" (Win32, POSIX), sehingga menjadikan Win16 sebagai subsistem ketiga adalah pilihan yang mudah.

Transisi Win32 ke Win64 tidak melibatkan perubahan besar yang serupa, tetapi Microsoft tetap menggunakan pendekatan yang serupa, mungkin karena terbukti dan dicoba.

Logistik distribusi usia internet melemahkan binari gemuk dengan dua cara:

1. Titik penjualan tidak melibatkan barang fisik dan oleh karena itu mendukung lebih sedikit SKU seperti halnya ketika produk bersaing untuk ruang rak ritel dan pelanggan memiliki kesempatan terbatas untuk melakukan pembelian.

2. Biaya bandwidth hanya memberikan bit minimum yang diperlukan untuk paket perangkat lunak tertentu. Mengirimkan biner besar ke server mengurangi pengalaman pelanggan dan efisiensi infrastruktur penjual.

Binari gemuk lebih masuk akal ketika perangkat lunak dibungkus dengan media fisik.

Salah satu alasan mengapa biner gemuk tidak berhasil adalah bahwa ada lebih dari spesifikasi ABI & prosesor (sebenarnya, set instruksi ) untuk membatalkan validitas biner yang dapat dieksekusi. File biner yang dapat dieksekusi seringkali sangat tergantung pada sumber daya lain, khususnya perpustakaan dinamis (lihat neraka DLL ), layanan eksternal (pikirkan DBMS seperti PostGreSQL ....), konfigurasi sistem (mis. Lokasi file konfigurasi /etc/di Linux,), dll. dll ...

Hanya untuk Linux / x86-64 dalam praktiknya sulit untuk membuat biner yang dapat dieksekusi dapat berjalan pada setiap distribusi Linux (karena sering dikaitkan dengan versi tertentu libcatau dari libstdc++). FatELF ada tetapi tidak terlalu berhasil.

Bahkan dengan ABI dan set instruksi yang terdefinisi dengan baik, optimisasi akan berbeda pada berbagai merek prosesor - lihat flag -mtune=native optimasi x86 dari GCC .

Apple sebagian berhasil memiliki binari yang gemuk hanya karena mereka menyediakan sistem sumber daya komputasi yang sangat tertutup.

Perangkat lunak bebas adalah cara lain untuk menyelesaikan masalah portabilitas Anda: Jika suatu aplikasi adalah perangkat lunak bebas (dikodekan dengan hati-hati untuk portabilitas), ia dapat dengan mudah dipindahkan ke sistem yang serupa. Dan bahkan jika kode sumber asli tidak berfungsi sebagaimana dimaksud pada sistem Anda, Anda dapat mengadaptasinya (atau membayar seseorang untuk melakukan pekerjaan itu) biasanya dengan mudah (tentu saja, perangkat lunak bebas yang terikat pada OS atau ABI atau prosesor tertentu tidak mudah port, Anda akan membayar lebih banyak upaya untuk itu). Dan standar seperti POSIX atau Linux Standard Base juga membantu.

^{Anda dapat membayar (atau meminta) seseorang untuk mem-porting beberapa perangkat lunak (gratis) dengan kode sumber yang tersedia, tetapi tidak realistis untuk mem-porter biner yang dapat dieksekusi.}

Akhirnya, ada beberapa kerangka kerja untuk membantu porting pada beberapa sistem operasi (disediakan kode sumber tersedia), misalnya Qt & POCO .

Bahkan menggunakan bytecode yang ditentukan dengan baik seperti JVM tidak selalu merupakan jaminan portabilitas: beberapa aplikasi Java diketahui tidak portabel (misalnya karena mereka mengharapkan beberapa hierarki dan penamaan file tertentu).

BTW, sistem komputer mungkin jauh kurang heterogen saat ini daripada pada 1980-an atau awal 1990-an (atau di era mainframe).

Akhirnya, binari gemuk adalah gemuk: Anda akan menghabiskan banyak sumber daya (waktu pembuatan, bandwidth, ukuran yang dapat dieksekusi) untuk masalah portabilitas yang mungkin tidak menjadi perhatian banyak orang. Ingat pepatah: "tidak ada perangkat lunak portabel, hanya perangkat lunak yang telah diangkut" (ke beberapa sistem tertentu).