Плоть слаба: как я писал свой Wine для браузера

Каждый год на новогодних каникулах у меня просыпается ностальгия: хочется перепройти что‑то из детства, типа «Harry Potter and the Philosopher’s Stone» от KnowWonder. И если с консольными играми всё просто (эмуляторы типа DuckStation или PCSX2 работают идеально), то с PC‑играми 32-битной эры всё сложно, особенно на Mac. Часто, пока ты добьешься запуска игры, уже пропадает всякое желание ее проходить.

В этот раз я решил проблему радикально: написал свою «Windows». В браузере. На TypeScript.

Усаживайтесь поудобнее, я расскажу вам, как я полгода дебажил чужие игры двадцатилетней давности и почему на это подсел.

Пролог. Голова в банке

Однажды вечером я спросил у ИИ: «Слушай, а можно ли к готовым эмуляторам типа boxedwine или v86 как‑то по‑быстрому прикрутить WebGPU?»

ИИ ответил: «Это будет медленно, слишком много оверхеда. Может, лучше сделать свой High Level эмулятор с нуля?»

Я немного растерялся: «Но подожди, это же почти как Wine с нуля написать! Его тридцать лет пилят всем миром!»

ИИ уверенно ответил: «Не боись, прорвемся. Для игр нужно гораздо меньшее подмножество системных функций, чем для тяжелых программ, так что всё будет нормально».

Я призадумался:

• вообще разработка WinAPI ведь достаточно хорошо изученная задача, ИИ должен помочь реализовать все эти бесконечные CreateWindowEx правильно

• это может быть интересный тест того, насколько сложный проект вообще можно разработать сегодняшними моделями (все же не чистая трансляция с одного языка на другой)

• ну и вообще, я наконец могу воплотить свое идеальное видение запускалки Windows игр! Мне всегда импонировала концепция ROM‑картриджей из мира консолей: вкинул файл — и погнали. А ещё меня всегда раздражало, как старые игры мусорят в реестре, прячут сейвы по всему диску и растягивают кривое 4:3 на весь ultrawide монитор.

Архитектура

Итак, ИИ предложил использовать High‑Level Emulation. В чём здесь идея?

Если совсем грубо, полный системный эмулятор притворяется компьютером, а High-Level Emulator — самой Windows.

В полном эмуляторе почти вся цепочка остаётся внутри гостевой x86-среды:

игра → WinAPI / DirectX → драйвер Windows → виртуальное устройство → эмулятор → браузер

Игра, системные библиотеки и драйверы — всё это x86-код, который v86 приходится переводить в WebAssembly, а браузеру затем — в машинный код хоста. Получается настоящая матрёшка: чтобы нарисовать один треугольник или воспроизвести звук, операция проходит через несколько вложенных машин.

HLE срезает почти всю середину:

игра → перехваченный вызов WinAPI / DirectX → TypeScript → WebGPU / Web Audio / OPFS

Оригинальный x86-код игры по-прежнему исполняется внутри v86. Но как только игра просит Windows нарисовать графику, прочитать файл или воспроизвести звук, эта работа выходит из низкоуровневой эмуляции и передаётся браузеру, где её выполняют нативные подсистемы хостовой системы.

В результате целевая архитектура BottleShip напоминает голову в банке, подключённую к огромному механическому телу. Внутри эмулятора остаётся мозг игры — её оригинальный x86-код, логика и состояние. А всё тяжёлое и ресурсоёмкое выполняет браузер, используя нативные возможности хостовой системы.

Как говорят в Adeptus Mechanicus: «Плоть слаба!»

Таким образом у нас есть три задачи:

• Выбрать «голову» — нашу x86-командомолотилку, способную исполнять оригинальный код игры.

• Построить для неё экзоскелет — подобрать современные браузерные API, которые заменят соответствующие подсистемы старой Windows.

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

Голова

В качестве «головы» я выбрал v86 — достаточно зрелый браузерный эмулятор x86, значительная часть ядра которого написана на Rust. Его главное преимущество — встроенный JIT‑компилятор: вместо побайтовой интерпретации каждой инструкции v86 на лету переводит блоки машинного кода x86 в WebAssembly, который затем эффективно исполняется браузером.

