Programmiererecke: Treibjagd

An SpeedoGDOS wird wieder gearbeitet - wird, was lange währt, endlich gut?

Der Lieferumfang des Atari-SpeedoGDOS läßt kaum zu wünschen übrig: neben zahlreichen Zeichensätzen (der Speedo-Distribution liegen 14, Ataris neusten Falcons immerhin 18 Vektorzeichensätze bei) und verschiedenen Treibern bat man sich auch die Mühe gemacht, die Installation von Treibern und Fonts möglichst einfach zu gestalten. Deshalb liegen dem GDOS zwei Programme bei, die das Erzeugen der »ASSIGN.SYS«- und »EXTEND.SYS«-Datei übernehmen. Das SpeedoGDOS selbst hätte jedoch ein paar Wochen mehr Arbeit verdient, um ein wirklich gutes Produkt zu werden. Während sich Atari in den letzten Monaten verstärkt der Umsetzung der AES und des VDI gewidmet hat beginnt nun tatsächlich noch einmal die Überarbeitung des SpeedoGDOS.

Es hat zahlreiche ellenlange Briefe gekostet, bis Atari endlich davon überzeugt war, daß ein oder zwei Monate Arbeit an Speedo sicher keine Fehlinvestition sind. So wird man sich hoffentlich den von uns an dieser Stelle bereits mehrfach angemahnten Problemen annehmen.

Doch, wie das bei gewachsenen Systemen oft der Fall ist: flickt man ein Loch, so findet man dabei drei weitere. Ein wirkliches Ärgernis ist die Tatsache, daß der bislang ausgelieferte »MEMORY.SYS«-Treiber zwar grundsätzlich seinen Dienst tut, daß er jedoch in einer Multiprozeßumgebung wie Ataris »MultiTOS« die klassischen Probleme des VDI-Treiberkonzeptes zutage treten läßt.

So ist beispielsweise der Bildschirm das einzige VDI-Gerät, auf das mehrere Prozesse quasiparallel zugreifen können. Die Koordination dieser Zugriffe erfolgt jedoch nicht über eine VDI-Funktion, wie man das eigentlich vermuten müßte. Vielmehr übernimmt eine AES-Funktion, genauer: »wind_update()« die Koordination, obschon sie eigentlich den AES, und, wenn man es ganz penibel halten möchte, den Window-Funktionen zugeordnet ist. Diese konzeptionelle Unstimmigkeit ist in der Regel nicht weiter tragisch, zumal auf den Bildschirm ohnehin nur durch Fenster zugegriffen werden sollte und die wenigen Ausnahmen zwar ästhetisch störend, jedoch in aller Regel nicht funktionsgefährdend sind.

Leider mußte dieser »Semaphor« (Betonung auf der letzten Silbe) in der Vergangenheit für eine ganze Reihe anderer Zwecke herhalten, für die sie nicht vorgesehen war, in der sie aber oftmals die einzige Möglichkeit zur koordination zwischen verschiedenen Prozessen war. Diese Zweckentfremdung gipfelte schließlich darin, daß viele Programme ihre Disketten- und Festplattenzugriffe durch »wind_update()« klammerten, um damit einem Fehler in der »etv_critic«-Fehlerbox zu entkommen, der bei älteren Betriebssystemversionen zum Systemabsturz führen konnte.

Daß dieser »Fehlerschutz« nur dann funktionieren konnte, wenn sich restlos alle im System befindlichen Prozesse an dieses schwer einzusehende Verfahren hielten, störte dessen Propagandisten wenig. Daß jedoch eine Window-Funktion zur Klammerung von Dateizugriffen herhalten sollte, störte nicht nur die Verfechter der »reinen Lehre«, sondern viele Programmierer mit etwas gesundem Menschenverstand: das Klammern würde ein wirkungsvolles Multitasking stark erschweren - eine Sorge, die sich bei Einführung des MultiTOS prompt als berechtigt erwies.

Jedoch wirft das Problem eine grundsätzliche Frage auf. Wenn es schon bei der Koordination von Bildschirmausgaben eines echten VDI-Semaphoren mangelt, wie stehts dann mit all den anderen VDI-Treibern?

