С точки зрения скомпилированного кода, в чем разница между программой, скомпилированной для одной ОС против другой (например, Linux против Windows). Разве программа не запускается непосредственно на процессоре? Или это потому, что программа должна ссылаться на конкретные библиотеки ОС?
Обычные скомпилированные программы «запускаются напрямую» на процессоре, но программа не запускается в вакууме:
Многие программы используют внешние динамически загружаемые библиотеки ( DLLsили .soбиблиотеки). Способ их связывания зависит от компилятора / компоновщика, и каждая ОС имеет свои стандарты. Однако существуют также «статически связанные» программы, которые предоставляют весь собственный код.
Современная ОС не дает полного контроля над работающей программой. Программы полагаются на «системные вызовы» для ввода-вывода, доступа к оборудованию и таким вещам, как сигналы и переход в спящий режим. Доступные сервисы и интерфейс определяются ОС. ОС также контролирует, какие части системы (память, регистры, прерывания) программе разрешено использовать.
Программа с графическим интерфейсом также должна работать в графической среде пользователя, чтобы рисовать себя на экране. Но вы, наверное, уже думали об этом.
По этим причинам независимые от ОС приложения должны полагаться на какую-то «виртуальную машину», подобную той, которая предоставляется средой выполнения Java. Важно отметить, что виртуальная машина предоставляет стандартный интерфейс для ресурсов ОС (ввод-вывод, сигналы и т. Д.). Конечно, Java или Python также интерпретируют «байт-код» вместо того, чтобы иметь дело с особенностями набора команд Intel; но это другая история.
Разные ОС также имеют разную функциональность. В Windows есть порты завершения ввода / вывода, в Linux нет. У FreeBSD есть kqueue, у Linux нет. У Linux есть фьютексы, у Windows нет. У них также есть разные способы сделать одно и то же - какие параметры вы передаете, чтобы открыть файл? В каком порядке они идут? Как конкретно вы вызываете функцию операционной системы "открыть файл"?
источник
Как правило, программы несовместимы из-за различий в их двоичном интерфейсе приложения (ABI) .
НЕТ ! Это задача операционной системы - предотвращать запуск приложений «непосредственно» на процессоре. Как правило, на самом низком уровне (то есть на том, на котором построен API-интерфейс ОС) приложение взаимодействует с ядром операционной системы .
Да . Многие библиотеки ОС написаны для облегчения взаимодействия с самой операционной системой, но столько же написано для кроссплатформенности. Они скрывают низкоуровневый интерфейс ОС от разработчика и предполагают, что скомпилированная версия для этой ОС будет доступна во время выполнения (см. Ниже).
Хотя библиотеки могут быть написаны в кросс-платформенных образом, при компиляции они не могут работать кросс-платформенный. Их по-прежнему необходимо перекомпилировать для конкретной целевой операционной системы, чтобы снова использовать конкретные базовые компоненты операционной системы (ядра).
Наконец, сами исполняемые файлы часто содержат очень специфичные двоичные заголовки загрузки и т. Д. (Например, формат исполняемого файла PE [.exe, .dll и т. Д.] Для Windows или ELF для Linux [нет, .o, .so , так далее...]). Они также могут включать в себя код для загрузки скомпилированных специфичных для ОС двоичных файлов для конкретной библиотеки программного обеспечения.
Наконец, с точки зрения программиста: соглашение о вызовах . Скомпилированный код передает переменные функциям заданным образом (т.е. через регистры или в стеке) в очень определенном порядке. Даже в этом случае необходимо также договориться о том, кто отвечает за «очистку» вызовов функций (вызывающий или вызываемый?). Хотя существует несколько стандартных и широко используемых соглашений о вызовах x86 , некоторые из них могут не поддерживаться определенными операционными системами (это является частью ABI).
источник