MultiTOS - Ein Blick in die Zukunft

Zwar wird es noch einige Monate dauern, bis das neue MultiTOS für den Atari offiziell erhältlich ist; aber was die Leistungsmerkmale dieses Systems betrifft, konnte man in letzter Zeit bereits einiges lesen. Dabei wurde das MultiTOS jedoch stets aus der Sicht des Anwenders betrachtet. Wie schaut es aber für den Programmierer aus? Was gibt es zu beachten, damit eigene Programme möglichst reibungslos unter MultiTOS laufen?

Nun, da es bisher keine verläßlichen detaillierten Angaben über Neuheiten im Hinblick auf die Programmierung des MultiTOS gibt, setzt man am besten bei dem an, was es auf der CeBIT während der offiziellen Vorführungen sowie auf diversen Messeständen an Features zu sehen gab. Darüber hinaus lassen sich aus den bereits erhältlichen Mehrprozeß-Systemen, nämlich MiNT und MultiGEM, einige wichtige Rückschlüsse für die Gestaltung eigener Programme ziehen.

Dornröschenschlaf

Die Idee des Multitasking gibt es nicht erst seit gestern. Auf anderen Rechnern finden sich solche Systeme bereits seit geraumer Zeit. So ist der parallele Ablauf mehrerer Prozesse unter UNIX immer schon Alltag gewesen. Auf dem Apple Macintosh gibt es seit Jahren den MultiFinder, unter DOS stehen Microsoft WINDOWS und IBM OS/2 zur Verfügung. Schließlich besitzt auch der Commodore Amiga ein Betriebssystem, das auf Multitasking ausgelegt ist. Man gewinnt hier die Erkenntnis, daß Atari, was diese Thematik betrifft, lange Zeit geschlafen hat. Aber dieser Schlaf ist ja nun vorbei.

Nun ist Multitasking nicht gleich Multitasking. Kernpunkt solcher Systeme ist natürlich die Möglichkeit, diverse Anwendungen nebeneinander laufen zu lassen, wobei die Zahl der parallel arbeitenden Prozesse lediglich durch den zur Verfügung stehenden Speicherplatz eingeschränkt sein sollte. Unterschiede ergeben sich allerdings bereits in der Art und Weise, wie das Hin- und Herschalten zwischen den einzelnen Programmen vonstatten geht. Schauen wir uns diesen Mechanismus am Beispiel von MultiGEM an, das bereits seit längerem auf dem Markt ist. Hier geschieht die Prozeßumschaltung immer dann, wenn ein Programm die AES (Application Environment Services, Plural!) aufruft. Setzt die Anwendung während eines gewissen Zeitraums keinen AES-Aufruf ab. kommt unter MultiGEM kein anderer Prozeß zum Zuge, es findet also keine Prozeßumschaltung statt. MultiGEM baut darauf, daß eine Anwendung zugunsten anderer Prozesse Rechenzeit abgibt. Man spricht in diesem Zusammenhang von kooperativem Multitasking.

Das Gegenstück hierzu ist das preemptive Multitasking. Hier kommt es nicht darauf an, daß der laufende Prozeß freiwillig Rechenzeit abgibt, sondern das System entscheidet, wann die nächste Anwendung zum Zuge kommt. Somit kann das aktive Programm zu jedem Zeitpunkt unterbrochen werden. In der Regel läßt sich für jede Anwendung eine Priorität festlegen, nach der die Rechenzeil verteilt werden soll. Dieser Mechanismus ermöglicht es, die Prioritäten einzelner Prozesse gegeneinander abzustufen und so die Leistung des Rechners auf den für den Benutzer wichtigsten Prozeß zu konzentrieren.

Eine eingeschränkte Form des kooperativen Multitaskings war auf dem Atari in Form von Accessories übrigens schon immer vorhanden. Diese können aus jedem (sauber programmierten) GEM-Programm heraus aufgerufen werden und stehen somit quasi parallel zum Hauptprogramm zur Verfügung.

MiNT is Now TOS?

