Jak Microsoft chciał przejąć sieć Web – historia Internet Explorera, część III

Bardzo nudnej, bo mowa tu o DirectX. Pierwsze wersje IE zawierały kompletny komponent DirectX spakowany do olbrzymiego pliku CAB i próbowały bezwarunkowo instalować go w systemie. Wbrew pozorom, Explorer w ogóle nie używał DirectX do sprzętowego wspomagania. To nie te czasy – rysowanie stron przez silnik graficzny to wynalazek dopiero z okolic lat 2010. Bardzo mało elementów strony w jakikolwiek sposób przechodziło przez DirectX. Ale multimedia przechodziły już niemal w całości. Głównie dlatego, że natywna systemowa obsługa multimediów była dość nędzna (MCI). Z jakiegoś powodu, wersja 4.01 wyrzuciła instalator DX na poczet specjalnie okrojonego podzbioru, zawierającego wyłącznie DirectSound, DirectDraw (wraz z Clipperem i Ex) i dwie biblioteki Direct3D. Wielu gotowców, wykorzystywanych np. przez gry, w takim zestawie brakowało. Trudno powiedzieć dokładnie, dlaczego pozbyto się DirectX, być może zbyt mocno ingerował on w podsystem wyświetlania, może rozwijał się za szybko, a może po prostu 380MB instalatora przeglądarki internetowej zaczynało wyglądać niepoważnie. Istotnym brakującym puzzlem takiego mini-DirectX (DXMINI.CAB) był element DirectSound. Wgryzając się mocniej w strategię popularyzacji multimediów przez IE, może się to wydawać dziwne. Aż do momentu, gdy odkryjemy inny dodatek…

Wersja „Technical Preview” Internet Explorera 4.0 zawierała bardzo wczesne wersje plików CAB, które w dojrzalszych formach pojawiły się w wydaniach finalnych i poza kolejno ubijanymi podprojektami, towarzyszyły instalatorom IE przez następne 5 lat. Wśród nich można było odnaleźć jeden taki, który nijak nie pasował do układanki: IHAMRT.CAB. Nie zawierał żadnych plików, których nazwy pojawiałyby się później. W kolejnym wydaniu był pusty, a w finalnym zupełnie zniknął. Identyfikatory CLSID zwracały zero wyników w Google, a kolejne wersje Windows 9x nie znały takich klas w swoich gałęziach HKEY_CLASSES_ROOT. Nazwa rodzajowa biblioteki brzmiała „Microsoft Multimedia Controls”. Z tym, że pod ową nazwą kryje się dziś zupełnie inny produkt. Aby rozgryźć tę zagadkę, trzeba się nieco natrudzić. Na pewno nie należy pisać do człowieka, który pod powyższym CAB-em podpisał się imieniem i nazwiskiem. Pan Van Kichline po 21 latach awansował w Microsofcie na stanowisko menedżerskie, wiążące się ściśle z nieodpowiadaniem na maile od osób trzecich. Trzeba poszukać innych tropów. Na przykład spróbować załadować owe kontrolki i odpytać je o wyprowadzane funkcjonalności. Okazało się to jednak niemożliwe:

Przez wiele dni nie udało się znaleźć odpowiedzi na pytanie, czym jest IHAMR. Plik INF instalatora, zdradzający, że nazwa to tak naprawdę skrót od „Interactive ‘Project Hammer’ Runtime Libraries”, a jego autorem jest właśnie pan Kichline, nie mówił wiele więcej. Google też raczej nie było pomocne: przez dwadzieścia lat, liczba projektów o nazwie „Hammer” wzrosła dość znacząco, czyniąc wyniki wyszukiwania bezużytecznymi. Pozostało szukać wskazówek w bardziej brutalny sposób: wyciągnąć wszystkie łańcuchy tekstowe ze wszystkich plików składowych, znaleźć te brzmiące rozsądnie i karmić nimi Google’a aż do skutku.

