Gdy Windows był Uniksem, czyli dlaczego bash w Windows 10 to żadna nowość

Kilka tygodni temu gruchnęła wiadomość, że nadchodzące kompilacje Windows 10 będą zawierały między innymi linuksową powłokę bash, wraz ze zbiorem innych narzędzi, jak coreutils, czy też w ogóle oprogramowanie systemowe GNU. Miało to być pokłosie zabitego Projektu Astoria, a odpowiednie moduły – rzekomo dostępne przez sklep Windows Store jako dystrybucja oprogramowania Canonical. Wiele serwisów informacyjnych oraz innych „entuzjastów”, zwyczajowo niemających pojęcia, o czym piszą, rozpływało się z radości nad niesamowitym postępem, jakim najwyraźniej jest dołączenie basha do Windows. Byłem nieco zniesmaczony aferą, jaka wyrosła wokół tej błahej wiadomości, bowiem nie trzeba wiele intuicji, by domyślić się, że przydatność tego rozwiązania jest/będzie porównywalna z .NET Core i obsługą ASP.Net w Linuksie. No niby istnieje, ale jakoś nikt normalny nie postawiłby na tym produkcyjnego serwera (zapewne w komentarzach dostanę jakieś linki do całych serwisów, które jednak stoją na tym rozwiązaniu, ale teraz będę udawał, że na pewno ich nie ma, nie popierając tego żadnym researchem, a jedynie intuicją). Skorzystają zapewne tylko niektórzy programiści. Zaproponowane w Windows 10 rozwiązanie jawi się obecnie jako wirtualizacja dla ubogich, obarczona jarzmem idiotycznych, dawno rozwiązanych problemów. Nie jest to jednak wirtualizacja. Bardziej wygląda na kolejne „zróbmy to od nowa!”. Doskonale świadczy to o logice podziału pracy w nowym Microsofcie. Jest szwadron ludzi od wlewania Linuksa w Dziesiątkę, ale brakuje kogokolwiek, kto dokończyłby np. nowy Panel Sterowania, rozgrzebany od 2012 roku. Ale to nie partanina była źródłem mojej głębokiej dezaprobaty wobec projektu z bashem w Windows. Do partaniny bowiem przyzwyczaiło mnie już ostatnie pięć lat. Do całej sprawy zniechęcił mnie fakt, że bash w Windows to tak naprawdę „old news” – obsługa podsystemu POSIX w Windows NT istniała już w 1994. Żeby zrozumieć, o czym mowa, musimy nieco przyjrzeć się architekturze NT.

World's most advanced Operating System

W tym celu trzeba jednak przełknąć pewną gorzką prawdę, jakże sprzeczną z powszechną opinią na temat Okienek. Otóż: Windows NT to najlepiej zaprojektowany system operacyjny na świecie, a Dave Cutler jest geniuszem. Zapewne mi Państwo nie uwierzycie. Istnieje na to jednak szereg dowodów, więc wyruszmy na chwilę do roku 1988. To był bardzo ciekawy rok! Na rynku istniał już procesor 386, ale nie było na niego tak naprawdę systemu operacyjnego. Oprogramowanie rozwijało się znacząco wolniej, niż sprzęt. Co ciekawe, od czasu do czasu zdarzały się przełomy, jak wielozadaniowy MS‑DOS 4, ale nikt go nie chciał (!). Stagnację w krainie MS‑DOS chciał przełamać IBM, pełniący w tamtych czasach rolę lidera rynku PC (której to wkrótce miał się samodzielnie pozbawić). Forsowano plan znaczącej modernizacji systemu MS‑DOS, z uwzględnieniem takich elementów, jak wielozadaniowość i tryb chroniony. Pierwsze próby owej modernizacji pochodzą jeszcze z roku 1984 i zdradzają, że do ostatniej chwili nie było porozumienia w kwestii.. nazwy nowego systemu. W końcu zdecydowano się na zbrodniczo banalną nazwę OS/2.

