Plan maksimum: anulowane i nieukończone funkcje w systemie Windows na przestrzeni lat

Ostatnio podnosi się straszna afera, że kolejne kompilacje Windows 10 w ramach programu Windows Insider nie oferują nowych funkcji. Miesiąc temu informowano nas, że częstość publikowania nowych „buildów” wzrośnie, zgodnie z szalenie popularnymi żądaniami użytkowników. W praktyce darmowi betatesterzy otrzymali częstsze aktualizacje, ale wszelkie zmiany w nich są kompletnie niewidoczne dla użytkownika. Oczywiście, modyfikacje „pod maską” również wymagają przetestowania, aczkolwiek jest ono dalece mniej ekscytujące, niż praca z nowym produktem o widocznych zmianach. Zainteresowanie dość mocno spadło, ukazując tym samym, dlaczego praca testera jest opłacana, a nie powierzana chmarze pasjonatów, nieważne jak dużej.

Wspomniane rozczarowanie ukazuje pewną istotną bolączkę dotyczącą Windows 10. Testerzy Windows Insider, prosząc o szybsze wydawanie nowych kompilacji, nie prosili o częstszą możliwość tracenia dwóch godzin na pobranie i zaktualizowanie obrazu całego systemu, tylko chcieli nowych funkcji dostarczanych szybciej. Naiwna arytmetyka, sugerująca, że częstsze podnoszenie numerków oznacza szybsze dostarczanie nowej funkcjonalności okazała się tak samo błędna, jak zawsze. Bowiem na nowe zabawki trzeba czekać tak samo długo (niektórzy wręcz sugerują, że coraz dłużej). Niecierpliwość względem Windows 10 nie wynika tylko z nerdowskiego pędu do wszystkiego, co najnowsze. Program Windows Insider jest bowiem na tyle duży, że poza amatorami próbnych wersji „Nightly” wszystkich możliwych programów, wśród uczestników jest znacznie więcej tzw. przeciętnych użytkowników. Oznacza to, że Windows 10 jest odczuwalnie wybrakowany i mimo ciągłego rozwijania „jako usługa”, w dalszym ciągu jest nieukończoną Ósemką z 2012 roku, w której obiecane funkcje uparcie nie chcą się pojawić.

Jak to dawniej bywało

