Windows Longhorn: piętnaście lat od porażki. Co poszło źle i kim jest Jim Allchin?

Ósmego września 2004 roku powstała kompilacja 5000.winmain, która mimo wysokiego numeru, była pierwsza. W konsekwencji, obiecany system (a wraz z nim szereg prototypowych rozwiązań) nigdy nie ujrzał światła dziennego. Zamiast niego otrzymaliśmy mniej ambitny, acz również rewolucyjny produkt: Windows Vista. Jego solidny fundament do dziś stanowi serce najnowszych wersji Okienek, nie zmienia to jednak faktu, że w planach było coś znacząco innego...

O wersjach beta systemu Longhorn napisano już tak wiele, że trudno być tu odkrywczym. Uwagę entuzjastów przyciągał głównie jego wygląd. Swego czasu galerie zrzutów ekranu z Longhorna były niezwykle popularne i choć część z nich pochodziła z materiałów promocyjnych i była zrobiona we Flashu, grafiki i tak budziły emocje. System miał bowiem być nie tylko zaawansowany, ale i bardzo piękny. Aby nie mnożyć ponad miarę przewodników po Longhornie, skupmy się jedynie na krótkiej liście jego kluczowych, planowanych elementów:

• Obiektowy system zarządzania danymi: WinFS. Nadbudowując się nad systemem plików NTFS, WinFS miał oferować super-zaawansowane metody dostępu i przeszukiwania danych. Każdy plik miał być możliwy do rozbudowanego otagowania metadanymi, zarówno dodawanymi ręcznie, jak i wykrywanymi automatycznie. Przykładowo, zdjęcia miałyby być tagowane datą i miejscem wykonania, obecnością innych osób i pogodą. Te dane z kolei, miały być korelowane z kalendarzem, celem dopasowania okoliczności wykonania fotografii oraz z danymi z książki adresowej, pozwalającymi generować sieć powiązań między kontaktami. WinFS nigdy nie ujrzał światła dziennego a dziś potrzeba jego istnienia jest kwestionowana przez chmurowych dostawców magazynów przechowywania danych.img=1369376427.or.90180
• Podsystem rysowania interfejsu Avalon. W zamierzeniu był to wektorowy, skalowalny i akcelerowany procesorem graficznym mechanizm rysowania okien opartych na nowych widżetach (.NET 1.2), programowany za pomocą języka XAML. Wszystkie aplety systemowe oraz powłoka (Explorer) miały zostać przepisane do dedykowanej wersji .NET tak, by móc zrobić użytek z nowości. Opisywany mechanizm zadebiutował dopiero wraz z Windows 8, a narzędzia Windows od siedmiu lat pozostają przepisane na niego jedynie w mikrym stopniu. Zamiast Avalon otrzymaliśmy WPF: znacząco mniej ambitny, domyślnie nieakcelerowany podsystem również programowalny przez XAML i będący w praktyce nadbudową nad klasycznymi widżetami, a nie nowym toolkitem, jak UWP. Ograniczony, skromniejszy i niezbyt wydajny WPF został dołączony do .NET Framework 3.0 również dla Windows XP.
• Kompozytowy menedżer okien DCE, który w swoim założeniu był niezwykle podobny do rozwiązania DWM obecnego w finalnym produkcie. Z jedną różnicą. DCE miał dostarczać zaawansowane możliwości dla aplikacji napisanych z interfejsem Avalon, wszystkie pozostałe rysując w \trybie zgodności\
• a więc zaopatrując we wszystkie dostępne animacje i przejścia, ale bez dedykowanych ułatwień dla wszelkich nowych widżetów. DCE w swojej oryginalnej postaci został porzucony i ponownie najbardziej zbliżoną do niego technologią jest nowy DWM z Windows 8, stosowany do tej pory.img=DCE

Zdecydowana większość owych wynalazków przestała być ekscytująca, bowiem dostarczono je w zupełnie inny, acz funkcjonalnie zbieżny sposób lata później. Główną rolę w dewaluacji mitu Longhorna odegrały usługi chmurowe (to one oferują dziś ekspresowe przeszukiwanie, metadane do absolutnie wszystkiego oraz zaawansowane metody przechowywania) oraz powszechna migracja na urządzenia mobilne, które potrzebowały lekkich i czytelnych interfejsów, a nie animowanej zorzy polarnej i aplikacji zakładających, że pecet będzie "multimedialnym centrum domu", stojąc jako wielkie pudło na środku pokoju.

