Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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:

Windows Server 2008 (Datacenter Core) Service Pack 1WIN-F4XHH7UQKE login:

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.

 

windows linux

Komentarze

0 nowych
  #1 31.05.2016 17:59

Tak, znam to stare logo Winszajsu. Ty nie masz jak pamiętać, za młody jesteś ;p

kuba3351   9 #2 31.05.2016 23:28

Jak ja lubię czytać takie wpisy o wnętrznościach Windowsa, zwłaszcza jeśli w tle jest historia :D było już tutaj wiele takich wpisów i mamy kolejny. Jestem z rocznika 95, więc jak się urodziłem to dopiero wchodził Windows 95, i taka dawka informacji jest naprawdę fajna. Oby więcej.

aPoCoMiLogin   8 #3 01.06.2016 11:22

Rzeczowo i na temat. Fajnie się czytało.

kilijanek   9 #4 01.06.2016 11:29

Dlatego powinni zabić Win XP, Win Vista, Win 7... i wszystko do Win 10, a ten stopniowo kastrować z niepotrzebnych "bajerów" związanych z czasami zamierzchłymi. Jądro NT było cudowne, póki nie zaczęli marketingowo go przerabiać :(

  #5 01.06.2016 11:57

@kuba3351: Wpisz sobie w internecie Windows 2.0.Pierwszy publicznie znany Windows to 3.1,3.11 - ten się najbardziej spopularyzował w latach 90 XX w.
Każdy Windows ma 10 lat życia,a potem traci wsparcie.Za rok porzucą Vistę 2007-2017

AntyHaker   18 #6 01.06.2016 12:19

@kilijanek: Nic z tym nie zrobią, bo bez tego Windowsa nie ma ^^

artur9010   4 #7 01.06.2016 13:42

Miło się czytało.

WMP   1 #8 01.06.2016 14:25

Hmmm, skąd te wszyztkie informacje? Wszyztko jest w linkach które są w tekście? Zastanawia mnie gdzie można znaleźć inforamcje na temat budowy jądra Windowsa.

Berion   14 #9 01.06.2016 14:58

Gorzką prawdę? Za wysoka temperatura na dworze? ;)

pb2004   7 #10 01.06.2016 16:26

Wpis ciekawy ale twierdzenie że LXSS jest odkrywaniem koła na nowo jest nieprawdziwe. Podsystem ten bazuje na idei podsystemów ze starych wersji WNT i rozwija ją aby umożliwić uruchamianie binarek Linuksa bez rekompilacji. Tutaj[1] jest dobry opis architektury LXSS.

1. https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-over.../

  #11 01.06.2016 16:41

Bardzo podoba mi sie ten profesjonalny artykul. Gratuluje!

AlbatrosZippa   11 #12 01.06.2016 16:52

Czy ten co prezentował Windows New Technology nie wyspał się, albo nie wziął antydepresantów?
A tak serio post bardzo ciekawy !

  #13 01.06.2016 17:02

"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."

Rendering czcionek na poziomie kernela windowsa jest obecnie jednym z głównych wektorów ataku (poza wiodącymi, celującymi w brak rozsądku użytkownika końcowego). Zdalne wykonanie kodu, nieautoryzowane podniesienie uprawnień - zgodnie pieją biuletyny bezpieczeństwa od mikromiękkich... Włos się jeży na samą myśl jakie kongo w środku musi siedzieć.

Próby łatania takich kwiatków to syzyfowa praca - bezcelowa, ale za to pewna.

  #14 01.06.2016 17:26

DOBRE! I straszne...

  #15 01.06.2016 20:37

Uss Yorktown to okręt nawodny, krążownik typu Ticonderoga, co zresztą jest w linku. Awaria polegała na paraliżu sieci elektrycznej, wskutek czego jednostka zaczęła dryfować po Zatoce Meksykańskiej.

KyRol   18 #16 01.06.2016 21:24

"A wiecie, że to kiedyś było oficjalne logo"

Wygląda na gniazdo żmiji albo skupisko pijawek - w każdym razie każda z tych interpretacji jest trafna w odniesieniu do m$, dla mnie to logo powinno zostać do dzisiaj.

przemo188   8 #17 01.06.2016 22:47

Wielokrotnie pisałem że MS od jakiegoś czasu (odejścia na emeryturę starych inżynierów odpowiedzialnych za jądro tego systemu) pogubilo się w tym co w ich jądrze siedzi. Brak pełnej dokumentacji wprowadzanych zmian, modyfikacji a także inna filozofia myślenia tych nowych, po szkołach inżynierów jest powodem, dla którego od czasu xp jądro jest to samo, już przestarzałe, nie pasujące do nowych wymagań i rynku. To samo odnosi się do systemu plików. Dlatego kolejne systemy działają coraz gorzej, bo to stare jądro dostało kilkanascie protez dostosowywujących je do obecnych czasów. W końcu kiedyś ktoś w MS powie dość i zaczną myśleć nad nowym jądrem, napisanym od początku lub zaimplementowuja jądro linuxa wyposażone w warstwę implementacji windowsa. Zresztą chyba MS liczy że społeczność zrobi większość pracy oddając na licencji open swoje biblioteki.

  #18 02.06.2016 00:04