Advanced DOS

Nowy system był tworzony wspólnymi siłami przez Microsoft i IBM. Odświeżony, „zaawansowany” DOS, poza oferowaniem pokracznej, acz sprawnej zgodności API z MS‑DOS, rozszerzał funkcjonalność PC o elementy, których brak zaczynał być powoli coraz bardziej wstydliwy. Niestety, popełniono olbrzymi błąd, jakim było oparcie OS/2 o procesor 286, a więc układ bez zdobyczy technicznych oferowanych przez 386, jak np. rejestry 32‑bitowe. Jest to błąd, ale tylko z naszej perspektywy. Łatwo dziś powiedzieć, że decyzja o wykorzystaniu 286 była „straszna” i jej efekty druzgocące dla całego projektu, ale musimy pamiętać, że były to lata osiemdziesiąte. Od ogłoszenia nowego układu, do jego pojawienia się w obudowach pecetów mijało więcej czasu, niż dziś. I o ile OS/2 był tworzony jako lek na makabryczny prymitywizm MS‑DOS, to nie był jedynie projektem teoretycznym, którego rolą miałoby być „chwalenie się” założeniami projektowymi. Ktoś owego systemu musiał używać. A większość użytkowników miała układ 286. Oczywiście, można było „poczekać”. Ale to dawało czas konkurencji na wyrównanie strat (a Commodore i Apple, już co prawda na ostatni dzwonek, ale dalej miały szansę zmieść PC), jednocześnie dając pecetowemu obozowi system operacyjny widzący jedynie 640 kilobajtów pamięci, w którym redirector sieciowy był oszałamiającym osiągnięciem, podobnie, jak obsługa dysków 32MB. Przeczekanie jeszcze kilku lat i oparcie OS/2 od razu o 386 było zbyt ryzykowne.

Rzecz jasna, wybranie 286 było z kolei ślepą uliczką. Napisany w języku symbolicznym ASM, OS/2 musiał być gruntownie przepisany, by pracować z układem 386. Wersja 2.0 dalej nie była kodem przyszłościowym, zadecydowano więc, że Microsoft rozpocznie prace nad wersją trzecią systemu OS/2, którego cechami miała być łatwa przenośność – aby uniknąć problemu z kompletnym przemeblowaniem wszystkiego przy każdej zmianie architektury. Takie podejście do tworzenia OS/2, z dzisiejszego punktu widzenia naturalne, miało nosić nazwę Nowej Technologii (NT). W celu poprowadzenia owego ambitnego projektu, wynajęto Dave’a Cutlera, autora nowatorskiego systemu VMS. Microsoft był zdecydowanym zwolennikiem owego podejścia: ich produkt, Windows 2.0, zbierał nędzne recenzje i nie został szczególnie ciepło przyjęty przez rynek. Krążą wieści, że pełnił on nierzadko rolę środowiska „runtime”, do uruchamiania graficznych wersji elementów pakietu Office.

Protected Windows

