X auf dem Serviertablett: Ein X-Window-Server für den ATARI

Das Thema „Netzwerke“ gewinnt auf dem Computersektor zunehmend an Bedeutung. Waren einst lediglich Rechner größerer Institute miteinander vernetzt, finden heute auch zunehmend Computer in kleineren Betrieben Anschluß zueinander. Vielen privaten Anwendern ist eine Vernetzung über Mailboxen nicht mehr fremd. Eine besonders interessante Form der Netzwerknutzung ist die Einbindung eines Rechners in eine vernetzte Unix-Umgebung. Mit Hilfe geeigneter Soft- und Hardware kann man einen ATARI als grafikfähiges X-Terminal verwenden. Als Software bietet sich der X Window Server von X/Software an.

Die Idee, einen handelsüblichen Computer als X-Terminal einzusetzen, ist bei weitem nicht neu und bei IBM-kompatiblen PCs unter Microsoft Windows nicht ungewöhnlich. ATARIs hingegen werden für diesen Zweck nur selten verwendet. Dabei bieten MegaSTE und TT durch ihren VME-Bus gute Voraussetzungen für den Betrieb im Verbund mit Unix-Workstations, und auch ein normaler ST kann als X-Terminal fungieren. Sind die grundlegenden Hardware-Voraussetzungen gegeben, fehlt lediglich noch die Server-Software. Bild 1 verdeutlicht das Verhältnis zwischen Servern und Clients unter X.

Von VT100 zum X-Terminal

Was verbirgt sich eigentlich hinter einem X-Terminal? Modem-Besitzern ein Begriff ist die Emulation eines VT100-Terminals, wie es die handelsüblichen Terminalprogramme für den ATARI beherrschen. Hier dient der Rechner als Endpunkt für die Kommunikation mit einem anderen Gerät, das indirekt über eine Modemverbindung oder aber direkt per Nullmodemkabel mit dem eigenen Computer verbunden ist. In beiden Fällen geschieht die Kopplung der Rechner über eine serielle Schnittstelle. Eine Verbindung per VT 100 ist weitestgehend unabhängig von der Hardware oder dem Betriebssystem, d.h., es spielt keine Rolle, welcher Rechner mit welchem verknüpft ist. Wichtig ist nur, daß die verwendeten Terminalprogramme eine gemeinsame Kommunikationsbasis besitzen, wie sie durch die VT 100-Norm gewährleistet wird. Ist diese Voraussetzung erfüllt, lassen sich Informationen, die auf der einen Seite auf die Leitung gegeben werden, auf der anderen Seite wiedergewinnen. Dabei werden nicht nur lesbare ASCII-Zeichen, speziell Buchstaben oder Ziffern, übertragen. Auch diverse Steuerfunktionen für das Bildschirm-Handling sind im VT100-Standard definiert. So läßt sich über geeignete Escape-Sequenzen eine bestimmte Bildschirmposition ansteuem oder der Bildschirm löschen.

Standardmäßig eingebaut ist im TOS eine Untermenge des VT100-Standards mit der Bezeichnung VT52. Für einfache Anwendungen ist der VT52-Befehlsumfang ausreichend, allerdings läuft heutzutage die Kommunikation vorwiegend über VT100, VT200 oder neuere Protokolle ab.

Der entscheidende Unterschied zwischen VT- und X-Terminals besteht nun darin, daß es sich bei den VT-Protokollen um vorwiegend zeichenorientierte Protokolle handelt. Ein X-Terminal dagegen versteht sich auch auf Grafik.

Bild 1: X Window System - Server und Clients

Das Büro der Zukunft?

Sie sitzen an Ihrem Arbeitsplatz vor einem Bildschirm und arbeiten wie gewohnt mit der Maus unter einer grafischen Benutzeroberfläche. Vom Bildschirm weg führt ein Kabel nicht in den nebenstehenden Computer, sondern verschwindet irgendwo in der Wand. Wo der Rechner steht, der den Bildschirm bedient und mit dem Sie kommunizieren, wissen Sie gar nicht, und es spielt auch keine Rolle. Der Kollege rechts von Ihnen hat einen ähnlichen Arbeitsplatz und die Kollegin links ebenfalls. Für einen Informatikstudenten dürfte ein solches Szenario Alltag sein, denn vernetzte Arbeitsplätze sind keine Seltenheit mehr. Daß man den Eindruck hat, ein kompletter Rechner arbeite für einen allein, rührt lediglich daher, daß eine Multitasking-/Multiuser-Oberfläche dieses Gefühl suggeriert. Man kennt das ja inzwischen von MultiTOS und Mag!X: In einer Multitasking-Umgebung können nahezu beliebig viele Programme gleichzeitig ablaufen. Kann ein Betriebssystem darüber hinaus mehrere User, meist an unterschiedlichen Terminals, gleichzeitig verwalten, spricht man von einer Multiuser-Umgebung.