Oczywistym kandydatem jest nagłówek pliku instalatora: „Microsoft Animation Theater”. Niestety, taka technologia nie istnieje. Nigdy nie wydano żadnego produktu ani komponentu o takiej nazwie. Samo „Animation Theater” to również samobójczo ogólna nazwa, ponieważ tak nazywa się jedna z sal konferencyjnych zjazdu SIGGRAPH, na którym Microsoft pokazywał inny komponent IE: program Comic Chat. Niniejsza korelacja kompletnie zanieczyszcza wyniki wyszukiwania.

Powyższe poszukiwania dały efekt dopiero po zapytaniu dotyczącym kontrolki „Microsoft Multimedia Sprite Control”. Właśnie ta fraza pada w książce zatytułowanej „Programowanie gier w języku Visual Basic dla nastolatków”. Fantastycznie – brzmi wreszcie jak mój poziom. Okazało się jednak, że to zwykła kolizja nazewnictwa, czyli taki sam problem, jak przy „Hammer”. Wyniki wyszukiwania przytoczyły jeszcze jeden wynik: niecierpliwe pytanie bezradnego ucznia, zadane siedemnaście lat temu na forum o języku Visual Basic 6.0 i pozostawione bez odpowiedzi. Wspomniany uczeń pytał o obsługę kontrolki Sprite Control (tej, której próby załadowania do IDE zakończyły się niepowodzeniem), ale podał… inną nazwę. Plik ‘daxctle.ocx’ jest już bardziej znaną nazwą i należy do zbioru AXA.CAB. Skrót „AXA” rozwija się naturalnie do „Zbiór klas języka Java dla komponentu DirectAnimation”.

To dopiero początek. Badana kontrolka nie ma bowiem nic wspólnego ani z Javą ani z DirectX. Java przypętała się tutaj, bo pakiet dostarcza wrappery pozwalające sięgać do DirectAnimation z poziomu JVM. A DirectX… No cóż, wszak chodzi o coś związanego z grafiką, co ma się stać popularne – lepiej nadać temu branding jakiejś znanej technologii.

Tymczasem DirectAnimation to zupełnie inne zwierzę. Paradoksalnie, jego nazwa mogła mu raczej zaszkodzić, przyciąga bowiem skojarzenia związane z renderowaniem grafiki 3D, a przecież zupełnie nie o to chodzi. Krótko mówiąc, jest to odpowiedź na Flasha, głównie pod kątem animacji wektorowych. Ten krzywdząco skrócony opis nie oddaje jednak natury środowiska, którego przedstawienie wywoła nieuniknioną lawinę nazw innych niezwykle ambitnych, ale zarazem rozczarowujących, wymarłych i antycznych produktów z Redmond. Zacznijmy od ogłoszenia z grudnia 1997, przedstawiającego nowy projekt jako element DirectX, dostarczający obsługę dwu- i trójwymiarowej grafiki wektorowej, animacje i przekształcenia obiektów, ścieżek i krzywych oraz rozbudowane środowisko programistyczne. Niniejszy komplet cech powinien brzmieć swojsko dla każdego, kto kiedykolwiek dotknął Flasha. Mając świadomość, jak bezkonkurencyjny był przez wiele lat Flash i ile lat zajęło mu godne odejście, jest to tym bardziej interesujące.

Doniosłe ogłoszenie premiery DirectAnimation obfitowało w entuzjastyczne „zeznania świadków”, z wigorem opisujących jak wspaniałą inwestycją okazało się zaangażowanie w ową technologię. Magia marketingu polega jednakże na tym, że tego typu deklaracje są częste, ale bardzo rzadko cokolwiek z nich wynika. Na szczęście, artykułowi towarzyszył odnośnik do SDK narzędzia DirectAnimation. Adres prowadzi do czarnej dziury już od wielu lat, a archive.org od kilku tygodni ma straszne problemy, żeby cokolwiek z niego załadować. Na stronach MSDN i Technetu istnieją jakieś strzępy i przykłady, trudne do złożenia w wartościową całość, na szczęście jest jeszcze jedna droga. Pakiet SDK dla DirectAnimation został wydany na płycie z dokumentacją do środowiska Visual Studio 6.0.

