Вышел (http://www.winehq.org/announce/1.5.22) очередной экспериментальный релиз открытой реализации Win32 API - Wine 1.5.22. С момента выпуска версии 1.5.21 было закрыто 50 отчётов об ошибках.
Основные изменения в новой версии:
- Обновлён HTML (Gecko) движок;
- Начата реализация драйвера графики для Mac OS X;
- Добавлена поддержка архитектуры ARM64;
- Исправлены проблемы с RTL-текстом из Uniscribe;
- Произведено множество улучшений в поддержке библиотек DirectX и C/C++;
- Обновлены переводы;
- Исправлено множество ошибок.
URL: http://www.winehq.org/announce/1.5.22
Новость: http://www.opennet.me/opennews/art.shtml?num=35874
> Добавлена поддержка архитектуры ARM64лучше бы допилили нативную поддержку 64-битных линуксов... чтоб 32-битных библиотек не нужно было ставить вагон
Это несвязанные вещи. WINE - это не эмулятор. Это прослойка, между программой под Windows и текущей системой. Поэтому невозможно заставить 32-х битную win-программу работать с 64-х разрядными Linux-библиотеками.
64 битных винпрограмулек нет?
2.5 штуки?
а какие с ними проблемы? если ставить в 64битную систему 64битный вайн предназначенный для запуска 64битных виндовых программ, то установка 32 битных библиотек не требуется.
Колличество обнаруженных ошибок ограничено по определению. Колличество необнаруженных стремится к бесконечности :)
Что за ерунда. Есть теоретически точка, в которой отсутствуют баги. Расстояние до этой точки прямопропорционально сложности продукта.
> Есть теоретически точка, в которой отсутствуют баги.Учитывая, что определение баги субъективно, сомневаюсь.
Точно есть. Она примерно там же где и получение пароля перебором для современного алгоритма шифрования, на текущем железе.
> Есть теоретически точка, в которой отсутствуют багив wine то может и есть такая точка, а вот в винапи и в виндовых прогах... теоретически да, есть (точнее была) - это момент времени до появления винапи.
А это смотря на то, включаем ли мы в список багов лишь баги из исходников программы, или баги уже скомпилированной программы. В первом случае все верно - в каком-нибудь хелловорде из пары строк багов нет. А вот в этом же скомпилированном хелловорде их может быть. Ибо в самом компиляторе баги уж точно есть.
> Есть теоретически точка, в которой отсутствуют баги.Эта точка есть не только теоретически.
int main()
{
return 0;
}А дальше уже появляются баги :)
> Расстояние до этой точки прямопропорционально сложности продукта.А сложность продукта растет с каждой версией.
Да, за счет нововведений.
> Есть теоретически точка, в которой отсутствуют баги.
> Расстояние до этой точки прямопропорционально сложности
> продукта.Насчёт наличия такой точки, спорить сложно. Но вот о прямопропорциональности -- это не так, по-любому. Я склонен считать, что речь об экспоненциальной зависимости расстояния от сложности. Ну или где-то около того.
Ещё можно вспомнить, что сложность -- величина зависящая от времени, и в подавляющем большинстве ситуация -- величина монотонно возрастающая. А вот количество находимых багов, при постоянной сложности проекта -- это монотонно-убывающая величина по времени. В общем, ситуация выглядит безнадёжной. Быть может стоит забить на всю эту теорию, и признать количество багов бесконечным, поскольку в обозримом будущем расхождений такой теории с практикой не придвидится. А простота такой теории подкупает. Как говорится кип ит симпл, стьюпид. ;)
> Расстояние до этой точкивспомнил школьное про горизонт)
как то было исследование о том, что можно создать продукт без багов, причем математически точно доказать что багов нет - но стоимость будет фантастической ...
Не очень понял, каким боком тут ARM64. Виндовые x86 бинарники уже можно запускать на ARM без виртуализации? Или они и WinRT теперь эмулируют?
ну начнём с того что есть виндовые программы с открытым исходным кодом
Угу, десяток где-то. На остальном капусту рубят/пытаются рубить. Это тут не мир СПО, где никто никому ничего не должен.
>Угу, десяток где-тоКаждая вторая линуксовая программа имеет вин версию, их не считаем?
Можно посчитать и их. Но какой смысл линуксовую программу собирать под windows, чтобы потом запускать под wine, крутящимся под линуксом? ;)
Наверное, имеется в виду поддержка ARM64 в winelib.
А 1.6 когда планируют?
По дате или когда ошибки пофиксят? (гусары молчать!)
Последняя из ветки 1.3 - это 1.3.39.
Последняя из ветки 1.1 - это 1.1.44.
Последняя из ветки 0.9 - это 0.9.61.
Вопрос был не о том, какие были номера - а каковы планы на выпуск 1.6
По плану, у них, по стабильному релизу в год. Когда не известно, но в течении 2013 года. И каждый тестовый выпуск раз в две недели.
> По плану, у них, по стабильному релизу в год.Спер с педивикии:
17 июня 2008 года, после 15 лет разработки, вышла версия Wine 1.0, первая, которую разработчики называют стабильной.
16 июля 2010 года вышла следующая стабильная версия Wine под номером 1.2.
7 марта 2012 года вышел стабильный релиз версия Wine под номером 1.4
>>Начата реализация драйвера графики для Mac OS X;Это того, который включен в последний кроссовер?
Кажется, что да
Я бы порекомендовал многим не ориентироваться на wine так как люди заведомо не решаемую задачу, так как по прогнозам экспертов 80% текста Windows это заплаты и поэтому разработать загрузчик который бы их все учитывал не возможно. Лучше использует и развивайте существующие проекты.
> Я бы порекомендовал многим не ориентироваться на wine так как люди заведомо не решаемую задачу, так как по прогнозам ИКСПЕРТОВ и АНОЛИТЕГОВ 80% текста Windows это заплаты и поэтому разработать загрузчик который бы их все учитывал не возможно. Лучше использует и развивайте существующие проекты.FIXED
> Исправлено множество ошибок.А я уже переживал, в прошлом релизе не было.
сейчас посмотрел обновления в своем Дебиане (6.0.6). На Wine опять ничего не было (стоит штатная- "1.0.1"). И чем она от "1.5.22" отличатся может?
http://www.winehq.org/announce/1.5.22
Это у них список, чего поломали? А то после "32340 View NX2 does not launch", запускавшийся и работавший в прошлой версии View NX2 стал снова стабильно виснуть. Лайтрум всё так же ни с патчами, ни с бубнами, ни с отдельными либами не работает.