Чому "жирові бінарні файли" більше не використовуються для міжплатформних додатків?

Наскільки я знаю, так звані "жирові файли" - виконувані файли, що містять машинний код для декількох систем - реально використовуються лише на комп'ютерах Apple, і навіть там здається, що вони використовували їх лише тому, що їм потрібно було перейти з PowerPC до x86.

В наші дні багато програмного забезпечення є крос-платформним, і, схоже, зробити єдиний жирний бінарний файл буде багато в чому простіше, ніж відслідковувати десяток чи більше різних завантажень для кожної комбінації операційної системи та архітектури, не кажучи вже про те, щоб якось передавати замовнику, якого вони хочуть.

Я можу придумати чимало здогадок щодо того, чому такий підхід ніколи не натрапляв, наприклад:

• Відсутність засобів перехресної компіляції, що робить бінарні файли з декількома ОС нездійсненними
• У будь-якому випадку вам потрібно перевірити код на кожній ОС, тому вам вже доведеться мати системи, які зможуть компілюватись для кожної ОС
• Мабуть, 32-бітні програми "просто працюють" на 64-бітних машинах
• Динамічне підключення працює по-різному в кожній ОС, тому "бібліотека жирів" може не працювати, навіть якщо "жирна програма"

Але оскільки я завжди працюю з бібліотекою або рамкою, яка приховує від мене всі ці специфічні для ОС та архітектури деталі, я не знаю, наскільки насправді це є щось, або якщо є ще більше проблем, яких я не знаю о. Отже, які фактичні причини, чому жирові файли зазвичай не використовуються для створення програмного забезпечення для багатьох архітектур та / або програмного забезпечення для багатьох ОС? (за межами Apple)

Бінарний підхід жиру має найбільш сенс, якщо:

1. Обидві архітектури співіснують в одній системі
2. Все інше більш-менш однакове для всіх архітектур

Ось чому вони не використовуються для крос-платформного коду (обидва критерії не застосовуються) або для підтримки різних дистрибутивів Linux одним бінарним (1. не застосовується, 2. застосовується до певної міри).

В Linux обидва критерії все ще застосовуються, якщо ви хочете підтримувати і 32, і 64 біт в одному дистрибутиві Linux . Але навіщо турбуватися, якщо вам вже доведеться підтримувати кілька дистрибутивів?

У Windows перехід від 16-ти до 32-ти бітових відбувся спочатку з впровадженням Windows NT, що багато в чому було великим відхиленням від 16-бітного світу Windows (віртуальна пам'ять, багатокористувацький контроль доступу, зміни API ...). З усіма цими змінами краще було тримати роздільний 32 і 16 бітовий світи. У NT вже було поняття "підсистеми", що підтримують різні ОС "персони" (Win32, POSIX), тому перетворення Win16 в третю підсистему було прямим вибором.

Перехід Win32 до Win64 не передбачав подібних істотних змін, але Microsoft все-таки застосував подібний підхід, ймовірно, тому, що це було перевірено та випробувано.

Логістика Інтернет-розподілу віків десенсивізує жирові камери двома способами:

1. Торговельний пункт не передбачає фізичних товарів, а тому надає перевагу меншій кількості товарних позицій, як це відбувається у випадку, коли продукція конкурує за роздрібні торгові площі, а клієнти мають обмежені можливості зробити покупку.

2. Витрати на пропускну здатність сприяють доставці мінімально необхідних бітів для певного програмного пакету. Перевезення жирного двійкового по дроту знижує як клієнтський досвід, так і ефективність інфраструктури продавця.

Жирові бінарні файли мали більше сенсу, коли програмне забезпечення було згорнуте фізичними носіями.

Частина причин, через які жирові файли не досягли успіху, полягає в тому, що існує більше, ніж специфікації ABI та процесора (власне, набір інструкцій ) для недійсності бінарного виконуваного файлу. Бінарний виконуваний файл часто багато залежить від інших ресурсів, зокрема динамічних бібліотек (див. Пекло DLL ), зовнішніх служб (подумайте про СУБД, як PostGreSQL ....), конфігурації системи (наприклад, розташування файлів конфігурації в /etc/Linux) тощо тощо.

Тільки для Linux / x86-64 на практиці складно зробити бінарний виконуваний файл, який може працювати на всіх дистрибутивах Linux (оскільки він часто прив’язаний до конкретних версій libcабо з libstdc++). FatELF існує, але не дуже успішний.

Навіть за умови чітко визначеного ABI та набору інструкцій, оптимізація була б різною для різних марок процесорів - дивіться прапор -mtune=native оптимізації x86 GCC .

Apple частково досягла успіху в жирових кормах лише тому, що вони забезпечують дуже закриту екосистему обчислювальних ресурсів.

Вільне програмне забезпечення - це ще один спосіб вирішити проблему з портативністю. Якщо програма - це вільне програмне забезпечення (ретельно кодується для портативності), воно досить легко переноситься на подібні системи. І навіть якщо оригінальний вихідний код працює не так, як призначено у вашій системі, ви можете адаптувати його (або заплатити комусь, щоб виконати роботу), як правило, досить легко (звичайно, безкоштовне програмне забезпечення, пов'язане з конкретною ОС або ABI або процесором, нелегко порт, ви докладете більше зусиль для цього). І такі стандарти, як POSIX або Linux Standard Base, також допомагають.

^{Ви можете заплатити (або попросити) когось портувати якесь (безкоштовне) програмне забезпечення з наявним вихідним кодом, але портувати бінарний виконуваний файл нереально.}

Нарешті, існує декілька фреймворків, які допомагають переносити декілька операційних систем (за умови наявності вихідного коду), наприклад Qt & POCO .

Навіть використання добре визначеного байтового коду, як-от JVM , не завжди є гарантією портативності: добре відомо, що деякі додатки Java не є портативними (наприклад, тому, що вони очікують певної ієрархії файлів та імен).

До речі, комп’ютерні системи, ймовірно, набагато менш неоднорідні сьогодні, ніж у 1980-ті або на початку 1990-х (або в епоху мейнфрейму).

Нарешті, жирові файли - це жир: ви витратите багато ресурсів (час побудови, пропускну здатність, розмір виконуваного файлу) на проблему переносимості, яка може не стосуватися багатьох людей. Пам’ятайте про афоризм: «портативного програмного забезпечення немає, лише програмне забезпечення, яке було перенесено» (для деяких конкретних систем).