Próżny trud – przegląd zaniechanych kierunków rozwoju Windows 10, część III

Ostatnio w ramach naszej mini-serii, przedyskutowaliśmy kwestię dołączonych do systemu aplikacji. Historia programów dostarczanych wraz z Windows 10 jest zaskakująco bogata. Wiele z nich przebyło długą drogę, niekoniecznie skutkującą stworzeniem lepszej wersji. Kilka aplikacji wykruszyło się po drodze i zniknęło, a z biegiem czasu coraz silniej widoczny był brak inicjatywy w rozwoju aplikacji nawet w wykonaniu Microsoftu. Czy skromna liczba autorskich aplikacji w Sklepie i ich nierzadko mierna jakość wskazują na to, że gdzieś w Redmond planują porzucenie nowej platformy?

Przesadą byłoby jednoznaczne stwierdzenie, że oto następuje całkowity odwrót od „nowoczesnych”, zintegrowanych aplikacji, dołączanych do systemu od czasu premiery Ósemki. Żyją one bowiem nadal, ale na innym polu. Istnieją systemowe narzędzia, które w dalszym ciągu są rozwijane na bazie nowego API WinRT/UWP, jak aplikacje Zdjęcia, Kalkulator czy Rejestrator Dźwięku (wszystkie znacznie wolniejsze od klasycznych poprzedników). Prawdopodobnie pozostaną one aplikacjami UWP, a dokładniej mówiąc „nowoczesnymi” aplikacjami WinRT, ale nie ze względu na wieloplatformowość, a na łatwość serwisowania i wiele gratisowych bonusów, jak np. lepsze skalowanie i bezpieczeństwo. Coraz wyraźniej widać jednak, że WinRT się nie przyjmie. Aplikacje konsekwentnie dzielą się dwie grupy – opakowanych aplikacji webowych oraz klasycznych aplikacji Win32. Jeżeli ktoś planuje stworzyć aplikację dla systemu Windows i nie jest to coś, co da się (albo jest sens) przerobić na wieloplatformową wersję Web, to w większości wybiera klasyczne środowisko programistyczne. W ten sposób aplikacje mają szanse działać również na systemie Windows 7, a jednocześnie nie wyklucza ich to z dystrybucji w dzisiejszym Sklepie. Wbrew myśleniu życzeniowemu i zaklinaniu rzeczywistości, UWP nie zawiera w sobie wstrząsająco rewolucyjnych rozwiązań zapewniających bezsprzeczną, niepodważalną i wszechstronną przewagę nad czystym Win32. Bez telefonów do kompletu, UWP naprawdę ma nikły sens.

Samo środowisko dla nowych aplikacji, zwane początkowo TWIN UI, rodziło się w bólach. Jego pierwsza wersja, debiutująca w Windows 8, była dobrze przemyślana, ale bardzo ograniczona. W świetle rozpaczliwie niskiej jakości wbudowanych aplikacji może się to wydawać zaskakujące, ale TWIN UI swój skromny zbiór możliwości realizował zaskakująco dobrze. Windows 8.1 wyraźnie go rozszerzył, co wraz z aktualizacją interfejsu pozwoliło tworzyć bardziej zaawansowane aplikacje. W dalszym ciągu były to jednak inne aplikacje, niż te na telefony i na konsolę Xbox. WinRT z telefonów jedynie rymowało się z tym z pecetów i przeniesienie logiki wcale nie polegało wyłącznie na „przetargetowaniu” aplikacji. UWP rozwiązał ten problem, pozwalając na celowanie jednocześnie w więcej rodzajów urządzeń tym samym kodem.

Z historycznej perspektywy zabawnym jest, jaki ogrom pracy wykonano celem rozszerzenia API o całą klasę urządzeń, które zostały całkowicie odrzucone przez rynek: tablety bez pióra oraz telefony z Windows Mobile. Dyscyplina w implementacji takiego środowiska zapewniła jednak obecność pewnych przyszłościowych zalet, jak skalowanie i mniej bolesne przesuwanie kodu między architekturami. Wszystkie te zalety mogą jednak pozostać niewykorzystane. Najnowszy .NET Framework otrzymał wiele poprawek dotyczących skalowania, a prężnie rozwijający się (i naprawdę przyjemny w obsłudze) .NET Core w nadchodzącym wydaniu 3.0 otrzyma możliwość tworzenia aplikacji pulpitowych oraz zabudowywania „wysp” wykorzystujących elementy sterujące pierwotnie powstałe i dostępne tylko dla prawdziwych aplikacji WinRT. Jest to niewątpliwie racjonalne biznesowo podejście, jest jednak bolesne z powodów ideologicznych – stanowi wszak dość stanowczy odwrót od wizji ogólnoświatowej eksplozji nowoczesnych aplikacji tworzonych w UWP. Te bowiem nigdy nie nadejdą.

