Architektur von X

Eine der Besonderheiten von X ist die Netzwerkfähigkeit. X wurde im Gegensatz zu anderen Benutzeroberflächen wie bspw. MS Windows, welche nicht auf einen im Netzwerk befindlichen Rechner getrimmt sind, für den Einsatz im Netzwerk entwickelt.

Damit ist es möglich, Anwendungen auf mehreren Workstations (welche auch unabhängig vom Hersteller und Betriebssystem sind) in einem oder verschiedenen Netzwerk(en) auszuführen - die Ein-/Ausgabe wird dabei von einer einzigen Workstation behandelt.

Damit dies funktioniert, wurde X als eine Client-/Server-Architektur implementiert. Der Server ist dabei für die Ausgabe auf dem Bildschirm und der Verwaltung und Verteilung der Eingaben verantwortlich. Dadurch ist der Server auch von der Hardware des Systems abhängig, da die Verarbeitung der Ein-/Ausgabe auf die Hardware des Systems angepasst sein muss. Der Server hat Kontakt zur Hardware wie dem Bildschirm - aber auch zur Tastatur und Maus. Er ist natürlich maschinenspezifisch geschrieben und teilt zum Beispiel einer Clientanwendung mit, wenn der Benutzer den Mauszeiger in das zur Anwendung gehörende Fenster bewegt hat. Das Programm XF86_SVGA, welches mittlerweile von XFREE86 abgelöst wurde, ist bspw. ein solcher Server für die Grafikkarte.

Auf der Clientseite hingegen werden die Anwendungen wie Büroprogramme, Datenbanken oder Spiele ausgeführt, welche eines oder mehrere Fenster verwenden können. Natürlich gibt es noch ganz spezielle Clients - nämlich den Windowmanager. Vielleicht sind Sie ein wenig überrascht, dass ein Windowmanager wie bspw. mwm (Window Motif Manager), olwm (Open Look Windowmanager) oder gar der KDE- und GNOME-Desktop auch nichts anderes sind als einfache Clients des X11-Servers. Theoretisch können Sie X auch ganz ohne einen Windowmanager ausführen, womit allerdings keine Veränderungen mehr in der Position und Größe des Fensters möglich wären.

Wie auch im Netzwerk, gibt es zwischen dem X-Server und dem X-Client ein Protokoll, mit dem beide kommunizieren, welches schlicht und einfach X-Protokoll genannt wird. Natürlich ist das Protokoll (wie auch beim Netzwerkprotokoll) geräteunabhängig. (Sie sollten die Finger davon lassen, direkt mit dem Server zu kommunizieren.) Die Bibliothek Xlib bietet hierfür unzählige Funktionen für alle Fälle an. Das X-Protokoll definiert dabei verschiedene Päckchen, die mit Informationen gefüllt sind und zwischen dem Serverprogramm und dem Anwendungsprogramm transferiert werden. Es wird dabei zwischen vier Arten von solchen Päckchen unterschieden:

Request (Anfrage) - Protokollaufträge werden von der Xlib erzeugt und zum Server geschickt. Solch eine Anfrage enthält verschiedene Informationen für den Server - wie zum Beispiel eine Anweisung, dass eine Linie gezogen oder die Schriftfarbe verändert werden soll. Bei einigen Requests muss auf eine Antwort vom Server gewartet werden. Solche bezeichnet man als Round-Trip-Request und sollten recht sparsam eingesetzt werden, da diese die Performance erheblich einbremsen. Requests die keine Antwort erwarten, werden als One-Way-Requests bezeichnet.
Reply (Antwort) - Wird dem Server ein Round-Trip-Request gesendet, so muss dieser mit einem Reply antworten.
Events (Ereignisse) - Der X-Server kontrolliert Eingabegeräte wie die Maus, Tastatur usw. auf Aktionen, die der Anwender auf diesen Geräten ausführen kann. Sämtliche Aktionen (Tastendruck, Mausbewegung etc.) werden vom Server registriert und als Event an das Anwendungsprogramm des Clients geschickt. Beim Client werden die Events bei Bedarf in einer Warteschlange abgelegt und der Reihe nach abgearbeitet.
Error (Fehler) - Fehler werden ähnlich wie Events behandelt. Die Xlib unterscheidet dabei zwischen einfach behebbaren und fatalen Fehlern. Dafür stehen wieder eigene Funktionen zur Verfügung.