Dlatego wyraźnie ciekawszą kwestią jest to, jak doszło do zresetowania projektu. Czy naprawdę było to nieuniknione, kto zebrał się na taką (obcą w korpo) odwagę i kto był za ten stan rzeczy odpowiedzialny. Podczas poszukiwania odpowiedzi na to pytanie pojawia się nazwisko brzmiące Jim Allchin. Był to jeden z głównych menedżerów w Redmond, skazujący wiele projektów na podobnie nędzny los. Okazuje się bowiem, że Longhorn nie był jedynym ambitnym projektem, który okazał się niewykonalny.

Allchin, urodzony w 1951 roku, jest absolwentem Uniwersytetu Stanforda, starannie wykształconym i niezwykle utalentowanym informatykiem o niezaprzeczalnych osiągnięciach i bogatej karierze. W 1990 roku rozpoczął pracę w Microsofcie, początkowo jako architekt odpowiedzialny z system operacyjny Microsoft LAN Manager. Wtedy też dał się poznać bardziej jako menedżer, niż informatyk. Jego decyzje miały bowiem o wiele więcej wspólnego z priorytetami biznesowymi, niż z zasadnością techniczną. I choć firmy IT mają w pierwszej kolejności zarabiać pieniądze, a nie tworzyć doskonałe oprogramowanie, niektóre z owych decyzji do dziś budzą wątpliwości. W dodatku mają pewną osobliwą cechę wspólną, jaką jest "dotyk śmierci".

Jednym z jego pierwszych postanowień dotyczących LAN Managera było... anulowanie projektu. System ten, oparty o OS/2, miał nie przystawać swoją formułą do oczekiwań klientów i do nadchodzących scenariuszy wykorzystania sieci w firmach. Magazyn InfoWorld z tamtych czasów nieśmiało sugeruje, że pomysłem Allchina było zintegrowanie obsługi sieci bezpośrednio z portfolio systemów. Innymi słowy, obsługa sieci miała być naturalną funkcją systemu operacyjnego, a nie oddzielnym produktem. Takie podejście miało podważyć sensowność zakupu oprogramowania Novell NetWare, niekwestionowanego lidera rozwiązań sieciowych przez sporą część lat dziewięćdziesiątych.

Łatwo jest dziś pisać "pod tezę" i stwierdzić, że Allchin przyszedł i popsuł. O decyzji anulowania LAN Managera wiadomo dziś jednak bardzo niewiele, a należy też pamiętać, że system OS/2 nie miał przyszłości, a NetWare był produktem stokroć lepszym od ówczesnych rozwiązań sieciowych Microsoftu. Allchin dobrze o tym wiedział: wcześniej pracował w firmie Banyan jako współtwórca nowoczesnego systemu sieciowego VINES. Jednak na następcę OS/2 przyszło czekać aż do roku 1993. Oznacza to, że w swojej ofercie Microsoft miał produkt, któremu poświęcał marginalną uwagę aż przez trzy lata!

Bezwzględne podejście Allchina stało się jego wizytówką. W roku 1993, na wieść o wykupieniu system DR-DOS przez firmę Novell, rekomendował politykę wobec owej firmy używając następujących słów:

[quote]Wszelkie dyskusje z nimi nie mają sensu, musimy się do nich uśmiechać, ciągnąc w międzyczasie za spust.[/quote]

Wkrótce potem, w instalatorze systemu Windows 3.10, za zgodą Brada Silverberga, pojawił się niesławny kod AARD, przeprowadzający szereg skomplikowanych testów wykorzystujących nieudokumentowane interfejsy system MS-DOS. Celem owego działania było wykrycie, czy Windows jest uruchamiany na systemie MS-DOS, czy jego tańszym klonie, jak DR-DOS. Nie istniały ograniczenia techniczne uzasadniające taki test. Zarząd w wewnętrznej korespondencji wprost przyznawał, że komunikat o błędzie (z numerem zdefiniowanym na sztywno) wyświetlany przez AARD ma wzbudzić w użytkowniku przekonanie, że korzystanie z oprogramowania konkurenta może wywoływać nieokreślone problemy. Kod w dodatku był zaciemniony i polimorficzny, jeszcze bardziej podkreślając swoje złowrogie przeznaczenie.

