Доступна (http://www.winehq.org/announce/1.1.23) новая версия Wine ветви разработчиков. В этой версии реализовано:- Поддержка зарегистрированных MIME типов для рабочего стола Linux- FBO режим теперь является установленным по умолчанию для Direct3D- Поддержка реализации функций COM proxy. (Support for COM proxy delegation.)- Улучшенная поддержка кросс-компиляции с помощью Mingw.- Надлежащим образом реализованный полноэкранный режим виртуального рабочего стола.- Различные исправления ошибок.
URL: http://www.winehq.org/announce/1.1.23
Новость: http://www.opennet.me/opennews/art.shtml?num=22049
Разработчики сломали сталкер! В версии 1.1.21 появилась красная трава, а в 1.2.22 полоски вертикальные красные. Если смотреть вертикально то их нет. МОжет, у юзеров nVidia их нет? Пошёл пробовать 1.2.23, если всё ещё есть - буду постить баг. Зато Обливион теперь при запуске не лагает видеом. Но пропустить его всё ещё нельзя... Трава стала исчезать.
>Разработчики сломали сталкер! В версии 1.1.21 появилась красная трава, а в 1.2.22
>полоски вертикальные красные. Если смотреть вертикально то их нет. МОжет, у
>юзеров nVidia их нет? Пошёл пробовать 1.2.23, если всё ещё есть
>- буду постить баг. Зато Обливион теперь при запуске не лагает
>видеом. Но пропустить его всё ещё нельзя... Трава стала исчезать.Сталкер Вообще перестал запускаться! Создал баг, делаю скриншоты в разных версиях Wine.
А когда они собираются выпустить следующую стабильную версию, ещё через 15 лет? ))
На самом деле это было бы даже логично. Ибо чтобы оно стало стабильным стабилизироваться должна хотя бы винда, которую оно пытатется догнать.
api winxp весьма стабилен
Вот только в нем масса недокументированных функций, из-за которых и пилят вайн. А так, да - написано, что стабилен. Сама M$ написала, что стабилен. Она ведь никогда не врет, правда? ;)
MS не врет, он просто сообщает не все и не всегда.Что по суммарным итогам эквивалентно, но формально придраться здорово труднее :D
Логично, было бы менять архитектуру wine, а также выпуск стабильных версий хотя бы 2а раза в год. Много чего логично, а так долго пилить вайн, чтобы через 15ть лет, уже после краха венды, выпускать следующую мажорную версию - это не логично, это тормознуто. Проекту не хватает свежей крови, очень нехватает. Работа идёт крайне медленно, отставание от венды таково, что без наращивания темпов разработки догнать её будет невозможно.
Ну и конечно венда не стабилизируется никогда, мс мечется из крайности в крайность много лет и этому не будет конца. Вопрос только один: "Догонять по настоящему или остановится сейчас?" Не стоит бояться нестабильности вендовых интерфейсов, если вайн будет последовательно реализовывать 100% интерфейсов 95й венды, потом 98, потом 2000, потом xp, то едва ли найдутся люди, которые будут упрекать проект в нестабильности. А вот упрёки за артефакты в d3d, вследствии нереализованных возможностей - это реальность.
И ещё, проектам подобного охвата нужные максимально дотошные автоматизированные комплексы тестов, чтобы хотя бы тривиальные регрессии выявлялись сразу и без лишних криков. Так что проекту нужные разработчики, финансирование и реструктуризация. Тогда пожалуй будет толк серьёзный.
>Так
>что проекту нужные разработчики, финансирование и реструктуризация. Тогда пожалуй будет толк
>серьёзный.предлагаю вам этим заняться.
Хорошее предложение, с двумя оговорками.
-я уже занят в другом проекте
-не могу для себя до конца определить ценность, пусть даже высококачественного вайн. То есть ценность допустим хорошей работы gcc мне ясна, ценность гнома понятна, и kde тоже. А ценность вайна, кроме попытки притащить в линукс кучу неродного софта - весьма сомнительного удовольствия. Ведь правильный вайн, технически будет похож на виртуальную машину с хорошим jit. То есть в итоге получим кросплатформенный win32+x86 код. Закрадываются сомнения в душу, насчёт нужности подобного. Вполне естественным мне кажется будет просто отмирание венды как платформы со временем. Таким образом и остарая необходимость в вайне отпадёт, и побочных эффектов не возникнет.
Ну и конечно третья оговорка, я один, а для того чтобы двигать вайн быстрее нежели сейчас он движется, добавлением парочки разработчиков не обойдёшся.
а в каком проекте вы уже участвуете? просто любопытно.>не обойдёшся.
ь забыли
> То есть ценность допустим хорошей работы gcc мне ясна, ценность гнома понятна, и kde тоже. А ценность вайна, кроме попытки притащить в линукс кучу неродного софта - весьма сомнительного удовольствия.Гражданин, а что такое "родной" и "не родной" софт? И "родной" кому? Конечному пользователю ведь пофиг каким способом отрисовыватся на его мониторе кнопочки, точно так же как тебе пофиг, как в мониторе реализовано переключание цвета пикселя, и какая физика за этим стоит. Т.е. программисту пофиг, как переключаются пиксели, а физику и инженеру пофиг как отрисовываются кнопочки. И конечному пользователю начихать, кошерно это или нет с твоей точки зрения. Какая программа предоставит пользователю интересное соотношение функциональности, цены и стабильности, та и останется на рынке. А уж какими инструментами она реализована и с помощью каких инструментов она работает в конечном итоге никого, кроме теоретиков и критиков, не волнует.
С помощью Wine можно портировать программу под Linux как минимум на 2 порядка быстрее, чем писать с нуля "правильную" версию под Linux. Часто требуется всего несколько изменений. Это означает, что пока я завтра и послезавтра буду писать и отлаживать "правильную" версию под Linux, пользователи могут пользоваться портированной из Windows СТАБИЛЬНОЙ (!) версией уже сегодня. Можно, конечно, нанять программистов под Linux, но это (а) не ускорит выход "правильной" программы под Linux и (б) увеличит стоимость продукта, что конечного потребителя не обрадует. А увеличение стоимости означает потерю части рынка.
> Ведь правильный вайн, технически будет похож на виртуальную машину с хорошим jit.
Вайн является реализацией Win API, а не виртуальной машиной. Если бы он был виртуальной машиной, то (1) вносил бы тормоза, (2) его реализация заняла бы на порядок больше времени и к моменту его реализации он был бы никому не нужен.
ПО, которое писалось для Windows+x86 - писалось для определенного рынка компьютеров, на котором альтернативы x86 по соотношению потребительских качеств и цене не было и сейчас не особо есть. А на рынке x86 всегда была только одна ОС, адекватная по соотношению потребительских качеств и цены (не считая узкоспециализированных задач). И то, что Wine добавляет для этого ПО поддержку конструктора Linux, причем практически бесплатно (некоторые расходы всё таки есть - требуется внести некоторые изменения в ПО, чтобы оно работало в Wine без проблем) - это же отлично!
Wine является очень важным, одним из ключевых звеньев в распространении Linux. Чем больше программ запускается под ОС, тем выше ее возможности (а следовательно и привлекательность) для пользователя. И важно обеспечить Linux как можно более полным комплектом программ в кратчайшие сроки. Это очень важно! А кроме Wine помощника в быстром портировании ПО из Windows в Linux нет (ни среди программ, ни среди людей). А пока все компании подумают о и найдут ресурсы на "родную" Linux-версию своих программ, я сто раз сдохну, а Linux так и останется конструктором с ограниченным набором программ.
-- поскипано
>
>С помощью Wine можно портировать программу под Linux как минимум на 2
>порядка быстрее, чем писать с нуля "правильную" версию под Linux. Часто
>требуется всего несколько изменений. Это означает, что пока я завтра и
>послезавтра буду писать и отлаживать "правильную" версию под Linux, пользователи могут
>пользоваться портированной из Windows СТАБИЛЬНОЙ (!) версией уже сегодня. Можно, конечно,
>нанять программистов под Linux, но это (а) не ускорит выход "правильной"
>программы под Linux и (б) увеличит стоимость продукта, что конечного потребителя
>не обрадует. А увеличение стоимости означает потерю части рынка.Другими словами, вы хотите сказать, что под винду проги пишутся в 100 раз (2 порядка)
быстрее ? чем "правильные" программы под линукс ???? ... и вы будете правы!
Потому что статистика != не врет :))
И только потому, что затраты на разработку во столько же раз более оправданы -
винда и держит ту долю рынка, которая у нее есть сегодня.-- аналогично
Во многом соглашаясь, всё же не вижу причин =отмирания венды=. Потому что - =покуда есть на свете дураки, обманом жить, нам, стало быть, с руки=. Иными словами - ес тьспрос - есть и предложение.
>технически будет похож на виртуальную машину с хорошим jit.Wine не занимается эмуляцией х86 - нафиг ему jit?Он х86 команды в лоб выполняет на х86 процессоре.Еще есть winelib - либа предоставляющая софту win32 api из wine, если есть сорц windows-аппы, по идее можно аппу с ней собрать.В этом случае уже не обязательно под х86.Но сие направление проработано меньше чем обычный wine и специфичных проблем с этой либой - АФАЙК есть.
А где нет х86 но надо выполнить х86 код - трансляция шила в мыло будет мееедленной как ни крути.Архитектуры разные и 1 в 1 не транслируются.А если не 1 в 1 тогда будет тормозить по понятным причинам из-за лишних действий (которые жестоко икнутся когда эти действия окажутся в узких местах).В итоге полная виртуализация - малоперспективно.Из-за скорости.Никому не надо ноутпад запускать.А монстры типа офисных пакетов и игр под полным виртулизатором - не смешно, понадобится Крэй для того чтобы скорость этого всего была на уровне.
Вот один из смыслов: написание программы-эквивалента DirectX для Linux. Не надо эквивалентов всем библиотекам из Windows! Достаточно лишь DirectX или возможности без сбоев запускать нативные, а остальной код игр пусть будет нативным! А программа, о которой я сказал в начале, это прослойка между DirectX из Wine (скомпилированного без всего лишнего) и нативными Linux-играми. Их количество должно возрасти, если DirectX появится не только в Windows. Собственно, мы им пользуемся, но и остальные библиотеки из Windows используются тоже. Как вам идея?
DirectX работает через COM, т.е. кроме библиотек DirectX придется тащить еще библиотеки COM.Не думаю, что для Linux актуален DirectX без Wine - в Linux DirectX всё равно работает через OpenGL, в связи с чем производительность Linux DirectX не будет выше Linux OpenGL, что для разработчиков игр может быть очень критично.
>DirectX работает через COM, т.е. кроме библиотек DirectX придется тащить еще библиотеки
>COM.
>
>Не думаю, что для Linux актуален DirectX без Wine - в Linux
>DirectX всё равно работает через OpenGL, в связи с чем производительность
>Linux DirectX не будет выше Linux OpenGL, что для разработчиков игр
>может быть очень критично.Ну, подумаешь, -15% от скорости! Зато без глюков и полный Open Source. Появится много новых игр. Просто в нативной игрушке можно будет выбрать DirectX.
>венда не стабилизируется никогда, мс мечется из крайности в крайность много лет и этому не будет концапуть развития мсвин достаточно четко прослеживается. можно даже снаружи сделать некоторые прогнозы на ближайшие 3-5 лет
>путь развития мсвин достаточно четко прослеживается. можно даже снаружи сделать некоторые прогнозы
>на ближайшие 3-5 летДа уж.Минимум инноваций, больше DRM и ограничилова в ядре.Просто как топор.Но совместимость по мелочи корежить не забывают.Под вистой половина прог прекрасно работавших под XP банально не работает.Вплоть до молчаливого отказа стартовать.Без каких либо сообщений в логи, эвентлоги и куда там еще.
>Да уж. Минимум инноваций, больше DRM и ограничилова в ядре. Просто как топор.это сознательный выбор клиентов
>Под вистой половина прог прекрасно работавших под XP банально не работает.
либо ядерная несовместимость (уж линакс фанбои бы помалкивали), либо изначально некорректное делегирование прав. на сей момент основные приложения давно исправлены
>Вплоть до молчаливого отказа стартовать. Без каких либо сообщений в логи, эвентлоги и куда там еще.
логированием обязано заниматься само приложение
> Проекту
>не хватает свежей крови, очень нехватает. Работа идёт крайне медленно, отставание
>от венды таково, что без наращивания темпов разработки догнать её будет
>невозможно.Так надо просто сделать так, чтобы все разработчики винды из M$ по совместительству стали разработчиками wine.
>Так надо просто сделать так, чтобы все разработчики винды из M$ по
>совместительству стали разработчиками wine.Упаси боже - они скопипастят кода из винды и потом засудят нахрен всех за нарушение копирайтов MS.
кто нибудь знает как работает COM proxy delegation.
Хочу виндосовскую прогу с ком портом подружить.
>кто нибудь знает как работает COM proxy delegation.
>Хочу виндосовскую прогу с ком портом подружить.Это не тот COM порт о котором ты подумал.
>кто нибудь знает как работает COM proxy delegation.
>Хочу виндосовскую прогу с ком портом подружить.