RAMOS

Ruijs Automation Modular Operating System

Wat is RAMOS? Overweeg eens de volgende vraag: Met welk operating systeem kan of wil ik werken? Zoveel mensen, zoveel wensen, maar desondanks zijn er intelligente mensen die in de computer een potentiëel nuttig gereedschap zien. Vroeger (in de jaren tachtig) was het simpel, een computer kon toen relatief gezien nog niet veel, dus was er nog niet veel te wensen. Tegenwoordig is de hardware echter vele malen krachtiger/sneller en is het reëel om bepaalde wensen te hebben omtrent het gebruik van de computer. De hardware is er heel goed in geslaagd om vooruitgang (in dit geval verbetering) te boeken, maar bepaalde software is tegelijkertijd met een hoger tempo achteruit gegaan (positieve uitzonderingen hierop zijn o.a. bepaalde computerspellen), zodat de programma's tegenwoordig nog trager werken dan vroeger. Natuurlijk veel programma's zien er tegenwoordig veel leuker uit met al die venstertjes en zo, maar wat heb je eraan als je echt wilt werken en het irritant vindt om op een supersnelle computer te wachten! Indien U tevreden bent met de huidige situatie leest U dan vooral niet verder, U bent dan waarschijnlijk een expert op het gebied van expanded/extended/upper/high-memory en hebt daar al veel tijd aan opgeofferd. Of bent U diegene die verslaafd is aan het ledje van de harddisk of aan het o zo mooie zandlopertje, welke schijnbaar aangeven dat een programma met iets nuttigs bezig is!?

Wat moeten hobbyisten die graag zelf willen programmeren? Tegenwoordig zijn de moderne operating systemen dermate complex dat men een gigantische harde schijf, een gigantische compiler en een gigantische hoeveelheid computerboeken nodig heeft om ook maar een nuttige regel code te schrijven. Krijgt men al iets voor elkaar dan weet men absoluut niet meer wat er eigenlijk precies gebeurt. Potentiële hobbyisten zullen dus al snel ontmoedigd raken door bepaalde zaken als voortdurend ratelende harde schijven tijdens het compileren van een klein testprogramma. Het volgende verhaal is dus voornamelijk bedoeld voor hobbyisten die graag zelf willen programmeren en die graag willen weten waar de computer mee bezig is. Het verhaal is ook voor mensen die denken een systeem te hebben dat hen het gevoel geeft dat het systeem voornamelijk bezig is zichzelf bezig te houden en dat de gebruiker af en toe ook iets mag doen en dat men maar af moet wachten of en wanneer het verzoek gehonoreerd wordt. Ikzelf vergelijk bepaalde systemen met een zelfdenkende hamer die met een vertraging eventueel op de spijker terecht komt, onkundige mensen vinden zo'n hamer o.k. maar vakmensen zullen zo'n hamer meteen weggooien. Wat echter veel erger is, onkundige mensen zullen met zo'n hamer ook altijd onkundig blijven.

Volgend zijn de overwegingen gemaakt door mezelf, oordeel zelf of men dezelfde overwegingen kan maken. Ik heb een simpele wens; Ik wil een eenvoudig te gebruiken programmeertaal om zelf programma's te kunnen schrijven. Aangezien ik graag wil weten waar de computer mee bezig is, is de keuze snel gemaakt. Assembleertaal is en blijft de uitgangsbasis voor een 'goede' programmeur. Argumenten als dat de taal machinespecifiek zou zijn kloppen, maar de taal is sinds de begintijd van de computer nauwelijks veranderd, en dit kan men niet zeggen van de meeste andere programmeertalen! Assembler is dus de basis, maar er zijn dan nog twee 'kleine' problemen, ten eerste dient men samen te werken met een bepaald operating systeem en is men daarvan voor een groot deel afhankelijk en tevens is de taal vrij obscuur en voor niet-hoogbegaafde mensen en voor bepaalde taken niet altijd de meest logische keuze. Een hogere programmeertaal is dus de volgende stap. Echter welke? Belangrijk voor mij is dat er een eenvoudige koppeling moet zijn met assembler en eens geschreven routines moeten voor lange tijd algemeen gebruikt kunnen worden. Tegenwoordig zou C dus een voor de hand liggende keuze zijn. Deze keuze heeft echter enkele vervelende nadelen.

