Ostatnim zagadnieniem, które chcę poruszyć w serii artykułów na temat Edytora TAG, jest kwestia archiwizacji oprogramowania. Jest to temat, któremu poświęca się zdecydowanie zbyt mało uwagi, prawdopodobnie ze względu na brak namacalności software'u. Niekoniecznie intuicyjnym jest bowiem, że oprogramowanie może bezpowrotnie zaginąć. Nieoczywiste są również konsekwencje takiego zaginięcia.

Mamo, czy oprogramowanie idzie do nieba jak zakończy swój cykl życia?

Po co archiwizować oprogramowanie? Zacznijmy od tego, że prawdziwym pytaniem jest tutaj "dlaczego należy traktować oprogramowanie jako potencjalny artefakt historyczny". Brzmi ono może mniej porywająco, niż poprzednie, ale zadane w ten sposób, ułatwi znacząco dotarcie do meritum. A więc skąd na przykład w portalu BetaArchive tyle pieczołowitości w gromadzeniu archiwów i wręcz kronikarskiej skrupulatności w przygotowywaniu nowych "eksponatów"?

Internet przyzwyczaił nas do informacyjnego i technologicznego urodzaju. To z kolei doprowadziło do powszechnego przekonania, że wiele codziennych rozwiązań jest oczywistych i że zostaną z nami raz na zawsze. Przytoczmy prozaiczny przykład: tworząc listę zakupów w Wordzie (lub programie OneNote, jak porządni ludzie) nie zastanawiamy się, czy uda się nam ją otworzyć za 20 lat. Po pierwsze dokument jest mało istotny, a po drugie - zawsze ktoś gdzieś ma Worda. A nawet, gdy jakimś cudem nikt wokół go nie posiada, pozostaje LibreOffice lub Office w darmowej wersji online. Programów nie archiwizujemy zatem dla ozdoby, a po to, by móc w przyszłości otwierać zapisane w nich dokumenty. Praktyka dowodzi jednak, że często nie archiwizujemy, bo nawet przez myśl nam to nie przechodzi.

The Paradox of Plenty

Nonszalanckie spojrzenie na dostępność oprogramowania wynika z przekonania, że nie istnieje siła na tym świecie, która pozbawiłaby nas np. Worda. Tymczasem owa postawa była, jest i pozostanie, ze zmiennych powodów, wysoce błędna. Dawne programy zniknęły z powierzchni ziemi, wiele ich formatów zapisu plików, a czasem zapisu całych nośników, było nieudokumentowanych, a oryginalne dyski instalacyjne, z powodu magnetycznej nietrwałości, uległy erozji. Z kolei dzisiejszy Word (nie uwolnię się teraz od tego nieszczęsnego przykładu) rozpoczyna - jeszcze bardzo powolną - ucieczkę w chmurę. Pełna popularyzacja modelu "Software-as-a-Service" doprowadziłaby jednak z czasem do utraty dostępu do danych wraz z upadkiem dostawcy usługi.

Obecne czasy mogą się nam dziś jawić jako apogeum nowoczesności, ale jeżeli wszystko pójdzie, jak należy, za setki lat będą rozpatrywane jako dawne dzieje. I na tej samej zasadzie, jak nieodszyfrowany do dziś Manuskrypt Wojnicza, nasze dzisiejsze pliki, zapisane w niszowych formatach, staną się mało zrozumiałym ciągiem bajtów - zwłaszcza, gdy nieobecne będą poszlaki wskazujące na to, czego szukać. Wtedy najsilniejszy komputer nie odkoduje formatu zapisu. Nie trzeba nawet czekać setek lat - wspomniane zjawisko zachodzi już teraz. Taśmy magnetyczne z zapisem przebiegu operacji marsjańskiej Viking okazały się niemożliwe do przetworzenia, bo format zapisu był nieznany, a taśmy - podatne na działanie środowiska. Oryginalne zapisy lądowania na Księżycu (czegoś, co brzmi, jak ważne wydarzenie) również zaginęły, a w pewnej części zostały bezrefleksyjnie nadpisane inną zawartością.

