Linux w winie: przepis na aplikacje windowsowe pod Linuksem

Po napisaniu artykułu o stawaniu dość nietypowego NASa spotkałem się z opiniami, że Windowsowe aplikacje należy odpalać pod Windowsem i nie należy wiązać nadziei na uruchamianie ich w środowisku Linuksowym. Niby logiczne, ale moim zdaniem nie jest to do końca prawda. W tym artykule podstawiam się zatem przybliżyć jak obsługiwać Wine i jak uruchamiać aplikacje Windowsowe pod Linuksem.

Wine: o co chodzi?

Wypadało by powiedzieć o co chodzi w ogóle z tym Wine (akronim rekurencyjny od ang. Wine is not an emulator, tłumaczony oczywiście jako wino). Jest to warstwa kompatybilności, której zadaniem jest uruchamianie programów windowsowych w środowisku Linuksa. Jak to działa? Teoretycznie wystarczyć powinno podwójne kliknięcie na aplikacji windowsowej i wszystko powinno się uruchomić tak jak na Windowsie. Łatwe? Łatwe. Niestety nie zawsze będzie tak cudownie.

Co zatem taki Wine robi, żeby zaczęło działać? Tworzy sztuczne środowisko uruchomieniowe dla aplikacji Windowsa (domyślnie w podkatalogu .wine w folderze użytkownika). Ścieżka do tego katalogu nazywa się Prefiksem Wine.  Czasami jednak wolimy ustalić własny prefix. Jak to zrobić? WINEPREFIX=<nazwa katalogu> wine <ścieżka do pliku .exe> Jeżeli z tego prefiksu będziemy chcieli korzystać to będziemy odpalać z nim również wszystkie aplikacje konfiguracyjne i skrypty. No dobrze, a co, jeśli coś się nie uruchamia? Zacznijmy od tego, że Wine posiada swój program konfiguracyjny winecfg. Możemy ustawiać tam właściwości graficzne aplikacji (np. sztuczny ekran o określonej wielkości), ustawienia dźwięku, montować linuksowe katalogi pod windowsowe literki określające dysk. Możemy też wybierać wersję systemu Windows, którą Wine będzie udawać lub określić czy nie zastąpić biblioteki wbudowanej zamkniętym odpowiednikiem windowsowym. Cóż niestety nie zawsze to co wychodzi z projektu open source działa jak należy. Jak to robimy?

Winetricks

Zabawę w podmienianie bibliotek niby można wykonywać ręcznie, ale w rzeczywistości nikt tego nie robi. Od tego jest dodatkowy skrypt winetricks, który trzeba sobie najczęściej doinstalować osobno. Ten pozwala min. na instalacja bibliotek czy czcionek, ale również daje łatwy dostęp do narzędzi takich winecfg, edytora rejestru, explorera, konsoli cmd czy powłoki pozwalającej odinstalować pogramy. Czynności za jego pomocą można wykonywać z linii poleceń, jak również za pomocą graficznego kreatora. No dobrze, samo podmienianie bibliotek nie wydaje się jakoś szczególnie trudne, gdy można to sobie wyklikać w winetricks. Ale skąd mamy widzieć co podmienić, by działało? Tu z pomocą przychodzi szeroka biblioteka gier i programów WineDB, w której opisane są sposoby ich instalacji i uruchamiania aplikacji i oceniane jest na ile działają one z Wine. Czasami jednak opisu nie ma i trzeba będzie patrzeć w konsolę, szukać wyświetlanych tam błędów aplikacji i wydedukować jakoś rozwiązanie. Nawet jeśli nam się już uda coś odpalić, nie zawsze jest tak różowo, jeśli chodzi o stabilność i wydajność.

Ano właśnie, wydajność...

