LINUX.ORG.RU

Wine 6.23

 


0

2

Вышла новая версия Wine 6.23. Wine – прослойка совместимости приложений для Windows с POSIX-совместимыми ОС, транслирующая вызовы Windows API в вызовы POSIX на лету вместо эмуляции логики Windows вроде виртуальной машины. С момента выпуска версии 6.22 было закрыто 48 отчётов об ошибках и внесено 410 изменений.

Важные изменения:
  • драйвер CoreAudio и менеджер точек монтирования (Mount manager) преобразованы в формат Portable Executable;
  • добавлена поддержка обработки исключений в прослойку для запуска 32-разрядных программ в 64-разрядной Windows;
  • реализована возможность использования PE-библиотек, предоставляемых дистрибутивом, вместо библиотек из поставки Wine;
  • исправлена ошибка в GIMP при редактировании скриншотов;
  • улучшения в интерфейсе WineDbg.
Исправления связанные с работой игр:
  • Layers of Fear;
  • Internet Chess Club (ICC) Dasher 1.5.8;
  • Rockstar Game Launcher;
  • GTA 1997;
  • Crazy Stone.
Исправления связанные с работой приложений:
  • ICC Dasher 1.5.4;
  • Serif WebPlus X8;
  • Accessible Event Watcher;
  • Sookasa;
  • Windows PowerShell Core 6.2 Preview 2;
  • Navicat V15.0.25;
  • Ashlar Vellum/DrawingBoard 1.00;
  • Insta360 pro Stitcher;
  • outSPOKEN 3.0.

>>> Подробности

★★

Проверено: hobbit ()

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

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

dimgel ★★★★ ()
Ответ на: комментарий от Skullnet

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

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

dimgel ★★★★ ()
Ответ на: комментарий от dimgel

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

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

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

ZenitharChampion ★★★★★ ()

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

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

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

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

anonymous ()
Ответ на: комментарий от dimgel

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

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

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

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

anonmyous ()
Ответ на: комментарий от anonmyous

ханговер

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

enable-win32on64

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

anonymous ()
Ответ на: комментарий от anonmyous

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Kron4ek ★★★★★ ()
Ответ на: комментарий от anonymous

Использует 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.

anonmyous ()
Ответ на: комментарий от anonymous

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

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

anonmyous ()
Ответ на: комментарий от anonymous

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

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

anonmyous ()
Ответ на: комментарий от anonymous

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

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

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

anonmyous ()
Ответ на: комментарий от anonmyous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonmyous ()
Ответ на: комментарий от dimgel

А много там ещё осталось до полного выпиливания 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)

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

anonmyous ()
Ответ на: комментарий от anonmyous

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

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

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

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

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

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

anonmyous ()
Ответ на: комментарий от anonmyous

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

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

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/

anonmyous ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonmyous

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonmyous

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

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

anonymous ()