De nadelen van de keuze voor C:

• Ik vind de taal totaal onleesbaar, de hele syntax is opgebouwd uit beperkingen die voortkomen uit het beperkt aantal ascii-tekens die men voor bepaalde operatoren kan kiezen. Zo is != nog wel een beetje te volgen, maar & en && en ^ en * en | en }, zeggen mij op het eerste oog zo weinig, zodat de taal op mij een zeer rommelige indruk maakt.
• Indien men meerdere memory-models wil kiezen dient men bij het maken van assembler routines daar rekening mee te houden en verschillende versies te onderhouden. Ik wil niets te maken hebben met memory-models!
• Ik heb een hekel aan het gebruik van een linker, deze tussenstap voegt functioneel niets toe. Ik heb een hekel aan onnutige stappen ook al zijn ze voor de gebruiker niet echt lastig.
• Indien men meerdere programma's ontwikkelt, hebben de programma's exact gelijke stukken code die afkomstig zijn uit een algemene bibliotheek. Dit is niet echt efficiënt.
• C lijkt machine-onafhankelijk maar dit geldt alleen maar voor eenvoudige standaardfuncties. Indien men echte efficiënte code wil schrijven dient men machine/systeem-afhankelijke routines te ontwikkelen/gebruiken waarmee het voornaamste argument en kracht van C wegvalt.

Dit zijn de nadelen van C zelf die in principe nog niet echt onoverkomelijke problemen opleveren, het grootste probleem is de koppeling met een operatingsysteem. Bijna alle operatingsystemen (unix als belangrijkste uitzondering) staan los van welke programmeertaal dan ook, het is dan ook logisch dat de voornaamste problemen zich bij de interface tussen taal en systeem zich voordoen. Voor de hand ligt een operatingsysteem die de minste problemen oplevert voor de programmeur. Het normale DOS-systeem biedt voor de programmeur nog de beste oplossing, niet zozeer omdat deze zo goed is, maar alleen omdat dit systeem niet de gigantische beperkingen en onzinnige 'wetten' met zich meebrengt. Tevens is dit systeem eenvoudig te omzeilen en wil het zichzelf niet irritant op de voorgrond plaatsen, dit is ook de voornaamste reden dat veel moderne spellen nog gewoon onder DOS opgestart dienen te worden. De bottleneck van DOS is echter zoals iedereen weet het geheugenbeheer welke gebaseerd is op 16-bits en dus niet echt lang meer efficiënt is.

Indien men een andere programmeertaal kiest dan zit men al heel snel met problemen bij het opbouwen van algemene routines die al of niet geschreven zijn in assembler. Een unit voor pascal is bijvoorbeeld een heel handig iets. Maar men dient deze units solide en heel goed op te zetten wat zeer zeer veel tijd kost. Meestal doet men dit niet en moet men een unit later veranderen (of debuggen) en dan kan het voorkomen dat men oudere programma's niet meer kan compileren! Men dient dus praktisch gezien alle units bij de broncodes van te ontwikkelen programma's te bewaren en afzonderlijk te debuggen. Maar ja dan kan men net zo goed include-files gebruiken! De kracht van de units is in de praktijk alleen maar voor zeer grondige programmeurs weggelegd. Verder vind ik dat als ik programmeer in pascal ik telkens tegen de beperkingen van deze taal aanloop die voornamelijk met het geheugenbeheer, pointers en strings te maken hebben.

