RiScript - De binnenkant
waarin Jeroen Medema laat zien wat er schuilgaat

In deze laatste aflevering van de reeks over RiScript wil ik het hebben over hoe we RiScript gemaakt hebben. Dat wil ik doen door eerst naar de conceptuele opbouw te kijken, daarna naar de code, en het releasen, en dan uiteindelijk af te sluiten.

Opbouw

Kern
In het eerste artikel over RiScript schreef ik dat RiScript eigenlijk een verzameling van vier applicaties is (op de manier waarop RISC OS daar naar kijkt): !RiScript, !ScripTerm, !DSCript, en !PDFront. RiScript is de kern, en kan zelfs zonder de andere applicaties gebruikt worden. Op deze manier is het een eenvoudige PostScript-interpreter, waarmee je (dus) geen PDF kan bekijken, niet kan browsen, geen informatie over het document kan krijgen, en niet interactief kan werken. Je kan nog wel kiezen wat voor een soort output je wilt, en dat is dan een beetje vergelijkbaar met de export waar ik het de vorige keer over had. De applicatie is dus zeker wel bruikbaar, maar beperkt in zijn mogelijkheden.

Samenwerking
In de praktijk zal de kern van RiScript tezamen met een andere applicatie het "gezicht" voor de gebruiker vormen, en vaak zal dat met de plug-ins (!DSCript en !PDFront) zijn. Deze voegen toe wat we misten: PDF bekijken, browsen, en documentinformatie bekijken. Om dit voor elkaar te krijgen, moeten de plug-ins en deze kern samenwerken, waarbij in principe de leiding bij de plugin ligt. Hiervoor is er communicatie tussen de plug-ins en de kern nodig, en daarvoor hebben we een eigen protocol gedefiniëerd waarmee we vanuit de plugin opdrachten kunnen geven. De beste manier om opdrachten te geven is hiervoor een taal te gebruiken, en gelukkig hadden we die al: PostScript! De plug-ins spreken dus, via een eigen protocol, PostScript tegen de kern, en die doet waar hij goed in is: interpreteren van deze PostScript-code.

Let dus wel dat PDFront (verantwoordelijk voor het bekijken van PDF) PDF analyseert en de RiScript-kern de relevante PostScript-commando's geeft. Dit lijkt heel erg lastig (en makkelijk is het ook zeker niet) maar omdat er een grote overeenkomst is tussen PDF en PostScript valt het nog wel mee.

Integratie
De functie van de plug-ins (en !ScripTerm) is niet heel moeilijk te beschrijven: het n.a.v. een gebruikersactie het geven van opdrachten (geformuleerd in PostScript) om te bewerkstelligen wat de gebruiker net gevraagd heeft. Hiervoor heeft de gebruiker natuurlijk wel een GUI nodig, en vanaf RiScript versie 4 is deze interface geïntegreerd met de GUI van de kern: de navigatiebalk (hieronder die per ongeluk uit het vorige artikel verdween) is, als er een plug-in "praat" met de RiScript-kern, een window van de plug-in. Deze techniek is gebaseerd op de techniek van de Nested Window Manager, en werkt, moet ik zeggen, wel erg mooi, want het geheel is transparant voor de gebruiker. Die heeft geen last van het feit dat hij eigenlijk met twee (of zelfs drie of vier) applicaties werkt: het is voor hem één window.
Hier zijn dus twee applicaties te zien.

Code

Talen
RiScript is geschreven in twee talen, namelijk C en PostScript. Ja, u leest het goed, een deel van de functionaliteit is in PostScript zelf geschreven, gebouwd op de functionaliteit in C. Dit is weliswaar iets langzamer tijdens executie, maar wel veel makkelijker te schrijven. Verder is het ook vrij normaal om het zo te doen, en vereisen sommige gedeelten het zelfs.

Getallen
De RiScript-code is over een kleine vijfhonderd files verdeeld, waarvan er ruim vierhonderd in C geschreven zijn, en zo’n tachtig in PostScript. Hierbij tel ik code die we van anderen hebben (bibliotheken, waarover later meer) niet mee. In deze vijfhonderd files zitten bij elkaar bijna twee miljoen karakters, allemaal door Roeland van den Bos en mij ingetypt (en nog wel wat meer ook, want er is in de loop van de tijd wel wat veranderd), waarvan een kleine negen procent in PostScript. Een grove schatting van het aantal regels code is tachtigduizend, een exacte telling hiervan heb ik niet. Al met al een in grootte niet onaardig project.

Naast de code die direct in de applicaties terecht komt, hebben we ook een aantal tooltjes geschreven. Allereerst om een heel eenvoudige manier van versiebeheer te hebben. Maar daarnaast is er ook een tool om licenties te genereren: wel belangrijk voor een commerciële applicatie als RiScript. Uiteraard vallen deze zaken in de marge van de applicatie-code, maar het is wel allemaal gemaakt.

Organisatie
Bij de opbouw van onze code hebben we niet alle code files in één directory staan. Dat was onder RISC OS 3 ook niet mogelijk gegeven het aantal daarvan, maar het is ook niet handig. We hebben de code-files zo opgedeeld dat we onafhankelijke bouwblokken hebben, die in principe zelfs als module uitleverbaar zouden zijn. [Dat is nog steeds een idee, maar zal waarschijnlijk nog gebeuren.] Zo hebben we bijvoorbeeld bibliotheken met code gerelateerd aan fonts, filters (o.a. voor compressie en beveiliging), en output devices.
We maken ook gebruik van een aantal externe bibliotheken, zoals de jpeglib, zlib, en de MD5 bibliotheek. Deze hebben we hier en daar wat moeten aanpassen (lees: uitbreiden) maar over het algemeen waren ze "out-of-the-box" al goed bruikbaar na compilatie.

Omdat we ook Taborca gemaakt hebben, hebben we in onze code stukken zitten die afhankelijk van de applicatie die we maken wel of niet meegenomen wordt. Zo was het voor ons veel makkelijker de boel te beheren. Eén voorbeeld is dat alle code om iets te laten zien in Taborca niet nodig is. En reken maar dat dat scheelt!

Tools
We werken met de Acorn C compiler met de bijgeleverde toolset (o.a. ResEd). Hierbij hebben we dus wel wat extra's gemaakt, maar over het algemeen voldoet deze suite goed. Ontwerpen en veranderen van de GUI is vrij eenvoudig, en dat hebben we zeker nodig in een applicatie als de onze.

Release

Als we een release willen uitbrengen is het voor ons nu een druk op de knop, da's ook één van de dingen die we zelf gemaakt hebben. [Het aantal files dat uitgeleverd wordt is 105 per release, en daarom zult u begrijpen waarom dit proces geautomatiseerd is.] Deze actie levert een zip-file op van ongeveer 650K. Hierin zitten dan alle vier applicaties en alle resources die deze nodig hebben, zoals bijvoorbeeld de opstart-banner. De gecompileerde en ge-squash-te applicaties zijn (bij elkaar) 470K groot. De grootste bijgeleverde file is echter de StartUp file, een snapshot van het interne interpreter-geheugen, waarmee de interpreter opstart.

Afsluiting

In een vogelvlucht heb ik u deze vier artikelen meegenomen in de wondere wereld van RiScript. Deze aflevering vond ik zelf moeilijk te schrijven, want je vervalt al snel in zeer technische details. Ik hoop dat u deze en andere afleveringen leuk vond; ik vond het leuk ze te schrijven. Mochten er nog vragen zijn, mail dan gerust medema@freemail.nl. Ik lees deze mail weliswaar niet zo frequent, maar een reactie zult u zeker krijgen.