Das Gerücht, daß Ataris MultiTOS in wesentlichen Bestandteilen auf einem bereits existenten System basiert, verdichtete sich auf der CeBIT zur Gewißheit. Grundlage des neuen TOS stellt das MiNT-Kernel des Kanadiers Eric Smith dar. Einigen Programmierern dürfte das Freeware-Produkt MiNT („MiNT is Not TOS“) bereits bekannt sein. Es erlaubt auf Atari ST und TT einen preemptiven Multitasking-Betrieb auf GEMDOS-Ebene. Es ist also möglich, eine grafische Anwendung unter GEM sowie beliebig viele GEMDOS-Prozesse parallel laufen zu lassen. MiNT orientiert sich in seiner Struktur stark an UNIX, so daß man viele Eigenschaften aus diesem Bereich hier wiederfindet. Die Portierung Shell-orientierter UNIX-Software wird so begünstigt.

Die Entscheidung, MiNT für das MultiTOS zu lizensieren, darf wohl als überaus positiv gewertet werden. Seit mehreren Monaten ist MiNT bereits unter Programmierern im Umlauf, wobei sogar die Quelltexte für jedermann einsichtlich sind. So gesehen, dürfte es sich beim nicht grafikorientierten Teil des neuen TOS um ein bereits zum jetzigen Zeitpunkt gut ausgetestetes System handeln.

Für den Programmierer bedeutet die Verwendung von MiNT, daß er, egal ob eingetragener Entwickler oder nicht, jederzeit die Möglichkeit hat. seine Anwendungen hinsichtlich des MultiTOS auf der Basis von MiNT zu testen. Man darf davon ausgehen, daß Programme, die unter MiNT Schwierigkeiten bereiten, in Verbindung mit dem neuen TOS erst recht nicht laufen werden. Der Einsatz von MiNT hat darüber hinaus den interessanten Nebeneffekt, daß man selber an der Entstehung eines neuen Betriebssystem-Kerns teilhaben und durch Bug-Reports dafür sorgen kann, daß MultiTOS möglichst fehlerfrei wird. Für all diejenigen, die konstruktive Kritik an MiNT (und damit indirekt an MultiTOS) üben wollen, die email-Adresse von Eric Smith: eric.smith@uwo.ca

Bild 1: Wieviele Fenster hätten ’s denn gern?

Speicher-Problematik

Daran, daß es Programme gibt, die unter MiNT nicht korrekt arbeiten, zeigt sich, daß teilweise bereits auf GEMDOS-Ebene unsauber programmiert wird. Beliebte Fehler bei der Nutzung der GEMDOS-Routinen finden sich in Verbindung mit der Speicherverwaltung. Zunächst einmal gilt schon seit jeher die Devise: „Thou shalt not mess with memory thou ownest not.“ Dieses Zitat aus dem PEXEC Cookbook der Atari-Entwicklerdokumentation erfreut sich zunehmender Beliebtheit, wird nur leider nicht konsequent beherzigt. Zugriffe auf Speicherbereiche, die nicht vorher mit MALLOC korrekt vom eigenen Programm alloziert wurden, können nicht nur auf Multitasking-Systemen verheerende Folgen haben. Insbesondere eine virtuelle Speicherverwaltung kommt bei solch unsauberen Methoden leicht aus dem Tritt [2].

Aber man kann auch andere Fehler beim Allozieren von Speicher machen. So gehen manche Programme davon aus, daß sie bei kurz aufeinander folgenden MALLOC-Aufrufen direkt hintereinander liegende Speicherbereiche zugewiesen bekommen, die sich bei Bedarf zu einem einzigen Speicherblock zusammenfügen lassen. Und dann gibt es noch den Programmierer, der glaubt, wenn man mit MFREE einen großen Speicherbereich an das System zurückgibt und gleich darauf einen MALLOC-Aufruf für einen kleineren Speicherblock macht, bekäme man einen Bereich mit dergleichen Startadresse zugewiesen, wie der vorherige Block sie besaß. Darüber hinaus seien auch noch alle Daten in diesem Bereich unverändert.

