Czyli słów kilka o Amiga Guide
Nie będzie niczym odkrywczym, gdy powiem, że komputery Amiga były super, miały ciekawe i wyjątkowe rozwiązania. Historia marki to temat na kilka osobnych artykułów (zarówno wychwalających jak i ganiących). Dziś jednak nie o tym. Chciałbym Wam pokazać rozwiązanie, które powstało około 1991 roku wraz z pojawieniem się systemu AmigaOS 2.1.
Zacznijmy jednak od początku (jak mawiał klasyk), byście złapali kontekst. Rok 1985 to moment pojawienia się Amigi 1000. Na początku było to rozwiązanie naprawdę ciekawe jak na tamte czasy, ale też nietypowe. Amigi miały inną architekturę sprzętową i odmienny system operacyjny.
Pamiętajcie, że był to prawdziwy system operacyjny, a nie graficzna nakładka na „coś”, jak to było w wypadku np. komputerów PC (MSDOS+Nakładka graficzna MSWindows). Potem Amiga zmieniła się, także ze względów kosztowych. O ile Amiga 1000 była typowym desktopem, a więc skrzynią (chociaż smukłą i leżącą) plus klawiatura, to już kolejne modele, jak Amiga 500, Amiga 600 czy Amiga 1200, były komputerami „schowanymi” pod klawiaturą.
Jednak niezależnie od wersji, trzonem Amigi był jej niebagatelny system operacyjny, mający coś, o czym inni mogli tylko pomarzyć: wielozadaniowość. Nie w procesorze, a w systemie operacyjnym!
W czasach, gdy większość komputerów domowych wykonywała jedno zadanie naraz, Amiga od początku (1985!) miała wbudowany preemptive multitasking. Wyglądało to tak, że programy, a nawet części systemu, „rozmawiały” ze sobą:
Aplikacja 1: „Ze mną wszystko OK, możesz mnie przerwać.”
AmigaOS: „OK, dziękuję, teraz poproszę o pracę aplikację 2, potem możesz kontynuować.”
Aplikacja 2: „Spoko, zabieram się do pracy.”
Takie rozmowy (no dobrze, nie dosłownie takie) odbywały się setki razy na sekundę. W efekcie nie było problemu, by jednocześnie wyświetlać obraz (nawet animację), w tle odtwarzać muzykę, oczekiwać na wciśnięcie klawiszy, ruchy myszą czy reakcję joysticka. W tym samym czasie z dyskietki dogrywane były materiały potrzebne później. Dodatkowo dało się (bez zająknięcia) przechodzić z warstwy aplikacji pełnoekranowej do systemu operacyjnego.
Dzisiaj wydaje nam się to normą, ale wtedy to było prawdziwe novum, graniczące z magią. Sercem AmigaOS było jądro Exec — lekkie, szybkie i napisane tak, by działać nawet na 256 KB RAM.
Procesy (taski) miały:
• własne priorytety,
• kolejki gotowości,
• system sygnałów do komunikacji.
Co ciekawe, AmigaOS był mikroskopijny w porównaniu do dzisiejszych systemów. A mimo to potrafił to, czego np MS Windows „nauczył” się robić stabilnie dopiero lata później.
Jednak różowo nie było. AmigaOS nie miał pełnej ochrony pamięci, programy mogły nadpisywać pamięć wzajemnie, a crash jednego zadania mógł zawiesić cały system. To był trochę sport ekstremalny. Ale jaka wolność!
W świecie stacji roboczych (np. systemy UNIX) multitasking już istniał, ale były to drogie maszyny akademickie. Amiga przeniosła tę ideę do domowego salonu. Poniżej różne wersje wizualne systemu os 3.1 (źródło: internet)
Sam system operacyjny — nawet tak dobrze skrojony jak AmigaOS — nie mógł jednak istnieć w próżni. Potrzebował oprogramowania użytkowego. A to z biegiem lat pięło się w górę. Rosły możliwości, rosła złożoność, a wraz z nią… potrzeba informacji, jak to do jasnej cholery działa! Poniżej kilka aplikacji (źródło: internet)
Instrukcje drukowane przestawały wystarczać. Programy stawały się bardziej rozbudowane. Trzeba było w jakiś sposób ujednolicić sposób przekazywania wiedzy użytkownikowi — tak, by była pod ręką, zawsze aktualna i wygodna.
A wraz z rosnącą złożonością rosła też potrzeba wyjaśniania. Bo co z tego, że masz narzędzie, skoro nie wiesz, jak użyć połowy jego funkcji?
Internet? W teorii już istniał. W praktyce — dla zwykłego użytkownika domowej Amigi (czy innego komputera) był czymś równie dostępnym jak podróż na Marsa i drogim. Świat Amigi potrzebował czegoś pomiędzy książką a programem. Czegoś, co żyje razem z aplikacją.
Amiga dostała coś znacznie bardziej eleganckiego.
AmigaGuide
Czysty plik hipertekstowy. Bez zbędnych ozdobników. Bez ciężkich silników. Bez powolnej Javy i innych „dobrodziejstw” przyszłości. Prosty tekst, który potrafił być interaktywną dokumentacją, systemem pomocy, a nawet miniaturową bazą wiedzy. I to wszystko w 1991 roku.
- Klikasz słowo i przenosisz się do innej sekcji.
- Wracasz.
- Skaczesz dalej.
To było coś niezwykle nowoczesnego jak na 1991 rok. W czasach, gdy Windows dopiero kilka lat później zacznie popularyzować swoje pliki *.hlp, Amiga miała już system dokumentacji oparty na idei, która dziś wydaje się oczywista.
I co najciekawsze to wszystko było lekkie. Prostota rozwiązania, to jedno, ale możliwość rozbudowy systemu o kolejne elementy współgrające z OS to już była zupełnie inna liga.
AmigaGuide mógł korzystać ze zmiennych systemowych, poleceń ARexx (czyli skryptowego języka programowania obecnego w AmigaOS), a także dynamicznie wywoływać programy. To powodowało, że nie był wyłącznie systemem dokumentacji. Mógł stać się szkieletem instalatora, interaktywnego menu, a nawet całej publikacji. W tym formacie powstawały magazyny dyskietkowe — ziny, które były czymś pomiędzy czasopismem a aplikacją.
ARexx pozwalał tworzyć samodzielnie działające programy (skrypty), na przykład przetwarzające pliki tekstowe. Co jednak ważniejsze, umożliwiał współpracę z aplikacjami działającymi w multitaskingu, które udostępniały swoje funkcje przez tzw. port ARexxa. Dzięki temu można było tworzyć skrypty automatyzujące złożone zadania — zwłaszcza takie, które wymagały przekazywania danych między programami.
Wyobraźmy sobie scenariusz: skrypt pobiera dane z jednej aplikacji (np. bazy danych), uruchamia inny program w celu ich przetworzenia (np. wykonania obliczeń albo wygenerowania grafiki), następnie wstawia wynik do dokumentu i wysyła go do drukarki. Wszystko to w środowisku domowego komputera z początku lat 90. Podam jeszcze jeden przykład bo mnie on dopadł. Potrzeba w programie graficznym narysować 200 kółek od najmniejszego do największego, ręcznie? Można ale skrypt AREX robił to w pięciu prostych linijkach. ARexx był więc w praktyce mechanizmem komunikacji międzyprocesowej. Czymś, co dziś nazwalibyśmy automatyzacją workflow.
Wróćmy do naszego dzisiejszego bohatera
AmigaGuide wprawdzie oficjalnie nie mógł wyświetlać obrazów w tekście w taki sposób jak HTML, ale mógł korzystać z bardzo ciekawego mechanizmu systemowego DataTypes. Zasada była prosta i elegancka: jeśli system potrafił obsłużyć jakiś typ pliku, AmigaGuide mógł prowadzić do tego pliku, a system automatycznie wyświetlał go przez swoją przeglądarkę danych — MultiView.
Żeby to lepiej zrozumieć, wyobraźcie sobie eksplorator plików w systemie Windows. Gdy przełączycie widok na miniatury, pliki JPG pokażą swoje podglądy. Ale już plik projektu Corela czy Photoshopa często zobaczycie jako zwykłą ikonę. System sam z siebie nie wie, jak zajrzeć do środka. A teraz wyobraźmy sobie, że istnieje uniwersalny mechanizm, który po doinstalowaniu odpowiedniego modułu sprawia, że menedżer plików nagle zaczyna rozumieć nowe formaty. Instalujesz obsługę plików graficznych konkretnego programu — i od tej chwili system potrafi wyświetlać ich miniatury tak samo jak JPEG-i. Bez modyfikowania eksploratora. Bez aktualizacji każdej aplikacji osobno. Właśnie tak działały DataTypes w Amidze.
Czyli w praktyce:
instalujesz w AmigaOS jpeg.datatype — system zaczyna obsługiwać pliki JPEG
instalujesz w AmigaOS gif.datatype — system zaczyna obsługiwać pliki GIF
Od tego momentu wystarczyło w dokumencie umieścić:
@{„Otworz obraz” system „multiview DF0:obraz.iff”}
i grafika otwierała się w programie MultiView.
Można było pójść dalej:
@{„Otworz animacje” system „multiview DF0:animacja.gif”}
albo nawet:
@{„Otworz sampla” system „multiview DF0:sampel_audio.wav”}
Dokument przestawał być tylko tekstem. Stawał się interfejsem do systemu.
Tak powstawały ciekawe, wieloplikowe publikacje, tekst w AmigaGuide, obrazy i animacje jako osobne pliki, a wszystko spięte prostymi linkami systemowymi. Czytasz i jak chcesz to oglądasz, bez ładowania galerii z 200 plikami, których i tak nie chce oglądać.
Dziś może wydawać się to archaiczne. Z drugiej strony był to mechanizm niezwykle czysty architektonicznie i przez to szybki. AmigaGuide odpowiadał za strukturę i nawigację, MultiView za wyświetlanie danych, a DataTypes za rozpoznawanie formatów. Każdy element robił swoje. Przypuszczam, że ewolucja formatu AmigaGuide poprowadziła by w stronę czegoś bardziej przypominającego HTML.
Internet poszedł w stronę rozbudowanych przeglądarek, coraz cięższych silników renderujących i rosnących warstw pośrednich. Brakuje mi tego, co pokazywała Amiga: dokument jako lekki tekst, logika jako skrypt, multimedia jako usługa systemowa. Wiem to były inne czasy.
Czasem mam wrażenie, że coś po drodze się rozrosło bardziej, niż było to konieczne. Kiedyś telefon służył do dzwonienia, konsola do grania, a komputer do pracy i zabawy. Dziś w przeglądarce internetowej uruchamiam aplikację, która emuluje inny komputer, żeby w tej emulacji zagrać w grę sprzed trzydziestu lat. Warstwa na warstwie, abstrakcja na abstrakcji.
Nie twierdzę, że to źle. Dzisiejsza technologia potrafi rzeczy, o których w 1991 roku nawet byśmy nie marzyli. Ale gdzieś po drodze zniknęła ta bezpośredniość. Ta świadomość, że plik to plik, tekst to tekst, a system robi dokładnie to, co mu każemy — bez pięciu pośredników. Czasami rozmawiam z młodymi ludźmi i wychodzi na to, że oni nawet nie widzą różnicy pomiędzy plikiem a katalogiem. Może tak już musi być. Może to naturalna ewolucja wygody (lub intelektualnej bierności w technologicznym konsumpcjonizmie). Ale ja wciąż lubię ten moment, kiedy wiem dokładnie, co dzieje się tam pod spodem.
Pogadaliśmy o historii, zahaczyliśmy o teorię — teraz czas na trochę mięska.
Jak to w rzeczywistości wyglądało?
Wszystkie polecenia zaczynały się od symbolu @ (po naszemu „małpa”). Reszta to był już tekst Jeśli na początku dokumentu pojawiała się linijka:
@database Amigaguide.guide
Od tego momentu plik działał inaczej a przeglądarka zaczęła dogłębnie analizować treść i ją dostosowywać. Dokument był dzielony na węzły (NODE) Początkiem węzła był: @NODE nazwa „Tytuł widoczny dla użytkownika” końcem węzła @ENDNODE jak widzicie jest to podobne do znaczników HTML ( <BODY> </BODY>)
To co w środku to była treść dla użytkownika, pomiędzy węzłami można było się przemieszczać jak przez linki w późniejszym WWW. Amigaguide posiadał też pewne (dziś byśmy nazwali je markerami) specjalne linki do węzłów oraz ogólny mechanizm linków hipertekstowych.
- @INDEX *
- @HELP *pomoc
- @NEXT *następny
- @PREV *poprzedni
- @TOC *spis treści
- @TITLE *Tytuł okna
- @QUIT *Wyjście
Atrybuty tekstowe nie były tak bogate jak w HTML ale pozwalały na wiele
- @{b} – *bold, pogrubienie
- @{ub} – *unbold koniec pogrubienia
- @{i} – *italic, pochyły tekst
- @{ui} – *unitalic, koniec pochyłego tekstu
- @{u} – *underline, podkreślenie tekstu
- @{uu} – *ununderline, koniec podkreślenia tekstu
- @{fg kolor} – *kolor tekstu
- @{bg kolor} – * kolor tła tekstu
- @{font nazwa} – *aktualna czcionka
- @{justify left|right|center} – justyfikacja tekstu
Co ważne link nie musiał prowadzić tylko w obrębie jednego pliku. Można było wskazać ścieżkę AmigaDOS (program lub część systemu), do innego dokumentu AmigaGuide i przeskoczyć tam bez żadnego problemu. Można było uruchamiać dodatkowe programy specjalne (np odtwarzacz plików muzycznych). Sam pamiętam jeden z ZINów (czasopism rozpowszechnianych na dyskietkach) gdzie treść była w formacie Amiga Guide a w treści autor pokazywał najnowszy utwór muzyczny to po kliknięciu uruchamiał się odtwarzacz muzyczny (chyba HippoPlayer). Ogólnie taki link wyglądał tak:
- @{„Tekst przycisku” link NazwaWezla}
ale mógł jak pisałem wcześniej prowadzić w wiele miejsc
- link *wewnątrz dokumentu
- system *do aplikacji systemowej lub innej
- rx *do skryptu Arexx
- close
- quit
@{„Powrot” link Main}
@{„Uruchom program” system „c:memtest”}
@{„Skrypt ARexx” rx „ram:test.rexx”}
@{„Zamknij” quit}
Odwołanie do innego dokumentu wyglądało tak:
@{„Inny dokument” link „sciezka/do/pliku.guide/NazwaWezla”}
Były też zalążki skryptowania:
@remark
@if
@else
@endif
@set
@unset
Z perspektywy dzisiejszego internetu brzmi to banalnie. W 1991 roku było to myślenie bardzo nowoczesne: dokumentacja jako sieć połączonych plików. Minimalistyczna elegancja oparta o interfejs systemu co też poprawiało pracę. Prosty skrypt wewnątrz dokumentu oraz dostęp do zmiennych systemowych pozwalał na np wyświetlanie treści związanych z aktualnym systemem.
Poniżej „tak na szybko” przykładowa strona główna ZINU Ekscynatorium
Polecam pobawić się rozwiązaniem, zarówno na Amidze, Amidze emulowanej ale też pod Windows bo tu też jest „player” tego formatu. Ubogi i nie ma dostępu do zmiennych systemowych – bo niby jak – ale zawsze
Do następnego artykułu
Aleksander Marcin Sanetra