Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.05.1988 - 

"Touch and feel" nur an der Oberfläche:

Systemwechsel unter Unix - Free-Style nach festen Regeln

Mit massenhaften Raubkopien werden sich die Unix-Werker wohl noch lange nicht rumschlagen müssen. Die fast problemlose Portierung von Anwendungsprogrammen, wie sie bei MS-DOS üblich ist, findet trotz aller Standardisierungsbemühungen nicht statt - da sei X/Open vor. Denn gerade die gepriesene Hardware-Unabhängigkeit macht den Anwender durchaus von der Hardware abhängig.

Die korrekte Bezeichnung von Unix als "Hardware-unabhängiges Betriebssystem" kann zugleich als Postulat aufgefaßt werden. Eine nähere Betrachtung verdeutlicht hier, in welchem Spannungsverhältnis der Wunsch des Anwenders nach leichter Übertragbarkeit seiner Programme zu der Portierbarkeit der Anwendungen an sich steht.

Bei MS-DOS-Maschinen handelt es sich um Systeme, die durch gleichartige Prozessoren nahezu identische Hardwarespezifikationen aufweisen, also durchaus auch als "Clone-to-clones" bezeichnet werden können. Die Bandbreite der Unix-Systeme umfaßt hingegen eine Vielzahl verschiedener Prozessoren und Architekturen.

Die weitgehende Identität der internen Maschinenbefehlssätze - zumindest der Aufsetzpunkte für die Kompatibilität bei MS-DOS-Systemen - führt zu einer fast 99prozentigen Portabilität der Anwendungsprogramme. Das gelte für Unix leider nicht, erläutert Albrecht Bernstein, Mitarbeiter der SCS Technische Systeme und Automation GmbH, Hamburg (siehe hierzu auch seinen Beitrag im CW-Focus Nr. 1 vom 22. 4. 1988).

Im Gegensatz zu anderen Betriebssystemen, wie sie von der Mainframe-Welt her bekannt sind, ist der Unix-Kernel selbst für Systemprogrammierer nicht begehbar, erklärt Heinrich Hofauer, Leiter Systemberatung Unix bei der Bull AG, Köln. Der Verkehr erfolge über Systemaufrufe, die weitgehend homogenisiert seien.

So bietet die Palette der verfügbaren Architekturen, die mit Unix arbeiten, nach außen zwar eine zu gut 95 Prozent gleichartige Oberfläche. Aber nach innen, bei der internen Umsetzung in den Maschinencode, können die Systeme durchaus unterschiedlich sein.

Für das Betriebssystem der 3B-Maschine von AT&T ist die Bezeichnung "Unix" (neben den VAX-Rechnern von Digital Equipment) lizenzrechtlich geschützt. Nach Hofauers Erläuterungen gibt es auf diesem Rechner beispielsweise eine bestimmte maschinenspezifische Eigenheit, die durch Unix mit einem Systemaufruf unterstützt wird. Es bestehe allerdings keine Notwendigkeit, diesen Aufruf auf eine andere Maschine zu übertragen, meint der Experte.

Maschineninterne Umsetzung bleibt Sache der Hersteller

Portierungsprobleme, die heutzutage auftreten, sind in den meisten Fällen auf die Implementierung zurückzuführen, konstatiert Ralph Treitz aus Heidelberg, PR-Koordinator der German Unix User Group (GWG). Als Beispiele aus eigener Erfahrung fährt Treitz nicht nur etliche Schwachstellen bei den Compilern an, sondern verweist auch auf die individuelle Handhabung der Funktionsbereiche und Systemaufrufe, die zu einem früheren Zeitpunkt noch nicht der aktuellen Standardisierung unterlagen.

Die Unix-Kompatibilität besteht also vor allem in einer Quell-Code-Kompatibilität, die zwar durch gleichartige Systemaufrufe charakterisiert ist, aber nichts darüber aussagt, wie diese Befehle maschinenintern umgesetzt werden. Diese Umsetzung bleibt, so Bernstein, dem Hersteller der Hardware überlassen.

Wie der Hamburger Experte verdeutlicht, steht Unix nicht für eine Festschreibung der Hardwarearchitektur, sondern lediglich für die Normierung einer bestimmten Ebene des Betriebssystems. Diese Vereinheitlichung soll letztendlich bei jeder Unix-Maschine zu einer festgelegten Oberfläche mit daraus resultierender identischer Vorgehensweise zum Beispiel im Bereich der Systemaufrufe, führen.

Exakt diese Freiheit der Hersteller, unter einem leistungsfähigen Betriebssystem wie Unix nach innen die Hardware-Architektur voll ausreizen zu können, begründet aber gleichzeitig das Handicap einer möglicherweise stark problembehafteten Portierung von Anwendungsprogrammen.

