Trotz deutlicher Schwächen des ersten Releases

Auf stabilem Unterbau ein vielversprechender Nextstep

02.03.1990

Mit der Vorstellung des Next-Rechners am 22. Oktober 1988 wollte Steve Jobs den Rechner der 90er vorstellen. Ob es nur bei dieser Ankündigung bleibt, oder ob das System, das 1988 vorbei an allen anderen Standards entwickelt wurde, in den 90ern zu einem neuen Standard werden kann, versucht dieser Artikel zu klären.

Daß die Software das Sein des Rechners bestimmt und die Hardware nur für die ausreichende Geschwindigkeit sorgen muß - dies ist die Botschaft, die wir mit ins nächste Jahrzehnt nehmen. So sind zwar in der Next-Hardware neue Konzepte enthalten - zum Beispiel eine optische Platte mit 256 MB, ein digitaler Signal Prozessor oder ein 12kanaliger DMA-Kontroller; aber das Entscheidende am Next-Konzept ist die Software. Sie besteht aus zwei Teilen, aus dem Betriebssystem Mach und aus Nextstep, einer grafischen Benutzeroberfläche, die sich aus mehreren Komponenten zusammensetzt.

War die Wahl von Mach 1988 fast eine Sensation - denn bis dahin war Mach nur als Forschungsprojekt der Carnegie-Mellon-Universität und des amerikanischen Verteidigungsministeriums bekannt - muß heute wohl an die Weitsicht des Next-Teams geglaubt werden. Denn die Entscheidung der OSF (Open Software Foundation), Mach als Betriebssystem einzusetzen, wertet nicht nur Next, sondern insbesondere Nextstep auf. Andere Schützenhilfe bekam Next direkt von IBM, denn IBM lizenzierte Nextstep für 10 Millionen Dollar, mit dem Recht, es auf beliebige Plattformen zu portieren. Daß zwischen IBM-Lizenznahmen und der tatsächlichen Umsetzung Welten liegen, weiß jeder. Aber erste Ergebnisse konnten bereits auf der CeBIT '89 gesehen werden, wo IBM ganz offen die damalige Nextstep-Version 8.0 auf einer RT-Workstation zeigte. Eine Woche vor der offiziellen Vorstellung der neuen RTs läßt IBM wissen, daß gleichberechtigt neben Motif, der grafischen Benutzeroberfläche der OSF, Nextstep angeboten wird. Diese Entscheidung von IBM bringt Next einen großen Schritt nach vorne. Was verbirgt sich aber wirklich hinter Nextstep?

Nextstep besteht aus vier Teilen. Der Unterbau ist der Next Window Server mit Displaypostscript als grafischem Kernsystem. Als zweiter Teil kommt das Applikations-Kit, in dem die Benutzerelemente der Oberfläche sowie andere Objekte definiert sind. Der dritte Teil, der nur Entwickler interessierte ist der Interface Builder. Im Interface Builder wird die Benutzeroberfläche sowie die Verbindung zu Objekten definiert. Der vierte Teil ist der Workspace Manager, der direkt mit dem Benutzer in Interaktion tritt. Er versteckt dabei das Unix unter einer grafischen Benutzeroberfläche. Durch den mehrteiligen Aufbau unterscheidet er sich deutlich von den Oberflächen-Konkurrenten Motif und Open Look, den grafischen Benutzeroberflächen von Unix International (UI). Beide basieren auf X-Windows als Window Server - darauf aufgebaut, jeweils die Elemente der Benutzeroberfläche zu definieren.

Weder Motif noch Open Look haben ein gleichwertiges Gegenstück zum Workspace Manager. Beide Organisationen haben zwar angekündigt, sie wollten Unix unter einer grafischen Benutzeroberfläche "verstecken", aber bis auf einige Demonstrationen wurde in dieser Richtung wenig gezeigt. Beim Applikations-Toolkit bieten alle drei Systeme genügend Unterstützung an. Der Unterschied liegt hier jedoch im Systemansatz. Liegt Open Look und Motif ein traditioneller Systementwurf zugrunde, ist Nextstep im Zeichen der Zeit objektorientiert aufgebaut. Bei der traditionellen Gestaltung von Applikationen mit Benutzeroberfäche wird die Oberfläche mit Hilfe eines Resource Editor gestaltet. Dieser generiert eine Include-Datei, die in den Quelltext des Hauptprogramms eingebunden wird.