Tu chwila na osobistą dygresję, bowiem mogę się uznawać za szczęściarza: podczas gdy inne dzieci dostawały na urodziny zegarki, rowery, narty i inne bezużyteczne przedmioty, ja dostałem pakiet Visual Basic 6. Głębsze poszukiwania na płytach z dwudziestoletniego pudełka pozwalają odnaleźć zbiór stron WWW składających się na przewodnik, SDK oraz próbki programistyczne.

Prędko wychodzi na jaw, że z DirectAnimation rozmawia się przy użyciu taga OBJECT, podając odpowiedni identyfikator klasy (CLSID) z Rejestru Windows. Pole „classid” jest oczywiście całkowicie nieprzenośne, zależne od systemu i wręcz nieobsługiwane w HTML5, ale jak się okazuje, DirectAnimation wylądowało na śmietniku tak szybko, że z jego poprawnym wyświetleniem ma problem już nawet Internet Explorer 6 z systemu Windows 2000. Paradoksalnie, lepiej poradzi sobie Firefox. Próbki i przykłady naturalnie nie działają i poza próbnym kodem naprawdę trudno o jakiekolwiek przykłady produktów tworzonych z użyciem DirectAnimation. Nawet YouTube milczy i kilka nielicznych próbek można wyciągnąć ze stworzonej kilkanaście lat temu, kiepskiej prezentacji o wątpliwej jakości merytorycznej (o estetyce nie wspominając). To przykre.

Narzędzie Microsoftu wydaje się nieco uboższe od zestawy dostarczanego przez firmę Macromedia (czyli późniejszego Flasha), ale środowisko programowania było znacznie bliższe użytkownikowi, przyjaźniejsze i – wszystko na to wskazuje – tańsze. Visual Studio InterDev nie wydaje się być szczególnie dostosowany do tworzenia stron multimedialnych, ale jaki FrontPage już usiłuje sugerować, że „bogate, interaktywne strony internetowe” są w zasięgu ręki. DirectAnimation istotnie wymagał IE i nie działał poza nim, ale nie to wydaje się powodem jego braku popularności. Nie chodzi też o całą feerię luk w zabezpieczeniach, oczywiście obecnych w stosie AXA. Po prostu na świecie nie było miejsca na aż tak wiele silników rysujących multimedia. VRML się nie przyjął, Real zagarnął strumienie, Flash wektorowe animacje, a do wszystkiego bardziej skomplikowanego pozostawała Java. Mimo wielu miesięcy ciężkiej pracy, produkt okazał się zbędny.

To częsty los wielu projektów informatycznych. Niestety, z powodów ambicjonalnych, branża bardzo powoli uczy się pokory i woli „litościwego uśmiercenia” inicjatyw skazanych na porażkę. Dzisiejszy Microsoft ma z tym o wiele mniejsze problemy niż ten z czasów powstania DirectAnimation. Dlatego mimo braku popularności frameworku do animacji, niepodobieństwem byłoby porzucić jego rozwój. W ten sposób powstał program Microsoft Liquid Motion, pozwalający tworzyć animacje zakorzenione skryptowo w dynamicznym HTML, a celem „ożywiania” treści, sięgający do Javy. Liquid Motion uchodzi za rzadkość i ciekawostkę, ale mimo to został przemianowany i dołączony jako równoprawny element pakietu Office 2000, pod nazwą Vizact.

Vizact, produkt płatny, najwyraźniej również nie został zakupiony przez ani jedną osobę, skutkiem czego jego rozwój, usłany przejęciami i burzliwymi przebudowami, wstrzymano. W ostatnich chwilach swojego istnienia, formuła tworzenia animacji oparta o rozszerzenia skryptowe, zwana „HTML+TIME”, została ujęta jako zgłoszenie standaryzacyjne W3C. Z względu na strumień porażek, Microsoft przybrał swoją grzeczną postać i wspomniane zgłoszenie przesłał jako pracę zbiorową wraz z firmą Macromedia. Będąc z definicji konkurentem dla technologii Microsoftu, Macromedia zaskakująco często splatała z nimi swój los. Internet Explorer dostarczał jej wtyczki, jednocześnie tworząc własne rozwiązanie. Kolejny raz dowodzi to faktu, że przedsiębiorstwa to nie gangi i nie warto się obrażać, bo to się zwyczajnie nie opłaca.

