Budowa Windows NT: mechanizmy zgodności, które działają do dziś

Popularność Windowsa nie bierze się z tego, że jest fantastycznym systemem operacyjnym. Wszak nim nie jest: Windows 11 stał się ciężki, połatany i niemożliwy do renowacji na niższych poziomach. Jego wszechobecność to efekt utrzymywania kompatybilności oraz inercji producentów sprzętu, piszących sterowniki. Gdyby nie detal o nazwie "oprogramowanie", Windowsa dawno zastąpiono by którymś z wielu konkurentów. Ale argumenty przytaczające pakiet Microsoft Office i Photoshopa wciąż są aktualne.

W jaki sposób Windows zapewnia zgodność? Przede wszystkim bardzo powoli rozstając się ze starymi bibliotekami. Obsługę aplikacji 16-bitowych utracił dopiero w 2021 roku. Zlikwidował Internet Explorera jedynie poprzez usunięcie najbardziej wierzchniej warstwy: MSHTML, HTA, VBS i BHO dalej są obecne w systemie. A wprowadzając nowe wersje bibliotek, dalej trzyma te stare: stosując mechanizm SXS i tryby zgodności, oferuje starszym aplikacjom stosowne wersje plików DLL. Sprawia to, że programy nie korzystają bezpośrednio z plików z katalogu SYSTEM32. Każde żądanie jest najpierw przechwytywane przez mechanizm zgodności (shim), który wybiera odpowiednią dla aplikacji wersję. To spory narzut i znaczący wzrost złożoności. Ale opłaca się.

To bardzo duża inwestycja w kompatybilność. Mechanizm zgodności jest olbrzymi i wciąż rozbudowywany. Jednym z etapów zbierania telemetrii w Windows (CompatTelRunner) jest aktualizowanie i raportowanie lokalnej bazy zgodności, zawierającej informacje o tym, które zainstalowane programy żądały których bibliotek. Katalog WinSxS zawiera tysiące katalogów. A gdy jakieś API pojawia się w systemie, bardzo rzadko go opuszcza. Dlatego możemy znaleźć w Windowsie silniki rysujące Trident (Internet Explorer) i EdgeHTML, Visual Basic, mechanizm Outlook MAPI, obsługę WinRT (Metro, znane z Windows 8), .NET Framework 2.0, DirectPlay, usługę faksowania i SMB 1.0. Pliki te nie pojawiają się w starych wersjach: są regularnie przebudowywane. Stanowią integralną część systemu i są powodem, dla którego zdekompresowane źródło instalacyjne Windows zajmuje dziś 16 gigabajtów.

Choć systemowa biblioteka języka C jest uznawana za wewnętrzną tylko na potrzeby systemu, jej struktura zachowuje wysoką zgodność na przestrzeni lat. Visual Studio nalega, by kompilować do dedykowanego MSVCRT, które następnie powinno być rozpowszechniane razem z aplikacją (co uległo znacznemu uproszczeniu w ostatnich latach), ale nawet to przebiega w bezproblemowy sposób. Biblioteki .NET Framework także są obecne w Windows, a gdy jakaś antyczna aplikacja (sprzed 2010) zażąda wersji 2.0 CLR, Windows Update pobierze starszą. Nowy .NET oferuje już możliwość bundlowania środowiska uruchomieniowego w formie redystrybucyjnej aplikacji. Zapewnia to prawdopodobnie zgodność z Windowsem na kolejne lata.

Coś takiego jest nieobecne u konkurentów. Android 14 usuwa kompatybilność z aplikacjami dla Androidów starszych niż 6.0 (zmiana ta ma więcej wspólnego z zabezpieczeniami niż z ABI, ale liczy się efekt). W macOS, niepodpisane i 32-bitowe aplikacje w ogóle nie działają, a najpopularniejsze programy zapewniają zgodność z tylko kilkoma wersjami wstecz. Linux z kolei w ogóle mało się przejmuje tą kwestią. Wszystko zależy od liczby zależności. Z powodzeniem możemy trafić na dwudziestoletnią aplikację, która zadziała od razu. Albo na trzydziestoletnią, która będzie wymagać tylko przebudowania. Zdarzą się aplikacje, w których nie będzie szans na uruchomienie np. dźwięku. Ale możemy też napotkać na problemy z tylko kilkuletnim programem, ze względu na zmiany w GTK lub biblioteki niezbudowane dla nowszej wersji.

Twórcy NT marzyli, że system ten będzie umiał "udawać" Uniksa i Windowsa na równych prawach - za pomocą podsystemu "osobowości" i implementując referencyjnie "userland" POSIX i Win32, NT miało zapewniać "wieczystą" zgodność. Aktualizacje miały polegać na dodawaniu nowej osobowości. Zgodność tę usunięto już dawno temu. Dzisiejszy WSL nią na przykład nie jest. Zwyciężyło bezsprzecznie Win32. Ale samo w sobie, środowisko programowania Windows nie jest cudem techniki.

Na rynku IT dźwigają je głównie decyzje biznesowe, w postaci olbrzymiej liczby mechanizmów zgodności. Teoretycznie, mogłyby one być osadzone na dowolnym systemie - ale to tylko teoria. Nie zanosi się na przeniesienie Windows API na żaden inny system. Dopóki fundamenty NT nie zawalą się pod ciężarem dodatków, trzydziestoletnia zgodność będzie w Redmond zarabiać pieniądze.