W międzyczasie, ktoś inny w Microsofcie miał przebłysk geniuszu, w momencie najbardziej niewłaściwym i nieoczekiwanym, w świetle planów i podjętych decyzji. Byli to David Weise i Aaron Reynolds. Można dziś bez wahania powiedzieć, że bez nich świat IT wyglądałby dramatycznie inaczej – byli to ludzie, którzy na potężną skalę zmienili świat, czyniąc to wyłącznie ciężką pracą własnych rąk i umysłów. A dziś nikt o nich nie słyszy. Zapytajcie swojego lokalnego entuzjastę komputerowego, czy wie, kim był Aaron Reynolds. Albo inaczej: znajdźcie kogokolwiek, kto choć słyszał to nazwisko. Tymczasem wspomniani panowie pracowali w drugorzędnym dziale w Microsofcie, jakim był dział obsługi środowiska Windows. Okienka obrywały od programistów za to, że wewnętrzne struktury danych środowiska zajmowały tak wiele pamięci, że zaczynało jej brakować na programy użytkowe. Innymi słowy, należało wywalić jak najwięcej rzeczy do pamięci rozszerzonej albo do górnego obszaru pamięci (zarządzanie pamięcią w MS‑DOS było kosmicznie skomplikowane ). DOS5 radził sobie z tym wykorzystując takie triki, jak DOS=HIGH,UMB oraz dyrektywy LOADHIGH i DEVICEHIGH, dziś na całe szczęście zapomniane. Windows był jednak jeszcze za głupi na takie sztuczki, a na DOS5 przyszło jeszcze trochę poczekać, zwłaszcza, że miał nigdy nie powstać, bo przecież całość miał zgarnąć OS/2. A więc by móc nieco odchudzić Windowsy, by lepiej nadawały się na środowisko runtime, powstał plan wrzucenia sterowników do HMA. Dlaczego tylko sterowników? Ano dlatego, że aplikacje dla Windows były w pełnej krasie programami zaprojektowanymi dla trybu rzeczywistego. Ich przeniesienie do obszaru chronionego zostało uznane za zwyczajnie niemożliwe i wymagające nakładu pracy porównywalnego z napisaniem ich od zera. Tym przecież zajmowali się koledzy z zespołu OS/2. Niestety, Wesie i Reynolds byli geniuszami. Nie tylko przenieśli sterowniki wyświetlania do trybu chronionego, ale i stworzyli potwora o nazwie PKERNEL.EXE. A więc jądro środowiska Windows oferujące tryb chroniony. Jakby tego było mało, w tym trybie było możliwe uruchomienie dotychczasowych aplikacji Windows. Bez żadnych modyfikacji!

To była katastrofa. Dwóch panów z Budynku 3 właśnie zlikwidowało problem, dla którego powstawał cały nowy, oddzielny system operacyjny. W dodatku zachowując pełną zgodność ze wszystkimi dotychczasowymi programami dla MS‑DOS i Windows, a jakby tego było mało – umożliwiając uruchomienie kilku aplikacji MS‑DOS jednocześnie. OS/2 nie potrafił tego zrobić. Był daleko w tyle. Dlatego zadecydowano, że OS/2 w wersji 3.0 musi być naprawdę hitem. Na szczęście, panowie w innym budynku szykowali właśnie bombę.

The Showstopper

Dave Cutler, korzystając ze swojego doświadczenia w firmie DEC, opracował system operacyjny napisany, w przeciwieństwie do MS‑DOS i OS/2, w języku C. A więc języku powstałym właśnie do pisania systemów operacyjnych. Oparcie systemu ów język dało znacznie większą niezależność od sprzętu, niż DOS. Twórcy Uniksa wiedzieli, co robią, wymyślając ów język, więc język C był idealny do tego właśnie zastosowania. Ale NT miał być czymś o wiele większym, niż Unix. Cutler widział szamotaninę z MS‑DOS, OS/2 i dziwnie wierzgające z boku Windowsy, więc zadecydował, że domyślnym API dla OS/2 3.0… nie będzie żadne z owych środowisk. Wbudowane API dla natywnych aplikacji miało zostać nieudokumentowane, i następnie ukryte, a służyć miało wyłącznie do opracowania najbardziej niskopoziomowych aplikacji (jak Check Disk) oraz tzw. osobowości. Ponieważ Microsoft i IBM nie potrafili się zdecydować, jak naprawdę ma wyglądać ten ich system przyszłości, nowy OS/2 miał oferować API dla wszystkich aplikacji. Program dla MS‑DOS miał dostać osobowość dla DOSa, program dla OS/2 dostawał osobowość klasycznego OS/2, a Okienka – swoją. Wszelkie różnice między owymi, nierzadko dramatycznie odmiennymi, platformami, miały być rozwiązywane między osobowościami, a jądrem, i uruchomione programy miały o tym nic nie wiedzieć. Pracowały sobie dalej, czując się jak u siebie w domu, umiejąc w dodatku wymieniać ze sobą dane. Cutler nie lubił Uniksa, był zrażony do jego czytania bajt po bajcie, trzymania gigantycznych deskryptorów i uchwytów w jednym int’cie oraz definiowania zegara w zmiennej typu long. Pogoń za odczytywaniem bajtu była przez niego wyszydzana. NT zachowywał się znacznie inaczej. Ale dla tych, co potrzebowali, potrafił udawać też Uniksa. Miał do tego kolejną osobowość, równoprawną z pozostałymi.

