Wine 6.23

Что там по поводу драйвера wine для wayland от collabora? Есть хоть какие то новости? Собираются его принять хотя бы в staging?

Под WSL уже можно пользоваться?

в WSL2 должно работать нормально

они там перестали ломать [ef]sync в каждой версии? а то его уже в ядро заапстримили

добавлена поддержка обработки исключений в прослойку для запуска 32-разрядных программ в 64-разрядной Windows;

[праздное любопытство] А много там ещё осталось до полного выпиливания multilib? Есть какой-нибудь roadmap?

полного выпиливания multilib

Не будет. Много линуксовых программ с 64бит библиотеками запускают, ммм?

Много линуксовых программ с 64бит библиотеками запускают, ммм?

Я один ННП? Или этот аноним до сих пор на 32-битном пентиуме под XP сидит?

Ты же про мультилиб вещал. Ну так много 32бит программ запускаются с 64бит библиотеками?

i386 либы в линуксе придется тащить в основном из-за вайна, потому что в линуксе софт пересобирается для 64 бит, а в винде нет.

i386 либы в линуксе придется тащить в основном из-за вайна,

Не «придётся», а «приходится». Пока что. Как раз вся эта возня в вайне вокруг «прослойки для запуска 32-разрядных программ в 64-разрядной Windows» вокруг этого и делается, чтобы от multilib на хост-системе избавиться. В новости про прошлый релиз wine обсуждали. Но тут похоже люди на какой-то своей волне.

> В новости про прошлый релиз wine обсуждали. Но тут похоже люди на какой-то своей волне.

Да, конечно, каждый человек обязан читать каждый тред на ЛОРе. Или как минимум все те же самые треды, что и ты

*а тред мы читаем жопой.jpg*

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

Это так не работает, твои обсуждавшие - клоуны-хомячки. 32бит код несовместим с 64бит кодом.

Они сглаживание шрифтов фиксить собираются?

GTA 1997

боюсь даже представить когда смогу в GTA 2 сыграть…

они там перестали ломать [ef]sync в каждой версии? а то его уже в ядро заапстримили

Уже чуть больше года не ломали, начиная с версии 5.22.

Вышла новая версия Wine

Это какой-то праздник, ясчитаю.

реализована возможность использования PE-библиотек, предоставляемых дистрибутивом, вместо библиотек из поставки Wine;

Теперь можно и Протон анфоркнуть. Ну или, по крайней мере, в этом направлении двигаются:

драйвер CoreAudio и менеджер точек монтирования (Mount manager) преобразованы в формат Portable Executable;

Что там от самого вайна осталось не в PE, что требует допиливания для повышения совместимости?

Вайн тормозит развитие нативного линукс десктопа.

4.2

А много там ещё осталось до полного выпиливания multilib? Есть какой-нибудь roadmap?

Смотря у кого. Есть несколько подходов. В КроссОвере, например, это поддерживается уже довольно давно. Есть опция сборки --enable-win32on64. Но нужен их собственный, патченый силанг, который понимает оба АБИ одновременно и может генерировать из 32битного кода вызовы в 64битный. В апстрим вайн такое не возьмут.

Есть ещё ханговер: https://github.com/AndreRH/hangover Тут они с кему мутят для проброса вызовов в 64битный мир. Проект на начальной стадии и вряд ли взлетит из-за существенной сложности технологии.

А в апстримном же вайне всё идёт своим чередом. Там не то, чтобы избавляются от мультилиба… скорее, делают постепенно свой собственный. Компилят все хостовые либы в PE32, вместо elf32, который в привычных мультилибах используется. По сути, это тоже решение. И главное, это позволяет им не уходить в глухой девелопмент на несколько лет, с полной дестабилизацией кодовой базы, а переходить на PE постепенно, без регрессий и нервяка. Конечно потом возникнут проблемы с обновлением такого зоопарка, особенно если какой секьюрити баг в очередной либе найден, и на хосте уже давно закрыт, а под вайном - всё ещё старая версия. Но, учитывая то, что они давно уже от любых вопросов о безопасности открестились, их это вполне устроит. И дистро-строителей это тоже устроит, так как с них поддержку мультилиба, наконец, снимут.

ханговер

Использует Qemu, cмекаешь? Просадка производительности на ровном месте нахрен не нужна, когда можно исполнять код нативно.

enable-win32on64

Это костыль для мак оси, требующий поддержки ядра этой мак оси. В линуксе не нужно и не будет работать.

с них поддержку мультилиба, наконец, снимут

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

Компилят все хостовые либы в PE32, вместо elf32

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

Для мультилиба это ничего не меняет и количество зависимостей не сокращает.

