Wine 8.13

Которая была до этой новой wow64 с трансляцией 32 в 64 и позволяла запускать 32-битные приложения в 64-битных префиксах. Называлась Shared WOW64.

По-моему, вы несколько путаетесь в показаниях.

Которая была до этой новой wow64 с трансляцией 32 в 64 и позволяла запускать 32-битные приложения в 64-битных префиксах. Называлась Shared WOW64.

С этим не поспоришь. 2 вайнпрефикса с полным мультилибом, под названием Shared WOW64.

А вот что вы говорили до этого:

Обычный wow64 в Wine уже много лет как есть,

Да нет же, был только этот самый Шаред.

то что начали пилить недавно

… и есть обычный виндовый мультилиб (в винде он примерно так же и организован, и назван WoW64). На хосте он мультилиб не требует.

• это трансляция 32-битных вызовов в 64-битные,

… и заворачивание всех библиотек в 32битные РЕшники.

чтобы избавиться от 32-битных зависимостей.

Да.

А вот что вы говорили до этого:

Под обычным я и имел в виду Shared, который уже давно реализован был. Обычный для Wine, просто криво выразился.

Под обычным я и имел в виду Shared, который уже давно реализован был. Обычный для Wine, просто криво выразился.

Проблема не только в этом. Мой поинт был, что и сейчас пилят не только и не столько трансляции - afaik трансляции таки пилят, но лишь на уровне сисколлов и ntdll. А в основном, пилят «виндовый мультилиб», то есть заворачивают мультилибные зависимости в РЕшники, дабы поставлять вместе с вайном, а не требовать их от хоста.

Вы же, вроде как, оспорили это, сказав, что, дескать, не, сейчас-то уж пилят именно конверторы в 64битные вызовы, а всё остальное (видимо, включая и РЕшники), было уже давно.

А в основном, пилят «виндовый мультилиб», то есть заворачивают мультилибные зависимости в РЕшники, дабы поставлять вместе с вайном, а не требовать их от хоста.

Ну так и есть, я с этим не спорю.

Вы же, вроде как, оспорили это, сказав, что, дескать, не, сейчас-то уж пилят именно конверторы в 64битные вызовы, а всё остальное (видимо, включая и РЕшники), было уже давно.

Про PE я ничего не имел в виду, просто видимо недопонимание вышло.

«PEшники» это не замена хостовым библиотекам, это перенос библиотечного кода самого wine из нативной «зоны» (обычные so-файлы, к которым прокинут интерфейс из виндовых бинарников) в виндовую «зону», где они подключаются обычным PE-линкером. Внешние зависимости (какой-нить libasound2) при этом как были так и остались. wow64 же означает, что win32-прога будет обращаться к win64-dll (нативно-виндовым способом), а та, с свою очередь - к 64-битному libasound2.

Космические рейнджеры всё так же зависают при смене раскладки и вводят вопросики вместо кириллицы?

Ну, пересобери какой-нибудь nquake или ezquake.

Я даже не знаю что это. Слышал только про ioquake, у которого есть исходники.

Вполне продолжают выпускать новые 32-бит бинарники и никого это не заботит.

Нах*я? Ну а зачем я спрашиваю впрочем, винда же. Там всё вот так.

А 16-бит бинарники не выпускаете? Как же так.

Самоцели «перейти на 64» нет, это обычно побочный эффект фикса всяких нехваток памяти (2-3гб на процесс) итд.

Цель такая: выкинуть 32 бит префикс со всеми либами, чтобы в системе не было 2 архитектуры хрен знает зачем. Тебе не нужно трахаться с multilib-ом, LD_PRELOAD куда проще. Кароче, одни плюсы.

И, кстати, из-за x86 народ не стал юзать x32 (32 бит приложения, которые юзают 64-бит фичи процессоров, но указатели 32 бит). Вот в этом есть какой-то смысл, но это дополнительная по сути третья архитектура, поэтому плодить ещё один префикс никто в разумном уме не станет. Да и память сейчас дешевая.

Вот именно. Под линукс чёртова уйма софта, на который либо нет исходников, либо который невозможно пересобрать под современный линукс.

Вот именно. Под линукс чёртова уйма софта, на который либо нет исходников, либо который невозможно пересобрать под современный линукс.

Что-то я не вижу эту «уйму». Так что продолжаем выкидывание не смотря на то что какие-то юзлессные 2,5 проги сломаются.

Что-то я не вижу эту «уйму».

Это в силу узости взгляда.

Это в силу узости взгляда.

ССЗБ что просрали исходники.

А толку? А если исходники под svgalib? Если под Qt3? Под OSS? Под С89?

А толку? А если исходники под svgalib? Если под Qt3? Под OSS? Под С89?

Ну так вы сами подтвердили что оно никому не нужно. Раз так и застряло на Qt3 и прочих древних либах. Кстати OSS ещё в FreeBSD юзается, он актуален, а C89 код вообще без проблем можно и сейчас собрать.

А это очень удобно! Объявить то, что нельзя собрать под линукс из исходников - «никому не нужно». В то время как под виндой оно работало, работает и будет работать.

