Dieses Handbuch wird mit freundlicher Genehmigung von Sebastian Hetze auf den Servern der Linux Information Systems AG gehosted.

next up previous contents index
Next: Datenreisen und reisende Daten Up: Fremde Welten Previous: Wine

Subsections


Der iBCS2-Emulator

     Linux ist auf Quelltextebene zu 99% kompatibel zu seinem Vorbild, dem System V Unix. Leider bieten die meisten Hersteller professioneller Unix-Software ihre Produkte noch immer nicht für Linux an. Deshalb ist mit dem iBCS2-Emulator die Möglichkeit geschaffen worden, professionelle Software von anderen PC-Unixen direkt unter Linux anzuwenden.

Die Idee, ausführbare Programme zwischen den verschiedenen PC-Unix-Derivaten auszutauschen, ist nicht neu. Die Grundlage für die systemübergreifende Verwendbarkeit der Software bilden zwei standardisierte Binärformate (COFF für SVR3 und ELF für SVR4) sowie die ``Intel Binary Compatibility Specification 2'', kurz iBCS2.

Leider hat die iBCS2-Spezifikation einige Mängel, und die Hersteller von PC-Unixen sind verschiedene Wege gegangen, um diese Mängel für ihre eigene Betriebssystemversion zu beheben. Dadurch ist das Ziel einer vollständigen Binärkompatibilität knapp verfehlt worden. Indem der Linux-iBCS2-Emulator die eine oder andere Variante, die ``personality'', einiger iBCS2-Implementationen nachvollzieht, können Binärdateien mehrerer Unix-Versionen unter Linux eingesetzt werden. Namentlich sind das SCO, System V Release 4, einfache System V Release 3 Programme sowie die speziellen Versionen für ISC, Wyse V/386 und Xenix V/386. Mit kleinen Veränderungen am Kernel können auch Binärdateien der freien BSD-Unixe genutzt werden. Das Hauptgewicht der Entwicklung liegt auf Wyse, SCO und SVR4.

Wie Sie iBCS2 bekommen und installieren können

  Die Binärkompatibilität zu System V Unix muß durch Kernelfunktionen hergestellt werden. Die zum Laden der Binärdateien im COFF- und ELF-Format verantwortlichen Funktionen sind in jedem Linux-Kernel enthalten. Der Rest, der eigentliche iBCS2-Emulator, wird als Laufzeitmodul in den Kernel eingefügt.

Das Modul muß für jede Kernelversion passend erzeugt werden. Damit das funktioniert, müssen Sie die Sourcen zu Ihrem Kernel installiert haben[*] und die Quelltexte vom iBCS2-Modul compilieren. Nur für einige der älteren Kernelversionen (1.0 und frühere als 1.1.15) sind Patches am Kernelcode und die neue Übersetzung des Kernels notwendig.

Die aktuellen Sourcen vom iBCS2-Emulator finden Sie auf tsx-11.mit.edu im Verzeichnis /pub/linux/ALPHA/ibcs2 und auf jedem FTP-Server, der dieses Verzeichnis spiegelt.

Sie können die Sourcen an jedem beliebigen Ort auspacken. Wenn Sie das bereits existierende Verzeichnis /usr/src/linux/ibcs2 benutzen, wird das Modul bei jeder Kernelübersetzung automatisch miterzeugt.

Das iBCS2-Laufzeitmodul wird manuell erzeugt, indem in dem gerade ausgepackten Verzeichnis ./ibcs2/ das make-Kommando aufgerufen wird.

Das fertige Modul heißt iBCS und wird mit dem insmod-Kommando in den laufenden Kernel eingebunden.

Wie bei jedem Quelltextpaket finden Sie die wichtigen Informationen zum aktuellen Paket im README. Zusätzlich gibt es HINTS zur Installation von Software für den Emulator.

Shared Libraries

    Dynamisch gelinkte Programme sind keine Erfindung der Linux-Entwickler. Auch unter System V Release 3 und 4 gibt es Shared Libraries. Natürlich sind die Bibliotheken für Linux und die Unix-Varianten unterschiedlich. Wenn Sie dynamisch gelinkte Programme verwenden wollen, müssen Sie die passenden Bibliotheken bereitstellen.

SVR3/COFF

 

Weil die Schnittstelle zwischen der Bibliothek und dem Kernel für SVR3 in der iBCS2 definiert ist, können Sie beispielsweise die Shared Libraries von SCO im Verzeichnis /shlib unter Linux installieren, wenn Ihre Lizenz das erlaubt. Ein Satz freier Bibliotheken für SCO, die auf der freien GNU Library basieren, wird hoffentlich bald fertiggestellt.