Als Multiuser-Betriebssystem findet häufig Unix Verwendung, als grafische Oberfläche das auf diesem Sektor weit verbreitete X-Window-System (X11). Und weil Ihr Terminal in der Lage ist, mit diesem System auf grafischer Basis zu kommunizieren, wird es schlichtweg X-Terminal genannt. Solche Terminals, die stets mit Tastatur und Maus ausgestattet sind, stellen also Bildschirmarbeitsplätze dar. die nicht nur mit Zeichen umzugehen wissen, sondern auch Grafiken darstellen und Mauseingaben verarbeiten können.

Mehr als nur Utopie

Im Universitätsbereich wird die geschilderte Arbeitsumgebung immer mehr zur Regel und auch andernorts findet man aufgrund deutlicher Preissenkungen immer mehr vernetzte Unix-Workstations oder auch gemischte (heterogene) Netze mit unterschiedlichen Systemtypen. So sind die Preise für die Einstiegsmodelle diverser Workstations, die in der Regel schon mehr Rechenleistung bieten, als man als Privatmann benötigt, bereits an der magischen Grenze von 10.000,- DM angelangt, inklusive Großmonitor versteht sich. Auch gebrauchte Geräte finden schnell ihre Abnehmer, denn gerade derjenige, der sich mit der Nutzung und Programmierung eines so wichtigen Betriebssystems wie Unix auseinandersetzen will, ist ein dankbarer Abnehmer für eine ausrangierte Workstation. Zu zahlen ist nur ein Bruchteil des Preises, den das Gerät noch vor wenigen Jahren gekostet hat. Das ist nicht weiter erstaunlich, denn wie die Geräte auf dem PC-Sektor veralten auch Workstations in relativ kurzer Zeit. Daß solche Maschinen heutzutage im Gegensatz zu IBM-kompatiblen XTs aus der gleichen Zeit überhaupt noch Abnehmer finden, liegt daran, daß die Rechenleistung aus damaliger Sicht extrem hoch war und daher auch für heutige Bedürfnisse durchaus akzeptabel ist.

Für viele Programmierer auf dem ATARI-Sektor erscheint eine Unix-Workstation unter einem besonders interessanten Licht: MiNT, als Grundlage von MultiTOS, erweitert das Standard-TOS des ATARI um eine Vielzahl von Funktionen, die identisch mit dem sind, was man an Systemaufrufen unter Unix vorfindet. Man kann also von einer gewissen Kompatibilität auf Quelltextebene zwischen MiNT und Unix sprechen, solange man Anwendungen in C nutzen will, die ohne grafische Oberfläche auskommen.

Daten en masse

Sollen nicht nur Text-, sondern auch Grafikinformationen über eine Schnittstelle zwischen Rechner und Terminal ausgetauscht werden, kommt es auf eine schnelle, effektive Datenübertragung an. Diese geschieht in der Regel durch eine Vernetzung auf Ethernet-Ebene. und so ist eine Ethernet-Schnittstelle fester Bestandteil jeder Workstation. Hinzu kommen ein oder zwei serielle Schnittstellen, die für die Ansteuerung eines Druckers, Modems oder eines zusätzlichen VT-Terminals genutzt werden können. Ein paralleler Port ist nicht bei jeder Workstation zu finden.