Ein solches Verhalten des GEMDOS war nie dokumentiert, und spätestens seit MiNT können sich solche Methoden rächen. Man muß schließlich jederzeit damit rechnen, daß ein anderer Prozeß zwischen zwei Speicheranforderungen ans Ruder kommt und sich einen Speicherblock reservieren läßt. Von zusammenhängenden Bereichen für das eigene Programm kann dann gar nicht mehr die Rede sein. Es kann sogar so weit kommen, daß man nicht einmal mehr den Speicher vom System zugewiesen bekommt, der kurz vorher noch als frei gemeldet wurde. Konstruktionen wie MALLOC(MALLOC(-1)) sollten deshalb nicht verwendet werden. Die MALLOC-Funktion ist also in Zukunft bedachtsamer einzusetzen.

User statt Supervisor

Um Schwierigkeiten mit systemnahen Programmen, insbesondere Gerätetreibern, aus dem Wege zu gehen, findet unter MiNT eine Prozeß-Umschaltung nur dann statt, wenn der Prozessor sich im User-Modus befindet. Die Konsequenz aus diesem Verhalten ist, wirklich nur dann mittels SUPER oder SUPEXEC in den Supervisor-Modus zu wechseln, wenn Aufgaben erledigt werden müssen, die privilegierte Prozessorbefehle benötigen, oder bei denen auf im User-Modus geschützte Speicherbereiche zugegriffen wird.

Traurigerweise gibt es Programme auf dem deutschen Markt, die direkt nach dem Start in den Supervisor-Modus gehen und dort verbleiben. Auf diese Weise wird das Multitasking-Konzept von MiNT wirkungsvoll untergraben, denn es findet kein Prozeßwechsel mehr statt. Der Anwender solcher Produkte ist wieder einmal der Leidtragende der unsauberen Programmierung.

GEMDOS-Ausgaben bevorzugt

Die meisten Textverarbeitungen für den Atari haben es schon längst erkannt: Es geht nicht an, daß man für die Textausgabe auf Druckern die Hardware direkt anspricht. Zu leicht könnten sich die Ausgaben eines anderen Prozesses hinzugesellen, und das Chaos bricht aus. Aus diesem Grund bieten viele Programme die Möglichkeit, Ausgaben wahlweise selber durch direkte Ansteuerung der Hardware zu übernehmen (was natürlich der schnellste, dafür aber der unsauberste Weg ist) oder diese Aufgabe dem BIOS zu überlassen. Leider ist auch die letztgenannte Methode in einem Multiprozeß-System nicht wasserdicht. Es gibt nämlich keine Möglichkeit, für die Dauer der Datenausgabe eine BIOS-Funktion quasi zu reservieren, also für andere Prozesse zu sperren. Somit ist es auch bei BIOS-Ausgaben stets denkbar, daß ein anderes Programm dies zur gleichen Zeit versucht.

Der einzig sichere Weg, ein Durcheinander beim Ansprechen der Schnittstellen zu vermeiden, ist die Nutzung des GEMDOS. Schon immer bot TOS die Möglichkeit, die Druckerschnittstellen über Gerätedateien anzusprechen. Um beispielsweise einen Text über die Centronics-Schnittstelle an den Drucker zu schicken, kann man eine Datei mit dem Namen „PRN:“ öffnen und die Daten dann per FWRITE ausgeben. Nach Beendigung des Druckvorgangs muß wie bei „normalen“ Dateien auch lediglich noch ein FCLOSE abgesetzt werden. Analog läßt sich die serielle Schnittstelle ansprechen, wenn man als Dateinamen „.AUX“ benutzt.

In einem System, das wie MiNT File-Locking beherrscht, ist bei einer Ausgabe nach dem obigen Muster die Schnittstelle exklusiv für den Prozeß reserviert, der die Gerätedatei als erstes geöffnet hat. Andere Programme haben während dieser Zeit keine Möglichkeit, über das GEMDOS auf den Drucker-Port zuzugreifen. FOPEN liefert in diesem Fall einen Fehlercode zurück, und die Ausgabe muß abgebrochen bzw. erst einmal verschoben werden. Wenn man also in eigenen Programmen nicht darauf verzichten will, die Druckerschnittstelle über eigene Routinen anzusprechen, muß die Alternative hierzu nicht die Ausgabe über das BIOS, sondern über das GEMDOS sein.

Bild 2: Eine Zeile gewonnen

Der aktuelle Stand