Bösartige Zungen behaupten, daß die gesamte Unix-Kompatibilitätsdiskussion daher rühre, daß die Hardwarehersteller endlich eine Gelegenheit gefunden hätten, preiswert ein Betriebssystem auf ihre Maschine zu bringen. "Ohne die interne Begeisterung der Hersteller könnten die Anwender ganz schon in die Rohre gucken", meint ein Branchen-lnsider.

Es ist also bei Portierungen in jedem Fall notwendig, einen Übersetzungslauf zu starten - sofern es sich nicht um denselben Prozessortyp handelt. Die Normierung der Oberfläche mache es allerdings möglich, sich in kurzer Zeit an ein anderes Unix-System zu gewöhnen, sagen die Experten. Hält sich der Softwerker dann auch noch an die festgelegten und beschriebenen Unix-Parts und funktioniert der Compiler einwandfrei, dann erfordere die Portierung einen weitaus geringeren Aufwand als bislang üblich.

Probleme des Investitionsschutzes für die Software tauchen bei der Auswahl einer Anfangskonfiguration ebenso wie bei einem eventuell geplanten Herstellerwechsel auf. Schattierungen dieses Betriebssystems sind jedenfalls zuhauf am Markt.

Um die aktuelle Situation in all ihren Ausprägungen zu begreifen, schlägt Bull-Mitarbeiter Hofauer die Aufteilung in echte Portierungen und Look-alikes vor. Die Nachempfindung von Unix-Funktionen wurde zu einer Zeit. als Unix für den Mikrobereich als zu teuer galt, in Form solcher Look-alikes realisiert, die heute jedoch nur noch ein Nischendasein fristen.

Auch die Unix-Derivate haben nahezu ausgedient. "Es ist heute unmöglich, eine Lösung anzubieten, die nicht X/Open-konform auf der Basis des System V lauft", meint Hofauer. Der Schwenk in Richtung System V ist eindeutig auszumachen; die Vielzahl verschiedenster Unix-Derivate mit ihren Aufsplitterungserscheinungen gehört mittlerweile der Vergangenheit an.

"Heute ist alles wieder in einen Mainstream eingeflossen", erläutert der X/Open-Experte des Hauses Bull. Diese Hauptrichtung heiße System-V-Interface-Definition (SVID); es sei jedoch um Zusatzdienste wie die Datenhaltung, SQL-Schnittstellen oder die Empfehlungen für die einzusetzenden Hochsprachen erweitert - so, wie sie durch die Common Application Environment (CAE) von X/Open definiert sind.

Lizenzvorschriften bedingen, daß auch echte Portierungen des Betriebssystems, bei denen zum Beispiel lediglich die englische Dialogausgabe eingedeutscht wurde, einen anderen Namen als "Unix" führen müssen. Look-alikes können also am Namen nicht eindeutig von Portierungen unterschieden werden; intensives Nachfragen nach der Betriebssystembasis ist bei der Auswahl also unabdingbar.

Abgleich der verwendeten Systemaufrufe notwendig

Bei den großen Strömungen vergangener Tage - Berkeley-Version (BSD) und System V - gab es erhebliche Unterschiede, die teilweise tief in die Funktionalität des Kernels hineinreichten. Laut Hofauer verlangt die heutige Situation, daß bei der Portierung einer Applikation eigentlich immer ein Abgleich der verwendeten Systemaufrufe vorgenommen werden muß.

Würden hier größere Differenzen festgestellt, so der Bull-Experte, dann sei grundlegendes System-Know-how ebenso vonnöten wie Kenntnisse der Programmierung im allgemeinen und C-Kenntnisse im speziellen. Dennoch stehe nicht nur ein reichhaltiges Arsenal von Umgehungslösungen zur Verfügung; vielmehr sei es heutzutage möglich, auch exotische Anwendungen mit gutem Willen und relativ geringem Aufwand zu übertragen.

Eine klare Aussage trifft der Kölner Systemspezialist in bezug auf die Auswahlentscheidung, die gerade auch für den kommerziellen Anwender immer bedeutender wird: Die Konzentration auf die inhaltlichen Aspekt einer Problemlösung ist angesagt. Es sei für die Hersteller geradezu eine Herausforderung, dafür Sorge zu tragen, daß sich der Anwender nicht mit Systemproblemen zu befassen habe, fordert Hofauer. Dennoch ist die Auseinandersetzung mit dem System zur Zeit noch unumgänglich.

