LINUX.ORG.RU

Вышел wine 0.9.28


0

0

Изменения более значительные, чем обычно:

- OpenGL in child windows should work again.
- Better mouse support in games.
- Beginnings of new state management in Direct3D.
- Improved audio and font support on Mac OS.
- Lots of bug fixes.

Радует, что на этот раз нет ничего связанного с msi, видать починили наконец-то. Мышь больше не застревает посреди экрана в играх типа GTA, в CS порадовал очередной прирост fps (~10%), только вот патч, реализующий поддержку PALETTED_TEXTURES через fragment shader для карт GF6xxx и старше почему-то не включили. Хотя я проверял его и никакого ускорения не заметил.

Ну, теперь пишите, у кого какие проги отвалились :)

>>> Патч с предыдущей версии

★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

>выходит, микрософт выпускает разные директх для разных видеокарт? гы, сына, лол

это задача вендора вообще-то - реализовывать поддержку DX в своих дровах. Поэтому и весят вантузятные дрова для видяхи по 60Мб =)

geek ★★★
()
Ответ на: комментарий от anonymous

Народ, а кто-нибудь ставил КОМПАС V7 или V8 под вайном? Еще недавно у меня получалось его там завести (до версии 0.9.25), но были проблемы с ГОСТовскими шрифтами. Ныне я его даже поставить не могу из-за странного бага в msi. На страничке где надо согласиться с Асконовским лицензионным соглашением надо поставить галочку, после чего должна стать активной кнопка "далее", но она не становится активной. Может кто с таким сталкивался?

anonymous
()
Ответ на: комментарий от anonymous

сталкивались, пришлось переносить инсталляцию с венды

что интересно - при инсталляции viewer такого нет, все работает

anonymous
()
Ответ на: комментарий от Deleted

> Т.е. ты либо тупишь, либо троллишь, и то и другое есмь нехорошо и достойно всяческого порицания.

Боюсь, тупит не geek. Вспомним всё-таки исходный момент: http://www.linux.org.ru/jump-message.jsp?msgid=1711879#1712010

И ответ анонимуса, что wine уже так работает. Так вот, оно так не работает. Надеюсь, мы понимаем, что при вызове 90% API функциё всё в конечном счёте упирается или в ядро или в драйвер. wine-же до этого момента не доходит, вызывая аналогичную функцию целевой платформы.

И что у нас получится для варианта "заменить весь wine на библиотеки M$ win"? А получится то, что случатся опаньки. Скажем простая функция чтения файла приведёт к обращению к драйверу файловой системы, который в "родном" варианте понимает fat и ntfs. Скажем, не слишком часто используемые fs для Linux. :) Далее, будет осуществлён вызов драйвера диска, которому точно останется только повесится, т.к. никто ему прямого доступа к железу не даст. Или придётся уже пихать часть dll-ек в ядро. Мило, да.

Но, как говорят в агрессивной рекламме, и это ещё не всё. :) В отличии от упомянутого ndiswrapper, проедставляющего собой "вещь в себе", т.е. - инкапсулирующего фрагмент реализации ядра win для обработки драйверов сетевых карт и представляющих стандартный интерфейс Linux, здесь возникает вторая проблема - как заставить работать параллельно драйверы для одних и тех же устройств? Ведь драйверы (скажем, видеокарты для X.Org и Win) не знают ничего про "кооперативную" работу. Напоминаю, условие было "выкинуть wine и заменить его загрузчиком PE и родными библиотеками win".

Вот мы и вернулись к драйверам. Как ни крути, но решение использовать только либы от M$ приведёт к завязке на них, а их использование параллельно с Linux - такой гемморой, что wine по сравнению с ним...

Тоже самое и с DirectX. Можно ли использовать его с wine? Зависит от того, что считать "использовать", Если вы согласны, что большая часть либ будет лежать мёртвым грузом, что вы "сделаете ручкой" аппаратному ускорению, вероятно, поддержке устройств ввода, типа джойстиков и т.д., то - милости просим.

Позволяет ли wine использовать родные библиотеки? От чего же не позволить? Но только те, что не завязаны на железо и те, что опираются на реализованные в wine функции. О полной замене либ wine речи не идёт и идти не может. Это уже ReactOS получается. :)

Так что geek в данном случае прав на 100%, просто никто не утрудился понять о чём он говорит. Ну, а anonymous, не просто "газифицировал лужу", он ненароком надристал туда. Но теперь, разумеется, не сознается.