Windows 3.0

Jednocześnie, Windows przeniesiony z trybu chronionego, został wydany jako oddzielny produkt. IBM otworzył szeroko oczy, pytając po co na świat przychodzi kolejna wersja Windows, skoro przyszłością ma być OS/2. Rozumiano jednak, że zawsze chodzi przede wszystkim o pieniądze. Niewiele wcześniej przecież sami wywinęli numer z forsowaniem obsługi 286. Z nieco większą niechęcią przyjęto wiadomość, że Windows 3.0 osiąga popularność o wiele wyższą, niż opracowywany w pocie czoła OS/2. Microsoft jednak cieszył się z tego faktu. Podjęto więc decyzję, że API Windows zostanie unowocześnione i przeniesione do 32 bitów, a następnie dodane jako kolejna osobowość NT OS/2 3.0, by nie tylko obsługiwać aplikacje OS/2 na solidnej platformie, ale i dostarczyć na rynek coś nowego. Genialnie zaprojektowany system, który obsługuje jedynie API z przeszłości to zmiana, którą trudno będzie sprzedać. Dlatego nowe API, nazwane Win32, musiało zaoferować coś wartego uwagi. Jednocześnie będąc naturalnym rozwinięciem dotychczasowego API Okienek, zapowiadało się obiecująco. OS/2 w wersji NT urastał więc do rangi produktu bardzo innowacyjnego. Nadszedł czas na spotkanie z IBM.

Podjęto wtedy kolejną genialną decyzję. NT okazał się bowiem znacznie lepszym OS/2, niż dotychczasowy, ale dzięki innowacyjnemu projektowi w wykonaniu Cutlera, był też o wiele lepszym Windowsem. Dlatego też Microsoft powiedział IBMowi „dość ” i zmienił nazwę swojego NT OS/2 3.0 na… Windows NT. Ostatecznie zrozumiano, że OS/2 nie ma przyszłości: „ostateczne” rozwiązania wielkich problemów, zastosowane w owym systemie prędko okazały się podatne na ząb czasu. IBM przez długie lata nie potrafił się z tym pogodzić. I trzeba im przyznać, że nie próżnowali: rozmach prac nad OS/2 wcale nie wskazywał na to, że ów system jest nadmiernie skomplikowaną ślepą uliczką. Przez długi czas utrzymywała się opinia, że dalej ma on szansę. Polecam zresztą doskonałe nagranie konferencji promocyjnej obu systemów. OS/2 jest na niej reklamowany z entuzjazmem start-upu, który towarzyszył wczesnym latom w Microsofcie, nie kojarząc się zupełnie z wizerunkiem poważnego IBM. Tymczasem wysłannik Microsoftu przybył w garniturze, prowadząc bezemocjonalną prezentację produktu, którego nie było jeszcze nawet na rynku. Wydawało się wręcz, że obie firmy zamieniły się miejscami…