Die derzeitige Implementation des VDI beantwortet diese Frage recht eindeutig: auf ein VDI-Gerät kann stets nur ein Prozeß zugreifen - die einzige Ausnahme ist der Bildschirm. Für alle anderen Geräte sind virtuelle Workstations nicht gestattet. Sie bieten allein physikalische Workstations. Das ist prinzipiell erst einmal kein Problem, weil die Anwendung virtueller Workstations auf beispielsweise Druckertreibern schwer vorstellbar ist: sollte ein Prozeß beispielsweise stets den Briefkopf erzeugen, während ein anderer den Inhalt zu Papier bringt? Oder die Behandlung eines FAX-Treibers - ein Prozeß ist für die Adresse zuständig, ein anderer für den Inhalt? Beides denkbar, aber doch ein wenig sehr aus der Luft gegriffen.

Sehr ärgerlich ist hingegen die Tatsache, daß jeder VDI-Treiber nur eine einzige physikalische Workstation zur Verfügung stellt. Denn wenn schon nicht mehrere Prozesse auf ein und dieselbe Seite zugreifen können, so möchten Sie doch vielleicht auf zwei verschiedene Seiten zugreifen. Das gewinnt dann an Interesse, wenn mehrere Prozesse beispielsweise über den »MEMORY.SYS«-Treiber Speicherseiten erzeugen möchten.

Die derzeitige Dokumentation läßt nur den Schluß zu, daß so etwas nicht geht - der zweite Prozeß sollte vom Treiber daran gehindert werden, eine physikalische Workstation zu öffnen. Der »v_opnwk()«-Aufruf sollte einen Fehler zurückliefern. Das passiert aber nicht. Stattdessen verhält sich der Treiber, als wisse er von nichts und gestattet dem zweiten Prozeß den Zugriff. Daß dabei das Chaos in Reinkultur entsteht, brauchen wir wohl nicht näher zu erläutern. Keiner der beiden Prozesse weiß vom anderen, dennoch zieht der erste Prozeß, der seine physikalische Workstation schließt, dem anderen dessen Arbeitsbasis unterm Hintern weg. Die physikalische Workstation ist dann geschlossen und der »Veteranenprozeß« guckt in die Röhre.So geht‘s also schonmal nicht. Zunächst einmal müßte demnach sichergestellt werden, daß wirklich nur ein Prozeß auf eine physikalische Workstation zugreift. Das geschieht unserer Erfahrung nach bei den bestehenden Druckertreibern auch, »MEMORY.SYS« macht die Ausnahme, die dringendst überarbeitet gehört.

Grundsätzlich sollte man sich jedoch überlegen, ob nicht einige der Treiber mehrere physikalische Workstations anbieten sollten. Das ist natürlich erst einmal wieder für den »MEMORY.SYS«-Treiber interessant, der mehreren Prozessen gleichzeitig zur Verfügung stehen sollte. Aber auch andere Treiber könnten davon profitieren: so existierten von unserem Autor Julian Reschke eine Reihe von Treibern, die Ausgaben in eine Datei umlenken und als ».IMG«-Rasterdatei speichern. Weiterhin sollte auch der »META.SYS«-Treiber in der Lage sein, mehrere Metafiles gleichzeitig zu bearbeiten. Schließlich sollte man sich überlegen, ob nicht auch Drucker- und Faxtreiber ein solches Feature bieten sollten. Damit ließe sich beispielsweise mit verhältnismäßig geringem Aufwand ein vom System bereitgestellter Druckerspooler realisieren: im einfachsten Fall würden die Programme ihre Seiten bei jedem »v_updwk()«-call und damit unter Umständen quer durcheinander ausgeben. Ein etwas intelligenterer Treiber könnte alle Seiten im RAM oder auf Disk zwischenspeichern und prozeßweise nacheinander ausdrucken. Sobald einer der Prozesse seine Workstation schließt, gibt er die Seiten anderer Applikationen zum Ausdruck frei. Naturgemäß ist dies etwas schwieriger zu bewerkstelligen, da insbesondere beim »v_updwk()«-Aufruf auf größtmögliche Kompatibilität zu bestehenden Treibern geachtet werden müßte.

Denkbar ist so ein System jedoch fraglos, und wünschenswert wäre es auch, insbesondere angesichts der Tatsache, daß viele Drucker über die serielle oder parallele Schnittstelle angeschlossen sind und deshalb oftmals recht langsam arbeiten. Ein Systemspooler könnte hier merklich für Entzerrung sorgen. (uw)