Всем привет!
В этой статье я расскажу, почему у нас действительно получится заменить Wine, и что мы для этого делаем.
В прошлой статье я писал о простейшем способе создать и запустить импровизированный исполняемый файл, и на тот момент проект Vodka уже существовал на своей ранней стадии, поэтому у меня был план постепенно вводить читателя в эту тематику. Но с тех пор многое поменялось, поэтому теперь статьи будут посвящены тому, чего уже удалось достичь при разработке проекта.
С тех пор главным изменением стало то, что я познакомился с прекрасным человеком и глыбой‑разработчиком Александром Борисовым (@lastmac) создателем самого быстрого в мире парсера HTML — lexbor. Он стал куратором и принёс тот опыт, которого мне не хватало.
Мотивация проекта
Волею судьбы меня занесло в пару наших IT‑компаний, где мы занимались переходом с Windows на отечественные ОС семейства Linux, которые вы все прекрасно знаете. Конкретно я занимался импортозамещением программного обеспечения, которое существует и работает на Windows. Конечно, для этого мы использовали Wine, который приходилось постоянно дорабатывать под конкретное ПО, что создавало большие сложности и часто порождало непродуманные и неверные решения, а многие проблемы и вовсе не удалось победить.
Видя эти трудности, я захотел создать нечто, что позволит раз и навсегда переломить сложившуюся ситуацию, в которой большинство пользовательского и специализированного ПО остаётся непереносимым между различными ОС.
Именно для решения этой проблемы и разрабатывается Vodka, а идейно она описывается так:
Создать универсальный слой совместимости, чтобы избавить исполняемые файлы от «гражданства» в виде операционной системы.
Но это всё лирика, пора приступать к делу!
Наш подопытный кролик
Как минимальное доказательство работоспособности, соберём и исполним всеми любимый «Hello, world!» как исполняемый файл Windows на основе настоящих библиотек Microsoft — hello.exe, а получим его через mingw‑gcc.
Здесь всё как обычно, написали да собрали.
#include <stdio.h> int main() { printf("%s, %s!\n", "Hello", "World"); return 0; }
В чём сложность?
Загрузчик на ОС умеет запускать только определённый формат;
Форматы исполняемых файлов разные, и каждый имеет свои уникальные возможности;
У каждой ОС свой контракт между User Space и Kernel Space, API системных вызовов;
ОС имеют разный системный ABI, то есть используют отличающиеся соглашения о вызовах;
Различное представление ОС о том, какой информацией они должны делиться с ПО;
И многие другие нюансы разного уровня сложности.
Чтобы побороть эти несостыковки, в Vodka есть не только различный инструментарий, но и фундаментальные новшества.
Собственный загрузчик Vodka
Итак, сердце проекта, загрузчик Vodka, уже на данном этапе не уступает нативному загрузчику Linux по скорости и может служить его полноценной заменой в будущем. Он реализует весь необходимый функционал для подготовки файла к исполнению, включая, в том числе, отображение страниц, вычисление релокаций, поиск и загрузку зависимостей, заполнение TLS и shared‑данных, а также динамическое создание проксирующих функций для трассировки, конвертации ABI и подстановки заглушек на пути нереализованного функционала в нашем слое совместимости.
Архитектура с самого начала предполагает последующую модификацию загрузчика, чтобы имелась возможность дополнять и модернизировать его поведение. В такой функционал входит, например, возможность создавать runtime‑ссылки, которые перенаправляют пути в нужные пользователю места, что позволяет избавиться от Wine‑специфичного понятия префикса и напрямую «накладывать» пространство Windows на Linux.
Но одного загрузчика для запуска нам не хватит.
Новый формат — VDK
Формат исполняемого файла VDK создан с максимальной гибкостью и по принципу конструктора (насколько это возможно), так как в нашем видении уже пора отказаться от монолитности и идеи, что исполняемый файл — это немодифицируемый артефакт, который нельзя пересобрать, отредактировать или изменить впоследствии.
Весь цимес в том, что внутрь него можно уместить, со всеми их фишками, всех трёх мастодонтов: ELF, PE и Mach‑O. И с такой возможностью, получается, что все они при дистилляции в формат VDK будут существовать как разный программный код, но в едином типе контейнера, и могут работать друг с другом на уровне формата.
Дистилляция и подкоманда distillate
Дистилляция в контексте проекта — преобразование контейнера файла в наш контейнер VDK. Мы просто разбираем имеющийся исполняемый файл на составляющие, убираем ненужную нам служебную ОС‑специфичную информацию и оставляем только полезные данные. Такая промежуточная структура в Vodka называется vdk_mash.
После, мы эту информацию формируем и упаковываем в наш формат. На первый взгляд может показаться, что это бессмысленное действие, но на самом деле это даёт нам инструментарий модификации исполняемого файла под единым API независимо от его происхождения, и позволяет избежать некоторых юридических нюансов. На всякий случай уточню, что дистилляция — это именно способ получения VDK, а не единственный путь к исполнению.
И вот мы дистиллируем наш hello.exe в hello.vdk и с помощью подкоманды sense смотрим, какие зависимости у программы.
Но все эти api‑ms, честно сказать, мне не нравятся в списке зависимостей, поэтому, для наглядности, мы от них избавимся по готовой карте замещений, а на Windows этот функционал встроен в низкоуровневую библиотеку — ntdll.dll. Чтобы это сделать мы используем подкоманду rectify.
Хирургия с помощью подкоманды rectify
Эта подкоманда редактирует VDK‑файлы: изменяет экспорты и импорты, внедряет хуки, смешивает несколько VDK в один и предоставляет другой функционал для мутации файлов.
Изменяем текущие links с помощью rectify и смотрим итоговые зависимости.
Ну и самое главное — запуск и результат.
Осталось последнее и самое важное — то, где кроется большая часть работы и в чём принципиальная разница с подходом Wine.
На этапе разрешения зависимостей читается определённая карта редиректов, как та, которую мы использовали для очистки api‑ms библиотек из импортов. Так вот, там есть самый важный редирект, а именно: ntdll.dll => ntdll.vdk— это узкая талия между User Space и Kernel Space, единственное место, где вызываются сами инструкции syscall. Мы подменяем её собственной имплементацией этих системных вызовов через универсальную библиотеку примитивов, которая, можно сказать, является HAL'ом, а он уже подключает необходимую платформенную реализацию, в зависимости от системы, на которой мы работаем.
Данная архитектура позволяет реализовать слой совместимости для любого пользовательского ПО. А также для драйверов — тремя разными способами, но об этом в следующий раз.
В общем, мы выбрали путь реализации идеального слоя совместимости, а не воссоздания каждой библиотеки Windows, которые меняются день ото дня. Предупреждая возможные юридические вопросы, хочу заверить, что было продумано несколько способов их разрешения. А собственная реализация этих библиотек будет необходима исключительно как способ сделать их быстрее, потому что у Windows, оказывается, с этим действительно есть проблемы.
На данный момент мы размышляем о том, какая лицензия должна быть у Vodka и будет ли вообще программный код открытым, поэтому будем рады вашим идеям на этот счёт.
Спасибо, если вы дошли до этого момента, и отдельная благодарность, если вы видите проблему, которую мы хотим решить, и разделяете наши убеждения на этот счёт!
Скрытый текст
P. S.:
Комментарии (147)
gigimon
31.08.2026 19:42Так, а реализовать поддержку всех API call'ов windows как будете? Из статьи я так понял, вы облегчаете себе жизнь удалением не используемых dll, ок, а если это игра используяющая тот же directx, то как?
kmatveev
31.08.2026 19:42Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.
TizZy Автор
31.08.2026 19:42Из статьи я так понял, вы облегчаете себе жизнь удалением не используемых dll
К сожалению, тут я вас не понял. Если вы про очистку от api-ms импортов, то это просто схлопывание для наглядности.
Мы делаем слой совместимости, а не воспроизводим поведение Windows. Поэтому все зависимости могут быть предоставлены как вольной имплементацией, так и оригиналом.
gigimon
31.08.2026 19:42про слой совместимости в статье особо ничего не сказали, как вы совмещать нехватку реализованных api вызовов будете
ImagineTables
31.08.2026 19:42Что делать с приложением, у которого полгуя написано на WebView1 (IE)? Этого кода больше нет нигде и транслировать вызовы не во что. (COM-овские представления элементов DOM, я имею в виду). Автору надо будет незаконно редистрибьютить
mshtml.dll?
rikert
31.08.2026 19:42Парни, вы просто сделайте и покажите. В нашем менталитете очень много слов сделаем, получится, планируем, будет, предоставим итд. Надо так: смотрите - мы сделали.
Belarus
31.08.2026 19:42В нашем менталитете
А в нашем - делаем, и хорошо, но хронически не умеем презентовать и продавать.
andreymal
31.08.2026 19:42Сомнительно, но окей
Лично для меня признаком успеха будет работоспособность актуальной версии Adobe Illustrator (люди, которые проставили Gold в AppDB, даже не пытались его юзать)
единственное место, где вызываются сами инструкции syscall
Вы, видимо, просто ещё не натыкались на программы, которые вызывают syscall напрямую в обход ntdll, в том же вайне есть несколько баг-репортов об этом
не воссоздания каждой библиотеки
А откуда тогда легально взять Win32 API хоть для того же Paint?
TizZy Автор
31.08.2026 19:42Вы, видимо, просто ещё не натыкались на программы, которые вызывают syscall напрямую в обход ntdll, в том же вайне есть несколько баг-репортов об этом
На деле такие прямые вызовы вряд ли можно назвать хорошей практикой в разработке, а ПО, которое этим занимается, вряд ли можно назвать популярным. Но и на этот случай у нас будет инструмент :)
boris768
31.08.2026 19:42не воссоздания каждой библиотеки Windows, которые меняются день ото дня
Что в них меняется? Большая часть изменений - security-fix, и уж точно не функциональные изменения.
Честно говоря, я не понял, какую фундаментальную проблему подхода Wine решает описываемая архитектура. Wine, при всех его косяках и недоделках, уже работает и являет собой пример того, что реимплементация WinAPI - рабочий подход.
Собственный контейнерный формат и унифицированный loader - конечно круто, но нижняя граница совместимости всё такая же тяжёлая уже сейчас. Мало удовлетворить набор syscall-зависимостей из ntdll и win32u, нужно еще воспроизвести целую кучу механик и подсистем ядра NT:
Хендлы/объекты Windows, в том числе объекты ядра;
реестр;
все синхропритивы;
все тонкости обработки исключений (особенно обработка ud2);
IPC - пайпы, RPC - это как минимум;
для сети, directx и прочего - отдельные HAL-слои, поскольку юзерспейс это запрашивает у соответствующих драйверов.
Главный вопрос для меня в том, где тут архитектурная граница, будто в какой-то момент слой примитивов и HAL тут перестаёт быть относительно тонкой трансляцией, перерастая в ещё одну реализацию слоя совместимости Windows NT, посути становясь иным вариантом Wine.
Выше упомянули сисколы, как обрабатываются direct syscalls и тем более indirect syscalls? Кстати говоря, тут ваша парадигма, возможно, даже имеет больше шансов для рабочего решения, чем Wine, если ваш слой корректно ловит системный вызов.
То же самое и про исключения. Исключения в Windows ведь не только про раскрутку стека, само исключение надо правильно собрать, извлечь контекст (+ его совместимо изменить) - всё это очень сильно завязано на поведении ядра. Интересно, на каком уровне это предполагается эмулировать.
В целом сам подход выглядит любопытно, но пока не ясно, насколько проще обеспечить весь объём совместимости, которую надо реализовать. Пока выглядит как перенос основной сложности с уровня WinAPI на уровень юзермод ядра, при этом не факт что это легче
rukhi7
31.08.2026 19:42Wine, при всех его косяках и недоделках, уже работает и являет собой пример того, что реимплементация WinAPI - рабочий подход.
для графики и рисования нужна большая часть DirectX. DirectX это интерфейсы (С/С++) и их реализация на уровне драйверов. Главный принцип что реализация может как угодно меняться, интерфейсы и их поведение меняться не должны, вы можете только создать новый интерфейс если вас перестал устраивать старый. Но в Linux идеология совсем другая, хотя VScode вполне себе работает под теми не родными для Linux принципами и какой-то особый слой там вроде и не нужен или его не видно.
maximnik0q
31.08.2026 19:42для графики и рисования нужна большая часть DirectX. DirectX это интерфейсы (С/С++) и их реализация на уровне драйверов
В wine эту проблему уже давно фирма Valve решила:Транслятор DXVK -> Vulkan .DXVK транслирует вызовы 8-11 версии derectx в вызовы вулкан практически без снижения скорости, бывают даже случаи когда игра работает быстрее чем под Винду.
arteast
31.08.2026 19:42Пока выглядит как перенос основной сложности с уровня WinAPI на уровень юзермод ядра, при этом не факт что это легче
Однозначно легче, потому что грубо говоря >90% кода Wine работает исключительно на уровне userspace, опираясь на другие WinAPI.
имеет больше шансов для рабочего решения, чем Wine, если ваш слой корректно ловит системный вызов
Wine тоже их ловит и редиректит в соответствующие вызовы ntdll (обратный механизм к Windows), см. Syscall user dispatch.
TizZy Автор
31.08.2026 19:42Что в них меняется? Большая часть изменений - security-fix, и уж точно не функциональные изменения.
Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Wine, при всех его косяках и недоделках, уже работает и являет собой пример того, что реимплементация WinAPI - рабочий подход.
Нисколько не умоляю заслуги Wine, тем более с точки зрения первопроходца, но есть фундаментальные проблемы, например драйвера и wineserver.
Не хочется писать много слов без аргументов, поэтому мы просто покажем и расскажем всё в будущих статьях :)
Главный вопрос для меня в том, где тут архитектурная граница, будто в какой-то момент слой примитивов и HAL тут перестаёт быть относительно тонкой трансляцией ...
Мы стараемся выстроить архитектуру так, чтобы граница находилась строго на уровне системных вызовов в NT-слое, но при работе с устройствами допускаем три места внедрения слоя — в том числе, например, DXVK для аппаратного ускорения. О совместимости устройств нужно писать отдельно и подробно.
Выше упомянули сисколы, как обрабатываются direct syscalls и тем более indirect syscalls?
На данном этапе мы обрабатываем их исключительно на уровне замещения ntdll и win32u. Если честно, то это не является для нас первоочередным, но мы периодически размышляем как сделать это правильно, и, скорее всего, оставим несколько вариантов, в том числе рантайм-патчинг. Тут для нас важно избежать медленных инструментов, типа перехвата сигналов.
То же самое и про исключения. ... всё это очень сильно завязано на поведении ядра
На самом деле всё не так плохо. Важно понимать, что мы полностью контролируем низ, благодаря чему мы в состоянии даже полностью изменить поведение под себя. Можно сказать, что мы и есть ядро в этом контексте.
В целом сам подход выглядит любопытно, но пока не ясно, насколько проще обеспечить весь объём совместимости, которую надо реализовать.
Это намного легче. Как минимум потому что меньше мест, где можно сделать ошибку и допустить «рассинхрон» поведения.
zartarn
31.08.2026 19:42Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Шутка что Win32 самый стабильный ABI в Линуксе не на пустом месте появилась) и это заслуга не линукса
boris768
31.08.2026 19:42Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Никто не будет таким образом поступать, реворк стандартной библиотеки нужен был, чтобы не нужно было устанавливать redist всех ее версий. Благодаря этому рефакторингу последний redist сразу покрывает все совместимые версии стандартных библиотек начиная с VS 2015 и заканчивая своей версией.
Остальное - чистая совместимость с WinAPI, не будет ничего меняться.TizZy Автор
31.08.2026 19:42В любом случае, мы основываемся на совместимости с NtAPI, который является более стабильным для наших потребностей.
Kobagugi
31.08.2026 19:42Подмена одной только ntdll быстро разобьется о подсистему win32k.sys, куда вынесены отрисовка GDI и очереди оконных сообщений. В юзерспейсе эти вызовы все равно придется транслировать в полноценный оконный сервер
dimonz80
31.08.2026 19:42По традиции (Wine, Whiskey) должно называться Wodka же.
zartdinov
31.08.2026 19:42Strong russian accent же, поэтому все равно превращается в Vodka.
Alenkinenok
31.08.2026 19:42если говорить о strong russian - должен быть SamoGOne :)
jameskotov
31.08.2026 19:42Но поскольку все же требуется наличие W в названии, то в итоге получается SamoGOWne :-)
AleGen
31.08.2026 19:42Нет, водка - слово, заимствованное из темного, поэтому на английском произносится так же, как и на русском - не через "уай" (уодка), а через "в" (водка), и, соответственно пишется не через w, а через v.
poige
31.08.2026 19:42Если думать на как произносится, а в первую очередь об уникальности названия, то w явно лучше. И, кстати, это отдельно уделывает wine, потому что у них именно a-la vodka. ;)
Neo8
31.08.2026 19:42Звучит, несомненно, круче яиц вкрутую, но Вы все системные вызовы собрались подменить? Ведь придётся воспроизводить целую кучу систем, в частности, реестр, синхронизация, обработка исключений. Это не говоря уже про сетевые взаимодействия и такие прелести как DirectX. Так что удачи в реализации этого безнадёжного дела.
randomsimplenumber
31.08.2026 19:42Как назыется ОС, которая как windows, которую пилят лет 20, и которая никак на приблизится к Windows XP?
diakin
31.08.2026 19:42... которую 10 человек пилят лет 20...
arteast
31.08.2026 19:42Новый формат, новый загрузчик - это все красиво, но непонятно зачем. С тем же успехом можно отдельным загрузчиком грузить нативные PE и MachO. Но допустим - выносим разницу в исполняемых файлах в отдельные утилиты, переводим файлы в унифицированный формат. Это, правда, может сломать всякие там навесные защиты (в большей или меньшей степени, в зависимости от того, как загрузчик работает) - но до черт с ним, это все вопрос маленький.
Идея с реализацией syscall-интерфейсов довольно логична. Но откуда берутся userspace библиотеки? Откуда берется слой выше HAL?
Вот в вашем примере для загрузки hello.vdk вы указываете каталог `winfiles/64/dll` (унификация такая унификация... для vdk файла, сделанного из PE, в любом случае потребуется свой каталог, а для vdk файла из PE+ - свой собственный; в загрузчик надо будет добавлять этот механизм, как это делает нативный загрузчик Windows). Именно оттуда, как я понимаю, грузятся файлы kernel32.dll и ucrtbase.dll, которые уже вызывают подмененный ntdll.dll.
Где вы взяли эти файлы? Из Windows - нельзя, запрещает лицензия. Из Wine? Нет, от Wine мы избавляемся (да и не заработает оно, там емнип не вполне "как в Windows" сделано). Из ReactOS, может быть? Из фразы "предупреждая возможные юридические вопросы, хочу заверить, что было продумано несколько способов их разрешения" - именно из Windows; интересно было бы послушать про эти способы...
В случае mspaint - еще есть user32.dll и gdi32.dll (а для новых программ Direct2D) - там тоже такая же идея с HAL на стыке user/kernel? И "чужие" dll выше.
Еще 100500 всевозможных COM-сервисов в реестре и т.д - тоже откуда-то надо их взять.
funca
31.08.2026 19:42Из Windows - нельзя, запрещает лицензия.
В статье пишут, что свой формат позволяет обойти лицензионнве ограничения. Может они не только exe, но и dll из vindovs решили дисцилировать таким же способом?
Скрытый текст
Тогда это не vodka вместо wine, а уксус.
Ded_Banzai
31.08.2026 19:42Не позволяет. Тогда бы можно было без зазрения совести брать файлы из Windows, паковать их в какой-нибудь формат и использовать.
TizZy Автор
31.08.2026 19:42Ни в коем случае, мы не собираемся обходить никакие лицензии, в том числе лицензии компонентов Windows.
Nickroc
31.08.2026 19:42Главный вопрос, действительно, юридическая сторона, ребята возможно не знают как Вайн доказывал, что они не смотрят в утекшие исходники и как там строго с чистотой.
Удивительно наивно считать, что если как то перепаковать код, то это уже другой код и его лицензия не защитит. Пережать фильм и оп уже лицензия. Плюс эти люди ещё и не в опенсорс кладут, наверняка с целью монетизации.
lexore
31.08.2026 19:42Если присмотреться к картинке mspaint, можно увидеть поехавшую верстку на заднем фоне у кнопок и у обоих линий скроллов. И тут два варианта - либо оно так криво отображается, либо картинка чуть-чуть не настоящая.
UFO_01
31.08.2026 19:42Насколько я помню, подобные артефакты это характерное поведение Wine если не настроить темы оформления для win98/xp. Так что скорее всего просто у Wine взяли user32.dll, gdi32.dll, comctl32.dll.
TizZy Автор
31.08.2026 19:42Эти артефакты — следствие ранней стадии реализации функционала NtGdi и NtUser.
lexore
31.08.2026 19:42Понял вас. Вы знаете, я рекомендую вам посмотреть на свой проект с точки зрения вопроса "А не переизобретаем ли мы wine?"
Совместимость с windows - это не только перепакованный бинарник, но и совместимость с очень большим количеством библиотек. Вы сделали свой вариант работы с бинарником. Хорошо. Но остались библиотеки. И, возможно, может оказаться, что библиотеки займут 98% всей необходимой работы. То есть, перепаковка бинарника окажется наименьшей частью этой работы.
В wine уже проделали эту работу. Они делают эту работу уже больше 30 лет(!). Возможно, вы можете здорово сэкономить свое время, если сможете воспользоваться их наработками. Например, может быть, вы можете просто доработать wine? Понаделать патчей, получить нужную фунциональность. А потом, если захотите, можете прислать патчи в upstream.
TizZy Автор
31.08.2026 19:42Полностью понимаю вашу мысль.
Дело в том, что мы переизобретаем Wine только с точки зрения: «запустить Windows ПО на Linux». Мы создаём Vodka как универсальный слой совместимости, другими словами, связка Windows-в-Linux не единственная связка, которую мы хотим обеспечить.
Также хочу дополнить, что мы (на данный момент) не идём по пути имплементации самих библиотек пользовательского пространства Windows, а для запуска используем оригинальные. Это позволяет нам воссоздавать эталонный os-proxy слой и подготовить необходимые примитивы, которые потребуются в дальнейшем.
Реальное превосходство нашей архитектуры на примере работы с сетями мы покажем в следующей статье на примере запуска и замеров производительности nginx.exe против Wine.
CAHbKA_IV
31.08.2026 19:42Насколько понимаю, модель распространения чисто проприетарная, разработка полностью своими силами, открытость не планируется?
TizZy Автор
31.08.2026 19:42На данный момент мы размышляем о том, какая лицензия должна быть у Vodka и будет ли вообще программный код открытым, поэтому будем рады вашим идеям на этот счёт.
Какое у вас мнение?
Ded_Banzai
31.08.2026 19:42Ну, логично предположить, что если вы хотите распространить свой продукт, то открытый код этому поспособствует. Плюс, не будет нарушена лицензия.
Einherjar
31.08.2026 19:42действительно получится заменить Wine
А зачем? В нем обнаружился фатальный недостаток?
randomsimplenumber
31.08.2026 19:42Свой wine можно 20 лет пилить, если есть финансирование. А чужой - он бесплатный.
xtraroman
31.08.2026 19:42В лучшем случае вы научите уже выпущенный софт как то работать. Как то. Но каждый день производится новый софт и никто не тестирует его в вашем окружении. Именно в этом проблема всяких "вайнов" и "водок". Чтобы софт работал на российской операционной системе надо чтобы в CI были тесты на совместимость с ней. Вот, несколько лет назад мы наблюдали появление своих процессоров у Apple. Представляете сколько всего им надо было сделать чтобы под m1 появился качественный софт... Но они почему то не пошли по пути который вы предлагаете.
Ded_Banzai
31.08.2026 19:42Вы ошибаетесь. Уже много даже отечественных контор пишут софт и тестируют его в вайне.
Vedomir
31.08.2026 19:42Плохо будет, если в итоге получится закрытое решение.
UFO_01
31.08.2026 19:42Причём плохо для самих же разработчиков потому что есть открытый Wine. Если реально хотят что-то делать, а не просто просмотров на хабре собрать, то тут и обсуждать нечего.
adsl4ik
31.08.2026 19:42Ну Proton живёт ведь!
Mixaill
31.08.2026 19:42Proton – это огромный набор патчей на Wine (ну и dxvk, vkd3d-proton) от примерно тех же самых разработчиков.
UFO_01
31.08.2026 19:42Так Proton же тоже опенсорсный, базируется на Wine, с разрабами Wine сотрудничают, да и денег у Valve много.
TizZy Автор
31.08.2026 19:42Будет здорово, если вы поделитесь своим мнением на этот счёт!
Vedomir
31.08.2026 19:42Закрытые решения в наше время изначально мертворожденные и не добьются серьезного успеха. Особенно если говорить о технологии, не рассчитанной на конечного и технически неграмотного пользователя.
TizZy Автор
31.08.2026 19:42С чем связано ваше видение?
Vedomir
31.08.2026 19:42Наблюдением за индустрией. Много вы знаете закрытых языков программирования? Закрытых браузеров? Закрытых веб-серверов? Открытые операционки уже победили на серверах и мобильниках и постепенно отъедают долю десктопов, несмотря на огромную инерцию экосистемы. Открытые СУБД теснят закрытые, гугл говорит что уже 50% рынка, а если не только SQL брать, где тоже сильная инерция экосистемы, а NoSQL там уже и 70%.
Закрытая система - это монопольная привязка к ее производителю, который может закрыть проект, повысить цены во много раз, изменить систему лицензирования на неприемлемую. Те, кто думают о будущем, будут всеми силами избегать закрытых систем.
lastmac
31.08.2026 19:42Вот я в open source не первый день и точно могу сказать, что без корпораций, весь этот open source жить не будет. Но это дискуссия другого порядка. Тут я бы не торопился.
Vedomir
31.08.2026 19:42Не весь открытый софт делается корпорациями, но в любом случае это никак не противоречит сказанному мной.
UFO_01
31.08.2026 19:42Присоединюсь к доводам выше. Проблема в первую очередь в ресурсах. Огромная фирма может себе позволить лучших инженеров и кучу тестировщиков. Маленькая команда вынуждена полагаться на то, что кто-то продукт будет использовать и оставлять хотя бы баг-репорты, то есть полагаться на энтузиастов. А работать бесплатным тестировщиком закрытого кода будет только чудак.
mSnus
31.08.2026 19:42импортозамещением программного обеспечения, которое существует и работает на Windows. Конечно, для этого мы использовали Wine
Вся суть импортозамещения
domix32
31.08.2026 19:42А сорцы-то покажут от водки или только ректификационной колонной помашут?
TizZy Автор
31.08.2026 19:42На данный момент мы размышляем о том, какая лицензия должна быть у Vodka и будет ли вообще программный код открытым, поэтому будем рады вашим идеям на этот счёт.
Будет интересно послушать вашу точку зрения.
domix32
31.08.2026 19:42Насколько я понял, т.к. вы делаете дериватив вайна, то оно по идее тоже должно получить LGPL. Если же оно будет как враппер над вайном, то предложил бы тогда идти путём Proton и взять BSD.
TizZy Автор
31.08.2026 19:42Насколько я понял, т.к. вы делаете дериватив вайна
Нет, нас с Wine объединяет только стремление дать Windows ПО на Linux :)
domix32
31.08.2026 19:42То есть никаких заимствований вообще? Даже всякие ntdll планируете собственный поставлять, а не взять уже работающий от вайна?
TizZy Автор
31.08.2026 19:42Именно, так как нам нужна стабильность и точность, которую мы выстраиваем благодаря работе с оригинальными библиотеками.
взять уже работающий от вайна
В нашем представлении, они не являются в полной мере работающими, а также имеют архитектурную Wine-специфику.
domix32
31.08.2026 19:42Они же dll. Оттуда только API фактически нужен. Который будет повторять API виндовых библиотек, которая собственно и будет влиять на всю архитектуру, т.к. придётся повторять её ради бинарной совместимости.
Хотя, если брать готовые артефакты и работать с ними как с честными dll, то LGPL перестаёт быть проблемой, т.к. тот позволяет динамическую линковку без копилефта.
peacemakerv
31.08.2026 19:42Если штука окажется утомительной на каком-то этапе, то без опен-сурс лицензии она просто загнется в опер-сурс среде применения.
zartarn
31.08.2026 19:42Вы почему то думаете что, если человеку которому это было интересно и стало утомительно, вдруг найдется замена, в виде опенсорс сообщества? Думаете почему популярные фреймворки сейчас начали менять лицензию? а потому что тех кто готов поддерживать, на порядки меньше чем тех кто рассказывает про хотелки.
Выложив что то в опенсорс это не значит что набегут те кто захочет это поддерживать. Практика показывает что чаще как раз таки обратное. Тем более есть рабочий Wine, поэтому желающих делать альтернативу вкладывать огромное количество жопа-часов будет еще меньше.
Qetzlcoatl
31.08.2026 19:42Или я ничего не понял, или это движение в сторону PE loader / Win32k.sys loader проекта Odin для OS2.
TizZy Автор
31.08.2026 19:42Odin находится выше и больше похож на Wine, чем на Vodka.
Qetzlcoatl
31.08.2026 19:42Odin, как набор библиотек, да, аналог Wine (если не наоборот, КМК, Odin появился раньше). Но Odin - это не только набор бибилиотек, но и loader-ы, SDK и PE2LX.
Mixaill
31.08.2026 19:42И вот мы дистиллируем наш hello.exe в hello.vdk
Как такой подход будет дружить с различными анти-тамперами, вроде Denuvo?
TizZy Автор
31.08.2026 19:42Это один из пунктов, почему Vodka может не выйти в open source в полноценном виде с полным функционалом.
V1tol
31.08.2026 19:42Denuvo кстати не проблема, я не встречал ни одной игры с ним, которые не запускаются под Протоном. Вот античиты это уже совсем другая история.
TizZy Автор
31.08.2026 19:42Тут речь не о проблемах, а о возможности создать доверенного клиента там, где он не предполагался изначально, а это может сильно навредить.
ciuafm
31.08.2026 19:42Должен заметить автору что судя по комментариям большинство читателей (так же как и я) не смогли разобраться достаточно в вашем продукте чтобы писать осмысленные комментарии. Мне бы хотелось увидеть сравнение с wine в виде схем взаимодействия между запускаемой программой и библиотеками. Возможно подробное объяснение поможет понять инновационность вашего решения. Название норм.
achekalin
31.08.2026 19:42Шутка с названием Vodka сама по себе нормальная. Но на фоне заявления «мы уверены, что заменим Wine» она невольно усиливает ощущение стартапа из серии «нас трое, зато архитектура правильная».
Так и хочется плакат "Every Russian needs vodka and balalayka!" Для пиара полезно: Vodka — чтобы запускать Windows-программы. Balalaika — видимо, следующий проект для запуска macOS-программ. А когда понадобится оркестратор — назовут Matryoshka.
А по делу: Только Wine 11.0 — около 6300 изменений и более 600 исправленных ошибок за один год. А свежий Wine 11.16 от 21 августа 2026 года исправляет ещё 35 совершенно разнокалиберных вещей: Steam, WPF, WebView2, Acrobat, старые Win16-программы, сертификаты, Wayland, WoW64, syscall emulation и т. д. Это и есть настоящая цена слова «совместимость».
wadeg
31.08.2026 19:42Balalaika — видимо, следующий проект для запуска macOS-программ. А когда понадобится оркестратор — назовут Matryoshka
Тогда придется демонстрировать не "Hello World", а "Превед Медвед".
TizZy Автор
31.08.2026 19:42Так и останется Vodka, слой примитивов (наш «HAL») и слой совместимости с NtAPI остаётся одинаковым, изменится исключительно платформенный backend. Поддержка других хостов предполагается в архитектуре изначально.
Kobagugi
31.08.2026 19:42Ну приукрасили ребята ради красивого заголовка немножко) Над кодовой базой Wine непрерывно работают инженеры Valve, CodeWeavers и сотни контрибьюторов со всего мира. Закрыть такой разрыв по объему кода локальной командой без готовой кодовой базы практически невозможно
DmitrySolomennikov
31.08.2026 19:42А свой формат стабилизировался как-то уже? Можно, хотя бы, если не на сорцы, то хотя бы на спеку посмотреть?
Ну и можете ли вы отделить формат и инструменты для него в отдельный проект/продукт? Мне как компиляторщику очень любопытно, есть потенциальные точки роста в этом направлении.
TizZy Автор
31.08.2026 19:42На данный момент мы не определили наш путь лицензирования, поэтому пока мы не можем полноценно описывать формат, но о том, чтобы формат попал в open source мы думаем :)
soulkoden
31.08.2026 19:42А какой вообще смысл пытаться запускать win приложения под линуксом, особенно в целях импортозамещения? Вот чтобы что? 1С запустить? Так они 100 лет как нативную Linux версию имеют. Или редкие CAD какие-нибудь? Так вылетели с рынка они давно уже, кто не сделал мультиплатформенных решений, и остались там среди пользователей только парочка инженеров на всю страну. Весь смысл exe под линуксом в 2026 году по сути заключается в запуске игр. И приводить в пример продукты Adobe не надо - у них нет уникальных решений уже тоже.
TizZy Автор
31.08.2026 19:42Промышленное, медицинское и специализированное ПО работает на проприетарных драйверах, которые написаны под Windows, причём многие из них уже давно не поддерживаются разработчиками устройств, но до сих пор активно используются.
Также не строит забывать, что офисное ПО от Microsoft до сих пор не имеет нормального и работоспособного аналога, как, в прочем, и многое другое ПО, которое нельзя в сжатые сроки переизобрести.
soulkoden
31.08.2026 19:42Если поискать конкретные примеры промышленного ПО, то выяснится, что это не так. Ну и что касается офисных документов, то слабо поддерживаемые версии встречаются только в древних необновляемых шаблонах с макросами, которые используются исключительно в учебных целях в университетах. "Многое ПО" - это большой миф. За исключением штучных экземпляров ПО для конкретных предприятий написанных в древности ещё в эпоху activex.
TizZy Автор
31.08.2026 19:42У меня был опыт по адаптации ПО для одного из крупнейших банков РФ. "Многое ПО" - точно не миф и потребность в этом существует. Например, такое ПО как SAP - очень нужно, но не имеет полноценного работающего варианта на Linux (хоть и существует такая версия). А макросы активно используются и по сей день, к сожалению.
Помимо этого, требуется поддержать работу таких устройств, как сканеры посадочных талонов в аэропортах, драйвера для которых существуют только на Windows. И в медицинских учреждениях такие примеры есть.
soulkoden
31.08.2026 19:42Ну хорошо, SAP полностью ушел. Саппорта нет. Обновлений нет. Лицензий нет. И больше не будет. И толку от него, если это тыква, которая уже развалилась. Издержки от поддержания работоспособности уже сейчас могут превышать стоимость внедрения альтернатив.
ion_nsk_region
31.08.2026 19:42Промышленное, медицинское и специализированное ПО
Если не секрет, не могли бы вы назвать по два-три примера такого ПО из каждой категории. Иными словами, кто ваши пациенты? Кого вы водкой лечите?
xtraroman
31.08.2026 19:42Промышленный и тем более медицинский софт так не делают. За вайн и водку в этой сфере могут и посадить ведь от этого софта зависит жизнь людей.
randomsimplenumber
31.08.2026 19:42Все зависит от сертификации, то есть от количества правильных бумаг.
RamHiro
31.08.2026 19:42"Как вы яхту назовёте..." Надеюсь хулиганское название поменяют на что-то более благородное.
TizZy Автор
31.08.2026 19:42В нашем видении, название полностью отражает суть проекта :)
artemisia_borealis
31.08.2026 19:42Всё же Портвейн (
Portwein,Porto) было бы более душевно.В
Vodkaесть что-то отталкивающее.А если жечь по-настроящему, то можно
Spiritus. Прям несколько смыслов сразу.
roqin
31.08.2026 19:42Вот прочитал я эту статью - и у меня сразу воспоминания нахлынули: кто-то ведь (как будто бы из России) уже пытался сделать свой wine, лет эдак 25 (?) назад. Вроде даже что-то запускалось быстрее, чем под wine’ом, но то, что я даже название сейчас вспомнить не могу - многое говорит (там явно дальше версий 0.* дело не пошло, делали, вроде, для Windows 9x, при максимальном использовании родных dll).
От всего сердца желаю удачи, но в дальнейшем успешном развитии очень сильно сомневаюсь.
zavbaz
31.08.2026 19:42Я поначалу подумал что 1 апрельская статья, ан нет.
"Итак, сердце проекта, загрузчик Vodka, уже на данном этапе не уступает нативному загрузчику Linux по скорости и может служить его полноценной заменой в будущем. "
Естественно что на такой стадии (пока в нём почти нифига не реализовано) он будет децл быстрее и легковеснее. Но практика показывает что ещё задолго до первого полноценного релиза такие прожекты оказываются тяжелыми (даже без учета утечек памяти) и глючными "аналлогами" (не опечатка) того что они пытаются заменить.
fivlabor
31.08.2026 19:42Для меня главная печаль Wine - это не_поддержка USB. Китайские производители электроники никак ни в линукс, ни в макось не переезжают, а свои утилитки-настройки-прошиваторы только для Windows.
yadowit
31.08.2026 19:42С другой стороны, это очень хорошо. Вы точно знаете с какой ОС у вас это будет работать. Если бы часть девайсов работала с одной осью, часть с другой, а остальное с третьей - это было бы намного неприятнее.
Kobagugi
31.08.2026 19:42Хорошая инженерная разминка, но основной объем работы начнется на уровне реестра, оконных очередей и IPC
VladislavKalinkin
31.08.2026 19:42Задумка конечно интересная. Сам тоже пытался сделать под Apple Silicon Mac. Только вот у меня вопрос. Вы вообще для какой архитектуры планируете это. x64 (проще всего), ARM или даже RISC-V? Только Linux или еще MacOS (Asahi Linux может)? Удачи вам, но вообще я думаю если бы проект был бы с открытым исходным кодом вам было бы проще. Если вы хотите коммерчески использовать - просто сделайте GPL 3.0 и берите деньги с компаний. Если у вас закрытый код - понять нельзя чем помочь вам, честно ли вы делаете (вдруг копируете код wine или Microsoft). В общем удачи в развитии
TizZy Автор
31.08.2026 19:42Да, в планах есть поддержка macOS в том числе. Мы стараемся сделать наше решение универсальным слоем совместимости, который не привязан ни к целевой, ни к текущей ОС.
VladislavKalinkin
31.08.2026 19:42Единственное сразу хочу спросить. А вы как в принципе планируете работать с macOS. Intel маки уже по сути мертвы, а царит Apple Silicon (ARM). На Rosetta 2 полагаться уже нельзя, так как ее уже в версии 27 вырезают почти полностью. Лично я пробовал через кастомный JIT основанный на Cranelift, но на задачах типа 7zip скорость падала почти в 100 раз, а написать свой JIT полностью с нуля вообще практически неподъемная задача, если целиться именно на абсолютную скорость. Признаю так как с ИИ писал да и такого опыта нету где-то не дожал, но все равно во многих задачах замедление будет огромное. Вы вообще думали о подобном, есть ли идеи?
Tanriol
31.08.2026 19:42А свой бинарник программа видит в каком виде - оригинальный или перепакованный? А то какой-нибудь самораспаковывающийся архив от такого изменения формата вполне может перестать работать, как мне кажется.
strok_ova
вообще звучит нереально, но это так круто.. Правильно понимаю, что последнее фото это paint в виндовском окне на Linux?!
TizZy Автор
Да! Верно!