Kolejną "misją" Allchina po uśmierceniu LAN Managera, było przejęcie kontroli nad zespołem Windows NT, zastępując wybitnego Dave'a Cutlera. NT był gotowy, choć miejscami mocno niedokończony, ale "potrzeba biznesowa" nakazywała już myśleć o wielkim następcy. Windows NT miał więc zdominować rynek, a następnie zostać zastąpiony przez nowsze, jeszcze lepsze rozwiązanie.

Popularyzacja NT miała się odbyć wskutek zmiany priorytetów: zamiast ewolucyjnego zwiększania jakości, którego efektem był Windows NT 3.5, przyszłe wersje miały przede wszystkim obniżyć wymagania sprzętowe, zbliżając je do tych z Windows 95. Konsekwencją tej decyzji było... zintegrowanie stosu graficznego z jądrem. System istotnie zaczął działać szybciej, ale cena tej krótkowzrocznej polityki (komputery z czasem przecież przyspieszyły!) po latach okazała się wysoka.

Jest nią bowiem istnienie potwora o nazwie win32k.sys, niskopoziomowego sterownika kwestionującego decyzje projektowe NT, premiującego wydajność kosztem stabilności. To dzięki sterownikowi win32k dzisiejsze jądro NT jest odpowiedzialne za rysowanie pasków przewijania, a aktualizacje krytyczne rozwiązują gigantyczne problemy w zabezpieczeniach, niemające racji bytu.

Następcą NT miał zostać Cairo, którego szefem również został Allchin. Cairo to taki "mały Longhorn": obiektowy system plików, domenowa usługa katalogowa, usługi sieciowe, akcelerowana grafika i szereg innych rewolucji, kompletnie egzotycznych na pecetach owych lat. Ten system naprawdę istniał: stworzono dziesiątki jego wersji próbnych, ale wydano jedynie skromny zbiór jego funkcji. Poszlaki wskazują na to, że Cairo był rozwijany równolegle z NT, jako jego bogatsza wersja. Wszystkie jego komponenty były dostarczane modularnie, dzięki czemu dało się je usunąć w razie opóźnień. System Cairo wydano w 1996 roku, ale (czyż to nie brzmi znajomo?), znajdował się w nim jedynie ułamek opracowywanych technologii: OLE 2.0 oraz Cabinet Explorer. Zawędrowały one w także do systemu Windows 95. Obiektowy system plików OFS oczywiście przepadł.

W drugiej połowie lat dziewięćdziesiątych, Jim Allchin odpowiadał za uśmiercenie kolejnego po OS/2 systemu, który nie miał przyszłości. Tym razem był to MS-DOS i jego VMM, czyli tandem zasilający klasyczne wersje Windows. Najnowsza wersja NT, Windows 2000, miała zasypać przepaść między serwerowymi a klienckimi wersjami Okien. Tylko, że Windows 2000 wcale nie miał się tak nazywać. Miał mieć swoją premierę dwa lata wcześniej. Ale jak przyznał sam Allchin, wiele planowanych funkcji systemu nie mogło zostać ukończonych, ponieważ technologia "pod spodem", która miała zapewniać im środowisko, była niegotowa lub niestabilna.

Ponownie, możemy tu pisać pod tezę i twierdzić, że rozwój systemu Windows 2000 był katastrofą i marnowaniem zasobów. Koniecznym jest jednak wziąć pod uwagę, że na tamte lata przypada nagły wzrost popularności zjawiska kompletnie zignorowanego w planach Microsoftu: internetu. A wraz z nim – otwartych standardów, a więc czegoś zupełnie niebranego pod uwagę podczas prac nad Windows. Zgodność ze standardami miała być zapewniana głównie celem przeciągnięcia klientów i zaoferowania im innych, znacznie mniej przenośnych rozwiązań. Allchin był wrogiem otwierania Windows na świat, ale wielu menedżerów w firmie twierdziło, że to konieczne. Mimo tego, że przysłużyło się to do budowania rzeczywistości, w której Windows jest tylko jedną z opcji, a nie koniecznością.