Niestety, to nie wystarczyło. Microsoft miał wkrótce zaprezentować system, który był najlepszym Windowsem i OS/2 jednocześnie, w dodatku będąc również Uniksem. Tak jest. Trzecią osobowością w NT miał być bowiem POSIX. I nie był to podsystem „na kształt” POSIX-a, ani implementacja w stylu Microsoftu i polityki Embrace-Extend-Extinguish, jak z LDAP w Active Directory (by nie wspominać o wielu innych przykładach). Faktem jest, że ów podsystem nie był potęgą o wszechstronnym zastosowaniu i implementował jedynie kilka najważniejszych „rozdziałów” ze specyfikacji POSIX. O wiele pełniejszym Uniksem od Microsoftu był inny produkt, spisany już wtedy na straty – Xenix. Microsoft bowiem dorobił się swojej fortuny sprzedając między innymi pakiety biurowe na Macintosha i systemy uniksowe dla pecetów. W przeciwieństwie do OS/2, który załączał zgodność z MS‑DOS, bo w przeciwnym wypadku nikt by go nie używał, NT oferował zgodność z POSIX.1 ze znacznie bardziej mrocznych powodów. Microsoft miał ambicję, by system przeszedł certyfikację bezpieczeństwa i funkcjonalności, aby dało się go używać do celów militarnych (swoją drogą efekt był fantastyczny i skończył się między innymi paraliżem łodzi podwodnej amerykańskiej marynarki wojennej). Niemniej, NT obsługiwał API uniksowe. Shell? Proszę bardzo. Grep? Ależ służę uprzejmie. A to wszystko na prawach aplikacji OS/2, Menedżera Programów, czy Worda. Chwała Cutlerowi! Właśnie z tego powodu wieść o bashu w Windows 10 mnie tak zdenerwowała. Obecnie to rozpaczliwa próba powrotu do oryginalnego projektu NT, w którym aplikacje wielu systemów operowały na płaskiej przestrzeni, na równych prawach między sobą. To, co pokazano niedawno, to jakaś żałosna proteza, w porównaniu z tym, co osiągnięto już 20 lat temu. Powstaje zatem pytanie, dlaczego nie powrócić do owego dawnego projektu i ponownie nie zintegrować basha, oraz najlepiej całego GNU z Windowsem, na równi z całym Win32? Czyż to nie byłoby genialne? Istnieje szereg powodów, dla których nie da się tego zrobić i nie wyłożę ich bez popadania w nadmierne uproszczenia, ale możemy odważyć się na stwierdzenie, że wspomniany wariant jest niemożliwy, ponieważ Microsoft musiał się zachować jak Microsoft. Oznacza to, że oryginalny projekt NT trzeba było popsuć. Zanim jednak zacznę marudzić na minimalizm podsystemu POSIX w NT, pomarudzę na coś innego.

W pogodni za wolną pamięcią

Skoro NT był taki genialny, to dlaczego równolegle z nim sprzedawano Windows 3.11? Dlaczego do zlikwidowania Windowsów związanych z MS‑DOS musieliśmy czekać aż do roku 2001 i premiery Windows XP? Odpowiedź jest prosta. NT był strasznie ciężki. A tymczasem popularyzacja komputerów PC w domach następowała zazwyczaj wskutek rozpowszechniania sprzętu o wątpliwej mocy. Proszę odkopać swojego Optimusa z lat 90tych. W środku odnajdziemy kiepskie płyty główne no‑name z brakującymi kondensatorami, na gnących się w rękach PCB, wybrakowany cache, chipsety produkowane przez firmy o nieznanych nazwach oraz jakieś oszałamiające ilości pamięci, rzędu 8MB. Sytuacja wyglądała tak nie tylko w Polsce (wbrew pozorom). Tymczasem klasyczny Windows był znacznie mniej łakomy na zasoby. Co więcej, przy pokaźniejszej ilości RAMu działał wręcz gorzej, co pod koniec lat dziewięćdziesiątych owocowało awariami systemu na mocniejszych konfiguracjach. Zaszła potrzeba odchudzenia NT. I tak, jak OS/2 który celem działania na słabszych maszynach stał się potworkiem dla procesora 286, odchudzony Windows NT był efektem bolesnych poświęceń.

Popsujmy podsystem graficzny