Zresztą UWP nie tylko nie jest priorytetem, nie jest nawet domyślną sugestią dla nowych programistów. Microsoft nie przyznaje tego wprost, ale jak zwykle można poznać ich intencje po owocach: wskazówki i poradniki dotyczą w przeważającej większości tego, co zarabia pieniądze: Azure, a więc ASP.NET w wydaniu Core. W drugiej kolejności znajdują się aplikacje PWA, czyli tak naprawdę brzydsze, aż sensowniejsze rozwiązanie tego samego problemu, z którym mierzyło się WinRT. Zresztą już pal licho tutoriale. Przyjrzyjmy się, w czym powstają najnowsze aplikacje. Microsoft Teams na przykład? Czy to aplikacja UWP? A skąd! No to może chociaż .NET? Też nie. Teams to aplikacja Electron. Czyli pod spodem jest rysowana przez przeglądarkę Google Chrome (od Microsoftu!). Co gorsza, nie jest to nawet aplikacja PWA – i to jest dopiero hit. Wersja PWA istniała i była dostępna w Sklepie. Ale już nie jest. Wyrzucono ją ze Sklepu, bo silnik Edge, używany do rysowania UWP, nie dawał sobie rady. W efekcie mamy więc aplikację nienapisaną w .NET, bo po co używać własnej platformy. Nieobecną w Sklepie, bo Edge nie daje sobie rady w dużych zastosowaniach. Nieaktualizującą się nawet przez ClickOnce, bo ten najwyraźniej też nie działa jak należy (użyto narzędzia Squirrel). Koniecznym było zatem nie tylko nieużywanie własnych technologii, ale wskutek nędznej obsługi PWA, wykorzystanie zupełnie obcych, niemal konkurencyjnych rozwiązań.

Zastosowanie kilogramów JavaScriptu, wynalazków jak React albo Electron i pominięcie Sklepu to jakaś zupełna potwarz dla wszystkich olbrzymich frameworków wbudowanych w Windows 10. A jest to podejście stosowane w wielu produktach Microsoftu. W ten sposób działają Skype, Teams i Visual Studio Code. Ten ostatni nie został napisany z najmniejszych choć użyciem Visual Studio i .NET. Co więcej! Wyżej wymienione aplikacje działają w niezmienionej postaci również pod Windows 7. Oznacza to, że nie tylko po prostu zignorowały nowe środowiska programistyczne, ale również nie wykorzystały w ogóle żadnych nowego API i funkcji Dziesiątki. Nieważne, czy z .NET, UWP, Win32, czy jakichś obskurnych COMowych „bebechów”.

Jaki płynie z tego wniosek dla użytkownika końcowego? Ano taki, że Windows 10 nie dostarcza najwyraźniej żadnej korzyści uzasadniającej migrację z poprzednich wersji systemu. Bo wszystko działa w niezmienionej postaci również na Siódemce z 2009 roku. Więc może przydałoby się w ogóle wywalić wszystkie te nowoczesne wynalazki i udawać, że Windows 8 i 10 nigdy nie miały miejsca? Hm…

Powrót do starych rozwiązań zapewne nie wchodzi jednak w grę. Spójrzmy chociażby na mapę drogową rozwoju przeglądarki Microsoft Edge. Całkowita porażka Edge’a nie poskutkowała planem powrotu do Internet Explorera. Zamiast tego sięgnięto po Chromium. Owa wstrząsająca decyzja (swoją drogą, skoro to w imię otwartości, to czemu nie Gecko?) wpisuje się w ducha postawy „dajmy już spokój z tym wszystkim”. Jeżeli to nie Windows zarabia pieniądze w Redmond, to po co się starać? Nie warto ładować góry pieniędzy w rozwój nieużywanej (i nieużywalnej) przeglądarki. I nie warto szkolić armii programistów, by korzystali z fikuśnej infrastruktury UWP, skoro można zatrudnić programistów webowych? Będzie to łatwiejsze i tańsze. Krążą wręcz już o tym złośliwe żarty, że obecnie programiście Node’a rosną już na drzewach i prawdopodobnie lęgną się z brudu, w ciepłych i nieoświetlonych zakamarkach.

W systemie oczywiście „utkną” silniki rysujące zarówno IE, jak również Edge’a i będzie to stan utrzymujący się przez lata. Tym samym sposobem w Windows znajdują się dziś inne zamrożone truchła, jak MAPI albo Windows Media Player. W końcu jednak znikną (lub zostaną wywalone do opcjonalnych paczek zgodności) i zostaną zastąpione albo cudzym/otwartym projektem albo w ogóle niczym.