Nie jest to problem nowy. Osoby śledzące niegdyś rozwój Longhorna znają to aż za dobrze. Moim zdaniem jednak problemy z Longhornem były niczym w porównaniu z rażącymi brakami w Windows 10, bardzo często w bardzo podstawowym zakresie. Ale to nie Longhorn był początkiem maratonu opóźnień w Redmond. Problemy pojawiały się już w latach 80tych, były jednak mniej widoczne publicznie. Tymczasem w Windows od wielu lat można się natknąć na pozostałości wyraźnie niedokończonych projektów, rozwiązania wprowadzone w 20% i nigdy nierozwinięte oraz mieszanki interfejsów wskazujące na wiele nakładanych po sobie warstw, zamiast jednej, porządnej. Po przyjrzeniu się swego czasu Centrom Aktywności, postanowiłem zbadać, jak wyglądały wielkie obietnice dotyczące Windowsów i w jakim stopniu znajdowały pokrycie w rzeczywistości. Wbrew pozorom, zwycięzcą niespełnionych obiecanek nie będzie Longhorn, a coś znacznie potężniejszego. [youtube=https://www.youtube.com/watch?v=b9ifQvQCO7Y] O wyciętych funkcjach Visty wiadomo tak wiele, bo Microsoft popełnił karygodny błąd i postanowił nam je pokazać na filmie. To z tego powodu oczekiwania makabrycznie wzrosły. Był to chyba ostatni raz w historii Microsoftu, w którym dziennikarze techniczni byli szczerze podekscytowani nowościami prezentowanymi przez MS. Zdaję sobie sprawę z tego, że jakość samego dziennikarstwa spadła, ale np. taki Paul Thurrott od lat trzyma poziom, a jego reakcja na longhornowe nowinki była wyraźnie silniejsza, niż na cokolwiek od tego czasu. Nie pomaga zaczarowywanie rzeczywistości, poprzez szastanie określeniem „ekscytujące” – dziś mało co już wzrusza, w myśl tego obrazka:

Wtedy jednak, WDDM, WinFS, Windows Search i Avalon naprawdę robiły wrażenie i spotykały się z autentyczną owacją. Do tej pory dostaliśmy nie więcej, niż 2/3 z owych dawnych szumnych zapowiedzi i dziesiątki osób wciąż po wielu wyrażają o to głęboki żal. Tymczasem wśród nowych zabawek od Microsoftu nie pojawia się od dawna nic, co dziennikarze witaliby szczerymi brawami.

Cairo!

Może się to wydać zaskakujące, ale król chybionych oczekiwań pochodzi nie z 2003, a z 1993 roku. Microsoft i wtedy miał na swoim koncie szereg przekroczonych terminów i zupełnie pomylonych projektów, ale żaden z nich bezpośrednio nie był związany z Windows. Tymczasem w opublikowanych (odtajnionych!) wewnętrznch notatkach służbowych, służących za dowody w głośnym procesie Comes v. Microsoft, pojawia się szkic projektowy potężnego systemu, którego datę publikacji ustalono na rok 1996. Mowa tu o projekcie Cairo.

Mityczny projekt

Dziś już niemal zupełnie zapomniany, system Cairo miał być następcą przełomowego NT OS/2 3.0, lepiej znanego pod handlową nazwą Windows NT 3.1. Jego kluczowymi „selling points” miały być nowa powłoka, opracowywana w ramach projektu Chicago, OLE, zdalne wywoływanie procedur oraz... obiektowy system plików i usługa katalogowa! Jeżeli dla niektórych nie brzmi to znajomo, sprecyzuję, że mowa tu o niczym innym, jak Active Directory. Korporacyjny rejestr zgodny z LDAP, czołowa funkcja Windows 2000, nieodwracalnie zmieniła krajobraz środowiska NT w firmach, dotychczas napędzanych pakietami SNA i BackOffice. Microsoft pracował nad tym rozwiązaniem już lata wcześniej, a jego premierę planowano na 4 lata przed wersją RTM szalenie opóźnionego Windows 2000. Ktokolwiek pracował z AD, wie jak nieocenionym i bezkonkurencyjnym jest narzędziem. Świat IT wyglądałby więc rażąco odmiennie, gdyby było dostępne już w 1996 (it's a big deal, proszę mi tu wierzyć na słowo. Wiem, że jaram się tu jak Most Łazienkowski, ale naprawdę świat wyglądałby inaczej.). Ale serwer LDAP w 1996 nie był nawet najbardziej szalonym pomysłem w projekcie Cairo. W tej konkurencji bezapelacyjnie wygrywa bowiem OFS, a więc obiektowy system plików. Jest on czymś, czego nie otrzymaliśmy nigdy. Jeżeli bazę dla Windows Search uznamy za namiastkę WinFS, to samo WinFS możemy z powodzeniem uznać za namiastkę OFS. A było to dekadę wcześniej!

Nie taki znowu mit

Cairo w powszechnej opinii uchodzi za projekt istniejący wyłącznie na papierze, ale to nieprawda. Istnieją bowiem inne źródła, niż odtajnione dokumenty, odkryte lata po nich. Mowa tu o wyciekłym w 2004(!) roku kodzie źródłowym Windows NT 4.0 oraz o „magicznej” kompilacji 854, a więc post-RTM systemu Windows NT 3.5, pochodzącej dosłownie znikąd, ale niewątpliwie autorstwa Microsoftu. Oba skarby zawierają mnóstwo odniesień do serwera Cairo, enigmatycznych podsystemów typu CairOLE, a Daytona 854 skrywa w swoich bibliotekach nieinstalowany (i nierejestrowany domyślnie) plik OFS.SYS. Jest to sterownik typu Installable File System dla testowej, bardzo wczesnej wersji obiektowego systemu plików. Jego pomyślna instalacja w systemie pozwala przekonać się, że możliwe jest formatowanie woluminów z jego użyciem, a następnie poprawny zapis na nich. Daytona jest jedynym namacalnym wystąpieniem sterownika OFS, ale listowanie plików zaginionych kompilacji oraz pakietów DDK pozwala odkryć, że rozwijano go jeszcze przez wiele miesięcy, nie dołączając go do większości próbnych wydań NT.

Dokładniejsze wypróbowanie możliwości OFS jest obecnie niemożliwe, ponieważ brakuje oprogramowania, które umiałoby się z nim dogadać. Niewątpliwie stworzono je, ale zapewne nigdy nie uda się go odnaleźć. Gdzieś w drugiej połowie lat 90tych o OFS ślad zaginął, bez oficjalnego komunikatu ze strony Microsoftu. Wszak z marketingowego punktu widzenia, nigdy nieogłoszony obiektowy system plików po prostu nie istniał. Wzmianki o podobnym narzędziu zaczęły się pojawiać w okolicach roku 2002, gdy gdzieniegdzie wspominano o pracach nad WinFS. Mało kto jednak wiedział, co kryje się pod tą nazwą, do prototypów dopuszczono groteskowo małą liczbę osób, ale zeznania jednej z nich (jak zwykle Paul Thurrott) wskazują, że miała to podobno być gigantyczna rewolucja...

Wiele innych możliwości Cairo dziś brzmi, jak bełkot, naszpikowany modnymi wtedy określeniami, jak „zorientowany obiektowo”, „sieciowy” i „wielozadaniowy”. Wynika to z tego, że wiele z dawnych cudów świata dziś uznajemy za bolesne oczywistości. Musimy jednak pamiętać, że nowoczesna wizja Cairo powstała w czasach, gdy najpopularniejszy system dla komputerów osobistych nie oferował chronionej pamięci, użytkowników ani stosu TCP/IP, a programy, w których istniało zastosowanie dla prawego przycisku myszy, uchodziły za drogie oprogramowanie specjalistyczne. Biorąc pod uwagę specyfikę owych czasów, Cairo jawi się jak tym bardziej rewolucyjny.

Co pozostało?

Istnieją jednak elementy projektu Cairo, na które nie musieliśmy czekać aż tak długo. Głównym z nich była 32‑bitowa powłoka, Explorer, teoretycznie wspólna dla Cairo i Chicago. Rozwój projektu nieco „rozjechał się” między owe dwie gałęzie, ale w końcu wylądował w Windows 95. Zabawnym jest, że próbne wersje Chicago zawierały o wiele bardziej dojrzały funkcjonalnie Eksplorator, niż ten, który umieszczono w wersji finalnej. Legendarne drzewo folderów z lewej strony okna pozwalało, poza nawigowaniem po systemie plików, na zaglądanie do folderów poczty i kontaktów oraz „folderów specjalnych”. Pod tą nazwą kryły się systemowe pseudo-katalogi, jak Drukarki lub Panel Sterowania, ale również automatycznie tworzone foldery wyników wyszukiwania, ukazujące jedynie wyszukiwane elementy. Było to echo OFS, który pozwalałby w Cairo na tworzenie katalogów przechowujących jedynie konkretne elementy, np. Muzykę albo dokumenty, w których padają konkretne nazwiska. Pomysł wrócił wraz z WinFS, a strzęp takich funkcji dostarczają foldery wirtualne, wyniki wyszukiwania i biblioteki w systemie Vista (2006). Swoją drogą, OFS miał być niedostępny (celowo) w Chicago. Jestem ciekaw, jak przyjętoby taką przepaść funkcjonalną między systemami wydanymi w odstępie jednego roku.

Innym elementem Eksploratora Cairo miał być wbudowany podgląd dokumentów. Nic z tego nie wyszło, ale mając tę wiedzę jasnym (i zabawnym) staje się, czemu w Windows 95 znajduje się QuickView, czyli „szybki podgląd”. Po prostu nie udało się go zintegrować z powłoką. Uniwersalny podgląd dokumentów wrócił dopiero do wzbogaceniu Windows w Internet Explorera i pulpit HTML. Była to jedna z funkcji pełniących rolę wymówki uzasadniającej nieusuwalność IE. Tylko, że Cairo miał sobie radzić bez tego, wykorzystując jedynie OLE...

Żadna z nieporzuconych funkcji Cairo nie pojawiła się na czas. Nawet Microsoft Mangement Console nie zdążył na premierę Windows NT 4.0 (o nazwie kodowej „Cairo”, al bądźmy szczerzy...) i wydano go rok później. Zunifikowane wdrażanie oprogramowania czekało jeszcze dłużej i pojawiło się dopiero w Windows 2000. W sumie to wersja 2000 jest najbliższa realizacji planu Cairo. Oczywiście, najtrudniejszy element (OFS) dalej był daleko poza zasięgiem, ale gdyby system wydano w 1996 roku, jak planowano, Windows byłby naprawdę bezkonkurencyjny. Wygryzłby nawet sieciowe rozwiązania Novella wcześniej, niż to iało miejsce. Windows NT byłby nowoczesny znacznie wcześniej, a musimy pamiętać, że naprawdę było na to zapotrzebowanie. NT 4.0 Workstation nie obsługiwał nie tylko USB, ale i Plug and Play, a nawet ACPI! Komputer trzeba było wyłączać „z buta”, przyciskiem. Pograć też się nie dało, bo przecież DirectX powstał tylko dla wersji 95 i 98. Biznesowy system Microsoftu był odczuwalnie przestarzały, a nowa wersja się spóźniała (Jim Allchin stwierdził, że wydanie Windows 2000 w wydaniu „plan max”, ze wszystkimi planowanymi elementami, musiałoby zostać przesunięte poza rok 2000, co byłoby wizerunkową katastrofą.). Sytuację ratował jedynie fakt, że wymagania sprzętowe NT były nieco zbyt wysokie dla domowego użytkownika, pracującego zazwyczaj na nieziemskim złomie. Ale przecież sprzęt przyspieszał...

No dobrze, a więc dzięki Cairo świat byłby lepszy. Ale przecież beta Active Directory pojawiła się jesienią 1998 i była nieużywalna, czy wydanie tak ambitnego projektu było w ogóle możliwe tak wcześnie? Niestety, prawdopodobnie tak. Rynek IT wiecznie przeżywa gigantyczne poślizgi i wycięcia funkcji, ale istnieje szereg systemów, które powstały „nagle” i „znikąd”, jak QNX, Rhapsody i NextSTEP. A więc twierdzę, że jak najbardziej było to możliwe. Niestety, sprawy nie poprawiały absurdalnie ogólnikowe cele projektu. Platforma multimedialna Clockworks miała służyć do wszystkiego, co ma w nazwie „multimedia”, ale nie do końca wiadomo, czy miało to być strumieniowanie multimediów (jak GSteamer), jakiś pakiet filtrów pracujących między kodekami (jak ffmpeg), czy może jakiś turbodoładowany odtwarzacz wspomagany przez OFS? Nigdzie nie padają konkrety, ale (niepokojąco wczesna) data publikacji już tak. Tymczasem Microsoft musiał wydać Internet Explorera 4.0 z programem RealPlayer, bo ich własny Windows Media Player rozmieniał się na drobne formantami ActiveMovie i filtrami DirectX. „W dalszym ciągu nie zdążyliśmy napisać nowoczesnego odtwarzacza, ale za to mamy bardzo fajny podsystem OLE!”. Odważę się stwierdzić, że to nie „feature creep” (próba wprowadzenia zbyt wielu funkcji), a zwyczajne problemy organizacyjne były odpowiedzialne za klęskę Cairo.

Windows 95

A nie był to jedyny projekt Mirosoftu, który łapał poważne opóźnienia. Okazało się bowiem, że Windows 95, sam spóźniony o dwa lata, zestarzał się dość brzydko, a w dodatku bardzo szybko, bo już kilka miesięcy po premierze. Gdy zespół NT/Cairo bawił się eksperymentalnymi sterownikami do obiektowego OFS, mającego zastąpić i tak jeszcze świeży, korporacyjny NTFS i jego starszego brata HPFS, Windows 95 zadebiutował na rynku obsługując jedynie system FAT16, przestarzały w momencie powstania, obsługujący partycje o maksymalnym rozmiarze 2GB. Brakowało też obsługi USB, mimo, że nad jego powstaniem pracował między innymi sam Microsoft. „Rewolucyjne” Okienka nie obsługiwały też domyślnie protokołu TCP/IP i nie miały żadnej przeglądarki internetowej. System obsługiwał APM, ale ACPI już nie, przez co mroczny napis „teraz można bezpiecznie wyłączyć komputer”, w dalszym ciągu wywołujący u mnie dyskomfort, pojawiał się aż nazbyt często. System nie oferował również obsługi dla AGP, więc DirectX radośnie akcelerował wyświetlanie grafiki na jakże superszybkiej magistrali PCI. Zintegrowany z Eksploratorem program PIM też gdzieś zniknął, a jego strzępem był Windows Messaging i koszmarny klient Exchange (oczywiście żaden z nich nie obsługiwał poczty internetowej). Zaszła potrzeba „wyremontowania” wnętrzności Chicago i z Windows95 wydzielono projekt Cleveland.

Cleveland + Athena = Nashville

Wraz z głośnymi narzekaniami dostawców sprzętu (ISV), domagających się obsługi jakichkolwiek nowoczesnych standardów, problemy zaczął też sprawiać niesforny Netscape, który najpierw uświadamiał światu, że Windows jest wybrakowany, bo samodzielnie nie nadaje się do internetu, a potem zaczął sugerować, że Okienka w ogóle są niepotrzebne, bo niedługo będzie potrzebna tylko przeglądarka i oni planują dostarczyć właśnie coś takiego (taki Chrome OS 20 lat temu). Pakiet „Internet Plus Pack” od Microsoftu niezbyt pomagał zmienić ową opinię. W ten sposób powstał projekt Athena, który pracując pod kontrolą projektu Cleveland miał dostarczać gotowy zestaw do pracy w internecie, czyli system Nashville. Mimo imponującej prędkości prac i rozmachu, projekt Athena okazał się takim mini-Cairo: planem było dostarczyć nową internetową platformę, a w rzeczywistości udało się zaoferować ułamek owej obietnicy. Na czym miał polegać system Nashville? Przede wszystkim chodziło o ActiveX. Pulpit i Eksplorator miały być rysowane przez Internet Explorer, oferować dynamiczne podglądy dokumentów i interfejs wyrażany za pomocą HTML. Ponadto, program pocztowy miał powrócić, uzyskać integrację z eksploratorem i wreszcie łaskawie obsługiwać pocztę internetową i książkę telefoniczną. Interfejs przeglądarki (i w efekcie również eksploratora), miały pozwalać na całkowite dostosowanie przez użytkownika. Poza powyższymi zmianami, system miał być zaopatrzony w program do telekonferencji i aplikację do czatu.

Internet Explorer

To powinno brzmieć znajomo: na tym (między innymi) polegał przecież Internet Explorer 4.0. Wobec tego, dlaczego IE w projekcie Nashville przedstawia się jako wersja 3.0? Przez lata, dominującą teorią, która miała wyjaśnić powyższą rozbieżność, była teza, że wersja raportowana przez IE jest zwyczajnie błędna i nie „podbito jej” do numeru 4.0 podczas prac modernizacyjnych. Istniały poboczne źródła które twierdziły coś innego, ale dopiero 2 lata temu udało się udowodnić, że początkowo to IE3 miał być „zabójcą” Netscape’a, integrującym się z powłoką odświeżonego systemu. Niestety, nie zdążono ukończyć projektu Athena na czas. Internet Explorer 3.0 nie oferował wysokiego poziomu integracji, mimo, że wykonano bardzo dużo pracy, która wkrótce zaowocuje wydaniem 4.0. IE3 został dołączony do Office 97 jako element opcjonalny. W dalszym ciągu nie oferował bowiem zaawansowanej platformy, do której mógłby zależeć jakikolwiek element oprogramowania. Wciąż była to „wolnostojąca” przeglądarka, na prawach każdego innego systemu. Projekt Athena nie spełnił oczekiwań, dostarczając zbyt niewiele. Jednakże, sam w sobie nie był aż taką porażką, jak Cairo: wykonano bardzo dużo pracy, po prostu efekty były „niewidzialne”. Tymczasem Cairo było systemem mitycznym, zbiorem przyszłościowych funkcji, odległych jak ludzkie kolonie na Marsie. Niepowodzenie Atheny miało ciekawy skutek uboczny: fork Windows 95, Cleveland, bez Atheny stał się niepotrzebny. Główna gałąź Windows 95 ulegała szybszym przemianom i dostarczała obsługę brakujących technologii, ujętą w ramach (odpłatnej…) aktualizacji OSR2. Zdecydowano się więc zintegrować nowości z Cleveland do głównej gałęzi Windows 95. Dzięki temu wprowadzono do systemu projekt Detroit: obsługę koncentratorów USB, osiągniętą w ciekawy sposób: poprzez „przeszczep” fragmentu jądra NT, celem dostarczenia obsługi modelu sterownika WDM. Tymczasem, odświeżony Windows 95 dalej nie był platformą internetową o sile mogącej konkurować z Netscape. Projekt Nashville trwał więc dalej, mimo rocznego opóźnienia. Żywiołowo pracowano nad jego ukończeniem, oferując kolejne migawki w postaci, dziś już kompletnie zapomnianych!, „Nashville Plus Pack”. Kolejne wydania coraz mocniej integrowały narzędzia internetowe z systemem Windows. Aż w roku 1997 ogłoszono ukończenie projektu Nashville, wydając program Microsoft Internet Explorer 4.0, z rocznym opóźnieniem. Czy dostarczono wszystkie obiecane funkcje? Nie, i to po dwakroć nie. Przede wszystkim wersja 4.0 dalej nie zawierała odtwarzacza multimedialnego: podczas instalacji IE4 w systemie pojawiał się „Real Player by Progressive Networks”. Dopiero wersja 4.01 poprawiła tę lukę i była „kompletna” jako wydanie pakietu platformy internetowej. A więc 1,5 roku opóźnienia. Jeżeli jednak będziemy pamiętać o systemie Cleveland, szybko okaże się, że opóźnienie jest większe: przecież „odświeżony” system do celów internetowych, a więc na tamte czasy Windows 95 OSR2, był nędzną wymówką: doklejenie suplementu USB, modelu WDM, obsługi AGP, systemu plików FAT32 dla dużych dysków, oraz takich nieistotnych detali, jak UDMA lub MMX odbyło się kosztem stabilności. System działał lepiej, niż oryginalne wydanie Chicago… dopóki nie skorzystało się z żadnej z nowych zabawek. Na przykład użycie USB było proszeniem się o bluescreen (który zresztą grzmotnął podczas prezentacji z udziałem Billa Gatesa). Gdy niedawno przywracałem do życia komputer z 1996 roku, z USB na pinach, odczułem boleśnie, jak chybotliwe były dodatki zaserwowane w OSR2. Zdecydowanie nie była to „platforma internetowa”, godna do konkurowania z  projektem Netscape. Chyba, że zainstalowaliśmy IE4 na Windows NT, ale wtedy nasza platforma może i jest internetowa, ale z kolei multimedialna już nie za bardzo. Dlatego potrzebny był fundament, w którym powyższe dodatki nie były doklejone szarą taśmą, a naprawdę zaimplementowane z jakąkolwiek kontrolą jakości. Takim systemem był dopiero Windows 98, a więc opóźnienie projektu Nashville (w swojej pełnej formie) wynosiło już dwa lata. Jednakże pierwsza wersja wciąż była wybrakowana i wiele ostrych brzegów wygładzono dopiero w wersji Wydanie Drugie. A więc, czepiając się, można stwierdzić, że Nashville miał wręcz 3 lata opóźnienia.

NT 5.0

Mimo mocnych poślizgów terminowych, udało się ukończyć projekt Nashville i dobić Netscape. Ale jak tam w międzyczasie miał się nasz Cairo ze swoją usługą katalogową? Otóż nędznie. Nie było jej ani na początku projektu Nashville (1996), ani po jego zakończeniu (1999). Gdy ostatecznie upadł pomysł wydania Cairo rok po Chicago, pierwszą planowaną datą premiery usługi katalogowej był rok 1997. A więc tylko rok później. Ktoś najwyraźniej głęboko wierzył, że to racjonalnie oszacowany termin. Jak wyglądało zaawansowanie prac na Active Directory w roku 1997? Otóż było wiadomo, że do jej udźwignięcia będzie potrzebny nowy system, Windows NT 5.0. Wydano wersję beta NT5, ale chyba tylko po to, by uspokoić dziennikarzy: system żadną miarą nie zasługiwał na miano bety. Nie przeszkadzało to ogłosić kolejnego projektu, który będzie cierpiał w „Development Hell” przez najbliższe lata, czyli złączenia linii 95 i NT, planowanego na rok 1998. Czy beta, a więc system teoretycznie zbliżony do kompletnego funkcjonalnie, zawierał usługę katalogową? Oczywiście, że nie. Nie zawierał nawet serwera DHCP. Active Directory pojawiło się w wersji beta 2, rok później. Dwa lata po niewydanym Cairo, rok po niewydanym NT 5.0, w terminie niezrealizowanego połączenia linii 95 i NT, zmuszającego do wydania wersji 98, na wszelki wypadek przygotowywanej dalece wcześniej (patrz wyżej). Windows 98 miał być ostatnim klasycznym systemem Windows, dorocznie aktualizowanym. Dlatego pierwsze próbne wersje 98 SE, były wydawane w postaci paczki przypominającej Service Pack. Przyszłość miała należeć do NT. Ponieważ rok 1998 zaowocował dopiero betą NT5, premierę przesunięto o rok. Mimo publicznego przyznania, że opóźnienia wynikają z nadmiaru zaplanowanych funkcji, nie przeszkodziło to panu Allchinowi rzucić obietnicy, że NT5 będzie obsługiwać nową platformę internetowych multimediów opartych o Windows Media, NetShow, DirectX i HTML (Silverlight!), nowe API do tworzenia aplikacji HTML (Neptune!) oraz zasady grupy w Active Directory. Były to ogłoszenia nieproporcjonalnie zuchwałe względem poziomu dojrzałości kodu, wyglądające jak żart nawet wtedy.

Windows 2000 nadchodzi

Pod koniec roku 1998, Microsoft narzucił sobie pętlę na szyję, ogłaszając, że NT5 zostanie nazwany „Windows 2000”. Kilka miesięcy później ogłoszono trzecią betę, wraz z obwieszczeniem, że do systemu Windows 2000 nie zostaną dodane żadne nowe funkcje. Wydanie „Home” odpięto i opóźniono, wrzucając nieukończone elementy do projektu Neptune, z datą wydania „nie wiadomo, kiedy”. Udało się co prawda ukończyć usługę katalogową (wreszcie), ale była ona elementem systemu, który dalej nie był gotowy. Udało się go wydać dopiero w moje 10 urodziny, w lutym 2000 roku. Zrealizowano około 2/3 początkowo zakładanych projektów dla NT5. Najbardziej bolesnym brakiem była nieistniejąca wersja Home, która miała nadejść „wkrótce później”, ale projekt Neptune zawiódł, a wycięte z niego działające fragmenty, w postaci systemu Millennium, wydano chyba tylko po to, żeby w XXI wieku użytkownicy domowi nie musieli kupować czegoś z „98” w nazwie.

Whistler

Wycięte funkcje NT5, oraz brakujące połączenie linii domowej i biznesowej, miał dostarczyć nasz ukochany Whistler, a więc Windows XP. Ta, wedle niektórych najlepsza, wersja Okienek nadeszła już rok po Windows 2000, a wydano ją w terminie? Czyżby wreszcie ukończono projekt NT 5.0 (1998) i zbliżono się do Cairo (1996)? Otóż w dalszym ciągu nie. Może się wydawać, że było inaczej, przecież powstały wydania „Home” i „Professional”! Zdradzę zatem, gdzie jest brakujący element układanki: widać do w okienku „Internet Explorer – Informacje”, podającym numer wersji przeglądarki. Co tam widzimy? Otóż „6.00.2600.0000.xpclient”. I co z tego? Ano skoro istnieje „xpclient”, to znaczy, że miał istnieć również „xpserver”. Jak najbardziej – produkt „Whistler Server” był trzecim wydaniem Windows XP, dość mało znanym. Okazało się jednak, że XP Server nie jest na tyle gotowy, by go wydać, poza tym stwierdzono, że złośliwością jest oferować nowy system serwerowy rok po wydaniu poprzedniego, który w dodatku wymuszał najtrudniejszą migrację w historii serwerów Microsoftu. Nie przeszkodziło to Microsoftowi dekadę później wywinąć takiego numeru z Windows Server 2012 R2. Takie usprawiedliwienie brzmi logicznie, ale dziś wiemy, że to myślenie życzeniowe: Windows XP Server nie został wydany, bo był zbyt niestabilny, Windows.NET Server 1.0 (2002) nie ukazał się, bo integracja .NET z systemem po prostu się nie powiodła, a Windows Server 2003 musiał czekać jeszcze rok, bo przecież po tej nieudanej integracji trzeba było posprzątać. No ale przynajmniej udało się wyczyścić wiele błędów i Windows Server 2003 był podobno „najlepszym systemem na świecie”. Fakt, trzeba go było poprawiać tylko raz, bo nie załapał się na refaktoring w ramach Trustworthy Computing (Windows XP też nie, stąd Service Pack 2) i cichcem wydano wersję „R2” pod koniec 2005, czyli wtedy, co Windows Media Center. Można zatem powiedzieć, że obietnice dotyczące Windows NT 5.0 zrealizowano z siedmioletnim opóźnieniem. Jeżeli oczywiście nie policzymy Centrów Aktywności, środowiska programowania DHTML/HTA z Neptune (tzw. Mars), nowego panelu sterowania i ekranu startowego. Wtedy możemy mówić o czternastoletnim opóźnieniu, bo przecież powyższe elementu zadebiutowały dopiero w Windows 8. Rzecz jasna, tylko wtedy, gdy uznamy środowisko Metro, nowe menu Start i aplikację „Ustawienia” za dokończone…

Longhorn, oczywiście

Podczas walki o wydanie Windows Server 2003, w innych zakamarkach Microsoftu rwano sobie włosy z głowy, próbując ukończyć króla niedotrzymanych obietnic, czyli niesławnego Longhorna. Na temat tego systemu napisano już morze słów, a ja bardzo nie lubię być odtwórczy. Dokonam więc szybkiego przeglądu funkcji, które najdobitniej udowadniają moją niepopularną tezę, że gdyby Longhorn został wydany, byłby katastrofą.

[item] powłoka użytkownika w .NET. Ekhm:[/item][img=robot]

Świetnie, ale po co? Bo ma być programowalna i rozszerzalna? Active Desktop i „Widok folderów sieci Web” też były programowalne, przez plik folder.htt. Mam uzasadnione obawy twierdzić, że wykorzystanie tej funkcjonalności byłoby rzadkie, a efekty morderczo brzydkie. Nie wspominając o tym, że .NET jest zwyczajnie ciężki, optymalizację, która pozwala ulżyć interfejsom GUI, oraz taką nieistotną rzecz, jak np. WĄTKI, wprowadzono dopiero w wersji 4.0, w 2010. Jakże więc to miało działać poprawnie w próbnej wersji 1.2? [item] obsługa dodatkowych wyświetlaczy[/item][img=aux]

Pozorny strzał w dziesiątkę, ale tak naprawdę ślepa uliczka wyobraźni sprzed 12 lat. Widział ktoś takie wyświetlacze? Ja tak. Służyły za wyświetlacz numeru utworu, gdy laptop działał w trybie gigantycznego discmana. System musiał być podczas jego użycia wyłączony. Powyższe rzekomo trafione rozwiązanie jest kompletnie niefunkcjonalne, podobnie, jak.. [item] dawny Sidebar![/item]Piękne animacje-atrapy, stworzone we Flashu, pokazywały jak wspaniałe małe aplikacje miałyby korzystać z uroku pocznego paska powiadomień, na który nagle zrobiło się dużo miejsca, bo przecież ekrany panoramiczne. Niestety, nie udało się ukończyć powiadomień przez Sidebar, licząc na wenę ze strony dostawców oprogramowania. Dlatego w systemie Windows Vista, pasek boczny jest domyślnie włączony. No dobrze, niech każdy, kto zna funkcjonalną aplikację-gadżet, korzystającą z Paska Bocznego, podniesie rękę. Tak myślałem. Sidebar to również strzał w stopę, zaklinanie rzeczywistości i myślenie życzeniowe nie są w stanie zmienić tego, że Pasek Boczny wykorzystywano tylko do pokazania efektu szkła i ładnego zegara, gdy koledzy przychodzą zobaczyć Vistę. Potem zawsze był wyłączany. [item] animowane okna i przezroczystość.[/item][img=4015]

Matko jedyna! Jakże wszyscy chcieli dopaść legendarny Build 4015.lab06_n, zawierający te wspaniałe efekty! Faktem jest jednak, że powyższe demo powstało, by pokazać możliwości silnika rysującego, a nie po to, by zademonstrować, jakie lansujące błyskotki zostaną zaszyte w Longhornie.

Oczywiście – czepiam się. Longhorn był pełen fascynujących rozwiązań. Świetnie byłoby je dostać wcześniej, tak samo, jak świetnie byłoby dostać Cairo w 1996. Ale większość z owych funkcji już otrzymaliśmy. Czasami w gorszym wydaniu, a czasami w znacznie lepszym: na przykład Windows 8 nie oferuje tańczących okienek i efektu Glass, ale rysuje cały interfejs użytkownika z wykorzystaniem akceleracji 3D. Owszem, Longhorn zapowiadał interfejs wektorowy, ale mam nadzieję, że nikt się nie dał nabrać.

Epilog

Chichotem historii jest tu Longhornowy WinFS, echo nieukończonego OFS. Podczas gdy wiele osób narzeka, że obiektowy system plików nigdy nie powstał, wymienia potencjalne jego zalety i marudzi, że system operacyjny z obiektowym widokiem pliku dostarczałby niesamowitych funkcji, świat poradził sobie inaczej. WinFS, podobnie jak OFS, to bardzo „desktopo-centryczny” pomysł na bazę danych. W dodatku, jest to pomysł niebiorący pod uwagę trybu online. Kategoryzacja danych, indeksowanie, tagowanie (często automatyczne!) danych, ekspresowe wyszukiwanie i wiele, wiele innych aspektów, odbywa się obecnie w usługach chmurowych. Stały się dla wielu użytkowników niewidzialne, a dla specjalistów IT – naturalne i nieodzowne. Tymczasem WinFS to tak przyszłościowe rozwiązanie, że samo zdążyło się w międzyczasie zestarzeć. Kto by się spodziewał. Jednakże, wiele osiągnięć projektów OFS i WinFS zaimplementowano na przestrzeni lat w pakiecie Microsoft SQL Server, fantastycznej bazie danych, która bardzo często napędza chmurowe usługi online, nie krzycząc żadnej panience z Tumblra, że korzysta z obiektowego zaplecza katalogowania danych o wysokiej wydajności :)

Cheers!