2015-07-09 2 views
0

Я узнал, что c-компилятор переводит код высокого уровня c в код машинного уровня, что соответствует кодировке команд базового процессора, которая делает этот код компиляции зависимым от процессора. Который я понял. Но почему тогда скомпилированная с программа зависит от ОС. Мой вопрос заключается в том, почему две машины с аналогичным процессором (такое же кодирование команд) с другой ОС не запускают один и тот же скомпилированный файл c, скомпилированный на любой из них. Я понимаю, что LINUX не может запускать WINDOWS .exe и наоборот, и у каждой ОС есть другой механизм системного вызова, но это вещи уровня ОС, почему эти вещи заставляют этот файл на уровне машины (уровня инструкций) зависеть от них.
Пожалуйста, помогите мне ..Почему скомпилированная программа C зависит от ОС

+2

поскольку исполняемые файлы Linux используют двоичный формат ELF, а Windows использует двоичные форматы PE или COFF. поэтому вы уже имеете дело с Coke v.s. Pepsi, прежде чем вы попадете в область системных вызовов. например каков системный вызов на уровне сборки, чтобы вызвать «выход»? LInux и Unix будут использовать разные программные прерывания, имена функций, бла-бла-бла. –

+1

Поскольку программа C должна взаимодействовать с ОС, и у них разные интерфейсы. Нет стандартного интерфейса ОС. В противном случае все они будут * одинаковыми * ОС. –

+0

Кроме того, программа часто использует услуги, предоставляемые ОС. И, как вы можете догадаться, разные ОС, предоставляющие разные сервисы. –

ответ

0

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

Однако, что может сделать программа, не использующая вызовы, специфичные для конкретной ОС, помимо обработки циклов процессора? Например, стандартная библиотека C не может быть реализована без вызовов, специфичных для ОС (например, как бы вы делали malloc или fopen, или даже любые операции ввода-вывода). Поэтому переносная программа не могла использовать какие-либо функции библиотеки, и ОС почти наверняка помешала бы ей напрямую обращаться к аппаратным средствам или к памяти, принадлежащей другим программам (простая ОС, такая как DOS, может быть исключением).

+0

Да, я понимаю, что, предположим, что я хочу, чтобы мой код выполнял ввод/вывод сокетов, мне нужен системный вызов или вызов ОС для этого. Но скажем, что мой скомпилированный код будет просто информировать (используя некоторую инструкцию или флаг) для ОС, что в какой-то момент инструкций мне нужен сокет-в/в, а ОС начнет сокет-ввод/вывод для меня. Теперь, когда механизм «информирования» (инструкция флага) может быть общим для всей ОС, и как обрабатывать этот сокет, происходит или нет, так это то, что бизнес ОС ... не может быть так? – user3690370

+0

@ user3690370 Да, теоретически может быть так, но на практике это не так. Совместимость на уровне исходного кода, например, вы можете использовать стандартные функции POSIX и C и компилировать двоичный файл для большинства ОС с незначительными изменениями или без изменений. Некоторые * nix-системы поддерживают запуск исполняемых файлов для некоторых других ОС для одной и той же платформы, а ранние версии OS X поддерживают классические исполняемые файлы Mac OS, но для этого обычно требуется установить любые библиотеки в двух экземплярах. – Arkku

Смежные вопросы