Состоялся экспериментальный выпуск открытой реализации WinAPI - Wine 5.13. С момента выпуска версии 5.12 было закрыто 22 отчёта об ошибках и внесено 407 изменений...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53390
> В функции GetPrivateProfileStringW(), WritePrivateProfileStringW(), GetPrivateProfileSectionNames() и WritePrivateProfileSection() добавлена поддержка отражения в реестр.Нихера себе! Этого до данного релиза не было, или оно просто иначе работало?
Предположу, что это были настолько "полезные" API, что их никто толком и не использовал...
> Проведена начальная работа по реструктуризации поддержки консоли.Ого, цигвин без патчей работать будет?
А еще можно вайн под всл2 запускать.
Хотя нет, https://bugs.winehq.org/show_bug.cgi?id=48891 этот патч все еще нужен. Но ошибок в вайнконсоли стало сильно меньше. Пишу коммент из-под UCBrowser, запущеного в 32-битном патченом wine-staging, собраном и запущеным в чруте 32-битной убунты 18.04, под манджарой.
links(на цигвине) - сразу уходит в сегфолт, а lynx - открывает все кроме опеннета. На опеннете - сегфолтится.
Здравствуйте! а про патчи можно подробнее? что не так "из коробки" и что допиливали?
Еще интесно зачем запускать в chroot?
Задался я вопросом сквозного тестирования свободной реализации винапи. Идея в том, чтобы под вайном, хотя-бы цигвин завёлся. Тогда мы сможем говорить о том, что у нас есть некая свободная реализация подмножества винапи, идентичная натуральной.Ну, и ради прикола проверил раотоспособность вантуз-онли UCBrowser. Ничего интереснее не придумал, а тут, внезапно есть программа, недоступная для линукса.
> что не так "из коробки"
До сих пор, из-за множества заглушек вантузные ACL не работают правильно. Дмитрий в патче сверху это подправил, но в staging это так и не попало.
> и что допиливали?
Играюсь с патчами, дёргаю пересборку. Сам ещё ничего не допилил.
> Еще интесно зачем запускать в chroot?
АааААааААааАА! https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu
Процесс сборки биарч-вайна - это билд 32-битного с установкой, а потом билд 64-битного с ещё одной установкой. Официально рекомендуют LXC с 32-битной убунтой. Для меня же чрут - дело традиции, хоть с LXC я тоже работал.
Но мой случай - немного проще. Пока-что я ограничился 32-я битами. На хосте - не забываем "xhost +" сделать.
Кстати, вспомните новость о том, как каноникал захотел резко дропнуть поддержку 32-х бит и как это не понравилось разработчикам вайна и Valve.
За Калду безусловно респект, вот то в мульте фпс был не очень на высоком разрешении экрана как помнится, может поправят когда-нибудь.) Хотя если железо - срань, то ничто не поможет.)
Попробуй Proton.
Точно, с ним было лучше, но не так чтобы положить на настроеный вайнтраком вайн, по крайней мере тогда, да и Колда два померла, вернее ее мульт. Есть обсерверы, но там за гранатомет банят.(
> Bugs fixed in 5.13 (total 22):
> 4096 IniFileMapping not Implemented (ini on win9x => Registry on NT)Красивый get.
Не работает Nvidie Geforce Now!
А он шо через вайн?!
Пха-ха, вот тебе и Now, вот тебе и облако для всех )
Да, официальная поддержка мак, вин, андроид. Хотя Громогласно заявляют на любом устройстве.
GFN вряд ли заработает под вайн, там у них какая-то жесткая зависимость к своему железу... Невозможно запустить в виртуалке, например, тоже. Хотя казалось бы зачем хардкодить? Ведь рендер же на серверах? Не? )) В общем, что-то они на мутили, а на линуксе, видимо, пока ждать стадию.
esync/fsync починили уже? Или пока лучше на старых версиях сидеть?
Врядли починили, вот сборка в которой всё работает - https://github.com/Frogging-Family/wine-tkg-git/releases
А я мучаюсь с такой вот фигнёй. Во времена Wine 3.x я починил сборку Wine в репозитории openSUSE под названием Emulators:Wine. Там нужно было одну строчку поменять, чтобы в старом дистре SLE 11 SP4 снова работала сборка. Наслаждался свежим Wine несколько месяцев, пока версия 3.19 не перестала работать. В новых дистрах всё работает и дальше. Ошибка такая:wine: Unhandled page fault on read access to 0x000000c4 at address 0x7808fd (thread 0025), starting debugger...
Я начал проверять, в каком именно коммите всё сломалось. Нашёл. Это был безобиднейший коммит, который, по идее, ни на что не должел влиять. Однако проблема оказалась глубже: эта ошибка начала появляться много версий назад. Например у меня сейчас Wine Staging 3.14, ошибка есть, но после неё всё работает. В новых версиях Wine, после неё всё валится.
Последняя сборка Wine в этом репо имеет версию 4.0: https://mirror.yandex.ru/opensuse/repositories/Emulators... В Wine 4.1 упала сборка для SLE 11 SP4, ругаясь на freetype. Я уже репортил такие сбои компиляции, а тут надоело: решил что пока с этим багом не разберусь, новых репортить не буду. А сейчас думаю: может пофиксили уже давно, просто я не могу проверить? Возникает двоякое ощущение: вроде я могу обнаружить и зарепортить сложный баг, с другой: пользователей новых дистров он не касается, а значит, никто этого не заметит...
> чтобы сборка в моём старом дистре SLE 11 SP4Eщe один местный поехавший - cидит на гoвне мамонта и компеляeт к нему новый софт 24/7.
Борцуны с системой они такиe, лол.
И против чего же я борюсь?
Против капиталистической системы, вестимо
Против капиталистической системы и прогресса за одно. Правда борятся не правильно, ведь сидят на капиталистическом железе, а должны в пещерах за самопальными калькуляторами из камней сидеть.
Это не прогресс )
Действительно, железо-то за последние 50 лет нисколько не изменилось же [сарказм].
Железо это железо, а прогресс это прогресс. Даже слова разные. Сразу высшее получать пришлось? )
Скажу ужасное: железо нисколько не изменилось. Это всё тот же Fe что и миллионы лет назад.
Заодно, прогрессмен )
Капиталистическое железо сделано руками рабочих и разрабы тоже всегда работают по найму. То что львиную часть дохода присваивает капиталист - это какой то идиотизм. Авторское право автору, а не буржую! От каждого по возможности, каждому по потребности! Вся власть Community !
Во времена ПК "Корвет" на 8-битном проце, он уделывал по скорости отрисовки графики IBM того же времени (не помню точно какие, но разрядность была больше). Были и другие превосходства СССР в электронике. С развалом Союза, страна растеряла все преимущества. Так что, причем тут политический строй или политические убеждения отдельных разработчиков? Разработчики вайна много лет делают свободный продукт не имея возможности толком рассмотреть изнутри проприетарный аналог. И что в этом плохого? Не нравится, - пользуйтесь чем нравится. Или у вас поп460ль от того, что кто-то использует сабж для своих задач, не отчисляя ничего в M$?
После отмены возможности установки системы без облаков, вероятно, придётся использовать не очень дружественный к гражданскому населению Linux. Хотя денег пришлось только раз в магазине за диск с Windows.
> Я уже репортил такие сбои компиляции, а тут надоелоЗарепорть прямиком в музeй вождя революции, там таким рады, хахахах!
Тебе же нравилась моя сборка PCSX2. Она единственная заработала в твоей Ubuntu 15.04 (последняя на тот момент версия Ubuntu). А сборка с сайта требовала от тебя таких плясок с бубном, что у тебя не получилось настроить, потому что в линуксе ты тогда был новичком. Моя же сборка работала в один клик.А всего-то надо было собрать в не самой новой системе, и нестандартные зависимости распространить с программой, подцепляя их при запуске.
Вождь в формалине уже столько лет, а пищеварение портит которому поколению неспособных на прогресс? :)
> SLE 11 SP4Поставь себе Tumbleweed и живи без геморроя!
>> SLE 11 SP4
> Поставь себе Tumbleweed и живи без геморроя!Этот дистр мне прежде всего нужен для сборки портабельных бинарников. Очень уж мне нравится писать в минимальных системных требованиях "Glibc 2.11 и выше". А если собирать в Tumbleweed, то бинарники попросят новый Glibc, а также новых вызовов из новых версий библиотек.
Например бинарники NVIDIA CUDA компилируют именно в SLE 11. В исходной системе только обновили Glib до 2.28 (для QtWebkit 5), и libopenssl до 1.0. FineReader для Linux тоже компилируют в SLE 11: https://www.abbyy.com/ocr-sdk/technical-specifications/
Интересно, на каком железе вы все это компиляете?
> Интересно, на каком железе вы все это компиляете?В облаке. Есть такой сервис, называется OBS. Там можно компилировать любую программу под любой дистрибутив Linux. Вот например мой home-репозиторий: https://build.opensuse.org/package/show/home:linux4humans:wi...
На домашнем компьютере я компилирую только в двух случаях: 1. Не осилил написать SPEC-файл (на OBS он обязателен, даже для компиляции DEB-пакетов) 2. Если нужно компилировать что-нибудь с CUDA (на OBS вроде нельзя загружать CUDA. Хотя может быть можно, если не публиковать бинарники).
Очень информативная ошибка. Я могу придумать примерно 1000500 причин её повстречать, и ни одна из них не будет связана ни с вайном, ни с приложением.
> Там нужно было одну строчку поменять, чтобы в старом дистре SLE 11 SP4 снова работала сборка.Какую?
> Ошибка такая:
> wine: Unhandled page fault on read access to 0x000000c4 at address 0x7808fd (thread 0025), starting debugger...Она ни о чем не говорит.
>Я начал проверять, в каком именно коммите всё сломалось. Нашёл. Это был безобиднейший коммит, который, по идее, ни на что не должел влиять. Однако проблема оказалась глубже: эта ошибка начала появляться много версий назад.
А можно подробнее, интересно стало. Вообще вместе с таким комментарием хочется прочитать spec. А лучше весь ваш SRPM с вашими патчами и комментариями, чтобы вникнуть.
> В новых дистрах всё работает и дальше.
> Возникает двоякое ощущение: вроде я могу обнаружить и зарепортить сложный баг, с другой: пользователей новых дистров он не касается, а значит, никто этого не заметит...Исходя из того что у вас там SLE 11 и вы его не обновляете, я предполагаю, что там что-то важное и корпоративное (куски SAP?), поэтому обновляться не предлагаю. Давайте исключим очевидную проблему со сборочным окружением и зависимостями.
Для начала я, лично, попытался бы удовлетворить требование к версиям зависимостей, предполагая, что wine неверно сообщает о версиях в документации для unstable ветки, дескать, они там могут измениться между минорными релизами. Нужно составить список всего что ему нужно по зависимостям. Включить в список версии пакетов для сборки с их версиями. Всё что не удовлетворяет минимальной версии в SLE11SP4 просто туда пересобрать. Причем так чтобы это была сборка в RPM на основе аналогичных SPEC-ов из SLE11. Собрать это все надо в какой-то префикс и чрутануться туда чисто для задач последующей сборки вайна. И вот там уже наваять решение. Все новые зависимости надо бы статикой к нему прилинковать, на всякий случай. И посмотреть что выйдет.
Альтернативно, можно действовать наоборот. Раз у вас там ентерпрайзный дистр и есть ентрепрайзный софт, которому требуется вайн, возможно имеет смысл собрать минимально допустимую версию вайна и бекпортировать патчами нужные вам изменения из более свежей версии... Хотя зачем я обманываюсь. Это же вайн... Там такое сделать сложнее чем ядром Linux.
>> Там нужно было одну строчку поменять, чтобы в старом дистре SLE 11 SP4 снова работала сборка.
> Какую?Строчку типа pkgconfig(appname) на appname-devel
> А можно подробнее, интересно стало.
Если ты будешь в этом треде завтра-послезавтра, расскажу о проблеме подробнее
Единственная нужная программа.
Эмулятор не может быть единственно нужным... Хотя может кому-то winemine хватает.
Если на платформе нормального софта нет, то вайн незаменим.
А ведь нету совсем :)
Тролль или просто дурачок? Хотя, сейчас даже самый забитый дурачок понимает разницу между эмуляцией и трансляцией.
Diablo 2 на нём запустится?
Хватит уже каждую новость про релиз вина это писать, вам же говорили в ответ, что фурычит и давно. Если же нет, а такое может быть даже из-за акдио как с ведьмаком3, то пробуйте winetricks и откажитесь от Пульсф и asoundrc.
Возможно написание пошаговой инструкции с положительным (хотя бы 98%) результатом для широко используемого ПО?
С бубном все запускается.
Версия 1.13 с якобы "CD" запускается через Lutris без проблем. Да и без Lutris на голом wine запускается
> потому что в линуксе ты тогда был новичком.Похоже изменилось не многое, топовое железо антипод гика самоучки.)
Любопытно, с момента выпуска Wine 1.0. сколько было закрыто отчётов об ошибках и внесено изменений?
Да Wine теперь лучше Windows должна работать!
Разве лозунг СПО не "никто тебе здесь ничего не должен!"? )
> Да Wine теперь лучше Windows должна работать!Увы,р егресс часто обламывает такое утвеждение, но в целом игры до 2017 в вине как правило чувствуют себя лучше.
Доказательств, что игры до 2017 работают лучше в wine, конечно же не будет...., ведь ботяры с opennet могут лишь набрасывать г на вентилятор и хейтить винду, да и вообще все подряд.
> Доказательств, что игры до 2017 работают лучше в wine, конечно же не
> будет...., ведь ботяры с opennet могут лишь набрасывать г на вентилятор
> и хейтить винду, да и вообще все подряд.Он имел в виду после, это же очевидно. Только mediafoundations и xaudio в вайне не очень работают, а в остальном вполне, сегодня запускаешь игру в день выхода и играешь в вайне не хуже венды (в венде с играми не очень, да).
Суть того же вайна не в сделать как в винде, только лучше, а сделать так же( в т.ч и повторить имеющиеся там баги, поскольку на них нередко опирается часть функционала отдельных программ ).То, что игры именно лучше работают - хз, но то, что запускать их удобней, нежели иметь пачку виртуалок - это да.
Если используется транслятор в Vulkan, то да, некоторые игры работают лучше, чем на Венде.
"Игр, приложений".. тьфу! Промышленный софт запустится? - Есть одна кривая поделка на wxPython вроде бы..
> Промышленный софт... Есть одна кривая поделка на wxPythonГотово к продакшну!
Это тебе смешно. А мне с этим работать мля..
Зарабатываешь на промышленном софте, жлобишься тратить на него и его платформу деньги.
> Зарабатываешь на промышленном софте, жлобишься тратить на него и его платформу деньги.Но что если ему не нравится платформа? Венда любому адекватному человеку не нравится, почему он не может выбрать более удобную платформу взамен навязываемой?
Можно в шахтёры или футболисты. Или сценарии зубрить, тротуары подметать...
Еще немного и виндовс сделают :)
Самая проблема в том, что закрывают одни ошибки и при этом появляются другие. Автоматизация тестов по всем закрытым ранее проблемам, вот что может помочь вайну. Жаль что нет никого кто бы хотел это всё финансировать, а это очень большие суммы и частными пожертвоаниями здесь не поможешь. Идея хорошая, но только как песочница для развития системных разработчиков. Иначе, если вам не повезёт, что случится с вероятностью 90%, вы рискуете потерять время на решение множества проблем возникающих то тут то там и ещё где то, и в конце не найдёте работающего решения.