Die Vernetzung per Ethernet geschieht auf kurzen Strecken über ein Koaxialkabel, wobei der Größe des Netzes zunächst einmal nur durch die Leitungslänge und den mit ihr wachsenden Leitungswiderstand Grenzen gesetzt sind. Daß sich dieses Problem durch zusätzliche Hardware zur Signalverstärkung und -Weiterleitung in den Griff kriegen läßt, liegt auf der Hand. Die Übertragungsraten im Ethernet können sich im Vergleich zur Übertragung über handelsübliche serielle Schnittstellen durchaus sehen lassen. Mehrere 100 KB/s sind die Regel, je nach Netzbelastung. Bei diesen Geschwindigkeiten entsteht keine merkliche Verzögerung, wenn Daten zunächst von der Workstation bis zum Terminal übertragen werden müssen, auf dem sie schließlich dargestellt werden.

Da viele Workstations nicht mit einer Floppy ausgerüstet sind, ist die Vernetzung über die Schnittstellen häufig die einzige Möglichkeit zum Datenaustausch.

Ethernet für jedermann?

Sind Unix-Workstations bereits von Hause aus mit einem Ethernet-Anschluß ausgestattet, ist dies bei anderen Systemen normalerweise nicht der Fall. Für nahezu jeden Rechnertyp existieren daher entsprechende Schnittstellenkarten. So auch für den MegaSTE und TT, wo solche Karten in der Regel für den eingebauten VME-Bus ausgelegt sind. Daß diese Karten überhaupt erhältlich sind, ist die gute Nachricht. Die Kehrseite der Medaille folgt auf dem Fuß. Da nur ein einziger VME-Steckplatz vorhanden ist, schließt eine Ethernet-Karte den Anschluß einer Grafikkarte aus, da diese ebenfalls einen VME-Steckplatz beanspruchen würde. Hier rächt sich wieder einmal das beschränkte Bus-Konzept der ATARI-Geräte. Man wird sich also für eine der beiden Anwendungen entscheiden müssen. Hinzu kommt, daß weder ST noch Falcon einen VME-Bus besitzen und so eine Ethernet-Anbindung bei diesen Modellen nicht ohne weiteres möglich ist. Einen Ausweg bilden Lösungen, bei denen die Schnittstelle über den DMA-Bus realisiert wird. In diesem Fall ist auch eine zusätzliche Grafikkarte für den VME-Bus nutzbar.

Ethernet-Karten für IBM-kompatible PCs gibt es in Hülle und Fülle und bereits zu Preisen unterhalb von 300,- DM. Auf dem ATARI-Sektor sieht es weniger günstig aus. Eine Ethernet-Karte für den VME-Bus kostet je nach Anbieter das Doppelte bis Vierfache. Karten für den DMA-Bus sind noch teurer. Die Ursache für das hohe Preisniveau liegt nicht allein an den niedrigen Stückzahlen, in denen die Karten für den ATARI produziert werden. VME-Karten sind nun einmal teurer als die bei preiswerten PCs verwendeten Karten für den ISA-Bus. Damit eine Vernetzung per Ethernet nicht am Geldbeutel scheitert, empfiehlt sich bei den für den ATARI erhältlichen Karten in jedem Fall ein Preisvergleich. Dabei drängt sich das Gefühl auf, daß so mancher Anbieter kräftig an dieser Technologie verdienen will. Dieser Schuß kann leicht nach hinten losgehen, denn hohe Preise sind natürlich gleichbedeutend mit wenigen Kunden.

Der Spatz in der Hand

Doch wie dem auch sei: Wer an der Uni bereits einen ATARI mit VME-Bus, also MegaSTE oder TT, auf seinem Schreibtisch stehen hat und bei wem außerdem ein Netzwerkanschluß vorhanden ist, das wird damit liebäugeln, mit dem ATARI weltweiten Anschluß zu suchen. Schließlich ist die Aufrüstung mit einer Ethernet-Karte auch im Vergleich mit den niedrigen PC-Preisen immer noch preisgünstiger, als sich einen neuen PC mit Karte zuzulegen oder gar zu einem „richtigen“ X-Terminal in der Preislage von 5.000.- DM zu greifen. Bei einem X-Terminal handelt es sich quasi um einen Bildschirm mit eingebautem Computer. Da sich als X-Terminal besonders gut ein schneller Rechner mit Großmonitor eignet, steht ein TT preislich gar nicht so schlecht da.