Zu diesem Hauptprogramm gehören eine Vielzahl von Include-Dateien und Bibliotheken, in denen unter anderem alle Funktionen enthalten sind, um eine Applikation mit grafischer Benutzeroberfläche zu generieren. Daß dies kein leichtes Unterfangen ist, zeigt die Entwicklung in der DOS-Welt, wo nach vier Jahren die ersten Windows-Applikationen zur Verfügung standen. Bis ein Softwareingenieur sich in eine grafische Benutzeroberfläche eingearbeitet hat, vergehen zirka fünf bis neun Monate. Dazu kommt noch der aufwendigere Entwurf für die Implementierung der Applikation.

C + + hat zu viele Inkonsistenzen

Da diese Zeitspanne über einer der kritischen Punkte im Software-Lebenszyklus ist, und da für den Next-Rechner schnell Applikationen am Märkt sein sollten, entschied man sich bei Next für einen objektorientierten Entwurf des Programmier-Toolkits. Da echte objektorientierte Sprechen wie Smalltalk für den Anwender noch eine zu große Hürde darstellen, und C+ + zu viele Inkonsistenzen besitzt, hat man sich bei Next für Objective-C entschieden, das die Sprachkonstrukte von C mit dein Objekt-, Klassen- und Methoden-Konzept von Smalltalk vereinigt, und dessen Sprachänderungen direkt von Smalltalk stammen. Wie sind die einzelnen Stufen von Nextstep aufgebaut, und wo sind die Schwachpunkte im System?

Der Window Server ist eine Hintergrundprozeß, der direkte auf das Betriebssystem Mach aufsetzt. Ein Handikap in den Welt der Standards ist die Inkompatibilität des Next-Window-Server zu X-Windows. Diese Inkompatibilität wird durch eine wesentlich höhere Geschwindigkeit gegenüber X-Windows wieder gutgemacht. Der Next-Window-Server bietet genau wie X-Windows die Möglichkeit, mehrere Benutzer von einem Window-Server ist somit netzwerkfähig. Die Aufgaben des Servers liegen beim Zeichnen und Verwalten von Fenstern sowie in der Rückführung der vom Benutzer zeugten Ereignisse an den Applikationsprozeß. Die Applikationen und das Applikations-Kit arbeiten dein Window Server zu .

Vom Applikations-Kit werden die Benutzerelemente wie Fenster oder Menüs erzeugt, von der Applikation selbst nur die applikationsabhängigen Elemente wie Text oder Grafik. Im Window Server wird als grafisches Kernsystem Display-Postscript-Interpreter generiert daraus das Bild, welches letztendlich auf dem Monitor gezeigt wird. Mit der Entscheidung für Display-Postscript geht Next wieder einen eigenen Weg. Die Frage, ob ein Interpreter ausreichend schnell ist, um die Anforderungen an komplexe Applikationen zu erfüllen, beantwortet vielleicht dieses Beispiel: In einem Vergleich zwischen der Next und der Sun 386i kommt es zu folgenden Ergebnissen: 100 000 Punkte werden in sieben Sekunden gegenüber elf Sekunden auf der Sun 386i initialisiert. Das Zeichnen von 99 999 Linien wird in 111 Sekunden gegenüber 165 Sekunden ausgeführt (Zahlen aus Unixworld 9/89). Viel entscheidender ist jedoch die Tatsache, daß das Darstellungsmodell im Rechner mit dem eines Druckers übereinstimmt, so daß sich die Forderung des Benutzers nach echtem "WYSIWYG" durch die Verwendung von Display-Postscript als grafischem Kernsystem erfüllt. Die Ereignisse, die vom Window Server aufgenommen und weitergeleitet werden, gelangen direkt zum Applikationsprozeß und somit zur eigentlichen Applikation.