Jednym z powodów, dla którego pierwsza (no, może druga: 3.5) wersja NT była tak stabilna, było usunięcie podsystemu graficznego z poziomu jądra. O ile w przypadku klasycznych okienek, wyrzucenie USER i GDI gdziekolwiek indziej było niemożliwe z poziomów dość fundamentalnych, projekt NT był wręcz stworzony dla takiego podejścia. Dzięki temu, gdy stos graficzny się wywalił, system stał dalej i, w przypadku poprawnej obsługi błędów, potrafił przywrócić sesję graficzną na nowo. A jeżeli nie, to korzystając z odpowiednich narzędzi, możliwa była praca na NT w trybie tekstowym. Niestety, oddalało to tryb graficzny od sprzętu, negatywnie wpływając na wydajność. Stąd też w wersji 4.0 zintegrowano tryb graficzny z trybem jądra, co znacząco zdestabilizowało cały produkt. To karygodne z dzieisjszego punktu widzenia podejście miało jednak sens. Sens biznesowy, ale nie techniczny. Niestety, jak już wiemy, rynkiem IT częściej rządzi biznes, niż technika. Pęd do zajęcia rynku mniej wydajnych komputerów jest więc zupełnie uzasadniony. Warto wspomnieć, że obecny mieszany system wyświetlania jest o wiele bardziej niewydajny i skomplikowany, dzięki podróżom międzywarstwowym, dokonywanym przez DWM.

Interix

Mniej uzasadnione jest lenistwo, jakie nastąpiło później. Objawiło się ono na szereg sposobów, pierwszym, i najbardziej dla mnie nieznośnym, był sposób potraktowania podsystemu POSIX w kolejnych wersjach NT. Wskazuje on na istnienie, wspominanych już przeze mnie, kilku walczących ze sobą frakcji w Redmond. Podczas budowania systemu Windows 2000, podsystem POSIX został zastąpiony nieco innym, znacznie bogatszym rozwiązaniem: był to Interix. Interix to, oczywiście wykupiony od zewnętrznej firmy, całkiem pełny userland środowiska Unix. Ale przede wszystkim, jest w dalszym ciągu „osobowością” dla NT, co oznacza, że współpracuje bezpośrednio z jądrem Windows, by oferować programom narzędziowym (GNU) pewną formę dystrybucji Uniksa (NT).

I jest to doprawdy fantastyczne. Podsystem jest na tyle zgodny z POSIX, że istnieją przekompilowane narzędzia z systemu Debian, stworzone by zaktualizować oprogramowanie oferowane przez Interix. Nieco więksi optymiści mówili, że ów projekt pozwoli przerzucić istotną większość narzędzi z Debiana, tworząc w efekcie kolejny „spin” systemu. A więc na równi z Debian/Linux i Debian/kFreeBSD stałoby Debian/NT. Tutaj jednak ów fenomenalny scenariusz zaczyna nieco blednąć. Skąd bowiem w ogóle powstał pomysł portowania Debiana na NT? Oczywiście, mowa o świecie open source, gdzie wytłumaczenie „because we can” jest częstsze, niż nakazuje rozsądek, ale to nie dlatego. Otóż genialny projekt Interix został następnie prowadzony przez partaczy bez wizji. Jasne jest, że opiekunowie Interiksa nie mieli na celu stworzyć systemu o poziomie funkcjonalnym np. pulpitowego Debiana, a raczej pracowali nad warstwą zgodności z Uniksem dla dużych firm. Oczywiście. Problem polega na tym, że i to robili źle. Z biegiem lat Interix nie był traktowany jako rozwiązanie poważne i programy, które musiały pracować na Windowsach, celowały raczej w zgodność z warstwą Cygwin, a nie z Interiksem. Podsystem został porzucony jako zbędny balast w roku 2011 i od tego czasu warstwy uniksowej w Windows już nie ma.

A co dalej z OS/2?