Offenbar sind einige Universitäten zur gleichen Schlußfolgerung gelangt, denn auf dem ftp-Server der TU Wien befindet sich frei zugängliche Treiber-Software (TCP/IP), die zur Ansteuerung der Ethernet-Karte von Riebl gedacht ist. Quellen zur Treiberprogrammierung sind in diesem Paket enthalten, so daß sich bei entsprechender Anpassung auch die Biodata-Karte verwenden lassen sollte. Für Bastler ist interessant, daß auch ein Ethernet-Pocket-Adapter unterstützt wird, der über den Centronics- und ROM-Port des ATARI angesteuert werden kann. (Man werfe einen Blick auf den ftp-Server fortec.tuwien.ac.at. oder in die Maus Kaiserslautern, 0631 -17901.) Wer aus dem Umstand, daß trotz der geringen Verbreitung von Ethernet-Karten für den ATARI Software von Fremdanbietern zur Verfügung steht, den Schluß zieht, daß die den Karten beigelegte Software nicht das Gelbe vom Ei sei, hat den Nagel auf den Kopf getroffen. Egal, ob es sich um die TCP-Software zur Riebl- oder Biodata-Karte handelt, die Qualität läßt arg zu wünschen übrig. So zeichnet sich die Software zur Riebl-Karte insbesondere in der Installationsphase durch eine hohe Absturzfreudigkeit aus. Die mitgelieferte telnet- und ftp-Software ist ebenfalls nicht übermäßig stabil. Die Verwendung einer Biodata-Karte im Rahmen dieses Tests war gar nicht erst möglich, da mit der mitgelieferten Treiber-Software keine Anbindung an das Internet möglich war. Auch eine Anfrage bei Biodata brachte keine Abhilfe. Ginge es hier um einen Test der beiden Karten, ließe sich das Ergebnis in puncto tcp-Software leicht zusammenfassen: mangelhaft.

Zur Riebl-Karte läßt sich noch anmerken, daß diese ursprünglich auch von ATARI vertrieben wurde und sich auf dem TT unter dem inzwischen von ATARI nicht mehr unterstützten, aber nichtsdestotrotz real existierenden ATARI-System V Release 4 (ASV) einsetzen läßt.

Grafik statt ASCII

Auch wenn die Erfahrungen zum Thema Ethernet bis hierher recht ernüchternd waren, lassen sich der Vernetzung per Ethernet eine Reihe positiver Seiten abgewinnen. Nur so ist nämlich das Einloggen auf einer Unix-Workstation mit grafischer Oberfläche bei hoher Geschwindigkeit möglich. Der Unterschied im Bedienungskomfort eines VT 100- und eines X-Ter-minals ist nun einmal gewaltig, und wer die Wahl hat. wird sich daher stets für das letztgenannte entscheiden.

Es bestand die Wahl, und sie fiel auf den X-Server XATOS/window/server von X/Software Michael Gehret, der bereits seit einiger Zeit erhältlich ist und X11 Release 5, also die aktuelle Version des X-Window-Systems, unterstützt. Die Server-Software läuft auf ST, STE und TT, wobei für den TT gegen Aufpreis eine Version mit Coprozessor- und 68020/68030-Unterstützung erhältlich ist, wie sie auch für diesen Test eingesetzt wurde. Neben zwei Disketten und einem Dongle für den Centronics-Port wird ein Manual mitgeliefert, das mit 20 DIN-A4-Seiten allerdings recht dürftig ausfällt. Nicht zuletzt die knappe Dokumentation trägt dazu bei. daß die Installation des Servers für Otto Normalverbraucher kaum möglich sein dürfte. X/Software hat offenbar völlig übersehen, daß immer mehr Computerlaien an vernetzten Rechnern sitzen. Wer noch keine Erfahrungen mit der Administration eines X-Systems gesammelt hat, wird im Stich gelassen. Weiterhelfen kann natürlich der zuständige Systemverwalter oder aber ein Anruf bei X/Software. Für den fortgeschrittenen X-Anwender gestaltet sich das Editieren der Konfigurationsdateien unkompliziert. da sich die Namensgebung und der Inhalt dieser Dateien an unter Unix und X übliche Konventionen hält, soweit dies auf dem ATARI machbar ist.

Bild 2: Grundlegende Einstellungen im Accessory-Betrieb
Bild 3: XDM meldet sich wie unter X üblich.

Grafik und Fonts

