Wprowadzenie

Witam państwa w studiu i przed telewizorami. W dzisiejszym odcinku zapoznamy się z pewnym dawnym polskim oprogramowaniem - Edytorem Tekstów TAG. Programem-legendą, używanym przez pewien czas przez całą Polskę. Pokolenia rozpoczynające kontakt z komputerami mniej więcej w okolicach roku 2000 i później (a więc mowa o dawnych czasach) mogą nie mieć pojęcia o istnieniu TAGa. Wynika to z prędkości, z jaką rozliczne polskie edytory tekstów (tak jest, była ich cała radosna gromadka!) zostały zmiecione z powierzchni ziemi przez brutalnie rozprzestrzeniający się na rynku program Microsoft Word. Po wieloma względami Word był lepszym produktem, ale rodzimy TAG miał niewątpliwe zalety, które robiły szczególne wrażenie zanim w polskich realiach zagościł spolszczony Word.

Polowanie na wersję 3.16 opisałem na dobrychprogramach i nie chcę tutaj do niej wracać. Mam zamiar przybliżyć zwłaszcza młodszym czytelnikom funkcje dawnego edytora i zestawić je ze specyfiką czasu, w których powstały. Łatwiej będzie dzięki temu zrozumieć, dlaczego możliwości dziś uznawane za "niewidzialne" i naturalne, wtedy robiły wrażenie. Następnie zajmę się historią "post mortem" TAGa, czyli próbą odpowiedzi na pytania jak powstał i jak się skończył projekt "Edytor TAG". Mam w planach przygotować kilka tekstów na temat TAGa.

TAG jest, oczywiście, programem dla systemu MS-DOS. "Edytor, jaki jest, każdy widzi" zatem zacznijmy od innej kwestii, czyli z czym musiał mierzyć się w 1988 roku (wtedy powstała pierwsza wersja TAGa) programista, który chciał stworzyć program dla MS-DOS. Szczególnie w Polsce. Po niezbędnych wyjaśnieniach, wrócimy do naszego edytora.

DOS: koszmar programisty

Dziś zewsząd można pobrać za darmo bardzo rozbudowane środowiska programistyczne, jak Visual Studio od Microsoftu, albo przynajmniej wspomagające edytory z elementami IDE, jak produkty firmy JetBrains. Trzydzieści lat temu kompilatory były ekstremalnie drogim, specjalistycznym oprogramowaniem. Wielu programistów z tamtych lat kompilowało swój kod dokonując uprzedniej wyprawy na uczelnię lub nieliczne centra obliczeniowe, zaopatrzone w odpowiednie oprogramowanie. Zdecydowana większość jednak stosowała wszechobecne wtedy piractwo komputerowe. Oprogramowanie było zbyt drogie i trudne do zdobycia, by przejmować się prawami autorskimi, prawna kontrola własności intelektualnej nie istniała w Polsce tamtych czasów, a ogólna świadomość informatyczna nie sprzyjała zrozumieniu zjawiska piractwa i jego konsekwencji jeszcze przez wiele lat. Legalny zakup kompilatorów wymagał wydania astronomicznej ilości środków dewizowych oraz złożenia zamówienia u zagranicznego dystrybutora. Żelazna kurtyna była już wtedy cieniutka i poszarpana, ale to nie znaczy, że nie działała.

Zdobycie kompilatora umożliwiało rozpoczęcie prac nad rozwojem oprogramowania, ale pisanie programów dla systemu MS-DOS było bardzo trudne. Być może niekoniecznie trudne, ale na pewno wymagające. Dosowy programista musiał o wiele rzeczy dbać samodzielnie, ponieważ sam system dostarczał naprawdę bardzo mało API. Część z tych ograniczeń była niwelowana przez "ułatwiacze" i biblioteki wbudowane w kompilatory (dlatego między innymi były takie drogie!), ale oczywiście nie wszystkie. Na domiar złego, DOS był nie tylko surowy, ale i ograniczony: domyślnie obsługiwał tylko 640 kilobajtów pamięci. Fakt, wiele komputerów w dawnych latach nie miało szczególnie dużo pamięci, czasem nawet było to mniej, niż wspomniane 640KB, ale nie zmienia to faktu, że programista musiał mocno gimnastykować się, żeby rdzeń programu mieścił się pod tą niską granicą. Tworzenie wszelkich bardziej skomplikowanych i wymagających algorytmów bezsprzecznie równało się ciężkiej przeprawie pełnej pułapek i trudności. Nie wspominając już o takich cudach, jak programy działające w tle i wspólne bufory dla danych, znane dziś pod uroczą nazwą "schowek".

Wreszcie, MS-DOS oraz w ogóle oryginalna architektura IBM PC są kulturowo zorientowane na anglosferę. Cóż to oznacza? Rzecz jasna nie było to postępowanie zamierzone, ale podczas projektowania PC nie przewidziano obsługi międzynarodowej, a domyślnie obsługiwanym alfabetem był zbiór używany w USA. A jest on przecież pozbawiony wszelkich akcentów i innych ogonków. Ponadto, co było wtedy zupełnie oczywiste, a dziś uchodzi za piramidalne niedopatrzenie, stosowano kodowanie jeden bajt -- jeden znak. Bajt potrafi przechować jedną z 256 wartości. Sygnałów sterujących, symboli specjalnych oraz "amerykańskich liter" jest co prawda mniej, ale zbiór wartości do swobodnego zagospodarowania prędko okazywał się dość skromny i zdecydowanie niezdolny do sprostania wymaganiom wielu języków używanych na świecie. Rozwiązaniem, a właściwie protezą-zaślepką, tego problemu było wprowadzenie stron kodowych. Wybór strony kodowej oznaczał załadowanie odpowiadającego jej zbioru znaków do pamięci karty graficznej z wykorzystaniem narzędzia MODE.COM. Naturalnie, standaryzacja obsługi języka polskiego wymagałaby współpracy z PRL, w konsekwencji czego Polacy stworzyli własne strony kodowe. Niezgodne ze sobą. A nie znając strony kodowej używanej przez autora pliku tekstowego, nie dało się poprawnie wyświetlić symboli wykraczających ponad amerykański zbiór liter. Brzmi to jak bardzo poważna przeszkoda dla kogoś, kto chce stworzyć edytor tekstu.