Сокращает. Например, до недавнего времени зависимостях у Wine были нативные FAudio, libjpeg и libxml2, но с версии 6.20 их конвертнули в PE и теперь они собираются вместе с Wine и не требуют наличия нативных библиотек в системе.

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

Ясно. Всё равно не намного: вся иксовая требуха, видеодрова, аудио, glibc и тд всё ещё нужны системные мультилибные.

+На генте ещё нужно 32бит gcc mingw канпелять)))

Использует Qemu, cмекаешь? Просадка производительности на ровном месте нахрен не нужна, когда можно исполнять код нативно.

У qemu+kvm просадка не так уж велика. Впрочем, это лишь попытка, и что она вряд ли взлетит - понятно и без слов.

Это костыль для мак оси, требующий поддержки ядра этой мак оси. В линуксе не нужно и не будет работать.

Какой умный анонимус попался. :) Всё, что требуется от ядра - сисколл modify_ldt, который в линуксе был с рождения. CONFIG_MODIFY_LDT_SYSCALL=y CONFIG_X86_16BIT=y Ну там, конечно, ещё всякой фигни в линукс недавно добавили для облегчения «кодосмешения», типа UC_SIGCONTEXT_SS, CONFIG_X86_ESPFIX64 и ещё кое какую дрянь.

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

Ну вообще, я предпочитаю инфу из первых рук, а не с лора. :) Приведу пару ответов на мои вопросы от разраба этого всего хозяйства:

> It mentions the PE conversion though, which
> may be it, or may not.
You are right, this is related. Part of the point is to reduce
the linux-win32 interface to a manageable level. The bigger goal
there though is to make copy protection systems that compare
ntdll.dll on disk to the image in memory happy. The other
side-goal is to allow TLS switching on Win32 enter/exit e.g.
for aarch64 x18 and x86_64 %gs on macos.

> Do you know if such support is there, or
> moved to wine-7 or what?
It got moved in the sense that it just wasn't finished for the
timed Wine 6 release. We release those every January. There are
certain feature goals but none of them block release. It might
not even be there for Wine 7, at least on the Linux side.

Уменьшение взаимодействий между хостом и 32битным гостём - это, как минимум, одна из мотиваций перехода на PE.

Всё, что требуется от ядра

«Инфу из первых рук» я бы почитал насчёт вот этого вот момента, а не то, что ты принёс.

У qemu+kvm просадка не так уж велика

Для примера, на венде vbs даёт 5-20% просадки.

«Инфу из первых рук» я бы почитал насчёт вот этого вот момента, а не то, что ты принёс.

Задавай конкретные вопросы. У меня в архиве этой инфы из первых рук - ну на твои вопросы ответить хватит уж точно. :) Но если будешь и дальше добавлять фразы, типа «а не то, что ты принёс» - вероятно, не получишь ответы.

Для исполнения 64бит кода процессор должен находится в «64-bit mode», для исполнения 32бит кода он должен находиться в «Compatibility mode». Ну и как же они мешают одно с другим?

«Compatibility mode». Ну и как же они мешают одно с другим?

За этим вопросом даже в архив не полезу. Есть изначально 2 режма: лонг и легаси. Легаси - 32битный. А есть компатибилити - это не отдельный режим, в том смысле, что в него не надо переключаться. Это просто флажок в таблице дескрипторов, дескать, этот дескриптор у меня 32-битный. Именно его и выставляют через modify_ldt.

«Просто флажок»? Это не беслатно-то небось, небось кэши сбрасывает, латенси вносит.

«Просто флажок»? Это не беслатно-то небось, небось кэши сбрасывает, латенси вносит.

Поясните свою мысль.

Вот у вас есть таблица дескрипторов. Некоторые из них помечены как компатибилити 32, или даже 16бит (да-да, они всё это протащили в лонг мод). Эта таблица висит себе в памяти, никого не трогает. В какой именно момент времени начинают сбрасываться кеши и вноситься лейтенси?

Каждый раз, когда переключается выполнение кода с 64 на 32 и обратно.

Ладно, скажем не «переключается» а «переходит к выполнению кода другой битности» (хотя не светым же духом одно и то же ядро начинает код интерпретировать, внутри ядра что-то да переключается, пусть и неявно).

Каждый раз, когда переключается выполнение кода с 64 на 32 и обратно.

Ну это, даже в самом лучшем случае, делается фар джампом, а чаще - через iret. В линуксе можно вообще сисколлом, для удобства. :) А это совсем медленно. Короче, как ни изгаляйся, а переключения слегка (или сильно, если с сисколлом) замедлятся. Но суть в том, что нет нужды прыгать между гостём и хостом слишком часто. Так что этот оверхед, вероятно, весьма теоретический.

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

