Multitasking onder OS/2

> OS/2 Index <

Hoe stem je de OS/2 af op je persoonlijke behoeften? Hoe haal je het meeste uit dit besturingssysteem? Wat is zinvol, wat niet? Dat zijn vragen die me bezighielden.

Ik bespreek hier slechts de zaken die er in mijn praktijk het meest toe doen. Daartoe behoren niet meer de CONFIG.SYS fijnafstemmingen die bedoeld waren om wat geheugen of processortijd te besparen. Ze lieten OS/2 sneller lopen op een jaren 90 PC. Maar gebrek aan werkgeheugen of processorkracht zijn niet meer het probleem. Pas als een applicatie 25% sneller loopt merk je een verschil. Maar een moderne processor staat meestal te wachten.

Het gaat nu om het maximaal benutten van de OS/2 mogelijkheden met behoud van de stabiliteit. Op een snel besturingssysteem is niet gebrek aan snelheid het probleem, maar het behoud van de stabiliteit. Dat u de controle behoudt en niet uit de bocht vliegt. Ik verzamelde hiertoe wat achtergrondinformatie, waarvan u zelf kunt bepalen, wat u ermee wilt doen. Enige kennis van besturingssystemen en de daaronder lopende processen is onontbeerlijk.

De taken van het besturingssysteem

> Top <

Pas als software toegang tot de hardware heeft komt de computer tot leven. De in het geheugen geladen software vertelt de processor wat het met de hardware moet doen. De software bestaat uit het besturingssysteem en de gebruikersprogramma's.

In een multitasking (multiprogramming) werkomgeving lopen meerdere programma's tegelijkertijd. De actieve programma's en data zijn in het hoofd- of werkgeheugen (primary storage) geladen. De nog niet aangeroepen programma's en data bevinden zich op de vaste schijf (backing of secondary storage).

Om te voorkomen dat actieve programma's elkaar in weg lopen moeten de computervoorzieningen centraal worden verdeeld. Daarom regelt het besturingssysteem de toegang tot de hardware. Het besturingssysteem weet dankzij zijn stuurbestanden als geen ander hoe de hardware aangesproken moet worden. Programmeurs besteden dit lastige programmeerwerk liever uit.

Single purpose besturingssystemen worden door hardwarefabrikanten geschreven. De fabrikant levert de stuurbestanden, een summier besturingssysteem en enkele systeemprogramma's om het doel van zijn apparaat (router, magnetron) te verwezenlijken.

Multi-purpose PC besturingssystemen spreken echter een veelheid van hardware aan. De leverancier van het besturingssysteem biedt slechts een interface (benaderingswijze) en software gereedschap (toolkit) om de stuurbestanden te schrijven. De stuurbestanden worden door of in opdracht van de hardwarefabrikanten geschreven. Zij hebben er immers het meeste belang bij dat hun hardware goed wordt verkocht. Vanwege de hoge ontwikkelingskosten zullen zullen ze zich vooral op de dominante platformen richten. Hetzelfde geldt trouwens ook voor de gewone software programmeurs.

Programma's roepen de functies van het besturingssysteem (diensten) aan om de hardwarebronnen te benaderen. Voor hun look en feel benaderen ze grafische programmabibliotheken. Ook deze roepen weer systeemdiensten aan. Zo maken de Presentation Manager (PM) en Workplace Shell (WPS) bibliotheken deel uit van de systeembibliotheken van het OS/2 2+ besturingssysteem en de Windows API (win32) van systeembibliotheken van Windows 95 en NT.

Het verschil tussen programmabibliotheken en systeembibliotheken is een beetje arbitrair. De makers van besturingssystemen neigen er steeds meer toe om gebruikersprogramma's en -bibliotheken in hun besturingssysteem te integreren. Je kunt dan van systeemdiensten spreken. De belangrijkste systeembibliotheek is wellicht de c bibliotheek. Maar denk hierbij ook aan netwerkdiensten, de DOS, Rexx en Java ondersteuning en niet te vergeten de bibliotheken van grafische gebruikersinterface (WPS, PMShell). De in het besturingssysteem geïntegreerde grafisch bibliotheken nemen programmeurs veel werk uit handen en zorgen voor een consistente look en feel.

Strikt genomen hoort de gebruikersinterface (shell) niet bij het besturingssysteem. De shell loopt immers in dezelfde gebruikersruimte als de programma's en behoort verwisselbaar te zijn. Een shell als GNU bash kan ook onder OS/2 als Windows draaien. Maar omdat de bekendheid met en de gebruiksvriendelijkheid van de schil zo bepalend is voor wat de gebruiker met het besturingssysteem kan doen, worden besturingssystemen in de praktijk vooral op hun schil beoordeeld. Hoe beter en vertrouwder de grafische interface oogt, des te gemakkelijker wordt het besturingssysteem verkocht. Tijd en kunde om onder de motorkap te kijken ontbreekt. Mede hierdoor werd Windows een groot succes.

Maar hieronder heb ik echter vooral over de prestaties van het besturingssysteem in enge zin. Wat in het UNIX schema hiernaast de kernel heet. Het is de spil van het besturingssysteem.

De kern(el) beheert de toegang tot de processor, het hoofdgeheugen en de perifere apparaten (toetsenbord, beeldscherm, vaste schijf, netwerkkaart, geluidskaart e.d.). De kernel heeft onbeperkte toegang tot alle geheugengebieden, inclusief de snelle registers van de processor en de perifere apparaten.

De toegang tot de randapparatuur verloopt via de door de adapterfabrikant geleverde stuurbestanden. De via de CONFIG.SYS geïnstalleerde stuurbestanden (HPFS, grafische adapters en netwerkaarten) maken gebruik van interfaces naar de OS/2 kernel. Interfaces zijn te vergelijken met stopcontacten. Ze kunnen al dan niet gezekerd zijn. Onjuist geconfigureerde of geprogrammeerde stuurbestanden kunnen het besturingssysteem laten crashen.

Gewone gebruikersprogramma's (zwart) kunnen de hardware alleen via de kernel benaderen. Ze moeten een beroep doen op de kernel of op de door de kernel en stuurbestanden beheerste systeemdiensten. Een onderdeel van de kernel (scheduler) verdeelt de processortijd (scheduling). Ander onderdelen regelen de toegang tot het geheugen en de stuurbestanden van de perifere apparaten. De kernel verdeelt steeds de bronnen (resource allocation).

Om de sneller te kunnen werken beschikken enkele gespecialiseerde gebruikersprogramma's over beperkte Input-Output Privileges (IOPL). Hiermee kunnen ze bepaalde stuurbestanden (beeldscherm, communicatiepoorten) direct beschrijven. Maar voor het overige maken ze net als de andere programma's gebruik van systeemdiensten om het geheugen en de daarin door het besturingssysteem gevirtualiseerde apparaten te gebruiken.

Bij een indirecte benadering van de hardware via een systeeminterface spreekt van virtuele apparaten. Bij een nagenoeg complete emulatie van een computersysteem spreekt men van een virtuele machine (VM). Voor een DOS applicatie in Virtuele DOS machine (VDM) lijkt het alsof het directe toegang tot bepaalde hardware (geheugen, beeldscherm, seriële poort) heeft, maar in werkelijkheid worden zijn bronnen door het OS/2 besturingssysteem beheerd. De virtuele DOS stuurbestanden (VDD) schotelen de DOS applicaties gewoon een DOS achtige omgeving voor die lijkt op de echte DOS stuurbestanden.

