Neden “şişman ikili dosyalar” platformlar arası uygulamalar için daha yaygın kullanılmıyor?

Bildiğim kadarıyla, sözde "şişman ikili dosyalar" - birden fazla sistem için makine kodu içeren çalıştırılabilir dosyalar - yalnızca Apple PC'lerde gerçekten kullanılıyor ve hatta bunlar, yalnızca onları kullanmaları gerektiği için kullanmış görünüyorlar. PowerPC'den x86'ya.

Bu günlerde pek çok yazılım çapraz platformdur ve tek bir yağ ikiliyi yapmak, bir şekilde aktarmadan bahsetmek yerine, işletim sisteminin ve mimarinin her bir kombinasyonu için bir düzine kadar farklı indirme işlemini takip etmekten daha kolay olacak gibi görünmektedir. müşteriye istediklerini.

Örneğin, bu yaklaşımın neden yakalanmadığına dair birçok tahmin yapabilirim, örneğin:

• Çoklu işletim sistemi ikili dosyalarını olanaksız kılan çapraz derleme araçlarının eksikliği
• Yine de her işletim sistemindeki kodu test etmeniz gerekir, bu nedenle zaten her işletim sistemi için yerel olarak derleyebilecek sistemlere sahip olmanız gerekir.
• Görünüşe göre 32 bit programlar zaten 64 bit makinelerde "sadece çalışıyor"
• Dinamik bağlantı, her işletim sisteminde farklı şekilde çalışır, bu nedenle bir "şişman uygulaması" olsa bile "şişman kitaplığı" çalışmayabilir

Ancak her zaman işletim sistemine özgü ve mimariye özgü tüm ayrıntıları benden gizleyen bir kütüphane veya çerçeve ile çalıştığım için, bunların gerçekten ne kadar doğru olduğunu bilmiyorum ya da bilmediğim daha fazla sorun varsa hakkında. Peki, şişman ikili dosyaların genellikle çoklu mimari ve / veya çoklu işletim sistemi yazılımı oluşturmak için kullanılmamasının asıl nedenleri nelerdir? (Apple dışında)

Bir yağ ikili yaklaşımı eğer en mantıklı:

1. Her iki mimaride aynı sistemde bir arada var
2. Her şey tüm mimariler için aşağı yukarı aynıdır

Bu yüzden platformlar arası kod için kullanılmazlar (her iki kriter de geçerli değildir) veya bir Linux ile farklı Linux dağıtımlarını desteklemek için kullanılmaz (1. geçerli değildir, 2. belirli bir dereceye uygulanır).

Linux'ta, tek bir Linux dağıtımında hem 32 hem de 64 bit'i desteklemek istiyorsanız, her iki kriter de geçerli olacaktır . Peki, zaten zaten birden fazla dağıtımı desteklemek zorundaysanız, neden canınızı sıkıyor?

On Windows'un 16 bit 32 bit geçiş birçok bakımdan 16 bit Windows dünyadan büyük sapmayı (sanal bellek, çok kullanıcılı erişim kontrolü, API değişiklikleri ...) idi, Windows NT, tanıtımıyla başlangıçta oldu. Tüm bu değişikliklerle, 32 ve 16 bit dünyalarını ayrı tutmak daha iyiydi. NT'nin zaten "alt sistemler" kavramı farklı işletim sistemi "personae" (Win32, POSIX) destekliyordu, bu yüzden Win16'yı üçüncü bir alt sistem yapmak basit bir seçimdi.

Win32-Win64 geçişi benzer büyük değişiklikler içermiyordu, ancak Microsoft muhtemelen kanıtlanmış ve denenmiş olduğu için yine de benzer bir yaklaşım kullandı.

İnternet çağındaki dağıtım lojistiği, yağ ikililerini iki şekilde engellemektedir:

1. Satış noktası fiziki malları kapsamamaktadır ve bu nedenle ürünlerin perakende raf alanı için rekabet ettiği ve müşterilerin satın alma yapmak için sınırlı fırsatları olduğu durumlarda daha az SKU'yu tercih etmektedir.