Нах*я? Ну а зачем я спрашиваю впрочем, винда же. Там всё вот так.

А почему надо 64? Потому что это модно?

А 16-бит бинарники не выпускаете? Как же так.

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

Цель такая: выкинуть 32 бит префикс со всеми либами, чтобы в системе не было 2 архитектуры хрен знает зачем. Тебе не нужно трахаться с multilib-ом, LD_PRELOAD куда проще. Кароче, одни плюсы.

Какой LD_PRELOAD, какое трахаться, ты о чём? Я настроил всё 10 лет назад (кажется вся настройка заключалась в dpkg --add-architecture и apt-get install wine32) и оно так же и работает, обновляясь с релиза на релиз через apt-get dist-upgrade. Никакая возня с LD_PRELOAD тут ни при чём.

работало, работает и будет работать.

нужным от этого не становится

А это очень удобно! Объявить то, что нельзя собрать под линукс из исходников - «никому не нужно». В то время как под виндой оно работало, работает и будет работать.

А потом появились ARM компьютеры и всё ваше сраное легаси, которые застряло на x86 без исходников стало никому не нужно. Кстати, поэтому винда физически почти и не существует на ARM и других архитектурах. Ну или пилите прослойки, которые будут работать в 20 раз медленее чем нативно собранный софт. Помойка ваша винда.

А почему надо 64? Потому что это модно?

Потому что легче когда в системе стоят приложения одной архитектуры. Это ещё экономия места на диске.

Какой LD_PRELOAD, какое трахаться, ты о чём? Я настроил всё 10 лет назад (кажется вся настройка заключалась в dpkg –add-architecture и apt-get install wine32) и оно так же и работает, обновляясь с релиза на релиз через apt-get dist-upgrade. Никакая возня с LD_PRELOAD тут ни при чём.

На 32 бит софт сделать LD_PRELOAD ты не сможешь, потому что тебе нужны будут 32 бит либы для этого, а их нужно собирать самому мультилибом.

https://github.com/nowrep/obs-vkcapture/issues/36

И этот 32 bit arch нужен только вайну, а так его уже давно выкинули.

Потому что легче когда в системе стоят приложения одной архитектуры.

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

Это ещё экономия места на диске.

А это уже почти нет.

На 32 бит софт сделать LD_PRELOAD ты не сможешь, потому что тебе нужны будут 32 бит либы для этого

Чтобы сделать LD_PRELOAD тебе по-любому придётся искать те самые библиотеки, которые ты хочешь туда засунуть. А будут ли они 32 или 64 битные - по-моему не особо важно. Ну, да, придётся сначала выяснить какой битности бинарник.

а их нужно собирать самому мультилибом.

Опять какие-то мультилиб-сказки. Не знаю откуда ты взял это слово, но 32-бит пакеты ставятся так же как 64-бит, но добавляя :i386 к названию (если первичная архитектура не i386).

И этот 32 bit arch нужен только вайну, а так его уже давно выкинули.

На 64-битном хосте в 99% случаев он нужен именно для wine, да. Собственно, такая ситуация уже давным давно. Но есть ещё и 32-битные хосты где он нужен всему софту, а ещё в линуксе, хоть и редко, но есть проприетарные 32-бит проги. Ну и нормальные дистры его не выкинули и не собираются.

«PEшники» это не замена хостовым библиотекам, это перенос библиотечного кода самого wine из нативной «зоны»

Ясно, спасибо. Полезное уточнение.

где они подключаются обычным PE-линкером. Внешние зависимости (какой-нить libasound2) при этом как были так и остались.

Поясните плиз. Допустим, была какая-нить winmm.so, зависящая от 32битной libasound2. Эту winmm.so превратили в winmm.dll. Что происходит с её 32битной зависимостью libasound2? Её тоже переносят в РЕ, или происходит какая-то магия, после которой нужен уже только 64битный libasound2?

wow64 же означает, что win32-прога будет обращаться к win64-dll (нативно-виндовым способом)

Такого, как я понимаю, не может быть в принципе. В винде, вроде бы, есть полноценный мультилиб, и 32битные либы, насколько я понимаю, только с 32битными и коммуницируют, а вот их 32битные сисколлы уже отрабатываются 64битным ядром винды.

а та, с свою очередь - к 64-битному libasound2.

Мне кажется, что нет. 64битный libasound2 доступен только через сисколлы, так как именно на уровне сисколлов происходит в винде взаимодействие между 32 и 64битными мирами.

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

А почему надо 64? Потому что это модно?

Да хотя бы по тому, что мир 64битных архитектур на х86_64 не заканчивается. х86_64 рано или поздно умрёт. А нормальный 64битный порт вайна нужен, чтобы потом работать на любых 64битных архитектурах, включая, к примеру, aarch64. В каких-то случаях - с оверхедом трансляции инструкций, но санкинг в 64битный мир понадобится в любом случае. И лучше его сделать заранее, чем ждать, пока мультилиб умрёт (уже), или пока х86_64 умрёт (тоже скоро, но пока нет).

