[Polish] Pięć dobrych cech konstrukcyjnych starego systemu AmigaOS, które trudno odnaleźć w nowych systemach

Choć komputer Amiga może być już młodemu pokoleniu nieznany, to z całą pewnością można powiedzieć, że zarówno ten komputer, jak i jego system operacyjny, zapisał się w historii informatyki złotymi zgłoskami. AmigaOS, czyli system operacyjny komputera Amiga, swoją premierę miał w 1985 roku wraz z premierą pierwszego modelu Amigi 1000. System ten był dostosowany do uruchamiania z dyskietek i poprawnego wykorzystywania pamięci RAM, której w tym komputerze można było uświadczyć jedynie 512 kB. Wykonywanie prac na procesorze o taktowaniu 7 MHz miało być szybkie, a sam system miał być bardziej innowacyjny, niż cokolwiek do tej pory stworzono. Programiści sprostali temu zadaniu tworząc system operacyjny z zaawansowanym multitaskingiem (obsługą wielu aplikacji na raz), wysokimi możliwościami konfiguracji i niespotykaną, jak na te czasy, wygodą użytkowania. System ten był potem rozwijany i jego kolejne wersje wprowadzały nowe koncepcje. Już jednak pierwsza wersja zawierała kilka konstrukcji, które pośród systemów operacyjnych nigdzie nie zostały już tak dobrze odwzorowane. Poniżej pięć z nich, które subiektywnie wybrałem.

Obsługa ekranów

AmigaOS wprowadzał koncepcję ekranu. Ekran ten mógł być otwarty przez dowolną aplikację w dowolnej rozdzielczości i palecie kolorów. Każdy ekran zajmował osobną pamięć graficzną. Ekrany dzieliły się na publiczne (public) i specjalne (custom). Ekran publiczny przeznaczony był do wykorzystania przez dowolne aplikacje. Każdy program mógł otwierać swoje okna na dowolnym ekranie publicznym (także otwartym przez inne programy). Ekrany specjalne dedykowane były jednej aplikacji (często grze), która otwierała go tylko dla siebie i definiowała w nim swoją rozdzielczość i paletę barw. Co ciekawe rozdzielczość, a wielkość ekranu były osobnymi pojęciami. Ekran większy niż rozdzielczość zwyczajnie przewijał się przy najeżdżaniu myszką na jego krawędzie. Niektóre osoby preferowały pracę w taki sposób. Inni lubili wykorzystywać pracę na wielu ekranach. Na jednym można było otworzyć np. wiele okien programu graficznego, na drugim okazjonalnie przeglądać katalogi, na trzeci przełączać się aby zastać pootwierane okna swojego edytora programistycznego. Przypomina to koncepcję wirtualnych pulpitów w Linuksie (często ponumerowanych od 1 do 4), ale nie chodziło tu o proste przełączenie zestawu otwartych okien, a fizyczne rozgraniczenie ekranów. To pozwalało np. na uruchomienie gry w innej rozdzielczości niż główny ekran publiczny i błyskawiczne przełączanie między nimi bez żadnych zaburzeń okienek. To coś zupełnie innego niż znamy chociażby z Windows-a. Windows ma tylko jeden ekran i zmiana jego rozdzielczości przesuwa wszystkie zawarte w nim okna. Zobaczenie ich po włączeniu gry na pełnym ekranie jest możliwe tylko po minimalizacji tej gry, co zmienia na powrót rozdzielczość ekranu okazjonalnie nawet zawieszając grę. To jednak nie koniec. Programiści AmigaOS poszli dalej w obsłudze ekranów i zaimplementowali obsługę ich przesuwania. Ekran można było odsunąć kursorem myszy, aby zobaczyć ten, który znajduje się pod nim, nawet jeśli tamten definiował inny tryb ekranowy. Widać to na poniższej animacji, gdzie kursor myszy swobodnie przechodzi do ekranu z inną paletą barw konwertując swoje kolory w locie. To prawdziwy majstersztyk, tak obcy dzisiejszym użytkownikom komputerów, że aż nieco trudny do zrozumienia.

Dyski

