Запуск ELF-файлов на ReactOS
Пожалуйста, будьте терпеливы в ответе, поскольку я новичок во всем этом и хочу, чтобы мои основы были на 100 процентов правильными. Я инженер-механик, так что не будь резким. Я изучаю некоторые очень простые вещи низкого уровня и был заинтересован в понимании концепции, связанной с бэкэндами компилятора. Вывод компилятора C / C ++ — это, вероятно, машинный код, специально разработанный для компьютерной архитектуры. Это также означает, что оно должно быть одинаковым в Windows и Linux, если оба работают на одном и том же оборудовании, например, на процессоре i7. Но есть еще один слой различий в виде двоичного формата. То есть у нас есть ELF (Исполняемый и связываемый формат) в Linux и PE / COFF (Портативный исполняемый файл) в Windows.
Таким образом, я чувствую, что компиляторы в Linux и Windows имеют бэкэнды, которые работают по-разному и испускают двоичные файлы в формате ELF или PE / COFF.
ReactOS является клоном Windows и двоично совместим с Windows.
Возможно ли теоретически иметь ПОГРУЗЧИК в ReactOS, который понимает ELF и загружает его правильно?
Я понимаю, что у нас должен быть уровень программного обеспечения, который сопоставляет API Linux с API ReactOS. Если такой слой отображения существует, имеет ли смысл мой вопрос?
Решение
Загрузчик не хватает.
Операционные системы имеют собственный интерфейс системных вызовов. Я не слишком разбираюсь в двоичных API Linux и Windows, в прошлый раз я использовал системные вызовы напрямую — MS-DOS.
В MS-DOS вы можете вызвать функцию DOS, загрузив код функции в регистр AH, а затем вызвать INT 21H. Регистр AL часто используется как подфункция или основной параметр. Например. Я могу вспомнить, как выйти из программы:
MOV AX,4C01H ; funciton AH = $4C (exit), error code is AH = 1
INT 21H
; program gets never here
Итак, другие операционные системы предоставляют другой модный интерфейс. Например. AmigaDOS имеет адрес exec.library по абсолютному адресу 4 (yep, $ 00000004), а функции библиотеки доступны через таблицу переходов, расположенную с отрицательным смещением по отношению к «базовому» адресу библиотеки (-4, -8 и т. Д.). Указатель других библиотек можно запросить из exec.library, используя функцию open.
Хорошо, MS-DOS и AmigaDOS работают на разных архитектурах, но это хороший пример того, как могут различаться вызовы операционной системы. Программные прерывания и адреса библиотек, предоставленные первой библиотекой.
Иногда разница — это удача. Когда различные вызовы операционной системы не мешают, можно написать обертка, который получает чужие вызовы операционной системы и преобразует их в операционную систему хоста. Было бы идеально, если бы API операционных систем отличались только порядком параметров системных вызовов — но ситуация сложнее. Более простая функция может быть сопоставлена с видом другой ОС, но более сложные функции — с обратными вызовами! — сложнее. Оболочки могут эмулировать не только функции, но и ошибки операционной системы.
В любом случае, в этом жанре есть что-то хорошее.
Хороший пример CygWin, которые позволяют запускать программы для Linux под Win32. Когда я в последний раз пользовался им, проблем с запуском командной строки не было, даже с потоками, сетью и т. Д. Отредактировано: требует перекомпиляции и libs, как говорит @fortran.
Для Linux ВИНО это хорошее усилие для запуска приложений Win32. Существуют даже официальные версии коммерческого программного обеспечения для Linux, в которых используется WINE! Если ваша программа не использует самые последние вызовы Windows API, WINE должен работать.
Поскольку Linux и BSD являются POSIX-совместимыми операционными системами, неудивительно, что такая вещь, как Уровень совместимости с Linux для BSD существует.
Другие решения
Других решений пока нет …