Wirtualizacja - przykłady

Wine - Wstęp

Aby uruchomić aplikację działającą na jakimś systemie operacyjnym w innym systemie operacyjnym, wcale nie trzeba emulować całego systemu. Aplikacje często działają w innej przestrzeni niż system operacyjny, a komunikują się przez Application Programming Interface (API). Dlatego wystarczy emulować zachowanie poleceń API. Ma to swoje wady, np. duża część aplikacji działa wyśmienicie, ale niektóre mogą nie zadziałać, bo brakuje implementacji jakiejś funkcji w emulatorze. Ale ma też i olbrzymią zaletę - dużo lepszą szybkość działania. Uzyskują ją, bo: nie muszą implementować przerwań procesora, wykonują wywoływania (systemowe i biblioteczne) w "native code" no i szybciej wykonują operacje wejścia/wyjścia.

system: aplikacja - API - sterownik systemu plików - kontroler dysku - dysk
wine: aplikacja - emulowane API - API - sterownik systemu plików - kontroler dysku - dysk
dla emulacji całego systemu: aplikacja - emulowane API - sterownik systemu plików - kontroler symulowanego dysku - API - sterownik systemu plików - kontroler dysku - dysk

WINE - Rys historyczny

Początki Wine'a siegają nawet 1993 r. W tych zamierzchłych czasach Windows był przewodnim systemem stosowanym w wiekszosci komputerów osobistych, ale jeszcze IBM łudziło się, że OS/2 zmieni ten stan rzeczy. Jednakże, oczywistym stał się fakt, że aby produkt był atrakcyjny, powinien obsługiwac programy windowsowskie.

We wrześniu 1992 r. Sun rozpoczyna rozwój Wabi, którego pierwsza prezentacja ma miejsce w 1993 r. Produkt ten umożliwiał użytkownikom Solaris x86 i Solaris 2.2 uruchamianie aplikacji windowsowskich. Był to przełom ponieważ dotychczas wymagało to emulacji na poziomie maszynowym i instalacji DOS-a oraz Windows. Ponadto okna Windowsa tłumaczył na wywołania X Window. Był on bodźcem rozpoczynającym rozwój Wine'a.

Użytkownicy Linuxa postanowili stworzyć coś podobnego (szanse na dostosowanie Wabi do Linuxa były nikłe). Szybko przyjęła się nazwa "Wine" (jednym z tłumaczeń jest Wine Is Not an Emulator - ponieważ nie jest to całe środowisko Windows, tylko produkt pozwalajacy na uruchamianie niektórych aplikacji). W pracę nad nim były zaangażowane nawet takie osoby jak E. Youngdale, D.Metcalfe, A. Julliard, B. Amstadt.

Pierwszym celem było stworzenie programu uruchamiającego 16-bitowe aplikacje. Po pierwszych 6 miesiącach, około listopada 1993 r. w Winie mozna było już uruchomić pasjansa (Solitaire).

W 1994 r. Microsoft zaczął wypuszczać 32-bitowy kod. Potrzebna była ścisła integracja. Zmieniono mechanizm adresowania, tworzenia okien na wywołania Xlib, dodano mechanizmy obsługujące połączenia sieciowe.

Styczeń 1996 - zanotowano uruchomienie Worda i Exela.

1998 - Corel postanawia "całym sercem" wspomagać Linuxa. Owocuje to wysokimi wymaganiami co do stopnia komplikacji Wine. Wspieranie rozwoju kończy się w 2001r.

Przeprowadzono wiele dyskusji co do licencji. Ostatecznie 9 marca 2002 wybrano Lesser General Public License.

Obecnie Wine obejmuje ponad 1,2 miliona linii kodu w C i dynamicznie się rozwija. Można się spodziewać, że z 6-miesięczną regularnoscią będą się ukazywać następne wersje.

Po co w ogóle jest Wine?

Przyczyny wirtualizacji w ogóle pojawiły się we wstępie. Przyczyny komercyjne - w rysie historycznym. Ciekawą przyczyną jest obecna sytuacja na rynku (monopol Microsoftu) i porównanie tej sytuacji do głodu ziemnaczanego w Irlandii. Tam większość żywiła się ziemniakami - gdy uprawy zdziesiątkował grzyb, nie było co jeść. Wielu musiało emigrować (głównie do USA), a ponad milion osób zginęło. Nasuwa się tu analogia, z tym, że większość użytkowników komputera używa tylko Windows...

Niektóre z zalet Wine'a:

Ma wszystkie zalety Linuxa - stabilność, przenośną administrację ... Korzysta z nich jednocześnie umożliwiając uruchamianie windowsowych aplikacji.
Zdalne uruchamianie aplikacji - pozwala korzystać z aplikacji znajdującej się na drugim końcu świata :)
Po zainstalowaniu na serwerze linuksowym z każdego terminala z X-sami możemy korzystać z jego dobrodziejstw.
Korzystamy z Linuxa i nachodzi nas chęć na np. pasjansa - nie musimy restartować komputera :)
Nie trzeba mieć orginalnego Windowsa ...
Debugowanie : Olbrzymią zaletą debuggera jest, poza podstawowymi funkcjami, możliwość debugowania uruchomień Windowsowych plików wykonywalnych w Linuksie. Wine posiada także dobrze zaprojektowane moduły do tracowania i loggingu. Jest to nie tylko, jak by się mogło wydawać, przydatne dla zaawansowanych programistów, ale i praktyczne, gdy instalujemy jakąś aplikację windowsową w Wine. Często powstaje dużo problemów, więc każdy użytkownik Wine musi mieć dostęp do dobrych narzędzi do debugowania.
WAŻNE : Możemy pisać skrypty w Linuksie wywołujące aplikacje windowsowskie! Jest to czasem bardzo przydatne i wyraźnie poszerza możliwości środowiska.
No i najważniejsze - jest udostępniony jego kod, więc jeżeli potrzebna Ci jakaś specjalna właściwość, możesz po prostu sam ją dopisać !!!

Obalenie paru mitów

Wine to nie jest emulator - nie korzysta z emulacji procesora, tylko bezpośrednio z niego. Teoretycznie uruchomione aplikacje powinny więc działać jak w Windowsie. Ba, niektóre dobrze napisane aplikacje Windowsa na Winie działają szybciej od właściwych, ale nieoptymalnie napisanych uniksowych aplikacji. Z drugiej strony rzeczywiscie grafika jest obsługiwana wolniej, bo kod Wine nie jest zoptymalizowany. Straty są spowodowane też tłumaczeniem sterownika X11.
Nie jest potrzebna instalacja Windowsa. Z drugiej strony Windows posiada funkcje, których Wine nie zapewnia.
Wine nigdy nie dogoni Windowsa. Widać w praktyce, że możliwość uruchomienia nowych aplikacji w Winie udaje się uzyskać stosunkowo szybko, ponieważ większość kodu jest już gotowa. Podobnie spodziewa się, że przejście na architekturę 64-bitową też nastąpi szybko. Argumentuję się to tym, że brano to pod uwagę już wczesniej, a przejścia z 16 na 32 też dokonano szybko.

Jak to działa

Wine jest to uniksowa implementacja API Windowsa. Tworzy on podstawowe biblioteki DLL takie jak Kernel, Gdi i User (teraz odpowiednio też i 32-bitowe wersje). Wine korzysta potem z tych bibliotek, jak również czasem z oryginanlnych bibliotek Windowsa. Nie tworzy natomiast warstwy jądra Windowsa. Mimo to umożliwia uruchamianie programów Windowsa (wszystkich wersji - Windowsa, nie wszystkich możliwych programów ;-) ) oraz plików wykonywalnych DOS-a (.exe oraz .com). Część Wine'a, Winelib, implementuje API Windowsa w Uniksie pozwalając na skompilowanie aplikacji do plików wykonywalnych. Wine ma wewnętrzną implementację dla setek windowsowych dll-ów w różnym stopniu zaawansowania. Od pełnych implementacji po 4-10%. Właściwości jądra systemu są dobrze rozwiązane w Wine. Windows i Linux róznią się poważnie, ale jest też parę podobieństw, z których korzysta Wine. Chodzi tu m.in. o podobieństwo w interfejsach użytkownika, wsparcie systemu plików, mulitimediów. Współbieżność, na przykład, jest rozwiązywana na dwa sposoby w zależności od rodzaju architektury Windowsa emulowanej aplikacji. Dla 16-bitowej w Winie w jednym procesie uruchamia się parę procesów windowsowych jako wątki. Bezpieczeństwo zapewnia odpowiedni mutex. Dla 32-bitowej każdy proces otrzymuje własną przestrzeń adresową. Wine dobrze wspiera obsługę procesów, wątków, plików i kolejek wiadomości.

A teraz trochę wad:

Niektóre problemy podczas korzystania z Wine:

Nie pozwala na działanie windowsowych sterowników pod Linuxem, więc dostęp do urządzenia będzie możliwy tylko wtedy, gdy:
A) urządzenie działa w Linuksie (posiada odpowiedni sterownik)

B) no i oczywiście, gdy Wine obsługuje połącznie interfejsu tego sterownika z API sterownika w Windowsie
Problemy z bibliotekami dll:
A) Nie ma odpowiedniego pliku dll - skutkuje to błędem przy instalacji jakiejś aplikacji. Jak widać, przydałby się debuger lub oryginalny Windows do sprawdzenia, czego potrzeba. Ale przecież nie o to chodzi.

