Sprachprobleme

von Carsten Schnober

Software einzurichten, kann so einfach sein: Den Paket-Manager starten, ein Programm installieren und es anschließend starten. Doch wie entsteht ein ausführbares Programm?

Im Zeitalter grafischer Benutzeroberflächen gestaltet sich die Kommunikation zwischen Mensch und Computer zwar nicht immer problemlos, aber mit komplizierten Kommandos braucht sich ein Desktop-Anwender heutzutage meist nicht mehr herumzuärgern. Die breite Kluft zwischen Maschine und ihrem Besitzer überwinden zahlreiche Hilfsprogramme.

Eine Besonderheit von Linux gegenüber kommerziellen Betriebssystemen stellt die Möglichkeit dar, dass jeder Benutzer den Quelltext einsehen kann. Das trifft auch auf den größten Teil der Anwendungen zu, solange es sich um so genannte Open Source Software (OSS) handelt -- die Quellen liegen offen.

Offene Quellen

Beim Quelltext oder auch Quell-Code handelt es sich um die Darstellung eines Programms, in der es der Programmierer schreibt (Abbildung 1). Unterschiedliche Programmiersprachen geben ihm jeweils einen bestimmten Befehlssatz und die Syntax, also den Satzbau, vor. Jede Programmiersprache versucht dabei, den Spagat zwischen der menschlichen und der Maschinensprache zu bewältigen: Je ähnlicher die Programmiersprache der menschlichen ist, desto leichter fällt es dem Programmierer, sie zu beherrschen. Jedoch muss das fertige Programm schließlich in die Maschinensprache übersetzt werden; das dafür zuständige Hilfsprogramm, der Compiler, ist dabei auf einen streng logischen Aufbau angewiesen.

Abb. 1: Software-Entwickler schreiben Programme in einer Sprache, die der menschlichen wenigstens ähnelt.

Nach dem Kompilieren liegt eine aus dem Quelltext erzeugte ausführbare Programmdatei vor. Diese lässt sich nicht mit gewöhnlichen Programmen wie einem Text-Editor betrachten (Abbildung 2): Sie besteht ausschließlich aus für den Menschen unlesbaren Zeichen. Binärdateien enthalten jedoch nicht immer ausführbare Programme, auch Daten wie Bilder, Musik oder Videos werden in Binärdateien gespeichert.

Abb. 2: Nach dem Übersetzen in die Maschinensprache kann man aus der Programmdatei keine Informationen gewinnen.

Einblick in die genaue Funktionsweise eines Programms verschafft nur der Quelltext. Dass er bei Open Source Software vorliegt, gilt als ihr großer Vorteil. Schließlich basiert darauf die Entwicklung freier Software: Jeder, der über ausreichende Programmierkenntnisse verfügt, nimmt auf Wunsch selbständig beliebige Änderungen im Quelltext vor und übersetzt mit Hilfe eines Compilers das Programm in die Maschinensprache. Gewöhnlich stellen Open-Source-Entwickler Änderungen auch der Öffentlichkeit zur Verfügung. Nach Bekanntwerden von Sicherheitslücken gibt es deshalb meist innerhalb weniger Stunden eine ausgebesserte Programmversion. Auch neue Features steuern bei Open Source Software häufig externe Interessierte bei, so bleibt die Arbeit nicht allein am ursprünglichen Entwickler hängen.

Gegner von Open Source Software bezeichnen gerade die freie Verfügbarkeit des Quelltextes als Schwachstelle. Sie argumentieren, Angreifer fänden dadurch Sicherheitslücken besonders leicht. Denn bleibt der Quell-Code nur dem Hersteller bekannt, lassen sich Sicherheitslücken nur durch ausgiebiges Ausprobieren des Programmverhaltens finden. Die Praxis zeigt aber, dass auch in so genannter Closed Source Software, also bei Programmen, der Quelltext geheim gehalten wird, häufig Sicherheitslücken gefunden werden; dem Anwender bleibt als Gegenmaßnahme dann allerdings nur das Hoffen auf ein baldiges Update vom Hersteller, ihm selbst sind die Hände gebunden.

Da ohne Einblick in den Quelltext die genaue Funktionsweise eines Programms verborgen bleibt, setzt die Verwendung einer solchen Anwendung außerdem Vertrauen in den Hersteller voraus. Open Source Software dagegen kann jeder Programmierer der Welt selbst nach eventuellen Hintertüren oder Sicherheitslücken durchforsten. Das gewährleistet eine weitgehende Kontrolle durch unüberschaubar viele unabhängige Personen.

Kompilieren

Benutzer moderner Linux-Distributionen kommen mit dem Quelltext selten in Kontakt. Obwohl er für den größten Teil der von ihnen verwendeten Programme verfügbar ist, installieren sie gewöhnlich direkt die bereits kompilierten Programme mit Hilfe des Paket-Managers.

Doch früher oder später gerät man häufig in die Verlegenheit, ein Programm nicht in der Auswahl des Paket-Managers zu finden. Möglicherweise möchte man eine aktuelle Version ausprobieren, während für die Distribution nur eine alte Ausgabe vorliegt; manche Anwendung fehlt gänzlich. Dann helfen nur der Download der Quellen und anschließendes Kompilieren.