Наличие готового JIT дало мне хороший фундамент: вместо того чтобы с нуля решать задачу быстрой трансляции x86, я мог сосредоточиться на Windows API и постепенно оптимизировать наиболее горячие пути уже внутри существующего компилятора.

Экзоскелет

• OPFS заменяет диск и часть файловой подсистемы Windows;

• WebGPU берёт на себя DirectDraw, Direct3D, OpenGL, Glide и конвертацию графических данных;

• AudioWorklet и Web Audio заменяют звуковое устройство и аудиомикшер;

• FFmpeg‑WASM декодирует видео в старых форматах типа Bink и Smacker;

• остальные браузерные API заменяют привычную периферию и внешнее окружение Windows. Gamepad API даёт доступ к геймпадам, Pointer Lock — к относительному движению мыши, Fullscreen API — к полноэкранному режиму, а WebSocket и другие сетевые интерфейсы можно в перспективе использовать для сетевых функций. Даже системные шрифты необязательно растеризовывать самостоятельно: браузер уже умеет корректно парсить и отрисовывать TTF, поэтому интерфейс игры можно рендерить через Canvas, а затем загружать получившийся атлас в WebGPU. Ну не круто ли?

Транспорт: как игра общается с эмулятором

Осталась третья задача — связать голову с экзоскелетом. Игра ведь не знает, что она внутри банки: она честно вызывает CreateWindowEx, Direct3D или ReadFile, ожидая, что за ними стоит настоящая Windows. Наша задача — перехватить эти вызовы и подсунуть вместо системной реализации свою, на TypeScript.

Механизм такой: каждая функция WinAPI в памяти гостя — это крошечная заглушка (thunk): несколько байт x86-кода, которые кладут ID функции и выполняют инструкцию OUT на «магический» порт 0xB077. Для процессора это обычная запись в порт ввода-вывода, но наш v86 на этом порту специально останавливается: исполнение x86 замирает, управление передается в наш TypeScript.

Дальше диспетчер по ID понимает, какую функцию вызвали, читает аргументы прямо из памяти и стека гостя, выполняет нативную логику — рисует через WebGPU, читает файл из OPFS, что угодно, — кладёт результат обратно в регистры EAX/EDX и будит x86. Игра продолжает выполнение как ни в чём не бывало: для неё это выглядит как обычный возврат из системного вызова.

Примерно так это выглядит с x86 стороны:

B8 2A 01 00 00    mov eax, 0x12A      ; ID функции (у каждой свой)
BA 77 B0 00 00    mov edx, 0xB077     ; тот самый «магический» порт
EF                out dx, eax         ; ← здесь исполнение x86 замирает
C2 10 00          ret 16              ; stdcall: снять со стека 4 аргумента

Обратите внимание на последнюю строчку: там не просто RET, а RET 16. Большинство функций WinAPI в 32-битной Windows используют соглашение о вызовах stdcall: после возврата именно вызываемая функция должна убрать свои аргументы со стека.

То есть заглушке нужно заранее знать, сколько байт занимают аргументы. Четыре 32-битных аргумента — RET 16, двенадцать (привет, CreateWindowExA) — RET 48. Чтобы сгенерировать такую заглушку, недостаточно знать имя функции — нужно знать её сигнатуру. Ошибись хотя бы на четыре байта, и после возврата ESP уедет. Игра может даже не упасть сразу: она продолжит работать с чуть-чуть сдвинутым стеком и развалится через десять кадров в совершенно другом месте.

Соглашения о вызовах

На практике пришлось иметь дело сразу с несколькими соглашениями.

У функций C-рантайма (printf, memcpy и компания) обычно используется cdecl. Здесь стек после вызова чистит уже вызывающая сторона, поэтому наша заглушка заканчивается обычным RET и ей вообще не нужно знать число аргументов. Это особенно удобно для функций вроде printf, где количество параметров заранее неизвестно и определяется строкой формата.

У методов C++ в старом MSVC используется thiscall: указатель this передаётся через ECX, остальные аргументы — через стек.

Для системных DLL число аргументов я беру из сгенерированной таблицы метаданных Win32. У C++ такой таблицы нет, зато нужная информация закодирована прямо в имени экспортируемой функции:

?Serialize@FArchive@@UAEXPAXH@Z

Эта абракадабра — декорированное имя функции в терминологии MSVC: компилятор кодирует в нём класс, соглашение о вызовах, тип возвращаемого значения и типы параметров . Генератор разбирает его и вычисляет размер аргументов на стеке. Для FArchive::Serialize(void*, int) это восемь байт, значит заглушка заканчивается RET 8.

А вот как это примерно выглядит с typescript стороны:

onPortWrite(functionId: number, cpu: CPU) {
  const esp = cpu.reg32[4];   // на вершине стека — адрес возврата,
                              // сразу за ним по порядку лежат аргументы
  const arg = (i: number) => dv.getUint32(esp + 4 + i * 4, true);

  const stub = this.stubs.get(functionId)!;   // → "user32:CreateWindowExA"
  const result = handlers[stub.key](arg, mem);

  cpu.reg32[0] = result >>> 0;                // EAX — младшие 32 бита
  cpu.reg32[2] = (result / 2 ** 32) | 0;      // EDX — старшие
}

Для функций, которые ещё не реализованы, стоит другая ловушка — инструкция UD2. Она вызывает контролируемое падение, и вместо того чтобы громко крешнуться с непонятным поведением, эмулятор аккуратно сообщает: вот эта конкретная функция ещё не реализована.

Акт 1. Первые шаги и первая игра

Закатав рукава, я взялся за работу. Для начала решил собрать пару легковесных single-exe демок — проверить базовые вещи, прежде чем браться за настоящую игру. Сделал DX9-сцену со своей старой 3D-машинкой и пианинку на GDI для проверки клавиатуры и звука — и начал кодить вместе с ИИ-агентом.

В процессе подключения v86 выяснилось, что нам нужен собственный бутлоадер. x86-процессор после запуска находится в 16-битном real mode, а наш код рассчитывал на 32-битное окружение. Значит, нужно было вручную настроить таблицу дескрипторов, включить protected mode и передать управление 32-битному коду.

Я приготовился к большому головняку, однако агент выплюнул прямо в TypeScript массив байтов с машинным кодом и после пары итераций бутлоадер заработал.

Кажется, именно в этот момент я впервые по-настоящему понял, какие возможности сейчас открываются для реверс-инжиниринга и системного программирования. Ну а ещё через пару часов обе демки уже вели себя в браузере так же, как под Windows.

Тогда я наивно подумал: «Ну, раз DX9 завелся, он же наверняка обратно совместим со всеми старыми версиями, это будет легко...», скачал какую‑то старую демку Re‑Volt как промежуточный шаг на пути к запуску Harry Potter.

Boy oh boy, как же я ошибался...

Re-Volt

Поначалу прогресс по Re-Volt пошел достаточно быстро: игра не падала, музыка и звуки заработали, но вместо 3D-изображения на экране была непроглядная чернота, которая после еще некоторого количества колдовства превратилась в черные объекты.

Постепенно, обвешивая пайплайн логами и дампами поверхностей, я выяснил, что текстуры до рендера доходят неправильно. Тогда я нашёл исходники Re‑Volt и почувствовал себя очень умным: теперь-то для любого странного вызова можно будет посмотреть, что именно делает игра и чего ожидает от DirectX.

Когда текстуры заработали, я столкнулся со следующей проблемой — некорректная работа с прозрачностью.

Примерно здесь я понял, что исходники оказались не от той версии, которую я тестировал. Исходники использовали SetColorKey для прозрачности, а настоящая игра использовала формат текстур ARGB1555. Так что вместо ускорения исходники несколько раз отправили меня по ложному следу. После этого я полностью перешёл к реверс-инжинирингу конкретных EXE и DLL из тестового бандла в Ghidra.

Заодно я узнал — не представляю, как дожил до седых волос, не зная этого, — что BMP хранит цветовые каналы в порядке BGR. Поэтому перед загрузкой текстур в WebGPU данные нужно было не только распаковать из ARGB1555, но и правильно переставить каналы.