B) Sytuacja jak wyżej, ale instalacja się powiodła - Wine udawał, że taki plik istnieje, tworząc fałszywe dll. Instalacja się udała, a program może nie dać się uruchomić, ponieważ np. przeglądane jest wnętrze dll i sprawdzana jego wersja - wówczas oszustwo wychodzi na jaw ...
screenshoot z instalacji Winampa

a tu z próby uruchomienia ...
Tak przy okazji sposób użycia - w linii poleceń wpisujemy: wine nazwa_aplikacji;
dlatego musimy wiedzieć, gdzie znajduje się dany plik wykonywalny i jaką ma nazwę;
Niektóre rzeczy trzeba zrobić samemu, np. jakieś konfiguracje - zamontować CD-ROM, pamiętająć o opcjach takich jak unhide (Windows lubi ukrywać pliki i gdybyśmy ich nie znaleźli, to np. wyskoczyłby błąd w razie potrzeby skorzystania z nich np. przez uruchamianą przez nas aplikację)

C) Co wybrać - Co za dużo, to czasem niezdrowo. Wine może używać oryginalnych windowsowych plików dll, jeśli są jakieś dostępne. Pytanie brzmi, czy jeżeli ma do nich dostęp, powinien wybrać właśnie je, czy też własną implementację. W praktyce należy przetestować wybory, korzystając też z debugera. Narzucające się oryginalne dll-e mogą zawierać wiele dowiązań, których nie będziemy w stanie odnaleźć.

D) Częściowa implementacja Większość plików dll ma odpowiedniki w Wine, ale ich możliwości są często niepełne. Zatem może się okazać, że dll, który powinien zapewnić jakąś funkcjonalność, nie jest w stanie tego zrobić. Okazuje się to dopiero po fakcie, gdyż pliki dll są ładowane dynamicznie.

Ciekawostki

Istnieje lista najlepiej obsługiwanych aplikacji na stronie WineHQ. Wśród nich jest m.in. putty.

Jak widać na załączonym obrazku działa bez zarzutu.
Jest też lista z troszkę gorzej obsługiwanymi - jest tam m.in. Winamp i Winzip. Konkretnie Winamp 3.0 co tłumaczy naszą porażkę przy instalacji nowszej wersji.
Wine umożliwia nawet drukowanie przez aplikacje Windowsowe. Radzi sobie też z Windows Media Player.
Konfiguracja - od niedawna jest wykonywana automatycznie, dlatego nie musimy się nią przejmować. Jeśli jednak chcemy zamontować coś samemu, trzeba wprowadzić zmiany w katalogu ~/.wine w pliku konfiguracyjnym wine.conf
Pojawiają się i komercyjne wersje Wine. Najpierw za sprawą CodeWeavers (rys historyczny). Jedną z takich wersji jest Cedega. Umożliwia ona uruchamianie nawet zaawansowanych gier windowsowych pod Linuxem. Nie potrzeba do tego źródeł gry, po prostu pliki wykonywalne są ładowane do pamięci na Linuksie i linkowane dynamicznie z kodem zapewniającym implementację Win32 API używaną przez program. API większości gier windowsowych jest bazowane na systemie Microsoft's DirectX. M.in. do radzenia sobie z grafiką 3D (Direct3D), wejście myszy i klawiatury (DirectInput), dźwiękiem (DirectSound) itd.
TransGaming pracuje nad stworzeniem kompatybilnych wersji tych API, pracujących na linuksowych odpowiednikach OpenGL, X11 oraz OSS i ALSA.
Cedega chwali się kompletnym wsparciem dla engine'ów i SDK takich jak Bink, Lithtech, Miles, Havok, Renderware. Twierdzą też, że po kilku latach prac mają, zaraz po samym Microsofcie, najlepiej znającą DirectX ekipę programistów.
Wspierają takie gry jak: Max Payne 2, GTA Vice City, Battlefield 1942, Battlefield: Vietnam, WarCraft III, Diablo II, Half-Life. Mimo że jest to projekt komercyjny, udostepnia źródła w CVS. Jest na naszym Wydziale przynajmniej jedna osoba, która skorzystała z tego i uruchomiła CounterStrike'a pod Linuxem.

Instalowanie

ściągamy najnowszą wersję ze strony www.winehq.org/site/download

Możemy instalować ze źródeł:
Rozpakowujemy ściągnięty plik:
tar -zxvf Wine-WERSJA.tar.gz
Wchodzimy do nowo powstałego katalogu i wpisujemy:
./configure && make depend && make && su -c "make install"
Zalogowani jako root możemy użyć pakietu i po prostu wpisać:
rpm -iv wine-WERSJA-i386.rpm