Началось тестирование первого кандидата в релизы Wine 6.0, открытой реализации Win32 API. Кодовая база переведена на стадию заморозки перед релизом, который ожидается в середине января. По сравнению с выпуском Wine 5.22 закрыто 53 отчёта об ошибках и внесено 457 изменений...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54197
Trine 4 уже вышла? Ого. А почему не было новости на ЛОРе?По поводу новости. Я предлагаю каждому тестеру запустить и прогнать свой софт, которым вы обычно пользуетесь в Wine. Проверить на ошибки. И в случае обнаружения таковых, запостить баг. В этом и есть суть бета-теста.
А то вы же знаете, как это бывает. Про беты и релиз-кандидаты никто обычно не слышит даже, и единицы их тестируют. Зато потом "какой сырой релиз, почему не тестировали?".
> Trine 4 уже вышла? Ого.С возвращением из анабиоза.
Wine и всё причастное к нему - замечательный проект. Успехов разработчикам.
Вайн ещё делают? Там же, вроде, оба студента выпустились и работать пошли, не до вайна теперь им.
С возвращением из анабиоза.Это было несколько лет назад. Речь шла не о Wine, а о Wine Staging. Этим студентам в течение месяца нашли замену. Wine Staging и по сей день развивается.
>Wine StagingЭто просто нестабильная ветка Wine.
Ну они тогда получается какие-то вечные студенты. С 1993 года.
>вечные студентыВек живи -- век учись.
речь шла наверное, не о тех первых студентах
О нём самом, Alexandre Julliard.
Какие студенты, там же контора теперь этим занимается.
https://www.codeweavers.com/
Масштабирование позволяет и уменьшить размер HUD. В принципе, если используется что-то помимо фреймрейта, удобно, чтобы текст не занимал пол экрана.Кстати, вот текущая версия скрипта обновления dxvk из комментариев прошлой новости (извините, если опеннет поломал код):
#!/bin/sh
#deps:curl, patch, gcc (mingw-w64, built with --enable-threads=posix), meson, ninja, glslang, wine-staging
XTRAOPTSMESON=(--unity on -Db_lto=true)
COMMON_FLAGS="-march=native -O2 -pipe -fomit-frame-pointer -fno-fat-lto-objects -fno-semantic-interposition"
TEMPDIR="${HOME}/dxvk"
# gcc flags
COMMON_FLAGS+=" -fipa-matrix-reorg -fipa-pta -fdevirtualize-at-ltrans"
# gcc lto
COMMON_FLAGS+=" -flto -fuse-linker-plugin -flto-partition=max -flto-compression-level=9"
# use relaxed flags (same as wine)
COMMON_FLAGS+=" -U_FORTIFY_SOURCE -fno-stack-protector -fno-stack-clash-protection"
export CFLAGS="${COMMON_FLAGS}"
export CPPFLAGS="${COMMON_FLAGS}"
export CXXFLAGS="${COMMON_FLAGS}"
export LDFLAGS="-Wl,-O1,-z,relro,-z,now,--sort-common,--as-needed,--hash-style=gnu,--no-copy-dt-needed-entries -fuse-linker-plugin -fuse-ld=bfd -flto=4"function ckwine() {
# validate config (gentoo specific) //from setupwine script
curwine=`eselect wine show|tail -1|sed 's/\s*//'`
curwine=${curwine:0:12}
if [[ ${curwine} != 'wine-staging' ]]; then
echo "Please set default wine to wine-staging (i.e. eselect wine)"
eselect wine list
exit 1
fi
}
function gtarch() { case $(uname -m) in x86_64) BITS=64; ;; i*86) BITS=32; ;; *) BITS=?; ;; esac }
function ckarch() { gtarch; [[ 64 -eq "${BITS}" ]] || { echo "${BITS} bit arch is unsupported"; exit 1; } }
function cleanup() { rm -rf -- "${TEMPDIR}" && echo "${TEMPDIR} removed"; }
function die() { [[ 0 -ne $? ]] && { local rc=$?; trap '' EXIT; cleanup; echo "${1}"; exit $rc; } }
function dienow() { local rc=$?; trap '' EXIT; echo "${1}"; exit $rc; }
trap cleanup EXIT;
ckarch
gittag="${1}"
[[ -n "${WINEPREFIX}" ]] || export WINEPREFIX="${HOME}/.wine-64"
[[ -f /etc/gentoo-release ]] && ckwine
# clean old && download
[[ -e "${TEMPDIR}" ]] && echo "Note: ${TEMPDIR} is found on disk, force removed." && rm -rf -- "${TEMPDIR}"
if [[ "${gittag:0:7}" == 'release' || "${gittag:0:1}" == 'v' ]];then
echo "Using branch: ${gittag}"
git clone --single-branch --depth 1 --branch "${gittag}" https://github.com/doitsujin/dxvk.git ~/dxvk || die 'Failure: git clone.'
else #master
git clone --single-branch --depth 1 https://github.com/doitsujin/dxvk.git ~/dxvk || die 'Failure: git clone.'
fi
cd "${TEMPDIR}" || die 'Failure: not found on disk.'
#patch async
curl --tlsv1.2 -sSLO https://raw.githubusercontent.com/Sporif/dxvk-async/master/d...
patch -p1 < dxvk-async.patch || die "Failure: async patch."
#build
meson --cross-file build-win64.txt --buildtype release --strip --prefix ${PWD}/x64 --bindir ${PWD}/x64 --libdir ${PWD}/x64 build_64 "${XTRAOPTSMESON[@]}" || dienow "Note: meson failure (see above for info)."
cd build_64
ninja install || die "Failure: couldn't install (64)."
cd ..
meson --cross-file build-win32.txt --buildtype release --strip --prefix ${PWD}/x32 --bindir ${PWD}/x32 --libdir ${PWD}/x32 build_32 "${XTRAOPTSMESON[@]}" || dienow "Note: meson failure (see above for info)"
cd build_32
ninja install || die "Failure: couldn't install (32)."
cd ..
#install
chmod u+x ./setup_dxvk.sh
WINEARCH=win64 ./setup_dxvk.sh install || die "Failure: couldn't setup wine (more like wine failed)."
ПС в 5.22 я так понимаю ОПЯТЬ поломали миграцию префиксов на новую версию, из-за чего старые префиксы перестали работать? Сколько можно то уже. system32\\ole32.dll и system32\\shlwapi.dll просто не работают, и без них вайн не работает. Или это ещё в 5.18 поломали (опять) и дальше доломали? Я вообще-то с 18 на 22 обновился, да. Пришлось, так бы 5.17 оставил, с ней всё нормально было.
с 5.17 на 5.22
Они много чего поломали в 5.20, особенно много поломок в kernel32, в 5.22 часть kernel32 починили, но далеко не все, что сломали
Ой там в git clone можно заменить ~/dxvk на "${TEMPDIR}", иначе при изменении TEMPDIR в шапке, всё сломается.
>Cгенерированный годМесяц, день. Rprt.
На Wine 6.0 будет работать Paint из Windows 7?
Да нет конечно
Да
Даже любопытно стало. :)
При всем моем уважении к wine, но она как не толком не работало, так и не работает
> Браузерный движок Gecko обновлён до версии 2.47.2.Вот о чём говорят эти числа? Как узнать, какой версии движок Gecko в актуальной версии Firefox 83? В About этой важной информации нет.
> Добавлена поддержка именованных каналов с пустым именем.А подробнее: где они используются?
Я конечно не знаток и могу ошибаться, но...Скорее всего это используется в USB-стеке, когда ендпоинт на стороне USB соединяется с софтиной на хосте через пайп у которого нет собственного имени, а в роли пути подключения выступает путь к файлу устройства.
Спасибо. Улучшения USB в wine давно ждём.
>формат PEЧто это?
https://en.wikipedia.org/wiki/Portable_Executable
Когда-нибудь они напишут свою OS.
ReactOS
Как у них с поддержкой Wayland?
Никак. Они сказали, что существуют непреодолимые препятствия и заморачиваться этим не будут.
То есть через лет 5 они останавливают развитие проекта?
Думаю, раньше. Наркоманы так долго не живут, помрёт вместе со своими двумя фанбоями.
>То есть через лет 5 они останавливают развитие проекта?Через лет 5 уже придумают новую замену вяленому.
Земля им пухом
Что за хамство, где ссылка на бездырные патчи? А ну бегом марш!
в чем хамство, шизоид? вот ты хамишь постоянно тут
Он таблетки забыл выпить.
Авторы молодцы, продолжают работу. Даже при версии 4.0 весь мой софт нормально работал, сейчас же это наверняка уже пригодное к использованию решение.Тем, кто использует Wine, будет полезно.
Не факт. Это вечные догонялки.
Больше вопрос: когда можно будет использовать напрямую PipeWire для вывода звука. Как никак, PulseAudio уже legacy скоро станет, + это уменьшит задержку. Не надо будет настраивать больше ничего и патчить библиотеки Wine'а (как это было с winepulse).
Audacity под wine?
Один вопрос: зачем?
Этот вопрос встречается почти в каждом треде про wine в разных формах, но шаблон такой:
Зачем использовать <название программы> из-под wine, когда есть нативная версия для Linux.И далее следует ряд ответов:
1) wine - это кроссплатформенная _реализация_ API Win32. Если возникает проблема c <название программы>, то это проблема в реализации функций API, которые с высокой долей вероятности проявятся и с другими программами.
2) wine - это кроссплатформенная _реализация API_ Win32, а не программа-эмулятор Windows для запуска программ, которых не достаёт пользователям
3) wine - это _кроссплатформенная реализация API_ Win32, кроссплатформенная, а не для Linux. Мало ли что там в Linux есть.Выберете, который из трех вам нравится больше.
Всё-таки для развития экосистемы Линукс гораздо полезнее писать линуксовые приложения, а не тащить виндовые программы в линукс через прослойку.
Для развития экосистемы Linux необходимо предоставить разработчикам единое стабильное API между всеми дистрибутивами и SDK для разработчиков. Тогда появятся нативные приложения отличные от платформы электрон и прочей вебни.Проблема экосистемы Linux выражается в её токсичности. Например, повсеместный NIH и люди которые будут просто против какого-то приложения или какой-то технологии, просто потому что им там что-то не нравится по религиозным или политическим причинам, хотя они не способны самостоятельно предложить альтернативное решение. "Баба Яга против!", короче говоря.
Программ пишут разработчики ПО, а для них не инструментов хороших нет, ни позитивной и продуктивной атмосферы, зато вместо этого есть такая сущность как меинтейнер дистрибутива, которая не пропустит твою программу в свой дистр, потому что лицензия не достаточно открытая. Если же лицензия открытая, то пропустит её в той форме в которой он хочет её распространять. Лишняя проблемная прослойка между разработчиком и пользователем, нужная лишь затем, что нет стандарта ОС, API и универсальных способов распространения, если таковой не считать doker.
Трудозатраты на поддержку нативного ПО на Linux со стороны независимых разработчиков настолько высоки, что проще этого не делать. А если и делать, то давать огрызок под открытой лицензией без грамма поддержки и ответственности, чай кто-то подберет и добавит как 10001-й пакет в дебиан.
Горькая правда в том, что wine под Linux имеет более надёжное и стабильное API чем весь остальной Linux вместе взятый, если не считать разве что контейнерные среды и веб-технологии.
>[оверквотинг удален]
> проблемная прослойка между разработчиком и пользователем, нужная лишь затем, что нет
> стандарта ОС, API и универсальных способов распространения, если таковой не считать
> doker.
> Трудозатраты на поддержку нативного ПО на Linux со стороны независимых разработчиков настолько
> высоки, что проще этого не делать. А если и делать, то
> давать огрызок под открытой лицензией без грамма поддержки и ответственности, чай
> кто-то подберет и добавит как 10001-й пакет в дебиан.
> Горькая правда в том, что wine под Linux имеет более надёжное и
> стабильное API чем весь остальной Linux вместе взятый, если не считать
> разве что контейнерные среды и веб-технологии.вы написали бред и далёкие от правды вещи примерно в 90% поверхности этого тексты
зы: о каком нужном стабильном апи линукса вы говорите, если ядро линукса имеет максимально стабильное юзерапи, даже иногда баги отказываются править, чтоб не сломать юзерапи ядра?
зыы: и разрабам не обязателбно ни само апи, ни стабильное апи ядра, обычно для этого есть фреймворки
а для нужных версий фреймворков есть системы типо nixpkg
Чтобы разрабатывать софт, нужно бабло (миллиарды USD, возможно триллионы).А запускать готовый вендо софт намного дешевле, создавая унифицированный для всех вендопрограмм WINE.
> Чтобы разрабатывать софт, нужно бабло (миллиарды USD, возможно триллионы).Вы тоже предполагаете зимбабвийский сценарий?
Столько лет, а командную строку так и не починили. Она там реализована явно по остаточному принципу. До сих пор сложные батники не работают как надо, а запуск командной строки из-под другой программы или крашит её, или вообще не выполняет.
Покажите ссылки на ваши багрепорты, пожалуйста, или на чужие с вашими комментариями и голосами!
Командную строку они починили,правда,частично.Wine Git:
https://source.winehq.org/git/wine.git/commit/8e54cad6a15b39...
https://source.winehq.org/git/wine.git/commit/d1790c984bebb5...
https://source.winehq.org/git/wine.git/commit/81fe7a2165ed24...
https://source.winehq.org/git/wine.git/commit/fc1bb9aff5c5af...
https://source.winehq.org/git/wine.git/commit/a19a770f96ca1b...
https://source.winehq.org/git/wine.git/commit/abe848f05f5d91...Правда,это не меняет факта,что многие вещи в cmd.exe сделаны через один известный орган.