Выпуск Wine 1.7.5

Может бубунтовский ppa использовать? Оно вроде с дебианом совместимо и инфраструктура вся готовая.

Всё равно перепаковывать надо. Зависимости разные, и т.д. Сложности больше.

Mass Effect 3 перестал запускаться после обновления на эту версию. Откатился на 1.7.4.

Удивлён, правда в этот раз у меня nvidia, а не швабодка амд.

Хехе, ну, а чего удивляться? Хочешь нормально работающую карту в линуксе - берёшь nvidia.

Хехе, ну, а чего удивляться? Хочешь нормально работающую карту в линуксе - берёшь nvidia.

Берешь AMD HD 7xxx серию. С AMD еще и коины помайнить можно, а nvidia-ии сильно тормозные.

С AMD еще и коины помайнить можно

А ещё можно пойти поработать, это более эффективно, например.

А ещё можно пойти поработать, это более эффективно, например.

Особенно в свете грядущих ограничительных мер в РФ, на потребление электроэнергии майнинг утюжками.

Играю в Crysis 3 - полет нормальный!

А как там обстоят дела с Medal or Honor, Battlefield 3 и Call or Duty; можно уже сносить венду?

Привет. А есть спецы по Wine Кто знает почему richedit не показывает урлы http://code.google.com/p/flylinkdc/issues/detail?id=1364 ? Сами rtf-ки с урликами и под виндой пашут http://flylinkdc.googlecode.com/svn/trunk/compiled/

А как там обстоят дела с Medal or Honor, Battlefield 3 и Call or Duty; можно уже сносить венду?

Call of Duty 1 нормально, старшие версии плохо. Оставайся в дуалбуте.

Battlefield 3

Не нужно. Кроме полигонального мыла ничем не доставляет.

Зависит от видеокарты\драйверов.

Игры

Wine

Дети, а теперь все вместе давайте позовём Деда Мороза Shaman007 и спросим, смотрит ли он, в какой раздел идёт новость. Перенеси в OpenSource, будь мужиком!

Особенно в свете грядущих ограничительных мер в РФ, на потребление электроэнергии майнинг утюжками.

Хорошо. Идите работайте и покупайте себе nvidia карты. А я буду вкладываться по возможности в то железо которое себя окупает. AMD карты себя отбили.

Ну хз, даже нищеброды могут позволить себе nvidia-карты.

Ну хз, даже нищеброды могут позволить себе nvidia-карты.

C nvidia у меня были проблемы, а с AMD - нет. Ну и мне нужна производительность под opencl.

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

А что, это возможно? Да и не такой уж и большой мультилиб - около 15-и i386-пакетов установится. Хотя я и сам хотел бы 64-онли систему.

Кроме полигонального мыла ничем не доставляет.

Ты на пс3 играешь? Или вообще никогда не запускал?
В четвёртой батле на консольки вообще забили, как сказали в одном из обзорах - на консолях камрип.

А что, это возможно?

Почему нет? Даже dosemu отучили от мультилиба, и он отлично крутит 32-битные досовые игрушки в 64-битной операционке, вызывая 64-битные нативные либы. Не думаю, что в вайне принципиальные отличия, а просто, скорее всего, всем лень.
https://ru.wikipedia.org/wiki/WOW64
Но здесь я хотел кого-то знающего спросить, а не собственные догадки излагать. :)

Я имел в виду что кроме графики оно ничем не впечатлило. Современные игры уже мало впечатляют. Необычных тайтлов не так уж и много.

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

Месье нашел сравнивать небо и землю. Архитектуры -то разные. В линуксе никогда не будет так же как на винде.

Вайн реализовывает виндовые концепции и виндовые внутренности. А WoW64 позволяет 32-битным виндовым прогам работать на 64-битной винде. В свою очередь, wine64 поддерживает как раз 64битные проги, а для 32битных требует мультилиб. И что, по вашему, мешает гонять WoW64 под wine64? И под этим всем уже 32битные проги.

а для 32битных требует мультилиб линуксовый

Потому что сам вайн их требует.

Потому что сам вайн их требует.

Что мешает ему довольствоваться их 64битными аналогами? Ещё раз говорю: wine64 их _не_ требует. Вот только он пока не умеет 32битные проги гонять, ибо никто не запилил под ним Wow64. Впрочем, кажется, и не думают пилить.

Впрочем, кажется, и не думают пилить.

И не запилят, потому что смешивание 32- и 64-битного кода в рамках одного процесса невозможно в принципе ибо различия этих архитектур размерами указателей не ограничиваются. И не надо тут про WOW64 — такой же мультилиб, как и в Linux, с отдельным набором 32-битных библиотек; никакой WOW64 не позволит коду напрямую обратиться к библиотеке, скомпилированной для другой архитектуры. Эмуляторы DOS тут тоже не в тему, т.к. сами DOS-овские программы ни про какие .dll/.so/... знать ничего не знают.

И не запилят, потому что смешивание 32- и 64-битного кода в рамках одного процесса невозможно в принципе

Да вы явно не в теме. Советую почитать man modify_ldt (найдите там флаг seg_32bit) и man mmap (найдите там флаг MAP_32BIT). А потом расскажите разработчикам досему, что, оказывается, создавать 32битные сегменты вышеозначенными способами, и передавать туда управление через iret, в рамках одного процесса невозможно...

И не надо тут про WOW64 — такой же мультилиб, как и в Linux

Я и не против мультилиба на стороне винды. Пускай этот WoW64 дёргает кучу 32битных виндовых dll'ек под wine64.

Эмуляторы DOS тут тоже не в тему

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