Wat is er mis met een object-oriënted programmeertaal? Met het oog op snelheid/complexiteit en efficiëntie wil ik hier vrij weinig woorden over vuil maken. C++ werkt bijvoorbeeld alleen maar indien men de basis zeer, zeer, maar dan ook zeer goed opzet, het hele systeem werkt alleen maar indien men alles foutloos opzet. Dat dit praktisch onmogelijk is weet uiteraard iedereen. Voor hobbyisten is dit ondoenlijk. Verder wil ik het al helemaal niet hebben over de problemen en complexiteit die ontstaan bij multitasking. De onzinnige wegen die men dient te bewandelen met het programmeren onder een multitasking systeem nemen alleen maar tijd in beslag die heel weinig opleveren.

Waarom deze klaagzang? Het is niet alleen een klaagzang! Het is een initiatief om met een 'betere' (voor bepaalde mensen dan te verstaan) oplossing te komen, te weten RAMOS (Ruijs Automation Modular Operating System) en RAP (Ruijs Automation Programming language). Wat houdt dit in? De filosofie bij het ontwikkelen was duidelijk en ligt min of meer vast:

• De basis MOET zeer eenvoudig zijn zodat iedereen het kan begrijpen.
• Eenvoudig uit te breiden EN aanpasbaar.
• Het systeem moet bruikbaar, eenvoudig omzeilbaar en onzichtbaar zijn.
• Compacte en snelle assembler routines moeten mogelijk zijn.
• Het operating systeem en programmeertaal moeten EEN systeem zijn.
• Het systeem moet ook kunnen werken op minder krachtige systemen (embedded software).
• Tot op een bepaald niveau moet het systeem, machine-onafhankelijk zijn.

Het volgende ligt al min of meer vast voor het verder te ontwikkelen systeem:

Het systeem is eenvoudig uit te leggen. Het operating systeem bestaat ALLEEN maar uit bibliotheken met routines/variabelen/structuren die in de programmeertaal gebruikt kunnen worden! Verder is er nog een heel klein programma (RAMOS) die de bibliotheken moet laden en starten. De basis is dus een klein laadprogramma die het systeem start en deze kan bij verschillende systemen ook verschillende vormen hebben. Verder is alleen de bibliotheek SYSTEM.LIB noodzakelijk, ALLE andere toevoegingen zijn optioneel.

Voor de PC ziet dat er bijvoorbeeld zo uit:

RAMOS.COM	-	Laadprogramma
RAMOS.CFG	-	Configuratie file
SYSTEM.LIB	-	Systeem routines
KEYBOARD.LIB	-	Toetsenbord routines
SCREEN.LIB	-	Scherm routines
PRINTER.LIB	-	Printer routines
....		-	Meerdere bibliotheken
STARTUP.PRG	-	Startup programma

De bibliotheken zelf bestaan dus uit de hardware-afhankelijke routines die men direct aan kan roepen zonder allerlei tussenlagen. Men dient dus alleen maar de bibliotheken te hebben die bij de beschikbare hardware hoort. Indien men bijvoorbeeld een andere printer gaat gebruiken dient men ALLEEN maar een andere PRINTER.LIB (dynamisch mogelijk=tijdelijk) te gebruiken. Applicatieprogramma's weten dan automatisch hoe ze de printer aan dienen te sturen, er zijn dus geen omslachtige configuratie procedures meer nodig. Tot zover niets nieuws want bij dat ene venster-systeem gebeurt dat ook al, echter daarbij weet men absoluut niet meer wat er onder water gebeurt en welke files (en die zijn er heel veel) er onnutig op de harde schijf staan en ruimte (=geld) innemen. Uniek is echter het feit dat de bibliotheken gemaakt zijn voor een bepaalde programmeertaal. De bibliotheken bezitten dus de namen van de routines en de informatie hoe deze aangeroepen dienen te worden, dus geen *.H files meer nodig (een ander nadeel van C), alles is geintegreerd en gericht op het gebruik ervan. Het grootste voordeel en de kracht van RAMOS en RAP is het feit dat de bibliotheken naamgericht zijn, wat dit precies inhoudt wordt later verklaard.

