Niedawno na Tabletowo mogliście przeczytać mój tekst o szansach i zagrożeniach związanych z Windowsem 10 dla procesorów ARM, który pojawi się na nowych urządzeniach już w pierwszej połowie roku 2017. Czy okaże się klęską, taką samą, jaka spotkała Windows RT? Czym technicznie różni się próba przeniesienia Windowsa na platformę mobilną sprzed paru lat od tej, którą zapowiedziano w tym miesiącu?
Dla powtórzenia – Terry Myerson podczas kongresu WinHEC w Shenzen ogłosił stworzenie nowej wersji (SKU) Windowsa, skompilowanej specjalnie dla 64-bitowych procesorów ARM. Tym razem będzie to „pełny Windows”, który zarówno wizualnie jak i funkcjonalnie ma (prawie) niczym nie różnić się od Windowsa 10 dla procesorów x86/64. Okaże się to możliwe dzięki emulatorowi wbudowanemu w system, który pozwoli na instalowanie i uruchamianie 32-bitowych desktopowych aplikacji Win32, projektowanych dla procesorów Intela/AMD bez żadnej dodatkowej ingerencji ze strony użytkownika czy programistów.
Nie jest to pierwsza przygoda Microsoftu z Windowsem dla ARM. Oprócz głośnego Windowsa RT, były przecież też Windows Embedded czy Windows Phone, a od jakiegoś czasu mamy darmowy Windows 10 IoT Core dla 32-bitowych ARMów. Skupmy się jednak przez chwilę na Windowsie RT, stał się pierwszą poważną próbą przeniesienia „dużego” Windowsa na tą nową architekturę, która zaczęła święcić triumfy w świecie smartfonów. RT to temat wiecznych polemik i złośliwości – po latach łatwo krytykować nieudany projekt. Warto się jednak zastanowić jaka idea stała za Windows RT, wcześniej roboczo nazywanym po prostu WOA (Windows on ARM).
Myśląc o Windows RT powinniśmy mieć na uwadze kilka najważniejszych elementów:
- nowe jądro skompilowane dla ARM, bazujące na wspólnym jądrze Windows NT (wraz z warstwą middleware nazywanym zbiorczo „Windows Core OS”);
- model aplikacji, który faworyzował dotykowe aplikacje „Metro” dystrybuowane wyłącznie przez sklep;
- aktualizacje sterowników, usług i systemu były dostarczane tylko i wyłącznie przez wbudowaną usługę Windows Update;
- brak możliwości instalacji czy emulowania starego oprogramowania Win32, poza MS Office, które było dołączane do systemu i w automatyczny sposób aktualizowane;
- wprowadzenie trybu Connected Standby, który sprawiał, że urządzenia z WOA nie były wyłączane, tylko „usypiane” jak smartfon;
- skoncentrowanie się na obsłudze dotykiem – pulpit (z myszą i klawiaturą) był tylko dodatkiem.
Dzisiaj mówi się tylko o wadach tego podejścia. Deweloperzy (z wielu przyczyn) nie tworzyli aplikacji dla WinRT, co sprawiło, że dla Windows RT brakowało zarówno oprogramowania dotykowego, jak i pulpitowego. A bez twórców aplikacji system po prostu nie mógł przeżyć. Ale jest i druga strona medalu. Takie założenia, w teorii, prowadziły do stworzenia systemu bardzo przyjaznego użytkownikowi. Bez złośliwego oprogramowania, bez stopniowej degradacji wydajności, z szybkim wznawianiem systemu i długim czasem życia na jednym ładowaniu. Kompromis był jak najbardziej świadomy i przemyślany. I to nie sam system zawiódł. Zawiodła platforma WinRT, która była na tyle niedojrzała, że nie pozwalała deweloperom tworzyć zaawansowanego oprogramowania, które już wtedy pojawiało się dla iOS i Androida. ARM to przyszłość. Dzięki architekturze RISC (w przeciwieństwie do CISC-owej architektury od Intela/AMD) i prostszemu zestawowi instrukcji, procesory od Qualcomma, Nvidii czy Texas Instruments z roku na rok czyniły ogromne skoki wydajnościowe, podczas gdy seria Core Intela drobiła z roku na rok odnotowując przyrosty wydajności na poziomie 10-15%. Intel nie może sobie pozwolić na innowacje i znaczące zmiany w projektowaniu czipów ze względu na wsteczną kompatybilność. Wystarczy wspomnieć projekt Itanium, by zrozumieć jak to się może skończyć.
Windows 10 dla ARM, oprócz natywnego jądra i systemu operacyjnego skompilowanego specjalnie dla ARM i natywnych aplikacji platformy UWP (nowa platforma Universal Windows Platform, która pojawiła się wraz z Windows 10), pozwoli na emulowanie niemalże wszystkich programów x86/64. Nie będziemy wdawać się w semantyczne spory czym jest emulacja i czym różni się ona od wirtualizacji, ale spróbujemy zebrać wszystkie informacje, które są dostępne na temat technicznych aspektów tego rozwiązania.
Jak zatem aplikacje desktopowe Win32 projektowane dla platformy Intela i AMD uruchamiane są na ARMach? Wiemy na pewno, że emulator będzie działał w trybie JIT (Just in Time), czyli w momencie uruchomienia pliku wykonywalnego będzie analizował uruchamiany kod i tłumaczył go na kod maszynowy zrozumiały dla procesora ARM. Emulacja zawsze wiąże się z pewnym narzutem w wykorzystaniu czasu procesora oraz pamięci operacyjnej – co oczywiście negatywnie odbija się na odczuwalnej wydajności. Microsoft zastosował jednak dwa bardzo ważne triki, znacznie zwiększające wydajność takiego rozwiązania:
- Caching („keszowanie”) rezultatów emulacji. W skrócie – tylko pierwsze uruchomienie danych funkcji czy wywołań systemowych będzie tłumaczone/emulowane „just in time”. Każde ponowne wywołanie będzie korzystać z zapisanych w pamięci (podręcznej lub trwałej) rezultatów emulacji, co w praktyce sprawi, że kolejne odwołania będą w zasadzie natywne – bez narzutu związanego z translacją kodu z jednej platformy na drugą. Dla dociekliwych, polecam zapoznać się z tym czym są fat bianries (i implementacją Compiled Hybrid Portable Executable) oraz z projektem Bascule.
- Wywołania systemowe i dowołania do istniejących API dla x86/64 będą przekierowywane do odpowiadających im natywnych zasobów i API Windowsa 10 dla ARM. To też pozwoli „znatywizować” wiele kodu bez konieczności jego tłumaczenia. A im więcej kodu natywnego (a mniej emulowanego), tym większa wydajność tego rozwiązania. I mniejsza zasobożerność.
Całość ma działać jako osobna warstwa systemu – a być może nawet jako podsystem, który może być włączany i wyłączany w zależności od potrzeb. Łatwo sobie wyobrazić włączanie i wyłączanie takiego podsystemu na smartfonie, który mógłby uruchamiać aplikacje pulpitowe dopiero po zadokowaniu czy podłączeniu do źródła zasilania (tryb Continuum). Na razie Windows 10 dla ARM zaprojektowany jest dla hybryd i laptopów, ale ciężko jest uniknąć spekulacji o wykorzystaniu tej technologii w smartfonach.
To zdecydowanie inne podejście niż w przypadku Windowsa RT. Windows 10 dla ARM w obsłudze i funkcjach dla użytkownika końcowego, (prawie) niczym nie będzie różnił od intelowego odpowiednika dla x86/64. Ktoś powie: „ale na ARM-ach nie uruchomi się wszystkich zaawansowanych programów czy gier ze względu na ograniczenia wydajności”. To prawda. Ale tak samo jest z intelowskimi Atomami. Oczywiście ograniczeń będzie trochę więcej. Najprawdopodobniej na Windows 10 dla ARM nie uruchomimy narzędzi do wirtualizacji, takich jak VirtualBox czy choćby Bluestacks. Ale większości użytkowników zupełnie nie będzie to obchodzić. Najważniejsze, że będą mieli do dyspozycji wszystkie programy i narzędzia, które dostępne były na ich poprzednim komputerze z procesorem x86/64.
Po klęsce Windowsa RT i dość powolnym starcie platformy aplikacji UWP, podejście wykorzystujące emulację i wsteczną kompatybilność wydaje się ze wszech miar zasadne. Microsoft nie może sobie drugi raz pozwolić na wypuszczenie systemu-pustyni – bez aplikacji zarówno desktopowych jak i dotykowych.
Wszystko jednak rozbije się o realną wydajność prezentowanego rozwiązania. Microsoft na prezentacji pokazał jak szybko i sprawnie uruchamia się Photoshop na urządzeniu ze Snapdragonem 820. Czas uruchomienia rzeczywiście robił wrażenie. Z pierwszymi opiniami jednak będzie poczekać i sugerowałbym studzić entuzjazm. A zagrożeń jest wiele. Wspieranie różnych form emulacji jest zaprzeczeniem nadrzędnego celu stworzenia nowoczesnego systemu operacyjnego, który będzie stabilny, przewidywalny i szybki po upływie czasu – z definicji, kod Win32 nie był optymalizowany do działania na mobilnej platformie zgodnej z ARM. Konwencja tworzenia oprogramowania desktopowego, uwzględniająca procesy w tle, pętle odpytywania, timery, programy w autostarcie, ingerencje w rejestr, kod wykonywany w kernel mode, prawa admina, niepodpisane sterowniki, plug-iny i wiele innych technik po prostu nie przystaje do nowoczesnego OS-u.
Wirtualizowane czy emulowane oprogramowanie będzie zużywać więcej zasobów, włączając w to pamięć RAM, CPU i baterię – być może na poziomie nieakceptowalnym dla współczesnych urządzeń mobilnych. Z drugiej strony, przejście z PowerPC na Intela w przypadku Apple dzięki emulatorowi Mac 68k było nad wyraz płynne i stabilne. W tamtym przypadku jednak, Intel miał znaczną przewagę wydajnościową nad PowerPC. Dzisiaj sytuacja ARM vs Intel wygląda odwrotnie…