Nach der Server-Installation, die sich auf das Kopieren diverser Dateien und das Editieren von Konfigurationsparametern beschränkt, ist die Festplatte um den eigentlichen X-Server sowie eine Reihe von Zeichensätzen reicher. Diese sind deshalb erforderlich, weil das Terminal vom X-Window-System keine detaillierten Informationen über das Aussehen einzelner Zeichen erhält, sondern die verfügbaren Zeichen als Ganzes abgerufen werden. Hierdurch wird die Datenmenge, die zur Übertragung von Grafikinformationen benötigt wird, möglichst gering gehalten. Anders als bei der rein zeichenorientierten Ansteuerung von VT100-Terminals bringen Grafikdaten ein sehr viel größeres Volumen mit sich, das durch redundante Informationen nicht noch weiter erhöht werden soll. Das ist auch der Grund, warum es kaum möglich ist, X-Terminals sinnvoll über eine serielle Schnittstelle zu realisieren: Der Datendurchsatz wäre hier viel zu gering, als daß sich mit akzeptabler Geschwindigkeit auf grafischer Ebene arbeiten ließe.

Verglichen mit X-Servern für IBM-kompatible PCs, ist die Zahl der mitgelieferten Zeichensätze mit gut 50 zwar recht dürftig, aber im Netzverbund lassen sich zusätzliche Zeichensätze über einen Fontserver laden, wie er ab X11R5 unterstützt wird. Lokale Zeichensätze wird man daher nur in Ausnahmefällen bereithalten. In der Praxis bereitete die Verwendung eines Fontservers in Form einer Sun 3 und einer Sun SparcStation allerdings gewisse Probleme, die nur schwer zu lokalisieren waren. Einige Programme hänglen sich beim Anfordern von Zeichensätzen auf. Beim Einsatz von lokalen Fonts traten dagegen keine Schwierigkeiten auf. Und wo wir gerade bei unerklärlichen Phänomenen sind: Einige wenige X-Anwendungen brachen reproduzierbar die Verbindung zum Server ab, sobald gewisse umfangreiche Grafikoperationen auszuführen waren. Vermutlich ist dies auf einen Fehler im tcp-Treiber der Riebl-Karte zurückzuführen, was sich jedoch nicht definitiv klären ließ, da sich die Biodata-Karte, die für diesen Test zur Verfügung stand, nicht im Netz betreiben ließ.

Die Session beginnt

Es ist endlich soweit, die Verbindungsaufnahme steht an. Zunächst wird die TCP-Treiber-Software gestartet, die dem X-Server als Grundlage für die Kommunikation über die Ethernet-Karte dient.

Nun ruft man das Server-Programm auf, das als Applikation oder Accessory eingesetzt werden kann. Es empfiehlt sich, den Server so zu konfigurieren, daß er sich über das XDMC-Protokoll bei einer oder mehreren Maschinen im Netz meldet und deren Login-Dialog darstellt. In diesem Fall durchläuft man die unter Unix übliche Login-Prozedur, und nach einer kurzen Wartezeit für das Starten des Window-Managers ist man auf der X-Ebene angelangt. Wurde der X-Server auf dem ATARI als Applikation im Vordergrund gestartet, obliegt die gesamte Verwaltung des ATARI-Bildschirms nun dem Server, der die von der Workstation gelieferten Grafikinformationen auf dem ATARI umsetzt. GEM ist in diesem Fullscreen-Modus nicht mehr aktiv. Beim Betrieb als Accessory kann der Server mehrere Bildschirme (Screens) bedienen, die sich jeweils in einem eigenen Fenster befinden, aber auch jeder für sich im Fullscreen-Modus genutzt werden können. Es werden maximal 10 solcher Screens unterstützt, die wechselseitig betrieben werden können, falls nicht genügend Fenster zur Verfügung stehen. Unter WINX können alle Screens gleichzeitig angezeigt werden. Gegenüber dem Fullscreen-Betrieb ist die Darstellung in Fenstern mit Geschwindigkeitseinbußen verbunden, da die Verwaltung von Fenstern naturgemäß einen erhöhten Rechenaufwand für Redraws mit sich bringt. Der X-Server ist in der Lage, Screens zu verwalten, die größer als der physikalische Bildschirm sind. In diesem Fall wird der sichtbare Bildausschnitt automatisch verschoben, sobald die Maus den Bildrand erreicht. Da das X-Window-System erst auf großen Bildschirmen richtig zur Geltung kommt, ist dieses Leistungsmerkmal vor allen Dingen für die Besitzer normal großer Monitore nützlich, da sich hierdurch der Nachteil eines kleinen Monitors teilweise auffangen läßt.

