Najprawdopodobniej na Tabletowo nie znajdziecie recenzji Windowsa 10. Wiele polskich i zagranicznych blogów stworzyło dość szczegółowe wpisy o tym systemie i nie mogę znaleźć wystarczającego powodu, by je dublować.
Pomimo tego, że wielu autorów odwaliło kawał dobrej roboty, ich tekstów nie nazwałbym recenzjami. Bo system operacyjny to nie tylko interfejs użytkownika, wbudowane aplikacje i nawigacja. Nie można zrecenzować systemu bez wzmianki o jego jądrze, środowiskach uruchomieniowych, narzędziach programistycznych czy wydajności. Są to elementy bardzo ważne, ale również mało interesujące dla przeciętnego użytkownika. Windows 10 jest początkiem czegoś nowego, a może nawet czegoś wielkiego dla Microsoftu, skoncentrujemy się zatem nie na powierzchownych zmianach, a na całej koncepcji stojącej za tym systemem.
One Core
Jeszcze kilka lat temu, Microsoft miał kilka systemów operacyjnych, opartych na różnych kernelach. Jądro CE gościło w smartfonach, NT w desktopach, a Xbox 360 również miał własne niskopoziomowe oprogramowanie, niekompatybilne z pozostałymi. Wersja 8.0 Windowsa i Windows Phone wprowadziła pewną unifikację – w obu tych systemach zastosowano kernel Windows NT. Ale to dalej było zbyt mało, żeby ułatwić sprawę deweloperom. Kolejnym krokiem były wersje Windows i Windows Phone 8.1, przynoszące wspólne środowisko uruchomieniowe WinRT, pozwalające na tworzenie (częściowo) uniwersalnych aplikacji. W jednej solucji Visual Studio tworzyło się trzy projekty – jeden wspólny, jeden dla W8.1 i jeden dla WP8.1. Trzeba było jednak tworzyć osobne widoki i interfejsy dla obu wersji – czyli osobny kod. Oddzielne też było API dla smartfonów i pozostałych urządzeń. A tymczasem Xbox One zadebiutował również z jądrem NT. Windows 10 to kolejne duże uwspólnienie systemów – współdzielony jest nie tylko kernel NT i środowisko uruchomieniowe WinRT, ale też biblioteki i API, które teraz koncentrują się nie na rodzaju urządzenia (smartfon / tablet / laptop), a na jego funkcjach (GPS / akcelerometr / dotyk / Bluetooth). To samo API i środowisko uruchomieniowe dostępne będzie na Xboxa, HoloLens czy urządzenia IoT, ale na razie nie na Microsoft Band.
Celem takiego podejścia jest uproszczenie pracy deweloperów, którzy dzięki nowym znacznikom XAML-a („odpowiednik” HTML-a do tworzenia interfejsów aplikacji WinRT) i podejściu Adaptive UX będą zazwyczaj tworzyć jeden widok i jedną logikę aplikacji, bez konieczności tworzenia kilku projektów w ramach jednej solucji. Wspólne jądro i niskopoziomowa warstwa systemu wraz z uniwersalnym API pozwolą na pokonanie dotychczasowych inżynieryjnych barier i uniknięcia konieczności wykorzystywania maszyn wirtualnych, znanych choćby z Androida. One Core to nie tylko smartfony i komputery. Cel jest dużo ambitniejszy i dotyczy nowych typów urządzeń, które albo juz zadebiutowały (HoloLens) albo zadebiutują w przyszłości. Dlaczego to takie ważne? Do tej pory Microsoft był wiecznie spóźniony z hardware’owymi nowościami. Sam proces tworzenia i projektowania nowego sprzętu jest długotrwały, ale jeszcze więcej czasu zajmuje przygotowanie systemu operacyjnego i platformy do nowego urządzenia. Windows 10 rozwiązuje ten problem. Każde nowe urządzenie może wykorzystywać jądro NT i Windows 10 „z marszu” przy jedynie drobnym dostosowaniu interfejsu użytkownika i sposobu interakcji z urządzeniem. Proces wprowadzenia nowej kategorii urządzeń na rynek dzięki temu może znacznie się skrócić. Mało tego – nowy sprzęt na dzień dobry będzie miał dziesiątki czy setki tysięcy uniwersalnych aplikacji ze skalowalnym UI. I to jest właśnie ogromna zmiana i potencjał, jaki niesie ze sobą Windows 10 – ze wspólnym jądrem, runtimem i API.
Windows as a Service
Windows jako usługa – słyszymy to od bardzo dawna, ale nadal nie dla wszystkich do końca jasne jest o co chodzi z tą ideą WaaS. Zacznijmy od tego czym WaaS NIE jest. Nie chodzi tu o coroczną odpłatność, tak jak jest to w przypadku Office 365 czy płatnych planów OneDrive. Windows jako usługę trzeba rozumieć jako odejście od tworzenia wielkich kompilacji raz na trzy lata i dystrybuowanie ich w postaci płyt DVD, nośników USB czy plików ISO. Wszelkie zmiany, łatki bezpieczeństwa i nowe funkcje będą dostarczane w postaci mniejszych i częstych automatycznych aktualizacji poprzez usługę Windows Update. Microsoft musi zmierzyć się ze swoim odwiecznym problemem – jak pogodzić użytkownika prywatnego, nastawionego na rozrywkę z użytkownikiem korporacyjnym czy instytucyjnym. W czym problem? Konflikt interesów. Pojedynczy konsument oczekuje dużej liczby nowości, częstych aktualizacji i nie przeszkadzają mu sporadyczne błędy i problemy. Widać to na przykładzie systemów takich jak iOS, Android czy OSX, które przechodzą jedną dużą aktualizację w roku i kilka mniejszych. Klient korporacyjny czy ten z instytucji publicznych / państwowych ma natomiast zupełnie inne priorytety. Po pierwsze – dla niego aktualizacje najprawdopodobniej nie będą darmowe, więc chce to robić najrzadziej jak tylko może – dopóki bieżący system wystarcza do pracy (tak jak to było i jest z XP). Po drugie, dla takiego klienta liczy się przede wszystkim stabilność i minimalne środki poświęcane na konserwację systemu.
Nikt sobie nie wyobraża ciągłych zmian i problemów z kłopotliwymi aktualizacjami w dużej korporacji czy szpitalu, gdzie system operacyjny jest narzędziem pracy, a nie gadżetem, o który kopie kruszyć będą wszelkiej maści fanatycy i entuzjaści. Do tych bardziej wymagających odbiorców trafi Long Term Servicing Branch, czyli gałąź, w której pojawiać się będą tylko łatki bezpieczeństwa, a wybrane aktualizacje będą mogły być instalowane na wyraźne życzenie administratora systemu. Użytkownik domowy będzie natomiast dostawał nowe funkcje automatyczne, ale z możliwością ich ręcznego odinstalowania. Pozwoli to na szybszą adaptację pełnej funkcjonalności systemu oraz utrzymywanie należytego poziomu bezpieczeństwa. A dostarczanie łatek bezpieczeństwa poza producentami i operatorami jest niezbędne, o czym boleśnie przekonują się użytkownicy Androida, którzy w większości w ogóle nie są chronieni, gdy Google lub wybrany producent nie decyduje się na wypuszczenie globalnego pacza. Takie podejście wyeliminuje też problem „Windowsa XP”, czyli sytuacji, w której większość użytkowników danego systemu korzysta z przestarzałej i ubogiej wersji systemu, podczas gdy firmie zależy na sprawnym wdrażaniu nowości.
W tym momencie też dochodzimy do momentu, w którym wyjaśnia się darmowość aktualizacji. Microsoftowi zależy, żeby wszyscy lub możliwie najwięcej osób porzuciło starsze systemy i zainwestowało w Windowsa 10, a co za tym idzie w jego aplikacje i środowisko WinRT. Bez setek milionów użytkowników nie ma mowy o ściągnięciu uwagi deweloperów, a bez ich uwagi nie ma nowych i bieżąco aktualizowanych aplikacji. A bez aplikacji konsumencki system operacyjny w dzisiejszym świecie nie ma racji bytu.
Universal Apps
Uniwersalne Aplikacje wreszcie stały się prawdziwie uniwersalne. Trzeba zaznaczyć, że UA w W10 to nie to samo co UA w W8.1. W wersji 8.1 UA mogą współdzielić kod źródłowy i cały backend (szacuje się, że jest to w zależności od złożoności appki od 70-90% kodu), ale trzeba było tworzyć osobne interfejsy użytkownika („wygląd”) dla smartfonów i dla tabletów. Wszystko w ramach jednej solucji Visual Studio, ale na osobnych wynikowych „binarkach”. Mało tego, „Uniwersalną Aplikacją” mogła się nazywać appka, która nie współdzieliła kodu wcale, a wspólne miała jedynie zachowywanie stanu aplikacji (np stan gry, czy zakupy w aplikacji) w chmurze i synchronizowanie tego stanu między smartfonem a tabletem. Przykładem takiej appki jest gra Halo od Microsoftu.
W Windowsie 10 Uniwersalne Aplikacje są prawdziwie uniwersalne. Nie ma rozróżnienia czy to smartfon czy tablet, czy komputer PC, czy Xbox, czy Surface Hub – kod w 100% może być ten sam – bez osobnych widoków. Nowy makrup XAML , dzięki kontrolkom takim jak RelativePanel czy AdaptiveTrigger, pozwala automatycznie lub półautomatycznie skalować interfejs w zależności od wielkości ekranu. Oczywiście projektant będzie mógł wprowadzić udogodnienia w sytuacjach, kiedy automatyczne skalowanie i rozmieszczanie elementów na ekranie nie będzie optymalne pod względem łatwości obsługi – na przykład w mniejszych urządzeniach będzie mógł przesunąć nawigację do dolnej części ekranu – w pobliże kciuka. To zdecydowanie najważniejsza zmiana, która pozwoli tworzyć „responsywne” aplikacje, a „responsywność” ta będzie uzyskiwana dzięki zabiegom w XAML-u, a nie w bazowym kodzie programu, tak jak wyglądało to dotychczas.
Pierwszym etapem jest właśnie uproszczenie fazy tworzenia aplikacji. Druga faza to powszechność ich występowania – mogą być one uruchamiane na wszystkich urządzeniach z Windowsem 10 bez żadnych dodatkowych zmian czy przystosowywania ich do wybranego sprzętu. Projekt UA może odnieść sukces tylko wtedy, gdy Windows 10 zgromadzi ogromne rzesze aktywnych użytkowników, którzy dodatkowo aktywnie będą korzystać z Windows Store. Jeśli Microsoftowi uda się zachęcić użytkowników do korzystania ze sklepu na desktopach i laptopach, a W10 będzie sukcesem jeśli chodzi o liczbę aktywacji – deweloperzy zaczną tworzyć aplikacje właśnie tam gdzie są ludzie. A dzięki temu zyska również Windows Mobile i wszystkie inne urządzenia działające pod kontrolą nowych okienek. Pytanie tylko – jak „zmusić” userów desktopowych do korzystania z Windows Store. A problem ten wbrew pozorom nie jest taki trywialny.
Islandwood i Astoria
Dla jednych portowanie appek z iOS i Androida to początek końca mobilnego Windowsa, dla innych – ostatnia nadzieja na podreperowanie sytuacji aplikacji w sklepie Windows Store. Temat ten niewątpliwie budzi skrajne emocje. Szerzej omawiałem go tutaj i tu, ale warto w kilku zdaniach omówić założenia tych projektów. Astoria to kodowa nazwa projektu, pozwalającego tworzyć aplikacje dla Windows 10 Mobile na bazie Appek z Androida. Aplikacje te nadal pisane są w Javie i znanych andridowcom środowiskach programistycznych takich jak Android Studio czy Eclipse. Microsoft udostępni narzędzia online i API, które pomogą nam przepakować .apk do kontenera windowsowego i stworzyć aplikację, która będzie uruchamiana na W10 Mobile w maszynie wirtualnej Javy lub natywnie, jeśli appka została napisana w C++. Ta maszyna wirtualna wraz z całym środowiskiem uruchomieniowym będzie nieodłącznym elementem Windows 10 w wersji mobilnej.
Projekt Islandwood pozwoli na przenoszenie aplikacji z iOS na Windowsa zarówno mobilnego jak i desktopowego. Działać to będzie jednak na zupełnie innej zasadzie, niż w przypadku przepakowywania appek z Androida. Dostępne narzędzia pozwolą na import projektu aplikacji iOS do Visual Studio 2015 – który w tym środowisku programistycznym będzie mógł być edytowany. Język programowania oczywiście pozostaje bez zmian i jest nim Objective-C. Po niezbędnych zmianach w kodzie oraz dodaniu opcjonalnych funkcji obsługiwanych przez Windowsa (takich jak dynamiczne kafelki), Visual Studio umożliwi debugging i kompilację projektu do natywnego kodu binarnego Windowsa 10 bez potrzeby korzystania z emulatorów czy maszyn wirtualnych.
Po co to wszystko? Głównym celem jest zainteresowanie deweloperów platformą Windows. Przy niewielkim nakładzie pracy będą oni w stanie przenosić istniejące aplikacje do okienek. W teorii brzmi to pięknie. W praktyce rodzi kilka zagrożeń. Po pierwsze, deweloperzy mogą na tym poprzestać. Zamiast tworzyć dopracowaną uniwersalną aplikację, na szybko przeportują istniejący projekt, który nigdy nie będzie tak wydajny jak jego natywne odpowiedniki. Po drugie, odciąga to uwagę od platformy aplikacji uniwersalnych, które dostępne będą nie tylko na smartfonach i pecetach. Czy to jest stateczne rozwiązanie problemu aplikacji? Wydaje mi się, że Microsoft może się bardzo przejechać na obu tych projektach.
Continuum
Windows 10 potrzebował wyróżnika. Wersja 8 miała być systemem operacyjnym dla tabletów i desktopów. Była jednak kiepskim systemem tabletowym i jeszcze gorszym desktopowym. O tym dualizmie mówił kiedyś Steve Jobs, który twierdził, że nie da się tego pogodzić. Windows 10 udowodnił, że się da – a wszystko dzięki zmyślnemu mechanizmowi Continuum, który dostosowuje interfejs użytkownika, w zależności od tego, czy obsługujemy urządzenie dotykiem czy myszką. Tryb ten dostępny jest nie tylko w wersji pecetowej, ale też w wersji Mobile. O ile w przypadku hybrydy takiej jak Lenovo Yoga 3 Pro czy Surface Pro 3 ma to sens, wiele osób kwestionuje to rozwiązanie w wydaniu smartfonowym.
W teorii, idea tego pomysłu jest świetna. Smartfon w każdej chwili po dopięciu klawiatury i myszki oraz zewnętrznego monitora może zamienić się w (prawie) pełnoprawny komputer. Pytanie jednak brzmi, czy ludzie będą korzystać z takiego rozwiązania. O ile w domu jest to możliwe po zakupieniu odpowiednich akcesoriów, o tyle na mieście nie ma do tego odpowiednich terminali. I nic nie wskazuje na to, żeby w najbliższym czasie to się miało zmienić.
Plan B?
W ostatnim wywiadzie dla BBC, Satya Nadella zapytany został o to, czy tworzenie microsoftowych aplikacji dla Androida i iOS to plan B. Czasem fani Windowsa mają za złe firmie z Redmond, że traktuje ich po macoszemu, wprowadzając appki i ich aktualizacje wcześniej dla konkurencyjnych systemów. W wielu rozmowach Nadella i Meyerson (szef Windowsa) podkreślają, że okienka dalej pozostają jednym z kluczowych produktów firmy. Wygląda jednak na to, że w przypadku kryzysu tej platformy, nikt nie chce za nią umierać. Nadella na pytanie reportera BBC odpowiedział, że nie jest to plan B, lecz plan A. Celem firmy jest stworzenie platformy aplikacji i usług (a nie systemu operacyjnego), która trafi do największej liczby użytkowników, bez względu na to, jakie środowisko pracy i zabawy sobie wybrali. Od strony biznesowej jest to decyzja ze wszech miar sensowna, jednak wyraźnie widać, że mimo ogromowi wysiłku jaki włożono w Windows 10, w przyszłości zdarzyć się może wszystko. Łącznie z uśmierceniem mobilnych okienek i marginalizacji pełnego Windowsa na starsze komputery i zastosowania korporacyjne. A wszystko będzie zależeć od liczby aktywnych użytkowników Windowsa 10 i popularności Windows Store.