Zwei Libraries, die libnsl und die libX11_s, wird es nicht für Linux geben. In der Bibliothek libnsl sind spezielle Netzwerkfunktionen enthalten, die mit den von Linux (noch) nicht unterstützten Streams arbeiten. Glücklicherweise benutzen die SCO-Programme auf Sockets basierende Gerätedateien für die Netzwerkzugriffe und können deshalb auch ohne diese Bibliothek unter Linux eingesetzt werden.

SVR4/ELF

 

Für SVR4 sind freie Shared Libraries erhältlich. Sie finden die Sourcen und fertig übersetzte Pakete dort, wo es den iBCS2-Emulator gibt. Die Bibliotheken werden normalerweise im Verzeichnis /usr/lib oder in /lib installiert. Sie können dem dynamischen Linker ld.so.1 einen anderen Suchpfad in der Umgebungsvariablen LD_LIBRARY_PATH angeben.

Bezüglich der Netzfunktionen gelten die gleichen Beschränkungen wie für SVR3. Dynamisch gelinkte Programme, die das X Window System benutzen, benötigen Shared Libraries, die Sie aus den entsprechenden XFree86-Distributionen für die SVR4-Unixe erhalten.

Gerätedateien

Der iBCS2-Emulator stellt den Anwendungen zwei Gerätetreiber zur Verfügung, mit denen bestimmte Funktionen angesprochen werden können. Es sind Bestrebungen im Gange, die Alloziierung der Hauptgerätenummern für Laufzeitmodule dynamisch zu machen. Zur Zeit müssen Sie die Gerätedateien noch mit den hier angegebenen Gerätenummern erzeugen.

# mknod /dev/socksys c 30 0
# ln -s /dev/socksys /dev/nfsd
# ln -s /dev/null /dev/X0R
# mknod /dev/spx c 30 1
# _

Die Netzwerkfunktionen von SVR3, die über die Dateien /dev/socksys und /dev/nfsd angesprochen werden, können vom iBCS2-Emulator bedient werden, obwohl Linux Streams nicht unterstützt.

Für Verbindungen zum X-Server erwarten die SVR3-Programme die Dateien /dev/X0R (das Zeichen zwischen X und R ist eine Null) und /dev/spx. Der iBCS2-Emulator umgeht die eigentliche Funktionalität dieser Gerätetreiber, indem er eine feste Verbindung von /dev/spx zum lokalen X-Server herstellt.

Programme installieren

Auch wenn die Binärdateien prinzipiell unter Linux ausführbar sind, kann es bei der Installation eines kommerziellen Programmes, beispielsweise für SCO Unix, zu Schwierigkeiten kommen. Zur Zeit lassen sich nur solche Programme problemlos unter Linux installieren, die ohne spezielles Installationsprogramm auskommen oder mit eigenen Installationsprogrammen geliefert werden. Unter Linux gibt es noch kein mit custom vergleichbares Programm.

Die Installationsdisketten der kommerziellen Programme sind häufig ohne ein Dateisystem einfach mit tar beschrieben. Wenn das GNU-tar das Format nicht erkennt, versuchen Sie es mit dem Schalter -i, damit tar die leere erste Spur der Diskette ignoriert.

Als Installationsprogramme werden sehr häufig Shellscripts eingesetzt. Es gibt kleine Unterschiede zwischen der bash und der sh von System V, die zum Abbruch der Installation führen können. Mit der Kommandozeilenoption -n können Sie die bash veranlassen, ein Shellscript auf Fehler zu testen, ohne es auszuführen.

Wenn Sie das Programm fertig installiert haben, kann es zu weiteren Hindernissen kommen, weil die Programme für PC-Unix die Linux-Console nicht unterstützen. Sie können die Linux-Console auf den PC-Zeichensatz umschalten, indem Sie die Steuersequenz `ESC-(U' eingeben. Zum Linux-Zeichensatz zurück kommen Sie mit `ESC-(B'.

Wenn bei Ihrem Programm Terminfo-Dateien mitgeliefert werden, können Sie versuchen, durch Belegung der Umgebungsvariablen TERM mit sco386, at386, vt100 oder ähnlichen Einstellungen eine befriedigende Bildschirmdarstellung zu erreichen.

Die Linux-Version 1.2 unterstützt weiterhin maximal eine doppelte Belegung der Funktionstasten. Es gibt aber bereits Kernelpatches, die diesen Mangel beheben. Die Belegung der Funktionstasten mit Funktionssequenzen weicht in jedem Fall von der bei SCO benutzten ab. Wenn Sie keine Möglichkeit haben, die entsprechenden Einstellungen für Ihr Programm zu verändern, können Sie auch mit dem Kommando loadkeys eine neue Tastaturtabelle mit geänderten Funktionssequenzen in den Kernel laden.

  


next up previous contents index
Next: Datenreisen und reisende Daten Up: Fremde Welten Previous: Wine

Das Linux Anwenderhandbuch
(C) 1997 LunetIX