Emulacja Linuksa w jądrze Windows NT, czyli jak Microsoft chce sobie zabrać aplikacje Androida

O autorze

Adam Golański

@eimi

Hodowca maszyn wirtualnych i psów, poza tym stary linuksiarz, bonvivant i śmieszek. W 2012 roku napisał na DP o algorytmie haszowania Keccak i wciąż pamięta, jak on działa.

Od kilku dni programiści zainteresowani przeniesieniem swoich aplikacji z iOS-a na Windows mogą już korzystać z mostu WinObjC (do niedawna noszącego nazwę kodową Project Islandwood), dzięki któremu kod pisany w ObjectiveC na mobilne systemy Apple'a będzie można zamienić w aplikację dostępną w Windows Store. Podobne rozwiązanie Microsoft przygotowuje dla piszących oprogramowanie na Androida. Rozwijany w tym celu Project Astoria nie jest jeszcze publicznie dostępny, ale redaktorzy serwisu WMPowerUser zdobyli pierwszą wersję jego dokumentacji deweloperskiej. Jeśli obietnice Microsoftu się sprawdzą, urządzenia z mobilnym Windows będą mogły sobie z oprogramowaniem Androida radzić równie dobrze, co sam Android.

Zgodnie z przedstawioną dokumentacją, kernel NT w urządzeniach z Windows 10 został rozbudowany, trafił do niego kompletny podsystem Androida, włącznie z mechanizmem translacji wywołań interfejsów linuksowego jądra. Nad tym zmodyfikowanym kernelem NT działa coś, co Microsoft nazywa „pikoprocesami”, swoistymi kontenerami, w których działać mają niezbędne dla androidowych aplikacji biblioteki i frameworki. I tak dostajemy dla aplikacji pełen komplet bibliotek Libc, SSK, WebKit, SQLite i OpenGL, pełen NDK dla aplikacji natywnych, środowiska uruchomieniowe Dalvik i ART, standardowy framework aplikacyjny, oraz specjalne microsoftowe SDK, umożliwiające emulację usług Google Play Services.

Zamknięte w pikoprocesie aplikacje będą jednak ograniczone w swoich możliwościach względem tego, co mogą na Androidzie – nie będą mogły np. uruchomić dodatkowych procesów, zapewne też nie będzie łatwo uruchomić większej liczby takich aplikacji na urządzeniu z Windows jednocześnie. Każdy kontener będzie bowiem sporo większych rozmiarów, niż normalna aplikacja, zawierając wszystkie jej zależności, niewspółdzielone między kontenerami. Androidowe procesy będą zarządzane autorskim menedżerem sesji Microsoftu, dbającym o przydzielanie im zasobów sprzętowych, tak by pikoproces nie zdominował całkowicie Windows Phone'a.

Przygotowywanie androidowych aplikacji do działania na Windows praktycznie nie będzie więc wymagało żadnych większych starań, chyba że korzystają z Google Play Services. Co ciekawe, Microsoft chyba pogodził się z tym, że dla coraz większej liczby programistów naturalnym środowiskiem pracy jest MacBook Pro – SDK Projektu Astoria będzie dostępne więc nie tylko na Windows, ale też na OS-a X. W systemie operacyjnym trzeba będzie mieć zainstalowane JDK Javy 7 lub 8 oraz środowisko deweloperskie IntelliJ lub Android Studio.

Zainteresowanych szczegółami zapraszamy do dysku MEGA, tam znajdziecie PDF z dokumentacją Astorii. Pozostaje teraz tylko pytanie – komu w świetle tych wszystkich mostów z iOS-a, Androida, WWW i win32 będzie się jeszcze chciało pisać natywne aplikacje na mobilne Windows? Microsoft gra tu w dziwną grę – tym bardziej, że cała ta historia z emulacją oznacza konieczność gonienia znikającego punktu, co już dziś jest widoczne w wypadku mostu WinObjC, nie obsługującego aplikacji pisanych w języku Swift.