Может ли исполняемый файл x86 работать на любой платформе x86 при наличии нужных библиотек времени выполнения?
Хотя я нашел похожие вопросы, они на самом деле не ответили на этот конкретный вопрос.
Может ли скомпилированный исполняемый файл x86 запускаться на любой платформе x86 при наличии нужных библиотек времени выполнения?
Скажем, я делаю программу на C ++ 17 без зависимостей, Могу ли я запустить эту программу в Windows 95 или какая-то поддержка требуется для ОС?
Я также слышал, что RTTI (в случае C ++) может поддерживаться не везде, только потому, что процессор должен поддерживать эту функцию, или ОС играет в этом роль? Это будет означать, что новые функции могут не поддерживаться, например, Windows 95.
редактировать
Я хочу узнать, может ли исполняемый файл (например, x86) работать на любой платформе, поддерживающей этот набор команд, или же некоторые функции, такие как RTTI, нуждаются в конкретной поддержке ОС и, следовательно, доступны не на всех платформах, поддерживающих этот набор команд.
Решение
В общем ты не можешь, даже если вы ограничиваете свою вселенную аппаратным обеспечением x86 — по крайней мере, без какого-либо преобразования двоичного файла или некоторого «загрузчика» для конкретной платформы для каждой целевой платформы.
Например, типичный двоичный файл, испускаемый компилятором C или C ++1 будет иметь некоторую минимальную зависимость от ОС и времени выполнения, например, для загрузки и выполнения связывания во время выполнения на исполняемом файле. Разные платформы имеют разные двоичные форматы (например, PE / COFF на Windows или же ELF в различных версиях UNIX и Linux), и не существует какого-либо распространенного «формата x86», который бы работал непосредственно на любой платформе.
Кроме того, любая нетривиальная программа и во многих случаях любой Программа, тривиальная или нет, будет зависеть от платформы для среды выполнения langauge. Например, даже пустой main() функция часто требует поддержки во время выполнения, чтобы перейти от определяемого операционной системой метода start к методу main, и без необычных опций сборки при запуске часто возникают вызовы для инициализации частей стандартной библиотеки.
Наконец, как вы уже упоминали в своем комментарии о RTTI, различные функции языка или платформы могут быть по существу скомпилированы в двоичный файл и требуют поддержки ОС. RTTI, вероятно, не очевидно попадают в эту категорию, но такие вещи, как независимый от позиции код, локальное хранилище потоков и поддержка разматывания стека для обработки исключений, часто делают. Скомпилированный код x86, который использует такие функции, может быть достаточно разный на разных платформах, так как нужно строить предположения о том, как они работают.
В принципе, однако, вы могли бы представить это работает, по крайней мере, для некоторого ограниченного набора программ. Например, хотя различные исполняемые форматы на практике несовместимы, они не тот разные и инструменты существуют конвертировать между ними. Таким образом, вы, безусловно, могли бы реализовать минимальное время выполнения на интересующей вашей платформе, которое берет исполняемый файл x86, скомпилированный в любой фиксированный формат, который вы выберете, преобразует во время выполнения в локальный формат и запускает его.
Помимо этого, на самом деле попытка отобразить даже стандартные вызовы библиотеки будет довольно сложной, поскольку разные операционные системы используют разные соглашения о вызовах, но это может быть возможно для функций «C», использующих некоторые thunks, чтобы поместить вещи в правильное место. C ++ в значительной степени прав, потому что ABI там гораздо более сложный, специфичный для компилятора и платформы, и большая часть деталей реализации уже встроена для вещей, реализованных в заголовках.
Фактически, идея о том, что (подмножество) x86 может обеспечить интересный промежуточный язык для кроссплатформенного исполнения, является именно той идеей, которая используется в Google [проект NaCl]. По сути, среда выполнения NaCl обеспечивает независимые от платформы возможности «загрузки», которые позволяют коду x86 более или менее естественным образом работать на различных платформах. Впоследствии были добавлены другие нативные форматы, такие как ARM, но они начинались как песочница x86. Большая часть проекта посвящена запуску кода, который доказуемо безопасен (то есть, помещен в песочницу), но он показывает, что с некоторой инфраструктурой вы можете написать «переносимый» x86. Однако стандартный компилятор C или C ++ не собирается напрямую генерировать код, совместимый с NaCl.
1 В самом деле, любой компилятор, который компилируется в собственный формат. Я просто называю C и C ++, поскольку они кажутся вам интересными и широко знакомы.
Другие решения
Этот вопрос не имеет смысла. C ++ — это, прежде всего, язык для описания поведение компьютерной программы.
Использование компилятора для создания собственного двоичного исполняемого файла производить такое поведение на реальном компьютере является типичным способом использования языка.
Как только у вас есть бинарный файл, все следы исходного кода, использованного для его создания, исчезают (если вы не создали специальную версию для целей отладки). Совместимость бинарного файла с конкретным оборудованием или операционными системами выходит за рамки самого C ++.
То же самое верно для C или любого другого языка программирования, который обычно компилируется в собственный двоичный код.
Или, чтобы ответить на вопрос более кратко:
Может ли скомпилированный код C ++ / C (то есть исполняемый файл) выполняться где-нибудь при наличии правильных библиотек времени выполнения?
Нет.
Может ли скомпилированный исполняемый файл x86 запускаться где-нибудь при наличии правильных библиотек времени выполнения?
Нет, он будет работать только на оборудовании x86 или другом оборудовании (или программном обеспечении, таком как виртуальная машина), которое эмулирует набор команд x86 (например, процессор x64). На практике это очень далеко от «где угодно».
И даже если оборудование соответствует, исполняемый файл x86 будет зависеть от операционной системы. Бинарный файл Windows не будет работать в Linux, даже если аппаратное обеспечение будет таким же. Существуют различные стратегии, которые могут заставить подобные вещи «работать» в некоторых ситуациях, Microsoft Подсистема Linux для Windows один недавний пример, который позволяет бинарным файлам Linux работать в Windows без изменений. Опять жаркий крик «откуда угодно».