Tu czasami będziemy mieli wydajność porównywalną z tą z Windowsową, a czasami koszmarnego żółwika. Jeśli chodzi o gry i aplikacje graficzne dochodzą nam dodatkowe biblioteki, które pozwalają nam na przyspieszenia pracy programów korzystających z akceleracji 3d. Dla AMD jest to min. Gallium Nine. Jest to biblioteka przeznaczona do emulacji DirectX 9, z którą podobno jest mniej problemów niż z standardową wbudowaną wersją. Ma też lepsza wydajność. Problemem jest, że Gallium Nine nie jest domyślnie obsługiwane przez Wine i trzeba dysponować specjalną kompilacją Wine. Bardziej uniwersalny jest projekt DXVK. Jest to implementacja DirectX od wersji 9 po 11 korzystająca z biblioteki Vulkan. Vulkan jest biblioteką dość niskopoziomową, a przez to szybką i wydajną, więc jego wykorzystanie powinno znacząco zwiększyć wydajność samego Wine. Niektóre gry wymagają tej implementacji do prawidłowego działania, inne jej nie obsługują. Analogicznie sprawa wygląda z Vkd3d, które implementuje (częściowo) biblioteki Direct3D 12.

W skrajnych przypadkach te nowe biblioteki, w połączeniu z Wine, dadzą wydajność porównywalną lub nawet wyższą niż w Windowsie.

No i wróćmy do prefiksów Wine. Jak sobie wszystko pozastępujemy, to często trudno coś takiego odkręcić. Tym samym dobrze jest dla aplikacji niepowiązanych ze sobą korzystać z osobnych prefiksów.

W ten oto sposób, dowiedzieliśmy się, że Wine nie jest takie proste w obsłudze. Da się coś tym zrobić? Po części tak. Mamy nakładki graficzne pomagające zarządzać nam aplikacjami Wine. Przedstawię tutaj obecnie najpopularniejszą: Lutris.

Lutris

Lutris w założeniach jest programem agregującym gry na Linuksie. Obsługuje produkcje natywne, emulowane i te odpalane przez Steam czy GOG. Niezależnie od tego jest bardzo fajnym narzędziem do zarządzania aplikacjami uruchamianymi poprzez Wine. Niestety nie jest to aplikacja wielojęzyczna i jej interfejs jest tylko po angielsku. Jakie są podstawowe założenia programu? Lutris posiada stronę z bazą gier. Jeśli mamy szczęście znajdziemy tam tytuł, który chcemy zainstalować. Klikniemy w specjalny link i przygotowany przez twórców skrypt zainstaluje grę za nas. Jeśli mam mniej szczęścia, to nic nie znajdziemy. W wypadku jeszcze większego pecha, tytuł będzie w bazie, ale nie będzie chciał się zainstalować lub nie będzie działać. Co wtedy? Można skorzystać z Lutrisa, by zainstalować aplikację ręcznie. Możemy skorzystać z naszego Wine zainstalowane w systemie, albo dociągnąć dodatkową wersję zarządzając programami uruchomieniowymi (runners). Niezależnie od wszystkiego powinniśmy mieć jednak Wine zainstalowane w systemie, ponieważ jego zależności będą potrzebne dla instalacji i uruchamiania programu. Środowisko graficzne daje możliwość dodania aplikacji i stworzenia jej konfiguracji od zera. Można ustawić prefix, plik instalacyjny/uruchomieniowy, architekturę 32‑bitową lub 64‑biotwą, użyć DXVK i parę innych mniej lub bardziej przydatnych funkcji. Dla konkretnego środowiska programu możemy uruchomić winetricks czy winecfg. Innymi słowy, GUI daje duże pole do popisu.

Gry

Jako jeden z największych platform dystrybucji gier, Steam również nie ignoruje Wine jako potencjalnej platformy do odpalania gier pod Linuksem. Na potrzeby projektu stworzył on i rozbudował własnego forka Wine – Proton. Ma ona osobną bazę kompatybilności gier – ProtonDB. Zdarza się nawet, że gry odpalane przez Protona działają lepiej niż natywne linuksowe porty. Sama procedura uruchamiania gier ze Steam jest identyczna jak pod Windowsem, czyli klikami i jest. Rozwój Wine i Protona powoduje, że granie na linuksie nie jest już totalnym wymysłem linuksowego fanatyka, a powoli staje się jakąś tam alternatywą dla systemu Microsoftu. Trzeba tu jednak zwrócić uwagę, że wydajność bywa gorsza niż w Windowsie, nie wszystko działa i zdarzają się irytujące błędy. Często gry sieciowe nie pozwalają na zabawę przez Wine, gdyż ich zabezpieczenia przed oszustami stosującymi modyfikacje, interpretują Wine jako niepożądaną modyfikację systemu. Uruchamiając taką grę można wpakować się nawet w permanentnego bana.