Der Quelltext besteht meist aus mehreren Dateien, die in einem komprimierten Archiv liegen, dessen Dateiname endet dann gewöhnlich mit .tgz, .tar.gz oder tar.bz2. Beim Entpacken entsteht ein Unterverzeichnis, mit allen zum Programmpaket gehörenden Dateien.

Kleine Helfer

Beim Kompilieren helfen einige Automatismen: So hat sich mittlerweile eine gängige Befehlskette, die Linux-Programme aus dem Quelltext zum ausführbaren Programm übersetzt, unter Linux-Benutzern zu einem festen Begriff gemausert: Der "Dreischritt", bestehend aus ./configure; make; make install.

Fast alle Software-Pakete liefern im Quelltextarchiv ein Skript namens configure mit. Es überprüft, ob alle zum Kompilieren notwendigen Programme und Bibliotheken vorhanden sind, und gibt entsprechende Hinweise aus. Außerdem lassen sich hiermit programmspezifische Parameter festlegen -- im Fall von Audioprogrammen beispielsweise, welches Sound-Wiedergabesystem sie verwenden sollen. Auch das Verzeichnis, in dem die fertigen Programmdateien landen werden, wird hier festgelegt.

Die Qualität der configure-Skripte variiert in der Praxis jedoch sehr stark. Im Idealfall bermerken sie zuverlässig, dass beispielsweise eine bestimmte Entwicklungsbibliothek fehlt, und geben deren Namen aus. Installiert man die benötigten Pakete lediglich über den Paket-Manager nach. Im schlechteren Fall übersieht configure fehlende Software, so dass der Kompiliervorgang scheitert, ohne dass sich dem Benutzer der Grund dafür erschließt.

Ist das configure-Skript zufrieden, speichert es seine Bestandsaufnahme in einer eigenen Datei. Aus dieser erfährt der nächste Schritt im Dreisatz seine Instruktionen: Beim Programm make handelt es sich um eine Kompilierhilfe. Es ruft im Wesentlichen den Compiler auf und sorgt dafür, dass er den Quelltext mit den richtigen Parametern in ein ausführbares Programm verwandelt.

Der make-Aufruf übernimmt also die eigentliche Arbeit, das Kompilieren. Anschließend liegt das fertige Programm im Quelltextverzeichnis und lässt sich gewöhnlich von dort aus direkt aufrufen. Es ist allerdings noch nicht ins System eingebunden, so dass ein Aufruf stets die Angabe des kompletten Verzeichnispfades erfordert, auch eventuelle Einträge im KDE-Menü fehlen noch. Diesen letzten Schritt erledigt der Befehl make install. Er kopiert die Programmdateien in die von configure festgelegten Zielverzeichnisse. Das erfordert fast immer root-Rechte.

Interpretationssache

Eine zunehmend beliebtere Ausnahmeerscheinung unter den Programmiersprachen sind die so genannten Skriptsprachen. Beim Programmieren selbst schreibt der Entwickler den Quelltext ebenso wie bei herkömmlichen Sprachen als Text in der von der jeweiligen Sprache vorgegebenen Art und Weise. Zur Unterscheidung nennt man ein solches Programm oft schlicht "Skript".

Skripte braucht man vor dem Ausführen nicht zu kompilieren, stattdessen benötigt man einen Interpreter. Er fungiert als Stufe zwischen auszuführendem Programm und Prozessor. Statt des minimalen Befehlssatzes einer Maschine versteht er eine ganze Programmiersprache, so dass eine Übersetzung nicht nötig ist. Das führt jedoch dazu, dass sich ein Skript nicht selbständig ausführen lässt, es setzt immer der Interpreter voraus.

Bekanntestes Beispiel für eine Skriptsprache ist Bash. Die meisten Anwender kennen diesen Interpreter eher von der Kommandozeile. Auf der Eingabeaufforderung eingetippte Befehle sind jedoch nichts anderes als einzeilige Miniaturprogramme. Ein Shell-Skript reiht in einer Datei Bash-Befehle aneinander. Beim Start des Skripts interpretiert Bash dann diese Befehle und übersetzt sie direkt in die Maschinensprache.

Der Grund für die fortschreitende Verbreitung von Skriptsprachen liegt in der technischen Entwicklung. Da das Interpretieren zur Laufzeit den Prozessor zusätzlich beansprucht, sind Skripte langsamer. Bei modernen Rechnern lässt sich dieser Geschwindigkeitsunterschied jedoch meist verschmerzen.

Paradies oder Hölle?

Compiler, Entwicklungsbibliotheken, Dreisatz; wer seinen Computer über die grafische Oberfläche bedient, kommt damit nur ungern in Kontakt. Schließlich soll der Rechner die Arbeit erleichtern und nicht erschweren. Deshalb sehen es Linux-Distributoren als eine ihrer Hauptaufgaben an, ihren Kunden diese Arbeit abzunehmen. Ohne Hintergrundkenntnisse gerät man dabei nämlich sehr schnell in ausweglose Sackgassen. (csc)

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.