Отличие исполняемых wine и wine64

cast Kron4ek

а в чем между ними разница?

Так навскидку.

bash-5.1$ ldd /usr/bin/wine64
        linux-vdso.so.1 (0x00007ffc5d3fc000)
        libc.so.6 => /lib/libc.so.6 (0x00007f27cc19b000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f27cc39e000)
bash-5.1$ ldd /usr/bin/wine
        linux-gate.so.1 (0xf7f45000)
        libc.so.6 => /lib32/libc.so.6 (0xf7cf9000)
        /lib32/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf7f47000)
bash-5.1$ 

И что я теряю не используя wine64?(это мне важно, т.к. софт очень прожорливый по памяти)

Тогда выбор x86_64 очевиден.

на i686 нельзя получить больше 3Гб на процесс.

То есть /usr/bin/wine - это 32-битное приложение, а /usr/bin/wine64 - 64-битное. Соотвественно 32-битное приложение не может есть больше ограничения для 32-бит и не может запускать 64-битные приложения. И так далее.

Вот это то меня и смущает, что он запускает 64х битный виндовый экзешник. В том что он 64х битный, я уверен, я сам его собираю в VS.

Тогда выбор x86_64 очевиден.

Так это я понимаю, у меня и сборка вайна x86_64 и префикс тоже x64. А вот сами бинарники, большинство софта запускают оба, но вот с некоторым есть проблемы.

Покажите ldd вайна. Может у вас как-то по другому слинковано.

alexv@home ~> ldd ~/lutris-GE-Proton8-10-x86_64/bin/wine64                                                                                                                                                                    (base) 
	linux-vdso.so.1 (0x00007ffde37a9000)
	libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007fb1976f3000)
	libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007fb1976ee000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb197515000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb197747000)
alexv@home ~> ldd ~/lutris-GE-Proton8-10-x86_64/bin/wine                                                                                                                                                                      (base) 
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0xf7eaa000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0xf7ea5000)
	libc.so.6 => /usr/lib/libc.so.6 (0xf7c00000)
	/lib/ld-linux.so.2 (0xf7efe000)

Слинковано так же, и да, я вижу разницу. Но префикс вайна 64х битный точно и приложение, которое я запускаю, то же x64 собрано. Вот насчет потребления памяти, сейчас попробую проверить.

Проверил по памяти. my64exe.exe запущенный с помощью бинарника wine, без 64 в имени, сожрал 6Гб памяти и не подавился. Смотрел в top.

Интересно, для чего по работе может понадобиться плотно использовать WINE (если, конечно, это не NDA или коммерческая тайна…).

Если без имён и лиц, то

Куча софта инженерного, который используют многие гос.конторы. В связи с курсом на импортозамещение, необходимо переводить на линукс. Переписывать накопившееся за 20+ лет легаси(WinAPI, MFC и прочие демоны) в какие-либо обозримые сроки - не реально. Так что «по бырому» обеспечиваем стабильную и корректную работу всего этого в вайне(пользователь даже знать ни про какой вайн не будет, все эти кишки внутри).

Куча софта инженерного

Речь, как я понял, не про покупной софт, а про самописный?

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

это rss или va ?

Посмотри в описании процесса - какой там реально бинарник используется и какая нативная разрядность и процесса. А то может он распознал что оно 64-битное и перенаправил в wine64.

Да, об этом я не подумал(точнее подумал, но очень вскользь), что wine может быть умным. А как в этих наших линуксах подробную информацию о процессе получить? В top даже не пишет, что он через wine запущен, прямо имя ехешника.

Интересно, для чего по работе может понадобиться плотно использовать WINE

MS Office

Kompas 3D

FineReader

FEMM

Смотря кем и где работать. Главная причина: аналоговнет-софт укоренившийся в рабочих процессах. Особенно если он древнючий, «консольный» или вообще самодельный.

Из встреченного: winbox, parus, materialize. Достойны отдельного упоминания всевозможные генераторы ландшафта (terragen, world machine) - эта сволочь способна выжрать 100+ Гб ОЗУ/Свопа.

Я например вот ниразу не 3д-артист, а у меня десятка два всяких виверов-редакторов-конвертеров для нужных мне закрытых ресурных форматов.

О, кстати, еще одна мастейвная штука (тоже шындовс-онли), нужная на любом ПК с exe файлами - https://ntcore.com/?page_id=371

Заходишь в /proc/{pid}/ и смотришь там всё подряд.

нужная на любом ПК с exe файлами

Протон теперь поддерживает это в самом вайне для всех exe. Теперь тут патчить exe не нужно.

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

Разница будет, если в дистрибутиве не установлен 32-битный glibc, тогда 32-битный бинарник с именем wine просто не будет работать, ну и 32-битные приложения не будут работать.

И что я теряю не используя wine64?

Ничего.

Есть подозрение, что wine64 это та версия, что переводит вызовы x86 в x64(и которая сырая), но я не уверен что правильно понимаю.

Нет, wow64 включается иначе, просто вызова wine64 недостаточно.

Разница будет, если в дистрибутиве не установлен 32-битный glibc, тогда 32-битный бинарник с именем wine просто не будет работать, ну и 32-битные приложения не будут работать.

У меня получилось, что при запуске удаленного отладчика(msvsmon) с помощью wine64, он прямо на старте падает с критической ошибкой, а при старте с помощью wine - нормально работает. И происходит такое только на REDOS, на Альте работают оба варианта. И да, запускаю в обоих случаях не системным вайном, а сборкой lutris-GE-Proton8-10-x86_64.

Меня такое поведение очень смутило. Поэтому и этот тред.

Спасибо. Поковыряю в чем там разница.

Фиг его знает что там в RedOS накручено, но вообще разницы быть не должно. Ты можешь попробовать запустить какой-нибудь 32-битный и 64-битный exe’шник обоими бинарниками, они должны в обоих случаях запуститься и работать одинаково.

Понял. Спасибо!

Запустить тот же офис с проджектом или компас.

Сам wine только лончер. Вероятно, он потом exec'ается в нужный процесс.
Можешь узнать какой бинарник на самом деле крутит процесс по симлинку /proc/$PID/exe. Скорее всего этот будет какой-нибудь wine64-preloader
Разное поведение может быть вызвано глючной сборкой wine (например wine32 не знает про наличие 64битного preloader

Разное поведение может быть вызвано глючной сборкой wine (например wine32 не знает про наличие 64битного preloader

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

PS: Столкнулся с тем, что в Убунте, если запускать _свой_ вайн, как wine, то он пишет «File not found», а wine64 запускается. Но тут мои подозрения пали на настройки apparmor, т.к. только в убунте так.

Вангую что там нет 32бит библиотек. В астралинукс похожая тема.

Ну так у тебя лончер не запускается 32битный потому что нет 32битного линкера

У меня не запускается некоторый софт через wine64 на REDOS, который запускается через него на Альте. Но при этом начинает запускаться через wine. Сам WINE запускается и тот и тот. Вот и возник вопрос, в чем может быть между ними разница(для софта вендового, который под ними выполняется).

А насчет /proc/$PID/exe спасибо. Обязательно посмотрю.

Посмотри через strace почему он не запускается