Ну и нормальные дистры его не выкинули и не собираются.

Собираются. Убунта уже много раз порывалась, но вайн-юзера её останавливали. МакОС выкинул, и это послужило тем самым пинком под зад вайновцев, после которого они, таки, признали проблему. А что им мешало её предвидеть 20 лет назад?

Кстати, поэтому винда физически почти и не существует на ARM и других архитектурах.

https://www.windowslatest.com/2023/04/30/microsoft-plans-to-take-on-apple-m-chip-macbook-with-new-arm-chips-windows-12/

Как видите, реальность вполне радужная: винда-12 будет заточена под арм, что повлечёт изобилие нативных арм портов для всего современного виндового совта. Да и сейчас на винде-11 уже есть все трансляторы из х86 в арм:

https://learn.microsoft.com/en-us/windows/arm/overview#support-for-existing-windows-apps-on-arm

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

А потом появились ARM компьютеры и всё ваше сраное легаси, которые застряло на x86 без исходников стало никому не нужно.

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

Не знаю деталей взаимодействия winmm.dll<->libasound2, но libasound2.so как было внешней зависимостью так и остаётся. Если речь про wow64 то нужен только 64-битный будет.

Такого, как я понимаю, не может быть в принципе. В винде, вроде бы, есть полноценный мультилиб, и 32битные либы, насколько я понимаю, только с 32битными и коммуницируют

Может и так. Но как бы то ни было, конвертация в 64-битный вызов происходит внутри wine и снаружи ему 32-битные библиотеки уже не нужны. Только вряд ли это сисколл, wine их насколько я знаю не эмулирует и технически не может - это только в ядре можно реализовать.

Там речь шла про 32 vs 64 проги в винде, а не про вайн. То что 64-бит вайн нужен это понятно, т.к. как минимум чем-то нужно запускать win64 софт.

Дебиан не выкинул. А убунта почти выкинула, там остались только i386 пакеты, которые можно установить в дополнение к amd64, но поставить целиком i386 систему нельзя.

Ковырять.

Не знаю деталей взаимодействия winmm.dll<->libasound2, но libasound2.so как было внешней зависимостью так и остаётся.

Только вот зависимостей было 2: 32битный libasound2, и 64битный. Вопрос: куда девается первая из них? Я предполагал, что тоже уходит в РЕ. Но это не точно. :)

Только вряд ли это сисколл, wine их насколько я знаю не эмулирует и технически не может - это только в ядре можно реализовать.

Вот и реализовали: https://docs.kernel.org/admin-guide/syscall-user-dispatch.html Это, конечно, наркомания… но для вайна - работает.

Там речь шла про 32 vs 64 проги в винде, а не про вайн. То что 64-бит вайн нужен это понятно, т.к. как минимум чем-то нужно запускать win64 софт.

Я говорил про 64битный вайн, способный и 32битные проги тоже запускать. Это всё нужно, тк мультилиб уже подох почти, да и х86_64 давно уже не венец инженерной мысли.

А убунта почти выкинула, там остались только i386 пакеты, которые можно установить в дополнение к amd64

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

но поставить целиком i386 систему нельзя.

А это называется поддержка архитектуры i386.

2 большие разницы.

То, что ты называешь мультилибом - это и есть обрезок от раньше нормально поддерживавшейся i386 на хосте. Пакеты именно оттуда. И в дебиане кстати поддержка никуда не делась.

Вопрос: куда девается первая из них? Я предполагал, что тоже уходит в РЕ. Но это не точно. :)

Вместо первой используется вторая через вайновский конвертер 32-64, который появился в 8.х (wow64). Я раньше думал, что это происходит ещё на этапе dll, но видимо нет, и 32-битное dll обращается через обёртку к 64-битному внешнему so.

Вот и реализовали: https://docs.kernel.org/admin-guide/syscall-user-dispatch.html Это, конечно, наркомания… но для вайна - работает.

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

А вот чуваку нужно

А вот чуваку нужно

И причём тут 32bit ABI?

Не знаю. Вы что-то выдумываете.

Погодите, погодите. А к чему тогда все эти постоянные «сконвертили такую-то либу в РЕ», к чему завязка на мингв, произошедшая отн недавно?

Конвертация в PE не относится никаким боком к поддержке 32/64 разрядных приложений через multilib. Это две разные проблемы/фичи.

Эт самое, доколе Hell Division будет тормозить? Как в 8.11 началось, так и тянется. Через какое то время после начала игры загрузка видео становится 100%. Это ж игра века, а они не чешутся

Конвертация в PE не относится никаким боком к поддержке 32/64 разрядных приложений через multilib.

Конечно относится. Тем более, что выше уже разобрались, как именно: конвертация в РЕ позволяет пропустить 32битные вызовы через слой преобразований в 64битные, которые делаются на уровне ntdll и ядра винды. С нативными сошками так сделать бы не получилось, по тому, что не могут 32битные сошки сосуществовать с 64битными в рамках одного процесса.