Hier mehr Klarheit zu schaffen, also die Arbeit mit Unix zu erleichtern, ohne die impliziten Freiheitsgrade einzuschränken, ist Aufgabe der verschiedenen Gremien wie Posix oder X/Open. So enthalten die verschiedenen Papiere derzeit zwar eine interpretationsfreie Beschreibung der verschiedenen Kernel-Dienste - aber nicht der Kommandos. Auf Basis dieser Bausteine werden auch von X/Open Kommandos definiert, die eine eigene Funktionalität und somit ein Normungsbedürfnis besitzen.

Gravierende Unterschiede bereits bei den Shells

Unterschiede zwischen den einzelnen Hardwareherstellern, die Unix anbieten, sieht Hofauer eigentlich nur im jeweiligen Engagement, ein wirklich offenes System bereitstellen zu wollen. Es sei Aufgabe der Zukunft, mächtige und benutzerfreundliche Werkzeuge zur Verfügung zu stellen.

"Die Implementierungen der Hardwarehersteller unterscheiden sich hauptsächlich in der Fülle der Utilities, die mitgeliefert werden," erläutert Jürgen Hertel, Geschäftsführer der Unify Deutschland GmbH, München. Der Kernel sei im großen und ganzen identisch, aber bereits bei den Shells gebe es gravierende Unterschiede. Insbesondere für den kommerziellen Markt, aber auch im Vorgriff auf Window-Implementierungen, seien neue Shells erstellt worden, konstatiert Hertel. Plattencontroller, Treiber, Netzwerkunterstützung und C-Compiler sind weitere Schlagworte der Varianten-Szene.

Auch der GUUG-Mitarbeiter Treitz sieht künftige Unterscheidungsmerkmale der Hersteller eher im Bereich des Unix-Umfeldes als beim angebotenen System selbst. "Die Unterschiede in den einzelnen Unix-Implementierungen sind für den Endanwender letztendlich so minimal, daß er sich voll auf den fachlichen Inhalt einer angebotenen Lösung konzentrieren kann," meint der Unix-Experte. Ist die Entscheidung für Unix allgemein als Multiuser/Multitasking-Betriebssystem gefallen, sei der Hersteller intensiv hinsichtlich seiner technischen und fachlichen Lösungsvorschläge, der Upgrade-Möglichkeiten oder des Supports zu überprüfen.

Fremderstellte Software als einfacher Ausweg

Aber auch hier muß sich der Anwender von dem Gedanken frei machen, daß seine eingeführten Programme beim Systemwechsel ohne weiteres portierbar seien: Die Prozessorwelt, in der er lebt, setzt Grenzen - es sei denn, der zur Portierung notwendige Sourcecode des Anwendungsprogrammes ist vorhanden.

Dann aber ist dank Unix die Portierung recht problemlos, meint Treitz.

Einen Ausweg aus dem Dilemma sieht der PR-Koordinator im Einsatz fremderstellter Software. Aus ökonomischem Interesse bemühten sich die Softwareschmieden, ihre Programme für die Systeme möglichst vieler Hersteller lauffähig zu machen. Treitz: "Hier ist durch Unix ein vollkommen neuer Markt mit eigener Struktur entstanden."

Dieser Markt befasse sich allerdings nicht nur mit der Erstellung von Anwendungssoftware. So haben sich im Laufe der Geschichte einige Unternehmen etabliert, die sich speziell mit Portierungen befassen. Dazu zählt beispielsweise die Unisoft aus Berkeley für die Motorola-Linie. Der Markt wird sich bereinigen meint Hertel; so könne produktionsseitig die Belastung vermieden werden, System-V-Quellen in immer neuen Releases portieren und pflegen zu müssen. Die Entwicklung laufe darauf hinaus, daß Basisboxen inklusive Betriebssystem eingekauft und peripher mit Plattensystemen oder Grafiksubsystemen veredelt werden.

Unterschiedliche Hersteller bedeuten Investitionsschutz

Umgestellt haben sich inzwischen vor allem die Großanwender, weiß Hertel aus seiner Berufspraxis zu berichten. Immer häufiger orientieren sich die User bei der Einführung von Unix an vorhandener Software. respektive sie stellen beim Neukauf die konkrete Frage nach der Portierungsfähigkeit, um ihre Software-lnvestition bei einem Herstellerwechsel zu schützen.

Hardware und anwendungstechnische Basis von dem einen Hersteller, Standardsoftware oder individuelle Programme von einem anderen - dieser Mix bietet sich aus Gründen des Investitionsschutzes nachgerade an, meint Treitz. Dies sei denn auch die klügere Entscheidung für denjenigen Anwender, der das Unix-Postulat der Herstellerunabhängigkeit für sich in Anspruch nehmen wolle.

*Horst-Joachim Hoffmann ist freier Fachjournalist in München.