Emulacja trybu użytkownika

Niedługo na rynku zagości Windows 8 w wersji na ARM. Postanowiłem więc swoje dzisiejsze rozmyślania pewnemu, dość abstrakcyjnemu tematowi – czy byłoby to technicznie możliwe, by system ten był w stanie uruchamiać aplikacje ze swojego biurkowego odpowiednika bez rekompilacji?

“HAHAHAHAAHAHAHAHAHAHAHAHAHAHAHA zmień dilera” – ile w tym prawdy?

Zacznijmy więc od teorii. Powszechnie wiadomo, że aplikacji skompilowanych dla jednej architektury procesora, nie da się uruchomić na innej, ponieważ ich kod binarny jest całkowicie inny. Posłużę się tutaj metaforą języków. Przyjmijmy więc, że każda narodowość to architektura procesora. Mieszkańcy tych różnych państw posługują się odmiennymi językami, które tylko oni rozumieją. W takiej sytuacji, by nawiązać kontakt z obcokrajowcem, potrzebujemy albo wspólnego języka (tzw. kod zarządzany) lub tłumacza, który zna oba (emulator). Pierwsza opcja zapewnia takie same zrozumienie komunikatu przez obie strony, zaś druga – powoduje opóźnienia i czasem też błędy.

Emulacja całej platformy sprzętowej jest jednak zbyt powolne i na dłuższą metę – bezsensowne. Kompletny system operacyjny pożera sporo zasobów i działa wolno, jednak kto powiedział, że nie można tego zrobić inaczej?

Kamień z Rosetty

Na ten pomysł wpadło Apple, dokonując w 2006 roku przejścia komputerów Macintosh z procesorów PowerPC na procesory Intel. Pierwsze wersje Mac OS X (aż do wersji 10.6) na procesory x86 zostały wyposażone w emulator o nazwie “Rosetta”, który pozwalał na uruchamianie aplikacji skompilowanych dla PPC z akceptowalną prędkością. Oczywiście, narzędzia wymagające dużej mocy nie były zbytnio użyteczne, ale Rosetta nie ma żadnego problemu z tymi mniej wymagającymi aplikacjami, jak np. Word. Jak widać, działa – i nawet sprawdza się w praktyce.

Darwine – czyli próba stworzenia portu WINE na Maka PPC

Na podobny sposób wpadli twórcy portu WINE na Mac OS X, zaczynając prace nad swoim portem w 2002 roku. Można się domyślić, że samo przekompilowanie na PowerPC w niczym by nie pomogło – moglibyśmy uruchamiać nieistniejące, Windowsowe aplikacje skompilowane pod PPC. Dlatego też postanowiono zintegrować emulator procesora x86 z WINE już na bardzo niskim poziomie – wymagało to sporej ingerencji w kod, ale mogło się udać. Projekt był już w całkiem obiecującej fazie, jednakże porzucenie PowerPC na rzecz procesorów Intela wystarczająco zniechęciło twórców, by stwierdzić, że to po prostu się nie opłaca.

qemu-i386 i smartfony z pasjansem

Użytkownicy Linuksa już od dawien dawna mogli uruchamiać aplikacje z x86 na innych architekturach, przy użyciu qemu-i386. Mimo, że skonfigurowanie go jest bolesne niczym wrzód na dupie oraz wymaga wszystkich plików z pełnoprawnej dystrybucji Linuksa na x86 (brak niskopoziomowej integracji), okazuje się nawet działać. W przeciwieństwie do pełnej emulacji platformy x86, tutaj podlegają temu jedynie aplikacje i wymagane biblioteki, więc aplikacje integrują się z systemem w całkiem natywny sposób. Nie straszne im też interfejsowanie z jądrem. Gdyby jednak emulacja ta była zintegrowana na niższym poziomie, prędkość aplikacji uruchamianych w ten sposób byłaby o wiele większa. jshafer817 z XDA Developers pokazał, że w ten sposób jest w stanie uruchomić na Androidowym smartfonie lub tablecie pasjansa z Windowsa przez WINE. Oczywiście jest to dość problematyczne rozwiązanie, tak więc obecnie to jedynie sztuka dla sztuki. Ale kto wie, w jakim kierunku to dalej pójdzie?

Port ReactOS’a z wbudowanym emulatorem x86 – to możliwe?

Jak już pokazałem wcześniej, niskopoziomowa integracja emulatora instrukcji x86 czyni cuda. Wróćmy więc do pytania ze wstępu, czy Windows 8 na ARM mógłby uruchamiać aplikacje z biurkowych komputerów, gdyby tylko Microsoft tego chciał? Odpowiedź na to pytanie najwidoczniej znają pewni zwolennicy ReactOS’a, którzy zaproponowali takie rozwiązanie w przypadku przyszłych portów na PowerPC, ARM i resztę dziwacznych platform. Z danych zdobytych przez użytkownika BrentNewland wskazują na to, że używając tej techniki, można uruchamiać aplikacje z x86 na innych platformach z przynajmniej 50% ich natywnej prędkości lub nawet więcej, gdyby przechwytywać również odwołania do bibliotek i emulować jedynie te, które nie są dostępne w systemie. Jak widać, to możliwe, lecz wymaga sporego nakładu pracy, na który twórcy tego systemu nie mogą sobie obecnie pozwolić, wciąż tkwiąc w fazie alfa. Bardziej zainteresowanych, odwołuję do wiki ReactOS’a, która powinna odpowiedzieć na Wasze wszystkie pytania.

Konkluzja

Wracając jednak do Windows 8. Microsoft w przeciwieństwie do fundacji ReactOS dysponuje odpowiednimi środkami, by urzeczywistnić tę koncepcję i pozwolić nam cieszyć się starymi Windowsowymi gierkami na naszych ARM’owych tabletach, których nie mamy. Niestety, obecnie zostaje nam jedynie narzekać na politykę tej firmy. Pocieszający jest jedynie fakt, że będziemy przynajmniej w stanie uruchamiać aplikacje z platformy .NET bez większych trudności, ponieważ to kod zarządzany.