AmigaOS podążył koncepcją podobną jak DOS (a potem Windows). Rozgraniczył byt dysku od bytu pliku i katalogu. Dla odmiany systemy Unix (więc i MacOS) i Linux rozumieją dysk/partycję jako obszar podmontowany pod katalog. W systemach tych można też dostać się do dysku z pominięciem systemu plików używając go jako pliku z katalogu systemowego „dev”. Ostatecznie więc dysk jest tam katalogiem lub plikiem... na innym dysku (w systemie plików). Tworzy to pewną ścisłą zależność systemu operacyjnego z systemem plików. Dostęp do uniksowych dysków nie tylko wymaga ich definicji (istnienia) w głównym systemie plików, ale i niepotrzebnie angażuje główny system plików do odczytu i zapisu na niepowiązanym dysku lub innym urządzeniu. To trochę jak wchodzenie do swojego mieszkania przez mieszkanie sąsiada. AmigaOS i DOS użyły notacji „DYSK:” do uzyskania dostępu do dysków, gdzie w przypadku DOS (i Windows) nazwa dysku jest zbędnie ograniczona do jednej litery. Mamy więc słynne dyski „C:”, „D:”, itd. W przypadku AmigaOS nazwy dysków były dowolne. Np. „System:”, „Dane:”, itp. System pozwalał też na dowolne zmienianie nazw dysków oraz tworzenie tzw. przypisań (assign). W związku z tym można było łatwo stworzyć sobie np. wirtualny dysk (przypisanie) „Kosz:”, który prowadził do katalogu „Dane:Inne/Kosz”. Było to szeroko stosowane i eliminowało konieczność używania zmiennych systemowych do wskazywania katalogów programów. Np. Java nie musiałaby tam definiować zmiennej systemowej „JAVA_HOME”, mogłaby utworzyć przypisanie dysku „Java:” do dowolnego katalogu. Zmienne systemowe pozostałyby do innych zastosowań.

Innym ciekawym rozwiązaniem powiązanym z dyskami był system partycji (a w późniejszych wersjach AmigaOS także niespotykany wtedy graficzny edytor partycji).

Informacje o partycjach zapisywane były w pierwszych blokach dysku twardego. Stosowana była tablica partycji RDB, w przeciwieństwie do znanego z DOS-a MBR. RDB definiowało domyślną nazwę każdej partycji (np. „DYSK:”), priorytet jej startu (boot order), jej początek i koniec (więc i wielkość), ale także przede wszystkim przechowywało plik sterownika systemu plików. Tak, to oznaczało, że możliwe było np. zpartycjonowanie dysku twardego, dyskietki, pendrive na kilka różnych partycji i każda z nich mogła używać innego systemu plików, nieznanego systemowi. Systemy plików powstawały więc niezależnie od samego systemu operacyjnego, były tworzone przez pasjonatów i powstały ich dziesiątki. Możliwość obsługi nowego systemu plików była możliwa bez instalacji czegokolwiek w systemie operacyjnym. Wystarczyło podłączyć dysk. Sterownik wgrywał się z RDB. Użytkownik miał możliwość dowolnej manipulacji systemem plików i plikiem sterownika każdej partycji, w tym systemowej.

Władza nad pamięcią RAM w rękach użytkownika

Większość systemów operacyjnych zarządza pamięcią RAM w sposób całkowicie automatyczny. To oczywiście dobrze, bo użytkownik nie musi się tym przejmować. Niektóre systemy jednak pozwalają na ingerencję użytkownika w zarządzanie pamięcią, jeśli tego sobie życzy. Np. Linuksy oferują zaawansowanym użytkownikom opcje dotyczące użycia pamięci wirtualnej (np. jak często używać swap, jak agresywnie odkładać pamięć na dysk twardy, itp.). AmigaOS ma jednak na tym punkcie obsesję. :) Użytkownikowi nieznającemu się na programowaniu udostępniono nawet takie opcje jak wielkość stosu przydzielanego domyślnie każdemu konkretnemu programowi (w bajtach), czy wielkość buforu dyskowego (cache zapisu i odczytu na dysk) każdej z partycji każdego dysku (a nawet dyskietki). Ciekawym rozwiązaniem jest możliwość ustalenia programu wykonywalnego jako rezydentny. Taki program ładuje się od razu do pamięci RAM, nawet gdy nie jest uruchomiony. Uruchamianie takiego programu (lub komendy) następowało już wtedy bez odczytu z dysku i było znacznie szybsze (szczególnie w czasach dyskietek). Podobnie można było wskazać dowolną bibliotekę, aby załadowała się naprzód (np. już przy ładowaniu systemu), aby potem używające jej programy nie zaglądały na dysk. Optymalizacja.