Гы. =)

Спасибо за развёрнутый ответ.

Уменьшение взаимодействий между хостом и 32битным гостём

Совсем перестанут взаимодействовать и получат реактОС

А много там ещё осталось до полного выпиливания multilib? Есть какой-нибудь roadmap?

Попробовал пробить этот вопрос у разрабов. Вот ответ:

ntdll is done, kernelbase, kernel32 are pure PE DLLs.
We're moving a lot of code from gdi32 and user32 into
win32u.dll/win32k.sys
Sound is work in progress.

So no, 7.0 won't have working 32on64. The gdi32/user32 stuff
is blocking it. 
Maybe command line programs can work in this mode, but will
probably need a lot of build system acrobatics.

OpenGL, Vulkan and d3d are also left. This is tricky due to
performance 
considerations. Our fake syscalls don't do an actual syscall,
but they do 
switch stacks and save all registers (needed to support Visual
Studio remote 
debugging and DRM as usual), so they are considerably more
expensive than plain calls)

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

переключение «битности» и стеков создаёт недопустимый оверхед в графической подсистеме.

А полноценный multilib не создаёт видимо потому что и драйвера 32-битные цепляет, и xcb, и всё остальное? Интересно, чего ради они тогда мучаются?

UPD. С другой стороны, если 32 бита нужны исключительно ради старых игрушек (а ради чего ещё?), то старые игрушки и с оверхедом будут летать, они ж старые.

А полноценный multilib не создаёт видимо потому что и драйвера 32-битные цепляет, и xcb, и всё остальное?

Получается, что так: вся меса с драйверами - 32бит. А так, на каждый колл в месу, сохрани регистры, переключи стек, сделай фар джамп/колл. Надо хотя бы примерно представлять, с какой же частотой они месу дёргают, чтобы вот ЭТО стало реальным оверхедом…

UPD. С другой стороны, если 32 бита нужны исключительно ради старых игрушек (а ради чего ещё?), то старые игрушки и с оверхедом будут летать, они ж старые.

Ну попробую и это спросить, раз уж такая пьянка пошла… Полагаю, ответ будет (если будет), типа, что многие игры и сейчас в виде 32битных бинарей клепаются, так как вендоры не спешат переходить на 64битные технологии, а винда их к этому и не обязывает.

Ну попробую и это спросить, раз уж такая пьянка пошла… Полагаю, ответ будет (если будет),

Не угадал. :) Ответ будет вот таким:

Old games are more affected by this than new ones in some way.
In very old GL, every vertex attribute was set with a separate
call (the glBegin/glEnd draw mode), so you might have multiple
calls from the application into GL *per vertex*. Modern GL,
Vulkan and d3d since version 1 handle this a lot better. But
even then depending on the game you can have tens thousands of
calls from the game to GL per frame.

И плюс ещё:

It's also the entire FPU / SSE state that needs to be pushed
and popped etc.

Вот теперь более понятно, откуда здесь оверхед! Хмм…

Про роадмапы, сказал, будут здесь публиковать: https://www.winehq.org/wwn/

Да уж, жуть. :)

За 20 лет попыток запустить на линуксе под wine хоть какое-то виндовое приложение, ни разу не получилось запустить ни-че-го. Ни одного раза. Никогда. Ни одного приложения.

Зачем они это развивают? Для кого? Кто этим пользуется и что запускает?

Жырно и тупо. Не всегда без пердолинга, но вполне запускаается и работает. Я не лично не встречал, чтоб прям не работало, хотя такие случаи есть.

Зачем они это развивают? Для кого?

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

Уж это-то не должно вызывать трудностей. Собирайте deferred state и пуште только во время дравколов. Сейчас игровые движки так и делают внутри себя, когда предоставляют подобные апи https://docs.unity3d.com/ScriptReference/GL.html

Этим же занимается OpenGL под макосью.

Тем не менее, как любитель поиграть в старые игры на маломощном UMPC, не одобряю ошибочное суждение:

старые игрушки и с оверхедом будут летать, они ж старые.

Вообще, кому-то давно пора сделать glvk в PE, желательно ещё и с разделением потоков на сборку и исполнение коммандбуферов. Уделает винду по перформансу, обещаю.

Надо хотя бы примерно представлять, с какой же частотой они месу дёргают, чтобы вот ЭТО стало реальным оверхедом

Запусти GPA, сдампай кадр какой-нибудь игры, увидишь порядка тысячи-другой вызовов к графическому апи, умножив на фпс, грубо, 10^4 в секунду. Довольно накладно