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

Question

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

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

Есть ли источник, по которому я могу получить краткую и подробную информацию об этом?

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

на что похожи данные, зависящие от ОС? и в качестве примера, каков формат файла .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

Answer 4

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

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

Answer 5

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

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

Answer 6

Программы должны знать, как вызывать службы операционной системы.Как это сделать, зависит от операционной системы: некоторые используют прерывания, некоторые используют инструкцию x86 lcall, некоторые (особенно Windows) имеют выделенные общие библиотеки и не документируют, как напрямую вызывать службы.Старые компьютеры Mac 680x0 и некоторые другие операционные системы 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.)