Типичный подход к эмулированию среды для запуска старых файлов с архитектурой i386 сопряжен со сложностями, в частности с поиском всех необходимых библиотек. Однако этой проблемы можно избежать, воспользовавшись заранее подготовленным образом Live CD, о чем в статье и пойдет речь на примере образа эмулятора Palm OS и игры Shogo: Mobile Armor Division.
Да, достаточно создать оптимизированный эмулятор, и люди со всего мира потянутся к вашему дому, чтобы запустить свои старые бинарники x86. На данный момент таким эмулятором является QEMU. Даже если вы запускаете исполняемые файлы Windows через Hangover, внутренне это все тот же QEMU (а сейчас Hangover работает только с ядрами, использующими страницы 4К, оставляя нас, пользователей стоковой Fedora ppc64l3, не у дел). И если вы захотите запускать исполняемые файлы Linux x86 или x86_64 на вашем ящике OpenPOWER, то это однозначно будет QEMU в пользовательском режиме.
Тем не менее один из недостатков этого подхода в необходимости системных библиотек. Для решения данной проблемы Hangover встраивает Wine (и собирает их нативно для загрузки
ppc64le), но в пользовательском режиме QEMU требуются сами общие библиотеки для целевой архитектуры. Это зачастую подразумевает их утомительное копирование из пакетов с чуждой архитектурой, а для сбора нужного комплекта потребуется пройти длительный путь через пробы и неудачи. Причем после очередного апгрейда придется все проделывать повторно.Вместо этого можно просто использовать в качестве источника библиотек Live CD/DVD: это позволит хранить все в одном месте (зачастую требуя меньше пространства), и апгрейд станет просто вопросом скачивания нового Live-образа.
Я использую этот метод для запуска старого эмулятора Palm OS, который применял в своих проектах с ретро железом. Несмотря на доступность исходного кода этого эмулятора, он в значительной степени 32-битный, и мне пришлось внести в файлы некоторые по истине пугающие доработки. Сомневаюсь, что мне когда-либо удастся скомпилировать его в 64-разрядной системе Linux, но есть уже собранный 32-битный бинарник под i386.
Я располагаю ROM Palm m515 и большим количеством свободного времени после работы, так что давайте загрузим этого негодника. Прошу заметить, что в этих примерах я «все еще» использую QEMU 5.2.0. Версия 6.1.0 содержала ряд проблем и в определенный момент давала сбой, который подробно я так и не разобрал. Вы можете рассмотреть вариант сборки QEMU 5.2.0 для этой цели в отдельном автономном каталоге (и в некоторой степени прокачать его).
В текущей статье мы будем использовать Debian live CD, хотя можно взять и другой подходящий Live-дистрибутив. Поскольку POSE 32-х разрядный, нам потребуется образ именно с этой архитектурой. Скачайте его и смонтируйте (на момент написания он выглядит как
d-live 11.0.0 gn i386).Фактической файловой системой в стандартном режиме выступает образ
squashfs из каталога live. Можете смонтировать его через mount, но я для удобства использую squashfuse. Аналогичным образом, вместо того, чтобы монтировать сам ISO при каждой необходимости, я просто копирую образ
squashfs и экономлю пару сотен мегабайт. Затем, из места его размещения убедитесь в наличии ~/mnt folder (mkdir ~/mnt), после чего выполните squashfuse debian-11-i386.squashfs ~/mnt.Давайте протестируем его на капитане Соло. Как-никак, мы только что смонтировали
squashfs с мешаниной сторонних двоичных файлов, так что:% ~/src/qemu-5.2.0/build/qemu-i386 -L ~/mnt ~/mnt/bin/uname -m
i686Теперь можно возвращать Люка Скайуокера к Императору:
~/src/qemu-5.2.0/build/qemu-i386 -L ~/mnt poseТа-да! Palm запущен через образ m515 ROM, который я скопировал со своего Mac.
Тем не менее,
uname и pose – это два одиноких исполняемых файла, расположенные каждый в своем месте. Предлагаю взять вариант посложнее с ресурсами и прочими загружаемыми компонентами, например игру. Я являюсь поклонником старого шутера от Monolith под названием Shogo: Mobile Armor Division, который изначально вышел под Windows (его все еще можно приобрести на портале GOG), но в последствии Hyperion портировал его также на классическую Mac OS и Linux. Кстати, саундтрек в этой игре восхитительный.
У меня есть не только боксовая копия ее релиза для Windows, но и версия для Mac, которую достаточно сложно найти. Еще продавалась коробочная версия для Linux, но эта вообще крайняя редкость. Несмотря на то, что не так давно энтузиасты вели многообещающую разработку с использованием опенсорс-движка LithTech, Shogo была первой игрой на LithTech и, очевидно, использовала очень старую его версию, которая все еще не доработана. Тем не менее есть доступное демо для Linux.
Это демо как раз представляет собой большой бинарник под i386. Но, если вы запустите его с помощью описанного выше метода, то получите только странную ошибку о попытке запуска другого исполняемого файла из временной точки монтирования. Причина в том, что по факту это образ ISO с монтировщиком i386 ELF в заголовке, так что его нужно переименовать в
shogo.iso и смонтировать вручную. На моей системе GNOME помещает его в /run/user/spectre/ISOIMAGE.Для настройки опций перед запуском самой игры в Shogo на всех платформах используется кастомный лаунчер, но вам нужно запустить его напрямую, так как в Debian нет всех нужных этому лаунчеру библиотек:
% ~/src/qemu-5.2.0/build/qemu-i386 -L ~/mnt /run/media/spectre/ISOIMAGE/shogolauncher
/run/media/spectre/ISOIMAGE/shogolauncher: error while loading shared libraries: libgtk-1.2.so.0: cannot open shared object file: No such file or directoryВы можете решить расшарить копию этой невероятно старой версии GTK, но в каталоге
Loki_Compact образа Shogo нужный расшареный объект уже есть. (Речь не о Loki Entertainment, а об этом Loki, бывшем сотруднике Monolith). Для qemu-i386 нельзя определять несколько опций -L, но можно задать переменные среды для его загрузчика ELF-файлов, поэтому мы просто укажем нужнуюLD_LIBRARY_PATH. В течение следующих двух шагов нужно будет находиться в смонтированном образе Shogo, чтобы он мог найти все свои файлы данных:% cd /run/media/spectre/ISOIMAGE
% ~/src/qemu-5.2.0/build/qemu-i386 -L ~/mnt -E LD_LIBRARY_PATH="/run/media/spectre/ISOIMAGE/Loki_Compat" ./shogolauncher
Мы обошли скрипт оболочки, который обрабатывает весь процесс запуска, поэтому при выборе настроек вместо запуска игры на экран будет выводиться командная строка. Это удобно! Для начала я выбрал оконное разрешение 640х480 с использованием программного рендерера, а также отключил звук (он все равно не работает, возможно из-за устаревших библиотек), получил командную строку и запустил игру через QEMU. Встречаем:
Ну что сказать, при условии установки низкого уровня детализации получается вполне себе играбельно.
Многое, конечно, не работает: нельзя сохраняться, так как запущена игра с ISO (перекопируйте в другое место при желании); нет звука, как говорилось, из-за устаревших библиотек (сама игра 1998 года, а порт для Linux от 2001); и даже не думайте запускать ее с использованием OpenGL — вывалит куча ошибок. Помимо этого, наблюдаются эпизодические глюки графики и проблемы с обтравкой, одна из которых не позволяет закончить уровень, хотя мне не понятно, ошибка ли это разработчиков или же просто баг QEMU.
Производительность не революционная как для POSE, так и для Shogo. Однако нужно иметь ввиду, что все системные библиотеки работают в режиме эмуляции (нативны только системные вызовы), а в случае с Shogo мы еще больше все усложнили, включив полностью программную отрисовку. С учетом этого получение вполне подходящего для игры фреймрейта уже впечатляет. Более того, я определенно могу без особых хлопот тестировать что-либо в POSE, и это будет намного удобнее, чем запускать экземпляр Mac OS 9 для выполнения POSE в нем.
Самое же удобное в том, что по завершении работы с чужеродными исполняемыми файлами нужно просто выполнить
umount ~/mnt, и все это исчезнет. А после выхода Debian 12 просто замените образ squashfs. Проще некуда! Таким способом подобные программы запускать куда удобнее. P.S.
В одной из предыдущих статей мы разбирали HQEMU. Это серьезно доработанный форк QEMU, который использует LLVM для перекомпиляции кода на лету, что обеспечивает существенный прирост скорости ценой эпизодической утраты стабильности.
К сожалению, с момента своего релиза он уже много лет не обновлялся, и даже после того, как я пересобрал его на Fedora 34 и использовал предварительно собранный LLVM 6, с которым он дружит, эмулятор просто зависает. Так что, как я и говорил, теперь только стоковый QEMU.