Zum Zeitpunkt der Drucklegung dieses Artikels ist MiNT bei der Versionsnummer 0.94 angelangt. Interessanterweise offenbaren sich in dieser Version Fehler im Standard-Desktop des Atari, die mit der Unterscheidung zwischen GEMDOS-und BIOS-Laufwerken Zusammenhängen.

So darf man diese beiden Systemebenen nicht in einen Topf werfen, wenn es um die Frage geht, ob ein dem System bekanntes Laufwerk dem BIOS oder dem GEMDOS zugeordnet ist. Eine Reihe von Programmen, darunter auch das Desktop des Atari, geht davon aus, daß alle über das GEMDOS erreichbaren Laufwerke in der Systemvariablen _drvbits vermerkt sind bzw. über die BIOS-Funktion DRVMAP erfragt werden können. Diese Annahmen sind jedoch grundsätzlich falsch. _drvbits ist eine BIOS-Variable und hat somit nur Aussagekraft in Verbindung mit BIOS-Aufrufen. Einen Bit-Vektor, der die dem GEMDOS bekannten Laufwerke beschreibt, erhält man durch den Aufruf der GEMDOS-Funktion DSETDRV, der zweckmäßigerweise gemäß DSETDRV (DGETDRV()) erfolgt, damit das aktuelle Laufwerk unverändert bleibt. Dieser Vektor muß anstelle von _drvbits als Grundlage für Laufwerkszugriffe auf GEMDOS-Ebene genommen werden.

Wie kann sich die falsche Verwendung von _drvbits in der Praxis äußern? MiNT richtet zusätzliche, über das GEMDOS erreichbare, Pseudo-Laufwerke Q, U, V und X ein, die spezielle Funktionen erfüllen, auf die hier nicht näher eingegangen werden soll. MiNT 0.94 kann nun so konfiguriert werden, daß diese Laufwerke (korrekterweise) nicht in _drvbits eingetragen werden. Dies hat zur Folge, daß dem Desktop und anderen Programmen, die _drvbits statt DSETDRV benutzen, solche Laufwerke nicht bekannt sind.

Einen unliebsamen Effekt durch falsche Benutzung von _drvbits kann man bei RAM-Disks feststellen. Dadurch, daß sich eine ganze Reihe solcher Programme des _dvrbits-Vektors bedient, kann es dazu kommen, daß die RAM-Disk eine Laufwerkskennung erhält, die auf GEMDOS-Ebene schon vergeben ist. Somit kann ein GEMDOS-Laufwerk nach der Installation der RAM-Disk ohne ersichtlichen Grund verschwinden.

Von MiNT zu MultiTOS

Wenden wir uns nun den grafischen Bestandteilen des neuen TOS zu, die den hauptsächlichen Unterschied zwischen MiNT und MultiTOS ausmachen.

Um auch GEM-orientierte Programme in einer Multitasking-Umgehung lauten zu lassen, müssen in erster Linie die AES und das GEM-Desktop entsprechend angepaßt werden. Diese Aufgabe obliegt in den kommenden Wochen und Monaten Atari, wobei ein gewisser Teil ja bereits getan ist. Es kommt darauf an, ein stabiles System zu erhalten, das möglichst kompatibel zu den bisherigen AES ist. Dabei darf man es mit der Kompatibilität natürlich nicht zu weit treiben. Im Klartext: Es sollte nicht so sein, daß zu Gunsten einiger Software-Häuser, die ihre unsauber programmierten Produkte als überaus wichtig erachten, Abstriche in der Funktionalität des MultiTOS gemacht werden. Es muß lediglich gewährleistet sein, daß Programme, sie sich strikt an die bisherigen Programmier-Richtlinien halten, auf dem Multi-TOS laufen werden. Software, die sich unsauberer Methoden bedient, muß halt an die neuen Gegebenheiten angepaßt werden. Dafür dürfte bis zum Erscheinungsdatum des neuen TOS noch genügend Zeit sein.