atrus ★★★★★
()
Ответ на: комментарий от eXOR

> Еще вопросы?

Однако, знать умные слова - мало. Надо их ещё применять к месту. :)

atrus ★★★★★
()
Ответ на: комментарий от atrus

>Надеюсь, мы понимаем, что при вызове 90% API функциё всё в конечном счёте упирается или в ядро или в драйвер. wine-же до этого момента не доходит, вызывая аналогичную функцию целевой платформы.

Опять, не совсем то... Вот здесь с картинками все объяснено: http://citforum.ru/operating_systems/windows/win32api/ Нетрудно понять, что львиная часть системных вызовов из юзерспейса в кернелспейс идет через довольно узкое "бутылочное горлышко" вроде ntdll.dll. (Это становится еще более понятным, если посмотреть "в ретроспективе", вспомнить линейку win9x и то как microsoft цепляется за совместимость) И собственно неспособность wine нормально гонять нативные виндовые длл-ки объясняется неполной реализацией функций той же ntdll.dll (что видно по ссылке данной geek'ом). А отнюдь не драйверами (под словом "драйвер" я понимаю кусок кода работющий в kernel-space).

>Скажем простая функция чтения файла приведёт к обращению к драйверу файловой системы, который в "родном" варианте понимает fat и ntfs.

Мдаа... а такие понятия как "абстракция" (в общем, в теории) и vfs (в частности, на практике) ни о чем не говорят? В винде ведь тоже есть vfs и ее (винду) можно научить понимать, например, ext2 как родную файлуху. Это говорит о том, что функции используемые для доступа к фс приложениями, не зависят от типа фс.

Deleted
()
Ответ на: комментарий от Deleted

> И собственно неспособность wine нормально гонять нативные виндовые длл-ки объясняется неполной реализацией функций той же ntdll.dll

А неспособность wine тут не причём. :) В первоначальном-то вопросе стояла задача заменить wine (ЗАМЕНИТЬ!) PE-загрузчиком и родными библиотеками. Вот вы мне и скажите, каковы перспектыивы практического использования родной ntdll.dll в Linux? ;-)

> А отнюдь не драйверами (под словом "драйвер" я понимаю кусок кода работющий в kernel-space).

Я, в общем, тоже. Какую часть кода M$ вы предлагаете пускать в Linux'овом kernel-space? ;-)

> Мдаа... а такие понятия как "абстракция" (в общем, в теории) и vfs (в частности, на практике) ни о чем не говорят?

Говорят. Даже название знаю - IFS. :)

> Это говорит о том, что функции используемые для доступа к фс приложениями, не зависят от типа фс.

Гы! Без этого бы проект wine вообще бы не имело смысла делать бы. Однако, у меня речь не о том, а о том, что если пройти по всей чепочке, то при полной замене wine на библиотеки windows, рано или поздно будет чего-то нехватать. :) А нехватать будет ядра windows и её драйверов.

atrus ★★★★★
()
Ответ на: комментарий от blaster999

>>Мелкософт инсталлер - убогий костыль, созданный из-за отсутствия в оффтопике менеджера пакетов, и для борьбы с зоопарком инсталляторов (типа инсталлшилд, нулсофт инсталлер и иже с ними)...<<

Ужасаюсь я вами, фэнами. Разнообразие, которое только приветствовалось в виндах - под линями резко стало недостатком, простота и функциональность - еще хуже, трансформировалось в "убожество". А что линя могут предоставить? .deb и .rpm которые настолько неоднозначны? или Loky Installer (вечная память уважаемому)?

anonymous
()
Ответ на: комментарий от atrus

>> Это говорит о том, что функции используемые для доступа к фс приложениями, не зависят от типа фс.

Гы! Без этого бы проект wine вообще бы не имело смысла делать бы.<< Если сравнивать по рентабельности игр, то тогда проект под названием PC вообще не было бы смысла делать.

Wine - эмуль (повторяйте слово до просветления), с какого перепугу он _обязан_ иметь доступ к "чужим" fs?

YagMort ★★
()
Ответ на: комментарий от geek

Угу, а линух - самая популярная десктопная ОС. Эмулятор это, эмулятор...

anonymous
()
Ответ на: комментарий от geek

> Wine Is Not Emulator - повторять до _полного_ просветления :)

Если эмулятор назвать неэмулятором, то он от этого не перестанет быть эмулятором.