2. Bant genişliği maliyetleri, belirli bir yazılım paketi için yalnızca gerekli minimum bitleri sağlamanızı sağlar. Kablodan aşağıya doğru bir ikili veri göndermek, hem müşteri deneyimini hem de satıcı altyapı verimliliğini düşürür.

Yağ ikili dosyaları, yazılımın fiziksel olarak sarıldığı büzülünce daha anlamlı hale geldi.

Yağ ikili dosyalarının başarılı olmama nedenlerinin bir kısmı, ikili bir yürütülebilir dosyayı geçersiz kılmak için ABI ve işlemci (aslında, komut seti ) özelliklerinden daha fazlasının mevcut olmasıdır . Bir ikili çalıştırılabilir dosya genellikle diğer kaynaklara, özellikle dinamik kitaplıklara ( DLL cehennemine bakın ), dış hizmetlere ( PostGreSQL gibi DBMS'yi düşünün …), sistem yapılandırmasına (örneğin /etc/, Linux altında yapılandırma dosyalarının konumu ) vb. . vb....

Sadece Linux için / uygulamada zordur X86-64 (genellikle belirli versiyonlarına bağlı olduğu için her Linux dağıtımları üzerinde çalıştırmak için ikili yürütülebilir mümkün hale getirmek için libcya libstdc++). FatELF var ancak çok başarılı değil.

İyi tanımlanmış bir ABI ve komut seti ile bile, optimizasyon çeşitli işlemci markalarında farklı olacaktır - bkz . GCC'nin -mtune=native x86 optimizasyon bayrağı .

Apple kısmen, yalnızca bilişim kaynakları için çok kapalı bir eko-sistem sağladıkları için şişman ikili dosyalara sahip olmayı başardı.

Özgür yazılım , taşınabilirlik konusundaki endişenizi çözmenin başka bir yoludur: Eğer bir uygulama özgür yazılım ise (taşınabilirlik için dikkatlice kodlanmış), benzer sistemlere kolayca taşınabilir. Orijinal kaynak kodu sisteminizde belirtilen şekilde çalışmıyorsa bile, genellikle makul bir şekilde (elbette, belirli bir işletim sistemine veya ABI'ye bağlı ücretsiz bir yazılımı veya işlemciyi kullanmak kolay değildir) uyarlayabilirsiniz (ya da işi yapacak birine para ödersiniz). liman, bunun için daha fazla çaba göstereceksiniz). Ayrıca POSIX veya Linux Standard Base gibi standartlar da yardımcı olmaktadır.

^{Birine bazı (özgür) yazılımları kaynak koduyla taşımalarını ödeyebilir (veya isteyebilirsiniz), ancak bir ikili çalıştırılabilir dosyayı taşımak gerçekçi değildir.}

Sonunda, çeşitli işletim sistemlerinde (kaynak kodunun mevcut olması koşuluyla) taşınmasına yardımcı olmak için çeşitli çerçeveler vardır, örneğin Qt & POCO .

JVM gibi iyi tanımlanmış bir bytecode kullanmak bile her zaman taşınabilirliğin garantisi değildir: Bazı Java uygulamalarının taşınabilir olmadıkları bilinmektedir (örneğin, belirli bir dosya hiyerarşisi ve adlandırma bekledikleri için).

BTW, bilgisayar sistemleri muhtemelen bugün 1980'lerde veya 1990'ların başında (ya da ana bilgisayar çağında) olduğundan çok daha az heterojendir.

Sonunda, şişman ikili dosyalar şişmandır: çok fazla insanı ilgilendirmeyecek bir taşınabilirlik sorunu için çok fazla kaynak harcayacaksınız (zaman, bant genişliği, çalıştırılabilir boyut). Aforizmayı hatırlayın: "taşınabilir bir yazılım yoktur, yalnızca taşınan yazılım" (bazı belirli sistemlere).