Es wäre müßig, erneut auf all das hinzuweisen, was es im Rahmen sauberer Programmierung zu beachten gibt. Hier empfiehlt sich ein Blick in die Fachliteratur [1]. Eines ist jedoch klar: Programme, die insbesondere zur Bildschirmausgabe nicht ausschließlich die vom Betriebssystem zur Verfügung gestellten Routinen verwenden, werden definitiv Schiffbruch erleiden. Ein wichtiger Faktor für die fehlerfreie Funktion eines Multitasking-Systems ist schließlich die ständige Überwachung der Ein- und Ausgabeoperationen durch das Betriebssystem. Ein einfaches Beispiel verdeutlicht, was passieren kann, wenn ein Programm seine Grafikausgaben nicht auf das VDI oder die AES stützt: Der unsaubere Zugriff auf den Bildschirm sorgt dafür, daß die Grafik auch in Fenstern anderer Programme erscheint und dort ohne das Wissen der betroffenen Anwendungen den Fensterinhalt zerstört.

Fenster massenweise

Beschäftigen wir uns weiter mit der Fenster-Thematik. ST-Anwendern ist vielleicht das Programm WINX ein Begriff, das es unter TOS 1.04 und in der neuesten Version auch bei anderen TOS-Versionen erlaubt, die Zahl der maximal verfügbaren Fenster zu erhöhen. Unter MultiTOS gibt es hier keine Obergrenze mehr, sofern ausreichend Hauptspeicher zur Verfügung steht (Abbildung 1). Auch wenn es zunächst erstaunen mag, daß dieser Umstand manchen Programmen Kopfschmerzen bereitet, stößt man hier und da tatsächlich auf ein fehlerhaftes Verhalten.

So mögen es einige Programme gar nicht, wenn sie als Fenster-Handle einen Wert zurückgeliefert bekommen, der die Zahl 7 überschreitet. Dabei muß noch lange kein Fehler vorliegen, wenn das gerade geöffnete Fenster eine viel größere Identifikationsnummer als bisher üblich zugeordnet bekommt, in Zukunft wird die Eigenschaft einer ganzen Reihe von Programmen, maximal 4 Fenster zu unterstützen, als Einschränkung des Anwenders gelten. Wenn möglich, sollte man seine Fensterstrukturen intern dynamisch verwalten. Bereits heute befindet sich eine Reihe von Programmen auf dem Markt, die dies beherzigen und in Verbindung mit WINX und MultiTOS beliebig viele Fenster erlauben.

Optimal genutzt

Werfen wir nun einen Blick auf Abbildung 2. Hier wurde ein Programm gestartet, das den horizontalen Scroll-Balken nicht benötigt, ihn beim wind_create-Aufruf also nicht als Fensterbestandteil aufgeführt hat. Bei den bisherigen AES-Versionen fand man an solchen Stellen einen leeren Balken vor, wie in der linken Hälfte der Abbildung zu erkennen ist. Das AES des MultiTOS nutzt diesen Bereich sinnvoller aus (rechte Hälfte des Bildes), indem es ihn für die Darstellung benutzereigener Daten freigibt. Der Arbeitsbereich von Fenstern, die keine Scroll-Balken besitzen, vergrößert sich in Zukunft also. Programme, die bei der Berechnung von Fenstergrößen die Annahme machen, daß grundsätzlich ein Scroll-Balken vorhanden ist, werden keine rechte Freude an dieser sehr praktischen Neuerung haben. Aber nicht erst seit MultiTOS gibt es die wind_calc-Funktion, die den AES die Berechnung von Gesamt- und Arbeitsbereich eines Fensters überläßt. Wer sich an die Richtlinien gehalten hat und diesen Aufruf in seinen Programmen verwendet, wird in diesem Punkt keine Schwierigkeiten mit dem MultiTOS haben. Andernfalls heißt es: Bereits jetzt für Abhilfe sorgen, damit bis zum Erscheinen des neuen TOS alles in Butter ist.

Noch ein weiterer Hinweis zu den Fensterelementen. Das Umschalten zwischen zwei Prozessen geschieht unter MultiTOS und MultiGEM in der Regel durch Anklicken eines Fensters. Wer in seinen Programmen auf das Größenfeld als Fensterelement verzichtet, erschwert dem Anwender unter Umständen den Prozeßwechsel. Öffnet sich nämlich ein bildschirmgroßes Fenster, und hat dieses kein Größenfeld, so lassen sich die restlichen Fenster nicht mehr erreichen. Zwar läßt sich ein anderer Prozeß auch über die Menüleiste auswählen (Abbildung 3), aber diese Methode ist meist umständlicher als ein einfacher Mausklick auf ein Fenster.