Довольно быстро выяснилось, что неправильный формат текстур — далеко не главная проблема. DirectX 7 оказался огромной и капризной стейт-машиной с кучей инвариантов. Главный вопрос, на котором я трижды обломал зубы: у кого прямо сейчас правильные пиксели — у CPU или у GPU?

DirectDraw разрешает игре в любой момент вызвать Lock() и писать в поверхность напрямую. GDI может нарисовать что-нибудь туда же. А потом всё это надо отрендерить на GPU.

Первая версия наивно держала пиксели на CPU и перезаливала текстуру на каждый чих. Вторая переехала на WebGPU — и утонула в багах синхронизации. В третьей появилась явная модель владения: у каждой поверхности есть authority — CPU или GPU, — версии и dirty-флаги. Конверсия форматов уехала в compute-шейдер: одна только распаковка RGB565 → RGBA ускорилась примерно в 4730 раз, со 141 мс до 0,03 мс. Позже пришлось добавить ещё и lease-модель: пока игра держит Lock(), ни один внутренний путь записи не имеет права трогать эту память.

Следом закономерно всплыла многопоточность. Не секрет, что планировщик — сердце любой ОС. Моё «сердце» в итоге разрослось примерно до шести тысяч строк и было переписано несколько раз — и, подозреваю, будет переписано ещё. Инварианты там всплывают неожиданно и не всегда детерминированно: часть багов, например, проявлялась только на моём макбуке.

Отдельная песня — время. Механизма понадобилось сразу два. Первый компенсирует виртуальное время: пока WinAPI-вызов исполняется на нашей стороне, x86 стоит и не генерирует «тики», поэтому прошедшее время приходится докручивать вручную. Второй — Frame Pacer — решает обратную задачу и не даёт игре рендерить быстрее дисплея: каждый вызов requestAnimationFrame() открывает игре следующий кадр, синхронизируя её с частотой монитора.

На то, чтобы Re-Volt нормально заработал, ушло около полутора месяцев. За это время я несколько раз всерьёз собирался сдаться и забросить проект. Но когда игра наконец поехала — причём благодаря отличной оптимизации самого Re-Volt уверенно держала 60 FPS, — я понял, что окончательно подсел.

Это ни с чем не сравнимое чувство: старая игра вдруг оживает в браузере, и тебя на несколько секунд переносит куда-то далеко в детство. А потом ты начинаешь биться за совместимость следующей игры — и всё начинается заново.

Акт 2. Турнир с Unreal

После Re‑Volt (и за компанию Diablo 2 с HOMM3) я решил взяться за следующий большой этап на пути к Harry Potter.

Дело в том, что Harry Potter была сделана на Unreal Engine 1, так что я решил начать его поддержку с демки Unreal Tournament 99. Здесь меня ждало залипалово еще на месяц‑полтора, к которому я оказался не готов.

DLL‑ад

До Unreal Engine мои игры были устроены просто: один exe, пара системных DLL. UT99 растоптал эту идиллию: сам UnrealTournament.exe — это крошечный лаунчер, а весь движок размазан по полутора десяткам собственных DLL — Core.dll, Engine.dll, Render.dll, Window.dll, D3DDrv.dll, Galaxy.dll... — которые импортируют друг друга во все стороны.

Это сломало сразу несколько наивных допущений моего PE‑загрузчика:

• Граф зависимостей. нужен честный обход графа импортов с правильным порядком инициализации, поиском по путям (DLL search order — тоже отдельная спецификация!) и вызовом DllMain каждой библиотеки.

• C++ через границы DLL. UE1 экспортирует не аккуратные C‑функции, а C++ классы целиком: запутанные имена вида ?Serialize@FArchive@@…, виртуальные таблицы, объекты, созданные в одной DLL и разрушаемые в другой. Пришлось учить загрузчик полноценным таблицам экспортов, а на каждый отсутствующий импорт ставить UD2-ловушку, чтобы игра падала с именем недостающей функции.

• Рантайм Visual C++ 6. Вместе с движком приехал весь зоопарк VC6: std::basic_string и компания из msvcp60, C++ исключения поверх SEH — с funclet’ами, которые надо исполнять на правильном стеке.

А что такое SEH?