Dit klinkt natuurlijk allemaal te mooi om waar te zijn en dat is het ook. De volgende problemen zijn de moeite waard om te belichten.

• Men kan nooit verwachten dat de eerste versie van het systeem meteen in functionaliteit vergeleken kan worden met moderne operating- en programmeer- systemen. Men doet dus initieel een stap terug (om later continue vooruit te kunnen stappen). Daarom is het systeem initieel ook voornamelijk bedoeld voor hobbyisten die zelf wat willen programmeren en zich niet bezig willen houden met onzinnige zaken.
• De moeilijkheid is dat, wil het systeem tot op een bepaalde hoogte systeem- onafhankelijk zijn, de routines een algemeen karakter dienen te hebben die op elk systeem mogelijk zijn, dit legt beperkingen en regels op. Wilgroei is mogelijk!
• De bedoeling is dat het systeem uiteindelijk op de PC onder protected mode moet gaan draaien. Dit is echter een ZEER grote stap die nooit in een keer genomen kan worden, al is het maar omdat de informatie voor de aansturing van verschillende hardware zeer schaars is. Daarom werkt het systeem in eerste instantie ook alleen maar onder DOS en heeft het ook dezelfde beperkingen. De bibliotheken zullen langzaam maar zeker steeds minder DOS afhankelijk worden, dit is mogelijk door de degelijke opzet van RAMOS, zodat de stap naar protected mode later eenvoudiger uit te voeren is.

Wat zijn de voordelen?

• Geschreven code in RAP blijft altijd bruikbaar! (in het ideale geval)
• Computerspellen ontwikkelaars kunnen zeer eenvoudig het systeem omzeilen en eigen hardware-specifieke routines gebruiken.
• Eigen gemaakte hardware-aansturingen worden niet ontmoedigd of verboden maar gewoon mogelijk gemaakt. DE PROGRAMMEUR IS DE TOTALE BEHEERSER VAN HET SYSTEEM!
• Zeer eenvoudig te begrijpen opzet van het systeem.
• Het hele systeem is in de basis onzichtbaar! Geen last van een opdringerig systeem dat koste wat het kost op de voorgrond EN achtergrond actief blijft en computertijd in beslag neemt.
• Er zal na verloop van tijd een grote hoeveelheid bibliotheken beschikbaar komen (afhankelijk van de gebruikers) die vanaf internet eenvoudig gedownload kunnen worden (freeware, shareware of commercieel).

Wat is echter het grootste voordeel? Het grootste voordeel is het feit dat de routines naamgebaseerd zijn. Dit houdt in dat een routine via een naam beschikbaar is, het gebruik hiervan is dus gekoppeld aan een naam. Er zijn meerdere systemen die gebaseerd zijn op modules/bibliotheken maar deze worden meestal aangeroepen via offsets (getallen) en deze liggen dus altijd vast! Indien een routine later verandert zit men vast aan een bepaalde offset die onmogelijk te veranderen is. De naamgebaseerdheid houdt in dat de naam van de routine/variabele opgeslagen ligt in de bibliotheek en programma's die gebruik maken van deze routines refereren aan deze naam en niet aan een bepaalde offset. Dit heeft als gevolg dat bij het laden van een programma deze routines opgezocht dienen te worden en de juiste adressen ingevuld dienen te worden. Dit houdt dus een bepaalde overhead in bij het laden van een programma. Maar deze overhead valt in het niet bij de overhead die nodig is indien men een routine in een bibliotheek gaat veranderen. Men gebruikt gewoon een andere naam voor een nieuwe versie van een bepaalde routine en laat de oude routine gewoon staan, zodat oude EN nieuwe programma's kunnen blijven werken. Dit lijkt een klein voordeel maar is de voornaamste reden voor de ontwikkeling van RAMOS!

Voor alle duidelijkheid U moet RAMOS en RAP initieel zien als een hobbyisten systeem, waarmee U in staat zult zijn om op een eenvoudige wijze Uw computer te besturen en programmeren.

Meer informatie volgt ...