LINUX.ORG.RU

Wine WoW64: запускаем приложения i386 без multilib

 , ,


0

2

Привет, ЛОР.
Захотелось странного: запускать win32-приложения без multilib в системе. к сожалению, технология слишком новая, чтобы для этого был мануал в интернете, и тем более для того, чтобы была инструкция или пакеты для Debian Stable. Поэтому придётся собирать самому. За основу возьмём wine-staging из официального репозитория wine для Testing – там WOW64 включен по умолчанию…

Итак, наши шаги:

  1. Добавляем репозиторий исходных кодов wine для forky (testing) в /etc/apt/sources.list.d/winehq-forky.sources:
Types: deb deb-src
URIs: https://dl.winehq.org/wine-builds/debian
Suites: forky
Components: main
Architectures: amd64 i386
Signed-By: /etc/apt/keyrings/winehq-archive.key
  1. Импортируем ключик и делаем apt update
wget -O - https://dl.winehq.org/wine-builds/winehq.key | gpg --dearmor -o /etc/apt/keyrings/winehq-archive.key -
apt update
  1. Ставим зависимости, необходимые для сборки:
apt build-dep winehq-staging
apt install devscripts gcc-mingw-w64-i686 gcc-mingw-w64-x86-64 
  1. Забираем исходники и компилируем:
apt source wine && cd wine-staging-11.0~rc5~forky
DEB_BUILD_OPTIONS="parallel=$(nproc)" debuild -us -uc
  1. Если всё прошло хорошо – ставим получившиеся пакеты:
cd ..
dpkg -i wine-staging_11.0~rc5~forky-1_amd64.deb winehq-staging_11.0~rc5~forky-1_amd64.deb
  1. Вуаля – теперь мы можем запускать Win32 приложения без мерзкого мультилиба, засирающего систему. ¯_(ツ)_/


Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)

Для начала хотелось бы примеров, какие именно win32-приложения ты таким макаром успешно запускал.

hobbit ★★★★★
()

у меня подтормаживают 32битные приложения в wow64 сборках.
Интересно, это связано с несовместимостью TLS или просто где-то что-то багануло?
В любом случае в дебиане мультилиб сделан относительно хорошо, потому запариваться ради этого со сборкой wine из сорцов сомнительно

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

у меня подтормаживают 32битные приложения в wow64 сборках

у меня одна игрушка подтормаживала, на wine-staging без проблем едет

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

потому запариваться ради этого со сборкой wine из сорцов сомнительно

это не запариваться, это буквально пересобрать готовый пакет.

ann_lortemp2
() автор топика
Ответ на: комментарий от err

У меня такой staging - есть заметная регрессия производительности по сравнению с мультилибом

[I] app-emulation/wine-staging
     Available versions:
     (9.0)  (~)9.0^t
     (10.0) (~)10.0^t
     (10.7) (~)10.7^t
     (10.8) (~)10.8^t
     (10.9) (~)10.9^t (~)10.9^t[1]
     (9999) **9999*l^t
       {+X +alsa bluetooth capi crossdev-mingw cups custom-cflags +dbus dos ffmpeg +fontconfig +gecko gphoto2 +gstreamer kerberos llvm-libunwind +mingw +mono netapi nls odbc opencl +opengl pcap perl pulseaudio samba scanner +sdl selinux smartcard +ssl +strip +truetype udev +unwind usb v4l +vulkan wayland wow64 +xcomposite xinerama ABI_X86="(+)32 (+)64"}
     Installed versions:  10.9(10.9)^t[1](12:09:00 07/25/25)(X alsa capi cups custom-cflags dbus ffmpeg fontconfig gecko gphoto2 kerberos mingw mono netapi nls odbc opengl pcap samba scanner sdl ssl truetype udev unwind usb v4l vulkan wow64 xcomposite xinerama -bluetooth -crossdev-mingw -dos -gstreamer -llvm-libunwind -opencl -perl -pulseaudio -selinux -smartcard -strip -wayland ABI_X86="64 -32")
     Homepage:            https://wiki.winehq.org/Wine-Staging https://gitlab.winehq.org/wine/wine-staging/
     Description:         Free implementation of Windows(tm) on Unix, with Wine-Staging patchset                                                                

Мне собственно и интересно, это какой-то баг или в принципе фатальный недостаток смешивания linux-amd64 и windows-x86 кода в одном процессе?

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

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

mittorn ★★★★★
()

Можно ли таким образом использовать 32-битные ODBC драйверы в 64-битных префиксах? 3 года назад нельзя было, но потом как раз вроде это вот всё(WoW64) и пилили 3 года.

Loki13 ★★★★★
()

В дебиане нет никакого multilib. Это шапковый термин. То, про что ты пишешь, называется multiarch.

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