Aus zwei mach drei

Die meisten ATARI-Anwender arbeiten mit einer Zwei-Tasten-Maus, da sich unter GEM nicht mehr als zwei Maustasten ansprechen lassen. Unter X hat jedoch auch die dritte, mittlere Maustaste eine wichtige Bedeutung, insbesondere bei Operationen wie Cut And Paste. Es scheint nicht allgemein bekannt zu sein, daß sich am ATARI gewisse Mäuse mit drei Tasten nicht nur anschließen, sondern auch bedienen lassen. Hierzu ist allerdings Software-Unterstützung erforderlich, die GEM nicht bietet, so daß die Verwendung einer Drei-Tasten-Maus nur bei speziellen Anwendungen Sinn macht.

Die dritte Maustaste erzeugt bei diesen Mäusen ein Signal an einem der Joystick-Eingänge des Maus-Ports. Der X-Server von X/Software erkennt dies, unterstützt also den Einsatz von drei Maustasten. Wer den Server mit einer beim ATARI üblichen Zwei-Tasten-Maus bedienen will, kann die Funktionalität der mittleren Maustaste dadurch nachbilden, daß er beide Maustasten gleichzeitig betätigt. Da diese Art der Mausbedienung ein wenig umständlich ist, wäre es nützlich, die Funktion der mittleren Taste auch über eine der beiden Tasten in Verbindung mit einer Shift-Taste erreichen zu können. Dieses Verfahren wird vom Server leider nicht unterstützt.

In diesem Zusammenhang möchte ich noch einen Hinweis für die vereinzelten Anwender des ATARI-System V loswerden: Der Effekt, daß sich der Mauszeiger der mitgelieferten Drei-Tasten-Maus unter X ab und zu selbständig macht, ist kein Bug in der Unix-Implementation, sondern ein Fehler in der Maus-Hardware. (Im Rahmen dieses Tests wurde die preisgünstige optische Maus GS-6000 von Goldenimage verwendet, die auch unter ASV vorteilhaft genutzt werden kann).

X für ein U

Der Einsatz des X-Servers gestaltet sich im großen und ganzen so, wie man es von einem „richtigen“ X-Terminal gewohnt ist. Bei ausreichendem Speicherausbau (möglichst 4 MByte oder mehr, minimal 2 MByte) läßt sich im Fu11screen-Modus flüssig arbeiten. Durch die Unterstützung des „Backing Store“, bei dem verdeckte Fensterinhalte automatisch gepuffert werden, gehen Redraw-Aktionen zügig vonstatten. X/Software gibt die Leistung des Servers auf dem TT mit 34000 Xstones an, der MegaSTE erreicht 10000 Xstones und ein normaler ST ca. 6000 Xstones. Daß für den Falcon keine Angaben vorliegen hat seinen Grund: Bisher ist keine Ethernet-Anbindung für ATARIs Jüngsten bekannt. Die Aussagekraft von Zahlenwerten mag gering sein, mein subjektiver Eindruck war jedenfalls sehr positiv. Man braucht absolut keine Bedenken zu haben, ein TT sei als X-Terminal zu langsam. Was die benötigte Hardware-Ausstattung betrifft, kann im reinen Server-Betrieb auf eine Festplatte als Peripheriegerät verzichtet werden, was sich positiv auf den Kostenfaktor auswirkt.

Wer sich im Zuge der Zeit etwas mehr in die Multitasking-Richtung bewegen, den ATARI also nicht ausschließlich als X-Terminal oder nur unter GEM betreiben will, wird den X-Server als Accessory einsetzen wollen. In dieser Betriebsart mit mehreren X-Bildschirmen in eigenen Fenstern hat man zwar noch keinen uneingeschränkten Parallelbetrieb von GEM und X-Anwendungen, da Accesories keine eigenständigen Applikationen darstellen, ist aber auf dem besten Wege dorthin. Nach dem Verlassen oder Starten einer Hauptapplikation ist es lediglich notwendig, das Accessory aufzurufen, damit die Fenster des Servers wieder aufgebaut werden können. Diese werden nämlich, wie bei Accessories üblich, beim Start eines neuen Programms geschlossen.