Structured Exception Handling — механизм обработки исключений, встроенный в 32-битную Windows на уровне ABI. У каждого потока FS:[0] указывает на голову односвязного списка зарегистрированных обработчиков. Когда происходит деление на ноль, обращение к чужой памяти или программный throw, Windows формирует EXCEPTION_RECORD и CONTEXT и последовательно вызывает обработчики из этой цепочки, пока один из них не решит обработать исключение.

C++-исключения VC6 построены поверх того же механизма. Windows сама не ищет подходящий catch: она передаёт исключение обработчику рантайма компилятора, а уже тот по служебным таблицам определяет нужный catch, разматывает стек, вызывает деструкторы и передаёт управление в соответствующий funclet — отдельный огрызок функции, которому нужен доступ к кадру стека исходной функции.

Для эмулятора это означает, что мало просто поймать ошибку — нужно правдоподобно воспроизвести весь этот протокол. Поймать fault в v86, собрать гостевые EXCEPTION_RECORD и CONTEXT, найти цепочку по FS:[0], вызвать гостевые обработчики с правильным ABI и, если потребуется, корректно размотать стек и продолжить выполнение в catch. И всё это — не сломав стек, регистры и состояние потока. UE1 полагается на SEH постоянно: движок оборачивает в try/catch каждый тик и через этот же механизм показывает то самое окно Critical Error.

Короче, «поддержать UE1» на практике означало переписать загрузчик, доделать C++ рантайм и реализовать SEH — механизм, который в настоящей Windows является жирным куском ядра (у меня он сегодня занимает ~4000 строк).

Кривой sprintf

В Windows все строки живут в двух мирах: «узком» — однобайтовые char в локальной кодировке (это буква A в конце функций WinAPI: CreateWindowExA), и «широком» — двухбайтовые wchar_t (буква W: CreateWindowExW). Соответственно, у функций C-рантайма тоже есть две версии: у sprintf есть широкий близнец swprintf. Узкий форматтер у меня был нормальный. А вот в широком я float‑спецификаторы (%f, %e, %g) реализовать забыл: встретив их, он просто копировал спецификатор в вывод как обычный текст.

У UE1 TCHAR = wchar_t, так что SaveConfig() пишет конфиг строго через широкий путь. В итоге все float‑параметры сохранялись в.ini как литерал %f:

Brightness=%f
ScaleXYZ=%f
ScaleRUV=%f

А при следующей загрузке движок звал atof("%f") — и получал ноль. В итоге этот баг форматирования проявлялся в игре двумя совершенно разными симптомами:

• Чёрный экран. Brightness=%f → atof = 0.0. Драйвер UE1 строит из нулевой яркости полностью нулевую гамма‑таблицу — на реальном железе это затемняет экран целиком.

• Мёртвый курсор. ScaleXYZ и ScaleRUV — это множители осей мыши. Сохранились как %f → на загрузке atof = 0 → каждое смещение мыши умножается на ноль → курсор намертво стоит в углу. И самое коварное: с дефолтным конфигом (там реальные числа) мышь работала, ломалось только после того, как ты один раз сохранил настройки и перезашёл.

Этот баг я починил, случайно заметив в сохраненном конфиге значение, подозрительно напоминающее криво отработавший printf.

Кривой GetProcAddress

UE1 лениво привязывает нативные функции через GetProcAddress(dll, "ИмяФункции"). Причём имя функции каждый раз собирается в одном и том же буфере на стеке: адрес не меняется, меняется только содержимое.

Мой кэш GetProcAddress был устроен ровно так, как делать не надо: ключом служил указатель на строку, а проверка кэша происходила до чтения самой строки. Поэтому после первого вызова любой следующий запрос с тем же буфером — уже с другим именем внутри — получал адрес первой функции.

Снаружи это выглядело как полный хаос: игра падала в разных местах, симптомы менялись от запуска к запуску, а точка креша не давала почти никаких зацепок. На всё это накладывалась ещё и не до конца детерминированная многопоточность. Я перебирал коммиты, сравнивал логи, разбирал место падения — и всё тщетно.

Настоящий баг находился на километр логов раньше, в самом GetProcAddress.