RS1 przenosi caly stos graficzny GDI do userlandu, standardowo DX pozostaje hybrydowy-dwa sterowniki,jeden czysto hardwareowy w kernel space, drugi driver do dx api w user space.

  #19 02.06.2016 11:40

Fantastyczny tekst. Smaczki dotyczące ładowania driverów do HMA przypominają mi czasy, gdy moja obudowa po wciśnięciu turbo wyświetlała na segmentowym ledzie oszałamiające 12Mhz :)

wielkipiec   13 #20 02.06.2016 19:01

@_qaz7_ (niezalogowany): źródło?

Magnum 44   17 #21 02.06.2016 21:03

@wielkipiec: Może to jest programista z MS i anonimowo robi wyciek tajnych informacji? :P

davidns   7 #22 03.06.2016 11:26

Obecnie największą zaletą i zarazem najgorszą wadą Window$a jest to, że musi zachować wsteczna kompatybilność z aplikacjami DOS, OS2/NT, Win32 i dotNET. Przez to cały kernel (oraz inne podprogramy jak np. rejestr) jest przerośnięty, archaiczny, dziurawy, zfragmentowany, niestabilny i mało wydajny. A napisanie lepszego systemu od nowa oznacza pozbycie się tych zaszłości oraz jednoczesnie zgodności z milionami aplikacji, na co M$ nigdy nie pozwoli...

Autor edytował komentarz w dniu: 03.06.2016 11:48
  #23 03.06.2016 14:00

@davidns: Jądro Linuksa też zachowuje pełną wsteczną zgodność z userlandem. Aplikacje mają działać nawet kosztem błędów w API.

wielkipiec   13 #24 03.06.2016 16:21

@Roman syn Ryżu (niezalogowany): jądro tak - sam userland już rzadziej :D

  #25 03.06.2016 18:14

jesteś najciekawszym blogerem na dobrychprogramach, tak trzymaj!

pocolog   12 #27 08.06.2016 17:09

Oddam głos tylko na Twój wpis żeby nie zmniejszać jego siły.
Dzięki za kolejny ciekawy artykuł. Myślę że poniektórzy w redakcji po przeczytaniu tego powinni się zarumienić ze wstydu.

But_w_trawie   9 #28 04.08.2016 13:11

dawno temu osobiście instalowałem sobie na kompie win NT 3.51 , bo to była pierwsza prawidłowo działająca wersja NT na rynku.
co do bagna pod maską, aż w takich detalach tego nie znałem, ale też mi kopara opadła jak usłyszałem o nowiści "bash w windows", podczas gdy niezależni od MS programiści już dawno to rozwiązali, i to na wiele sposobów. Także jako natywny exec dla win32.

btw. wyjaśnienia wymaga kwestia braku aplikacji pod OS/2. Otóż MS robił co mógł aby uciec z API dla win3.x, i właśnie dlatego wypuścił Windows95 właśnie wtedy, kiedy IBM wypuścił OS/2 Warp3. Problem w tym, że MS udostępnil programistom kompletnie za darmo narzędzia do tworzenia aplikacji na Windows95 który miał wspierać wielowątkowość, w zamian za lojalkę "apki będą tylko dla windowsów". Z drugiej strony IBM nie zrobiło totalnie nic w tej kwestii. ale paradoksalnie IBM OS/2 Warp3 wątki obsługiwał po prostu rewelacyjnie, pierwszy system na rynek konsumencki który to robił prawidłowo.

No to tyle uzupełnenia tematów. czyli do apokalipsy OS/2 nie przyczyniła się zgodność z windows3 której MS też nie chciał, lecz ...... brak bezpłatnych narzędzi dla programistów aplikacji OS/2. a takie narzędzia wtedy były bardzo drogie. dopiero w późniejszym czasie pojawiło się kilka świetnych narzędzi programistycznych dla OS/2, m.in. kompilator Modula2. Ja byłem z niego bardzo zadowolony. Tyle że to już była musztarda po obiedzie. ps: oddałem głos :) chociaż ja oczekuję więcej treści przypadającej na literkę tekstu :D

wielkipiec   13 #29 04.08.2016 16:52

@But_w_trawie: "więcej treści przypadającej na literkę tekstu"

a to ciekawie brzmi. Co masz na myśli?

But_w_trawie   9 #30 05.08.2016 11:18

@wielkipiec: więcej informacji, mniej liter :)

wielkipiec   13 #31 05.08.2016 15:16

@But_w_trawie: w pracy niedawno mi powiedzieli to samo. Musze się nad tym zastanowić.
Dziękuję :)