Der Kernpunkt von Nextstep ist das Applikations Kit (AK), es ist komplett objektorientiert aufgebaut und in Objective-C geschrieben. Im AK sind alle Ei(..)schaften der Next-Oberflächem zusammengefaßt. Über das AK werden die Knöpfe, Fenster, Menüs, Rollbalken und andere Benutzerelemente in Form von Objekten der eigenen Applikation zur Verfügung gestellt. Erstellt ein Programmierer eine Applikation, braucht er nur die Elemente aus dem AK zusammenzufügen. Die Objekte, wie zum Beispiel der Knopf, sorgen dann selbständig für die gewünschte Kette von Ereignissen: Wird der Mauszeiger auf das Objekt geführt und die Maustaste gedrückt, so wird das Ereignis ausgelöst. Der Knopf wird, solange die Maustaste gedrückt ist, heller dargestellt, und letztendlich bekommt die Applikation mitgeteilt, weicher Knopf gedrückt wurde.

Das Applikations-Kit stellt neben den Benutzerobjekten auch andere Objekte für den Interprozeß Kommunikation, für das Handling der Zwischenablage und der Speicherklassen zur Verfügung. Die Eigenschaften der Objekte können ganz dem objektorientierten Konzept "vererbt" oder überschrieben werden. Neben dem Applikations-Kit stehen dem Anwender noch weitere Kits für audiovisuelle Anwendungen sowie für die Ansteuerung des Digitalen Signal Prozessors zur Verfügung. Unmittelbar mit dem objektorientierten Design ist der Interface Builder verbunden. Im Interface Builder wird, ähnlich dem Resource Editor, das gesamte Aussehen einer Applikation festgelegt. Das Besondere daran ist nun, daß die Benutzerelemente direkt mit dem AK verbunden werden. Durch einfaches Anklicken der Elemente und Verbinden mit den Klassen werden die Aktions-Methoden definiert, die durch Benutzerklick ausgelöst werden und dem Objekt mitteilen, wie es auf das Ereignis zu reagieren hat.

Benutzerelemente direkt mit dem AK verbunden

Neben den Aktions-Methoden gibt es sogenannte Outlets. Bei diesen handelt es sich um Methoden, über die Klassen mit Objekten kommunizieren können. Die Benutzeroberfläche und die Verbindungen zu den Klassen werden in sogenannten Nib-Dateien gespeichert. Ist das Design abgeschlossen, kann die Benutzeroberfläche in einem speziellen Modus auf Unstimmigkeiten oder Funktionalität getestet werden. Bis zu diesem Zeitpunkt ist noch keine einzige Zeile Quelltext geschrieben worden. Aber das Programm öffnet bereits die Menüleiste, Fenster lassen sich verschieben, schließen oder Öffnen, Selbst im Texteditor erscheint jedes eigegebene Wort, das sich sogar kopieren oder einfügen läßt. Ebenso wird bei Anwahl des Schriftendialoges der Dialog geöffnet, und im Text kann Schriftart und Stil verändert werden.

Eigene Objekte direkt im Interface Builder

Erst durch "Anparsen" der neuen Klassen entstehen Quelltext-Dateien, die automatisch in den Projekt Manager des Interface Builder eingetragen werden. Der Interface Builder erzeugt eine Header- und eine Klassen-Datei.

In der Header-Datei stehen die Definitionen der Methoden der "angeparsten" Klasse, in der Klassendatei der Quelltext der Methoden, beziehungsweise der Rahmen für die zu schreibenden Methoden.

Benutzerfreundlich wird es, wenn in bestehende Klassen neue Methoden hinzugefügt werden; dann muß die Header-Datei durch den Parser laufen, um die bestehende Nib-Datei zu aktualisieren. Drückt man aus Versehen "Unparsen", so werden bestehende Klassendateien überschrieben.

In der Projektdatei zur Applikation können sämtliche die Applikation betreffenden Dateien hinzugeführt werden, ebenso Informationen für den Workspace Manager. Neben den bestehenden Objekten View, Fenster und Menü für das Gestalten der Benutzeroberfläche können eigene hinzugeführt werden.

