Відповіді:
Звичайні компільовані програми "запускаються безпосередньо" на процесорі, але програма не працює у вакуумі:
Багато програм покладаються на зовнішні, динамічно завантажені бібліотеки ( DLLsабо .soбібліотеки). Спосіб їх з'єднання - це компілятор / лінкер, і кожна ОС має різні стандарти. Однак є також "статично пов'язані" програми, які надають весь власний код.
Сучасна ОС не дає повного контролю за комп’ютером запущеній програмі. Програми покладаються на "системні дзвінки" для вводу-виводу, доступу до обладнання та таких речей, як сигнали та перехід у стан сну. Наявні послуги та інтерфейс визначаються ОС. ОС також контролює, які частини системи (пам'ять, регістри, переривання) програмі дозволено використовувати.
Програма GUI також повинна працювати через графічне середовище користувача, щоб намалювати себе на екрані. Але ви, напевно, вже про це думали.
З цих причин незалежні від ОС програми повинні покладатися на якусь "віртуальну машину", на зразок тієї, яку надає час виконання Java. Важливо, що VM забезпечує стандартний інтерфейс до ресурсів ОС (вводу / виводу, сигнали тощо). Звичайно, java або python також інтерпретують "байт-код" замість того, щоб мати справу з химерністю набору інструкцій Intel; але це вже інша історія.
Різні ОС також мають різні функціональні можливості. У Windows є порти завершення вводу / виводу, Linux - ні. FreeBSD має kqueue, Linux - ні. У Linux є фукси, Windows - ні. Вони також мають різні способи зробити те саме - які параметри ви передаєте, щоб відкрити файл? У якому порядку вони заходять? Як конкретно ви викликаєте функцію "відкрити файл" операційної системи?
В цілому, програми не сумісні через відмінності у застосованому бінарному інтерфейсі (ABI) .
Чи програма не працює безпосередньо на процесорі?
НІ ! Це завдання операційної системи - запобігати запуску програм «безпосередньо» на процесорі. Як правило, на найнижчому рівні (тобто на тому, на якому вбудований API ОС), додаток взаємодіє з ядром операційної системи .
Це тому, що сама складена програма повинна посилатися на певні бібліотеки ОС?
Так . Багато бібліотек ОС написано для полегшення взаємодії з самою операційною системою, але є так само багато таких, які написані для кросплатформної роботи. Вони приховують інтерфейс ОС низького рівня від розробника, і передбачає, що складена версія для цієї ОС буде доступна під час виконання (див. Нижче).
Хоча бібліотеки можна писати міжплатформовим чином, при їх компіляції вони не можуть бути запущені міжплатформенними. Їх ще потрібно перекомпілювати для конкретної цільової операційної системи, щоб знову використовувати окремі базові компоненти операційної системи (ядро).
Яка різниця між складеною програмою для однієї ОС проти іншої?
Нарешті, самі виконувані файли часто містять дуже специфічні бінарні заголовки завантаження та інше (наприклад, формат файлу PE Executable [.exe, .dll тощо)] для Windows або ELF для Linux [none, .o, .so тощо)]). Вони також можуть включати код для завантаження скомпільованих ОС, специфічних для бінарних файлів програмного забезпечення.
Нарешті, з точки зору програміста: угоду про виклик . Скомпільований код передає змінні функціям у заданому порядку (тобто через регістри чи на стек) у дуже конкретному порядку. Вже тоді потрібно також узгодити, хто несе відповідальність за "очищення" функціональних викликів (абонент або абонент?). Хоча існує декілька стандартних і широко використовуваних конвенцій для викликів x86 , деякі можуть не підтримуватися певними операційними системами (це частина ABI).