Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 128
вообще звучит нереально, но это так круто.. Правильно понимаю, что последнее фото это paint в виндовском окне на Linux?!
проверяйте свой продукт установкой и запуском Fusion360
Так, а реализовать поддержку всех API call'ов windows как будете? Из статьи я так понял, вы облегчаете себе жизнь удалением не используемых dll, ок, а если это игра используяющая тот же directx, то как?
Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.
Из статьи я так понял, вы облегчаете себе жизнь удалением не используемых dll
К сожалению, тут я вас не понял. Если вы про очистку от api-ms импортов, то это просто схлопывание для наглядности.
Мы делаем слой совместимости, а не воспроизводим поведение Windows. Поэтому все зависимости могут быть предоставлены как вольной имплементацией, так и оригиналом.
про слой совместимости в статье особо ничего не сказали, как вы совмещать нехватку реализованных api вызовов будете
Что делать с приложением, у которого полгуя написано на WebView1 (IE)? Этого кода больше нет нигде и транслировать вызовы не во что. (COM-овские представления элементов DOM, я имею в виду). Автору надо будет незаконно редистрибьютить mshtml.dll?
Гладко было на бумаге, да забыли про овраги.
Что-нибудь посерьёзнее хеллоу ворд и Paint - будут примеры?
Парни, вы просто сделайте и покажите. В нашем менталитете очень много слов сделаем, получится, планируем, будет, предоставим итд. Надо так: смотрите - мы сделали.
Сомнительно, но окей
Лично для меня признаком успеха будет работоспособность актуальной версии Adobe Illustrator (люди, которые проставили Gold в AppDB, даже не пытались его юзать)
единственное место, где вызываются сами инструкции syscall
Вы, видимо, просто ещё не натыкались на программы, которые вызывают syscall напрямую в обход ntdll, в том же вайне есть несколько баг-репортов об этом
не воссоздания каждой библиотеки
А откуда тогда легально взять Win32 API хоть для того же Paint?
Вы, видимо, просто ещё не натыкались на программы, которые вызывают syscall напрямую в обход ntdll, в том же вайне есть несколько баг-репортов об этом
На деле такие прямые вызовы вряд ли можно назвать хорошей практикой в разработке, а ПО, которое этим занимается, вряд ли можно назвать популярным. Но и на этот случай у нас будет инструмент :)
не воссоздания каждой библиотеки 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 на уровень юзермод ядра, при этом не факт что это легче
Wine, при всех его косяках и недоделках, уже работает и являет собой пример того, что реимплементация WinAPI - рабочий подход.
для графики и рисования нужна большая часть DirectX. DirectX это интерфейсы (С/С++) и их реализация на уровне драйверов. Главный принцип что реализация может как угодно меняться, интерфейсы и их поведение меняться не должны, вы можете только создать новый интерфейс если вас перестал устраивать старый. Но в Linux идеология совсем другая, хотя VScode вполне себе работает под теми не родными для Linux принципами и какой-то особый слой там вроде и не нужен или его не видно.
Vscode это браузер ( electron )
для графики и рисования нужна большая часть DirectX. DirectX это интерфейсы (С/С++) и их реализация на уровне драйверов
В wine эту проблему уже давно фирма Valve решила:Транслятор DXVK -> Vulkan .DXVK транслирует вызовы 8-11 версии derectx в вызовы вулкан практически без снижения скорости, бывают даже случаи когда игра работает быстрее чем под Винду.
Пока выглядит как перенос основной сложности с уровня WinAPI на уровень юзермод ядра, при этом не факт что это легче
Однозначно легче, потому что грубо говоря >90% кода Wine работает исключительно на уровне userspace, опираясь на другие WinAPI.
имеет больше шансов для рабочего решения, чем Wine, если ваш слой корректно ловит системный вызов
Wine тоже их ловит и редиректит в соответствующие вызовы ntdll (обратный механизм к Windows), см. Syscall user dispatch.
Что в них меняется? Большая часть изменений - security-fix, и уж точно не функциональные изменения.
Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Wine, при всех его косяках и недоделках, уже работает и являет собой пример того, что реимплементация WinAPI - рабочий подход.
Нисколько не умоляю заслуги Wine, тем более с точки зрения первопроходца, но есть фундаментальные проблемы, например драйвера и wineserver.
Не хочется писать много слов без аргументов, поэтому мы просто покажем и расскажем всё в будущих статьях :)
Главный вопрос для меня в том, где тут архитектурная граница, будто в какой-то момент слой примитивов и HAL тут перестаёт быть относительно тонкой трансляцией ...
Мы стараемся выстроить архитектуру так, чтобы граница находилась строго на уровне системных вызовов в NT-слое, но при работе с устройствами допускаем три места внедрения слоя — в том числе, например, DXVK для аппаратного ускорения. О совместимости устройств нужно писать отдельно и подробно.
Выше упомянули сисколы, как обрабатываются direct syscalls и тем более indirect syscalls?
На данном этапе мы обрабатываем их исключительно на уровне замещения ntdll и win32u. Если честно, то это не является для нас первоочередным, но мы периодически размышляем как сделать это правильно, и, скорее всего, оставим несколько вариантов, в том числе рантайм-патчинг. Тут для нас важно избежать медленных инструментов, типа перехвата сигналов.
То же самое и про исключения. ... всё это очень сильно завязано на поведении ядра
На самом деле всё не так плохо. Важно понимать, что мы полностью контролируем низ, благодаря чему мы в состоянии даже полностью изменить поведение под себя. Можно сказать, что мы и есть ядро в этом контексте.
В целом сам подход выглядит любопытно, но пока не ясно, насколько проще обеспечить весь объём совместимости, которую надо реализовать.
Это намного легче. Как минимум потому что меньше мест, где можно сделать ошибку и допустить «рассинхрон» поведения.
Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Шутка что Win32 самый стабильный ABI в Линуксе не на пустом месте появилась) и это заслуга не линукса
Тут больше логика в том, чтобы не воссоздавать библиотеки, которые могут в скором времени заменить как mscvrt на ucrtbase.
Никто не будет таким образом поступать, реворк стандартной библиотеки нужен был, чтобы не нужно было устанавливать redist всех ее версий. Благодаря этому рефакторингу последний redist сразу покрывает все совместимые версии стандартных библиотек начиная с VS 2015 и заканчивая своей версией.
Остальное - чистая совместимость с WinAPI, не будет ничего меняться.
Подмена одной только ntdll быстро разобьется о подсистему win32k.sys, куда вынесены отрисовка GDI и очереди оконных сообщений. В юзерспейсе эти вызовы все равно придется транслировать в полноценный оконный сервер
По традиции (Wine, Whiskey) должно называться Wodka же.
Strong russian accent же, поэтому все равно превращается в Vodka.
Нет, водка - слово, заимствованное из темного, поэтому на английском произносится так же, как и на русском - не через "уай" (уодка), а через "в" (водка), и, соответственно пишется не через w, а через v.
+1 к Wodka. Еще и поляки возрадуются.
Угу. А все пользователи данного продукта — alcogoliki?
Звучит, несомненно, круче яиц вкрутую, но Вы все системные вызовы собрались подменить? Ведь придётся воспроизводить целую кучу систем, в частности, реестр, синхронизация, обработка исключений. Это не говоря уже про сетевые взаимодействия и такие прелести как DirectX. Так что удачи в реализации этого безнадёжного дела.
Новый формат, новый загрузчик - это все красиво, но непонятно зачем. С тем же успехом можно отдельным загрузчиком грузить нативные 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-сервисов в реестре и т.д - тоже откуда-то надо их взять.
Из Windows - нельзя, запрещает лицензия.
В статье пишут, что свой формат позволяет обойти лицензионнве ограничения. Может они не только exe, но и dll из vindovs решили дисцилировать таким же способом?
Скрытый текст
Тогда это не vodka вместо wine, а уксус.
Главный вопрос, действительно, юридическая сторона, ребята возможно не знают как Вайн доказывал, что они не смотрят в утекшие исходники и как там строго с чистотой.
Удивительно наивно считать, что если как то перепаковать код, то это уже другой код и его лицензия не защитит. Пережать фильм и оп уже лицензия. Плюс эти люди ещё и не в опенсорс кладут, наверняка с целью монетизации.
Если присмотреться к картинке mspaint, можно увидеть поехавшую верстку на заднем фоне у кнопок и у обоих линий скроллов. И тут два варианта - либо оно так криво отображается, либо картинка чуть-чуть не настоящая.
Насколько понимаю, модель распространения чисто проприетарная, разработка полностью своими силами, открытость не планируется?
Дело Дениса Попова живет?
действительно получится заменить Wine
А зачем? В нем обнаружился фатальный недостаток?
В лучшем случае вы научите уже выпущенный софт как то работать. Как то. Но каждый день производится новый софт и никто не тестирует его в вашем окружении. Именно в этом проблема всяких "вайнов" и "водок". Чтобы софт работал на российской операционной системе надо чтобы в CI были тесты на совместимость с ней. Вот, несколько лет назад мы наблюдали появление своих процессоров у Apple. Представляете сколько всего им надо было сделать чтобы под m1 появился качественный софт... Но они почему то не пошли по пути который вы предлагаете.
Плохо будет, если в итоге получится закрытое решение.
Причём плохо для самих же разработчиков потому что есть открытый Wine. Если реально хотят что-то делать, а не просто просмотров на хабре собрать, то тут и обсуждать нечего.
Будет здорово, если вы поделитесь своим мнением на этот счёт!
Закрытые решения в наше время изначально мертворожденные и не добьются серьезного успеха. Особенно если говорить о технологии, не рассчитанной на конечного и технически неграмотного пользователя.
С чем связано ваше видение?
Наблюдением за индустрией. Много вы знаете закрытых языков программирования? Закрытых браузеров? Закрытых веб-серверов? Открытые операционки уже победили на серверах и мобильниках и постепенно отъедают долю десктопов, несмотря на огромную инерцию экосистемы. Открытые СУБД теснят закрытые, гугл говорит что уже 50% рынка, а если не только SQL брать, где тоже сильная инерция экосистемы, а NoSQL там уже и 70%.
Закрытая система - это монопольная привязка к ее производителю, который может закрыть проект, повысить цены во много раз, изменить систему лицензирования на неприемлемую. Те, кто думают о будущем, будут всеми силами избегать закрытых систем.
Присоединюсь к доводам выше. Проблема в первую очередь в ресурсах. Огромная фирма может себе позволить лучших инженеров и кучу тестировщиков. Маленькая команда вынуждена полагаться на то, что кто-то продукт будет использовать и оставлять хотя бы баг-репорты, то есть полагаться на энтузиастов. А работать бесплатным тестировщиком закрытого кода будет только чудак.
Я за открытый код, что бы форки назывались samogon, chacha и т. д.
импортозамещением программного обеспечения, которое существует и работает на Windows. Конечно, для этого мы использовали Wine
Вся суть импортозамещения
Ждём рабочий прототип, не слайды
а что, мы больше не ждем релиза ReactOS?
эх опоздал, выше в комментах уже вспомнили)
А сорцы-то покажут от водки или только ректификационной колонной помашут?
На данный момент мы размышляем о том, какая лицензия должна быть у Vodka и будет ли вообще программный код открытым, поэтому будем рады вашим идеям на этот счёт.
Будет интересно послушать вашу точку зрения.
Насколько я понял, т.к. вы делаете дериватив вайна, то оно по идее тоже должно получить LGPL. Если же оно будет как враппер над вайном, то предложил бы тогда идти путём Proton и взять BSD.
Насколько я понял, т.к. вы делаете дериватив вайна
Нет, нас с Wine объединяет только стремление дать Windows ПО на Linux :)
То есть никаких заимствований вообще? Даже всякие ntdll планируете собственный поставлять, а не взять уже работающий от вайна?
Именно, так как нам нужна стабильность и точность, которую мы выстраиваем благодаря работе с оригинальными библиотеками.
взять уже работающий от вайна
В нашем представлении, они не являются в полной мере работающими, а также имеют архитектурную Wine-специфику.
Они же dll. Оттуда только API фактически нужен. Который будет повторять API виндовых библиотек, которая собственно и будет влиять на всю архитектуру, т.к. придётся повторять её ради бинарной совместимости.
Хотя, если брать готовые артефакты и работать с ними как с честными dll, то LGPL перестаёт быть проблемой, т.к. тот позволяет динамическую линковку без копилефта.
Если штука окажется утомительной на каком-то этапе, то без опен-сурс лицензии она просто загнется в опер-сурс среде применения.
Или я ничего не понял, или это движение в сторону PE loader / Win32k.sys loader проекта Odin для OS2.
И вот мы дистиллируем наш hello.exe в hello.vdk
Как такой подход будет дружить с различными анти-тамперами, вроде Denuvo?
Должен заметить автору что судя по комментариям большинство читателей (так же как и я) не смогли разобраться достаточно в вашем продукте чтобы писать осмысленные комментарии. Мне бы хотелось увидеть сравнение с wine в виде схем взаимодействия между запускаемой программой и библиотеками. Возможно подробное объяснение поможет понять инновационность вашего решения. Название норм.
Шутка с названием 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 и т. д. Это и есть настоящая цена слова «совместимость».
Balalaika — видимо, следующий проект для запуска macOS-программ. А когда понадобится оркестратор — назовут Matryoshka
Тогда придется демонстрировать не "Hello World", а "Превед Медвед".
Так и останется Vodka, слой примитивов (наш «HAL») и слой совместимости с NtAPI остаётся одинаковым, изменится исключительно платформенный backend. Поддержка других хостов предполагается в архитектуре изначально.
Ну приукрасили ребята ради красивого заголовка немножко) Над кодовой базой Wine непрерывно работают инженеры Valve, CodeWeavers и сотни контрибьюторов со всего мира. Закрыть такой разрыв по объему кода локальной командой без готовой кодовой базы практически невозможно
"Мы" - это "Я и Клод" ?
А свой формат стабилизировался как-то уже? Можно, хотя бы, если не на сорцы, то хотя бы на спеку посмотреть?
Ну и можете ли вы отделить формат и инструменты для него в отдельный проект/продукт? Мне как компиляторщику очень любопытно, есть потенциальные точки роста в этом направлении.
А какой вообще смысл пытаться запускать win приложения под линуксом, особенно в целях импортозамещения? Вот чтобы что? 1С запустить? Так они 100 лет как нативную Linux версию имеют. Или редкие CAD какие-нибудь? Так вылетели с рынка они давно уже, кто не сделал мультиплатформенных решений, и остались там среди пользователей только парочка инженеров на всю страну. Весь смысл exe под линуксом в 2026 году по сути заключается в запуске игр. И приводить в пример продукты Adobe не надо - у них нет уникальных решений уже тоже.
Промышленное, медицинское и специализированное ПО работает на проприетарных драйверах, которые написаны под Windows, причём многие из них уже давно не поддерживаются разработчиками устройств, но до сих пор активно используются.
Также не строит забывать, что офисное ПО от Microsoft до сих пор не имеет нормального и работоспособного аналога, как, в прочем, и многое другое ПО, которое нельзя в сжатые сроки переизобрести.
Если поискать конкретные примеры промышленного ПО, то выяснится, что это не так. Ну и что касается офисных документов, то слабо поддерживаемые версии встречаются только в древних необновляемых шаблонах с макросами, которые используются исключительно в учебных целях в университетах. "Многое ПО" - это большой миф. За исключением штучных экземпляров ПО для конкретных предприятий написанных в древности ещё в эпоху activex.
У меня был опыт по адаптации ПО для одного из крупнейших банков РФ. "Многое ПО" - точно не миф и потребность в этом существует. Например, такое ПО как SAP - очень нужно, но не имеет полноценного работающего варианта на Linux (хоть и существует такая версия). А макросы активно используются и по сей день, к сожалению.
Помимо этого, требуется поддержать работу таких устройств, как сканеры посадочных талонов в аэропортах, драйвера для которых существуют только на Windows. И в медицинских учреждениях такие примеры есть.
Промышленное, медицинское и специализированное ПО
Если не секрет, не могли бы вы назвать по два-три примера такого ПО из каждой категории. Иными словами, кто ваши пациенты? Кого вы водкой лечите?
Если получится paint dot net запустить, то вот каеф будет. Его актуальной версии очень не хватает, а та, что сейчас "работает" - кривая вся. . .
"Как вы яхту назовёте..." Надеюсь хулиганское название поменяют на что-то более благородное.
Вот прочитал я эту статью - и у меня сразу воспоминания нахлынули: кто-то ведь (как будто бы из России) уже пытался сделать свой wine, лет эдак 25 (?) назад. Вроде даже что-то запускалось быстрее, чем под wine’ом, но то, что я даже название сейчас вспомнить не могу - многое говорит (там явно дальше версий 0.* дело не пошло, делали, вроде, для Windows 9x, при максимальном использовании родных dll).
От всего сердца желаю удачи, но в дальнейшем успешном развитии очень сильно сомневаюсь.
Я поначалу подумал что 1 апрельская статья, ан нет.
"Итак, сердце проекта, загрузчик Vodka, уже на данном этапе не уступает нативному загрузчику Linux по скорости и может служить его полноценной заменой в будущем. "
Естественно что на такой стадии (пока в нём почти нифига не реализовано) он будет децл быстрее и легковеснее. Но практика показывает что ещё задолго до первого полноценного релиза такие прожекты оказываются тяжелыми (даже без учета утечек памяти) и глючными "аналлогами" (не опечатка) того что они пытаются заменить.
Для меня главная печаль Wine - это не_поддержка USB. Китайские производители электроники никак ни в линукс, ни в макось не переезжают, а свои утилитки-настройки-прошиваторы только для Windows.
Хорошая инженерная разминка, но основной объем работы начнется на уровне реестра, оконных очередей и IPC
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Vodka, или как мы планируем заменить Wine