Windows XP: dlaczego zostanie z nami już na zawsze? (część II)

Po pierwsze, Microsoft nie chciał skalować swojego "małego" systemu, Windows CE, w górę. Zamiast tego obrano strategię "wszystko i tak staje się oparte o x86". Oczekiwano że urządzenia staną się "smart" i będą stanowiły podstawę dla pełnoprawnych systemów operacyjnych. CE nadawało się na nawigatory i telefony. Zatem kolejny Windows Embedded miał być oparty o rdzeń zwykłego Windowsa.

Po drugie, rdzeniem tym miał być... Longhorn. Można podejrzewać, jakie wady miała ta strategia.

Co może niektórych zaskoczyć, Longhorn potrafił być naprawdę mały. Microsoft rozbił NT 6.0 na szereg niezależnych komponentów i całkowicie uniezależnił je od wersji językowych. Możliwe było stworzenie minimalnej wersji Windows jak z klocków, za pomocą środowiska Windows Component Studio. Mogła być mniejsza od Windows XP.

Oczywiście, nie udało się. Projekt ogłoszono w maju 2004, ale już w sierpniu Jim Allchin, architekt Windowsa (następca Dave'a Cutlera), ugiął się pod presją faktów: Longhorn był niemożliwy do ukończenia. Gigantyczny graf współzależności, spowalniający prace nad systemem niemal do zera i obniżający jego jakość, został tylko pogorszony przez komponentyzację. Mamy tu więc kwestię trzecią: Longhorn poszedł do kosza.

Jego następca - Longhorn Omega-13 - także był skomponentyzowany, jednak jedynie z myślą o przyszłości. Vista i następcy (w tym Windows 10 i 11) składają się z "pakietów" i możliwe jest ich dodawanie/usuwanie, ale w praktyce jest do mechanizm wyłącznie do dyspozycji Microsoftu. Stosuje się go procesie wewnętrznym, do wydawania nowych SKU i rozproszonych kompilacji. Użytkownik może użyć SDK żeby wyciąć składniki samodzielnie, ale tak pocięty system staje się całkowicie jego odpowiedzialnością: jego zaktualizowanie jest niemożliwe, trzeba go składać od nowa - a nieznana liczba komponentów może przestać działać "bez powodu", w rezultacie takich zabiegów.

Zatem Vista była możliwa do składania z klocków, ale wyłącznie teoretycznie. Nawet Microsoft nie zastosował niniejszego mechanizmu do stworzenia oddzielnego "wbudowanego" SKU Visty. Środowisko po prostu nie było na to gotowe. Istniał co prawda produkt o nazwie "Windows Vista Embedded", ale była to nazwa niezwykle myląca. Była to bowiem zwykła, inaczej licencjonowana Vista Business. Czyli wg. dawnego nazewnictwa, powinna zostać nazwana "Windows Vista Business for Embedded Systems". Przebojowo.

Pięć lat od premiery XP, Microsoft nie miał więc żadnej platformy większej od CE, ale mniejszej od Visty. Stworzenie kolejnej, oddzielnej wersji Windows tylko do tego celu nie wchodziło w grę. Backlog problemów z Vistą był za długi, system nie nadawał się nawet na wariant serwerowy, a co dopiero mniejszy, wbudowany. Na Windows Server 2008 (czyli Service Pack 1 do Visty) przyszło poczekać nieco ponad rok od premiery, na przełom lutego i marca 2008. Dopiero na bazie tego systemu możnaby tworzyć wersję Embedded... ale Vista sprzedawała się źle i powstała presja na następcę.

Jako, że postanowiono o braku opóźnień celem usunięcia niesmaku po pięciu latach rozwoju Visty, jej następca miał być wydany pod koniec 2009. Aby nie dublować pracy, zapadła decyzja że nowy Embedded będzie oparty nie o Vistę, a o jej następcę. Co jednak zrobić z ponadpółtoraroczną przerwą? Licencjonowanie OEM dla Windows XP wygasało 30 czerwca 2008. Windows CE był za mały. Vista za duża. Następca był wczesną alfą. Czy producenci mieli zacząć stawiać np. tomografy na Xboksach?

Nie było innej drogi, jak tylko wydać Windows XP jeszcze raz. W ten sposób powstało jedno z większych dziwadeł w ofercie Microsoftu: Windows Embedded POSReady 2009. Jest to okrojony z niektórych komponentów, ale wzbogacony o składniki dla punktów sprzedaży Windows XP. Wygląda schizofrenicznie: ma branding rodem z Visty, o ile nie zajrzymy głębiej niż na tapetę pulpitu. Ma nowy temat graficzny, nieobecny nigdzie wcześniej ani później. Stosuje unikatowy instalator, oparty o (niekompatybilny!) plik WIM.

To właśnie Windows Embedded POSReady 2009 był źródłem słynnego triku "POSReady\Installed=dword:00000001", dzięki któremu możliwe było otrzymywanie aktualizacji w zwykłym Windows XP aż do kwietnia 2019 roku. Było to naruszeniem licencji, ale Microsoft nie przejmował się tym za bardzo. W Redmond wolano najwyraźniej, żeby ludzie stosowali "nielegalny" system, ale za to z aktualizacjami chroniącymi przed coraz popularniejszym ransomware.

POSReady 2009 miał inne wymagania sprzętowe, niż czysty XP. W rezultacie, aktualizacje do niego psuły XP zainstalowany na bardzo starych komputerach z Pentium III i starszymi, ze względu na brak SSE2. Wynikało to oczywiście z tego, że niemożliwe było otrzymanie licencji na POSReady dla sprzętu opartego o taki układ. Licencje otrzymywały tylko nowe urządzenia.

Premiera następcy Visty, Windows 7... dalej nie poskutkowała nową wersją Windows Embedded. Siódemkę dało się już bezboleśnie rozbijać na komponenty, ale nie przygotowano takiej wersji na czas. O wiele ważniejsze było wypchnąć coś dla klientów indywidualnych, bowiem niezdolność Redmond do dotrzymywania terminów miałaby konsekwencje giełdowe. Na wersję Embedded przyszło poczekać jeszcze rok, aż do sierpnia 2010. Dopiero wtedy, niemal 9 lat od wydania Windows XP, urządzenia wbudowane otrzymały następcę.

Dalej nie zatrzymało to hegemonii Windows XP. O powodach tego stanu rzeczy już jutro.