Bild 3: Doppelt und dreifach

Mein Fenster Dein Fenster

Wer ein wachsames Auge hatte, dem dürfte bei den Vorführungen des MultiTOS auf der CeBIT aufgefallen sein, daß Fensterelemente nun auch dann betätigt werden können, wenn sie nicht Bestandteile des obersten Fensters sind. Dieser Punkt ist für die Funktionalität des TOS ein wichtiger Aspekt, da es äußerst unpraktisch wäre, zunächst ein Fenster anzuklicken (um es zu toppen), dieses zu verschieben oder in der Größe zu verändern, und anschließend durch erneutes Anklicken das ursprünglich aktive Fenster in den Vordergrund zu bringen.

So, wie es im MultiTOS gelöst ist, spielt es für die Bedienung der Fensterelemente keine Rolle, ob es sich beim bewußten Fenster um das Top-Window handelt oder nicht. Und somit kann ich Ihnen nun die Frage stellen: Funktioniert das auch in Ihren Programmen? Sind Sie darauf vorbereitet, im richtigen Fenster zu scrollen, auch wenn dieses gar nicht aktiv ist? Falls Sie diese Fragen verneinen müssen, mag es Sie vielleicht trösten, daß es mir bis zur Messe nicht anders ging. Aber auch hier läßt sich bereits im Vorfeld alles ins Lot bringen. Es kommt lediglich darauf an, grundsätzlich bei jeder AES-Nachricht, die irgendein Fenster betrifft, das Handle zu überprüfen. Zunächst einmal darf man nur auf Nachrichten reagieren, die eigene Fenster betreffen. Ferner muß sichergestellt werden, daß Folgeaktionen sich auf das richtige Fenster beziehen. Es genügt also nicht, beim Eintreffen einer wm_arrowed-Meldung die Daten im obersten Fenster zu scrollen. Zum einen muß dieses Fenster noch lange nicht dem eigenen Programm gehören, und selbst, wenn dem so ist, muß nicht unbedingt das gerade aktive Fenster von der Nachricht des Window-Managers betroffen sein.

Wer Fenster-Nachrichten bereits in der Vergangenheit penibel ausgewertet hat, darf sich nun auf die Schulter klopfen, denn eigentlich hätte man das schon immer so handhaben sollen. Nun muß man es immer tun.

Weil es so schön war, noch einmal

So oder so ähnlich mag mancher Anwender denken und startet sein Lieblingsprogramm gleich mehrmals (Abbildung 3). Möglich ist dies bereits unter MultiGEM sowie bei GEMDOS-orientierten Programmen auch mit MiNT, bei MultiTOS wird es ähnlich aussehen. Hier drängt sich gleich die Frage auf, ob so etwas denn überhaupt sinnvoll ist und ob es gutgehen kann. Inwiefern es Sinn macht, das gleiche Programm mehrfach nebeneinander zu verwenden, hängt in erster Linie von den Aufgaben dieses Programmes und von der Arbeitsweise des Anwenders ab. In jedem Fall hat der Programmierer dafür Sorge zu tragen, daß im Falle des Falles keine Schwierigkeiten auftauchen.

Äußerst kritisch in einem Mehrprozeßsystem dürften nicht-residente Prozesse sein, die irgendwelche Systemvektoren verbiegen. Nach dem Verlassen müssen solche Programme dafür sorgen, daß der alte Zustand wieder hergestellt wird, sie müssen sich also aus der Vektorkette ausklinken. Dies geschieht häufig unter Nutzung des XBRA-Verfahrens [1]. Dieses setzt jedoch voraus, daß jedes Programm, das einen Vektor verbiegt, diesen Mechanismus anwendet. Verfolgt man beim Programmende die Vektorkette bis zur eigenen Kennung und entfernt dann den zugehörigen Vektor, so kann man sich im Multitasking-Betrieb noch lange nicht sicher sein, die richtige XBRA-Strukturerwischt zu haben. Wurde das gleiche Programm mehrmals gestartet, ist die Wahrscheinlichkeit, daß der falsche Vektor manipuliert wird, recht hoch. Ein System-Crash wird die unmittelbare Folge sein.