Można się sprzeczać, czy marketingowo to dobre zagranie. Losy i geneza NT są mocno splecione z decyzjami podjętymi przed laty przez IBM. Gdy wydawano (już bez współpracy z Microsoftem) system OS/2 2.0, IBM reklamował go hasłem „better DOS than DOS and better Windows than Windows”. Zgodność z MS‑DOS została zachowana (wszak nazwą kodową OS/2 było na początku DOS5), a licencje pochodzące z zerwanej umowy z Microsoftem dostarczały IBMowi kompletne(!) środowisko Windows 3.0, do którego można było „wyjść” celem uruchomienia programu z Windows, podczas, gdy pamięcią dalej zarządzał (po nowemu) OS/2. To twórcze podejście, pozwalające zaoferować system nie tylko najlepiej zaprojektowany, ale i zgodny ze wszystkimi programami na rynku, miało jedną małą słabość. Otóż po co pisać programy dedykowane dla OS/2, skoro można pisać programy na Windows? One zadziałają wszędzie. A dedykowany program dla OS/2 nie. Jeżeli klienci będą chcieli, kupią OS/2, ale to już ich sprawa.

Runtimowy zawrót głowy

Efektem był niemal brak aplikacji dla systemu od IBM. Pogrążyło to projekt jeszcze bardziej. Dlaczego o tym mówię? Bowiem taki jest prawdopodobny los Projektu Astoria. Gdyby Windows Mobile umiał uruchamiać aplikacje dla Androida, już nikt nie pisałby aplikacji UWP. Zresztą i tak nikt nie pisze, to API jest stracone. Niewątpliwa zaleta, w postaci przenośności między urządzeniami idealnie jednak nadaje się na bycie dodatkową „osobowością” dla NT, bowiem działałby blisko sprzętu, bez emulacji i międzyplatformowo, uwzględniając między innymi np. konsolę Xbox. Pisał o tym sam Paul Thurrott, denerwując mnie przy tym niemiłosiernie w 2012, wieszcząc „koniec Win32 ” i powrót do oryginalnych założeń NT. Towarzyszyło temu parę innych pięknych haseł, o których wiadomo było, że nie wypalą: koniec pulpitu na przykład. A dotyczyło to dopiero WinRT, a nie UWP! Przypomnijmy: od czasu publikacji Windows 8 Developer Preview w 2011 roku nie powstała. Żadna. Istotna. Aplikacja. Metro. Nawet pulpit wrócił! Doprawdy zdumiewa mnie, jak tak poważny dziennikarz mógł wierzyć takie frazesy. Etap naiwności przeszedł przecież 15 lat wcześniej…

Zwracam uwagę, że w sprawie osobowości WinRT użyłem trybu przypuszczającego. Wynika to z faktu, że WinRT zostało napisane… w Win32. Obecnie NT nie ma już żadnej osobowości poza Win32, która – you guessed it! – została wpuszczona głębiej w system, podobnie jak podsystem graficzny. Po co? „Dla szybkości”. Być może. Aczkolwiek chyba dla szybkości prac nad nową wersją Okienek, a nie szybkości w rozumieniu wydajności. Przy okazji – czytaliście kiedyś opisy aktualizacji z Windows Update (gdy jeszcze istniały)? Wiele z nich dotyczyło środowiska win32k.sys. To właśnie stąd „osobowość” Win32 chwyta (hook) kontakt z jądrem NT. Problem polega na tym, że win32k.sys, mimo istnienia oddzielnego zbioru dla przestrzeni użytkownika, musiał zostać zaopatrzony w „specjalne pełnomocnictwa”, ponieważ reszta Windowsa jest napisana w Win32. Na przykład taki detal, jak winlogon.

Borderline Personality Disorder