Dziś jest oczywiście łatwiej, niż kiedyś. Na przykład obecne dokumenty Worda (ech…) są skompresowanym plikiem, zawierającym wewnątrz zbiór plików XML. Taki format jest samo-wyjaśniający się i możliwy będzie powrót do oczekiwanej treści również po śmierci Worda. Gorzej jest jednak z jego starszą wersją, na przykład 6.0. Produkowała ona ni mniej ni więcej, jak binarny blob, o którego formacie trzeba sporo wiedzieć, chcąc uzyskać z niego treść. Wyżej wymienione zjawiska pozwalają wysnuć konkluzję, że zaniechanie archiwizacji oprogramowania może łatwo doprowadzić do odcięcia nas od materiałów historycznych. I może to mieć miejsce zarówno za 300 lat, jak i za dwa tygodnie. Ale to nie jedyny powód.

Projektowanie interfejsów użytecznych

Pomówmy przez chwilę o systemie Windows 95. Wprowadzono w nim kilka legendarnych elementów interfejsu, które dziś uchodzą za całkowicie naturalne i nieodzowne, takie, jak pasek zadań. Poprzednia wersja okienek, Windows 3.11, nie miała paska zadań ani łatwej do wywołania listy okien. Kombinacja Ctrl-Esc przywoływała Menedżera Zadań, ale niskie discoverability takiego rozwiązania często sprawiało, że biurowe komputery tonęły w tuzinach otwartych, a następnie zgubionych okien pasjansa. Wydawałoby się zatem, że poprzednie-złe rozwiązanie po krótkim przemyśleniu zastąpiono nowym-dobrym. To przekonanie okazuje się mocno chybione, gdy spojrzy się na kształt form pośrednich między Windows 3.11, a Windows 95, czyli wszelkie wersje beta projektu Chicago. Prędko wychodzi na jaw, że pasek zadań wcale nie był oczywistym rozwiązaniem, które natychmiast przychodzi do głowy. Zanim opracowano końcową jego postać, przewinęło się wiele projektów roboczych, z których niemała część była wręcz bezsensowna, a ich afunkcjonalność nie brała się żadną miarą ze zwykłego niedokończenia. Po prostu pasek zadań jest oczywisty dopiero, jak już się go wymyśli. Zanim dobrnie się do tego etapu, powstaje kilkanaście postrzelonych prototypów i nagrywa się tuziny drobiazgowo opracowywanych filmów z grupą kontrolą, testującą kolejne warianty. Bez zarchiwizowanych wariantów projektu Chicago, wiedza na temat naukowej metody dotarcia do ergonomicznego rozwiązania problemu przełączania zadań zaginęłaby. Jedyną informacją pozostałoby "firma Microsoft zaprojektowała Pasek Zadań Windows z wykorzystaniem wytycznych dyktowanych przez osiągnięcia ergonomii i badań w zakresie interfejsów użytecznych". Lub coś w tym rodzaju.

Interfejs TAGa opiera się na rozdziale warstw hierarchii i edycji. "U góry" edytuje się podział tekstu na części, a "pod spodem" dopiero pisze się tekst. Tworzenie oprogramowania, w którym taki podział jest obecny od samego początku, wynika nie tylko z obranego pomysłu na pracę z tekstem, ale także ze sposobu obchodzenia ograniczeń pamięci - w tym przypadku buforów 16-bitowych i szklanego sufitu tzw. "górnego obszaru pamięci". Zrozumienie obu tych kwestii będzie o wiele trudniejsze bez samodzielnej pracy z programem zaprojektowanym z uwzględnieniem powyższych kwestii. Nie wszystko da się w prędki i łatwo przyswajalny sposób przedstawić wyłącznie tekstem i zrzutami ekranu. Projektowanie interfejsów ergonomicznych w sposób oparty nie na modzie (UX), a na nauce (UI) wymaga znajomości dziedziny, w której się projektuje. Wiedzą to prawdziwi fachowcy: niezastąpiony Marcin Wichary, nazywający się "typografistą", pogłębia swoje wykształcenie poprzez badanie historii klawiatur. Jego nadchodzącą, pasjonującą książkę można zobaczyć tutaj. Niestety nie wszyscy pracują tak, jak pan Wichary i badanie dawnych wzornictw projektowych u wielu samozwańczych-acz-nie-samozatrudnionych specjalistów uchodzi za przeżytek i stratę czasu.