Po premierze Windows 2000, Allchin był odpowiedzialny za wdrożenie polityki Trustworthy Computing, co poskutkowało (a jakże!) opóźnieniem wydania serwerowej wersji Windows XP. Mniej więcej wtedy rozpoczęły się prace nad Longhornem. Teraz możemy spojrzeć na proces rozwoju owego systemu nieco inaczej, znając wszystkie wcześniejsze detale.

Obiecany system miał działać z wykorzystaniem obiektowych mechanizmów przechowywania danych, drastycznie odmiennych od wszystkich innych rozwiązań dotychczas dostępnych w Windows. Skorzystanie z niego wymagało stworzenia oddzielnej, nowej klasy zaawansowanego oprogramowania.Interfejs miał zostać drastycznie przebudowany z wykorzystaniem możliwości najnowszego sprzętu i być wizualnie wyraźnie odmienny od poprzednika, mocno dbając o jednoznaczność i konsekwencjęWszystkie nowe możliwości systemu miały być zapewniane przez dedykowany, nowoczesny i obiektowy framework programistyczny, oferując dodatkowo przezroczystą obsługę sieci. Framework ten miał być tworzony równolegle z aplikacjami, które by go wykorzystywałySystem był mocno skoncentrowany na konserwatywnie rozumianym komputerze PC, bez uwzględnienia mobilności i nowych internetowych standardów [img=screen057]

The Wall Street Journal podawał, że reset Longhorna był decyzją podjętą późnym latem 2004 i wynikał z niemożności dostarczenia tak ambitnego projektu za pomocą archaicznej metodyki stosowanej w owym czasie w Redmond. Nie opuszcza mnie jednak od pewnego czasu przekonanie, że dużą częścią problemu był sam Allchin. Będąc perfekcjonistą o rzetelnych i ugruntowanych poglądach o tym, jak powinien wyglądać nowoczesny system sieciowy, próbował on przez niemal dwie dekady stworzyć i sprzedać ten sam produkt. System, którego stworzenie okazywało się równie niemożliwe mimo upływu lat i którego cechy były nieprzystające do potrzeb rynku, mimo swojej niewątpliwej technicznej elegancji.

Przez cały ten czas, Microsoft zawsze miał jakiś "plan B". W przypadku NT LAN Managera był to OS/2, w przypadku Cairo – NT 4.0, klienckiego NT – Windows 98, a zamiast Neptune'a otrzymaliśmy Millennium. Podczas gdy Longhorn nie miał już planu B. A co gorsza, złożył bardzo wiele obietnic, na które wszyscy czekali.

Już na początku 2004 roku Allchin wiedział, że Longhorn ma poważne problemy. W połowie roku, a więc jeszcze przed wydaniem kolejnej "dawnej" bety dla deweloperów, los projektu był już przesądzony i prace rozpoczęto na nowo. Bardzo wymownym dowodem na to, co było największym problemem Longhorna, był... zakaz programowania w .NET. Vista istotnie dostarczyła .NET Framework 3.0, ale żaden element systemu nie został napisany z jego użyciem. Zaniechano przepisywania produktu do technologii, która nie była jeszcze gotowa. Powrócono do tego dopiero, gdy realia zaczęły na to pozwalać.

Windows 8 dostarczył środowisko WinRT oraz podstawowy zbiór aplikacji Metro z obietnicą rozwijania ich w przyszłości. Windows 10 nie składa dziś w zasadzie żadnych obietnic, nie narzucając żadnego specyficznego tempa rozwoju. Paradoksalnie, dopiero w taki sposób możliwe jest wdrażanie przełomowych nowości. Być może jest to fakt, z którym szef zespołu Windows nie mógł się pogodzić. Trudno też dziś ocenić, czy Microsoft również teraz usiłuje sprzedać nam jakiś mityczny produkt, który nigdy nie ujrzy światła dziennego. Pozory wskazują to, że takie coś nie ma już miejsca – z Windows 10 wypada coraz więcej przełomowych pomysłów, z których Microsoft po cichu się wycofuje.

Dziś, dla dobra ludzkości, Jim Allchin zajmuje się swoją inną pasją, jaką jest muzyka. Gra bluesa na gitarze, jego dotychczasowa dyskografia składa się z pięciu płyt. Na polu muzycznym udaje mu się osiągać branżowe sukcesy. Całkiem możliwe, że to dobra wiadomość przede wszystkim dla branży IT.