Привет, Хабр! Это Иван Сорокин, вы меня знаете по статья про far2l, его идейному продолжению f4 и порту Dos Navigator на современные системы. Хочу рассказать про новый проект (на самом деле, проекты), вам наверняка понравится и пригодится!

Представляю fix-it-in-wine и dllmgr. Первый это скилл, он позволяет поручать ИИ-агенту исправление ошибок совместимости Windows-приложений с Wine. Второй - что-то вроде пакетного менеджера для DLL: позволяет устанавливать исправленные библиотеки независимо от основного Wine, делиться ими, использовать готовые решения других разработчиков.

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

Я хочу попробовать решить сразу две проблемы:

1. Исправление Wine остаётся задачей для программистов и весьма высокой компетенции. ИИ-агенты могли бы взять на себя существенную часть такой работы, но в Wine не берут сгенерированный код, считая это риском для проекта.

2. Даже когда исправление существует, путь от обнаружения проблемы до его появления у пользователей часто проходит через ограниченное число перегруженных разработчиков и мейнтейнеров (как самого Вайна, так и дистрибутивов).

Догонять Windows так можно долго. Нам нужен другой способ организации экосистемы!

От ожидания исправления к самостоятельному решению проблемы

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

Что можно сделать?

Попробовать другую версию Wine. Поискать подходящий workaround. Проверить WineHQ AppDB и Bugzilla. Возможно, установить альтернативную сборку или попробовать разные настройки окружения.

Если ничего не помогает, остаётся ждать исправления или разбираться в исходниках самостоятельно.

Последнее для большинства пользователей просто нереалистично. Wine — большой и сложный проект, а для исправления одной ошибки может потребоваться разобраться в устройстве Windows API, внутренней архитектуре Wine, поведении конкретного приложения и взаимодействии множества библиотек.

А что, если вместо этого дать ИИ-агенту задачу: «Почини вот эту программу под моим Wine»?

Именно для этого я начал разрабатывать скилл fix-it-in-wine.

Агент получает возможность последовательно исследовать проблему:

• Запустить приложение и собрать логи Wine

• Найти соответствующие сообщения об ошибках в WineHQ Bugzilla

• Определить, какая DLL или функция Windows API может быть причиной неправильного поведения

• Собрать необходимую библиотеку отдельно от остального Wine

• Подготовить исправление и проверить его на конкретном приложении

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

• При необходимости откатить изменения

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

Результат: больше не нужно учить Си, WinAPI и внутренности Wine ради исправления одного сломанного диалогового окна один раз в жизни.

dllmgr: пакетный менеджер для DLL Wine

Следующий вопрос: что делать с уже найденным исправлением?

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

Для этого предназначен второй проект — dllmgr.

Его задача — управление альтернативными реализациями DLL и отдельными исправлениями для Wine: библиотеки рассматриваются как самостоятельные компоненты, версии и варианты которых можно распространять независимо от основного Wine.

Пользователь сможет выбрать:

• Стандартную библиотеку из своей версии Wine

• Более новую реализацию той же DLL из другого выпуска Wine, которого ещё нет в репозиториях его дистрибутива

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

• Вариант оригинальной библиотеки из ванильного Wine с конкретным исправлением конкретной ошибки (причём всё можно собрать прямо у себя на компе)

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

В итоге получается пакетный менеджер для компонентов Wine. winetricks на стероидах :)

При этом сам dllmgr не гарантирует безусловной взаимозаменяемости любых DLL из любых версий Wine между собой, это out of scope. Но они совместимы, dllmgr позволит написать и использовать рецепт использования новой либы в вашем Wine.

Главный тормоз — не только технический

Теперь о том, ради чего всё это затевается.

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

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

В результате возникает бутылочное горлышко.

Даже если проблема хорошо изучена и для неё уже существует исправление, включение его в основной Wine требует проверки качества реализации, соответствия архитектуре проекта, соблюдения правил разработки, рецензирования и дальнейшего сопровождения.

Все эти требования оправданны. Без них большой проект быстро превратился бы в неподдерживаемую коллекцию специальных случаев.

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

А если исправления станет генерировать не несколько десятков или сотен разработчиков, а тысячи пользователей с ИИ-агентами?

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

Поэтому масштабировать нужно не только производство исправлений, но и способ их доставки.

А что, если перестать требовать включения каждого исправления в Wine?

Идея dllmgr в том, чтобы разделить два принципиально разных процесса:

1. Решение проблемы конкретного пользователя

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

Если исправленная DLL решает проблему, успешно проходит необходимые проверки и не нарушает работу остальных используемых компонентов, её можно распространять как самостоятельный вариант библиотеки.

2. Создание универсального исправления в Wine

Это другая задача. Здесь важны качество реализации, архитектурная совместимость, отсутствие регрессий и возможность долгосрочного сопровождения.

Этим по-прежнему должны заниматься разработчики Wine по правилам своего проекта.

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

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

Как при этом помогать основному Wine, а не создавать параллельный хаос?

Есть принципиальный момент: я вовсе не предлагаю отказться от отправки результатов исследований обратно в Wine, наоборот, это одна из основных целей fix-it-in-wine.

Но здесь возникает проблема с ИИ-генерированным кодом. Передача такого кода в основной Wine проблематична из-за требований проекта. Заваливать разработчиков Wine патчами от ИИ, принимать которые запрещают их собственные правила — плохая идея. Поэтому предлагается другой подход:

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