Jednakowoż, HTML+TIME oraz jego osnowa, czyli SMIL, wypadły z Internet Explorera wraz DirectAnimation i Javą. Czystkę przetrwał, niczym karaluchy, tylko Flash. Jest to niezwykle zabawną i pouczającą lekcją biznesu.

Ostatnia niespodzianka z czeluści instalatora to pakiet Interactive Music. On również na przestrzeni wersji ulegał poważnym przekształceniom. Kontrolka OCX dla elementu „Microsoft Interactive Music Control” również rozpoczęła swoją cichą karierę jeszcze w czasach wersji trzeciej Internet Explorera. Odpowiada za odtwarzanie plików muzycznych, stworzonych w formacie opartym o technikę wavetable, znaną zapewne twórcom muzyki. Cyfrowy sampling wavetable polega na odwzorowaniu danego dźwięku poprzez jego uogólnioną postać falową (waveform). Wyłożenie różnic między syntezą opartą o próbki, a syntezą wywiedzioną z tablic nie jest skomplikowane, ale składałoby się na zbyt dużą dygresję. Na nasze potrzeby, wspomniany mechanizm wystarczy nazwać „mądrzejszym MIDI”. Przybliżenie natury działania technologii Interactive Music będzie o wiele łatwiejsze, gdy posłużymy się przykładem praktycznym. Zajrzyjmy do książki „Dynamic HTML in Action”, dostępnej dziś online. Rozdział 18-9 dotyczy właśnie mechanizmu Interactive Music Control.

Dzieło stworzone w IMC to oczywiście po raz kolejny element „OBJECT”, wskazujący na odpowiednią klasę w Rejestrze Windows. Urokliwy numerek „D2377D41-E6FD-11CF-8DCF-00AA00C01802” przyjmuje z kolei zbiór parametrów-konstruktorów, składających się na cechy tworzonego obiektu z muzyką: kontrola, sekcja, styl, osobowość, zespół i motyw. Podczas gdy te pierwsze są raczej programistycznymi narzędziami do kontroli, pozostałe składają się na elementy utworu muzycznego. Rozłożenie muzyki na tak elementarne części składowe pozwala kontrolce Interactive Music pobierać jedynie malutkie pliki z definicjami tempa, instrumentów, głosów, przejść itp. Muzyka była składana z nich na tej samej zasadzie, na jakiej artysta interpretuje zapis nutowy. Następnie, wyizolowane elementy muzyki były wysyłane jako żądania do procesora dźwiękowego, który rozwiązywał równania syntezy fali i produkował wyjściową muzykę.

Jakie są zalety tak horrendalnie skomplikowanego sposobu odtwarzania dźwięków? Cóż, przede wszystkim należy pamiętać, że wygląda to na skomplikowane tylko dla nas. Obliczenie równania fali jest dla komputera o wiele łatwiejsze, niż załadowanie splotu kodeków, a następnie strumieniowe dekodowanie wielomegabajtowego ciągu binariów. Prosty, acz kompletny wavetable będzie więc o wiele tańszy obliczeniowo, niż najsłabszy kodek. I mimo, że dźwięk zakodowany w MPEG będzie wszechstronny, w przeciwieństwie do zamkniętego zbioru dźwięków z Interactive Music, istnieją scenariusze w których owa wszechstronność jest zwyczajnie zbędna.

Jeżeli jednak okaże się, że paleta dźwięków udostępniana wskutek manipulowania tablicami postaci falowych jest zbyt ograniczona, Microsoft oferował „krok pośredni” między kontrolką IMC a pełnym, zwyczajnym plikiem dźwiękowym typu MP3. Opcjonalny komponent „Microsoft Synthesizer” rozwiązuje kwestie braku elastyczności opisywanego modelu, poprzez dostarczenie obsługi programowych, predefiniowanych krótkich próbek (sampli). Jeżeli możliwości programistyczne Interactive Music są zbyt ograniczone i stworzenie odpowiedniego dźwięku okazuje się niemożliwe w użyciem mikroskopijnych definicji „osobowości” i „stylu”, można zażądać pobrania własnej biblioteki sampli (DOODLS), a następnie komponować utwór z jej użyciem. Syntezator dostarczał też własny, wstępny zbiór sampli licencjonowany od firmy Roland, czyli niesławny plik „GM.DLS” naszpikowany kilkoma setkami niezależnych próbek w formacie WAV. Pogardzany przez profesjonalnych twórców muzyki, GM.DLS był czymś na kształt „czcionki dźwiękowej” (soundfont) w wykonaniu Microsoftu.

