Einführung in das Betriebssystem BeOS 5

- "interacting application" services -

 

Ebenso wichtig wie eine gute Auslastung der CPUs ist die Möglichkeit, effizient Daten zwischen Threads und Applikationen hin und her zu schicken. Im BeOS läuft praktisch die gesamte Kommunikation über sogenannte BMessages. Jeder Mausklick und Tastendruck, jedes Update, die Auswahl eines Menüs, eines Radio-Button oder einfach nur ein `Zeit-Puls´ erzeugt schlichtweg BMessages. Das Messaging-System arbeitet auf einer der untersten Ebenen und ist sehr effizient programmiert. Eine BMessage repräsentiert eine strukturierte Nachricht eines Thread an einen anderen. Die Nachricht ist in Felder verschiedenen Datentyps unterteilt. Jede BMessage enthält mindestens ein what-Feld, das Auskunft über die Art der Mitteilung gibt.

Auch hier nimmt das OS dem Programmierer wieder viel Mühe ab. Die gängigsten Nachrichten fängt der BLooper bereits ab und ruft dafür vorgesehene Hook Functions auf (z. B sted(), MessageDropped(), RefsReceived(), Draw(), FrameMoved(), MouseDown() etc.). Der Programmierer muß sich also nur um seine eigenen Messages kümmern. Die System-Messages kann er einfach durch Reimplementieren der Hook Functions erledigen - oder ignorieren, falls er die entsprechende Art Nachricht nicht verarbeiten will. Dann springen die Originalfunktionen des BeOS ein.

Darüber hinaus enthalten viele BMessages weitere Informationen, wie etwa ein long oder double oder ein Rechteck, einen Punkt, eine Record-ID, einen RTF-Text, eine RGB-Farbe oder ein TIFF-Bild. Ein Feld repräsentiert sich durch seinen Namen und seinen Typ. Es können auch mehrere Felder desselben Namens und Typs in einer BMessage enthalten sein, diese unterscheidet dann ein Index. Felder werden bequem mittels der Funktionenfamilien Add... und Find... hinzugefügt und gelesen (siehe Beispiellisting) Eine BMessage kann innerhalb des eigenen `Teams´ (als Team bezeichnet man alle Threads, die sich denselben Adreßraum teilen) oder über einen BMessenger an ein fremdes Team geschickt werden. Der Empfänger kann auf die BMessage direkt mittels Reply() antworten, da die Identität des Senders fester Bestandteil einer Nachricht ist. Darüber hinaus kann ein Thread auf niedrigerem Niveau Daten einem oder mehreren anderen Threads über einen Port zugänglich machen oder selbige von einem Port beziehen. Auf noch niedrigerer Ebene kann man einem ganz speziellen Thread, dessen Name oder thread_id bekannt ist, Daten senden. Beide Low-Level-Nachrichten werden wie BMessage durch ein ulong spezifiziert, bestehen sonst aber lediglich aus einem unstrukturierten Datenblock und der thread_id des Senders. Schließlich und endlich besteht noch die Möglichkeit, ganze Speicherblöcke (Areas) in den Adreßraum eines anderen Teams zu mappen, um diesem die Daten zugänglich zu machen.

Herzstück einer jeden Applikation ist die BApplication-Klasse. Sie stellt die Verbindung zum BeOS her, durchläuft ständig eine Message-Loop und ist daher der `Ansprechpartner´ für alle Dinge, die das gesamte Team betreffen. Vom Application-Objekt werden schließlich alle restlichen Objekte erzeugt, die während der Laufzeit auftreten. Einige der wichtigsten Interface-Klassen sind BWindow und BView (beide wie BApplication von der gemeinsamen Basisklasse BLooper abgeleitet). Ein- und Ausgabe, kurzum die gesamte Interaktion mit dem Benutzer, läuft über BWindow und BView-Objekte. Andere Klassen leiten sich wiederum von BWindow und BView ab, zum Beispiel BAlert und BTextView.