• Какая программа и при каких условиях работает неправильно

• Как воспроизвести проблему

• Каково ожидаемое поведение под Windows и фактическое поведение под Wine

• Какие вызовы API участвуют в ошибке

• В чём предполагаемая причина расхождения

• Какое изменение поведения устраняет проблему

• Какие тесты воспроизводят ошибку без исправления и успешно проходят после него

• Какие результаты получены при реальном запуске приложения

Все эти сведения можно добавлять в существующие отчёты WineHQ Bugzilla или использовать для создания новых, с проверкой и подтверждением пользователем перед публикацией.

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

В итоге ИИ берёт на себя значительную часть исследовательской и экспериментальной работы, не навязывая upstream свой код. На мой взгляд, это намного более конструктивная модель взаимодействия ИИ-агентов с крупными зрелыми open-source проектами, чем постоянные споры о том, можно ли вливать ИИ-код (и можно ли без ревью человеком), или нет. И она потенциально применима далеко не только к Wine.

Почему это может заметно ускорить развитие экосистемы

Попробуем представить, что такой подход получил распространение.

Пользователь обнаруживает ошибку в Windows-приложении и поручает агенту её исправить.

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

Исправление появляется в каталоге, после чего им могут воспользоваться другие пользователи.

Следующий агент, столкнувшийся с аналогичной проблемой, уже не начинает исследование с нуля: он может найти существующий вариант DLL и попробовать применить его.

Параллельно результаты диагностики поступают в WineHQ Bugzilla.

Разработчики Wine получают более качественные сообщения об ошибках, а удачные решения со временем могут превращаться в исправления основного Wine.

Таким образом, возникают сразу несколько источников ускорения:

• Массовое участие заинтересованных пользователей, которым больше не обязательно становиться для этого программистами

• Повторное использование идей исправлений вместо многократного независимого исследования одной ошибки

• Более мелкая гранулярность в сравнении с PlayOnLinux и аналогами (быстрее качается, собирается, тестируется - короче циклы обратной связи)

• Возможность параллельного сопровождения нескольких версий библиотек независимыми разработчиками - конкуренция всегда повышает качество продукта

• Снижение нагрузки на мейнтейнеров Wine за счёт отделения доставки локальных исправлений от их интеграции в upstream - смогут больше внимания уделять исправлениям по уже имеющимся точным описаниям причин

• Улучшение качества поступающих в Wine отчётов об ошибках - агент не забудет приложить лог

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

Что работает сейчас

Оба проекта пока находятся на ранней стадии разработки, но уже содержат полезные работающие фиксы! А также весьма полезный вспомогательный инструментарий.

В fix-it-in-wine готовы скрипты диагностики, поиска ошибок в WineHQ Bugzilla, сборки отдельных DLL локально, установки локальных замен и отката изменений.

В dllmgr реализованы формат каталога исправлений, его проверка и индексация, а также экспериментальные сценарии применения отдельных исправлений, которые уже готовы. Полноценные CLI, TUI и графический интерфейс менеджера пока в планах (первым сделаем TUI).

Есть и первый законченный практический результат: исправленная библиотека comctl32, решающая документированную в Wine Bugzilla проблему 59609 в FastStone Image Viewer. Первый пример того, как исправление конкретной ошибки приложения может быть подготовлено и распространено отдельно от основного Wine с установкой в один клик (см. scripts/apply-faststone-fix.sh). Или, скажем, поддержка AVIF в Wine: будет работать в любом совместимом просмотрщике изображений, не только в FastStone!

Что дальше

В ближайших планах — развитие каталога исправлений, автоматизация их применения, проверка совместимости и подготовка новых воспроизводимых тестовых сценариев на реальных приложениях. Far3, PuTTY, Photoshop CS2 - вот приложения, ошибки в которых агенты будут исправлять в первую очередь в качестве шоукейсов, когда закончат с FastStone. Предлагайте свои!

Цель — в перспективе прийти к ситуации, когда для установки исправления пользователю достаточно передать агенту ссылку на готовый рецепт, а тот самостоятельно установит необходимые инструменты, проверит окружение, применит исправление и протестирует результат. А также довести dllmgr до возможности по умолчанию работать в "режиме одной кнопки": "установить все фиксы для всех моих программ и следить за тем, чтобы они обновлялись и при необходимости подтягивались новые".

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

Ссылки и приглашение к участию

• fix-it-in-wine — skill для ИИ-агентов.

• dllmgr — менеджер вариантов DLL и каталог исправлений

Для экспериментов с fix-it-in-wine потребуется установленный Wine и агентный инструмент разработки, например, OpenCode, Cursor, Codex или Claude Code. Проверка результата и отправка материалов в WineHQ остаются под контролем пользователя: автоматическая публикация без подтверждения не предусмотрена.

Буду рад тестировщикам, сообщениям об ошибках, pull request’ам и особенно людям, которые захотят попробовать исправить с помощью этих инструментов какое-нибудь реально необходимое им приложение. И, разумеется, постараюсь помочь: t.me/unxed :)

Как думаете, насколько жизнеспособна, модель независимого распространения мелких исправлений, сможет ли она устранить одно главное ограничение скорости развития проекта?