Почему операционная система "Исполняемые файлы" зависит от операционной системы?

Я понимаю, что каждый процессор/архитектура имеет собственный набор команд, поэтому программа (двоичная), написанная для конкретного процессора, не может работать на другом. Но я действительно не понимаю, почему исполняемый файл (например, двоичный, например .exe) не может работать в Linux, но может работать на окнах даже на той же машине.

Это основной вопрос, и ответ, который я ожидаю, заключается в том, что .exe и другие двоичные форматы, вероятно, не являются машинными инструкциями, но содержат некоторые данные, зависящие от операционной системы. Если это так, то каковы данные, зависящие от ОС? и в качестве примера, каков формат файла .exe и разница между ним и исполняемыми файлами Linux?

Есть ли источник, который может получить краткую и подробную информацию об этом?

Ответ 1

Чтобы сделать что-то значимое, приложениям необходимо будет взаимодействовать с ОС. Так как системные вызовы и инфраструктура пользовательского пространства выглядят принципиально иными в Windows и Unix/Linux, наличие различных форматов для исполняемых программ - самая маленькая проблема. Это логика программы, которая должна быть изменена.

(Вы можете утверждать, что это бессмысленно, если у вас есть программа, которая зависит исключительно от стандартизованных компонентов, например библиотеки времени выполнения C. Это теоретически справедливо, но не имеет отношения к большинству приложений, поскольку они вынуждены использовать зависимые от ОС материалы).

Другие различия между файлами Windows PE (EXE, DLL,..) и Linux ELF связаны с различными загрузчиками изображений и некоторыми конструктивными характеристиками обеих ОС, Например, в Linux отдельная программа используется для разрешения импорта внешних библиотек, тогда как эта функция встроена в Windows. Другой пример: общие библиотеки Linux работают иначе, чем библиотеки DLL в Windows. Не говоря уже о том, что оба формата оптимизированы, чтобы позволить соответствующим ядрам ОС загружать программы как можно быстрее.

Эмуляторы, такие как Wine, пытаются заполнить пробел (и на самом деле доказывают, что самая большая проблема - не двоичный формат, а скорее интерфейс ОС!).

Ответ 2

.exe и другие двоичные форматы [определенно] не являются машинными инструкциями, но содержат некоторые данные, зависящие от операционной системы.

что такое данные, зависящие от ОС? и в качестве примера, каков формат файла .exe и разница между ним и исполняемыми файлами Linux?

Ну, я думаю, Google не смог вам полностью..EXE очень хорошо определены в документации Windows.

http://support.microsoft.com/kb/65122

Приложение Linux ld загружает исполняемый файл в память до "exec" в этот файл. Вы можете прочитать в формате ld или даже знаменитый a.out файл.

http://linux.die.net/man/1/ld

http://en.wikipedia.org/wiki/A.out

http://en.wikipedia.org/wiki/Executable

Ответ 3

Очень наивный ответ:

Их структура отличается от разных загрузчиков процессов;
Использование os-зависимых функций, таких как syscalls, которые зависят от ОС и ОС.

Ответ 4

Помимо исполняемого формата, который должен быть распознан системным загрузчиком (т.е. той частью ОС, которая приносит исполняемый файл в память), реальной проблемой является интерфейс к ОС. Вы можете представить себе ОС как своего рода API, который предоставляет точки входа, которые нужно вызвать для выполнения определенных действий, например, для записи символа на консоль.

Эти данные обычно более или менее скрыты от конечного пользователя, так что вы можете добиться написания символа на экране с тем же исходным кодом на языках более высокого уровня. Но часто все происходит иначе, например, в среде Windowing. Не все языки высокого уровня обеспечивают слой окон, который абстрагирует даже эти различия.

Ответ 5

Я не могу комментировать слишком много на * nix, но да, часть кода двоичного файла, как правило, счастлива работать в любой среде, но именно ОС задает определенные требования к двоичному. В окнах вы должны прочитать заголовки PE.

Вторая часть - это просто разработчик, много раз часть кода будет ссылаться на библиотеки, специфичные для ОС, поэтому вы можете иметь как переносимый, так и не переносимый код на С++ перед компиляцией в двоичный файл.

Ответ 6

Программы должны знать, как вызывать службы операционной системы. Как это делается, зависит от операционной системы: некоторые используют прерывания, некоторые используют инструкцию x86 lcall, некоторые (особенно Windows) выделяют разделяемые библиотеки и не документируют, как напрямую обращаться к службам. Старые 680x0 Mac и некоторые другие операционные системы 680x0 использовали зарезервированную область набора команд и захватили исключение "неправильного кода CPU". Более того, даже когда механизм одинаков, порядок и формат аргумента системных вызовов различаются между операционными системами (а иногда и разными версиями одной и той же операционной системы, см. stat() в ядре Linux на примере интерфейса, который изменился несколько раз).

Существует некоторая способность справляться с соглашениями других операционных систем: FreeBSD имеет "linuxulator", который обрабатывает интерфейс ядра Linux, у NetBSD аналогично есть эмуляторы для форматов системных вызовов других операционных систем с использованием того же оборудования (скажем, Ultrix на MIPS или OSF/1 на Alpha), Linux использовал iBCS2 для обработки интерфейса UnixWare/SCO Unix, Wine предоставляет замененные совместно используемые библиотеки и бинарный загрузчик для исполняемых файлов Windows PE. (Я не помню, что Wine также поддерживает LX .exe s в стиле OS/2, он, вероятно, обрабатывает исходный формат .exe, а затем там .com, который является дампом необработанных дат с заголовком, наложенным на.) Несмотря на это, всегда есть формат, который использует разные соглашения, и иногда соглашения достаточно похожи, чтобы требовать от ОС подсказки о том, как с этим бороться. (См. bless на FreeBSD, например.)

Ответ 7

Часто программа будет вызывать различные API в Windows, пытаясь не "повторно изобретать колесо" каждый раз.

Надеемся, что другие операционные системы содержат API-методы, позволяющие программе также вызывать их функциональность. Хотя я не знаю. Я ПК.:)

Очевидно, что такие API не будут определены при работе на одном компьютере под другой ОС.