До корня проблемы я дошёл почти случайно: в одном из обсуждений агент мимоходом упомянул кэш адресов. И я подумал, что баг в этом механизме максимально логично объяснил бы всё происходящее. Через несколько минут гипотеза подтвердилась — я нашёл ошибку, из-за которой едва не забросил проект во второй раз.

Акт 3. Harry Potter

Наконец я добрался до главной игры, и здесь меня ждал еще ворох багов...

Баг во _ftol

Прямо на запуске зависал сплеш‑скрин без каких‑либо признаков жизни и крешей.

Виновником оказалась крошечная функция C-рантайма — _ftol, которую старый MSVC использует при преобразовании чисел с плавающей точкой в целые. По ABI 32-битного MSVC она возвращает 64-битное целое, разложенное на пару регистров: младшие 32 бита в EAX, старшие — в EDX. Наша реализация возвращала только 32-битное значение, ограниченное INT32_MAX (0x7fffffff), а EDX вообще не трогала.

Лаунчер Unreal Engine строит шкалу времени так: берёт RDTSC (64-битный счётчик тактов, тикающий миллиардами в секунду), умножает на константу и 2^32, и через _ftol превращает в целое, чтобы вычислить DeltaTime. Уже через полсекунды аптайма это произведение (≈ 1.9·10^11) переваливало за INT32_MAX — и наш _ftol начинал возвращать 0x7fffffff каждый кадр. А раз время не меняется: DeltaTime = (сейчас − тогда) = 0 и игра не продвигается вперед.

Баг в планировщике

Игра рандомно зависала, иногда через 10 секунд после запуска, иногда спустя 10–15 минут. Один из тех самых неприятных плавающих багов.

Причина оказалась в следующем: гостевые потоки игры делят один‑единственный x87-FPU внутри v86. А мой планировщик при переключении контекста сохранял регистры общего назначения и EIP, но не сохранял состояние FPU‑стека. Поток, вытесненный посреди вычисления с плавающей точкой, возобновлялся с FPU‑регистрами другого потока. Отсюда и редкий недетерминированный мусор во float'ах, приводивший к зависаниям.

Flippendo!

Итак, после ещё сотни багфиксов — лайтмапы, семантика DirectSound, оптимизации — игра наконец стала по-настоящему играбельной. И вот я стою в Хогвартсе, запущенном в браузере, и на миг мне снова 12.

Эпилог. Полка с банками

За эти полгода я запустил еще много классных игр: Ядерный Титбит, Need For Speed: Porsche Unleashed, Need For Speed: Underground, Max Payne, Discworld Noir... Уже более 14 тайтлов. И в целом, кажется, я преодолел самый тяжелый этап, когда каждая следующая игра доставала кучу новых слоев несовместимости, реализация которых ломала уже работающие игры. Каждый новый проект уже добавляется быстрее.

Графика выросла в целую ферму бэкендов: Glide, OpenGL, DirectDraw и Direct3D от 7-й до 9-й версии (включая поддержку ранних шейдеров). Чтобы всё это не захлёбывалось на смене тысяч мелких состояний старого конвейера, появился мега‑шейдер с батчингом: вместо того чтобы плодить по отдельному WebGPU‑пайплайну на каждую комбинацию тумана/альфа‑теста/освещения, он собирает совместимые команды в пачки и гоняет их через один универсальный шейдер, а параметры прокидываются юниформами.

Улучшилась и производительность v86. Появился relaxed‑FPU (и JIT‑путь под него): ради скорости математика считается в нативных 64-битных double вместо честной 80-битной эмуляции x87. В играх с тяжёлой математикой это даёт заметный прирост. А сам мост между гостевым x86 и хостовым JS оброс несколькими скоростными полосами: hypercall'ы для сверх‑частых системных вызовов (время, синхронизация, строки — читаются прямо из общей памяти без выхода в JS), write buffer (WBUF) и arena, которые складывают мелкие вызовы в кольцевой буфер, а затем обрабатывают их пачкой — вместо отдельного дорогого перехода на каждый вызов.

За эти полгода изменилась не только техническая начинка. Совсем другой стала сама отладка.

