Нет, и во многих случаях исполняемый файл не может работать даже в той же ОС другой версии из-за изменений в ядро.
Простой пример, с которым я столкнулся на днях: команда dmesg
в OpenBSD выводит буфер системных сообщений, куда поступают все сообщения ядра (информация о загрузке и т. Д.). Я недавно перекомпилировал ядро, и внезапно dmesg
возвращался с сообщением
dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory
Это произошло из-за того, что не перекомпилировали утилиты пользовательского уровня, и dmesg
, хотя и «работал» в ощущение, что исполняемый файл был распознан как таковой, не мог выполнить свою задачу (из-за изменений в коде ядра).
Таким образом, dmesg
из предыдущей версии не будет «работать» в более поздних версиях ОС.
РЕДАКТИРОВАТЬ (из комментариев, с дополнениями)
Считайте системные вызовы ядра API. Что будет означать для API, если его нельзя будет изменить или если потребуется постоянно поддерживать совместимость с предыдущими версиями? Это не недостаток дизайна, это принцип работы программного обеспечения в целом.
Нельзя ожидать, что код, скомпилированный для одной версии API, будет работать с любой другой версией этого API. Как разработчик API / ядра вас больше беспокоит нарушение обратной совместимости, чем добавление и улучшение операционной системы.
К счастью, большая часть программного обеспечения в системах Unix разработана в соответствии со стандартом POSIX, что означает, что исходный код исполняемого файла может передаваться между типами системы и может компилироваться и запускаться практически где угодно. Проблема двоичной совместимости между платформами Unix становится проблемой только тогда, когда требуются