Oprogramowanie jako wytwór kultury

Ukrytych oczywistości w dawnym oprogramowaniu jest więcej. Jedna z nich jest fantastyczna i myślę, że jej przytoczenie pozwoli dostrzec aspekt kulturowy w procesie projektowania interfejsów. Oto przykład: jak wygląda ikona wyszukiwania? To proste - jak lupa. Zawsze i wszędzie. Ale dlaczego lupa? Bo jest uniwersalna! Owszem, ale czy to na pewno dlatego? Jest kilka innych, nie mniej uniwersalnych ikon, jak lornetka albo latarka. Były nawet wykorzystywane w oprogramowaniu (np. w Microsoft Office Find Fast). Więc może chodzi o to, że lupa dobrze wygląda w pomniejszeniu? Zapewne. Ale proszę zwrócić uwagę na co innego. Obiecuję, że zaraz wrócimy do meritum. Oto ikona wyszukiwania w systemie Mac OS 8. Narzędzie wyszukiwania nazywa się "Sherlock". Gdy zechcemy wyobrazić sobie, przefiltrowany przez popkulturę, wizerunek detektywa Sherlocka Holmesa, prawdopodobnie otrzymamy postać w (kraciastym?) peleryno-płaszczu, z fajką, charakterystyczną czapką i właśnie lupą.

Postać detektywa-poszukiwacza, uosabiana w anglosaskiej kulturze właśnie z Holmesem, zamyka naszą wyobraźnię w pewnej niezauważalnej konwencji, od której trudno uciec. Co przedstawia ikona wyszukiwania w TAGu? Otóż… kaganek. Ze świeczuszką. Wygląda on zaskakująco dobrze i rozpoznawalnie w (sporym przecież) pomniejszeniu i od razu kojarzy się nam z wyszukiwaniem. Bo niesiemy kaganek, oświaty lub nie, świecąc, aby łatwiej coś znaleźć, albo przynieść gdzieś metaforyczną światłość i wiedzę.

Nie mówię tu, że kaganek jest lepszą ikoną wyszukiwania, niż lupa. Prawdopodobnie nie jest. Pozwala nam jednak zwrócić uwagę na to, że ikona lupy mogła do nas przybyć z kultury anglosaskiej, a nie tylko z wzorniczej wygody. Gdyby internetowa eksplozja miała swoje źródło w Polsce, a nie w USA, możliwe, że ikona wyszukiwania wyglądałaby inaczej. Myślę, że identyfikowanie źródeł kulturowych w procesie projektowania interfejsów użytecznych jest wartościową wiedzą socjologiczną.

Bit Rot