Koniecznie należy tu też wspomnieć o legendarnym RAM-dysku. RAM-dysk to dysk logiczny stworzony z pamięci RAM. Na takim dysku możliwe jest tworzenie dowolnych plików i katalogów, kopiowanie ich, przenoszenie, kasowanie. Wszystko bez zapisu gdziekolwiek poza pamięcią RAM. Być może w czasach dysków SSD to mało ważna właściwość, ale wcześniej ekstremalna szybkość działania takiego dysku pozwalała przyspieszyć wiele operacji plikowych. Wiedząc, że potrzebne będzie wielokrotne operowanie na pliku można było umieścić go w RAM-dysku, a zapis i odczyt do niego był już bardzo szybki. Często RAM-dysk był używany też do przechowywania plików tymczasowych, bo jego zawartość przepadała wraz z restartem, jednocześnie czyszcząc „śmieci”. Co ciekawe idea RAM-dysku przeciekła też z czasem do systemów uniksowych i Windows (potrzebny dodatkowy program), ale nie zyskała tam popularności przez swój główny problem. W systemach tych RAM-dysk zajmował pamięć. Była ona niedostępna dla programów, trwale zarezerwowana. W przypadku AmigaOS RAM-dysk poszerzał się dynamicznie, miał wielkość taką, jaka potrzebna była do przechowania zawartych w nim plików. Pusty RAM-dysk oznaczał całą pamięć dla programów. Pełny oznaczał, że żaden nowy program się już nie uruchomi (pojawi się komunikat o braku pamięci). Oczywiście używanie go było opcjonalne. Kolejną ciekawostką było też, że system oferował także inny rodzaj RAM-dysku. Był to dysk, którego zawartość nie przepadała wraz z restartem. Jak to możliwe? Otóż wbrew pozorom pamięć RAM w komputerze nie czyści się przy resecie. Pozostaje w niej zawartość z poprzedniego uruchomienia, tylko system operacyjny nie zwraca na nią uwagi, nadpisując ją dowolnie przy uruchamianiu się. AmigaOS oferował funkcję oznaczenia obszaru pamięci jako przeżywającego restart, a który system pozostawiał przy uruchamianiu nietkniętym. To dawało kolejne ciekawe możliwości. Możliwe było nawet oznaczenie takiego dysku jako startowy (bootowalny) i skopiowanie na niego okrojonej dystrybucji systemu operacyjnego! System odpalał się wtedy błyskawicznie, w całości z pamięci, nawet bez obecnego w komputerze dysku twardego czy dyskietki. Można było go restartować, itp. Wszystko znikało dopiero po całkowitym wyłączeniu komputera.

Format ikonek

Ciekawą ideą jest też format ikonek zaprezentowany wraz z pierwszym AmigaOS. Pomimo ograniczeń pamięciowych i dyskowych były to ikonki animowane. Obrazek ikony zmieniał się po wybraniu (zaznaczeniu) go. Ciekawe jest też to, że format był zaprojektowany przyszłościowo, co pozwalało na wsteczną kompatybilność. Bez większych zmian kolejne edycje systemu pozwalały używać ikonek z większą paletą barw, a nawet ostatecznie ikonek PNG. Poniżej przykład blatu AmigaOS 3.9 z wieloma ikonami. Pośród nich można znaleźć charakterystyczną reprezentację katalogów jako szuflady lub regały szuflad (a nie jako tekturowa teczka, którą znamy z systemów Windows).

Co ciekawe, ikona w AmigaOS łączyła też funkcję skrótu znanego z systemów Windows (pliki lnk). Mogła (nie musiała) ona prowadzić do wskazanego programu i uruchamiać go z podanymi parametrami. Wszystko to w jednolitym, przemyślanym odgórnie, formacie.

Lokalizacja

Bolączka dla wielu użytkowników o niskiej znajomości języków obcych? Wszystko w obcych językach. Najgorzej jeśli każdy program w innym. AmigaOS oferował jako pierwszy rozwiązanie łatwej lokalizacji programów, czyli trywialnego ich tłumaczenia na inne języki. Programy posiadały swój plik lokalizacji (locale), gdzie zapisane były wszystkie występujące w nich teksty i komunikaty. Wystarczyło przetłumaczyć taki plik, aby program już wyświetlał wszystko np. po polsku. Można było to robić bez wiedzy o programowaniu. Spowodowało to wysyp tłumaczeń wszystkich programów na dziesiątki języków. Skopiowanie jednego pliku sprawiało, że program mówił już do użytkownika w języku jakiego oczekiwał. To było godne podziwu, jak na lata 80-90. Kompletnie przetłumaczony system robił wrażenie przeznaczonego dla zwykłego użytkownika, a nie komputerowego speca. To otwierało furtkę do jego dalszego poznania.

Mam nadzieję, że ten nieco techniczny tekst zaciekawił czytelników na tyle aby przetrwali do końca i poznali kilka ciekawych koncepcji. Umieszczam ten artykuł jako temat tygodnia polskiej społeczności Steemit, jako luźne nawiązanie do telefonu Nokia Series 90, który to oferował zupełnie inny, acz też ciekawy system operacyjny z charakterystycznymi sobie właściwościami. Chciałem jednak omówić coś jeszcze chyba mniej znanego, niż system tej Nokii, a jednocześnie coś, co wzbudzi szczególne zainteresowanie i podda refleksji, że nie wszystko co stare, musi być koncepcyjnie gorsze. ;)