Istniało więcej trudności - brak uniwersalnego standardu drukarek do użytku domowego, różnorodność rodzajów wyjścia kart wideo i kilka niezgodnych ze sobą fizycznych układów klawiatury, by wymienić najważniejsze z nich. Dzisiaj uznajemy każde z tych zjawisk za kompletnie oczywiste. Dysponujemy skalowalnymi wyjściami VGA, "świadomymi" swoich wymiarów, mamy uniwersalny sterownik drukarki (a jak nie mamy, możemy ją zawsze nakarmić PostScriptem), pamięci pod dostatkiem, kodowanie wielobajtowe Unicode obsługujące od polskich znaków, przez A z kółkiem aż po emoji z arbuzem i katakanę, a środowiska programistyczne niemalże piszą programy za nas. Ach, no i nie używamy już dyskietek. W porównaniu z tym, dawne czasy to męka.

To jest edytor na miarę naszych możliwości

TAG elegancko radzi sobie z każdym z tych problemów. Po pierwsze, oddziela warstwę hierarchii tekstu od warstwy edycji. Oznacza to, że ładując dokument do pamięci, najpierw otrzymujemy drzewiastą strukturę rozdziałów i dopiero po wybraniu rozdziału otrzymujemy tekst. Pilnując struktury tekstu sprawiamy, że zawsze do pamięci jest ładowany jedynie podzbiór całości, co ułatwia zmieszczenie się poniżej sufitu 640KB pamięci. Przy okazji dbało się o porządek opracowywanego tekstu. Strukturę rozdziałów można było oczywiście modyfikować, a samym sekcjom nadawać nazwy i tytuły.

Interfejs TAGa jest stworzony do obsługi za pomocą klawiatury, ale od trzeciej wersji mysz również jest obsługiwana. Skromne (w porównaniu z dzisiejszym Wordem) acz wystarczające menu górne pozwala na wybór kroju, czcionki, wyrównania linii i wymiarów kartki oraz na wstawianie linii, tabel i ilustracji. Możliwe jest aplikowanie wielu krojów i wysokości na różne fragmenty tekstu znajdujące się na tej samej linii. Nie była to wcale oczywistość. Rzuca się natomiast w oczy inna, bardzo sympatyczna cecha: domyślnie włączone jest pilnowanie wcięć na szycie. To ważna kwestia podczas pracy nad tekstem do książki.

Problem z drukarkami został rozwiązany poprzez zdefiniowanie kształtu glifu dla kilku najpopularniejszych rodzajów drukarek. Czcionki nie były bowiem wtedy wektorowe. Zresztą, dopiero Windows 3.1 wzbogacił się o obsługę wektorowych czcionek TrueType. Takie czcionki były wtedy bardzo drogie i rozprowadzane wyłącznie z zaawansowanymi programami do składu tekstu. Wymagały też więcej mocy obliczeniowej. TAG korzysta więc z czcionek bitmapowych, oczywiście brzydszych, ale możliwych do wykorzystania przez większą liczbę odbiorców. Działając na tańszych drukarkach i słabszych komputerach. Udało mi się wyekstrahować rastrowe czcionki TAGa i dokonać ich eksportu do formatu TTF. Są kanciaste i nieprzystające do dzisiejszych czcionek, mimo, że teoretycznie jako TrueType podlegają skalowaniu. Na kineskopowych, nierzadko monochromatycznych monitorach z przełomu lat 80/90 wyglądały jednak niewyróżniająco i typowo.

Format zapisu dokumentów stosowany przez TAGa jest binarny. To norma w tamtych czasach, niewynikająca (tylko) z prób zaciemnienia formatu i utrudnienia tworzenia konwerterów. Binarny format był po prostu mniejszy i mniej wymagający w przetwarzaniu, niż takie cudo, jak RTF. Takie twory, jak dzisiejszy DOCX, wytrzymujący próbę czasu już dziesiąty rok, na początku lat 90tych był nie do przyjęcia. Skompresowane wnętrze byłoby zbyt złożone dla słabych komputerów z kilobajtami pamięci. Z kolei format binarny można było ładować "tak, jak leży" - sposób najłatwiejszy do przetworzenia przez komputer. Zasada budowania pliku dokumentu TAGa wydaje się nie być szczególnie skomplikowana i możliwe było stworzenie podstawowego konwertera do HTML, czym zajął się pewien mój znajomy.

Nadchodzą okna

Wszystko jednak ma swój kres. Wraz z popularyzacją środowisk graficznych oraz systemu Windows 95, w których coraz rzadziej trzeba było wychodzić do DOSa, bo wszystkie potrzebne programy wzbogacały się szybko o warianty okienkowe. Tworzenie aplikacji na Windows było też o wiele łatwiejsze i szybsze, więc konkurencja rozwijała się dość prężnie. Stąd też pod koniec swego żywota, TAG powoli rozszerzał się o wersję w pełni graficzną. Ogłoszono ją na tylnej okładce ostatniej wersji dla systemu MS-DOS, o numerze 3.16, jako produkt będący w przygotowaniu.

Ten intrygujący epizod historii TAGa, wraz z kilkoma innymi ciekawymi detalami historycznymi, przytoczę w kolejnym odcinku.