Ну, в современных системах для запуска DOS-овских программ без эмулятора-гипервизора в любом случае не обойтись, т.ч. там можно было заморочиться. Для вайна же, некоторые DLL-ки которого (Open{A|C|G}L, например) являются лишь тонкими обёртками к соответствующим библииотекам хост-системы, это бессмысленное усложнение и снижение производительности. Неудивительно, что никто не хочет тратить своё время на реализацию этого «добра» ради удовлетворения хотелок горстки эстетов, впадающих в депрессию от одной только мысли об установке 32-битных библиотек в 64-битную систему.

Для вайна же, некоторые DLL-ки которого (Open{A|C|G}L, например) являются лишь тонкими обёртками к соответствующим библииотекам хост-системы

Что-то мне подсказывает, что, если бы они так же осуществляли трансляцию ABI 32->64, то не намного толще бы стали. Тем более, что, кажется, уже и gcc это всё поддерживает.

бессмысленное усложнение и снижение производительности.

За счёт чего бы производительности пострадать?

Неудивительно, что никто не хочет тратить своё время на реализацию этого «добра» ради удовлетворения хотелок горстки эстетов

Мультилиб из дистров будут постепенно удалять. Дистростроителем совершенно не нужно дистр в двойном объёме поддерживать. Хотя нет, не будут, его ж вайн требует, о щит... По-вашему, это нормально, когда одна единственная тупая прога требует от дистров поддержки мультилиба?

впадающих в депрессию от одной только мысли об установке 32-битных библиотек в 64-битную систему.

Я больше впадаю в депрессию от того, что разрабы вайна на подобные вопросы в мэйл листах либо отмалчиваются, либо откровенно гонят, вместо того, чтобы сказать, например, что им не охота, или нормально всё объяснить. А вопрос этот там всплывал неоднократно.

Для вайна же, некоторые DLL-ки которого (Open{A|C|G}L, например) являются лишь тонкими обёртками к соответствующим библииотекам хост-системы

Что-то мне подсказывает, что, если бы они так же осуществляли трансляцию ABI 32->64, то не намного толще бы стали. Тем более, что, кажется, уже и gcc это всё поддерживает.

Не забывайте, что те же указатели могут приходить не только от приложения, но и от библиотек. Пример — функции типа glMapBuffer(), запрашивающие у драйверов DMA-буферы для работы с некими данными. Т.к. драйверу этот запрос будет приходить от 64-битной библиотеки хоста, то он имеет полное право вернуть указатель на адрес за пределами 4ГБ и трансляцией ABI тут не обойтись. А править ради вайна такие библиотеки и прочее, добавляя спец. флаги или другие способы попросить драйвер выделять буфер в пределах 32-битного адресного пространства, никому нафиг не надо.

По-вашему, это нормально, когда одна единственная тупая прога требует от дистров поддержки мультилиба?

Нет, это не нормально.

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

Запускать 32-битные программы в 64-битной системе без 32-битных библиотек даже т.н. «виндузятникам» в голову не приходит, и только в *nix нашлась пачка несчастных, у которых голова болит от наличия в системе библиотек с разной разрядностью.

Я больше впадаю в депрессию от того, что разрабы вайна на подобные вопросы в мэйл листах либо отмалчиваются, либо откровенно гонят, вместо того, чтобы сказать, например, что им не охота, или нормально всё объяснить. А вопрос этот там всплывал неоднократно.

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

Пример — функции типа glMapBuffer(), запрашивающие у драйверов DMA-буферы для работы с некими данными. Т.к. драйверу этот запрос будет приходить от 64-битной библиотеки хоста, то он имеет полное право вернуть указатель на адрес за пределами 4ГБ и трансляцией ABI тут не обойтись.

Да, спасибо, хоть кто-то внятный пример привёл... А нельзя его потом mremap()ом вниз перенести? Или, если сама либа на него поинтеры закешировала, то, обычно, можно сделать алиас в нижней памяти, с помощью тоже же mremap(), подставив 0 в качестве old_size... Впрочем, этот костыль работал много лет назад, а что с ним теперь - мне неведомо.

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

Дистростроителей к несчастным приплюсуйте.

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

Когда апстрим говорит, что это нафиг не нужно, или невозможно, или вообще ничего не говорит - этого и не произойдёт. Для начала, апстрим сам должен своё отношение к проблеме изменить, и написать доку, что и как можно сделать. А теперь мне приходится на ЛОРе, а не в гугле, узнавать об этом - отличный апстрим...

А нельзя его потом mremap()ом вниз перенести?

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

А кто ремапить-то будет, если вайновская библиотека сама 32-битная, а вызываемая 64-битная функция

Когда я писал вот это:

Что-то мне подсказывает, что, если бы они так же осуществляли трансляцию ABI 32->64

А кто ремапить-то будет

Кстати, думаю, на этот вопрос уже ответили, когда делали win16 thunks. Подозреваю, что проблемы там все примерно те же... Или я не прав?

Кстати, думаю, на этот вопрос уже ответили, когда делали win16 thunks. Подозреваю, что проблемы там все примерно те же... Или я не прав?

Кстати, да. 16-битный вайн не требует 16-битных зависимостей :D

Запускать 32-битные программы в 64-битной системе без 32-битных библиотек даже т.н. «виндузятникам» в голову не приходит, и только в *nix нашлась пачка несчастных, у которых голова болит

Такие, как вы, видимо, клепают гном-3. :) Отвыкайте решать за юзеров, что и зачем им нужно. Уверен, что, если бы было голосование, то за эту фичу проголосовали бы, в принципе, _все_. А сейчас, когда апстрим людей откровенно игнорит, люди и помалкивают, боятся слово вставить.

Новость устарела, как то самое мамонта. Уже 1.7.6 имеется - везде, кроме PPA убунты. Там и 1.7.5 ещё нет.