Dzisiaj, 16 lipca 2010, ukazało się stabilne wydanie nie-emulatora WINE. W stosunku do poprzedniego wydania WINE wprowadzono szereg zmian, głównie w obsłudze grafiki i wsparciu programów tworzonych pod różne architektury. Po pełną listę zmian odsyłam do pełnego changeloga: http://www.winehq.org/announce/1.2 .
To duży krok w rozwoju całego zestawu bibliotek. Najważniejsze zmiany, to:
* Wprowadzenie obsługi programów 64-bitowych na 64-bitowych Linuksach z możliwością użycia trybu udawania systemu 32-bitowego(wsparcie dla prefiksów wspierających tylko 16-bitowe i 32-bitowe programy, a także dla wspierających dodatkowo 64-bitowe programy)
* Kod 16-bitowy do wsparcia 16-bitowych programów został odseperowany i przeniesiony do oddzielnych modułów, które są ładowane tylko w razie potrzeby
* Szczątkowa implementacja mmdevapi dll, czyli biblioteki do komunikacji z serwerem dźwięku wprowadzonym w Windows Vista
* WINE zostanie domyślnym programem do obsługi instalatorów .msi w systemach, gdzie zostanie zainstalowane
* Frame Buffer Obects(rozszerzenie OpenGL dostępne na Linuksach) będzie domyślnym backendem dla implementacji DirectX.
* Start programów, gdy używany jest backend FBO(Frame Buffer Objects) został przyśpieszony
* Dodano obsługę licznych rozszerzeń OpenGL, w tym dla multitekstur(przypisek od autora: wydaje mi się, że WINE wcześniej wspierało te rozszerzenia), jak również dla kart NVidii.
* Poprawiono wykrywanie kart graficznych, jak również ich obsługę
* Wirtualny pulpit automatycznie przejdzie w tryb pełnoekranowy, gdy aplikacja zawarta w nim zażąda trybu pracy o rozdzielczości równej rozdzielczości ekranu
* Obsługa wielu formatów zapisu obrazu(dotyczy filmów)
* Wprowadzono liczne zmiany, by backend dźwięku dla alsy nie stwarzał problemów z PulseAudio(przypisek od autora: z tego, co mi wiadomo, to przepisano Wine tak, by korzystała jedynie z wywołań nie powodujących problemów wraz z użyciem PulseAudio)
* Wine umożliwia kompilację programów na Solarisie
* Polepszony wygląd czcionek w niektórych konfiguracjach
* Porzucono skrypt wineprefixcreate
* Wiele usprawnień w kryptografii(np. możliwość zarządzania zaufanymi kluczami, implementacja pewnych wywołań)
* Dużo nieudokumentowanych funkcji shlwapi dll zostało zaimplementowanych
Wiele, wiele innych.
Nie jestem pewien czy głównym tagiem nie powinien być: informacja prasowa.
Nie, informacje prasowe to bardziej synonim "pr-owskiej papki" – dział powstał po to żeby agencje PR nie zaśmiecały wylęgarni 🙂
"Wirtualny pulpit automatycznie przejdzie w tryb pełnoekranowy, gdy aplikacja zawarta w nim zażąda trybu pracy o rozdzielczości równej rozdzielczości ekranu"
Nie wiem czy ta zmiana nie jest raczej negatywna. Pewnie niektóre menadżery okien nie potrafiłyby sobie z takim czymś poradzić lub powodowałoby to problemy graficzne, jednak nie jestem tego pewien.
W każdym razie, to niekiedy odpalam aplikację powodującą problemy w takim trybie. Jeżeli program samemu zarząda rozdzielczości mojego pulpitu, to nici. Oczywiście, że mogę takie zachowanie przewidzieć, gdyż raczej program nie będzie sobie losować rozdzielczości.
O pewnych zmianach nie mogłem znaleźć informacji, jak np. polepszone wykrywanie maksymalnej rozdzielczości. W Wine 1.0 jeszcze ograniczano maksymalną rozdzielczość do obecnej rozdzielczości pulpitu. Jestem niemal pewien, że wprowadzono stosowne zmiany, lecz w changelogu nic o nich nie wspomniano.
"głównie w obsłudze grafiki i wsparciu programów tworzonych pod różne architektury"
Przepraszam redakcję, ale powinno być:
głównie w obsłudze grafiki i wsparciu programów tworzonych pod dotąd niewspierane architektury
Dobra robota mimo problemów finansowych nieźle sobie radzą .
Inna sprawa – jak wygląda przyszłość integracji podsystemów wine z reactos . Devowie ROS w końcu się na to zdecydowali ?
Myślę, że devowie ReactOS teraz będą bardziej współpracować z programistami luks, choć to tylko takie gdybanie.
Trudno w tym wypadku pisać o problemach finansowych, gdyż:
a) Tworzą soft, więc głównym wydatkiem mogłoby być jedynie opłacenie pracy ludzi, a może wielu nie chce zapłaty za pracę?
b) Są sponsorowani przez Cedegę
c) Nigdzie nie przeczytałem o problemach finansowych
O problemach finansowych bodajże trasz kiedyś wspominał , nie wiem na ile to prawda , ale jak wielu wiadomo Projekty OS raczej bogate nie są . Wyjątkami są Linux , Vbox i FreeBSD ale to zupełnie inna sprawa .
Ros jest oparty na kilku projektach , jednak niedawno była mowa o integracji developmentu z wine dlatego mnie zaciekawiło jak to się potoczyło .
@Sławek – przez "Cedegę" miałeś na myśli CodeWeavers? 😉
Oprócz tego część kodu powstaje corocznie w ramach GSOC.
Ciekawe co dzieje się z Linux Unified Kernel. Niecałe 2 miesiące temu wydana została wersja 3.0 oznaczona jako stabilna, pozbyto się zależności od wineserver, czyli przeniesiono wszystkie funkcję do kernela (2.6.34).
Ale nie widziałem jeszcze tego cuda w akcji, ani żadnych testów LUK.
Ja kiedyś tego użyłem pod fedorą , dało się płynnie grać w starsze windowsowe gierki .
tak samo jak pod wine 😉
mnie ciekawi jaka jest różnica w wydajności/jakości/itd względem wine.
Ponoć o kilkanaście % szybciej , znająć życie Phoronix niedługo zrobi im benhmark 🙂
Ja wierzyłem, że LUK rozwiąże problemy z wieloużytkowością i aplikacjami Windowsowymi. Obecnie, to należy poczekać(jak narazie, to nie testowałem).
Może tu ktoś potrafiłby mi pomóc.
Otóż mam program który po uruchomieniu wyświetla okno powitalne które
należy zamknąć tym krzyżykiem co jest w prawym górnym narożniku.
Po zamknięciu tego okna, w trayu pojawia się ikonka i program działa w tle.
Chciałbym się dowiedzieć czy jest jakiś sposób, może jakiś wpis do
rejestru wine który by powodował że program po uruchomieniu wędrował by
prosto do traya bez wyświetlania tego okna powitalnego.
Zmień program… tu wine nie ma nic do roboty, tak program napisany jest, że ma okno powitalne pokazac.
domyślam się, że meritum pytania wiktorun-a dotyczy możliwości wysłania zdarzenia zamknięcia okna przy użyciu wine. Nie znam na nie odpowiedzi, ale może spróbuj zamknąć okno przy użyciu linii komend window-managera, którego używasz. (dla Kwin KDE 4.x można użyć np. qdbus)
Dokładnie o to mi chodziło.
Coś w rodzaju uruchom jako zminimalizowane.
Mógł byś coś więcej o tym qdbus napisać?
qdbus jest komendą odpytywania interfejsu DBUS, można między innymi obejrzeć sobie i uruchomić metody w DBUS, które udostępniają poszczególne programy. Do przeglądania w GUI jest qdbusviewer.
Niestety nie widzę metody w KWin, która umożliwiała zminimalizowanie określonego okna.
W takim razie inna technika – ikona okna "Zaawansowane/Dodatkowe ustawienia okna". Zaznacz "minimalizuj" i "Stosuj początkowo".