Kontrowersje

Wine budzi w środowisku linuksowym sporo kontrowersji. Z jednej strony często spełnia swoją funkcję, z drugiej potrafi zawieść pokrywane w nim oczekiwania. Proces instalacji może być bardzo prosty lub stosunkowo skomplikowany. Użytkownik powinien rozumieć czego wymagają od nas twórcy, jeśli chodzi o instalację dodatkowych bibliotek natywnych lub tłumaczących Direct X na inne biblioteki. Do tego wymagane jest jako takie zrozumienie jak to wszystko obsłużyć przy wykorzystaniu Wine. Dla sporej części użytkowników dystrybucji Linuksa nie będzie to najmniejszy problem, lecz dla początkujących może być to coś nie do przeskoczenia i powód frustracji. Nie pomaga duża fragmentacja związana z wykorzystaniem różnych wersji Wine i często nieaktualna lub myląca dokumentacja dotycząca kompatybilności. Jako że DXVK jest projektem rozwijanym poza Wine, to moderatorzy WineDB krzywym okiem patrzą na wskazywanie tej biblioteki jako rozwiązania problemu działania aplikacji. Dodatkowo sam Vulkan, z którego korzysta DXVK, jako biblioteka niskopoziomowa, potrafi negatywnie wpłynąć na stabilność pracy systemu. Różne konfiguracje sprzętowe mogą generować inną wydajność lub nie uruchamiać konkretnych aplikacji. Poza tym aplikacje Wine nie funkcjonują w taki sam sposób co linuksowe odpowiedniki. Instalują się na poziomie użytkownika i musza być instalowane dla każdego użytkownika systemu osobno. (oczywiście można kombinować...). Integracja z aplikacjami linuksowymi też nie zawsze musi działać. Czasami też Lutris nie funkcjonuje jak należy i korzystać z poleceń konsoli. Wszytko to jest frustrujące i wymaga niemałej wiedzy, jak postępować z warstwą kompatybilności.

Przykład na podstawie gry, którą odpalam regularnie pod Wine: MtG Arena. Gra jest sieciowa i pojawiają się nowe jej wersje. Na początku udało się po niemałych staraniach grę zainstalować i uruchomić: działała ok. Później zaczęła się wieszać, ale sprawę rozwiązało DXVK. Niedawna aktualizacja postanowiła się nie zainstalować, grę trzeba było przeinstalować pod nowym prefiksem. Ostatecznie gra przestała się aktualizować i instalować, ale kopia jeden do jeden z Windowsa działa (tak to jest, jak się zaczęło korzystać z powershella w instalatorze). Jak widać, kolorowo nie jest.

Użytkownik powinien mieć zatem świadomość, że próba przeniesienia wszystkich swoich programów z Windows na Linuksa, jest raczej skazana jest na niepowodzenie i powinien skupić się na natywnych aplikacjach linuksowych, a z Wine korzystać doraźnie.

Z drugiej strony

Osobiście już dobrych 8 lat temu nie stosowałem się do tego zalecenia i używałem Windowsowych aplikacji, o ile te mi bardziej odpowiadały (np. foobara). Nie byłbym jednak skłonny używać warstwy kompatybilności, by odpalać kluczowe aplikacje w środowisku firmowym (niezależnie od ich stabilności!). Osobiście nie uważam jednak, że należy bać się Wine. Trzeba jednak pamiętać, że nawet obecnie nie jest to narzędzie proste i w 100% niezawodne.