Kiedy "umarł" ostatni klasyczny Windows?

Nadchodzący koniec wsparcia Windows 8.1 oznacza zakończenie obsługi ostatniego wydania Okienek nieoferowanego w trybie ciągłym. Ósemka otrzymywała wszak upgrade tylko dwukrotnie: raz do 8.1 i raz (na rok) do Windows 10. Dziesiątkę możemy z kolei aktualizować "w nieskończoność".

Nowy model bywa (nieprawidłowo) nazywany "subskrypcyjnym" i przedstawiany jako przeciwieństwo poprzedniego, potocznie (i także nieprawidłowo) nazywanego "klasycznym". Choć to ta pierwsza nazwa jest bardziej rażąca ze względu na swoją nieadekwatność, określenie "klasyczny Windows" ma dłuższą i ciekawszą historię. Dotyczy ono bowiem, w swym poprawnym znaczeniu, oprogramowania wydanego ostatni raz w 2000 roku.

Klasyczny Windows wywodzi się z 16-bitowego środowiska operacyjnego, startującego z poziomu MS-DOS. Często opisywano je jako "oparte o MS-DOS", ale nie jest to do końca poprawna charakterystyka. Windows przeładowywał tak wiele elementów DOS-a, że system ten z wersji na wersję pełnił coraz mniejszą rolę.

Czym był klasyczny Windows? Początkowo - istotnie 16-bitową aplikacją MS-DOS. Dostarczała ona graficzne środowisko użytkownika, ułatwiony model sterowników graficznych oraz podstawowe API do rysowania i komunikacji, ujęte w trzech głównych komponentach: GDI, USER i KERNEL. Koncepcja GDI, ulegając od 1985 roku istotnym przemianom, pozostaje jednym z fundamentów dzisiejszych Windowsów.

Kolejne wersje wzbogaciły się o jądro pracujące w trybie chronionym i samodzielne zarządzanie pamięcią. W końcu, rzecz jasna, pojawiła się także obsługa 32-bitowego kodu (Win32 API). To wszystko osiągnięto na bazie niezwykle rozbudowanej aplikacji DOS-owej, odbierającej DOS-owi niemało jego własnych, systemowych zadań.

Klasyczny Windows rozmywał definicję systemu operacyjnego: teoretycznie to DOS inicjalizował WIN.COM, ale Windows sam dźwigał pamięć, sterowniki i zadania. Z perspektywy DOS-a, Windows nie był "systemem", a gigantycznym procesem: menedżerem maszyn wirtualnych (narzędziem umożliwiającym uruchamianie wielu programów DOS naraz) oraz graficznym środowiskiem operacyjnym (oferującym funkcjonalności GDI i USER).

Takie rozwiązanie uznano jednak za ślepą uliczkę i porzucono. Obecny Windows to żaden Windows: to system NT, zaopatrzony na wierzchu w to samo API, które oferowały klasyczne okna, zaimplementowane "na nowo" jako czysto 32-bitowy kod. Ponieważ samo to, że jakieś rozwiązanie jest gigantycznym hackiem nie jest jeszcze powodem, by je porzucać (NT jest zbieraniną hacków) - musiał być jakiś inny powód. Co nim było?

Otóż Windows po prostu nie był w stanie udźwignąć więcej. Genialne rozwiązania przedłużające żywot MS-DOS miały górną granicę rozwoju. Klasyczny Windows nie byłby w stanie obsłużyć więcej niż 4GB pamięci, wielordzeniowych procesorów, Hyper Threadingu i systemów 64-bitowych. Przez "nie byłby w stanie" rozumiemy tu konieczność napisania tak rozbudowanych sterowników VXD, że zakrawałoby to na stworzenie nowego systemu. Dość zbędne ćwiczenie, gdy inny system już istniał i było nim NT.

Ale to nie wszystko. Dziedzictwo MS-DOS sprawiało, że Windows domyślnie stosował strony kodowe (kodowanie jednobajtowe!) zamiast Unicode. Mocno utrudniało to regionalizację, a zmiana tego stanu rzeczy wymagałaby przekompilowania całego systemu, od VMM w górę. Ze względu na zgodność z kodem 16-bitowym, mechanizmy GDI i USER nie mogły zostać przy okazji przeprojektowane tak, by nie ulegać destabilizacji wskutek wyczerpania zasobów (nie RAM-u! mowa o wolnych uchwytach wewnątrz GDI). Ciężkie programy potrafiły zawiesić system, a bardziej rozbudowane UI, np. w .NET, to już w ogóle było proszenie się o kłopoty.

A kłopoty oznaczały zazwyczaj niebieski ekran i restart: Windows miał udawane procesy, one wszystkie były tylko formami zmiany stanu VMM32.VXD. To właśnie on był "procesem". Jedynym. Cała reszta to fikołki i coś co w większości (PID, entry point…) można traktować jak proces… ale nie całkowicie. Dlatego menedżer zadań z Windows nazwano menedżerem zadań, a nie procesów. Nazwę tę przeniesiono do dzisiejszych Windowsów, choć NT operuje na prawdziwych procesach.

Problem stanowiłyby nie tylko kwestie platformowe, jak HT i wiele rdzeni. Nowy sprzęt stawiał wymagania dotyczące sterowników, którym DOS i VXD nie mogłyby sprostać. Obsługę USB, IEEE 1394 i nowych klas "nowoczesnych" urządzeń dodano do Windows 95 nie poprzez rozszerzenie modelu sterownika, a poprzez… dodanie fragmentu jądra NT do systemu. Narzędzie "Mini NT Executive", dostarczane w postaci sterownika NTKERN.VXD, dodawało obsługę sterowników WDM przeznaczonych dla Windows 2000.

Oznacza to, że już w 1996 roku uznano, że jedyną drogą na rozwój klasycznego Windowsa jest dodawanie do niego fragmentów NT. System aż prosił się o znaczne rozszerzenie NTKERN (i usunięcie warstwy 16-bitowej), ale wtedy utraciłby jedną z głównych cech zarabiających pieniądze: kompatybilność - cenną nawet w ramach niestabilnego systemu.

Jakie wnioski możemy wyciągnąć z historii systemu, którego w pewnym momencie nie dało się rozwijać? Należałoby zapytać na przykład, czy i kiedy znajdziemy się w takiej sytuacji ponownie. Czy NT też ma swój kres, uniemożliwiający dodanie technologii przyszłości? Póki co taka się nie pojawiła. Dzisiejsze komputery, z ustrojem UEFI, dyskami półprzewodnikowymi i magistralami Thunderbolt, są zupełnie innym sprzętem niż ten stosowany w pecetach 30 lat temu. A NT dalej sobie z nim radzi.

Nie wydaje się, że przed dzisiejszym Windowsem stanie wkrótce wyzwanie, któremu nie będzie on w stanie sprostać. Prędzej z rynkowego krajobrazu znikną same pecety, niż z pecetów - Windows. Lecz i na to się nie zapowiada. Prawdopodobnie w kwestii systemów operacyjnych dotarliśmy do końca historii.

Swoją drogą, Apple przeszedł tę samą drogę. Ich obecny system będzie niósł Maki jeszcze przez wiele lat, a jego poprzednik został pogrzebany na przełomie wieków, z powodów zbliżonych do motywu uśmiercenia technologii Windows 95.

Kamil Dudek, współpracownik dobreprogramy.pl