MÜNCHEN (CW) - Obwohl das systemunabhängige Betriebssystem Unix auch bei EDV-Herstellern und -Anwendern größere Verbreitung findet, steht dem endgültigen Durchbruch dieser Systemsoftware ein großes Hindernis im Weg: Es fehlt an der Vereinheitlichung. Branchenexperten fragen, wie Unix Standard sein kann, wenn es nicht eine einzige Standardversion von Unix gäbe. Ein neuer Ansatz könnte jetzt vielleicht die Wende bringen.
Im Juni diesen Jahres wurde nach Meldung der COMPUTERWORLD die erste herstellerunabhängige Konvention für auf Unix basierende Betriebssysteme und Unix-Devirate veröffentlicht. Initiator dieser Aktion war die /usr/group, eine Vereinigung verschiedener UNIX-Anwender in den USA. Angefangen hatte alles im Sommer 1981, als die Gruppe ein Komitee aus der Taufe hob, das die notwendigen Schritte unternehmen sollte, um einen herstellerunabhängigen Unix- Standard zu entwickeln.
In dieses Komitee wurden Vertreter der wichtigsten Hard- und Softwarehersteller, die sich mit Unix beschäftigen, gerufen. Die /usr/group versuchte so, die wichtigsten Interessen unter einen Hut zu bekommen. Auch AT&T nahm, vertreten durch die Bell Labs, an den Vorarbeiten teil.
Herstellerunabhängigkeit immer dringlicher
Die Notwendigkeit, einen herstellerunabhängigen Standard für Unix zu entwerfen, wurde in letzter Zeit immer dringlicher, als sich die wachsende Bedeutung dieses Systems für die 16- und 32-Bit-Rechner zunehmend herauskristallisierte. Denn während sich die Standards für 8-Bit- und 16-Bit-Mikros CP/M und MS-DOS durch die aggressive Marktpolitik der jeweiligen Hersteller Digital Research und Microsoft auf dem Markt durchsetzten, liegt der Fall bei AT&T und Unix anders. Das Unternehmen trat bisher mehr als Technologieanbieter und Lizenzgeber von Unix, denn als Software- Supplier auf dem Markt in Erscheinung. Bestes Beispiel hierfür ist wohl die Inkompatibilität der verschiedenen UNIX-Versionen bei AT&T selbst.
Standardisierung nützt allen
Deshalb, so meinen die Experten, kann eine erfolgreiche Standardisierung von Unix nur über den herstellerunabhängigen Weg wie es jetzt die /usr/group versucht, durchgeführt werden. Damit würden Betriebssysteme, die dieser Konvention entsprechen, egal ob UNIX-Derivate oder unabhängige Neuentwicklungen, ein hohes Maß an Softwareportabilität gewährleisten.
Profitieren würde jeder im Unix-Markt Beteiligte. Die Hardwarehersteller wären der Qual der Wahl enthoben, sich für eine der vielen Versionen der Software zu entscheiden. Die Softwareentwickler hätten einen vorgegebenen Rahmen, um Portable Anwendungsprogramme zu schreiben. Dem Anwender schließlich öffnete sich ein großer Markt an Softwarepaketen, unter denen er das für ihn Beste auswählen und ohne Hardwareänderung einsetzen könnte.
Doch mit den Standards ist das so eine Sache: Das Hauptproblem ist nämlich festzulegen, was es zu standardisieren gibt. Und je komplexer das Produkt, desto schwieriger gestaltet sich dieser Prozeß.
Eine charakteristische UNIX-Implementierung umfaßt mehr als 200 Kommandos und Dienstprogramme; der Objektcode hat einen Umfang von acht bis zehn Megabyte. Das Ziel der Normierungsbemühungen, die Portabilität von Anwendungsprogrammen, wird jedoch in erster Linie durch die Standardisierung von zwei relativ kleinen Teilen des Betriebssystems erreicht, der Unix-Systemaufrufe und der C-Sprachbibliotheken (Abbildung 1).
Die Systemaufrufe stellen die fundamentale Schnittstelle zwischen den Anwendungsprogrammen und dem Betriebssystemkern (kernel) dar, die der Programmierer ständig benutzt. Der Standard definiert nun 39 dieser Calls und gibt Unix damit eine "saubere" Schnittstelle zwischen der Anwendungssoftware und dem BS. Im Unterschied hierzu sprechen beispielsweise beliebte MS-DOS-Anwendungen wie 1-2-3 von Lotus oder Wordstar von Micropro oft interne Routinen direkt an. Dadurch entsteht eine Abhängigkeit von der inneren Struktur der Systemsoftware, die vermieden werden soll.
Die verschiedenen Kernels realisieren die Speicherverwaltung auf unterschiedliche Weise. Dennoch können sie vollkommen kompatibel zum Standard sein. Die UNIX-Anwendungen ihrerseits kommunizieren mit dem Kernel nur über die definierten Aufrufe, laufen also isoliert ab, das bedeutet, unabhängig von der internen Arbeitsweise des Systems. Dadurch erhöht sich die Portabilität von Unix, denn der Hardwarehersteller übernimmt jetzt einfach den zu seinen Maschinen passenden Kern.
Die zweite Schnittstelle, mit der sich der Standard befaßt, ist die Sprachbibliothek, eine Sammlung von Dienstprogrammen, die der Softwareentwickler häufig benötigt (wie Arithmatik-Funktionen, Routinen für die I/O-Formatierung und Datenverschlüsselung, Sortieralgorithmen und vieles mehr). Anwendungen, die auf diesen Routinen basieren, laufen unter jedem Betriebssystem, das dem Standard entspricht, garantiert ordnungsgemäß.
Die Normierung schließt jedoch weder eine Definition einer Unix-Benutzerschnittstelle ein, noch befaßt er sich bis heute mit den Utilities und den Kommandos, da diese Systemkomponenten in den einzelnen Versionen und Derivaten viel stärker variieren wie die Systemaufrufe und die Sprachbibliotheken. Und was noch viel schwerer wiegt - sie tendieren stark zur Anwendungsabhängigkeit und geben deshalb schlechte Kandidaten für die Standardisierung ab.
Flexibilität gehört zu den Stärken
Als exzellentes Beispiel zur Illustration dieser Problematik ist der Kommando-Interpreter von Unix, die Shell anzusehen. Obwohl die AT&T Bourne Shell heutzutage zu den Benutzerschnittstellen zählt, die die weiteste Verbreitung fanden, favorisieren die Softwaredesigner in vielen Fällen die von der University of California in Berkeley entwickelte CShell. Schlüsselfertige Installationen ersetzen diese Schale vollständig durch ein anwendungsspezifisches, menübetriebenes Programm. Diese Flexibilität gehört zu Unix großen Stärken. Bemühungen, einen einzigen Satz von Kommandos oder ein einziges Userinterface zu entwickeln, das zu allen Anwendungen paßt, zielen daher sehr wahrscheinlich in eine falsche Richtung.
Obwohl der /usr/group-Standard unabhängig von speziellen UNIX-Versionen oder Hardwareinstallationen ist, basiert sein Inhalt sehr stark auf dem System m von AT&T. Ein System kann den dort festgelegten Konventionen voll entsprechen und dennoch keine einzige Zeile von Unix" enthalten. Es existieren bereits einige solcher "Look-alikes".
Konventionen - aber keine Zeile Unix
Der Standard unterstützt die wichtigsten Charakteristika, die Unix so beliebt werden ließen:
- Multiprogramming: mehrere Prozesse können nebeneinander ausgeführt werden;
- Mehrbenutzerfähigkeit: individuelle Benutzer des Systems werden eindeutig identifiziert und wahlweise Benutzergruppen zugeordnet;
- Sicherheit: aufgrund der Organisation in Benutzergruppen kann der Dateizugriff kontrolliert werden;
- Hierarchisches File-System: zur Dateiorganisation setzt Unix eine hierarchische Verzeichnisstruktur ein;
- Pipes: bezeichnet den berühmten Unix-Mechanismus, zwei Befehle miteinander zu verbinden (Prozeßkommunikation); dabei werden die Resultate des ersten Befehls dem nächsten Kommando zugeführt.
Details nicht spezifiziert
Die Differenzen zwischen dem Standard und den am häufigsten eingesetzten Unix-Versionen und -Derivaten entstehen meist aus Hardwareabhängigkeiten oder aus Inkonsistenzen unter den verschiedenen Ausführungen. Die Details der Terminal-I/O-Kontrolle beispielsweise spezifiziert der Standard nicht, obwohl der diese Funktionen ausführende Systemaufruf definiert ist. Variationen unter den Versionen bei Halb- und Vollduplex-Operationen und ähnlich niedrig angesiedelter Terminalfunktionen machen eine Standardisierung auf dieser Ebene unmöglich.
Daß eine Übereinkunft über eine einheitliche Methode des File-Lockings getroffen werden konnte, zählt zu den wichtigsten Errungenschaften der Arbeitsgemeinschaft. Der Standard spezifiziert einen Systemabruf für das Sperren von Sätzen gemeinsam benutzter Dateien, um den Mehrfachzugriff zu koordinieren. Obwohl schon seit langem als dringend erforderlich eingestuft, bietet bis heute keine einzige offizielle UNIX-Version von AT&T diese Fähigkeit. Fast alle kommerziellen Unix-Anbieter fügen sie jedoch ihren Implementierungen hinzu. Die Normierung dieser "quasi-standardisierten" Erweiterung verleiht ihr nun endlich einen offiziellen Status.
Der Standard ist ebenso in hohem Grad kompatibel zu System V, das zuletzt im Zusammenhang mit AT&Ts Einzug in das Computergeschäft im Zentrum ausgedehnter Werbefeldzüge stand. Die einzigen Merkmale des Newcomers, so COMPUTERWORLD, die im Standard keine Berücksichtigung fanden, sind Shared Memory und Interprozesskommunikation. Sie stießen bisher auf keine bemerkenswerte Akzeptanz unter den Softwareentwicklern, eignen sich aber sehr wahrscheinlich für zukünftige Erweiterungen des Standards.