OS/2 Warp ondersteunt meerdere Application Program Interfaces (API's): software bibliotheken die het besturingssysteem de programma's ter beschikking stelt. Het besturingssysteem past zich zo aan, dat het voor de programma's lijkt dat ze in hun eigen omgeving draaien.

De belangrijkste zijn:

• OS/2 Warp ondersteunt vijf soorten OS/2 programma's: 16 en 32 bits OS/2 tekstmodus (Video I/O , VIO) programma's, 16 en 32 bits grafische OS/2 Presentation Manager (PM) programma's en 32 bits Workplace Shell (WPS) programma-uitbreidingen (DLLs).

• Ieder Java programma draait in zijn eigen Virtuele Java Machine (JVM). De JVM emuleert een RISC processor. Een JVM laat multithreading toe.

• DOS programma's, die gewend zijn de hardware direct aan te spreken, krijgen virtuele stuurbestanden (virtual device drivers, VDD) die het BIOS en de hardware emuleren. Ze lopen in een Virtuele DOS Machine (VDM).

• Ook 16 bits Windows programma's lopen onder een DOS VDM. De geëmuleerde Win-OS/2 omgeving loopt wat sneller dan die van MS DOS (en zeker sneller dan die van Windows 2000/NT).

• Het op WINE gebaseerde ODIN project biedt "on the fly" van Windows PE naar OS/2 LX geconverteerde 32 bits Windows programma's (EXE en DLL) een beperkt met WIN32 compatibele OS/2 API aan.

• De XFree86/OS2 X Window emulatie van OS/2 doet niet merkbaar onder voor die van de Linux.

Een PC besturen is een beetje te vergelijken met regeren. U geeft de opdrachten met de muis, het toetsenbord en via uw opstartscripts. Daarna moeten de soft- en hardware het werk doen.

Maar ook onder het krachtigste besturingssysteem bent u niet almachtig. Uw regering is afhankelijk van de wetten en krachten uit het veld. Dus van een goede samenwerking van programma's, diensten, stuurapparaten en de beperkingen van uw hardware. Een besturingssysteem kent geen god-mode. Samenwerking gaat niet zonder compromis. U moet besturen met de middelen die u hebt. U kunt slechts de voor uw behoeften best mogelijke configuratie samenstellen.

• Kies een besturingssysteem dat bij uw behoeften past.

• Kies geschikte hardware.

• Bepaal welke stuurbestanden er geladen worden en welke niet.

• Bepaal welke programma's er draaien en met welke prioriteit.

Elementair nietwaar? Maar hoeveel mensen zouden dat nu zelf bepalen? Meestal is het een kwestie van het gegeven Windows paard niet in de bek willen kijken. En zich vervolgens afvragen waarom dat winkukel het niet onder NT, OS/2 of Linux doet...

Multitasking

> Top <

De in het geheugen geladen programma's wedijveren om de aandacht van de processor. Zonder rekentijd kunnen ze niets doen. De processor, het moederbord en de perifere apparaten leveren de spierkracht, de software vormt het brein. De software vertelt de processor wat het met de hardware moet doen.

Met de processor bedoel ik de centrale verwerkingseenheid (CVE), die in het Engels central processing unit (CPU) wordt genoemd. Op een symmetrisch multiprocessing (SMP) systeem (WsEB, eCS SMP) bemoeien meerdere processors zich met de programma's in het hoofdgeheugen. Daarnaast bestaan er aan de processor(en) ondergeschikte rekenhulpjes, waarvan de mathematische coprocessor wel de bekendste is. Zonder deze hulpkrachten is processorintensieve software-emulatie vereist. Ook videokaarten en printers bevatten rekenkundige hulpprocessors, die de hoofdprocessor(en) zullen ontlasten.

OS/2 is een pre-emptief, multitasking, multithreading besturingssysteem

Op een single-tasking besturingssysteem draait maar één programma. De taken in dat programma worden na elkaar uitgevoerd. Als u onder DOS een lang document print kunt u niet tikken. De printopdracht moet eerst worden afgemaakt. Pas als het document naar het printergeheugen (of een wachtrij op het netwerk) verzonden is, krijgt het programma weer aandacht voor het toetsenbord. Als het programma tenminste goed geschreven is...

Multitasking (multiprogramming) wil zeggen dat meerdere taken tegelijkertijd uitgevoerd worden. Dat kunnen meerdere programma's zijn, maar ook meerdere deeltaken (draden) binnen één proces. Een tekstverwerker kan bijvoorbeeld tegelijkertijd nieuwe invoer accepteren, printen en de spellingscontrole uitvoeren.

Als één uitvoerbaar bestand (proces) de processor meerdere taken (nu draden geheten) tegelijkertijd laat verrichten spreekt men van multithreading. Multithreading is van groot belang op systemen met meerdere processors, maar zal ook niet-SMP systemen voordelen bieden. M.n. als er op trage randapparatuur moet worden gewacht. Multithreading is een goed alternatief voor het opdelen van taken in meerdere processen, omdat het aanmaken van een draad binnen hetzelfde proces veel minder overhead kost dan het aanmaken van een nieuw proces.

Het woord tegelijkertijd moet u echter niet letterlijk opnemen. De processor voert zijn instructies nog steeds achter elkaar uit. Alleen op een symmetrisch multiprocessing (SMP) systeem kan iedere processor op hetzelfde moment een draad/taak binnen hetzelfde proces (programma) uitvoeren. Maar een enkele processor voert op ieder moment maar een instructie uit. Maar omdat die processor in microseconden van taak kan wisselen (task-switching) valt niemand dat op.

Een single-tasking besturingssysteem voert maar een programma uit. Aaneengesloten rekeninstructies zullen normaal vlotten (het paarse gebied), maar de processor zal veel rekentijd verspillen zodra hij op de relatief langzame in- en uitvoer instructies stuit (het witte gebied). Tijdens het wachten op de relatief trage in- uitvoerapparaten heeft de processor niets te doen.

Een multitasking besturingssysteem met interrupt gestuurde I/O controllers kan die wachtperioden van de processor beter benutten. De lees- of schrijfopdracht wordt naar de interrupt gestuurde I/O controller gedelegeerd. Via de op de kloksnelheid van de oorspronkelijke IBM PC (4,77 MHz) lopende direct memory access (DMA) kanalen verloopt het transport van data tussen randapparaten en het geheugen grotendeels buiten de processor om. Met de op de kloksnelheid van de PCI bus lopende bus mastering techniek kunnen randapparaten ook het geheugen omzeilen. De elektronica in de EISA, MCA of PCI randapparatuur is dan even de baas (bus master). Tijdens de wachttijd van proces 1 kan de processor zijn rekenkracht voor een andere taak (proces 2) gebruiken. Proces 1 wordt tijdens de leestaak tijdelijk geblokkeerd. Als de I/O operatie van proces 1 klaar is wordt dit door een interrupt gemeld. Daarna kan de processor de oude staat van proces 1 herstellen, tenzij er een taak bestaat met een hogere prioriteit.

Multitasking /multiprogramming is vooral een mechanisme om de processorkracht beter te benutten. En omdat ook perifere apparaten op de processor moeten wachten heeft dat ook een positief effect op de randapparatuur. Als de processor op een input/output operatie moet wachten, schakelt het besturingssysteem vliegensvlug over naar een andere taak. De machinecode van de uit te voeren processen 1 en 2 moeten zich dus in het hoofd- (liever nog cache)geheugen bevinden. Die vliegensvlug door de processor benaderde stukjes geheugen noemt men de werkset van het systeem: het geheugen waar de processor over die periode mee werkt (working set, vaak aangeduid met de Griekse letter delta).

De achtergrondtaak moet nuttig werk te doen hebben. Snel overschakelen naar een tekstverwerker die op de achtergrond op invoer zit te wachten heeft weinig zin. Aan de hand van de prioriteiten van iedere gereedstaande draad bepaalt het besturingssysteem de volgorde waarin ze aan bod komen (scheduling).

Bij geheugengebrek zullen de instructies van het langzame secundaire geheugen (pagineringsbestand, swapper.dat) van de vaste schijf worden gehaald, waardoor de efficiëntie van het systeem (m.n. de processor) drastisch zal verminderen. De processor moet nog langer op de uit te voeren programmacode wachten. De overhead van het systeem neemt toe (trashing).

Daarom hebt u onder OS/2 meer aan een wat langzame processor (P1) met ruim hoofdgeheugen (minimaal 64 MB), dan aan een snelle PIII processor met te weinig geheugen voor uw programma's. Pure processorkracht is vooral van belang op een PC waarop u een spelletje draait. Door die ene taak kunt u de werkset laag kunt houden. Maar onder OS/2 zal die snelle PC uit de doorsnee winkel PC met veel processorkracht maar met met krap geheugen het grootste deel van de tijd moeten wachten...

Preemptive multitasking wil zeggen dat het besturingssysteem vooraf bepaalt hoeveel processortijd een taak maximaal zal krijgen. Iedere programma krijgt een deadline. Daarna wordt het door het systeem geïnterrumpeerd (een preëmptieve onderbreking). Als een programma niet op tijd klaar is, moet het zijn volgende beurt maar afwachten.

Multithreading programma's zijn hier in het voordeel: hun deeltaken (threads, draden) hebben afzonderlijk recht op processortijd. Doordat de draden zich binnen hetzelfde proces bevinden geeft een taakwisseling veel minder systeemoverhead. Bij OS/2 (en NT) hebben alle draden afzonderlijk recht op hun eigen processortijd.

Een preëmptief multitasking systeem kent meer overhead (rompslomp) dan een cooperative multitasking systeem waarbij ieder programma zelf kan bepalen wanneer het klaar is (voluntary multitasking). Maar het deadline principe voorkomt wel dat een enkel programma alle processortijd in beslag kan nemen en/of dat een slecht geschreven programma het systeem laat hangen.

Programma's en diensten

> Top <

De in het geheugen geladen programma's en diensten staan bekend als processen. Ieder proces heeft een uniek process identificatie-nummer (PID) en gebruikt zijn eigen deel van het virtuele geheugen (user-space).

Het besturingssysteem zorgt ervoor dat processen niet aan elkaars (ongedeelde) geheugen en bestanden komen.

Zo levert het benaderen van het voor een ander programma (proces) gereserveerde virtuele geheugen een algemene beschermingsfout (general protection fault, GPF) op. Het beschrijven van elkaars bestanden wordt met file-locking voorkomen.

Daarnaast zorgt het besturingssysteem voor methoden waarmee afzonderlijke processen data kunnen uitwisselen. Deze interproces communicatie (IPC) is aan strikte regels gebonden.

Ze variëren van een simpele omleiding van in- (TXT< PROG) en uitvoer (PROG> LPR) tot de complexe protocollen voor de berichtenuitwisseling die TCP/IP, Presentation Manager en WPS programma's gebruiken. Zo moeten de programma's die op de Werkplek lopen voortdurend met PMShell communiceren om die object georiënteerde omgeving mogelijk te maken. Die communicatie verloopt via berichten.

In het overzicht hiernaast ziet u hiërarchisch overzicht van de bij mij lopende processen.

U ziet het beeld van een zich vertakkende boomstructuur. Vanuit het rootproces worden zelfstandige diensten gestart. Bepaalde diensten (shells en initialisatiescripts) starten weer ander diensten op, waardoor de boom zich snel vertakt.

Uiteindelijk resulteert dit in een voor OS/2 typische besturingsomgeving waarin de meest uiteenlopende gebruikersprogramma's (OS/2, DOS, Windows, Java, X-protocol) in het geheugen kunnen "drijven".

Het eerste OS/2 proces (PID =1) is sysinit. Deze system initialisation thread laadt de stuurbestanden (basedev, device=) en diensten (run=) uit de config.sys. Ze worden met opzet buiten het met Ctrl-Escape opgeroepen taakoverzicht gehouden. Als u ze zou afsluiten zouden alle ervan afhankelijke processen en en draden onderuit gaan...

Een belangrijke tak in het overzicht is de protected mode shell Presentation Manager. Van hieruit worden alle PM applicaties (StarOffice, Organizer, en ook de Werkplek ) geladen. Zonder PMShell lopen ze niet. Alle grafische programma's zijn van het functioneren van Presentation Manager afhankelijk.

In het schema lijkt het alsof de OS/2 opdrachtaanwijzing (CMD) en de XFree86 X Server ook van PMShell afhankelijk zijn. Maar dat is niet helemaal waar. Ze kunnen ook los van elkaar functioneren. De X server is hier vanuit Presentation Manager opgestart, omdat ik daar nu mee werk. Xman is op het startx.cmd met detach als zelfstandige daemon gestart, die alleen onderuit gaat als hij de X server mist.

Maar voor XFree86, de DOS en OS/2 opdrachtaanwijzing kunt u ook een niet grafische protected mode shell nemen (mshell.exe of cmd.exe), vanwaar u eventueel ook PMShell starten kunt.

In de met Procview gemaakte afbeelding wordt PMShell tweemaal gestart. De eerste keer werkt hij als Presentation Manager: het strak blauwe scherm waarop uw programma's in vensters draaien.

PROTSHELL=F:\OS2\PMSHELL.EXE 

En ook als u de protshell ingang weglaat, wordt standaard pmshell gebruikt.

De tweede keer dat PMShell opstart wordt hij als Werkplek geladen: De met mappen en iconen gevulde object georiënteerde desktop van OS/2 .

SET RUNWORKPLACE=F:\OS2\PMSHELL.EXE 

Als u de map Werkplek onder de WPS bekijkt ziet u een mini Werkplek ontstaan (zie de afbeelding hiernaast). Dat is een essentie van het begrip object georiënteerd: Op de Werplek presenteert Presentation Manager uw iconen van hardware, programma's, mappen en bestanden (de objecten) alsof ze daadwerkelijk op uw schijf staan. Via drag and drop kunt u ze met elkaar verbinden. Een icon die ik naar de trashcan sleep gaat de prullenbak in. Een bestand dat ik naar een programma object uit Programma's sleep, wordt door dat programma geopend. Sleep ik het naar het printer object dan wordt het geprint.

Presentation Manager (protshell) en Workplace shell (runworkplace) zijn dus verschillende processen. Als de WPS opnieuw moet starten (WPS reset), blijven Presentation Manager programma's als Organizer, StarOffice en Netscape actief. Voor meer info: Hoe wordt de werkplek geladen?.

Processen lopen via draden

> Top <

Ieder proces (programma) begint met een begindraad (thread 1), die minimaal de communicatie met het besturingssysteem verzorgd. Ook processen (DOS, UNIX ports) die het begrip draad niet kennen. Van hieruit kunnen andere taken als een extra draad (OS/2 programma's) of als een nieuw proces worden opgestart. Als u de begindraad (Thread ID=1) van Process ID 50 afsluit zal de gehele applicatie eindigen. Dat is wat een kill opdracht doet.

Sommige programma's gebruiken maar een draad (single threaded). Ze voeren hun taken een voor een uit. Het zijn eenmansbedrijven. Ze zijn te vergelijken met handwerkslieden die niet aan taakspecialisatie doen.

Andere programma's starten voor iedere taak een nieuw proces. Meerdere uitvoerbare bestanden naast elkaar vormen een programma suite. Iedere proces krijgt zijn eigen processortijd. Voorbeelden zijn de aan de de internet daemon gekoppelde TCP/IP diensten, maar ook de OS/2 port van Lotus Notes. Een voordeel van zo'n systeem is dat als een proces onderuit gaat, het andere proces kan blijven voortbestaan. Het grote nadeel is dat ieder proces zijn eigen systeembronnen (vooral geheugen) nodig heeft en dat de onderlinge communicatie tussen afzonderlijke processen minder snel zal verlopen. Een bedrijf dat zijn activiteiten over meerdere panden verdeeld heeft meer overhead door de voor ieder bedrijfspand benodigde basisvoorzieningen. Daarnaast moet het voor de interne communicatie van externe diensten (de post, hier het OS) gebruik maken.

Veel voor OS/2 geschreven programma's zijn daarom multithreading. Ze maken voor een nieuwe taak een nieuwe draad aan binnen hetzelfde proces. Dat is veel efficiënter dan voor iedere draad een nieuw proces te starten. Voorbeelden zijn PMShell (de Werkplek en al zijn uitbreidingen) en StarOffice. Hun modulen hebben even tijd nodig om te laden, maar als ze eenmaal geladen zijn profiteren ze van de synergie van een groot bedrijfspand. De tekstverwerker als StarOffice (StarWriter) kan via afzonderlijke draden meerdere taken tegelijkertijd uitvoeren (tekstinvoer, spellingscontrole, automatisch opslaan, printen). Maar ook de andere modulen van StarOffice (StarDesktop, StarDraw, StarCalc, StarMath, StarImpress, StarImage, StarMail, StarDiscussion, StarChart, StarBase, StarSchedule) draaien binnen hetzelfde proces (soffice.exe). Iedere draad krijgt onafhankelijk van de andere draden zijn eigen processortijd. Op die manier kunt u gewoon doortikken terwijl u op de achtergrond print.

Een nadeel is dat het programma zelf voor overhead zorgt. Als u alleen maar tekst verwerkt, hebt u de andere eigenschappen niet nodig. Laat staan een ingebouwde desktop. Men spreekt dan van opgeblazen software (bloatware). Een ander nadeel is dat, als een component een defect vertoont (bijv. StarDraw) ook de andere componenten onderuit zullen gaan. Ze draaien immers binnen hetzelfde vastgelopen proces. Hierbij treedt dataverlies op. Bij een kantoorpakket dat uit meerdere uitvoerbare bestanden bestaat (Lotus SmartSuite) is de kans hierop minder groot.

Door de prioriteiten van afzonderlijke draden slim in te stellen kunnen programma's nog effectiever met de processortijd omgaan. Een tiende seconde op een cursor wachten is lang, maar voor de printer telt u de tijd in seconden. Voor het automatisch opslaan telt u de benodigde tijd niet eens. Om die reden krijgen voorgrondtaken meer processortijd dan achtergrondtaken. In processortijd verdelen kom ik er op terug.

De CONFIG.SYS variabele THREADS = 256 (64-4095) geeft aan dat OS/2 voor 256 draden systeemgeheugen reserveert. Als de variabele ontbreekt geldt het minimum van 64. Bij een te lage waarde kunnen programma's foutmeldingen geven. Een te hoge waarde gebruikt onnodig systeemgeheugen. Een waarde van 256 is in op een 64 Mb systeem voldoende. Maar als u ruim geheugen hebt en Java applicaties als Limewire wilt gebruiken (bij mij 160-360 draden), verhoog dan deze waarde tot 512 of 1024. Of beperkt het aantal gelijktijdige downloads...

Proces statistieken

> Top <

Proces- en thread-informatie krijgt u met:

pstat /c | more 

U kunt in plaats van more ook de viewer van het GNU less utility gebruiken (afsluiten met q).

Voor meer overzicht kunt u naast het standaard EGA scherm ook een extra object van de opdrachtregel (*) maken met "/k mode co80,43" of extra groot met "/k mode co132,50" in het parameterveld waar anders een % staat (co voor color, 80 en 132 voor de tekenbreedte en 43 of 50 de regellengte van het scherm). Het gebruik van kleinere tekens zal dan nuttig zijn (Linker bovenhoek, met Font size experimenteren).

Informatie over een afzonderlijke proces krijgt u met:

pstat /P:PID | more 

PID is het proces ID.

De Werkplek draait bij mij met ruim 30 draden. Voor zover ik kom zien is dat niet direct afhankelijk van het aantal geopende vensters. Het aantal geregistreerde WPS addons zal wel uitmaken.

Verder valt op dat pure WPS programma's als Object Desktop, XWorkplace en geopende WPS objecten niet in het procesoverzicht voorkomen. Het zijn geen afzonderlijke processen, maar uitbreidingen (extensies) van de Workplace Shell. Het zijn geen EXE bestanden, maar bibliotheken (DLL) die als draden van het hoofdproces PMShell lopen. Het starten van een nieuwe draad is efficiënter dan het laten lopen van een extra proces. Bovendien is alleen op deze manier die hoge mate van integrate te bereiken die kenmerkend is voor de WPS. U ziet ze (evenals de geopende vensters) vaak wel in het met Ctrl-Escape opgeroepen taakoverzicht.

Interrupts

> Top <

De aandacht van de processor

Programma's, stuurbestanden, de kernel en subonderdelen van de processor vragen voortdurend de aandacht van de processor. Vergelijk het met een overvolle kleuterklas. Als een kind iets wil steekt het de vinger op. Juf (de processor) moet het regelen. Op de x86 computer gaat het iets anders. Niet via opgestoken handjes, maar via 256 interrupts. OS/2 is een door interrupts gestuurd systeem.

Met een interrupt (eigenlijk een verstoring) geeft een proces aan dat het nù de aandacht van de processor wil. Een I/O operatie is klaar, een programma loopt vast of er is iets anders waarvoor de aandacht van de processor nodig is. Zonder de processor kan het proces niet verder. De processor moet dus iets regelen. Bijv. het afbeelden van een teken op het scherm.

Randapparaten versturen een hardware interrupt naar de processor als er in het randapparaat iets is gebeurt waar de processor op moet reageren. Daartoe gebruiken ze zestien Interrupt Request Channels (IRQs) die hen met de processor verbindt. Deze hotlines zijn door IBM voor de IBM PC gedefinieerd. Andere interrupt signalen zijn door Intel voor de 86 processor familie gedefinieerd: delen door nul en stroomstoring. Hardware interrupts kenmerken zich door hun snelheid en het feit dat ze op ieder willekeurig moment kunnen ontstaan.

Software interrupts worden daarentegen met opzet opgewekt. Zo kan software via een interrupt de subroutines van het IBM PC BIOS en aanhangsels aanroepen om de randapparatuur tot actie te bewegen: bijv. schermafhandeling of het benaderen van de schijf. Maar ook het besturingssysteem (DOS interrupts) en toepassingen kunnen interrupt aangestuurde software routines bevatten. Moderne besturingssystemen emuleren trouwens de BIOS functies.

Iedere interrupt (hardware, software, besturingssysteem) is herkenbaar aan een bepaald nummer. Hoe lager het nummer, des te hoger de prioriteit.

Met een interrupt worden de activiteiten van de processor onderbroken. Na aankomst van een interrupt maakt de processor de laatste instructie van het actieve programma af, slaat de registergegevens in een stack (stapelplaats) op en gaat na wie de interrupt veroorzaakte. Op grond van het interruptnummer zal het systeemprogramma voor de interrupt-afhandeling er wat mee doen. Als de in een geheugentabel vermelde interruptbehandelingsroutine voor de genoemde interrupt klaar is gaat de processor weer met de oude taken door.

Interruptafhandeling

Net als in een drukke klas hebben niet alle verzoeken dezelfde prioriteit. Minder belangrijke zaken moeten in de wachtrij worden gezet. Een dreigende systeemcrash moet als eerste worden aangepakt. Delen door nul geeft een soort brandalarm (exception interrupt). Maar de ernst wordt weer bepaalt door de geheugenlocatie (systeem- of programmageheugen). Zaken die voor nodeloos oponthoud van de activiteiten van de systeembronnen zorgen (de vaste schijf die klaar is met een karwei en om een nieuwe opdracht vraagt) hebben een hogere prioriteit. Maar een programma dat via een software interrupt aangeeft dat er nieuwe post aangekomen is, kan wel even wachten.

Op het gebied van prioriteitstelling (lees interruptafhandeling) bestaan er grote verschillen tussen de verschillende besturingssystemen. MS DOS maakte van de automatismen Intel 8259 chip en navolgers gebruik. Net als onder het huidige Windows werden moeilijke zaken naar de hardware fabrikanten gedelegeerd. In dit geval naar Intels 8259 PIC chip. Maar Microsoft kon het zich permitteren. De PC werd een onovertroffen succes en Intel heeft ruimschoots van de exclusieve samenwerking met Microsoft geprofiteerd.

De eerste IBM/MS DOS PC's gebruikten de Intel 8259 Prioritized Interrupt Controller met 8 interruptlijnen (IRQ 0-7). Op de IBM AT kwamen daar nog 8 interruptlijnen (IRQ 8-15) bij, die t.b.v. de compatibiliteit met de XT via IRQ 2 (cascade) werden doorverbonden. Dus als op de AT een IRQ 2 signaal afgaat, zal de Intel 286 processor nagaan welke "hogere" IRQ 8-15 in het geding was.

De truc van DOS was dat de PIC chip al aan een vorm van prioriteitsstelling deed. Want ook onder DOS lopen meerdere processen. De timer interrupt IRQ 0 kreeg de hoogste prioriteit. Deze kristallen klok genereerde 18 maal per seconde een interrupt. Om typen en een noodstop (Ctrl-C, CAD) mogelijk te maken kwam daarna de IRQ 1 van het toetsenbord. Daarna kwamen de via interruptlijn 2 doorgeschakelde AT interruptlijnen 8 t/m 15 en vervolgens de interruptlijnen 3 t/m 7. IRQ 7 (printerpoort LPT1) is dus de traagste van het geheel.

Tegenwoordig regelt een Programmable Interrupt Controller (PIC) chip het interruptverkeer naar de processor. Het is de secretaresse van de druk bezette processor. Interrupts van de processor zelf (divide by zero fouten e.d.), de hardware en het besturingssysteem krijgen altijd voorrang boven door software applicaties gegenereerde interrupts. Ze worden eerder door de PIC aan de processor doorgegeven. Ze hebben hun eigen hotline die altijd open staat.

Dankzij deze supersnelle hardware interruptlijnen behoeft de processor de geluidskaart en communicatiepoorten niet aldoor over hun status te ondervragen. Het via de software ondervragen van de randapparatuur (pollen) vergt altijd meer processortijd. Pollen vindt namelijk ook plaats als er niets gebeurt. Overigens werkt het op gezette tijden (pre-emptive) pollen onder OS/2 nog steeds beter dan maar afwachten totdat een randapparaat zelf aangeeft klaar voor een opdracht te zijn. Want dan kunt u tot Sint Juttemis wachten.

Onder het single-tasking DOS was wachten geen bezwaar, maar in een multitasking besturingssysteem heeft de processor wel wat beters te doen. Een voor DOS geschreven tekstverwerker als WordPerfect zal het toetsenbord continu pollen. Onder DOS was dat geen probleem. De PC was niet meer dan een flexibele typemachine.

Maar op een netwerk is het al weer wat anders. Ook communicatieprogramma's controleren voortdurend de status van de communicatiepoorten. Ze verwachtten immers dat daar iets zou gebeuren. U doet hetzelfde als u met de muis in de aanslag naar een Windows zandloper kijkt. Maar het gespannen wachten op "Wanneer mag ik weer verder gaan" kost wel energie en de aangespannen vingers leveren u RSI op.

In het voorbeeld hiernaast werd een printopdracht op een laserprinter uitgevoerd. Tijdens het grafische printen was de IRQ load zo'n 40% (rode lijn), terwijl de processorbelasting (groene lijn) niet steeg. Maar toen ik dezelfde opdracht zonder de /IRQ optie in BASEDEV=PRINT01.SYS uitvoerde, zodat de OS/2 printspooler software polling gebruikte, werd de processorbelasting nagenoeg 100%.

Hierdoor zou de printopdracht met de op de voorgrond lopende processen moeten wedijveren. Onder het slim multitaskende OS/2 is dat geen probleem. Hier vertraagt het sofwarematige pollen van een printerpoort de met voorgrond prioriteit lopende applicaties nauwelijks. En al helemaal niet de hardware en software interrupts van het besturingssysteem, aangezien die over hun eigen hotlines naar de processor beschikken. Maar wie wel eens een een floppy formatteert onder Windows, weet dat dergelijke processen het systeem fors kunnen belasten.

Onder OS/2 kunt u het overmatige pollen van DOS en Windows programma's voorkomen door in hun DOS instellingen de waarde voor IDLE_SENSITIVITY naar 5 te verlagen.

Bibliotheken

> Top <

Vrijwel alle programma's maken gebruik van de in bibliotheken aanwezige programmacode. Deze run time libraries roepen weer andere (gemeenschappelijke) bibliotheken op. Door de diensten van een PM bibliotheek aan te roepen hoeft de programmeur de voor het tekenen van vensters benodigde programmacode niet zelf te bedenken. Het gebruik van in bibliotheken vastgelegde standaardprocedures leidt tot een consistente interface, bespaart u geheugen en de ontwikkelaar veel tijd.

pstat | more 

geeft de lopende processen en bibliotheken.

PSTAT /P:PID geeft een overzicht van de door een individueel proces gebruikte bibliotheken.

De WPS is de grootste bibliotheek gebruiker. Als ik PSTAT /P:PID voor de Werkplek (hier PID 23) opvraag, blijkt PMShell een hele reeks runtime link bibliotheken (DLL bestanden) te gebruiken. Ik laat het eerste vensterbeeld zien.

Proces- en thread-informatie 
Proces ID Sessie- Naam Runtime Namen gemeensch. 
ID parent- ID proces link- geheugen 
proces bibliotheken 
0023 001D 12 F:\OS2\PMSHELL.EXE F:\BIN\WPS\OBJDESK\OBJDARAR.DLL PMWP\CLASS.TBL 
F:\BIN\WPS\OBJDESK\OBJDATAR.DLL PMGLOBAL.MEM 
H:\ACROBAT3\READOS2\AAPDF.DLL PMDRAG.MEM 
F:\OS2\DLL\HELPMGR.DLL DDE4@@@@.@@Z 
F:\OS2\DLL\MINXMRI.DLL XWORKPLC\DMNSHARE.DAT 
F:\OS2\DLL\MINXOBJ.DLL ULSMEM\IBM850 
F:\MUGLIB\DLL\NETAPI32.DLL LSWORKER 
F:\OS2\DLL\NLS.DLL FFSTMEM.DAT 
F:\NETSCAPE\PROGRAM\NS46DRAG.DLL 
F:\OFFICE51\WPS517CO.DLL 
F:\OS2\DLL\IGSMRI.DLL 
F:\OS2\DLL\IGSREG.DLL 
-- Meer -- 

Hier zitten ook bibliotheken bij die ik misschien niet nodig heb. Ze worden wel door PMShell geladen. Bijv. AAPDF.DLL van het PM programma Acrobat Reader. Dergelijke bibliotheken zijn tijdens de installatie van dit niet WPS programma in terecht gekomen. Vrijwel altijd gebeurt dit via een REXX script. In dit geval via acrowps.cmd. De opdracht "acrowps remove" zal de klasse AApdf uit OS2.INI verwijderen.

De NS46DRAG.DLL maakt drag & drop van URLs mogelijk van en naar het Netscape venster. Die laat ik staan.

Bibliotheken deregistreren

> Top <

WPS programma's integreren vloeiend met de Workplace Shell. Hun bibliotheken breiden de functionaliteit van de Werkplek uit. Hun Dynamic Link Libraries (DLLs) worden in de PM_Object klassentabel van \OS2\OS2SYS.INI geregistreerd. Op die manier worden ze tijdens het opstarten van Presentation Manager geladen.

Voor pure WPS programma's als Object Desktop zijn deze registraties essentieel. Dit zijn geen zelfstandig uitvoerbare bestanden, maar bibliotheken. Zonder de registratie van hun DLLs in het OS2.INI bestand kan PMShell.exe ze niet gebruiken. De situatie is enigszins te vergelijken met de in de Windows registry geregistreerde Windows DLLs, alleen verloopt de communicatie onder OS/2 via het System Object Model (SOM). Voor details: De Werkplek.

Anders ligt het bij in de WPS geregistreerde Presentation Manager programma's. Dit zijn door PM uitvoerbare grafische programma's. Ze kunnen door het registreren van nieuwe klassen een verhoogde WPS integratie krijgen, maar het is maar de vraag of u die functionaliteit nodig hebt. Zonder registratie van de klasse AApdf loopt Acrobat Reader (ACROREAD.EXE) ook wel en de koppeling van *.pdf extensies aan het Acrobat Reader programmaobject zal in de praktijk voldoen. De zin van deze klasse heb ik dus nooit ontdekt (waarschijnlijk handelt het zich om een soort WPS plugin). Andere PM programma's die bibliotheken registreren zijn StarOffice (een hele reeks StarOffice klassen gekoppeld aan soagent.dll), IBMWorks en FaxWorks. Maar al deze Presentation Manager programma's werken ook zonder WPS en kunnen via de WPS met hun bestanden geassocieerd worden.

Samenwerking en saamhorigheid is goed, maar het moet niet verstikkend worden. Zeker op systemen waar u tegen acute geheugenproblemen aanloopt, loont het de moeite om niet urgent benodigde programma's te deregistreren. Het deregistreren van WPS DLLs geeft zowel systemen met weinig als systemen met veel geheugen meer lucht.

Systemen met weinig geheugen (< 64 MB) hebben vooral behoefte aan vrij geheugen, maar door het verplicht laden van allerlei bibliotheken met de Workplace Shell neemt dit snel af. Hoe langer u op de WPS bezig bent, des te meer zal de swapper.dat groeien. Vanwege OS/2's vertraagd doorvoeren zullen de applicaties nog wel laden, maar het geheugengebrek geeft systeemoverhead en maakt dat uw applicaties trager lopen. De WPS word tergend traag en kan door ongeduldig muisklikken gemakkelijk vastlopen.

Op systemen met veel geheugen (>> 128 MB) zag ik een ander fenomeen. De WPS bleef responsief. Maar hoewel er nauwelijks gebruik gemaakt werd van het wisselbestand (swapper.dat < 4 MB) en er nog tientallen megabytes geheugen beschikbaar waren, weigerden programma's hun bibliotheken te laden en traden vreemde foutmeldingen op. De reden was geen gebrek aan werkgeheugen, maar een gebrek aan adresruimte in het gedeeld virtueel geheugen (shared arena). Het probleem was op te lossen door de WPS te resetten en de niet benodigde WPS bibliotheken te deregistreren. Voor de details zie: Geheugenbeheer van de Aurora kernel.

Het probleem van een volle shared arena is wat te vergelijken met Windows 9x en de systeembronnen. Als de 64 k systeembronnen volzitten worden onder Windows worden geen nieuwe vensters en iconen meer geopend. Vrij geheugen helpt niet. Zelfs het afsluiten van applicaties geeft die systeembronnen niet meer vrij. Meestal moet je rebooten. Als vanwege INI vervuiling vaak gebeurt moet u een schone installatie moet doen.

Zo ver gaat het onder OS/2 niet. Het betreft bepaalde applicaties. Applicaties die met forse bibliotheken de shared arena met de WPS delen maar nog niet in het geheugen geladen zijn: Lotus SmartSuite, StarOffice, Netscape, Mozilla en Virtual PC. Ik kon ze niet tegelijkertijd laden. Na het afsluiten van de ene applicatie, kon ik de andere weer laden. Maar de oorzaak was geen gebrek aan vrij geheugen, omdat er nog geheugen vrij was en de swapper.dat nog kon groeien. Bovendien kon ik nog tientallen CMD's en VDM's laden.

Achteraf realiseerde ik me dat na Mozilla de Werkplek met al zijn geregistreerde bibliotheken de grootste geheugenvreter in de shared arena was. Maar omdat de WPS bibliotheken al in de shared arena geladen waren traden hier geen problemen op. Maar de vele WPS bibliotheken veroorzaakten wel de laadproblemen bij andere programma's omdat ze virtuele geheugenplaatsen innamen die alleen met het afsluiten van PMShell (WPS reset) weer konden vrijkomen.

Na onderzoek met Theseus besloot ik de voor mij niet essentiële in de shared arena geladen WPS DLL's te deregistreren. Hiervoor gebruikte ik Class Manager (classman.zip). Class Manager geeft bij iedere geregistreerde WPS klasse (zeg maar functie) de benodigde DLL aan. Zo wordt de MultiMedia OS/2 functie MMMPG gekoppeld aan MMPARTS.DLL in MMOS2\DLL. Niet in het Libpath voorkomende DLL's moeten met het volledige pad worden opgegeven.

Maar het probleem is dat je van tevoren niet weet welke klasseregistratie wat doet. Het is daarom wel wijs van tevoren een backup van de WPS INI bestanden te maken. Ik deed dat met het onvolprezen Robosave.

De vraag is steeds welke WPS functionaliteit u echt op prijs stelt. De WPS functionaliteit van bepaalde WPS of PM programma's gebruikte ik niet en die kwamen als eerste aan bod om te deregistreren:

• De klassen van de Advantis dialer (AdvDialer, AdvUser, AdvAccount, AdvReg en AdvCust) gooide ik meteen weg. Ze hebben met het IBM global netwerk (ISP) te maken dat voor zover ik weet al niet meer bestaat.

• Het IBM UltiMail programma is verouderd: IBMUmailWPS kan ook weg. Het programma is ook zelfstandig te gebruiken.

• Andere programma's die veel WPS klassen registreren zijn: IBM's Voicetype en de IBM OS/2 Developer's Toolkit. De voorbeeldprogramma's uit de Toolkit zou ik zeker deregistreren.

• Uit Peter Moylans fameuze Warp 4 tuning tips begreep ik dat de klasse EzPlay met PnP te maken heeft (liet ik dus zitten). Deze klasse bleek bovendien niet vatbaar voor deregistratie te zijn.

• Voor IBM Works is een script verkrijgbaar (IWDEREG.CMD), maar het met Classmanager deregistreren van de met Fpw (Footprint Works) beginnende klassen werkt ook.

• MultiMedia voor OS/2 Presentation Manager (MMPM/2) is lastig onderwerp. Deels gaat het om echte WPS objecten die u waarschijnlijk niet kwijt wilt: Ik denk aan het volumeobject (classe MMvolume in MMParts) en de onvolprezen lichttabel MMshadow. Maar deels gaat het ook om objecten die door MMOS2 of andere programma's uitgevoerd kunnen worden. Denk aan PMview. Het geldt al helemaal voor audio en video. Zo zou het 1,5 MB grote MMPARTS.DLL behulpzaam moeten zijn bij het afspelen van MPG video's op de desktop. Door de associatie met de klasse MMMPG te wissen, lukt dat wellicht niet. Maar of u zich daar aan een buil aan zult vallen? Niet als u prima PM programma's als MPEG/2 of Video/2 gebruikt.

Ook pure WPS programma's zijn kandidaten voor deregistratie, maar hier moet u selectiever te werk gaan. Een WPS programma bestaat immers uit de associatie van een DLL met de WPS. Als u de functionaliteit van een WPS enhancer niet echt nodig hebt , of als het problemen geeft met de concurrentie (XWorkplace en ObjectDesktop) gooit u er een weg. Meestal laten WPS enhancers zich goed deïnstalleren. Dat is de gemakkelijkste weg. Als er geen script voor de deïnstallatie is (soms de setup.cmd met aangepaste parameters!) kunt u de klassen door Class Manager verwijderen. Na een reboot kunt de map desgewenst wissen. Als er toch nog bestanden door PMShell "gelocked" zijn, moet dat vanaf een noodpartitie of vanaf de Alt-F1 prompt. Ook kunt u een unlock utility gebruiken (repmod01.zip). INI ingangen van bibliotheken die niet meer op de schijf aanwezig zullen met checkini /c worden verwijderd.

Voor MMOS2 gaat het om \mmos2\install\dinstsnd.cmd en instmmvw.cmd met de -r optie. U kunt de systeemgeluiden ook uitzetten, maar dinstsnd levert tevens geheugenwinst op. Hierdoor zullen vertrouwde objecten verdwijnen. Maar met instsnd en instmmvw zet u de oude waarden terug. Met mmfix11.zip kunt u op maat deïnstalleren (bijv. wel bepaalde geluidsassociaties, maar niet de volumeknop en de lichttabel). De WPS integratie neemt wat af, maar de afzonderlijke programma's zullen gewoon blijven werken. De winst die u boekt bestaat uit toegenomen vrij geheugen, verhoogde WPS stabiliteit en een kleiner OS2.INI bestand. Voor meer info zie: OS/2 Tips.

Programma's die de grafische gebruikersinterface verfraaien (WPS enhancers) kunnen elkaar aanvullen, maar elkaar dwars zitten. Bijv. als ze ieder op hun eigen wijze iets met de vensters proberen te doen. Bekende WPS verfraaiers zijn NPS WPS enhancer, Nice voor OS/2, XWorkplace en Object Desktop. Meestal kunt u selectief bepaalde functies uitzetten. Als u ze niet meer gebruikt kunt u ze het best deïnstalleren. Dit voorkomt dat deze DLLs bepaalde gebieden in het in het virtueel geheugen (shared arena) bezet houden, wat het laden van andere programma's zal verhinderen. Ik kom hier in Geheugenbeheer van de Aurora kernel uitgebreid op terug.

LIBPATH en PATH zuiveren

> Top <

Een programma dat in het zoekpad (PATH=) vermeld staat kan vanuit iedere map opgestart worden. Hierbij kan het gebruik maken van de in het LIBPATH vermelde bibliotheken. Dankzij de punt in het LIBPATH vindt OS/2 ook DLL bestanden in de actieve directory. De punt in het LIBPATH is het symbool van de actieve directory. Een DIR .. geeft de directory lijst van de onderliggende map.

De zoekpaden worden van voor naar achteren doorzocht. De meest gebruikte mappen zet u dus vooraan. Houdt er echter rekening mee dat een verandering van de zoekvolgorde in het zoekpad soms weer nieuwe problemen geeft. Zo kunt u de netwerkbibliotheken die voor de punt staan (G:\IBMLAN\NETLIB;G:\MUGLIB\DLL;.) beter vooraan laten staan. Ook Netscape plaatst zichzelf voor de punt. Het kan van belang zijn bij installaties met de Feature Installer. Maar zet OS2\DLL liever achter de punt. Zo zag ik dat een verouderde WPTOOLS.DLL in OS2\DLL het opstarten van checkini verhinderde.

Het opdrachtverwerkingsprogramma zal bij de opdracht PROG eerst naar gelijkluidende interne opdracht zoeken, dan naar PROG.COM, dan naar een PROG.EXE en ten slotte naar een PROG.CMD bestand in de actieve map. Pas daarna wordt het pad doorzocht. Daarom kan een DIR.CMD alleen via een CALL opdracht worden uitgevoerd. DIR is een interne opdracht van het opdrachtverwerkingsprogramma CMD.EXE.

[G:\cmd]call dir.cmd 
[G:\cmd]echo test 
test 

Welke mappen behoren in het PATH en LIBPATH te staan? Systeembestanden en hulpprogramma's die door andere programma's aangeroepen worden, moeten in het zoekpad staan. Dergelijke bestanden moeten vanaf iedere locatie te vinden zijn.

Maar de mappen van EXE programma's die u alleen vanuit de WPS opstart, kunt u in de regel beter uit het PATH en LIBPATH verwijderen. Maak na een verandering altijd een backup. Met Copy and Paste en een REM opdracht voor het oude zoekpad kunt u later nog terug.

REM LIBPATH=G:\NETSCAPE\PROGRAM;G:\IBMLAN\NETLIB;G:\MUGLIB\DLL;.;G:\OS2\DLL;etc
LIBPATH=.;G:\IBMLAN\NETLIB;G:\MUGLIB\DLL;G:\NETSCAPE\PROGRAM;G:\OS2\DLL;etc

Opstarten vanuit de WPS kan alleen als het volledige pad in het WPS programma-object vermeld staat. Daarnaast moeten eventueel meegebrachte bibliotheken (*.dll) en initialisatiebestanden (*.ini) in dezelfde map staan als het uitvoerbare bestand. Gelukkig is dat gebruikelijk voor OS/2, zodat het fenomeen "DLL Hell" u bespaart blijft. Als de EXE en DLL bestanden in dezelfde map staan doet de punt in het begin van het LIBPATH de rest.

Een ander optie is het gebruik van: A Cool OS/2 Feature: LIBPATHSTRICT

Als er problemen ontstaan doordat EXE, INI en DLL bestanden gescheiden zijn, kunt u de map van de bibliotheek soms als werkdirectory opgeven, maar dit zal meestal betekenen dat een initialisatiebestand niet gevonden wordt. In dergelijke gevallen kunt u een cmd bestand aanmaken. Het zou er zo uit kunnen zien.

@ECHO OFF 
REM Batch voor sjoerd mbt programma PROGRAM 
SET USER = sjoerd 
SET PROGRAM.INI= f:\os2\bin\lan\program.ini 
SET BEGINLIBPATH= f:\os2\bin\lan\program\dll,f:\iets\en\is\goed
REM Applicatie (bijv. compiler) heeft de default van 20 + XX nodig
SET SHELLHANDLESINC=xx 
f: 
cd\ 
cd \os2\bin\lan\program 
start program 
exit 

De locatie van de bibliotheken wordt met de BEGINLIBPATH variabele aangeven. De variabele ENDLIBPATH voegt mappen aan het eind van het LIBPATH toe.

Als een INI bestand in f:\os2\bin\lan staat wordt het gevonden. Dat is de actieve directory als het programma opstart. Het SET PROGRAM.INI= f:\os2\bin\lan\program.ini is dan overbodig.

Ik wil er vooral mee aangeven dat u in CMD batches de omgevingsvariabelen voor afzonderlijke programma's (voor zover ze die ondersteunen) op maat instellen kunt. Dat is vooral handig voor TCP/IP programma's of programma's die u op verschillende manieren opstarten wilt. Dergelijke cmd bestanden plaats ik in een aan het PATH toegevoegde CMD map.

Presentation Manager

> Top <

Presentation Manager (PM) is de grafische gebruikersinterface (GUI) van OS/2. Presentation Manager presenteert de grafische uitvoer van uw programma's (sessies) in vensters. Als grafische schil vervangt PM de OS/2 opdrachtaanwijzing, die u alleen maar de voorgrondsessie liet zien. Onder PM ziet u de programma's naast elkaar. U schrijft in vensters. U kopieert tussen vensters. U maneuvreert met vensters en iconen. In combinatie met de object georiënteerde eigenschappen van de Werkplek biedt Presentation Manager u een bijna perfecte shell.

Tenminste - zolang de programma's het nog doen. Zolang ze de invoer van uw muis en toetsenbord blijven accepteren.

Presentation Manager als spin in het web

> Top <

Presentation Manager is een interface. Presentation Manager zit tussen u en uw programma's in. U kunt Presentation Manager beschouwen als een continue voorgrondsessie die uw programma's in beeld brengt.

Als u op de PM een tekstverwerker gebruikt of met de muis klikt, klikt u niet op het grafische programma, maar op een venster van het programma Presentation Manager.

De programma's krijgen uw informatie via PM en geven hun informatie aan PM door.

Hoewel uw programma's naast elkaar draaien, kan steeds maar één applicatie de invoer van de muis en/of het toetsenbord accepteren. Als u in een tekstverwerker schrijft, dan moet de voorgrondsessie die de focus heeft (het actieve venster), weten waar uw tekst moet komen te staan. PM zal het programma daarover informeren. PM plaatst uw invoer in een bericht (message), waar het programma wat mee moet doen. Het programma stuurt vervolgens een bericht naar PM om aan te geven wat het er mee wil doen. Net als op de prompt is het niet vanzelfsprekend dat u dezelfde tekst terug krijgt (output) als u invoert (input): type maar eens DIR op de prompt (een VIO sessie). Hetzelfde gebeurt in een tekstverwerker met een Autocorrect functie. Het programma interpreteert uw invoer en laat haar interpretatie aan PM weten. PM geeft het vervolgens weer op het scherm.

Alle programma's moeten goed met Presentation Manager samenwerken. Er zijn programmeerregels opgesteld om die samenwerking goed te laten verlopen. Vergelijk het met een vergadering. Hier gelden ook regels. Zo kan er steeds maar één spreker zijn. Wil het ene programma het andere programma met een pop-up menu interrumperen, dan kan dat alleen maar via voorzitter PM. PM beheert de microfoon. En er is steeds maar een venster actief. PM maakt gebruik van zogenaamde semaforen om die noodzakelijke wederzijdse uitsluiting af te dwingen. Semaforen zijn te vergelijken met verkeerslichten. Met dit verschil dat door rood licht rijden uitgesloten is. OS/2 legt dit als beheerder van de bronnen dwingend op. Maar PM kan niet voorkomen dat een programma veel spreektijd neemt. En dat hierdoor een wachtrij voor de microfoon ontstaat. Zo zorgen semaforen en wachtrijen voor de noodzakelijke synchronisatie, maar ook voor oponthoud.

Het single input queue of single message queue probleem

> Top <

In een grafische multitasking omgeving klikt u niet rechtstreeks in uw programma's, maar in de vensterbeheerder die uw acties (gebeurtenissen) één voor één aan zijn venstergebruikers doorgeeft. Uw invoer in de vensters van Presentation Manager wordt in eerste instantie in een enkele PM invoerwachtrij (single input queue, SIQ) geplaatst: bijvoorbeeld het typewerk in venster A en uw muisklik in venster B. De bij de venster behorende PM programma's A en B lezen deze berichten één voor één (asynchroon) uit. Pas als een bericht door programma(draad) A geaccepteerd is, komt programma(draad) B aan bod.

Hiermee wordt invoerwachtrij van Presentation Manager de flessenhals in het grafische OS/2 systeem. Normaal zou dat geen probleem mogen zijn, want het gaat om interrupt gestuurde invoer via de hardware. En dat snelle aanbod van informatie via de hardware moet nu eenmaal binnen fracties van een seconde worden afgewerkt. En natuurlijk in de juiste volgorde. Want om de logische volgorde van uw klik- en typewerk recht te doen - u klikt bijvoorbeeld eerst op knop A en dan op knop B, moet de ontvangst van de muisklik B natuurlijk wel wachten op die van muisklik A. Daarom wacht PM eerst op de ontvangst van bericht A, alvorens hij B bestelt.

Maar in dat "logisch" op elkaar wachten zit het probleem. Als PM de systeemberichten m.b.t. uw toetsenbord- en muisacties voor de aan de beurt zijnde programmadraad niet afhandelen kan, komen andere programma's die ook op uw invoer via de muis en het toetsenbord (gebeurtenissen) zitten te wachten niet meer aan bod.

De enkele wachtrij werkt dan als een rigide postbesteller, die, als hij één pakket niet door de bus krijgt, de rest van de post niet meer besteld. Of als een meer herkenbare situatie: Als u bijna aan de beurt bent bij de caissière, degene die voor u is uitgebreid beklag gaat doen ...

Als de PM hardware invoerwachtrij in één vensterdraad faalt, kunt u wel tikken en klikken, maar uw opdrachten komen niet meer aan. Want er is maar één (single) invoerwachtrij (input queue). Uw muisklikken worden slechts in de groeiende invoerwachtrij gezet. En omdat u onder Presentation Manager werkt, lijkt het alsof het hele systeem is vastgelopen. De programmadraden die de PM vensters lanceerden ontvangen de gebeurtenissen van uw muis en het toetsenbord niet meer.

Dit staat bekend als het single input queue (SIQ) probleem. Het treedt op als bepaalde draden van PM programma's niet of niet snel genoeg op hun muis en toetsenbord invoer via Presentation Manager reageren.

Achtergrondprocessen die niet van PM's grafische invoer afhankelijk zijn (netwerk) draaien gewoon door. Het besturingssysteem is niet vastgelopen, maar haar grafische interface is op de communicatie met een enkel VIO venster, PM of WPS programma gestrand.

Berucht zijn de situaties waarin een PM of WPS programma de afhandeling van langdurige (>0,1 s) taken niet meteen delegeert naar een afzonderlijke draad, maar hier eerst op wacht. Zo'n de SIQ ophoudend programma doet dan niet aan fatsoenlijke meerdradige multitasking. Zoals de uw caissière ophoudende zeurpiet niet gewoon afrekent, en zich tevens voorneemt om beklag te doen bij de winkelmanager. Maar dit "tevens" impliceert het creëren van een aparte draad, en net als mensen houden niet alle door mensen geprogrammeerde programma's er onder sommige omstandigheden rekening mee dat ze niet de enige op aarde zijn...

Overigens wil ik de OS/2 PM programmeurs niets verwijten. De door Microsoft als PM ontwikkelaar en IBM als eindverantwoordelijk te stellen SIQ problematiek was al lange tijd een voor iedereen toegankelijk (publiek) taboe. Iets wat wel opgevallen was, maar waar liever niet openlijk over werd gesproken. Want ze waren ook al bij de met het besturingssysteem geleverde programma's binnengeslopen. En de documentatie van OS/2 Presentation Manager was summier. Want Microsoft en IBM hadden er alle belang bij om met hun geavanceerde meerdradige OS/2 Presentation Manager technologie een voorsprong op andere programmaontwikkelaars te houden.

Een klassiek voorbeeld van "hoe het niet moet" is een zoekactie met view.exe. Volgens de regels der OS/2 programmeerkunst (CUA, Common User Access) moet view.exe binnen 0,1 sec nadat het de opdracht gekregen heeft om Alle bibliotheken op een trefwoord te doorzoeken - Presentation Manager een bericht sturen in de trant van: "Okay, zoekopdracht begrepen, ik ga aan het werk". Dan weet PM dat het bericht is aangekomen en komen de muisaanwijzer en het toetsenbord weer vrij. Vervolgens moet View een afzonderlijke draad starten om op de achtergrond te zoeken. Maar view.exe informeert PM pas als hij klaar is met de zoekopdracht. Tijdens de zoekactie ziet u een zandloper en kunt u slechts wachten. View is gelukkig een robuust programma dat er met de zoekactie wel uitkomt, maar als een programma dat dit mankement vertoont vastloopt en door een volle SIQ niet meer af te sluiten is, ontstaat een groot probleem.

Strikt genomen is het SIQ probleem een applicatieprobleem. Want de SIQ ophoudende applicatie voldoet niet aan de CUA (binnen 0,1 s een response) principes. U doet er daarom goed aan een reproduceerbaar SIQ probleem bij de auteur te melden. Misschien dat het in de volgende release wordt gerepareerd. U kunt het vastlopen voorkomen door de functie (draad) die het probleem luxeert niet meer te gebruiken. Het afsluiten van het disfunctionerende programma lost het probleem ook op (zie verder).

Maar in de praktijk is het zelden evident welke functie van welk programma op een bepaald moment de boosdoener is. Kom daar maar eens achter als meerdere programma's (inclusief de multithreaded WPS) onder Presentation Manager draaien. Een goed functionerend OS/2 systeem is een hectische vergadering van programma's waarin de proces(microfoon)wisselingen in rap tempo plaatsvinden. Veel situaties zijn niet eens reproduceerbaar. Maar toch komt het vastlopen van PM met bepaalde programma(combinatie)s steeds weer terug. Maar als u de oorzaak van die reproduceerbare fouten niet herkent kan gemakkelijk de indruk ontstaan van een instabiel grafisch OS/2 systeem.

Een voorbeeld: Een Larsen Commander gebruiker klaagde eens dat hij OS/2 minimaal eenmaal per dag moest rebooten en Windows NT nooit. Hij weet dit aan OS/2. Maar ik vermoed dat het hier om een wat verouderde versie van de OS/2 Larsen Commander ging:

Subject: [WarpCast] Larsen Commander 0.93. Changes since the previous public release: Major redesign of the way that a file object is launched from file panels. This fixes the problem that caused VIO programs to be executed in a background window. They are now launched in the foreground Z-order as they should. This change also fixed the problem that Larsen Commander did lock the Single Input Queue of OS/2 when launching WAV-files (among others).

De gebruiker heeft tijdens zo'n SIQ lock een niet op de muis of het toetsenbord reagerend systeem. Er verschijnen pop-up berichten die melden dat toepassingen niet meer op de berichten van het systeem reageren. Maar de toetsen waarmee die niet-reagerende programma's beëindigd zouden moeten worden werken niet. De muis- of toetsenbordacties voor PM programma's komen niet aan. In ieder geval niet via de berichtenwachtrij die PM daarvoor hanteert. Dat is een pijnlijke designfout van de Presentation Manager van OS/2.

IBM heeft het single input queue probleem helaas nooit structureel aangepakt. Waarschijnlijk moeten bij het alsnog invoeren van hte NT model met meerdere synchrone wachtrijen, waardoor de programma's niet per definitie op elkaar hoeven te wachten, veel oude OS/2 programma's herschreven worden. Dat zou OS/2 de das om doen. Gevreesd wordt dat maar weinig OS/2 ontwikkelaars bereid zijn om hun programma's voor zo'n verbeterde PM te herschrijven. Als de OS/2 programmeurs er nog zijn. Want de bedrijven die dergelijke programma's gebruiken zouden hun oude OS/2 applicaties (bij het gebrek aan geoefende OS/ programmeurs) wellicht sneller naar NT of Java kunnen herschrijven.

Ironisch is dat juist Microsoft, die Presentation Manager ontwikkelde, ooit op het behoud van deze asynchrone (stap voor stap) message queue heeft aangedrongen. Dat zou het porteren van Windows 3x code naar OS/2 vergemakkelijken. Maar nu werkt die "coöperatieve"designkeuze voor OS/2 als een val. Want Microsoft gaf Windows NT wel meerdere message queue's mee. De NT message queues werken onafhankelijk van elkaar (synchroon). Daardoor zijn programma's die niet op een bericht uit één wachtrij reageren via een andere wachtrij wel grafisch af te sluiten. Omdat Windows NT en zijn navolgers Windows 2000, XP en Vista niet over een van de grafische modus onafhankelijke tekstmodus schil (DOS, CMD) beschikken is dat natuurlijk ook wel essentieel.

Linux en OS/2 hebben het voordeel dat veel cruciale programma's (netwerk) de grafische interface niet hoeven te gebruiken. Ook onder Linux komt het probleem dat een X server niet meer op de muis en het toetsenbord (incl. Alt-F2) reageert regelmatig voor. Maar met een telnet sessie kan de X-server afgesloten worden. Onder OS/2 is de CLI applicatie als Watchcat een oplossing. Evenals het met de CAD handler te activeren Top. Dergelijke niet-PM programma zijn via een speciaal stuurbestand en een sneltoets (hotkey) te activeren, waarmee ze buiten Presentation Manager om geladen worden.

De zogeheten SIQFix

> Top <

Met de zogeheten SIQFix van Aidon Jennery in Warp 4 en FP 17 (1996) kwamen er wat doekjes voor het bloeden. Maar de zandlopermuis tijdens een zoekactie van view zal hier niet door verdwijnen.

De eerste SIQFix kunt u instellen onder Configuratie / Weergave / Invoer / Asynchrone focustoewijzing of direct in de CONFIG.SYS:

SET PM_ASYNC_FOCUS_CHANGE=ON 4000 

Deze instelling zorgt ervoor dat een PM sessie, die niet binnen 4 seconden (4000 ms) op een bericht van PM dat de focus (het actieve venster) gewijzigd wordt, reageert, automatisch de focus verliest. Het venster wordt door het systeem op non-actief gesteld (bad window). De microfoon wordt weggehaald. Pas als het betreffende programma de berichten van het systeem weer leest, mag het aan de vergadering der PM vensters meedoen en is het weer te activeren.

Vòòr de SIQFix (en nog steeds als u deze CONFIG.SYS ingang nog niet heeft ingevoerd!) kon een OS/2 programma dat een bericht van wisseling van focus negeerde de muisaanwijzer in zijn venster gevangen houden (het venster wacht op SIQ input, maar het zal er nog niet op reageren, wat met een zandloper aangegeven word), totdat u het programma met het door Ctrl-Esc opgeroepen Taakoverzicht zou proberen te beëindigen.

Die afsluitfunctie van het Taakoverzicht maakt voor de SIQFix altijd gebruik van een WM_QUIT bericht. Dit is de opdracht Bestand/Beëindigen (Alt-F4) of de X in de rechterbovenhoek van het PM venster. Dit start een afsluitroutine waardoor het programma netjes afgesloten wordt. Een goed geschreven PM programma zal u via een dialoogvenster nog in de gelegenheid stellen om gewijzigde bestanden op te slaan. Daarna zal het zichzelf beëindigen. Maar zo'n vriendelijk verzoek om af te ronden heeft weinig effect op een programma dat niet op de berichten van PM reageert.

Met de SIQFix krijgt een op non-actief gesteld programma daarom een DosKillProcess opdracht. Hierbij gaan niet opgeslagen gegevens verloren. Een programma dat wel op de berichten van PM reageert krijgt nog steeds een WM_QUIT bericht, waardoor het normaal afgesloten wordt.

Naast het Taakoverzicht kan ook WarpCenter als een proces killer optreden met de CONFIG.SYS ingang:

SET KILLFEATUREENABLED=ON 

Klik met de linker muisknop op de venster pictogram met de Control toets ingedrukt: U krijgt een overzicht van de lopende processen. Door er nog eens op te klikken kan een applicatie afgesloten worden. Er wordt om een bevestiging gevraagd (tenzij: SET KILLCONFIRMDISABLED=ON).

Voordeel van WarpCenter is dat ook met detach gestarte programma's zichtbaar zijn.

Een strategie bij vastlopers

> Top <

Hoe werkt het nu in de praktijk? Om te beginnen zou ik de SIQFix altijd activeren. Niet alleen vanwege de timer, maar ook vanwege de verbeterde afsluitmogelijkheden van Warp Centre en het Taakoverzicht.

SET PM_ASYNC_FOCUS_CHANGE=ON 4000 
SET KILLFEATUREENABLED=ON 

De standaardwaarde is uit (off). De instelwaarde in milliseconden zal afhangen van de belasting van uw systeem. In ieder geval bereikt u hiermee dat een programma dat niet binnen de gestelde periode op de berichten van het systeem, wat PM betreft op non-actief gesteld wordt. Zo'n programma krijgt overigens nog wel processortijd. Zo kan het zijn taken afmaken en zich alsnog bij PM melden. Denk aan de zoekactie van view.

Een programma dat niet op berichten van PM reageert kan ook vastgelopen zijn en maar processortijd blijven opeten. In dat geval kunt u niet doorwerken en moet u het programma beëindigen. Daartoe roept u met Ctrl-Escape het Taakoverzicht op.

Maar als Presentation Manager zich in het SIQ probleem heeft verslikt, is het nog maar de vraag of u het Taakoverzicht en andere PM programma's kunt besturen. Alle programma's die via de SIQ invoer wachtrij van Presentation Manager met u communiceren zullen hieronder lijden. Daarom is een programma als Watchcat (zie verder) dat niet van PM afhankelijk is ideaal.

Zonder een dergelijke oplossing moet u bij een SIQ probleem geduld hebben en de sneltoetsen van het systeem gebruiken: Ctrl-Escape, Alt-Tab en in noodgevallen Ctrl-Alt-Del. Deze toetsenbordcombinaties staan niet onder beheer van het programma Presentation Manager, maar worden door de toetsenborddriver van OS/2 onderschept. Vandaar dat ze vrijwel altijd reageren.

Enig geduld kan nooit kwaad. Schrijf de programma's die actief zijn op. Bedenk dat programma's het SIQ probleem veroorzaken. Als u de omstandigheden die steeds problemen geven identificeert, kunt u ze vermijden. Terwijl u een paar minuten wacht en noteert kan het zijn dat een niet reagerend programma alsnog reageert. OS/2 blijft een multitasking besturingssysteem. Andere programma's die niet van uw invoer afhankelijk zijn kunnen hun taken daarom afmaken. Bijvoorbeeld een download afronden. Als ik StarOffice om de 5 minuten een bestand zonder bevestiging (geen PM popup menu) automatisch laat opslaan, ben ik mijn tekst niet kwijt. Ik maak altijd wel gebruik van de backup optie, want met een ongelukkige knip- en kopieeractie kan het automatisch opslaan van een ongewenste wijziging heel vervelend zijn...

Het maneuvreren met de sneltoetsen Alt-Tab of Control-Escape zal meestal aanleiding geven tot de foutmelding dat een bepaald programma niet meer op systeemopdrachten reageert. Het oproepen van het taakoverzicht (Ctrl-Esc) is sinds OS/2 v 2.1 een tijdkritisch proces. De sneltoets Control-Escape activeert naast het Taakoverzicht ook een timer (waakhond, watchdog) die programma's een bepaalde tijd geeft om zich te melden. Als een programma niet tijdig reageert, wordt dit in een pop-up menu aangegeven. Met Enter kunt u het beëindigen. Bedenk echter wel dat met een geblokkeerde SIQ wachtrij en/of een hoge processorbelasting maar weinig programma's in staat zijn zich tijdig te melden! En dus wordt vrijwel ieder programma als niet-reagerend aangemerkt. Ze een voor een beëindigen heeft dan weinig zin.

Beter is het in een dergelijk geval de hulp van Watchcat in te roepen. Watchcat geeft in grote lijnen aan hoeveel % van de tijd een programma de processor bezet. U sluit dan niet willekeurig af, maar begint met de programma's die het systeem het meest belasten. Een hoge processorbelasting van PMShell moet u accepteren, maar als Netscape op 99% CPU-use zit, gooit u Netscape er meteen uit. Als het systeem daarna minder belast is gaat u met Escape terug naar PMShell om te zien of het probleem is opgelost.

Het afsluiten van niet benodigde programma's zal het systeem verder ontlasten. Als het systeem nog responsief genoeg is kunt u gegevens opslaan. Maar vaak is dat niet het geval. Begin dus maar met de onder de WPS gestarte gebruikersprogramma's zonder data. PM programma's kunt u met watchcat afsluiten. WPS programma's alleen maar onder de WPS. Als dat niet lukt kunt u de WPS herstarten (XWP heeft een goede tool). Met detach gestarte servers sluit ik nooit af. Ze veroorzaken geen SIQ probleem. En andere programma's zijn er van afhankelijk.

Soms brengt u weer leven in de brouwerij door een hardware-interrupt te genereren: druk eens op de uitwerp knop van de CD-Rom. Dit kan ook helpen als u te lang op de Control-Alt-W van Watchcat, op een shutdown of een reset van de WPS wacht.

Als laatste optie hebt u Control-Alt-Del (soms twee keer CAD nodig) om een niet responsief systeem af te sluiten. Maar gebruik liever de gecontroleerde shutdown optie van Watchcat.

Watchcat

> Top <

Het is handig om een hulpprogramma te hebben dat buiten PM Shell te benaderen is. Net als onder Linux is bij een niet reagerend toetsenbord de telnet daemon een optie. Maar het shareware programma Watchcat (wcat21.zip, 1995) is in deze materie gespecialiseerd. Stardocks Process Commander is op Watchcat gebaseerd.

Watchcat maakt gebruik van het stuurbestand watchcat.sys dat de sneltoets Ctrl-Alt-W (of een andere combinatie van toetsen) buiten het virtuele toetsenbord van Presentation Manager opvangt. Met een goed gekozen sneltoets is Watchcat bijna altijd oproepbaar. Ook tijdens het SIQ probleem. Ik gebruik Watchcat met een kortere sneltoets (Ctrl-F10). Deze wordt beter onderschept dan de Ctr-Alt-W. De Ctrl-F10 van StarOffice is gedeactiveerd.

De geregistreerde versie van Watchcat kan ook randapparatuur als een seriele poort of een joystick gebruiken.

Na het onderscheppen van de sneltoets wordt het programma Watchcat op het volledig scherm gestart. In tekstmodus zijn de muis en het toetsenbord tijdens een SIQ probleem normaal te benaderen. Het gaat immers om een PM probleem. OS/2 blijft stabiel.

Zoals u in de afbeelding ziet is hier allerlei informatie op te vragen. In dit geval gaat het om de lijst van processen en de draden van ieder proces.

Door op Kill process te klikken kunt u een dolgedraaide StarOffice buiten de Presentation Manager om afsluiten.

Maar ook hier heeft een WM_QUIT de voorkeur. Het voordeel van WM_QUIT is dat het programma netjes afgesloten wordt. Maar dit werkt alleen als het programma nog enigszins met de shell Presentation Manager samenwerkt. En een PM dialoogvenster "Gegevens opslaan?" kunt u vanuit Watchcat natuurlijk niet beantwoorden. Als u niet in PM komt sluit u met een tweede WM_QUIT ook dat dialoogvenster maar af.

Kill process beëindigd het geselecteerde proces. Kill all sluit alle processen met die naam (bijv. NETSCAPE.EXE) af. Helaas blijken veel programma's signalen als Ctrl-C en Ctrl-Break te onderscheppen. Om die reden wordt het SIQ probleem ook wel als een afsluitprobleem gezien. Onder UNIX zou u een niet op SIGTERM (kill -15 PID) reagerend proces, na enige seconden een niet te onderscheppen SIGKILL bericht (kill- 9 PID) sturen. Maar deze UNIX opdracht is niet in OS/2 geïmplementeerd.

OS/2 gebruikers beschikken echter over Eberhard Mattes Emulate Unix (EMX) bibliotheek. Met het XF86SUP.SYS stuurbestand van Holger Feit of de hierop gebaseerde HKILLDD.SYS driver uit het pakket killenh.zip kunt u de Watchcat Add-On Wkill9.zip installeren. U vindt ze op Hobbes (ftp://hobbes.nmsu.edu) in de submappen system en process van pub/os2/util. Daarna beschikt ook Watchcat over krachtige afsluitmogelijkheden. Tevens bestaat een prachtige Watchcat Addon in de vorm van wnice.zip, waarmee u de prioriteiten van de processen dynamisch kunt aanpassen (Zie: Prioriteiten stellen).

Maar het bruut afsluiten van programma's is echter nooit zonder risico's. Niet opgeslagen gegevens gaan altijd verloren. Het programma wil soms later niet meer opstarten. Bijvoorbeeld als een geopend configuratiebestand niet adequaat werd bijgewerkt. Als u pech hebt wist de eerst volgende checkdisk het bestand. Ook de systeembronnen van de bruut afgesloten processen worden niet altijd correct vrijgeven. Onder Windows, OS/2 en NT zijn de grafische processen nauw met het besturingssysteem vervlochten. Een X server of een Werkplek kunt u herstarten, maar een als protshell opererende Presentation Manager niet. De snelheidswinst die deze integratie oplevert heeft consequenties voor de stabiliteit van het besturingssysteem. Het beperkt uw mogelijkheden om processen af te sluiten. Uiteindelijk zult u toch moeten afsluiten (shutdown) en een checkdisk laten uitvoeren. Een WM_QUIT heeft daarom steeds de voorkeur.

Processen besturen

> Top <

Automatiseer door het gebruik van batches en scripts

Een GUI is aardig om een overzicht te krijgen van de vele mogelijkheden van de PC, maar als u iets vaker doet is het handiger om een eenvoudig batch.cmd bestand aan te maken en deze in een uw pad aanwezige map /cmd of /batch in het pad te plaatsen.

Een batch voert een procedure uit. Een reeks van opdrachten. De procedure kan interactief zijn - of wel zo effciënt - niet interactief en/of door parameters gestuurd.

Heel vaak voert de GUI al een procedure voor u uit. Denk hierbij aan het opstarten van een programma. De belangrijkste variabelen kunt u via het instellingenblok van het propgramma beinvloeden. Zo kunt u het volledige pad en de werkdirectory instellen van een programma (de map van bestand openen). Een vraagteken in het Parameters instellingenblok geeft u de mogelijkheid om interactief opstartparameters op te geven. In Netscape kunt u ook opgeven welke gebruiker u bent ( -l nl_NL \Psjoerd). Het op Netscape gebaseerde mozilla geeft de opstartopties netjes aan. Netscape -h doet dit helaas niet.

F:\WARPZILLA\bin>mozilla /? 
Usage: F:\WARPZILLA\bin\mozilla.exe [ options ... ] [URL] 
where options include: 
-height <value> Set height of startup window to <value>. 
-h or -help Print this message. 
-installer Start with 4.x migration window. 
-width <value> Set width of startup window to <value>. 
-v or -version Print F:\WARPZILLA\bin\mozilla.exe version. 
-CreateProfile <profile> Create and start with <profile> 
-P <profile> Start with <profile>. 
-ProfileWizard Start with profile wizard. 
-ProfileManager Start with profile manager. 
-SelectProfile Start with profile selection dialog. 
-nosplash Disable splash screen. 
-quiet Disable splash screen. 
-compose <url> Start with messenger compose. 
-edit <url> Start with editor. 
-mail Start with mail. 
-chrome <url> Start with browser. 
-addressbook Start with the addressbook. 
-jsconsole Start with Javascript Console 
-news Start with news. 

Voordelen zijn van het werken met scripts en batches zijn:

• U kunt gecompliceerde procedures in een keer uitvoeren.

• Batches staan hierbij een modulaire opbouw toe.

• U kunt omgevingsvariabelen op maat bepalen (SET USER, BEGINLIBBPATH).

• De hier genoemde variabelen kunnen buiten het systeempad blijven

• Bij wachtwoorden (telnetd) is dat wel zo discreet.

• U kunt programma's met een aangepaste prioriteit starten (zie verder).

• U kunt vanaf de opdrachtregel uw favoriete programma's zonder gezoek opstarten.

• U bent minder van specifieke PM problemen afhankelijk.

Kortom meer snelheid en flexibiliteit! En dat geldt zowel voor een eenvoudige script voor het OS/2 opdrachtverwerkingsprogramma cmd.exe, als voor ook op andere platforms inzetbare script-, macro- en programmeertalen als rexx, bash (sh) en perl.

Nuttige link: Windows 95 / DOS 7 Batch Programming werken ook onder OS/2.

Processortijd verdelen

> Top <

Een besturingssysteem dat gebruik maakt van time-slicing geeft alle taken evenveel processortijd. Het nadeel hiervan is dat er geen onderscheid wordt gemaakt tussen belangrijke en minder belangrijke taken. Op een besturingssysteem waar al gauw meer dan 100 draden lopen, moet een speciale strategie worden gevolgd.

Het onderhouden van een actieve TCP/IP netwerkverbinding door Injoy heeft meer recht op processortijd (prioriteit) dan het wachten op een toets in een Netscape formulier. Als een serveerproces vertraging ondervindt zullen alle daarvan afhankelijke programma's daaronder lijden. Ze staan in de file. Ze krijgen misschien wel processortijd, maar kunnen nog niets doen.

OS/2 bepaalt van te voren hoeveel processortijd een taak toebedeeld krijgt. Een belangrijke taak krijgt eerder processortijd dan een onbelangrijke (priority based scheduling). Als een belangrijke taak processortijd nodig heeft, wordt een minder belangrijke taak tijdelijk onderbroken (preemptive multitasking). De prioriteiten worden aan de heersende omstandigheden aangepast. De dispatcher (verdeler, process scheduler) kiest uit het aanbod van op processortijd wachtende draden, de draad die het eerst aan bod komt. Hiervoor zijn beslissingsschema's (algoritmen) ontworpen. De programmeur van het programma (die de noden van zijn programma het beste kent) helpt OS/2 hierbij, door iedere uit te voeren draad een bepaalde prioriteit mee te geven.

Programma's draaien onder OS/2 als draden. Een single-treaded programma heeft een draad. Een multithreaded programma heeft twee of meer. Iedere draad krijgt minimaal een time-slice (standaard 32 ms) processortijd. Draden draaien in vier hoofdklassen van prioriteit. Binnen een hoofdklasse bestaan er weer subschalen met waarden van 0 t/m 31 ("Delta" 00-1F) . Dat geeft 4 maal 32 is 128 gradaties in prioriteit.

De draden met de hoogste prioriteit komen het eerst aan bod. Eerst komen de tijdkritische (prioriteit 3) en daarna de andere systeemprocessen (prioriteit 4). Daarna komen de gewone gebruikersprocessen (gewone programma's , ook spelletjes en servers) met prioriteit 2 aan bod. Na maximaal MAXWAIT seconden komen ook achtergrondtaken met normale prioriteit (2) in de wachtrij aan bod.

Draden met de laagste prioriteit (idle priority) krijgen alleen processortijd als alle op processortijd wachtende draden met normale (99%) of verhoogde prioriteit al geweest zijn. In theorie kunnen ze dus heel lang wachten, maar in de praktijk (we hebben nu supersnelle procesoren) valt het wel mee. Bovendien krijgen ze met PRIORITY_DISK_IO=YES een priority boost als ze de vaste schijf benaderen. En krijgen ze een

Draden met idle priority draaien dus pas als er processortijd over is. Een virusscanner die op de achtergrond de hele vaste schijf doorzoekt zou u met idle priority kunnen laten draaien. En caches legen de cache bij voorkeur op een rustig moment. Als een proces met hogere prioriteit zich aandient wordt een draad met idle priority preëmptief onderbroken.

De meeste OS/2 programma's draaien met gewone prioriteit (2 Delta 0, regular priority). Dit geldt ook voor PM spelletjes en veel servers. Maar op het moment dat u er iets mee doet, lopen ze in de praktijk sneller (zie verder: priority boost)

Tijdkritische draden (netwerk, communicatie, audio, timers) mogen niet op processortijd wachten. Een tijdkritisch proces dat om processortijd vraagt, wordt onmiddellijk (< 6 ms) bediend. Het lopende proces zal hiervoor worden onderbroken. Voorbeelden zijn: peer.exe, midimon.exe, cntrl.exe.

Taken die met server prioriteit lopen hebben enige voorrang boven de gewone programma's. Voorbeelden zijn: nbtcp.exe, pmshell (gedeeltelijk), Injoy (gedeeltelijk). De gebruikersinterface van een server zal vrijwel altijd met gewone prioriteit lopen.

DOS en Win-OS/2 programma's lopen met gewone prioriteit. Dit niveau is weer te graderen zoals u in de DOS instellingen van bijv. Win-OS/2 kunt zien. Standaard beginnen ze met Regular priority +1 (SESSION_PRIORITY). Als een programma een tijdje (IDLE_SECONDS) niets nuttigs doet, dan zakt het op de prioriteitenlijst.\

Als een nauwelijks actief DOS programma de processor belast moet u IDLE_SENSITIVITY lager instellen. Dit speelt bijvoorbeeld als WP voor DOS het toetsenbord polt. De standaardwaarde van 75% leidt gemakkelijk tot een onnodige hoge processorbelasting. Met een IDLE_SENSITIVITY van 5-15% is het DOS programma in de praktijk even snel, maar wordt OS/2 niet door de CPU intensieve poltechniek van DOS belast.

Opvallend is dat de prioriteiten van OS/2 programma's niet via een instellingenblok in te stellen zijn. In feite vraagt OS/2 alleen maar naar het pad en de bestandsnaam. Het instellen van de aanvangsprioriteit van een bepaalde draad is een taak voor de programmeur. Hier zijn richtlijnen voor opgesteld. Zo zal een draad die vitale communicatie onderhoudt als een server mogen lopen, terwijl de gebruikersinterface van een communicatieprogramma met normale prioriteit loopt.

Daarnaast past OS/2 de prioriteit waarmee een OS/2 programma's draait dynamisch aan. Dit wordt met PRIORITY = DYNAMIC aangeven. Dit is een standaardwaarde die niet expliciet in de CONFIG.SYS hoeft te staan. Hierbij krijgen in de praktijk interactieve sessies een hogere prioriteit dan achtergrondprocessen.

OS/2 houdt een soort hitparade bij van programma's die haar aandacht moeten hebben. De top 10 wordt het meest gedraaid. Servers met hoge prioriteit en tijd-kritische processen komen gemakkelijk aan de beurt. Maar hoe komt een gewoon programma dan aan de beurt? Laat staan een achergrondproces dat met prioriteit 1 loopt? Dit wordt met PRIORITY = DYNAMIC geregeld.

Gewone programma's krijgen regelmatig een priority boost. Zo'n oppepper (boost) zorgt ervoor dat een op processortijd wachtende draad even met bijna tijdkritische prioriteit loopt. Ook als is het programma oorspronkelijk met de laagste prioriteit (idle priority) opgestart. Zijn draad zal hierdoor een rondje processortijd krijgen.

De priority boosts van de standaard OS/2 Desktop instelling () zijn:

• Ieder actief (lees: door u geselecteerd) venster krijgt een foreground boost.

• Daarnaast krijgen alle interactieve sessies die tekst of grafiek in hun venster willen schrijven krijgen een keyboard of windowed priority boost.

Deze twee maatregelen zorgen ervoor dat al uw voorgrondprogramma's responsief blijven. Een met lage prioriteit opgestart proces loopt door de foreground boost tijdelijk sneller dan normale applicaties zodra het in beeld komt. En ook interactieve achtergrondsessies krijgen meer prioriteit zodat ze hun venster moeten bijwerken. Hierdoor blijven uw venstergegevens actueel.

• Programma's die recent een I/O (lees- of schrijf)opdracht voltooid hebben krijgen met PRIORITY_DISK_IO=YES een Input/Output boost.

Programma's die de vaste schijf benaderen worden tijdens de lees of schrijfactie geblokkeerd. Maar dan komen ze wel weer achterin de wachtrij. Als de I/O actie voltooid is, zullen ze deblokkeren om de gegevens te verwerken of iets anders te doen. En met de instelling PRIORITY_DISK_IO=YES mogen dan meteen aan de slag.

Op die manier zal een met laagste prioriteit (1 0) opgestarte mencoder of ffmpeg ineens veel processortijd (vaak 99.9%) krijgen. Want het schijfintensieve codeerwerk levert aldoor input/output priority boosts op. Het kan er zelfs toe leiden dat de WPS (die met normale prioriteit loopt) trager reageert. In dat geval kunt u mencoder afremmen met PRIORITY_DISK_IO=NO.

• Programma's met normale prioriteit (delta 2) die niet aan bod komen krijgen na MAXWAIT seconden een starvation boost.

Om te voorkomen dat onder het top 10 tien geweld van servers en voorgrondtaken, achtergrondtaken met normale prioriteit nooit aan bod komen (versterven, starvation), is de MAXWAIT variabele ingesteld. Dat is het maximaal aantal seconden (1-255, standaard 3) dat een gereed staande draad hoeft te wachten voordat het via een starvation boost de aandacht van de processor krijgt. Op een snelle PC met ruim hoofdgeheugen kunt u MAXWAIT gerust op 1 of 2 seconden zetten. De standaardwaarde van 3 stamt nog uit de tijd dat een 25 MHz PC met 16 MB een power systeem was. De starvation boost laat de draad kortdurend nèt onder time-critical priority lopen. Zo komt die gereed staande achtergrondtaak toch aan bod. Als het zijn status niet door een I/O operatie of anderszins opkrikken kan, wordt de draad na een minimale hoeveelheid (timeslice) processortijd opnieuw maximaal %MAXWAIT% seconden inactief.

Een draad met normale prioriteit moet na %MAXWAIT% seconden aan bod komen. Hiermee wordt versterving voorkomen. Zo nodig zal het besturingssysteem hiervoor een draad met hogere prioriteit onderbreken. Een lage MAXWAIT waarde geeft daarom bij een groot aantal met normale prioriteit lopende draden extra systeembelasting. De kernel zal zelf overigens nooit preëmptief worden onderbroken. In ieder geval niet door een verstervend gebruikersproces.

Draden met idle priority krijgen geen starvation boost. Ze kunnen daarom geen draden met hogere prioriteit onderbreken. Op een bezet systeem kunnen ze gemakkelijk versterven (nooit aan bod komen).

Stel mijn CONFIG.SYS bevat:

PRIORITY=DYNAMIC
rem IOPL=NO geeft hapering bij multimedia
IOPL=YES
PRIORITY_DISK_IO=NO
MAXWAIT=3

Met PRIORITY=ABSOLUTE deelt OS/2 geen foreground boosts meer uit. Ook de MAXWAIT variabele werkt dan niet meer. Hier zouden server systemen met I/O intensieve processen (en met PRIORITY_DISK_IO=YES) op de achtergrond van kunnen profiteren. Maar op een interactief WPS Desktop systeem levert PRIORITY=ABSOLUTE meestal veel vertraging bij het openen van de menuvensters op.

Bij PRIORITY=ABSOLUTE moet u met de TIMESLICE variabele aangeven hoeveel processortijd een draad minimaal en maximaal mag hebben:

TIMESLICE = 32,512 

In dit geval zal OS/ 2 een draad maximaal 32 milliseconden processortijd geven voordat het de processortijd aan een draad met een hogere prioriteit geeft en maximaal 512 milliseconden als er alleen nog draden met dezelfde of lagere prioriteit op processortijd wachten.

CLOCKSCALE=4 

Moderne OS/2 kernels

Meer lezen: High Resolution Timing under OS/2

Met Watchcat de status van draden bekijken

> Top <

Om te zien hoe de verhoudingen m.b.t. de processortijd in uw systeem zijn, en of u er wat aan kunt tunen, is het zinvol om in Watchcat de lopende processen eens langs te lopen met het venster met de draden in beeld. U krijgt dit beeld door in Watchcat Info/ Threads te kiezen.

Watchcat probeert zo goed en zo kwaad als dat kan een dynamisch beeld van de onder OS/2 lopende processen te weer te geven. Maar voor de meeste processen verandert de werkelijkheid veel sneller dan Watchcat kan laten zien.

Volgens Watchcat liep StarOffice hier met 13 draden (even) 50% van de processortijd te gebruiken. Maar dat kan alleen als een of meer draden actief (running) zijn. Op het moment dat ik de snapshot nam, waren alle draden al weer geblokkeerd: oftewel de CPU-use van StarOffice was al weer 0 geworden.

Maar juist de zaken die niet goed lopen (processen die blijven hangen), zijn met Watchcat goed op te sporen.

Ik concentreer me nu op de draden.

De status van een draad is actief (active), gereed (ready) of geblokkeerd (blocked).

Geblokkeerde draden

> Top <

In de praktijk zijn de meeste draden geblokkeerd. Ze kunnen (nog) niets met de processor doen. Ze wachten niet op de processor, maar op invoer. Bijv. dat u ze actief maakt door iets in hun venster te tikken. Of ze wachten op het afronden van hun eigen I/O operaties. De verdeler van de processortijd (scheduler) zal deze geblokkeerde draden overslaan.

Bij geheugengebrek zijn de geblokkeerde draden de beste kandidaten om geheel of gedeeltelijk naar de vaste schijf te swappen. Ook in dit secundair geheugen houden deze draden de status geblokkeerd. Als zo'n zich in het secundair geheugen bevindend proces via een I/O operatie word geactiveerd - u maakt het achtergrondproces via het taakoverzicht actief - dan levert het aanroepen van zijn op de schijf geparkeerde virtuele geheugen een paginafout in de processor op. Dit deel van het virtuele geheugen bevindt zich immers niet meer in het hoofdgeheugen. In die situatie genereert de processor een interrupt om de paginafout aan het besturingssysteem te melden. OS/2 kiest een geschikt moment om de draad weer in het hoofdgeheugen te laden. Daarna wordt de draad weer in een wachtrij van gereedstaande draden geplaatst.

Gereed staande draden

Draden die klaar staan om processortijd gebruiken krijgen het label gereed (ready). Ze worden in het rooster van de scheduler opgenomen (een wachtrij). Vervolgens hangt het van hun prioriteit af, of en wanneer ze aan bod komen. Maar op een zeker moment (maximaal MAXWAIT seconden) krijgt iedere normale draad processortijd. Alleen draden met idle priority komen misschien nooit aan bod (versterven).

Komt de draad met de hem toebedeelde portie (timeslice) processortijd uit, dan geeft de draad de besturing weer aan het besturingssysteem terug. Daarna wordt de draad afgesloten of zal het programma de draad blokkeren (active => blocked), bijv. omdat het op een I/O operatie wacht.

Omdat alleen de programmeur weet wanneer een OS/2 programma processortijd nodig heeft, wordt de verantwoordelijkheid voor het gereedmaken en blokkeren van een draad bij de programmeur gelegd. Hetzelfde geldt voor de prioriteitstelling van de draad. Maar als een minder goed geschreven programmadraad niet voor zijn deadline klaar is en/of wordt opgewacht door een draad met een hogere prioriteit, dan wordt hij voortijdig (preëmptief) door het besturingssysteem onderbroken en weer achterin de wachtrij gezet.

Op die manier worden ook DOS programma's steeds weer achteraan gezet. De status verandert dan van actief in gereedstaand. De prioriteit van DOS programma's die niets doen worden met een lage IDLE_SENSITIVITY waarde (5 is mooi) na IDLE_SECONDS seconden (0 is de default) bovendien verlaagd, zodat ze eerst op de normale OS/2 processen moeten wachten. Op die manier houden pollende DOS en 16 bits Windows programma's het systeem nauwelijks op.

Als het goed is moeten niet te veel draden het "ik wil nu starten" ready signaal laten zien. Maar ook niet te weinig. Teveel wachtende draden duidt op een overbelast systeem. Blijkbaar komen ze niet aan bod. Doorgaans wordt de processortijd dan niet goed verdeeld en/of zijn er teveel urgente processor intensieve processen in het geheugen geladen. Anderzijds zou het ook niet goed zijn als slechts het altijd op de achtergrond draaiende "idle proces" alle processortijd gaat gebruiken. Dan blijft de processorkracht onbenut.

DOS programma's kunnen eindeloos de status van het randapparaten opvragen om te zien of er wat gebeurd (pollen). Op die manier kan het programma bepaalde zaken achterhalen; bijv. of iemand een toets indruk en of de printer de printopdracht ontvangen heeft. Maar in een multiprogrammering omgeving is het pollen van het toetsenbord alleen zinvol als het programma de voorgrondsessie is. De cpu tijd van een DOS programma moet dus preëmptief worden onderbroken. Dat gebeurt ook. Om te voorkomen dat een DOS achtergrondsessie de processor onnodig belast door steeds weer een nieuw rondje processortijd op te vragen, moet u zijn IDLE_SENSITIVITY zo laag (5-30) instellen dat de CPU-USe 0 wordt en zijn status geblokkeerd.

OS/2 programma's doen dit automatisch. Als WordPro het actieve venster is (voorgrondsessie), is draad 1 ready. Verplaatst u de focus naar buiten (achtergrondsessie), dan wordt draad 1 geblokkeerd en verdwijnt de knipperende prompt.

Tijdkritische processen krijgen onmiddellijk processortijd. Voordat Watchcat kan aangeven dat ze gereed zijn, moeten ze hun beurt al hebben gehad. Ze staan dus bijna altijd op geblokkeerd.

In mindere mate geldt dit voor de serveerprocessen (400). Als servers vaak op ready staan dan is dit een teken van een (over)belast systeem.

Bepaalde draden met lage prioriteit (100) mogen daarentegen wel lang op processortijd wachten. Een voorbeeld is draad 3 van CACHEF32, die een achtergrondtaak verricht. Pas als de normale en systeemprocessen klaar zijn, krijgen ze wat processortijd. Hier is het kenmerk ready normaal.

Actieve draden

> Top <

De meeste draden zijn gauw klaar met hun bezigheden. Het label running (actief) zult u dan ook weinig zien. Watchcat zal van zichzelf wel aangeven dat het voortdurend running is. En wel in draad 2 als een tijdkritisch proces (300). Ook dat is normaal.

Prioriteiten stellen

> Top <

Er zijn meerdere programma's waarmee u de prioriteiten van programma's kunt instellen. Een programma dat traag verloopt en veelvuldig de status ready heeft kunt u met een hogere prioriteit sneller laten lopen. Een programma dat geen haast heeft (diskfragmentatie, virusscan) kunt u het prima met idle priority laten verlopen.

De freeware utilities (fm2utils.zip) van FM/2 auteur Mark Kimes bevatten het hulpprogramma Priority. Hiermee kunt u een programma met een door u bepaalde prioriteit opstarten. Normaal gesproken bepaalt de programmeur dat. Overigens is het wel goed om te weten dat op die manier alleen de beginthread te beïnvloeden is. Als het programma een nieuwe thread start, zullen voor die taak weer de instellingen van de programmeur gelden.

PRIORITY.EXE -- sets priority as specified, then runs command. 
A public domain launch-with-priority program by M. Kimes. 
Usage: PRIORITY [/Quiet] <class> <delta> [command and args...] 
Examples: 
PRIORITY /q 1 31 SWEEP DEL *.BAK (note /q before <class> and <delta>) 
PRIORITY 4 0 MYPROGRAM.EXE 
<class> must be between 1 and 4 (required argument). 
<delta> must be between 0 and 31 (required argument). 
The higher the class, the higher the priority EXCEPT that class 4 is lower than class 3 but higher than class 2. You should probably NEVER use class 3. Class 1 is "idle" priority and can be useful for starting background processes. You might want to create an I.CMD with "@PRIORITY /Q 1 1 %1 %2 %3 %4 %5 %6 %7 %8 %9" in it to facilitate starting idle processes. The higher the delta, the higher the priority within the class. Class 2, delta 0 is standard priority. 

Mark Kimes adviseert om class 3 (time-critical) niet te gebruiken. De klasse van tijdkritische processen is gereserveerd voor systeemprocessen (netwerk, midi, pmshell), die weliswaar buiten de (micro)kernel lopen, maar ze zijn zo essentieel zijn voor het systeem dat ze voortdurend weer processortijd moeten krijgen, ook al moet daar een uitstekend draaiend gebruikersprogramma (klasse 2) of server (klasse 2 of 4) voor worden geïnterrumpeerd.

Daarom hoort een gewoon gebruikersprogramma niet in klasse 3 thuis. Sommige programma's (Warpamp) maken toch misbruik deze door de processor bevoordeelde klasse en draaien als tijdkritisch proces. U zou dergelijke programma's beter met een lagere prioriteit (2 0) kunnen starten of als klasse 4 proces. Want het mag niet zo zijn dat een (onder OS/2) traag werkend programma, zijn prestaties opkrikt door processortijd te stelen van andere programma's.

Een top-achtig programma om te achterhalen welke processen de meeste processortijd vreten is VIOusage (vusage11.zip). Helaas heb ik nog geen port van GNU top kunnen vinden. TOP V2.01 by Paul Ratcliffe (top201.zip) lijkt er nog het meeste op. Netscape is momenteel inactief op de achtergrond, maar gaat toch de processor belasten. De instelling van Nice OS/2 Enhancer om Netscape te dimmen zet blijkbaar nog geen zoden aan de dijk. Cntrl.exe is een echt netwerk systeembestand dat o.a. een rol speelt bij de netwerkbuffers. Watchcat draait twee keer. Dergelijke processen draaien als een tijdkritisch proces.

PID CPU* Process 
---------------------------------------------------------- 
12 26.15% F:\MPTN\BIN\CNTRL.EXE 
77 24.61% F:\NETSCAPE\PROGRAM\NETSCAPE.EXE 
76 23.07% F:\BIN\DRV\WATCHCAT\WATCHCAT.EXE 
35 9.23% F:\OS2\PMSHELL.EXE 
7 6.15% F:\OS2\FS\FAT32\CACHEF32.EXE 
75 4.61% F:\OFFICE51\SOFFICE.EXE 
23 4.61% F:\IBMCOM\PROTOCOL\NBTCP.EXE 
28 1.53% F:\BIN\DRV\WATCHCAT\WATCHCAT.EXE 
67 0.00% F:\IBMLAN\SERVICES\PEER.EXE 
56 0.00% F:\IBMLAN\NETPROG\NETMSG.EXE 
55 0.00% F:\BIN\WPS\NICE-OS2-V45\NICE\ENHANCER\NICE-OS2.EXE 
1 0.00% SYSINIT 
49 0.00% F:\IBMLAN\SERVICES\WKSTA.EXE 
69 0.00% F:\BIN\SYS\VUSAGE11\VIOUSAGE.EXE 
29 0.00% F:\OS2\PMSHELL.EXE 
100% is 65 time-slices in 2.032 seconds. 
* - Represents percentage of CPU time that was acually used by applications. 

Als Netscape zich met 99% cpu-use in bepaalde HTML code verslikt, dan is het niet de bedoeling dat de een FTP upload met FTP Browser daar onder lijdt. Dat heeft immers meteen consequenties voor mijn FTP achtergrondsessies. Wget en FTP Browser kunnen een download herstellen, maar FTP Browser een upload niet. Hoe los je dit nu op? Ik draai FTP Browser dan met wat verhoogde prioriteit. Het programma gedraagt zich anders wat al te braaf.

@echo off 
F: 
CD \ 
CD \bin\LAN\FTPBROWS 
G:\CMD\PRIORITY 4 1 FTPBADDR.EXE 
EXIT 

Het kan ook terwijl een programma al draait. Wnice (wnice.zip) is een watchcat addon waarmee u prioriteiten dynamisch kunt aanpassen.

De wnice.dll die de Watchcat interface aanpast kopieert u naar de watchcat map. De niced(aemon) moet actief zijn voordat u het programma start. Deze kan via startup.cmd worden geladen:

i:\bin\sys\wnice\nice_v0_07b15_bin\bin\niced.exe \start

of als CONFIG.SYS opdracht:

run=i:\bin\sys\wnice\nice_v0_07b15_bin\bin\niced.exe -start

Programma's die de processor minimaal mogen belasten zet u op 1. Processen die wat harder mogen lopen (servers als Junkbuster, Squid) op 4. Change class to 3 kunt u beter niet gebruiken.

Out of memory errors bij gebruik van Watchcats WNICE.DLL

Het gebruik van wnice.dll heeft een groot nadeel. Het gebruikt veel virtueel geheugen (32 MB) zoals blijkt uit getlinmp.cmd van Theseus.

19D80000  ...............i.......................................      0  WNICE    #0003 (private)
 object is 32.000M

Dit zal eerder "out of memory errors" opleveren op geheugenrijke systemen.

De gedetailleerde verklaring van deze paradox is als volgt:

Op een geheugenarm systeem (64 MB RAM geheugen) zult u het wel laten om steeds meer applicaties tegelijkertijd te draaien. Hier dwingt het gebrek aan fysiek geheugen u om op een zeker moment weer applicaties af te sluiten. Ze kunnen immers alleen via de door alle applicaties, stuurbestanden en de kernel gedeelde 64 MB RAM met de processor communiceren. Het beperkte fysieke geheugen wordt dan de flessenhals van het systeem. Het in en uit het fysieke geheugen swappen van het aan de programma's beloofde virtuele geheugen kost immers veel tijd.

Maar aan virtueel geheugen - OS/2 reserveert 480 MB virtueel geheugen voor uw applicaties - hebt u met een ruime vaste schijf geen gebrek. En zolang u geen tekort hebt aan virtueel geheugen, geven normale OS/2 programma's geen "out of memory" foutmeldingen. ze werkenimmes met virtueel geheugen. U kunt voor honderden megabytes programma's laden totdat de wanverhouding tussen het beperkte fysieke geheugen en de te grote working set van uw geheugenresidente applicaties uw systeem laat vastlopen. Maar "out of memory errors" horen daar niet bij. Het vastlopen van het systeem zal meestal op disktrashing berusten (een overspannen geheugenbeheerder) en/of een door time-outs geplaagde user interface (niet afgewerkte message queues en dergelijke). Maar niet aan gebrek aan geheugen zoals de programma's dat zien: want zij "zien" alleen hun del van het virtuele geheugen van de intel 386 processor (4 GB in totaal).

Op een OS/2 systeem met 512 MB of meer geheugen kunt u daarentegen lange tijd probleemloos (zonder merkbaar geswap) programma's laden. Ook de WPS blijft lange tijd responsief. Maar op een zeker moment houdt het op. Dan krijgt u "out of memory errors", "cannot find DLL" en andere foutmeldingen, die op een gebrek aan virtueel geheugen duiden. Er kan - ook al is er nog veel fysiek geheugen vrij - geen virtueel geheugen voor applicaties en hun bibliotheken meer worden gereserveerd.

DLL's die in het LIBPATH staan worden vreemd genoeg niet meer teruggevonden. Ze zijn evenals de WPS objecten die niet meer willen laden en waarvan de WPS klaagt over niet gevonden paden niet uit hun pad verdwenen, maar ze konden niet meer in het overvolle virtuele geheugen geladen worden. Vandaar de foutmelding "cannot find DLL". Want niet de schijf, maar het met hen gedeelde virtuele geheugen is de plaats waar ieder OS/2 programma zijn bibliotheken en executables zoekt. Van het bestandssysteem hebben ze geen weet. Het laden van programma's en Dynamic Link libraries is niet hun taak maar een taak van de kernel. Maar dat de almachtige kernel daar op een zeker moment niet meer toe in staat is, dat komt niet bij de programmeurs en hun compilers op. Vandaar dat ze veronderstellen dat de kernel het pad naar de door hen opgevraagde code niet gevonden heeft.

In Virtueel geheugenbeheer en Geheugenbeheer van de Aurora kernel kom ik hier op terug.

Real-time processen

> Top <

Bij real-time processen gaat het om de juiste timing. De beschikbare gegevens moeten binnen een bepaalde responstijd worden verwerkt. Zo mag de berekening van een weersvoorspelling geen dagen duren. Want dan komt de uitkomst als mosterd na de maaltijd. Bij het KNMI worden dus supercomputers ingezet om met de veelheid aan gegevens toch tijdig (voor het journaal) over uitkomsten te beschikken.

Bij video en spraakherkenning op de PC kan de responsetijd fracties van seconden bedragen. Massa's data moeten tijdig worden verwerkt, maar een bit (pixel) meer of minder maakt weinig uit. Een deel van de data mag dus verloren gaan.

In sommige real-time processen is vertraging ingebouwd om oscillatie te voorkomen. Denk aan een thermostaat waar een dempmechanisme het voortdurend aan- en uitzetten van warmtebron moet voorkomen. Snelheid is daarentegen weer van belang bij de elektronische circuits van een versterker. En accuratesse bij industriële controlesystemen en sommige wetenschappelijke experimenten.

Afhankelijk van eisen en de complexiteit van de taken kunnen real-time processen in de hardware (hardware real-time systeem) of in de software (software real-time systeem) worden uitgevoerd.

Industriële controlemechanismen en robots zullen voornamelijk in de hardware worden uitgevoerd. De software dient dan om de hardware bij te sturen. Virtueel geheugen en time-sharing zullen ontbreken en het systeem wordt via hardware interrupts bestuurd.

Complexe en sterk wisselende taken kunnen echter beter in software worden uitgevoerd. Voor iedere aanpassing een nieuwe chip ontwerpen is immers geen doen. Een software implementatie is goedkoper en flexibeler. Dergelijke software moet moet snel (interrupt-driven) en voorspelbaar (deterministisch) zijn en draait bij voorkeur op een real-time besturingssysteem (RTOS) als QNX.

Ook OS/2 kan dienst doen als een "soft" real-time systeem. Met zorgvuldige priority based multithreading zullen ook ingewikkelde tijdkritische processen door OS/2 goed te behappen zijn. Hardware interrupts zorgen voor een snelle response van in- en uitvoer apparaten en de prioriteit van de programmadraden voor de tijdige verwerking door het besturingssysteem. Voorbeelden van dergelijke tijdskritische informatiesystemen zijn de programma's waarmee u reizen boekt of geld overmaakt. Als financiële transacties niet volgens een "wie het eerst komt die het eerst maalt" principe worden afgehandeld ontstaan niet meer actuele saldi en of dubbele boekingen. Een ander voorbeeld is de real-time besturing van een of meer industriële robots. As ze niet snel genoeg reageren, ontstaat er een chaos. Bij dergelijke real-time systemen staan betrouwbaarheid èn snelheid voorop.

Ook de hypervisor van Virtual PC is een goed voorbeeld van een real-time proces. Deze draad moet iedere kernel modus processorinstructie van het gastbesturingssysteem analyseren en bewerken, voordat ze naar de processor gaat. Maar als het te lang duurt lopen andere tijdskritische processen vast. Een real-time virusscanner heeft hetzelfde probleem met het binnenkomende dataverkeer. Om een snelle afhandeling mogelijk te maken zullen deze processen deels in assembler geschreven zijn.

Onder OS/2 kunnen meerdere tijdskritische taken met een verhoogde prioriteit draaien. Real-time draden lopen onder OS/2 met prioriteit 3. Ze wachten in het geheugen op het moment dat ze in actie moeten komen (trigger-event), maar als ze eenmaal processortijd nodig hebben (ready) zullen ze die vrijwel onmiddellijk krijgen. Het besturingssysteem zal draden met lagere prioriteit pre-emptief onderbreken om een real time proces processortijd geven. De lopende draad mag zijn taak in maximaal 32 ms (de minimale time-slice) afmaken en daarna is het tijd-kritische proces aan de beurt. Om de vaart erin te houden, krijgen tijd-kritische draden een kortere time-slice (8 ms en 2 ms op recente kernels met CLOCKSCALE=4) toegewezen. Meestal zijn deze draden door hun snelle code en kleine werkset (assembleertaal) gauw klaar.

Real-time draden met een superviserende taak (hypervisor, virusscanner) kunnen de voortgang van de door hen bewaakte processen (hun trigger) enorm vertragen. Het wordt helemaal lastig als real-time processen met elkaar in competitie gaan. Of als het ene real-time proces het andere triggert of ophoudt (deadlock). Waarschijnlijk is dat reden dat in een Virtual PC alleen de hypervisor als real-time draad draait.

Embedded and Real-Time Systems

Timur Tabi: High Resolution Timing under OS/2

Waarom is Injoy een joy?

> Top <

Hieronder ziet u als voorbeeld de prioriteiten van het OS/2 PPP inbelprogramma Injoy. Er lopen 8 draden. De draad met ID 1 is het beginproces. Deze draait op het laagste niveau van regular priority (PRIO= 2.00). Maar de threads die de verbindingen onderhouden (ID 6-8) draaien als foreground server. Draad 6 is "ready" en vraagt om de aandacht van de processor. Met de server priority 4 duurt dat niet lang.

ID PRIO STATUS BLOCKID 
1 200 blocked fe1c1408 
2 200 blocked fe1c1800 
3 200 blocked fff75b93 
4 200 blocked fe1c1418 
6 418 ready 4a81672 
7 418 blocked 2ac0e92e 
8 418 blocked f275000a 

Virtueel geheugenbeheer

Real modus

> Top <

Het Disk Operating System (DOS) draait in de real modus van de 16 bits Intel 8088 processor. In deze processorstand kunnen programma's instructies op willekeurige geheugenadressen uitvoeren. De centrale verwerkingseenheid (CVE, processor) voert ze meteen uit. Door die vrijheid krijgen programma's maximale snelheid en ongekende mogelijkheden. Die snelheid was ook wel nodig op de 5 MHz 8086 PC's met het 64 kB werkgeheugen van weleer.

Op een moderne 80386 PC (1985, 1988 voor de 386 SX) wordt de "real modus" nog steeds gebruikt voor spelletjes en tools die onder Dos en varianten de hardware direct moeten benaderen. Denk aan PQMagic, Bootlin, DiskImage en BIOS upgrade tools. Veel spelletjes en tools regelden hun eigen geheugenbeer omdat ze niet op het geheugenbeheer van MS DOS konden vertrouwen.

Maar voor multitasking (office suits, netwerk) is de real modus volstrekt ongeschikt. De processortijd wordt niet goed verdeeld; er is met 1 MB altijd geheugentekort en door de onbeperkte geheugentoegang kan het ene programma het geheugen van een ander proces overschrijven.

Op het eerste gezicht lijkt dat op een single-tasking besturingssysteem geen probleem, maar in de praktijk komt pure single-tasking niet voor. Als u een programma vanuit de schil (command.com) start, blijft de schil in het geheugen staan. Als u het programma afsluit, wilt u weer verder. Maar onder DOS ging bij een geheugenfout het hele besturingssysteem ten onder.

Deze labiliteit (doe maar met me wat je wilt) van de real modus kan ook creatief worden gebruikt: met Bootlin wordt Linux geladen, met win.com neemt Windows 3.1 het geheugenbeheer over en veel spelletjes en utilities deden hetzelfde. Maar ook veel DOS virussen maakten er gebruik van. Labiliteit; flexibiliteit: Het is maar vanuit welk perspectief je het beziet. Maar de onbeperkte vrijheid voor gebruikersprogramma's is voor een multitasking besturingssysteem onacceptabel.

Protected modus en virtueel geheugenbeheer

> Top <

De 16 bits Intel 8088 processor (1979) werkte intern 16 bits, maar extern met een 8 bits databus. Hierdoor kon hij maar 1 MB geheugen adresseren. Zijn voorganger, de Intel 8086 uit 1978, werkte zowel intern als extern met 16 bits, maar had minder succes vanwege het ontbreken van goedkope 16 bits apparatuur.

Met de Intel 286 processor (en latere x86 PC processors) kwam naast een geëmuleerde 16 bits real modus een protected modus van geheugenbeheer. In deze door DOS, DrDOS, CP/M, Windows 286 en 3x en OS/2 gebruikte beschermde processormodus kent het besturingssysteem processen virtueel geheugen toe. De met een 16 bits databus uitgeruste Intel 286 processor kon extern 16 megabyte fysiek geheugen adresseren, maar intern al 1 gigabyte virtueel geheugen.

Met het 8/16 bits DOS kan een willekeurige processor niet meer dan 1 MB fysiek geheugen bereiken. In de praktijk beschikte een DOS programma nog niet eens over 640 kB conventioneel geheugen, omdat ook het besturingssysteem geheugen innam. Via een 64 kB geheugenwisselvenster konden programma's met LIM EMS geheugeninsteekkaarten grote spreadsheets draaien, maar dat vereiste aparte hardware.

De 16 bits 286 processor en hun 16 bits besturingssystemen (OS/2 1.0, QEM en andere DOS extenders, Windows 3.1) kunnen in protected modus 16 MB adresseren (1 MB conventioneel en 15 MB uitgebreid geheugen). Het pre-emptive multitaskende 16 bits OS/2 maakte exclusief gebruik van de protected modus van de Intel 286 processor. Ook als het DOS eMuleerde ("mDOS"). Maar het coöperatief multitaskende 16 bits Windows sprong desgewenst van protected modus naar real modus als DOS programma's dit behoefden. De DOS programma's liepen daardoor sneller, maar ten koste van de stabiliteit van het besturingssysteem. Ze kregen in real modus immers onbeperkte vrijheid, ook de vrijheid om het 16 bits Windows te laten crashen. En omdat Windows 286 en Windows 3.x in de 16 bits protected modus slechts aan coöperatieve multitasking deden, liep Windows in tegenstelling tot OS/2 gemakkelijk vast.

Maar toch werd Windows een succes, omdat het krakkemikkige Windows nog steeds draaide ("bestuurde" is een te groot woord) wat er al liep. En dat waren veel MS DOS applicaties (grafisch en tekstmodus) en een toenemend aantal Windows applicaties, terwijl onder het stabiele OS/2 alleen maar de "nette" DOS en de nauwelijks nog ontwikkelde OS/2 VIO (tekstmodus) applicaties liepen. Want OS/2 1.0 had nog geen grafische schil.

De 32 bits Intel 386 processor en opvolgers (486, Pentium) kunnen met de door OS/2 2.0 en Windows NT gebruikte de 32-bit protected mode 4 GB virtueel geheugen per proces bieden. Voor een overzicht zie: Protected Mode tutorial.

De 32 bits processors kenden bovendien de virtual 8086 (V86) modus, waarmee een conventionele 8086 PC in het virtuele geheugen kon worden geëmuleerd (\OS2\MDOS\V(irtual)*.SYS). De 386 kon ook het door spreadsheets en andere geheugenintensieve DOS applicaties benodigde EMS geheugen in het virtueel geheugen emuleren. Voor de acceptatie van de moderne 32 bits besturingssystemen was deze compatibiliteit met DOS erg belangrijk, omdat de meeste applicaties voor DOS geschreven waren en gebruikers de eerste 80286 en 80386 PC's vooral als snelle DOS machines inzetten De echte 286 besturingssystemen van IBM (OS/2) en Microsoft (Presentation Manager voor 286 - een ramp) waren nog volop in ontwikkeling.

Het gebruik van virtueel geheugen heeft een enorme impact gehad op de ontwikkeling van de grafische gebruikersinterface (GUI) zoals wij die nu kennen. Waar de eerste PC programmeurs voor 64 - 640 kB werkgeheugen moesten schrijven, konden de programmeurs van de 16 en 32 bits besturingssystemen van vele megabytes grote grafische systeembibliotheken gebruik maken. Hiervan hoeft maar een deel in het fysieke geheugen geladen zijn. Het andere deel van het virtueel geheugen kon op de schijf blijven. Doordat een groot deel van de programmacode als dynamische link bibliotheken op de schijf beschikbaar bleef en door meer programma's gebruikt konden worden, hoefde het wisselbestand niet eens zoveel te groeien.

Geheugenbeheer in de praktijk

Natuurlijk kan de processor alleen maar gegevens bewerken (data lezen/beschrijven, code uitvoeren) die in het werkgeheugen - tegenwoordig de CPU caches- beschikbaar zijn. Als een proces op het wisselbestand geparkeerd virtueel geheugen opvraagt, zal het besturingssysteem dit dus eerst in het fysieke geheugen moeten plaatsen. Om ruimte vrij te maken moet de kernel een ander deel van de in fysieke geheugen lopende processen afsluiten of in de swapfile plaatsen.

Dit "swappen" van en naar de trage schijf vertraagt de afhandeling van een proces enorm. Tijdens de wachttijd zal het besturingssysteem de processor andere taken willen laten uitvoeren. Maar als bij deze gereedstaande draden ook beschikbaarheidsproblemen optreden, komen de programma's niet meer aan bod. Bij een tekort aan fysiek geheugen kan het besturingssysteem meer tijd besteden aan het verplaatsen van virtueel geheugen van en naar de schijf dan met het afwerken van de processen zelf. Men spreekt dan van trashing.

De situatie is te vergelijken met een bedrijf dat in een reeks reorganisaties zit. In het extreme geval zijn de de nog in het geheugen aanwezige draden en processen (mankracht en kennis) al buiten spel gezet, terwijl de nieuwe (primaire) processen nog niet draaien. Er is veel overhead door elkaar overbiedende managers, maar in de productieve "het" sfeer - het primaire proces in management jargon - gebeurt er nagenoeg niets.

Wat kunt u als CEO in zo'n crisissituatie doen? De destraseus verlopende reorganisatie terugdraaien (of bevriezen) is een optie. Blijkbaar kwamen uw initiatieven niet op het goede moment. Het afsluiten van de vastgelopen processen met watchcat zou mijn insteek zijn. Vervolgens zou ik de minst benodigde processen afsluiten (ontslaan, outsourcen), om daarna vanuit een responsief besturingssysteem opnieuw een poging te wagen de door mij benodigde programma's op te starten.

Voor effectief multitasken geldt daarom: hoe meer direct benodigde programmacode en data in het fysieke random-access memory (RAM) zitten, des te vlotter de voortgang. Daarom levert op een meertaken besturingssysteem geheugenuitbreiding meer snelheidswinst op dan een processor-upgrade. De processor zit toch de meeste tijd niets te doen. Grafische videospelletjes profiteren daarentegen meer van pure rekenkracht (CVE incl. processorcache, videokaartversneller en mathematische coprocessor).

Tip: Greg Shaw geeft in Memory Analysis in OS/2 aan hoe u Theseus kunt gebruiken om de working set te bepalen. Dat is de hoeveelheid geheugen die uw configuratie nodig heeft.

Vertraagd doorvoeren: OS/2 als slimme centrale bankier

> Top <

Op een Desktop systeem staat standaard de volgende CONFIG.SYS instelling:

MEMMAN=SWAP,PROTECT

Met deze instelling gaat OS/2's Memory Manager (MEMMAN) via het lazy commit mechanisme met virtuele geheugen (PROTECT) om. Het vertraagd doorvoeren van geheugenverzoeken van programma's (wel toezeggen, maar lui uitvoeren) zorgt ervoor dat u met krap werkgeheugen en een relatief klein wisselbestand toch een groot aantal geheugenintensieve applicaties kunt draaien.

De term vertraagd doorvoeren stamt uit de wereld van de caches. Een vaste schijf cache doet zich voor als de vaste schijf, maar is in werkelijkheid niet meer dan een in het veel snellere geheugen afgebeeld deel van de schijf. De cache verbergt de echte vaste schijf: caché is Frans voor verborgen. Als een programma via een vertraagd doorvoerenden lazy write back cache naar een bestand op de vast schijf schrijft, zal de cache als vaste schijf emulator wel doen alsof hij die schrijfbewerking uitgevoerd heeft, maar het pas doen na een gezette tijd. Het is namelijk veel efficiënter om meerdere opgespaarde kleine veranderingen in een keer door te voeren dan iedere verandering (bijv. in de tekst die ik type) achter elkaar.

Een concreet voorbeeld van vertraagd doorvoeren stond in mijn artikel over Os20menu beschreven. Het OS/2 systeem had 64 MB werkgeheugen (1024 kB=1 MB), het aangevraagde virtuele geheugen was 213 MB, maar het wisselbestand SWAPPER.DAT was nog geen 50 MB gegroeid.

Deels is dit met de 75 MB door applicaties gedeeld geheugen (shared storage) te verklaren. Applicaties die elkaar geheugen delen (WPS applicaties, PM Shell applicaties, emx applicaties) kunnen met met minder fysiek en virtueel geheugen toe. Hun gedeelde bibliotheken worden maar eenmaal in het virtuele geheugen geladen.

Voor een ander deel bestaat de truc van OS/2's geheugenbeheerder (MEMory MANager) eruit dat een groot deel van het aan applicaties beloofde virtuele geheugen nog niet werd uitgegeven. Programma's vragen immers meer geheugen op dan ze daadwerkelijk zullen gebruiken.

Net als een bankier speculeert OS/2's geheugenbankier erop dat zijn klanten (de programma's) wel over veel giraal geld (virtueel geheugen) willen beschikken, maar het niet meteen contant nodig hebben (fysiek geheugen, hun working set). Zouden de programma's door uw klikgedrag wel massaal hun virtueel geheugen als fysiek geheugen opeisen, dan ontstaat een traag systeem waarbij ieder programma op het vrijkomen van geheugen (liquide middelen) van een ander actief programma moet wacht. Die situatie is te vergelijken met een recessie. In het meest extreme geval ontstaat er een soort beurs Krach. De geldhandelaren (het systeem, meer specifiek de geheugenbeheerder) is druk aan het werk, maar de programma's staan te wachten. Hierbij wordt er aldoor van het wisselbestand gebruik gemaakt, wat een roffelende gedonder van de schijf oplevert (trashing).

Met de optie NOSWAP maakt de geheugenbeheerder niet meer gebruik van het "girale" geheugen op het wisselbestand. Op alle door mij geteste systemen nam het geheugengebruik hierdoor buitenproportioneel toe. Op een 512 MB systeem met 300 MB fysiek geheugen vrij (en een 1 MB wisselbestandje) hield ik met NOSWAP na opstarten nog maar 60 MB vrij geheugen over. Ook een minuscuul wisselbestand doet blijkbaar wonderen. Hoe zit dat? De reden is dat NOSWAP niet alleen het wisselbestand, maar ook het vertraagd doorvoeren uitschakelt.

Om dit aspect van het virtueel geheugen te begrijpen kunt u de OS/2 Memory Manager met bankier vergelijken: een geheugenbankier die meer geheugen aan de programma's uitleent dan hij in de kluis beschikbaar heeft.

Veel OS/2 programma's (bijv. PMShell, StarOffice, Netscape) zullen bij het opstarten tientallen megabytes geheugen bij OS/2 opvragen. De reden is dat de code sneller beschikbaar is vanuit het werkgeheugen (1e keus), of eventueel vanuit geswapt virtueel geheugen (2e keus) dan als zo'n bibliotheek eerst nog "dynamisch" in het geheugen geladen (gelinkt) moet worden. Om snel aan de slag te kunnen gaan willen de programma's dat geheugenbankier MEMMAN OS/2 hen snel en veel krediet verschaft. Wat de programma's echter niet weten, wat voor hen verborgen (caché) blijft, is dat het niet om echt, maar om om virtueel geheugen gaat. Dat echte geheugen heeft OS/2 onder zijn beheer.

De geheugenbeheerder van OS/2 leent het door programma's geclaimde geheugen meteen uit, d.w.z. hij zegt het hen als virtueel geheugen toe, maar hij rekent er heimelijk op dat ze maar een klein deel ervan zullen opvragen. Net als een bankier leent de geheugenbeheerder meer geld/virtueel geheugen uit dan hij op dat moment in het kasboeken afgedekt heeft, laat staan dat hij het als vrij geheugen in kas zou hebben. Want door dit bankiersgedeelte eerst op het trage wisselbestand te regelen zou hij zijn klant moeten laten wachten. En de volgende klant (draad) staat al voor de deur. De Memory Manager roept dus "geregeld!", maakt hier nog een notitie van en gaat door met zijn volgende klant: de draad met de hoogste prioriteit. Deze is vrijwel zeker al in het geheugen geladen en voor een goede voortgang van de economie moeten de processen snel werkgeheugen hebben.

Pas als het geheugen inlenende programma (nu als draad met de hoogste prioriteit) met zijn concrete eisen voor de balie verschijnt, moet de OS/2 Memory Manager het eerder toegezegde geheugen wel verstrekken (COMMIT). Maar dat gebeurt dus met vertraging. Vandaar de term vertraagd doorvoeren ("lazy commit").

OS/2 geeft een programma (bijv. de WPS) dus pas geheugen voor data en code als het programma dit daadwerkelijk gaat gebruiken. Pas dan wordt het benodigde code en informatie aan het spaarse geheugen beschikbaar gesteld. En als de data en code enige tijd niet meer gebruikt worden - zullen ze in het wisselbestand verdwijnen.

Door deze strategie houdt OS/2 maximaal geheugen voor andere programma's vrij en zal de bijdrage van het relatief trage wisselbestand aan het virtuele geheugen minder snel groeien. Het virtueel geheugen van afgesloten gebruikersprogramma's komt natuurlijk meteen weer vrij. Ook hier zie je dat OS/2 niet meteen de schijf benaderd, maar zal het een rustig momenten uitkiezen om het wisselbestand te defragmenteren. Desondanks zal het wisselbestand in de loop der tijd gemiddeld blijven doorgroeien, omdat steeds meer code van altijd actieve programma's als de WPS geladen wordt. Maar gezien het feit dat code sneller uit het wisselbestand, dan uit een nog ongelinkte *.DLL te laden is dat geen bezwaar.

Ook met de parameter COMMIT is het "vertraagd doorvoeren" uitgeschakeld. De situatie lijkt dan meer op die van de UNIX besturingssystemen. OS/2 kent pas virtueel geheugen toe als het zijn administratie op het wisselbestand afgerond heeft. Hierdoor groeit niet alleen het wisselbestand tot honderden megabytes, maar neemt ook de systeemoverhead toe en is er dus minder processortijd beschikbaar voor de applicaties. Het laden van volledige programma's kost nu eenmaal veel meer tijd. Maar het voordeel is dat de kans op een Krach afgenomen is: Er is geen geheugenverstrekking meer op de poef. Hieraan ontlenen Linux (en OS/2 met COMMIT) hun stabiliteit. Als er meer virtueel geheugen aangevraagd wordt dan dat er theoretisch beschikbaar is volgt een foutmelding. U kunt deze stabiele, maar op geheugenarme systemen trage UNIX variant eens uitproberen met:

MEMMAN=SWAP,PROTECT,COMMIT
SWAPPATH=L:\ 20480 1024

Door de snelle virtuele geheugenverstrekking (de commit) kan het wisselstand honderden megabytes groeien, ook als er nog voldoende geheugen beschikbaar is. Maar zolang u nog voldoende schijfruimte (de 20480 KB) over heeft kunt nog doorwerken. Ik zag bij een kleine tweede waarde van SWAPPATH bovendien een blokvormig patroon: in de afbeelding hiernaast ziet u in het violette gebied dat de swapper.dat vrij abrupt tussen de (bijna) 200 en 1 MiB (de minimumwaarde) wisselde. Weet u ongeveer hoe groot het wisselbestand maximaal zal zijn, dan voert u die waarde in als laatste parameter (200000 in plaats van 1024) van SWAPPATH in.

Overigens blijkt volgens Theseus deze gereserveerde ruimte zelden gebruikt te worden. Oftewel u ziet: There are 0 frames used. (0K => 0.000M) in Theseus / Sytem / swapper. Het daadwerkelijk aanspreken van de het wisselbestand speelt pas als al het vrije geheugen echt helemaal verbruikt is.

Met de NOSWAP parameter is de lazy commit definitief van de baan. OS/2 zal SYS0147 foutmeldingen rondstrooien omdat er te weinig geheugen voor programma's beschikbaar is. NOSWAP is een typische instelling voor embedded devices die zonder vaste schijf maar een paar applicaties draaien. Denk hierbij aan een router, firewall of terminal. Situaties waarin u van te voren weet hoeveel geheugen er zal worden gebruikt.

MEMMAN=NOSWAP,PROTECT,COMMIT
set os2_shell=f:\os2\cmd.exe 
protshell=f:\os2\cmd.exe
set runworkplace=f:\os2\cmd.exe

Pas als u over veel geheugen (> 512 MB) beschikt en/of maar een beperkt aantal kleine applicaties draait, kunt u deze instelling eens proberen. En dan hopen dat PMSHELL nog geladen wordt (met 1 GB valt trouwens prima met NOSWAP te werken).

Privilege levels

> Top <

De belangrijkste vooruitgang was dat de 286 protected modus processen tegen elkaar beschermde. De kernel bleef oppermachtig, maar de privileges van gewone programma's werden aan banden gelegd. De processor kreeg een proces bewakende functie.

Om de vertragende bureaucratie te voorkomen laat het besturingssysteem de programma's zoveel mogelijk hun gang gaan (deregulatie). Maar als de processor een instructie detecteert die de grenzen overschrijdt grijpt het besturingssysteem in.

U kunt een multitasking besturingssysteem vergelijken met een voetbalspel. De processen zijn de spelers. De CPU en de kernel zijn respectievelijk de grensrechter en de scheidsrechter. Zou een gebruikersprogramma een door een ander proces gereserveerd deel van het virtuele geheugen willen overschrijven (dreigende grensovertreding), dan zal de processor (grensrechter) het samenspel onmiddellijk stilleggen (fluitsignaal) en ontvangt de kernel (de scheidsrechter) een toelichting op de overtreding (wie, wat, waar). Vervolgens moet het besturingssysteem beslissen of het proces door mag gaan (gedogen) of niet (rode kaart, afsluiten). Aangezien de huidige generatie programma's niets van hun fouten leren heeft een waarschuwing (gele kaart) weinig zin. Maar in de toekomst kunnen programma's hun gedrag wellicht beter aanpassen (kunstmatige intelligentie).

In de protected mode treedt de processor dus als grensrechter op. In zijn Memory Management Unit (MMU) heeft hij een Global Descriptor Tabel (GDT) waarin de toewijzing van het virtuele geheugen bijgehouden wordt. Om niet alles te hoeven controleren wordt een zonesysteem met vier bevoegdheden gehanteerd. De zones heten ringen, de bevoegdheden privileges (privilege level). De programmacode in ring 0 (kernel space) mag alles, programma's in ring 3 (user space) bijna niets.

Als zo'n programma het volgens de GDT niet voor hem bestemde virtuele geheugen wil overschrijven (Page Fault), dan wordt dat meteen door de MMU als een Global Protection Fout aan het besturingssysteem gemeld (vlag omhoog). Het besturingssysteem handelt dit sein van de processor verder af. In de regel zal OS/2 u de gelegenheid bieden om de bewuste applicatie af te sluiten (SYS-fout). In een enkel geval weet OS/2 zich geen raad en sluit het systeem af (Trap error).

OS/2 gebruikt drie van de vier protected mode ringen van de Intel 286 processor. Ze komen enigszins overeen met de ringen van het UNIX systeem. De eerste 16 bits OS/2 v. 1.00 (1987) maakte al gebruik van de in de hardware ingebouwde multitasking mogelijkheden van de 286 processor.

De programmacode in ring 0 heeft een vrijbrief voor de processor. Op dit hoogste privilege niveau (kernel-of systeemmodus) lopen de virtuele stuurbestanden (VDD) en de (micro)kernel zelf. De kernelcode beschikt over de complete instructiesset van de processor (incl. gereserveerde instructies als HALT) en kan alle registers en het gehele geheugen beschrijven. De uitvoering van kernelcode kan alleen door een hardware-interrupt worden onderbroken.

Ring 1 wordt onder OS/2 niet gebruikt. Intel had hem voor stuurbestanden bestemd. Maar onder OS/2 draaien de 16 bits stuurbestanden vooral in ring 2. Omdat geen besturingssysteem van ring 1 gebruik maakt, kan het benut worden door XEN.

Geheugensegmenten in ring 2 krijgen beperkte privileges op bepaalde Input Output poorten. Het gaat vooral om de in de CONFIG.SYS geladen 16 bits stuurbestanden (Physical Device Drivers, PDDs) en netwerkdiensten. Deze stuurbestanden mogen zonder tussenkomst van de kernel hun I/O poorten lezen (IN), beschrijven (OUT) en de bijbehorende interrupts uit- (CLI) en aanzetten (STI).

Maar ook gebruikersprogramma's kunnen een Input Output Privilege Level (IOPL) aanvragen. Denk hierbij aan Presentation Manager presentatie stuurbestanden voor multimedia (dive), modems, fax en -backupprogramma's die directe toegang tot de de I/O poorten van de stuurbestanden krijgen. Maar met IOPL=NO lukt dat niet (zie hieronder).

Al deze I/O geprivilegieerde drivers en bibliotheken zijn 16 bits. Via een "thunking" mechanisme worden de 16 bits adressen in 32 bits vertaald.

PM Shell en andere gebruikersprogramma's draaien in ring 3. Onder OS/2 draaien systeemdiensten als de grafische device interface en gebruikersinterface (GDI en GUI) in de gebruikersmodus. Ze worden op gezette tijden (timeslices) door de kernel onderbroken. Programma's in ring 3 krijgen slechts toegang tot hun eigen gegevenssegmenten en hebben een beperkte instructiesset. Voor hun in- en uitvoeropdrachten moeten ze een beroep doen op de eerder genoemde 16 bits IOPL bibliotheken of de 32 bits OS/2 kernel.

Input Output Privilege Level

> Top <

De in kernel modus lopende draden hebben onbeperkte toegang tot het geheugen en de processor. De processor controleert niets. De kernel functioneert als een zwarte doos. Een taskmanager ziet niets. De in ring 0 uitgevoerde code wordt dus ook niet preëmptief onderbroken. Hardware interrupts kunnen kerneldraden tijdelijk onderbreken, maar niet preëmptief. De door hardware interrupts onderbroken kerneldraden gaan na de eveneens van de kernel afkomstige interrupt afhandelingsroutine gewoon door met hun klus.

Binnen ring 0 is de samenwerking van de onderdelen coöperatief. De code moet dus kort, krachtig en 100% betrouwbaar zijn. Dat is ook het geval. Het gaat om de OS/2 kernel en een enkel stuurbestand (midi.sys, hpfs386.sys). Om de betrouwbaarheid te vergroten blijft het kernelproces klein (microkernel) en worden zoveel mogelijk zaken naar de ring 2 stuurbestanden en ring 4 servers gedelegeerd.

De in de CONFIG.SYS geladen fysieke stuurbestanden krijgen directe toegang tot de geheugenadressen en interrupts van hun adapters. Hier ligt hun expertise. Hier mogen ze dus doen wat ze nodig achten. Maar een stuurbestand dat andere geheugengebieden aanspreekt resulteert in een trap error. De betreffende I/O adressen en IRQ waarden zullen in de regel door het BIOS worden toegekend, maar kunnen ook expliciet als parameters in een stuurbestand worden opgeven. Omdat de processor ze niet op hun specialiteit (Input Output Privilege Level) hoeft te controleren, kunnen ze sneller werken.

Maar gewone programma's in ring 3 krijgen alleen toegang tot hun eigen dataregisters. Ze draaien met een lagere prioriteit in de gebruikersmodus van ring 3. De processor houdt hun instructies voortdurend in de gaten. Als een programma meer geheugen wil moet het dat bij het besturingssysteem opvragen. Want alleen de kernel kan de GDI aanpassen. En ook als een programma systeembronnen (beeldscherm, I/O poorten, IRQ's) wil gebruiken moet het bij het besturingssysteem zijn.

Deze in het besturingssysteem ingebakken controlemechanismen leveren vertraging op. De controle op het geheugengebruik wordt door de processor uitgevoerd, maar het delegeren van een I/O taak naar de kernel kost meer tijd. Bij een systeemaanroep worden software interrups gebruikt om de aandacht van de kernel te trekken. Het programma moet dan wachten (interrupt latency). Als de kernel met de hardware klaar is moet het dat weer aan het gebruikersprogramma doorgeven. Een programma dat directe toegang tot de hardware interrupts en poorten heeft kan dus veel efficiënter werken.

Om die reden kunnen OS/2 programma's die veelvuldig het beeldscherm of bepaalde poorten beschrijven (PM Fax) een Input Output privilege Level (IOPL) aanvragen. Dit geeft hen het recht om buiten de kernel om bepaalde systeembronnen direct te benaderen. U verleent hen die ring 2 rechten met de IOPL instelling uit de CONFIG.SYS.

Met IOPL=YES kunnen I/O intensieve OS/2 programma's die daar om expliciet om vragen de I/O poorten direct benaderen. Ze krijgen dan dezelfde ring 2 privileges als de OS/2 stuurbestanden. Vanwege de snelheidswinst die dit oplevert, is IOPL=YES op een OS/2 desktop of server de eerste keus.

Met IOPL=FxPrint, mplayer kunnen alleen bepaalde programma's (hier de PM Fax en mplayer) dat.

Met IOPL=NO kan geen enkel in user mode lopend programma de hardware direct benaderen.

Sommige videostuurbestanden zullen met IOPL= NO niet goed werken. U kunt geselecteerde processen aan de IOPL lijst toevoegen, maar het is vaak moeilijk te achterhalen welke dat zijn. IOPL= YES verdient daarom de voorkeur. Ik citeer Timur Tabi:

Meer info:

Introduction to IOPL programming - or how to display physical memory size under OS/2

Holger Veit : 32-Bit I/O With Warp Speed

Retrofitting OS/2 for SMP

Embedded Intel(R) Architecture - Papers

Geheugenbeheer van de Aurora kernel

> Top <

De virtuele adresruimte

Een 32 bits intel 386 processor kan 4 GB virtueel geheugen adresseren (virtual address space). Hiervan stelde het 32 bits OS/2 versie 2.0 de eerste 512 MB voor programma's beschikbaar. De virtuele geheugenadressen boven de 512 MB werden voor het besturingssysteem gereserveerd (3,5 GB).

Deze virtuele geheugen adressen zijn een onlosmakelijk onderdeel van het protected memory systeem van de 16 bits 286 en de 32 bits 386 processors. De in de protected memory modus draaiende programma's mogen niet meer het direct het beperkte fysieke geheugen aanspreken, maar moeten het virtuele geheugen benaderen van de Intel 86 processor. Als de voor hen zichtbare geheugenplaats ook daadwerkelijk beschikbaar is en ook voor hen gereserveerd is, mogen ze het beschrijven, maar anders volgt er een algemene beschermingsfout (generel protection fault, GPF) waar het besturingssysteem van wordt verwittigd. De geheugenbeheerder van de kernel zal het programma dan afsluiten of - als de virtuele geheugenaanroep een legitieme was - het geheugen alsnog beschikbaar stellen, door fysiek geheugen vrij te maken (vaak door te swappen) en het aan de benaderde virtuele adresruimte te koppelen.

Een voorbeeld van een van een met paginerend besturingssysteem met 20 k virtueel geheugen voor programma's en 5 k fysiek geheugen.

In dit voorbeeld beschikt ieder programma in theorie over 20 kB virtueel geheugen, maar er slechts 5 kB fysiek geheugen beschikbaar. Het door de kernel ingenomen fysieke en virtuele geheugen blijft hier even buiten beschouwing. Er zijn vier processen actief: P₁ t/m P₄. Ze kunnen elk 20 kB virtueel geheugen reserveren, maar als een het eerst in het geheugen geladen programma dat zou doen zouden andere programma's niet meer willen opstarten. Ze geven dan een "out of memory" foutmelding, die onder OS/2 altijd op het virtuele geheugen slaat.

De eerste rij M(emory) geeft geheugenlokaties weer, de tweede rij de bezetting van fysieke geheugenadressen (F) en de derde rij de bezetting van ruim (20k!) bemeten Virtuele geheugen (V). Geheugenlokaties die wel virtueel beloofd zijn, maar nog niet vrij gegeven zijn komen met enige vertraging (lazy commit) op de swapper.dat van de vaste schijf (S) terecht. Met voldoende vaste schijfruimte voor de swapper.dat (ideaal 4GB, maar veel minder met "lazy commit") zal in theorie ook het meest geheugenintensieve programma willen laden.

Het voor Proces P_n beschikbare geheugen is weergeven als P_na (actief). Het aan de Proces P_n beloofde maar nog niet vrijgegeven virtuele geheugen is weergeven als P_nb (beloofd).

Het vrijgeven van virtueel geheugen zou op een Unix systeem leiden tot het beschrijven van het pagineringsbestand op de trage vaste schijf (het secundaire geheugen). Hierbij maakt UNIX gebruik van een dynamische lazy write vaste schijf cache, zodat het meest benodigde deel van de zich op de vaste schijf bevindende virtuele geheugen toch relatief snel beschikbaar komt. Hoe meer geheugen, des te sneller het systeem. Want pas als het op het pagineringsbestand geprojecteerde virtuele geheugen als fysiek RAM beschikbaar komt, kan de processor er wat mee.

In dit geval zal ieder proces 20 kB virtueel geheugen zien en in theorie kunnen gebruiken. Maar we hebben maar 5 kB fysiek geheugen. Op een niet met virtueel geheugen werkend systeem zou het 6 kB vragende proces P₃ niet eens kunnen opstarten (out of memory foutmelding). Maar omdat de processor niet alle in het fysiek geheugen geladen programmacode en data ineens kan benaderen, kan het proces beginnen met het geheugen dat het in eerste instantie echt nodig heeft.

In dit voorbeeld reserveerde het programma P1 drie kB virtueel geheugen, maar kreeg maar in feite maar 1 KB. Het benaderen van twee van de drie aan P1 beloofde virtuele geheugenplaatsen (2-3) zou een algemene beschermingsfout van de Intel 86 processor opleveren.

In theorie kan een enkel OS/2 programma dus 512 MB geheugen voor zichzelf reserveren, maar in de praktijk worden die 512 MB met andere programma's gedeeld. Want ook de Presentation Manager en de opdrachtverwerker cmd.exe hebben virtuele adresruimte nodig. Daarnaast moeten de 16 bits OS/2 stuurbestanden en hun buffers over 16 bits virtuele geheugenplaatsen beschikken. Kortom de door 16 en 32 bits gedeelde OS/2 en Win-OS/2 applicaties virtuele geheugenruimte is beperkt.

Een OS/2 programma dat meteen 512 MB RAM probeert los te peuteren zou met een "cannot load DLL" vastlopen. Alleen als het programma via een stuurbestand ook het virtuele systeemgeheugen boven de 512 MB bereiken kan, kan het meer dan 512 MB virtueel geheugen gebruiken. Cache programma's en programma's als Virtual PC kunnen hier hun sinds OS/2 Fixpack 17 hun code kwijt. Maar hun met anderen gedeelde bibliotheken (DLL bestanden) kunnen ze alleen maar in de voor gewone OS/2 programma's en bibliotheken gereserveerde 512 MB virtuele adresruimte kwijt.

De virtuele adresruimte is het geheugen dat het besturingssysteem de programma's voorschotelt. Het daadwerkelijk aanwezige geheugen zal in de regel veel minder zijn. Dankzij virtueel geheugenbeheer kunnen grote OS/2 programma's draaien, die meer geheugen nodig hebben dan dat er fysiek beschikbaar is. En omdat OS/2 hen dezelfde virtuele geheugenruimte serveert, of OS/2 nu onder 4 of 256 MB fysiek RAM draait, kunnen alle OS2 programma's zich in principe hetzelfde gedragen. Ze hebben immers alleen maar met de virtuele adresruimte te maken. Het probleem van een mogelijk tekort aan fysiek geheugen delegeren de programma's aan het besturingssysteem.

Hoe lost OS/2 dit op? OS/2 deelt zowel het fysieke als het virtuele geheugen op in brokjes (geheugenpagina's) van 4 KB. Een programma mag het deel (de blokjes) die voor hem gereserveerd zijn (zijn procesruimte) vrijelijk gebruiken. Als de geheugenpagina nog niet in het geheugen geladen is (een pagineringsfout), wordt het alsnog door OS/2 geladen. Maar als een proces geheugengebieden van andere processen benaderd, zal het met een algemene beschermingsfout worden afgesloten.

Dit pagineren door het besturingssysteem gaat weliswaar niet snel, maar het kan. Vergelijk het met het bladeren in een boek. Zie het boek als een programma en uw blik op de openstaande bladzijden van het boek als uw blikveld, uw momentele geheugen. De processor werkt de instructies van het programma een voor een af. En op dezelfde manier leest u regel voor regel. De door u gelezen regel van een roman gaat naar uw korte termijngeheugen, zoals de instructies in de programmacode naar de het werkveld (registers) van de processor gaan.

Nu bent u de programmeur van uw leven en als u besluit dat de roman saai en niet te volgen is, houdt u ermee op. Maar een procesoor volgt domweg de instructies die in zijn registers verschijnen en leest ook het saaiste programma als een meeslepende roman regel voor regel (automatisering).

Dit geeft u een idee van wat er met het begrip werkset bedoeld wordt. U ziet steeds maar twee pagina's en als de tekst die u zoekt zich op een in uw blikveld aanwezige bladzijde bevindt kunt u snel doorlezen. Dan beslaat de werkset (working set) van uw systeem minder dan 2 pagina's en dat is wat u in maximaal in beeld kunt hebben (uw willekeurig blikveld, lees uw RAM). Maar als u volgende pagina in beeld moet brengen, dan moet u de pagina omslaan en dat kost weer tijd en energie.

En als de auteur naar een ander boek verwijst (dat u uit uw boekenkast moet halen), dan weet u dat klus niet zo maar geklaard is. Misschien hebt u het boek wel niet (dan ontstaat er gegarandeerd een pagefout), en als u het boek wel hebt, dan zal het toch vaak eerst van de vaste schijf (uw boekenkast) in het geheugen (lees uw blikveld) geladen moeten worden.

Een deel van de virtuele adresruimte zal zich dus in het fysieke geheugen bevinden, een ander deel bevindt zich op de vaste schijf (swapper.dat, gedeelde bibliotheken).

In de tijd dat OS/2 v.2 uitkwam werden PC's maar met enige megabytes geheugen uitgerust. En in tijd dat een 512 MB vaste schijf al zeldzaam was haalde niemand het in zijn hoofd om programma's te maken die het wisselbestand honderden megabytes konden laten groeien.

Tegenwoordig kijken we niet meer van systemen met 512 MB of meer geheugen op, maar i

Kort door de bocht gezegd reserveren de programma's een stuk van het eerste deel van die 512 MB voor zichzelf (private arenas). De rest delen ze met elkaar (shared arena). Hiertussen zit het virtuele geheugen dat nog niet bezet is (unallocated). Het virtuele geheugen boven de 512 MB wordt door het besturingssysteem gebruikt (system arena).

Deze indeling zal op een PC met 64 MB werkgeheugen prima voldoen. In Vertraagd doorvoeren: OS/2 als slimme centrale bankier beschreef ik een 64 MB OS/2 Warp 4 systeem dat 213 MB virtueel geheugen gebruikte. Maar op een 512 MB systeem zal OS/2 snel tegen de virtuele adres limiet van 512 MB voor alle niet-systeem processen aanlopen. Het beschikbaar geheugen is verachtvoudigd, maar de virtuele adresruimte niet (maximaal 512 MB i.p.v. 8 x 213= 1704 MB). Op een systeem met veel geheugen (256 MB of meer, maar ik zag het ook al bij 128 MB) kan het dus voorkomen dat een programma niet wil opstarten, terwijl er nog fysiek geheugen vrij is.

In mijn praktijk beschikken mijn twee 512 MB OS/2 WPS systemen na het opstarten over minder dan 40-80 MB vrije ruimte in het 16 bits geheugengebied. Maar na een tijdje computeren, waarbij er steeds meer bibliotheken in de shared en private arena's geladen worden, kan de pret ineens ophouden:

RC:0 [eCS]I:\BIN\SYS\VIRTUALPC->VPC.EXE
SYS0008: There is not enough memory available to process this command.
All available memory is in use.

of

JunkBuster: can't fork: errno = 60

Het voor programma's beschikbare virtuele geheugen is op. PM programma's melden typisch dat ze DLL's die in de actieve directory of het LIBPATH staan niet kunnen vinden. Maar het echte probleem is dat ze deze bibliotheken niet meer kunnen laden. In het voorbeeld hieronder komt de klacht van Lotus Organizer. Onderzoek met DLL tree (pmdll28.zip), een programma dat de DLL afhankelijkheden van programma's en bibliotheken onderzoekt, levert op dat o.a. org32b.dll weigert te laden (rood). Maar volgens sysinfo was er nog 206 MB geheugen vrij.

Andere kenmerken zijn: het niet kunnen openen van bestanden (StarOffice,Virtual PC), het achterwege blijven van specifieke functies (bijv. het filteren van email door Post Road Mailer), lege dialoogvensters (Virtual PC), niet genoeg geheugen (SYS0147) foutmeldingen en programma's die niet lopen met SYS2070 fouten in popuplog.os2.

Deze foutmeldingen bleken in mijn praktijk te maken met een nagenoeg of volledig bezet virtueel geheugen in de shared arena. Met het programma Theseus kunt u dit nagaan: System / Linear Usage by Process. Theseus is op een Hobbes mirror verkrijgbaar. U krijgt een forse output van programma's en bibliotheken en waar ze in het geheugen geladen zijn. Gebruik de zoekfuncties Ctrl-F(ind) en Ctrl-A(gain) om naar het steekwoord "shared arena" te gaan.

There is 0.000M between the private and shared arenas.
Shared arena starts at 06640000, which is 102.250M.
Free memory from 06640000 for 109.000M, which is equivalent to 1744 64K spaces.

Op dit moment heb ik 109 MB geheugen vrij. Maar even even verder:

Total free space in the shared arena = 7.625M.

Oftewel: veel ruimte om de dynamic link bibliotheken van een applicatie in de shared arena op te starten heb ik niet. Lotus Organizer zal in die 7 MB zijn DLLs niet kunnen laden, tenzij een andere SmartSuite applicatie de door Organizer benodigde DLL's al in de shared arena (voor)geladen heeft.

In al deze gevallen is er dus onvoldoende geheugen in de shared arena vrij. De vraag is nu: Hoe los je dit op?

Het is vervelend, maar dit probleem lijkt veel op het 64 k probleem van de Windows 3.1 en 9x met de "systeembronnen". Een 64 K geheugengebied waarvan alle in venster schrijvende applicaties gebruik moesten maken. Als dat vol zat reageerden de applicatievensters niet meer.

Het is nog steeds een probleem van 16 bits Windows applicaties onder Windows 9x en NT: probeer maar eens met de handige Macro Editor van Windows 3.11 te werken onder Windows 2000 - die loopt na een tiental acties geheid vast. Helaas heeft MS geen 32 bits versie van dit anti-RSI pakket.

Fysiek geheugen toevoegen heeft dan geen effect. Programma's kunnen er geen toch gebruik van maken. Als die miezerige 64 K vol zit, heeft u niets aan een supercomputer met megabytes vrij geheugen. En worden er geen vensters meer geopend. Helaas geldt dat ook voor OS/2 met zijn paar honderd megabytes grote virtuele shared arena. Ook die kan volledig door DLLs bezet zijn. En dan kan geen enkele applicatie (WPS, PM of PM) meer opstarten.

Het zou mooi zijn als Lotus zijn DLLs in de private arena zou laden. Of dat de shared arena zou kunnen worden uitgebreid. Maar de private arena wordt onder OS/2 alleen gebruikt door programma's die hun bibliotheken niet delen. En hiervoor zouden de Lotus Smartsuite applicaties anders gecompileerd moeten zijn. Bovendien bewerkstelligt een Office Suite zijn integratie juist door bibliotheken te delen. En om iedere Smartsuite applicatie zijn eigen open32 subsysteem met Smartsuite DLL's mee te geven, gaat natuurlijk veel te ver. De geheugenvereisten zouden een normaal systeem (met minder RAM) teveel belasten.

Het uitbreiden van de shared arena boven de 512 MB is zeker een optie. Microsoft Office maakt bijv. gebruik van geheugen adressen boven de 512 MB. dat was de reden dat het draaien van MS Office Applicaties onder Odin lange tijd gedoemd was om te mislukken.

Maar met de Aurora kernel (WSeB, eCS, Warp 4 FP14) kwam daar verandering in. Met de volgende CONFIG.SYS instelling wordt het Windows NT systeem gehanteerd. Een gebruikersproces kan dan ook meer dan 512 MB virtueel geheugen aanspreken.

VIRTUALADDRESSLIMIT=2048

Hierbij komt de helft van de 4 GB virtuele geheugenruimte beschikbaar voor de programma's, de andere helft gaat naar het besturingssysteem. Het plaatje van de virtuele geheugenruimte ziet er dan zo uit.

Tot de weinige programma's die tot dit "hoge" virtuele geheugen boven de 512 MB gebruik kunnen maken behoren PMView, een deel van Virtual PC, op ODIN gebaseerde Java DLLs en de Freetype Cache van Innotek, Odin and Java 1.3. Maar StarOffice, Lotus SmartSuite, Netscape en niet te vergeten de WPS met al zijn bibliotheken, maken van de shared arena gebruik. Om die reden moest ik ook onder de Aurora kernel de geluidsintegratie van de WPS uitschakelen (zie: Bibliotheken deregistreren) om mijn 512 MB ten volle te benutten.

Voor degenen die op ODIN gebaseerde producten van Innotek gebruikt nog een tip: Laad ze niet tijdens de systeemstart al op. Dan worden ze nog wel eens in het (dan nog beschikbare) lage geheugen geladen. Open eventueel eerst StarOffice, SmartSuite en andere exclusieve gebruikers van het laag geheugen en daarna pas VPC en 32 bits Java versies. Dan worden de LIBS en caches die dat kunnen gedwongen van het hoge geheugen gebruik te maken:

There is 187.207M between the private and shared arenas.
Above 512m Shared arena starts at 2C000000, which is 704.000M.
 Free memory from 2C000000 for 1307.000M, which is equivalent to 20912 64K spaces.
7DB00000  ...................................................o      1  VPCWGSS  allocated it
 object is 512K
7DB80000  ...................................................o     21  VPCWIN   allocated it
 object is 2.000M
7DD80000  ...............................................o....      1  J2WIN    allocated it
 object is 512K
7DE00000  ...............................................o....     21  J2WIN    allocated it
 object is 2.000M
7E000000  ...............................................o....    256  FT2LIB   allocated it
 object is 32.000M
Total free space in the shared arena = 1307.000M.
< End of THESEUS4 (v 4.001.00) output @ 23:52:14 on 6/15/2003 >

Een 32 bits TCP/IP programma dat exclusief van de >512 MB adresruimte gebruik maakt (bijv. een Java programma in een hoog geladen Java Virtuele Machine), zou niet rechtstreeks van de laag geladen 16 bits TCP/IP stack gebruik kunnen maken. Maar met de 32 bits TCP/IP versie 4.1 heeft u dit probleem niet en kunt u Java in het 512-2048 MB gebied laden.

SET JAVA_HIGH_MEMORY=1

Daarmee raakt het 16 bits gebied minder snel vol.

Een derde CONFIG.SYS variabele betreft het uitzetten van de vaste laadlokaties (0x10000 load address offset) van de meeste DLLs in het virtuele geheugen. Hiermee laden ze iets minder snel, maar er komt 64-128 kB virtuele adresruimte vrij.

DLLBASING=OFF

Ten slotte is het wijs de optie THREADS niet onnodig hoog te zetten.

THREADS= 380

Iedere onnodig gereserveerde draad kost onnodig veel laag virtueel geheugen. Hier bestaat de paradox dat we vroeger het aantal draden moesten beperken om fysiek geheugen te besparen. Tegenwoordig speelt dat onbenutte draden virtueel geheugen gebruiken, dat dan niet meer voor andere programma's kan worden gereserveerd. het virtueel geheugengebruik van draden is moeilijk in te schatten (het kan per applicatie verschillen), maar houdt er rekening mee dat een onnodig hoog aantal draden het antal applicaties dat u op starten kunt beperkt.

Naschrift

Op 19 jan 2004 beschreef IBM's OS/2 kernel onderhouder Scott Garfinkle in comp.os2.bugs een "New kernel highmem feature" in de experimentele OS/2 kernels waarin de niet door het 16 bits OS/2 subsysteem gebruikte delen van Dynamische Link Bibliotheken hoger kunnen worden geladen:

For people who want to try out the latest stuff: As of the 20040116 kernels, I added a new feature, which should be considered beta/experimental. This feature allows loading parts of DLLs above the 512mb line. So, any DLL objects that do not need to be called by (for code) or addressed by (for data) 16 bit code can be moved out of the low shared arena. Since this is the place that most often runs out of room, causing sys0008 and similar, I'm hoping this is helpful.

Here's how it works: A new EXEHDR flag /HIGHMEM[:objnum] is used to turn on bit 16 of the OTE flags in one or more linker objects (if you don't know what this means, don't worry). If this flag is on and if the object is a 32 bit shared obj and isn't also marked as ALIAS, PACK, or IOPL, the kernel will try to load the object in the high shared arena, I've experimented with Mozilla and saved nearly 11mb of shared memory address space.

Download whatever kernel you need from ftp://testcase.boulder.ibm.com, then also download hdrtest.zip from that directory. What has worked for me is

EXEHDR /HIGHMEM MMPARTS.DLL > nul

EXEHDR /HIGHMEM:1 xx.dll > nul

; where xx is ever DLL in mozilla and mozilla/components except npoji6.dl.

For mmparts, you'll have to do this from a command prompt or something.

I will be interested in feedback.

-Scott

De thread geeft niet aan of het experiment geslaagd is.

Vaste schijf prestaties

> Top <

De duur van een zoekactie met view zal voornamelijk afhangen van de snelheid waarmee OS/2 de vaste schijf kan benaderen. Welke factoren lijken mij van belang?

Hardware

• Processor, geheugen(cache), PCI chipset op het moederbord.

• Vaste schijf (type, ingebouwde cache).

• Meerdere SCSI schijven zijn sneller dan meerdere IDE schijven.

• Maak gebruik van busmaster DMA.

De doorvoersnelheid van de legacy Direct Memory Access (DMA) controller op het moederbord is laag. Daarom werden voor snelle IDE schijven op ISA en PCI systemen PIO modes gebruikt, waarbij voor de overdracht van ieder paar bytes een processorcyclus werd gebruikt (PIO = Programmed I/O). Maar omdat dit dataverkeer via de processor wordt geleid, is overdrachtssnelheid sterk afhankelijk van de processor(belasting). Bij Small Computer System Interface (SCSI) systemen is dit veel minder het geval.

Sinds 1998 maakt het IBM stuurbestand voor IDE schijven IBMIBM1S506.ADD weer van DMA gebruik. Maar dit keer wordt de in de IDE schijf ("Integrated Drive Electronics") ingebouwde DMA controller meester van de systeembus (busmaster DMA). Het bus master device in de IDE schijf neemt dus zowel werk van de processor als van de trage DMA controller van het moederbord over. Het BIOS en het PCI moederbord moeten dit ondersteunen. Als IBM's stuurbestand uw PCI chipset niet met busmaster DMA ondersteund kunt u vaak van Daniella Engberts DaniS506.ADD gebruik maken.

Bestandssysteem en cache

Schakel voor ieder bestandssysteem een cache in. Ook een kleine read ahead cache (256 kB) levert al een merkbare snelheidswinst op. Leesacties zullen met een read ahead cache sneller verlopen. Gegevens die dicht bij elkaar staan, maken de grootste kans op opgevraagd te worden. Dit principe van de lokaliteit zorgt ervoor dat een cache bij het opvragen van een niet extreem gefragmenteerde schijf altijd wel een doel treft. En zolang de hit-rate van de vaste schijf (bijv. 50% treft doel) enige malen groter is dan de verhouding toegangstijd vaste schijf / toegangstijd geheugen is een cache ondanks de overhead meer dan de de moeite waard.

Moderne OS/2 versies gebruiken zowel het High Performance File System (HPFS) als het Journaled File System (JFS). De voordelen van het Journaled File System worden in Bestandssytemen en in Het Journaled File System onder OS/2 en Linux besproken. eComStation zal binnenkort ook van JFS kunnen booten.

Het High Performance File System (HPFS) valt op te krikken met een HPFS386 cache.

Met de opdracht:

cache386 /stats:d 

kunt u de effectiviteit van de HPFS 386 cache opvragen:

CACHE386 Statistics
Read Requests:              7716721     Disk Reads:        681507
Cache Hit Rate (Reads):          91%    Cache Reads:      7035214

Write Requests:              740064     Disk Writes:       106022
Cache Hit Rate (Writes):         85%    Lazy Writes:       634042

Hot Fixes:           0

Doordat de OS/2 INI bestanden niet lazy write gecached worden is de Write Request Cache Hit Rate soms laag. Met een patch van Peter Fitzsimmons (newcalls.dll) zijn 90% waarden te bereiken, maar dat gaf problemen bij backups van de Werkplek. Bovendien zal bij het cachen van de INI bestanden een trap-error vrijwel altijd schade aanrichten. Ik raad u dit daarom af.

Wel is het zo dat voor een object- georiënteerde multiprogramming omgeving een cache minder effectief is dan bij een spelletje dat op de voorgrond loopt. De reden is dat de opgevraagde gegevens van het spel zich voornamelijk in de /game directory en dan m.n. in /game/game.exe zullen bevinden, terwijl de WPS zijn data overal vandaan haalt. Bij mij van vele partities. Het principe van de lokaliteit is dan minder van toepassing. Daarom is een object georiënteerde omgeving geheugenintensief.

OS/2 lost dit op door zoveel mogelijk programmacode in het geheugen te laden. De meeste OS/2 programma's (inclusief de WPS) zullen bij het opstarten de naar verwachting benodigde DLL's en data in het geheugen laden. Die gegevens die niet onmiddellijk in het geheugen nodig zijn worden naar de centrale swapper.dat geswapt. Op die manier zijn de data en in de juiste vorm beschikbaar en snel beschikbaar, omdat nu wel aan de eis van de lokaliteit wordt voldaan. Het is immers veel effectiever om het stukje virtueel geheugen uit een enkel swapper.dat te pagen dan om complete DLL bestanden van allerlei plaatsen van de vaste schijf in het hoofdgeheugen te laden, om het virtueel geheugen aan de processor beschikbaar te stellen.

Physical Memory 261696 K Resident Memory 85420 K Allocating 176276 K 

Hierbij groeide ongebruikte swapper.dat van 8 naar 111 MB. Na enige tijd zakte hij naar 72 MB en kwam er 120 MB van de 256 MB fysiek geheugen vrij. De 173-130 MB (43 MB) fysieke geheugen werd meteen weer ingenomen door de draaiende applicaties (WPS, Netscape en StarOffice). Het OS/2 systeem gebruikte 85 MB resident memory, waarvan 64 MB voor HPFS, 10 MB voor FAT32, 2 MB voor FAT en 1 MB voor Ext2 (75 MB cache).

• HPFS is intrinsiek sneller dan (super)FAT, geoptimaliseerd voor intensief gebruik, maar heeft maar een 2 GB cache meegekregen.

• Gebruik van een grote 386HPFS of JFS cache.

• FAT32 is onder OS/2 merkbaar traag. Onder Windows is het snel (deels door primitieve structuur en grote FAT cache), maar niet geschikt voor mission critical transacties.

• BUFFERS=100 op FAT schijven (u zit niet met de geheugenrestricties van DOS).

• Het partioneringsschema (een 2 GB partitie op een 14 GB schijf is sneller te doorzoeken dan een 14 GB partitie, omdat er minder kopbewegingen worden gemaakt).

Meer informatie: Het HPFS 386 bestandssysteem en OS/2 Filesystem Shootout van Michal Necasek.

Besturingssysteem

Voor zware kopieeracties (mappen met duizenden bestanden) geen drag & drop gebruiken, maar de opdrachtregel of een bestandsbeheerder gebruiken die buiten de WPS om werkt (File Commander/2).

Met PRIORITY_DISK_IO=YES krijgen voorgrondtaken (dus vooral PM en WPS programma's) extra processortijd als ze de vaste schijf benaderen voor lees- of schrijfacties (I/O). Hun lees- en schrijfacties worden daarom minder snel onderbroken door draden met gelijke prioriteit die al langer in de wachtrij staan. En als de I/O actieve draad nieuwe code of data ingelezen heeft, kan hij er wellicht meteen mee aan de slag.

Op een moderne PC is PRIORITY_DISK_IO=YES de beste keus. Want dan hebt u er belang bij dat de programma's waarmee u nu werkt (en dat zijn de voorgrondprogramma's) sneller doorlopen. Maar op tragere PC's (< 100 MHz?) bestaat het risico dat tijdkritische taken die met normale prioriteit (2) op de achtergrond lopen time-outs krijgen. Dit speelde vroeger wel eens met langzame (modem)verbindingen. Dan zou PRIORITY_DISK_IO=NO er voor kunnen zorgen dat de CPU tijd gelijk verdeeld wordt tussen de browser op de voorgrond en het niet minder belangrijke inbelprogramma op de achtergrond dat de schijf niet benaderd.

Zaken die geen haast hebben, kunt u met idle priority starten.

Video prestaties

> Top <

Grafische besturingssystemen vragen veel van de processor. De opdracht "teken een blauw scherm" wordt pixel voor pixel uitgevoerd. Want de slechts met de inhouden van hier videogeheugenadressen bekende processor en heeft er geen notie van wat u met een blauw scherm bedoeld.

De eerste videokaarten waren geheugenbuffers. De processor stuurde zowel het voor de programma's als voor de videoweergave gereserveerde delen van het werkgeheugen aan. Dit werkte prima in de tekstmodus van DOS en WordPerfect. Een VGA (Video graphips array) scherm kent 640 maal 480 pixels. In grafische modus moet de processor terwijl u in het tekstverwerkingsprogramma WordPerfect een letter typt dus 640 maal 480 pixels bijwerken. Maar in tekstmodus hoeven slechts het aantal tekens van de VGA modus bijgewerkt te worden. En als in VGA modus hex11 de lettergrootte 16x8 pixels is, dan gaat het maar om het aansturen van 80 maal 30 tekens. En als het om slechts twee kleuren gaat, zijn er maar 80 maal 30 maal 2 is 720 mogelijkheden.

Vergeleken met het bloksgewijze aanstuurwerk van ASCI tekstmodusprogramma's, geeft het afbeelden van fonts op een grafische gebruikersinterface (GUI) vele malen meer rekenwerk. Hier moet de kleur van iedere pixel op het scherm opnieuw worden gedefinieerd. Om een 640x480 beeldscherm in 16 kleuren weer te geven zijn er 4915200 mogelijkheden. En dat vergt veel meer rekenwerk. De ontwerpers van eerste grafische interfaces waren dan ook geen kunstenaars, maar kenners van wiskundige algoritmen. Ze moesten slimme wegen vinden om met minimale code bij iedere gebruikersactie de hierbij passende videogeheugenadressen snel te laten bijwerken.

Gelukkig kon hun werk ook in de hardware worden geïmplementeerd. Het rekenwerk werd verricht door grafische co-processors en later door videoversnellerkaarten. Deze gespecialiseerde videokaarten beschikten over hun eigen videogeheugen en konden met relatief simpele opdrachten van de processor hele blokken van pixels (bitmappen) in hun eigen videogeheugen tekenen en snel over het beeldscherm (lees videogeheugen) verplaatsen. Dergelijke in de videokaart ingebakken bitmaptechnieken spelen bij het scrollen door grafische teksten en het verplaatsen van vensters een grote rol. De opdracht voor een sleepactie wordt nog steeds door de processor gegeven. Maar het rekenwerk wordt nu aan de hierin gespecialiseerde Grafische Processor Unit (GPU) van de videokaart uitbesteed. En die GPU is weer direct met het videogeheugen op de videokaart verbonden. Vervolgens zet een eveneens op de videokaart aanwezige RAMDAC chip het digitale signaal om in een analoog signaal, dat naar uw beeldscherm gestuurd wordt.

Voor de snelle weergave van bewegende 2D afbeeldingen (video, scrollen) en zeker voor 3D spelletjes is directe toegang tot de videokaart vereist. De processor moet de taal van de GPU van uw videokaart kunnen spreken. Om de processor maximaal te ontlasten moet de grafische API van het besturingssysteem dus over stuurbestanden beschikken die het maximale uit de hardware van uw grafische processor (GPU) halen. En natuurlijk moeten uw programma's hier ook gebruik van kunnen maken.

Onder Windows 95 werd de slechts voor haar eigen 32 bits Windows besturingssystemen geleverde Microsoft DirectX bibliotheek populair. Programma's roepen hem aan en kunnen hiermee de grafische processor direct instrueren, Microsoft leverde de software en specificaties van de 32 bits DirectX API en de videokaart producenten leverden hun voor deze Windows API geoptimaliseerde stuurbestanden.

Er waren ook ander grafische API's die niet aan het Windows platform waren gebonden. De bekendste is OpenGL (http://www.opengl.org). De API is nog steeds beschikbaar, mar hij wordt nog nauwelijks gebruikt. De reden is dat iedere Windows OEM PC al over Microsofts DirectX API beschikt en Microsoft patenten claimt over de in de praktijk niet zo open OpenGL bibliotheek (Microsoft stakes IP claims on OpenGL). En de vele software patenten van software makelaar Microsoft schrikken game ontwikkelaars af.

In de praktijk werd de ontwikkeling van OS/2 stuurbestanden steeds vaker aan SciTech uitbesteed. Deze firma leverde de beste OS/2 videodrivers. De basis vormt IBM's stabiele GRADD API. De chipset specifieke info wordt vervolgens in het SciTech videodriversysteem geïntegreerd. De door IBM gelicenseerde versie van de SciTech Display Doctor for OS/2 (SDD) (minimaal OS/2 Warp 4 met fixpak 5 of Warp 3 met fixpak 35) is gratis, maar voor de officiële versie met veel gemak en de beste resoluties (Mensys) moet u betalen.

Hierdoor werd de OS/2 gebruiker op kosten gejaagd: Hij betaalt voor de hardware en de ontwikkeling van stabiele 3D Windows stuurbestanden, maar moet ook nog eens de SciTech Display Doctor for OS/2 (SDD) of opvolger SciTech SNAP Graphics for OS/2 aanschaffen. Anderzijds is het toch wel prettig om te constateren hoe goed een al vele malen dood verklaard besturingssysteem met recente videochips uit te voeten kan. SciTech is qua stabiliteit een begrip - en omdat deze technologie op meerdere platforms kan worden toegepast - niet meer weg te denken. Als SciTech goede videodrivers voor OS/2 ontwikkelen blijft: dat is me wel wat waard.

OS/2 werd geen 3D platform. Maar PM programma's kunnen de videokaart wel direct beschrijven. De 2D ondersteuning is goed genoeg voor beeldvullende MPEG video. Zeker met een HW EnDive (WarpOverlay) of de op SNAP gebaseerde overlay technieken die

> OS/2 Index <

Enige literatuur:

The designer's model of the CUA Workplace van R. E. Berry in IBM Systems Journal, Volume 31, Number 3, Page 429 (1992)

The design of Operating System/2 van M. S. Kogan, F. L. Rawson III in IBM Systems Journal, Volume 27, Number 2, Page 90 (1988).

Understanding device drivers in Operating System/2 van A. M. Mizell in IBM Systems Journal, Volume 27, Number 2, Page 170 (1988)

Presentatie van Frank Meilinger over 3.3 OS/2 address range

Memory Analysis in OS/2 : Internet archief

Hunting memory bugs

The Life Cycle of a Memory Page in OS/2

EDM/2 - Digital Sound & Music Interface for OS/2

Comparison of OpenGL and Direct3D