To wszystko może się wydawać kwestią techniczną, istotną jedynie dla informatycznych estetów. Co kogo obchodzi oddzielna osobowość dla POSIX, skoro ewidentnie nie było dla niej potrzeby? Co komu po ładnie zaprojektowanym systemie, gdy jest on zwyczajnie powolny? Owszem, można by to wszystko nazwać detalami. Faktem jest jednak, że Microsoft płaci za swoje zaniedbania względem architektury NT. I nie mam tu na myśli tego, że obecnie muszą stosować dziwne protezy z Ubuntu. Nie mam nawet na myśli tego, że WinRT to oszustwo. Chodzi mi o dawny POSIX. Co prawda LXSS (to jest session manager!) pobiera Ubuntu, ale bez jądra. Gdy już wydaje się, że LX to osobowość NT, prędko wychodzi na jaw, że dziesiątkowe Ubuntu jest w klatce: nie działa na równych prawach z Win32, nie jest alternatywnym API pracującym na jądrze NT, bo ewidentnie gdzieś pod spodem jest coś, co udaje jądro Linuksa. Ale czy całe? Bo jeżeli całe, to jak wyjaśnić to, co zwraca uname…? Anyway – jest to rozkurzony Interix, ze wstawkami podsystemu LX, usiłuje ratować NT ale (jeszcze?) mu to nie wychodzi.

Resztki Astorii

Odkrywanie koła na nowo z LXSS (odwołam te słowa, gdy zobaczę sprawne rozwiązanie w wersji finalnej!) to jednak niejedyna cena za zapuszczenie pomysłu Cutlera. Drugą kwestią jest problem z Windows Server. W 2008 roku Microsoft pochwalił się, że wydaje wersję „Server Core”, zawierającą serwerowe wnętrzności, ale bez środowiska pulpitowego. Zarządzanie serwerem miało się odbywać wyłącznie zdalnie, przez przystawki MMC. Logowanie lokalne do systemu oferowało jedynie okienko Wiersza Polecenia (ale nie PowerShella! Jak można popełnić tak rażące zaniedbanie!?). Jednak system oferował ekran logowania, musiał wystartować z trybem graficznym. Okazało się bowiem, że wtopiony w jądro podsystem graficzny nie daje się usunąć. Niemożliwym okazało się otrzymanie ekranu logowania podobnego do Linuksów:

[code=C]Windows Server 2008 (Datacenter Core) Service Pack 1[/code]

[code=C]WIN-F4XHH7UQKE login:[/code]

Jeżeli przymkniemy na to oko, mówiąc, że da się to przeżyć, to pragnę zwrócić uwagę na inicjatywę Nano Server (minimalny system Windows Server, dla komputerów typu headless, kontenerów chmurowych itp.), która nie daje żadnych efektów. Sześć wersji poglądowych Windows Server 2016 i dalej nie ma gotowego i sprawnego systemu! Gdyby nie pęd za wydajnością z 1995, wycięcie przynajmniej systemu graficznego byłoby banalnie proste.

Wlanie Win32 w głąb NT też skończyło się świetnie. Obecnie jądro systemu zajmuje się np. rysowaniem pasków przewijania na oknach! Przecież to szaleństwo. Oczywiście, w owej procedurze znajdował się błąd, pozwalający na stworzenie jednobitowego exploitu. Wydanie aktualizacji naprawiającej tę wstydliwą usterkę było doprawdy załamujące.

Podsumowanie

NT to wspaniały system. Mam nadzieję, że udało mi się to pokazać. Wbrew pozorom, da się go uratować. Nadzieję pokładam tutaj właśnie we wspomnianych Nano Server oraz w podsystemie LXSS. Czy uda się go zaprojektować zgodnie z oryginalnymi założeniami NT? Jeśli tak, to znaczy, że wreszcie ktoś zaczął porządnie grzebać Windowsowi „pod maską”. Czas najwyższy – ostatni raz miało to miejsce w okolicach Visty. Niestety, nowości, o których obecnie głośno, mają bardzo duży potencjał by być dramatycznymi niewypałami. Tymczasem NT było od lat psute do takiego stopnia, że wywoływało wręcz frustrację jego programistów (bardzo polecam lekturę).

Zobaczymy. Może się uda. A może to wszystko nie będzie miało znaczenia, bo Windows dołączy do grona niechcianych przez rynek systemów. OS/2 na pewno za nim tęskni.