Um sich in einem solchen Fall halbwegs aus der Affäre zu ziehen, müßte man vor dem Entfernen des Sprungvektors prüfen, ob dieser überhaupt in das eigene Programm zeigt. Wenn nicht, kann es sich nicht um den richtigen Vektor handeln, und die XBRA-Kette muß weiter durchforstet werden. Das Ausklinken aus der Vektorkette ist jedoch nicht der Weisheit letzter Schluß. Die einzig sichere Lösung ist die, einen kleinen Programmteil, der in erster Linie die XBRA-Verzweigung beinhaltet, nach Beendigung des Programms resident im Speicher zu lassen. DieXBRA-Verkettung wird also nicht mehr angetastet. Ein gutes Beispiel für diese Vorgehensweise stellt der Systemmonitor SYS_-MON dar, der nach seiner Deinstallation einen kleinen residenten Teil im Speicher zurückläßt.

Nachdenkliches zum Schluß

Selbstverständlich ist die Thematik der Programmierung unter einem Mutiprozeß-System vielschichtiger, als im Rahmen dieses Artikels beleuchtet werden konnte.

Dennoch hoffe ich, einen Eindruck davon vermittelt zu haben, worauf man bei solchen Systemen prinzipiell achten muß.

Schenkt man den offiziellen Ankündigungen Glauben, wird das neue TOS im Herbst dieses Jahres erscheinen. Bis dahin sollte man seine eigenen Programmen „multitaskingfest“ machen. Es müßte doch eine Herausforderung an jeden Programmierer darstellen, bereits jetzt ein waches Auge auf die kommenden Entwicklungen zu haben. Den Lohn hierfür erntet man spätestens dann, wenn man sich freut, daß die eigenen Programme unter MiNT, MultiTOS und MultiGEM gleichermaßen stabil laufen. Bereits jetzt findet man eine Reihe von Programmen, die völlig problemlos mit Multitasking-Systemen Zusammenarbeiten. Es gibt jedoch auch Software, bei der es bedenklich aussieht. Kurz nach dem offiziellen Erscheinen des TT hatte ich mich mit der Frage beschäftigt, wie man es anstellen muß, zum TT inkompatible Software zu schreiben |3|. Interessanterweise handelt es sich bei vielen Produkten, die besonders schlecht oder gar nicht mit MultiTOS laufen, um die gleichen Programme, die bereits damals unangenehm aufgefallen sind. Verwundert hat mich das eigentlich nicht. Manche Programmiererscheinen halt immer noch nicht aus vergangenen Fehlern gelernt zu haben. (Bleibt anzumerken, daß die bewußten Programme inzwischen auf dem TT laufen.) Da kaum ein Anwender sich sicher sein kann, nicht einmal mit MultiTOS oder ähnlichen Systemen zu arbeiten, sollte man bereits jetzt beim Kauf von Programmen ein Auge auf deren Oberfläche werfen. Software, die keine Fenster unterstützt oder durch selbstgestrickte Oberflächen „glänzt“, wird im Multitasking-Betrieb für großen Ärger sorgen.

Um auch ohne MultiTOS Tests mit eigener Software durchführen zu können, dürften MiNT, MultiGEM und WINX eine große Hilfe darstellen. Woher man diese Programme beziehen kann? MiNT ist als Freeware-Produkt beispielsweise über das Mausnetz oder Internet erhältlich. WINX befindet sich auf der PD 500 der ST-Computer-PD-Sammlung.

MultiGEM wird (als kommerzielles Produkt naturgemäß nicht umsonst) von der MAXON Computer GmbH vertrieben. Und das neue MultiTOS von Atari? Das gibt es hoffentlich möglichst preisgünstig im Herbst.

Literatur:

[1] Jankowski, Rabich, Reschke, „Atari Profibuch ST-STE-TT" SYBEX Verlag

[2] Alexander Herzlinger, „Von Zeichen und Keksen“, ST-Magazin 4/92

[3] „Wie ST-kompatibel ist der TT?“. ST-Computer 10/90


Uwe Seimet
Aus: ST-Computer 06 / 1992, Seite 100

Links

Copyright-Bestimmungen: siehe Über diese Seite