Постоянная конвертация 32-64 вызовов функций конечно не бесплатная. Впрочем, с 32-битным wine конвертация тоже есть, только на уровне сисколлов в 64 ядро. Но видимо там она оптимальнее работает.

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

конвертация вызовов куда дешевле, чем сисколы. Это всего лишь jmp в другой сегмент.
Но я не знаю, как wine/wow64 решает другую проблему: и win32 и linux-amd64 вроде как используют fs сегмент под tls.
А вот переключать его на каждый вызов уже дорого.
так что если wine не нашёл способ заставить хостовый код в процессе использовать TLS по другому или просто не конфликтовать с win32, то это создаст большой оверхед.
Я не смотрел, как там сейчас устроено, но сам экспериментировал с загрузкой 32битного кода в 64битноый процесс, потому предвижу возможные проблемы

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

Нет, это не jmp, это надо все структуры конвертировать в другой формат и возможно копировать большие куски памяти куда-то. И вызовы библиотечных функций скорее всего происходят чаще чем сисколлы. Сисколлы и так тяжёлые со сменой контекста.

firkax ★★★★★
()

Захотелось странного: запускать win32-приложения без multilib в системе. к сожалению, технология слишком новая

Разве? Она же ещё в wine-9 была презентована, то есть, более 2 лет назад.

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

и win32 и linux-amd64 вроде как используют fs сегмент под tls. А вот переключать его на каждый вызов уже дорого.

Это уже давным давно не дорого. Гуглани на тему инструкции WRFSBASE.

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

В дебиане нет никакого multilib. Это шапковый термин.

Тем не менее, в GCC это называется multilib

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

Постоянная конвертация 32-64 вызовов функций конечно не бесплатная. Впрочем, с 32-битным wine конвертация тоже есть, только на уровне сисколлов в 64 ядро. Но видимо там она оптимальнее работает.

Конверсия не только аргументов - если хостовая архитектура aarch64, то, соответственно, 32битный код ещё и под эмулятором теперь выполняется. Так что сравнивать их wow64 со старым нативным исполнением бесполезно: оно где-то работало быстрее, а где-то (на aarch64) - не работало совсем никак.

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

Не «более 2» а «примерно 2». И это и есть «слишком новая» - меньше 5 лет. Его даже в oldstable до сих пор нет.

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

И это и есть «слишком новая» - меньше 5 лет. Его даже в oldstable до сих пор нет.

А, ну это вы с вашим дебианом, понял. :) Другие дистры категориями 5 лет не мыслят, там это всё «прошлая жизнь».

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

Думаю речь была про amd64 конечно же.

Да никто уже давно нон-портэбл софт в рассмотрение не берёт. Не работает на современных архитектурах - значит, отсутствует.

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

Ну вообще-то не только дебиан. Шапка, хотя я её и не одобряю, rhel7 с ядром 3.10 до сих пор поддерживает.

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

Современная архитектура компов это amd64. Есть ещё архитектуры для эмбедов, макетов, роутеров итд - вот их несколько.

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

Шапка, хотя я её и не одобряю, rhel7 с ядром 3.10 до сих пор поддерживает.

Так вайн там разве есть? В федоре - есть. В рхел - нету же вроде?

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

Современная архитектура компов это amd64. Есть ещё архитектуры для эмбедов, макетов, роутеров итд - вот их несколько.

Не совсем верно. Во 2й части вы забыли сервера - они на армах из покон веков. А в 1й - компы уже есть, как настольники, так и ноуты. Но, правда, это результаты лишь последнего года, так что тут можно согласиться с тем, что тренд пока не массовый.

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

Сервера на amd64 разумеется все тоже. Сервера на arm это либо сказки arm-маркетологов, либо чья-то глупость (если они в реальности встретились).

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

Конвертация wow64, вероятно, расположена в максимально неудачном, в плане высокой частоты «событий», месте (ближе всего из всех конвертаций к прикладному коду и чаще всего дёргается).

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

Ну в таком случае дейставительно может быть неэффективно, возможно, это даже баг.
Исходя из текста новости о Wine 11:

Во всех модулях, обращающихся к Unix-библиотекам, задействованы преобразователи системных вызовов WoW64 (thunk), позволяющие 32-разрядным модулям в формате PE обращаться к 64-разрядным Unix-библиотекам.

64битные unix библиотеки могут сразу реализовывать 32битные API поверх линуксовых 64битных без двойной конвертации

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

Ну смотри, libjpeg - опциональная зависимость для wine. Где-то она там используется, я уж не знаю где. И вот у нас 64 битное wine и 32 битная прога внутри, доходит дело до того кода который пользуется libjpeg, что дальше происходит?

firkax ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.