Ale w sumie to dobrze. Problemy z jakością oraz udziały rynkowe wyrażane w promilach to tak naprawdę mniejsza wtopa wizerunkowa, niż wciągnięcie kodu firm trzecich. Opory przed tym drugim są często ideologiczne. Stwierdzenie „wiecie co, z tą Dziesiątką to był głupi pomysł” wymaga nie tylko świadomości i samokrytyki, ale także odwagi. Tej jednak w kręgach menedżerskich nierzadko brakuje.

Gorzej, gdy proces integracji się nie powiedzie, a system celem zapewniania zgodności w dół pozostawi również stare komponenty i w efekcie urośnie jeszcze bardziej, a jakość spadnie dalej. Nie brzmi to jak nieprawdopodobny scenariusz. Może należy już tylko czekać, aż całość po prostu się zawali? Biorąc pod uwagę rozpaczliwy stan stosu serwisowego, w smutniejsze dni wygląda to już tylko na kwestię czasu.

Model „Windows jako usługa” to bowiem ponury żart. Zupełnie nowy biznes i zastosowanie wariacji na temat ciągłego dostarczania nie pociągnęły za sobą wystarczająco istotnej reformy zaplecza technicznego w postaci stosu serwisowego. Narzędzie DISM, zaprojektowane dla systemu Longhorn i kompletnie innych realiów, bardzo źle się skaluje. Z tego powodu proces aktualizacji wersji systemu jest taki ciężki i długotrwały. Zmiana wymagałaby solidnego nakładu pracy na przepakowanie obecnie dostarczanego kodu. To praca, jaką należało wykonać przed przejściem na ciągłe dostarczanie, które zresztą jest iluzją. Bardzo trudno jest cokolwiek dostarczać w sposób ciągły wykorzystując do tego mechanizm Windows Update. Owa systemowa usługa aktualizacji jest porażająco złożona i w zasadzie trudno powiedzieć dlaczego. Generuje ona kilometry logów, w postaci Zdarzeń Systemowych, binarnych wyciągów ETW i nawet plików tekstowych (!), ale nie wynika z nich klarownie, co aż tak skomplikowanego jest w procedurze wykrywania i instalowania aktualizacji.

Coś jednak musi być, ponieważ Windows Update jednocześnie urosło jako usługa i wyrzuciło wiele pozycji z listy obsługiwanego oprogramowania. Pakiety aktualizacji kumulatywnych SQL Server instalują się uruchamiając własne instalatory, bo Windows Update zapewne nie dałby sobie z nimi rady w akceptowalnym czasie. Microsoft Office 365 kompletnie wypisał się z tego biznesu i używa mechanizmu Click To Run. I tak dalej.

Istnieją przesłanki, acz nie dowody, że Sklep Windows miał w przyszłości pełnić rolę nowego mechanizmu serwisowania systemu. Dlatego aktualizacja Windows 8.1 była rozprowadzana przez Sklep, a nie przez Windows Update. Była to jednak różnica głównie optyczna, mająca wyrabiać nowe przyzwyczajenia – detekcja aktualizacji dalej zachodziła za pomocą Trusted Installera, a instalator systemu 8.1 wcale nie korzystał z mechanizmów Sklepu, a jedynie kazał mu uruchamiać swój instalator (Modern Setup Host). To doskonały temat do spekulacji, które piszą się tu zresztą same: czyżby Sklep był kolejną manifestacją wielu starć frakcyjnych, mających miejsce w Microsofcie? Być może Sklep miał być czymś więcej, niż tylko domem dla nowoczesnych aplikacji, może miał stanowić konkurencję dla Windows Update?

Nie dowiemy się tego. Tymczasem żadna kolejna aktualizacja Windows nie została już dostarczana w ten sposób. Depriorytetyzacja Sklepu to niewątpliwie odwrót od założeń promowanych wraz z Windows 8, ale kwestia dostarczania aktualizacji to bardzo trudne pole, nawet wyjąwszy hecę z instalowaniem nowych kompilacji systemu. Windows toczy tu niestety walkę, której nie ma prawa wygrać. Gładko działający Sklep i niewidzialne aktualizacje są niemożliwe do wdrożenia na tym systemie. Przeszkadzają w tym między innymi producenci sprzętu, niezdolni do poprawnego spakowania swoich sterowników. To przez nich w zasobniku systemowym ląduje łańcuszek ikon, przede wszystkim od Intela i NVidii. Dostarczają one własne aktualizatory, idąc zupełnie w poprzek wytycznym z Redmond. Ale cóż można zrobić? Odebrać certyfikat zgodności Intelowi, za to że wysyła w świat marne instalatory sterowników? I co wtedy?

Takie coś jak instalacja sterowników powinno dziać się samo, w tle, przez Windows Update. System macOS nie stroi sobie takich żartów z użytkownika i nie sabotuje sukcesu rynku PC, wprowadzając nieskończenie frustrujące badziewie techniczne.