So können häufig benutzte, eigene Objekte direkt in den Interface Builder eingebunden werden und stehen so allen Programmierern eines Teams zu Verfügung. Vom Interface Builder wird eine Make-Datei angelegt, und der Compiler kann direkt aufgerufen werden. Viele Dinge im Interface Builder sind richtungsweisend, jedoch fehlt es in der aktuellen Version 1.0 am letzten Rundschliff, was zur Zeit nur durch aufmerksamstes Lesen der Handbücher auszubügeln ist.

Auf der obersten Stufe von Nextstep steht der Workspace Manager. Jeder Anwender kommt automatisch nach dem Einloggen zum Workspace Manager. Er hat die Aufgabe, die Dokumente oder Ordner grafisch darzustellen, Dokumente zu kopieren, zu löschen, umzubenennen, Ordner anzulegen, zu kopieren oder zu verschieben etc., also alle Funktionen zur Verfügung zu stellen, die ein System zur Verwaltung benötigt. Das Besondere hieran ist, daß unter dem Workspace Manager nicht ein angepaßtes Betriebssystem liegt, wie beim Apple Macintosh, sondern Unix. Dem Workspace fällt es zu, aus dem Unix-Dateisystem eine brauchbare grafische Benutzeroberfläche zu basteln. Und dies erfüllt er - wie die Konkurrenten bestätigen sehr gut. Die Benutzerelemente des Workspace Manager beinhalten alles, was für die Verwaltung von Files benötigt wird. Vom Workspace Manager werden die Applikationen gestartet oder kehren dorthin zurück; dem Anwender wird jeder Kontakt mit Unix verweigert. Erst durch Shell- und Terminal-Applikationen wird der Blick zum Unix frei. Der Workspace Manager beinhaltet eine Vielzahl neuer Benutzerelemente, wie zum Beispiel die Browser-Darstellung oder das Docken von Applikationen, die aber in ihrer Fülle diesen Artikel sprengen würden.

Nextstep läßt sich wohl kaum mit den Konkurrenten Motif und Open Look vergleichen. Denn Nextstep besteht aus einem kompletten System, vom Darstellungsmodell bis hin zur grafischen Benutzeroberfläche für die Dateiverwaltung. Durch dieses paßgenaue Zusammenspiel ist Nextstep den anderen überlegen.

Ein anderer wichtiger Punkt ist die Portierbarkeit von Nextstep. Die Benutzeroberfläche stellt keine besonderen Anforderungen an das Betriebssystem, so daß Hersteller - IBM ist der Beweis - Nextstep schnell auf andere Systeme portieren konnten. Laut Next soll sogar eine Nextstep-Version OS/ 2 bereits fertig sein, welche der Anwender wohl nie zu sehen bekommt. Ein viel wichtigerer Entscheidungsgrund für Nextstep ist seine komplette Objektorientierung. Hat sich der Programmierer erst einmal in das Konzept eingearbeitet, steht ihm ein mächtiges Werkzeug zur Verfügung.

IBM-Entscheidung: Nextstep auf RTs

Durch dieses Konzept sind zwar auf der einen Seite schnell mächtige Standardapplikationen zu erstellen, aber wenn es um besondere Details geht, muß der Programmierer mit dem gleichen Aufwand rechnen wie in traditionellen Programmierumgebungen. Durch die IBM-Entscheidung, Nextstep auf den RTs anzubieten, Quelltext-Kompatibilität zwischen den Nextstep-Portierungen ist eine neue mächtige systemübergreifende Programmierumgebung entstanden. Das läßt ahnen, daß die Softwarehersteller, die frühzeitig auf Next gesetzt haben, eher die Ernte einfahren, als sie ged(..) hätten.

Nextstep ist von der Idee her konsequent und abgerundet, nur an einigen Stellen merkt man deutlich daß es sich hierbei um das erste Release handelt. Zumindest der Unterbau ist da, und die Zukunftsaussichten sind vielversprechender als bei Konkurrenten.