Nikt raczej nie angażował się budowanie własnych bibliotek sampli zgodnych z kontrolką Interactive Music. Jeżeli ktoś chciał robić muzykę na poważnie, i tak korzystał z bardziej profesjonalnych zestawów, dostarczających również własny syntezator. Uniwersalna postać Microsoft Synthesizera, rejestrującego się przecież w systemie jako kodek, źródło o raz wyjście dźwięku, okazała się jednak zaletą. Ów programowy syntezator stał się wkrótce potem wbudowanym elementem Windows, niezależnym od rozwoju Internet Explorera. Jeżeli karta dźwiękowa okazywała się kiepska (a nie ukrywajmy, że było to jednak powszechne w dobie zintegrowanych układów PCI bez pamięci, kosztujących coś koło 10 dolarów), Windows ładował swoje predefiniowane próbki. Odtwarzał nimi również pliki MIDI, które dzięki temu przez wielu ludzi były uznawane za kiepski, spłaszczony i zabawkowy format dźwięku – z owego przekonania wyjść można było jedynie usłyszawszy MIDI skomponowane za pomocą porządnej karty dźwiękowej a nie programowego syntezatora.

O ile syntezator zaczął żyć swoim własnym życiem, Interactive Music prędko rozpłynął się w mrokach dziejów. Jego niewątpliwa zaleta, w postaci oszczędzania mocy obliczeniowej oraz – być może przede wszystkim – transferu!, okazała się nie być wystarczająca, by IMC zostało z nami na dłużej. Bardzo rzadko zdarzało się by strony internetowe załączały jako obiekt element odtwarzający muzykę w owym formacie. O wiele częstsze było żądanie załadowania kompletnej kontroli WMP.DLL, nadania jej rozmiaru 1,1 i załadowania całego utworu muzycznego do środka. Później oczywiście ową rolę zaczął pełnić nieszczęsny Flash. Aż do momentu popularyzacji HTML5 i znacznika „audio”, spełniającego swoją rolę doskonale zwłaszcza po osiągnięciu globalnego kompromisu w kwestii kodeków (WebM).

Spadek techniczny po IMC odziedziczyło DirectX oraz jego komponent DirectSound, czyli inteligentny, programowalny mikser o zaletach oszałamiających jak na połowę lat dziewięćdziesiątych. Dziś są one jednak naturalne i procesem odpowiedniego mieszania dźwięków na stronach internetowych zajmuje się bezpośrednio przeglądarka internetowa. Interactive Music wypadło ze źródła instalacyjnego IE w 1999 roku, a wraz z Vistą zakończyło swój żywot na tym niewdzięcznym i głuchym na jego zalety świecie.

Na tym można by w zasadzie zakończyć historię Internet Explorera. Powyższy zbiór zamyka bowiem zestaw technologii opracowanych dla owej przeglądarki, przechodząc szczegółowo po wszystkich paczkach instalatora przeglądarki. W ten sposób można jednak ominąć jeden niepozorny element, który prawdopodobnie w największym stopniu wpłynął na kształt dzisiejszego Internetu. Nie miał on swojej nazwy, nie pojawiał się jako oddzielna pozycja na liście wyboru i w dodatku instalował się wyłącznie na Windows 95, nowsze wersje zawierały go już bowiem jako element środowiska MDAC, a nie przeglądarki, żyjący sobie cicho w katalogu WINDOWS\SYSTEM. W ostatniej części zajmiemy się przybliżeniem kiepsko reklamowanych funkcji Internet Explorera w wersji 5.0. Nijaka i zapomniana „piątka” dostarczyła narzędzia do tworzenia sieci Web 2.0, ale w momencie ich powstania nikt ich nie zauważył lub nie zdawał sobie sprawy z długofalowych konsekwencji.