A pamiętajmy, że poza samym systemem, pakietem Office i zbiorem sterowników, na komputerze znajduje się też cała reszta oprogramowania użytkowego. Nawet, jeżeli chodzi tylko o jakieś trzy aplikacje, to bardzo wysoka jest szansa, że każda z nich dostarczyła własny aktualizator. Jak przypomina Paul Thurrott w swoim niedawnym głośnym artykule „Keeping a Windows PC Up-to-Date is a Nightmare”, Microsoft wieki temu obiecał, że producenci oprogramowania będą mogli rejestrować swoje programy w usłudze Windows Update i dostarczać zintegrowane aktualizacje (w postaci pakietów MSP) z wykorzystaniem mechanizmów systemowych. Plan ten nigdy nie wypalił, więc dziś Firefox, Chrome, Adobe Reader, Spotify, Steam, Java, Slack, Discord, VLC, nuGet i tysiące innych programów rejestrują w systemie własne aktualizatory. Na szczęście coraz więcej z nich nie pracuje cały czas w tle i rejestruje aktywowaną zdarzeniem harmonogramu zadań usługę. Ale jeżeli uruchomi się ich jedenaście pod rząd, to nie jest kolorowo. Warto też wspomnieć o wielu programach niegdyś obecnych w Sklepie Microsoft lub wręcz bezpośrednio w systemie, które również wykorzystują własny mechanizm aktualizacji. Skype, Teams, i OneDrive to pierwsze, co przychodzi do głowy. Nie warto nawet zacząć wspominać o większych programach powstałych w czasach Windows 10, jak Visual Studio Code…

Jeżeli na tak wielu polach następuje odwrót od ambitnej i rozległej wizji nakreślonej podczas premiery Windows 8, a dzisiejsze coraz nowsze kompilacje „Dziesiątki” stopniowo demontują kolejne mechanizmy i odwołują dawne obietnice, jaka jest przyszłość? Internetowi szydercy wspominają nierzadko, że w takim tempie system niedługo zamieni się z powrotem w Windows 7. I że skończą się wtedy wszystkie dzisiejsze problemy. Ale to niemożliwe. Włożono bardzo wiele wysiłku w nowe rozwiązania i na pewno nie odejdą one na śmietnik historii. Aplikacja Ustawienia, przyszły zastępca Panelu Sterowania, mimo nieukończenia przez sześć lat jest już na tyle istotnym i dojrzałym komponentem, że znajduje się w systemie Windows Server jako element interfejsu. Mechanizmy serwisowania APPX i pakiety MSI, a więc w konsekwencji i Sklep Windows dostarczają znaczącą przewagę względem poprzedników w kwestii bezpieczeństwa i łatwości zarządzania/integrowania/wdrażania. A to, że są dziś wykorzystywane do dostarczania innych programów, niż „koszerne” aplikacje WinRT/UWP, to kwestia doktrynalna, ideologiczna.

Bardzo rzadko następuje moment, w którym cała góra pracy jest po prostu przekreślana i wyrzucana do kosza. Naturalnie, zdarzają się takie sytuacje. Czternaście lat temu taki los spotkał prototypową wersję Visty, porzuconą niemal w całości. Ale zazwyczaj buduje się na zastanej bazie, bo tak jest taniej.

Głośno wyrażana dezaprobata w tej kwestii wynika głównie z kwestii estetycznych. TWIN UI, druga twarz Windows, jest całkowicie odmienna od poprzedniej, ale musi taka być, bo problemów poprzednika nie da się tanio rozwiązać. Próba uczynienia atutu marketingowego z owej odmienności nie powiodła się, ale dwie twarze pozostały i rażą. Stąd tak częste opinie typu „po prostu wyrzućcie te nowe ustawienia i zostawcie tylko stary Panel Sterowania”. Tylko, że Windows 7 również miał dwa Panele Sterowania, migracji nigdy przecież nie ukończono, po prostu umieszczono wszystkie ikony, stare i nowy, w jednej kategorii. Migracja na skalowalne okna Metro/UWP jest znacznie bardziej drastyczna niż przejście na nowe Panele z Windows Visty/7. I jej niekompletność jest przez to bardziej widoczna.

Nie ma jednak odwrotu od Dziesiątki. Korekta kursu, opisywana jako porażka lub krok wstecz, to racjonalny krok biznesowy. Argumenty estetyczne zawsze jednak miały wysoką moc przekonywania, więc tak długo, jak istnieje Panel Sterowania, Kreatory Rozwiązywania Problemów i choć jedna ikona z Visty, Dziesiątka będzie uznawana za nieukończoną. Zwłaszcza, jeżeli wciąż w komplecie będziemy mogli znaleźć grę Candy Crush Saga.

Co będzie następnym krokiem w ewolucji systemu Windows? Czy system zachował swoją duszę po kolejnych wersjach po Windows 8? Dajcie nam znać w komentarzach!