Zukunftsvisionen

Im Sinne einer Weiterentwicklung des X-Window-Servers wäre es wünschenswert, wenn GEM die Aufgabe des Window-Managers übernehmen könnte, ähnlich wie es bei X-Servern auf IBM-kompatiblen PCs Microsoft Windows tun kann. Dann wäre es denkbar, daß von einer X-Applikation geöffnete Fenster durch eigene GEM-Fenster repräsentiert würden. Auf diese Weise ließe sich ein ideales Nebeneinander von GEM und X erreichen, insbesondere unter Mag!X und MultiTOS. Bisher scheiterte diese Idee aber nicht zuletzt daran, daß sich weder die Riebl- noch die Biodata-Treiber-Software unter Mag!X oder MultiTOS installieren ließen. Abhilfe ist allerdings in Sicht, da der X-Server in Zukunft auch die TCP-Software der TU Wien unterstützen soll. Eine Anpassung an den Multitasking-Betrieb sollte dieser Treiber inzwischen hinter sich haben. Dabei wäre es eigentlich Aufgabe von ATARI gewesen, für MultiTOS rechtzeitig Netzwerk-Software für eine Ethernet-Anbindung bereitzustellen. Auf diesem Sektor ist ATARI nahezu hoffnungslos im Hintertreffen, wie auch schon bei der Ethernet-Hardware.

Hinsichtlich eines parallelen Einsatzes von GEM- und X-Anwendungen dart man allerdings nicht übersehen, daß eine reine Anpassung der Treiber-Software und eventuell auch des Servers nur ein Teil des Weges ist. Notwendig wäre ein Clipboardähnlicher Mechanismus, der den Datenaustausch (speziell Texte und Grafiken) zwischen Programmen unter X und GEM erlauben würde. Es müßten dazu neue, dynamische Kommunikationsmöglichkeiten geschaffen werden, wie sie auch unter GEM in Zukunft benötigt werden. Hier gibt es bisher leider nur wenige Ansätze, beispielsweise das Drag & Drop-Protokoll unter MultiTOS [ 1 ].

Der Preis ist heiß

Die Firma X/Software wirbt damit, daß man den ATARI mit ihrer Software wiederbeleben könne. So ganz unrecht mag sie damit nicht haben, allerdings ist es trotz aller Unkenrufe wohl noch etwas verfrüht, einem TT mit Großmonitor nur auf diese Weise einen Nutzen abgewinnen zu wollen. Wer sich privat oder auch im universitären Bereich dem Unix-Sektor widmet und die Möglichkeit zur Vernetzung besitzt, wird dem ATARI durch den Einsatz als X-Terminal ein neues Aufgabenfeld erschließen. Ganz ohne Haken und Ösen geht das jedoch nicht vonstatten, was zum Teil auf Schwächen der den Ethernet-Karten beiliegenden Treiber-Software beruht.

Das größte Hindernis aus der Sicht des Anwenders dürfte der Preis für die Kombination aus Ethernet-Hardware und Server-Software sein, der zwischen 1.500,-DM und 2.000, DM anzusiedeln ist. Lohnenswert ist diese Investition dann, wenn man bereits über einen Teil der benötigten Hardware verfügt, möglichst über einen ATARI mit Großmonitor. Dann nämlich erspart man sich den Kauf eines teuren X-Terminals und hat den Vorteil, daß der ATARI auf Wunsch beides sein kann: PC und X-Terminal.

Literatur:

[1] Julian F. Reschke, "ATARIum - Drag & Drop", ST Computer 10/93

Bezugsquelle:

X/Software Michael Gehret Marktstraße 8 87730 Grönenhach

Preise:

X/TOS/window/server monochrom für ST. STE, TT: 917.10 DM

X/TOS/window/server color für ST, STE, TT: 1147.70 DM

Option 030 (optimiert für 68030): 112,70 DM

X-Server

Positiv:

virtuelle Screens
angenehm hohe Geschwindigkeit
unterstützt X11R5

Negativ:

für ATARI-Verhältnisse hoher Preis
knappe Dokumentation


Uwe Seimet
Aus: ST-Computer 01 / 1994, Seite 50

Links

Copyright-Bestimmungen: siehe Über diese Seite