Wreszcie docieramy do meta-powodów motywujących archiwizowanie oprogramowania. Zakładając, że przyjęliśmy argumenty za archiwizacją, bowiem mamy do czynienia artefaktami historycznymi, zwróćmy uwagę na detal do bólu praktyczny: nośniki. Nie wystarczy bowiem skopiować samych binariów. Większość software'u instaluje się z konkretnych źródeł. Sieciowe punkty instalacyjne, w których po prostu żywcem leżą pliki, które można rozrzucać po komputerach w sieci, to w przypadku starszego oprogramowania nadmiar luksusu. Zazwyczaj potrzebny jest nośnik lub jego wierny zrzut binarny, w formie 1:1. Dyskietki magnetyczne są medium wrażliwym, w dodatku ulegającym samoistnej erozji wraz z czasem (bit rot). Jest to zjawisko o wiele wolniejsze w przypadku tłoczonych płyt i zupełnie niedefiniowalne dla instalatorów chmurowych. Owa nietrwałość zmusza do wykonywania kopii archiwalnych takich nośników. Ponadto, niektóre programy stosowały mechanizmy kontroli kopiowania, wykorzystujące nieregularności w formatowaniu nośnika. W takich przypadkach konieczne są zrzuty bardziej szczegółowe, niż binarny, a więc zawierające informacje o strukturze logicznej, czy wręcz własnościach powierzchni. Stąd bierze, nierzadko groteskowa, skrupulatność w procesie tworzenia archiwów oraz przyjmowania nowych egzemplarzy do kolekcji.

I present to you, Taneleer Tivan, the Collector!

Praca twórcza wykonana w ramach produkcji oprogramowania nie ogranicza się więc wyłącznie do końcowego etapu, czyli działającego kodu wykonywalnego. Zachowanie wyłącznie działającej (pod pewnymi warunkami) kopii programu i niezadbanie o wszelkie pozostałe elementy doprowadza bezsprzecznie do utraty potencjalnie cennej wiedzy historycznej. Dlatego archiwizacja TAGa będzie się składać z wielu elementów:

  • Zrzuty binarne 1:1 nośników instalacyjnych. TAG nie stosował zabezpieczenia przed kopiowaniem, więc zrzuty surowe są wystarczające. Ich zastosowanie nie wiąże się z istotną utratą informacji. Tymczasowo dostępne tutaj. Dostępne są wersje 3.12 i 3.16, w formie obrazów dyskietek 3½ cala wysokiej gęstości (1440 KB) i 1.51, w formie obrazu dyskietek 5¼ cala podwójnej gęstości (360KB).
  • Skompresowane foldery z zainstalowanym katalogiem roboczym TAGa dla wersji, których oryginalne nośniki zaginęły. Tak zainstalowana wersja jest jednak dostosowana do sprzętu komputerowego, na którym przeprowadzono instalację i może np. usiłować użyć sterownika graficznego HGC zamiast EGA. Tymczasowo dostępne tutaj. Dotyczy wersji 2.02, 2.04 i 2.07. Dotychczas nie odnaleziono nośników instalacyjnych dla serii 2.x. Była rozprowadzana na nośnikach 5¼.
  • Uruchamialna wersja online programu TAG, celem zapoznania z interfejsem użytkownika. Do samodzielnego przetestowania tutaj, w ramach zadania domowego :)
  • Wyekstrahowane rastrowe czcionki, zapisane w formacie czcionek wektorowych oraz narzędzie użyte do stworzenia plików TTF. Wkrótce kolejna próba uzyskania wyższej jakości.
  • Eksporter formatu zapisu TAG, pozwalający na zapisanie dawnych plików w wyjściowym formacie TAG, z zachowaniem formatowania, autorstwa MCbx
  • Logotypy i grafika
  • Podręcznik użytkownika oraz pudełko (zdjęcia i skany - jeszcze niedostępne)
  • Wierny remake interfejsu programu TAG, używający rastrowego UI, stworzony w nowoczesnym, przenośnym języku programowania (proszę trzymać za mnie kciuki)

Dobranoc

Powyższy spis składa się na wykaz źródeł pozwalających na najbliższe zapoznanie się produktem, również pod kątem użytej technologii, narzucanych ograniczeń, decyzji projektowych i kulturowych. Dzięki temu możliwe staje się nie tylko odtworzenie dawnych danych, ale i świadome poznanie historii oprogramowania.

Wkrótce (mam nadzieję) kolejny odcinek! Po stosownym opracowaniu, kolejnym programem będzie edytor QR-Tekst.

Edytor tekstów TAG jest dostępny do pobrania w sekcji "Programy": https://stare.pro/app/10-tag/