anonymous
()
Ответ на: комментарий от anonymous

> простота и функциональность - еще хуже, трансформировалось в "убожество".

Если бы вы сами занимались когда-нибудь созданием сложного инсталлятора, который должен тащить с собой и обновления системных библиотек, были бы связаны требованием корректной деинсталляции, то поняли бы, какая жопа царит в винде. MSI - это, безусловно, прорыв. Но всего лишь до уровня rpm (не полностью). В то время, как "остальной мир" давно использует пакетные менеждеры.

atrus ★★★★★
()
Ответ на: комментарий от YagMort

> Если сравнивать по рентабельности игр, то тогда проект под названием PC вообще не было бы смысла делать.

Сказать было нечего, но очень хотелось... Про рентаьельность игр на PC мы как-нибудь в другой раз поговорим, а сейчас отмечу, что если не понимаете о чём говорят другие, то спрашивайте, а не влезайте непонятно с чем. Повторяю медленно и второй раз: чтение и запись файлов является краеугольным камнем современных ОС общего назначения. Если бы невозможно было реализовать поддержку этих операций в wine без геммороя, то проект не был бы востребован.

> Wine - эмуль (повторяйте слово до просветления)

Лучше прочтите официальную расшифровку wine и повторяйте до просветления. :)

> с какого перепугу он _обязан_ иметь доступ к "чужим" fs?

С такого, что windows немного сложнее игровой платформу и образами дисков тут не обойдёшся. Держать их в файлах - накладно и неудобно. А ставить Linux на fat или ntfs народ почему-то :) не хочет. Отсюда и требование - стандартные функции win32 api должны читать файлы и содержимое каталогов *nix fs так, как будто это родные для win файловые системы.

atrus ★★★★★
()
Ответ на: комментарий от anonymous

> Если эмулятор назвать неэмулятором, то он от этого не перестанет быть эмулятором.

Отметим, что это ваша проблема, а не остальных. Если вы непонимаете разницы, то это не значит, что её нет.

atrus ★★★★★
()
Ответ на: комментарий от geek

>Wine Is Not Emulator - повторять до _полного_ просветления :)

WINdows Emulator. Повесить в рамочку над кроватью.

anonymous
()
Ответ на: комментарий от anonymous

>WINdows Emulator. Повесить в рамочку над кроватью.

Угогога! Ужос! Рекурсию неасилил?

anonymous
()

Пока у них мелкие шрифты не станут отрисовываться с системными настройками (мне нужен субпиксельное сглаживание) и пока не перестанут тормозить XP-темы, реально win-приложениями под сабжем пользоваться элементарно неприятно :-/

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>Если эмулятор назвать неэмулятором, то он от этого не перестанет быть эмулятором.

Если апельсин назвать картошкой, от этого апельсином он быть не перестанет.

Кури на тему того, что такое эмуляторы, и что такое реализации API.

KRoN73 ★★★★★
()
Ответ на: комментарий от geek

> Как можно узнать, какие используются либы, без исходного кода запускаемой программы,

depends.exe - утилита от msvs

anonymous
()
Ответ на: комментарий от Farcaller

>IDA.

Линуксячую иду поставить религия не позволяет ? :). Нормально работает.

vtVitus ★★★★★
()
Ответ на: комментарий от anonymous

либы

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

mumpster ★★★★★
()
Ответ на: комментарий от KRoN73

> Пока у них мелкие шрифты не станут отрисовываться с системными настройками (мне нужен субпиксельное сглаживание)

Пересборка freetype с хинтингом не лечит?

atrus ★★★★★
()
Ответ на: комментарий от anonymous

> depends.exe - утилита от msvs

В общем случае не поможет. Покажет только статику. Полностью вычленить что прога может линковать через LoadLibrary не получится.

atrus ★★★★★
()
Ответ на: комментарий от vtVitus

> Всегда удивляли люди пользующиеся XP-темой (в простанородии, тема для чупочупсов) :D :D.

Вобще-то там (в XP) есть и Clearlooks 1,2 ;-)

atrus ★★★★★
()
Ответ на: комментарий от geek

>ржал. Сам придумал? :)

Нет, разработчики Wine. До того, как пошли по "всеми любимому" GNU way.

anonymous
()
Ответ на: комментарий от GladAlex

> Use LinuxDC++!

Таки, загрузку с нескольких источников там асилили?

Nelud
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.