R to ciekawy dodatek do DOSu. Komenda buduje GUI dla poleceń/programów ADOS na podstawie wyświetlanego przez te komendy wzorca (więcej o wzorcach znajdziesz tu). Wystarczy w linii poleceń wklepać np.

r copy

by po chwili cieszyć się ładnym GUI polecenia Copy, używającym MUI.

W archiwum programu znajdziemy jego wersje dla AmigaOS (2/3 i 4), AROSa x86, jak i MOS-a.
I wszystko jest pięknie, dopóki wywołujemy polecenie r w uruchomionym systemie operacyjnym. Jednak gdy uruchomimy komputer bez Startup-Sequence (a więc wtedy, gdy istnieje największe prawdopodobieństwo, że będziemy polecenia potrzebować) - r "staje okoniem" i odmawia współpracy.


r staje okoniem

Użytkownicy AmigaOS 2 i 3 mogą poszperać po archiwach i znaleźć wcześniejszą wersję r - niewymagającą MUI, Locali itd. - użytkownicy nowszych wersji OSów tak dobrze nie mają...
Żeby naprawić ten problem, wystarczy stworzyć programowi r minimalne środowisko pracy. Wykorzystałem do tego celu prosty krypt AmigaDOS o nazwie "u" (jak uruchom), będący nakładką na polecenie r. Skrypt uruchamiamy tak samo, jak polecenie r - podając mu parametr będący nazwą programu - dla którego r ma wygenerować GUI. Czyli zamiast wspomnianego wcześniej przykładu:

r copy

podajemy

u copy

Skrypt, jeżeli istnieje taka potrzeba, tworzy wymagane przez r przypisy - a następnie uruchamia polecenie r przekazując mu nazwę programu. Przy okazji polecenie r jest uruchamiane w multitaskingu - nie blokuje nam okienka CLI - dzięki temu możemy np. wygenerować kilka GUI, dla kilku programów jednocześnie (bo nie po to projektanci DOS zaimplementowali w nim multitasking, żebyśmy z niego nie korzystali... ;) ).
Poniżej zamieszczam skrypt "u" z komentarzami:

---

.KEY FILENAME
.BRA {
.KET }
;polecenie .KEY (opis) pozwala nam na przekazanie do skryptu parametrów, tak jak ma to miejsce w przypadku poleceń/programów uruchamianych z linii poleceń
;poleceń .BRA i .KET (opis) użyłem, ponieważ w skrypcie korzystam z redyrekcji (przekierowań strumieni/wyjścia), żeby nie zaciemniać składni skryptu.

Stack 100000 >NIL:
;Wydaje mi się, że z tym rozmiarem stosu (opis) to minimalnie przesadziłem ;) ale wszystko zależy od tego, jakim programom buduje się GUI. Dawno temu, któraś wcześniejsza wersja r ciągle mi się wieszała przy budowie GUI dla jakiegoś programu - więc dorzuciłem tą linijkę i tak już zostało do dziś...

Resident >NIL: C:Assign PURE
Resident >NIL: C:MakeDir PURE
;Polecenie resident (opis) umieszcza polecenia Assign i MakeDir w pamięci, dzięki czemu będą szybciej wczytywane niż z dysku twardego.

Assign ENV: EXISTS >NIL:
;Za pomocą polecenia Assign (opis) sprawdzamy, czy istnieje urządzenie (właściwie przypisanie do katalogu) ENV:

IF WARN
;(opis polecenia IF) jeśli nie to:

MakeDir RAM:ENV
;MakeDir (opis) zakłada katalog ENV w pamięci,

Assign >NIL: ENV: RAM:ENV
;tworzymy przypisanie do nowo założonego katalogu.

ENDIF
;Koniec warunku


Assign T: EXISTS >NIL:
;Sprawdzamy, czy istnieje urządzenie (właściwie przypisanie do katalogu) T:

IF WARN
;jeśli nie to:

MakeDir RAM:T
;zakładamy katalog T w pamięci,

Assign >NIL: T: RAM:T
;tworzymy przypisanie do nowo założonego katalogu.

ENDIF
;Koniec warunku

;podobną procedurę powtarzamy dla CLIPS: LOCALE:/HELP: i MUI:

Assign CLIPS: EXISTS >NIL:
IF WARN
MakeDir RAM:Clipboards
Assign >NIL: CLIPS: RAM:Clipboards
ENDIF


Assign LOCALE: EXISTS >NIL:
IF WARN
Assign >NIL: LOCALE: SYS:Locale
Assign >NIL: HELP: SYS:Locale/Help DEFER
ENDIF


ASSIGN MUI: EXISTS >NIL:
IF WARN
Assign >NIL: MUI: SYS:MUI
Assign >NIL: LIBS: SYS:MUI/Libs ADD
ENDIF

;no to środowisko uruchomieniowe mamy już przygotowane - mozna uruchamiać r

RUN C:r {FILENAME}
;polecenie RUN (opis) uruchamia nam polecenie r w multitaskingu

Resident Assign REMOVE
Resident MakeDir REMOVE
;sprzątamy po sobie - usuwamy polecenia Assign i MakeDir z pamięci

---

Skrypt bez komentów


a multitasking w ADOS wygląda tak... ;)