Началось тестирование первого кандидата в релизы Wine 10.0, открытой реализации WinAPI. Кодовая база переведена на стадию заморозки перед релизом, который ожидается во второй половине января. По сравнению с выпуском Wine 9.22 закрыто 17 отчётов об ошибках и внесено 311 изменений...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62362
> рискованные патчи, пока непригодные для принятия в основную ветку WineЗабавно, бегло глянул - есть патчи возрастом под 8 лет...
Настоявшиеся.
Принимаются только совершеннолетние патчи.
Если Вайн такой хороший и про него все время новости зачем нужен нативный клон вторых героев без ресурсов?
Затем, что кому-то так зачесалось.
Вайн, увы, не такой хороший. Поскольку большей частью ориентирован на актуальную винду, а вовсе не на дотошное воспроизведение особенностей всех выходивших. И поддержка всякой экзотической древности со временем протухает, либо с давних пор так и не реализована.Опенсорсные нативные движки всегда будут производительнее, совместимее и экономнее, нежели экзешник для другой архитектуры через несколько прослоек.
А кому он будет нужен, если будет ориентирован на не актуальную Винду ?Не все ведь счастливые владельцы коры дуба
Счастливые владельцы Коры Дуба счастливы и с нативным GNU/Linux.
Да ну, бред какой-то. Вайн отлично запускает софт 90х.
1) к сожалению, нет
2) требования к видеокарте всё растут.
Это было не утверждение а факт
Насчёт того, что «к сожалению, но нет»? Бесспорно, факт. Потому что я, в отличие от диванных апологетов, пытался вайн для этих целей применить. И оказывается, что если шаг влево, шаг вправо от популярных тайтлов — всё очень печально.
Ну то что у виндузятников руки кривые это и так все знают... Нашел чем гордиться...
Бинго! Кривые руки, конечно!
Ну вот когда не будут требоваться для запуска софта под вайном особенные руки, тогда и поговорим. А пока — малоюзабельно.
https://opennet.ru/60991-openttd
> Поскольку большей частью ориентирован на актуальную винду, а вовсе не на дотошное воспроизведение особенностей всех выходивших. И поддержка всякой экзотической древности со временем протухает, либо с давних пор так и не реализована.Вы то ли врете, то ли не сталкивались с этим.
Как раз у Вайна совместимость со старыми играми лучше, чем у последних версий Винды - настолько, что даже люди тянут его куски под Винду (см. WineD3D). При чем так есть уже лет 10 как минимум - сам примерно в 2013 проходил XIII (2003), где уже под конец игры при запуске очередного уровня был тупо черный экран. Перекинул сохранения на Линукс, и под Вайном прошел до конца без проблем. Причем это была Windows 7, а последних ее версиях с постоянно отваливающимися дровами ситуация гарантированно еще хуже.
> Опенсорсные нативные движки всегда будут производительнее, совместимее и экономнее
Это только если у разработчиков этих движков не чешутся руки наворачивать все современные технологии рендеринга на игру из 90х, как это делают авторы 90% портов Doom.
Оригинальные Герои 2 выходили под DOS и Windows 95. fheroes2 можно запустить даже на смартфоне на ARM.
Даже в браузере https://dos.zone/heroes-of-might-and-magic-ii/
Зачем нужен GZDoom, когда есть Doom 95?
Чтоб видеокарту грузить. В простой Doom без 3d ускорителя играть можно, даже без сопроцессора на 386.
В GZDoom тоже без ускорителя играть можно. Но кроме поддержки ускорения у него, мягко так скажем, есть ещё много отличий.
А на 386 играть можно было разве что в разрешении 160×200 (потому что Doom всё же не пошаговая игра).
на SX-16 ?
Нифига что вспомнил
Вы так это говорите, как будто никогда восьми дюймовых дискет не видели )))
Я видел. В коробке из-под тульских пряников. Идеально коробочка подходила. :)
На DX-40. На SX-16 будет вообще пара fps.
non-x86 arch ?
Потому что нативный клон использует GPU, а оригинал был создан тогда, когда GPU были только на промышленном оборудовании.
скорее зачем вайн, когда есть натив
Отрадно видеть столь быстрый рост номера версии, и количество игр доступных мне в стиме.Но есть вопрос: запретят ли вайне 11 перемещение панели задач?
Вот из-за таких хом которым нужен рост версии, а не функционала все это происходит.Ждём коммент товарища у которого аллергия на слово функционал.
Шикарная новость. Глядишь к январю к выходу wine 10 мультилиб допилю. Скворешники летают, сосредоточиться мешают.
Зачем тебе мультилиб, когда вайн давно с WoW64?
Старый 32-битный софт и игры запускать.
Wow64 подразумевает возможность запуска 32 битного софта.
wow64 там до сих пор в экспериментальном режиме, и его наличие совершенно не гарантирует запуск 32-битных приложений, поэтому - мультилиб как у камрада выше.
>добавлена возможность использования символов UTF-8 в файловых путяхВ именах можно использовать эмодзи. Уррряяя! :)
Использовать можно только приложение тебя не поймет.
Кто-нибудь знает, чего для библиотеки EMP.dll не хватает?Она пытается загружать функции как библиотеки:
0148:trace:module:load_dll looking for L"GetModuleHandleA.dll" in C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
0148:warn:module:load_dll Failed to load module L"GetModuleHandleA.dll"; status=c0000135
Попоробуй редисты, powershell поставить.Также, попробуй разные версии вайна.
Это проблема в ядре, GetModuleHandleA не должен грузиться как библиотека, но я не могу протрейсить вызовы, потому что денува начинает бесконечно срать в логи, когда обнаруживает переменную отладки.
При чём здесь ядро?1. Где-то вызывается GetModuleHandleA, что бы найти какую-то dll.
2. GetModuleHandleA возвращает NULL, поскольку в списке загруженных dll не обнаружена.
3. Программа делает вывод "надо загрузить такую dll" и вызывает LoadLibrary с именем "GetModuleHandleA" (вот это и видно в журнале отладки).Похоже, что на шаге 1 был вызов GetModuleHandleA("GetModuleHandleA").
Как так получилось - это уже другой вопрос. Но я бы не исходил из предположения "авторы Денуво - кретины". Наверняка она может делать это самое не только в лог. ;)
Потому что функции kernel32.dll он пытается загружать как dll файлы. Там около 50 аналогичных вызовов dll.Попытка протрейсить это поведение приводит к тому, что denuvo начинает бесконечно писать в логи, пока не заполнится файловая система.
А ещё зачем-то дергается SGDT инструкция.
Я очень не люблю что-то тупо трассировать в отладчике, потому предпочитаю предварительно понять, что там вообще происходит и почему. Почему "функции kernel32.dll он пытается загружать как dll файлы" я предположил выше. Соответственно, повторение мне в ответ и так известного не требовалось.Попробую упростить предположение: так проявляется антиотладка денувы.
>sudo apt install wine-staging
>Некоторые пакеты не могут быть установлены. Возможно, то, что вы просите,неосуществимо, или же вы используете нестабильную версию дистрибутива, где
запрошенные вами пакеты ещё не созданы или были удалены из Incoming.
>Следующая информация, возможно, вам поможет:
>Неудовлетворённые зависимости:
> libgstreamer1.0-0:i386 : Зависит: libunwind8:i386 но он не может быть установленПора закрывать проект Дебиан целиком. Они не в состоянии (банкроты то есть) поддерживать свою пакетную базу в непротиворечивом состоянии.
ты можешь закрыть его сам для себя целиком прямо сегодня.
У моего знакомого было что-то похожее на MX Linux. Он подключил Debian Unstable, поэтому часть пакетов оказалась новее, чем в репозитории Debian (а часть 64-битных пакетов не соотвествовала 32-битным). Решилось тем, что в репозитории MX Linux есть пакеты и для Unstable. Подключили дополнительный репозиторий - и смогли установить зависимости для Wine.
Чойта вспомнился бородатый анекдотВключил компутер, загрузился Нортон... Смотрю - у меня слева диск С: и справа диск С:... Я и подумал - нафиг мне два диска С:? И стер правый к чертовой матери!
>libunwind8/unstable,testing 1.6.2-3.1 i386Зависимости есть. Просто видимо где-то что-то гвоздями прибито к номерам версий через ==.
Попробуй низкоуровневое редактирование DEB-пакета. Распаковать, отредактировать control и запаковать.
Можно, но зачем? Cvsck lbcnhf - d njv? xnj,s gfrtns ,skb ujnjdst? f yt cfvjve gfrtns cj,bhfnm bk htlfrnbhjdfnm/
Можно, но зачем? Смысл дистра - в том, чтобы пакеты были готовые, а не самому пакеты собирать или редактировать.
Ну вот скажем, у меня в Ubuntu 9.10 был Glibc 2.10. Я обновил его до 2.12, и получил ошибку в пакете upstart. Там каким-то чудом встала зависимость glibc > 2.9 и < 2.11. Причём всё работало. В итоге я перепаковал пакет upstart, убрав эту зависимость, что и починило apt.В Debian 7 была похожая ситуация. Пакет libp11-kit0 имел нормальные зависимости, однако в бэкпортах доступна новая версия пакета, в котором была прописана зависимость Glibc < 2.14 (в системе 2.13). Я установил Glibc 2.17 (есть готовый репозиторий SteamOS 1.0 beta, который базируется на Debian 7), и до тех пор, пока не пользовался бэкпортами, всё было нормально. Но как только я установил все обновы из бэкпортов - долго пришлось голову ломать, какой именно пакет разрушил apt.
Решилось также редактированием метаданных пакета.
C вайном ситуация другая. Мне за всё время, с тех пор, как я с этой фигней столкнулся несколько месяцев назад, вайн ни разу не нужен был.
>Они не в состоянии (банкроты то есть) поддерживать свою пакетную базу в непротиворечивом состоянии.А зачем вы установили дебиан, широко известный своими проблемами с пакетами? Ставили бы NixOS
stable там ок, только обновляется раз в два года.Ну а все другое для использования не подходит.
Надо принудительно откатить версию libunwind8:amd64 на 1.6.2-3.1 из testing, либо на 1.7.0~rc2-1 из experimental. 1.7.2 не собирается под i386, поэтому ошибка в unstable и возникла. Они пока решают, бэкпортировать ли патчи, или просто обновить версию библиотеки.
При подключённом testing репозитории:
>sudo apt install libunwind8:amd64=1.6.2-3.1 libunwind8:i386При подключённом experimental репозитории:
>sudo apt install libunwind8:amd64=1.7.0~rc2-1 libunwind8:i386=1.7.0~rc2-1
Но вот интересный вопрос. Насколько велик вклад Вайна в демотивацию геймдевов и остальных разрабов ПО разрабатывать для Линукс? Потому,что во-первых, Вайн всегда крив сам по себе. Во-вторых, навряд ли его отсутствие побудило бы серьёзных разработчиков прикладного ПО и игрулек работать на онтопик.
А откуда у них вообще такая мотивация возникнет?
Как там обстоят дела с многопоточностью? Починили? По идее,её должны были починить,исходя из некоторых коммитов,относящихся к ядру (ntoskrnl.exe,ntdll,kernel32).
Выбери стул:wineserver sync - медленное уг
esync - уже быстрее, но это posix open костыли и совместимость страдает.
fsync - ещё быстрее, но совместимость страдает.
ntsync - всё красиво, но udev не настроен ни в одном дистрибутиве. В вайне его нет. Собирается также геморройно.
Исходя из этих коммитов,многопоточность есть,но в ОЧЕНЬ зачаточном состоянии:https://gitlab.winehq.org/wine/wine/-/commit/e01b70851fae74c...
https://gitlab.winehq.org/wine/wine/-/commit/dc7bdc3db6aa057...
https://gitlab.winehq.org/wine/wine/-/commit/0495948d00b4a6f...
А как она сейчас работает?
Тоже интересно, все на одном потоке?
Интересно, зачем я сюда заглянул...
"msvcrt: Initialize locale data in new threads"Тут написано про то, что многопоточность давно есть, и с ней проблем нет.
ntdll: Introduce a separate per-thread object for internal completion waits.
А вот это - про ожидание на объекте ядра. Зачем бы потоку что-то ждать, если он всего один? И что бы при этом случилось с системой?
По поводу ntdll:тут суть в том,что КАЖДЫЙ поток будет ждать СВОИ объекты отдельно от ДРУГИХ,насколько я понял. Поэтому и написали per-thread. Т.е на каждый поток. Но... Всё это только лишь первые наработки. Стабильность должна будет улучшиться. Правда,для этого,нужно будет допилить ядро (ntoskrnl,ntdll,kernel32). Надеюсь,они смогут его допилить.
> Встроенный пакет Vkd3d с реализацией Direct3D 12 обновлён до версии 1.14.Он точно встроенный?
Почему при запуске игр на Unreal Engine 4 они сообщают, что не находят dx12 и приходится запускать их с флагом -dx11, если он встроенный?
Вообще нет, надо доустанавливать отдельно. В сусе уже собрано с vkd3d.
Как там дела с non-Unicode программами,кто знает?
Покажите мне Стриммера, который запускает современные игры на Wine.
Что то я помню пробовал запустить Supreme Commander, но не через Wine, а через proton. Помню там в меню все дико лагало и тормозило. На windows норм. https://ratfactor.com/cards/arch-gaming
Все это дальше разговоров не заходит. Linux это хорошо, но и в игрушку иногда хочется поиграть. Вот думаю может Valve займется.
Это скорее для кринжа.
Стримера не подскажу. А сам недавно прошел Prototype, Stalker shadow of Chernobyl, Doom 2018, Doom Eternal, Doom bfg.Все ок.
Все равно все эти wine, proton это костыли.
Да, это так. Но если я хочу поиграть в игру, есть ли мне дело до того, как она работает, если она работает!?Я не думаю, что даже если бы разрабы кинулись бы делать под Linux, кто-то тратил деньги на переделывание старых игр типа prototype, stalker и т.д. Я бы тупо не смог играть в кучу игр. Зато мог бы чувствовать, что все эталонно.
И, кстати, в той же винде хватает костылей для совместимости, о чем постоянно ноют разрабы wine. Но это лучше, чем если каждый релиз будет отсекать огромный пласт софта или тот бред, как у playstation, где тебе нужно доплачивать за "обновленную" версию.
Короче, мир не идеальный, и решений требует таких же.
Самое интересное,что у Wine есть много интересных и довольно стабильных (для Wine 10.0)коммитов,но с ними не торопятся. Почему? Неизвестно...