Раньше процесс выглядел как бесконечное исследование логов и копипаст их агенту. Сейчас у проекта есть собственный harness — прослойка, через которую ИИ‑агент сам управляет эмулятором и наблюдает за ним, имея доступ к интерактивному отладчику и всему состоянию эмулятора. Так что теперь агент сам воспроизводит проблему, снимает нужный лог и проверяет гипотезы. Мне остаётся меньше ручной работы, а цикл от бага до фикса стал заметно короче.

import { harness } from "../harness";

const result = await harness()
  .streamLogs(["SYSTEM", "DDRAW", "USER32"])
  .openWgb("G:/WGB/half-life.wgb")     // загрузить бандл с игрой
  .waitForControl("New game")          // дождаться, пока меню отрисуется
  .click("New game")                   // клик по подписи, как это сделал бы человек
  .breakOnApi("ddraw:.*Surface7_Blt", { continuous: true })  // брейкпоинт на API
  .waitForEvent("apiBreak")            // ждём, пока игра туда придёт
  .state(["cpu", "surfaces", "threads"])
  .captureFrame({ dumpTargets: true }) // лог отрисовки одного кадра + PNG целей
  .run();

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

Еще один показательный пример: допустим, в игре глитчит какая‑то поверхность. Раньше это означало часы ручного копания. Сейчас я могу буквально подойти к этой поверхности и попросить ИИ разобраться. Агент сам подключается к отладочной вкладке, снимает лог отрисовки одного конкретного кадра — все Blt, Lock/Unlock, смены состояний, загрузки текстур — и идёт по нему, сверяя результат с поведением настоящей Windows.

Оговорки

BottleShip не возник из вакуума. В его основе лежит v86 — без его JIT перформанс был бы ниже плинтуса. Рядом стоят Wine, DXVK, ReactOS, MSDN и тридцать лет реверс-инжиниринга Windows. Именно благодаря этому модели часто «знают», какие флаги возвращает GetDeviceCaps или в каком порядке DirectDraw вызывает коллбэки. Но до того, как это знание попало к ИИ, его годами добывали и документировали живые люди.

Это разработка с ИИ — со всеми плюсами и побочными эффектами. Некоторые из самых мерзких багов в статье породил именно агент: достаточно вспомнить кэш GetProcAddress. Но без ИИ я, скорее всего, возился бы с BottleShip годами — или бросил бы его на первом чёрном экране. И обратное тоже верно: без моего опыта проект не ушёл бы дальше первого треугольника. Архитектура, декомпозиция, ревью и отладка багов самого ИИ всё это время оставались на мне.

Производительности есть куда расти. Я убеждён, что опытный разработчик эмуляторов выжал бы из связки v86 + WebGPU заметно больше, чем ИИ‑агенты на нынешней стадии развития. Если вы из таких — вам будет где развернуться.

На полке есть место

Я буду рад контрибьюшену — и тут есть нюанс, делающий проект необычным. Open Source сейчас стонет от AI‑пулл‑реквестов: мейнтейнеры тонут в правдоподобном сгенерированном коде, который дороже проверить, чем написать. Но BottleShip, по‑моему, из тех проектов, которые от AI‑контрибьюшена могут наоборот выиграть.

Здесь у AI-кода есть редкое преимущество: результат можно проверять не только глазами по диффу. Каждый фикс привязывается к конкретной игре, воспроизводимому сценарию в harness и кадру до/после, а затем остаётся в регрессионном наборе. Поэтому агент может взять на себя большую часть черновой работы, а мейнтейнер получает проверяемое доказательство, что код действительно чинит игру и не ломает остальные.

А главное — то самое ощущение из первого акта никуда не девается: каждая следующая игра из детства, которую удаётся запустить, дает такой же прилив дофамина как первый запуск Re‑Volt. Предупреждаю честно: это аддиктивно. Мне хватило одного раза, чтобы залипнуть на полгода. Теперь ваша очередь.

---

Пощупать проект руками можно здесь: https://bottleship.happydog.games

Покопаться в коде можно тут: https://github.com/jenissimo/bottleship

Следить за новостями можно в моем Telegram канале: https://t.me/ai_madness_diary

P. S. И теперь, когда релиз наконец‑то состоялся, можно с чистой совестью пойти поиграть в Гарри Поттера

Ты волшебник, Гарри.