Laufzeitbibliotheken, auf Englisch „Runtime libraries“ oder auch kurz „Runtime(s)“, scheinen für viele der größte Kritikpunkt an VB und dem .NET Framework zu sein. Dies zeigt, wie viele Programmierer den Sinn einer solchen Laufzeitumgebung nicht verstanden haben. Die vorliegende Kolumne versucht, den Sinn der Laufzeitbibliotheken zu erläutern.

Mit freundlichen Grüßen,
Konrad L. M. Rudolph

Inhalt

	Laufzeitbibliotheken und Laufzeitumgebung
	Weitergabe
	Schlusswort

In den meisten Fällen bestehen die Laufzeitbibliotheken aus einem Satz an Bibliotheken, die häufig benötigte Funktionen bündeln und auf die von Programmen aus zugegriffen wird. Sie werden zum Laufen des Programms benötigt und nennen sich daher eben Laufzeitbibliotheken. Es existiert auch eine Weiterführung dieses Konzepts. Diese wird zum Beispiel in .NET und Java, aber auch im P-Code aus VB, umgesetzt: hierbei übernimmt die so genannte Laufzeitumgebung die Aufgabe, die Programmdaten einer Anwendung zu interpretieren beziehungsweise zu kompilieren, da Programme nicht wie üblich aus Maschinencode-Anweisungen bestehen, sondern vielmehr einen so genannten Zwischencode verwenden, der erst für die Maschine verständlich gemacht werden muss.

Der Sinn dieses Konzepts ist es, für jede Plattform auf jeder Zielmaschine eine möglichst optimale Ausführung zu erhalten; im idealen Fall gleicht die Laufzeitumgebung also Unterschiede der verschiedenen Systeme aus und gewährt einen einheitlichen Zugriff auf unterschiedliche Systemschnittstellen, der ansonsten nicht gewährleistet ist.

Generell bedeutet der Einsatz von Laufzeitbibliotheken die konsequente Umsetzung eines Konzepts der Informatik, nämlich der Wiederverwendbarkeit von Code. Sobald eine bestimmte Aufgabe häufig in Programmen gelöst werden muss, lohnt es sich, die Problemlösung zu extrahieren und getrennt bereit zu stellen, so dass Anwendungen lediglich einen Verweis auf den bereits existierenden Code einbinden müssen. Da es eine große Anzahl solcher Aufgaben gibt, ist es logisch, diese externen Verweise zusammenzufassen und in einer Laufzeitbibliothek zu bündeln.

Visual Basic als Sprache für schnelle Anwendungsentwicklung („Rapid Application Development“, „RAD“) stellt solche Verweise in recht großem Umfang bereit. Wäre dies nicht der Fall, wäre VB keine RAD-Sprache. Hierzu gehört auch die Verzahnung mit scheinbar grundlegenden Datentypen und Aufgaben. So stellt in VB bereits eine Objektzuweisung ein Aufruf der Laufzeitbibliotheken dar. Und das ist gut so, denn andererseits müsste für jede VB-Anwendung ein ziemlich umfangreicher Code direkt in das Programm eingefügt werden, was die Größe der Programme extrem aufplustern würde.

Das Argument, C++ und ähnliche Sprachen würden schließlich ebenfalls ohne Laufzeitbibliotheken auskommen kann schnell widerlegt werden: erst einmal verwenden fast alle Windows-Programme, die in C++ geschrieben worden sind, Laufzeitbibliotheken, zum Beispiel „msvcrt.dll“ (welche Basisfunktionen von C und C++ bündelt) und die Microsoft Foundation Classes („MFC“, welche die WinAPI in Objekte kapseln). Ansonsten braucht man in C++ selbst für die simpelsten Aufgaben sehr viel mehr Code als in Visual Basic. Der direkte Vergleich (soweit dies möglich ist) zeigt, dass C++-Anwendungen oft um ein Vielfaches größer sind als VB-Anwendungen. Dies kann verhindert werden, indem man auf Bibliotheken wie die MFC zugreift. Auch dies sind schließlich aber Laufzeitbibliotheken – oder aber sie werden statisch eingebunden (wie die „Standard Template Library“, „STL“ oder die „Active Template Library“, „ATL“) und vergrößern somit wieder die Anwendungsdatei.

Wohingegen diese Benutzung von Laufzeitbibliotheken in C++ aber optional ist, ist sie unter VB verpflichtend. Der Programmierer hat keine Wahl und genau dies ist oft der Kritikpunkt. Wozu aber soll man diese Option haben, wenn man sie nie einsetzt? Es gibt keinen Grund, VB ohne Laufzeitbibliotheken ausliefern zu wollen, im Gegenteil: dies wäre extrem kontraproduktiv, allein aus dem Grund, dass auf den meisten modernen Systemen die VB-Laufzeitbibliotheken bereits vorhanden sind. Das Ausliefern einer Anwendung mit einkompilierten Laufzeitbibliotheken wäre redundant und eine verantwortungslose Verschwendung von Speicherplatz. Es mag unglaublich klingen aber auch heute noch hat nicht jeder eine 60-GB-Festplatte (ich habe keine).

Ausnahmen gibt es dabei keine: Wer unbedingt und kompromisslos eine Anwendung ohne externe Abhängigkeiten ausliefern möchte, sollte sich über zwei Dinge im Klaren sein: Zuerst einmal programmiert er in der falschen Programmiersprache, RAD ist hier das falsche Rezept. Zudem sollte er sich gut überlegen, für welche Plattform er seine Anwendung überhaupt entwickeln möchte. Schließlich stellen auch die Laufzeitbibliotheken eine Plattform dar. Konsequenter Weise müsste eine Anwendung ohne externe Abhängigkeiten auch auf Systemabhängigkeiten verzichten. Dies würde allerdings bedeuten, dass die Anwendung ihr eigenes Betriebssystem mitbringen müsste, schließlich stellt auch Windows eine Laufzeitumgebung dar, die WinAPI ist lediglich ihre Schnittstelle. Wo ist hier die Grenze zu ziehen? Wieso sollte es sinnvoll sein, ein Betriebssystem vorauszusetzen, wenn man keine VB-Laufzeitbibliotheken voraussetzt? Wegen der weiteren Verbreitung? Wohl kaum: fast jedes aktuelle Windows-System enthält die VB-Runtimes. Das .NET-Framework wird in jeder zukünftig ausgelieferten Windows-Version enthalten sein, ab Longhorn sogar fest ins System verdrahtet.

Die Forderung nach Laufzeit-Unabhängigkeit kommt der Forderung nach Plattform-Unabhängigkeit gleich und diese kann, wie weiter oben ausgeführt, nur durch eine Laufzeitumgebung gewährleistet werden. Ein Widerspruch in sich.

Ein weiteres Argument für das dynamische Einbinden externer Verweise, welches bei Laufzeitbibliotheken verwendet wird, gegenüber statischen Verweisen stellt die vereinfachte Wartung dar: die Laufzeitbibliotheken können im Falle eines Fehlers ausgetauscht werden, ohne dass unzählige Anwendungen neu kompiliert werden müssen. Dadurch war es Microsoft möglich, Service Packs für die VB-Laufzeitbibliotheken zu publizieren. Auch für .NET gilt dasselbe: Mit der ersten Version des Grundgerüsts kompilierte Dateien laufen auch mit Framework 1.1 und werden auch unter Version 2.0 und allen zukünftigen Versionen laufen.

Nun stellt sich die Frage, ob eine Laufzeitbibliothek gemeinsam mit einer Software publiziert werden sollte. Ich nehme die Antwort vorweg: Nein, (zumindest über das Internet) natürlich nicht. Wer publiziert schon seine Software zusammen in einem Paket mit Windows? Das geht bereits aus lizenztechnischen Gründen nicht, von der resultierenden Größe des Installer-Pakets ganz zu schweigen. Und auch das Mit-Ausliefern kleinerer Laufzeitdateien so wie jener von VB6 ist unsinnig, da wir meist davon ausgehen können, dass diese auf dem Zielsystem bereits vorhanden sind. Ausnahmefälle erfordern eine gesonderte Behandlung. Es reicht bereits, die Laufzeitdateien als unabhängigen Download bereit zu stellen. Oft höre ich, dies sei dem Benutzer nicht zumutbar. Leider trifft das manchmal zu, allerdings sollte man hier den Fehler eher beim Benutzer suchen. Doch andererseits gilt für die meisten Benutzer ebenfalls: wenn sie sich ein Programm aus dem Internet herunterladen wollen, schrecken sie vor großen Dateien zurück. Selbst mit einer DSL-Leitung entscheide ich mich zwischen zwei alternativen Programmen fast immer für das kleinere der beiden.

Es wäre natürlich schön, wenn sich dieser Vorgang automatisieren ließe, das heißt, wenn das Setup-Programm automatisch bestimmen würde, welche Dateien auf dem Zielsystem nicht vorhanden sind und nachgeladen werden müssen. Leider setzt diese Lösung eine bestehende Internetverbindung voraus. Eine ideale Lösung gibt es daher nicht. Oft höre ich den Ruf nach alternativen Versionen von auszuliefernden Programmen, eine mit und eine ohne Laufzeitbibliotheken. Einmal ganz davon abgesehen, dass dieses Konzept hinkt, sobald eine Anwendung mehrere verschiedene Laufzeitbibliotheken benötigt, finde ich das Verlangen unverschämt. Die wenigsten kleinen Programmierer (sowohl selbständig als auch in Firmen tätig) können es sich leisten, für jedes ihrer Produkte dermaßen große Versionen auf ihrem Webspace bereit zu stellen – von dem entstehenden Download-Verkehr ganz zu schweigen. Gerade bei kleineren Anwendungen, dem Vorzugs-Einsatzgebiet von Laufzeitbibliotheken, lohnt es sich finanziell nicht, den für ein solches Vorgehen nötigen Webspace und Datenverkehr zu mieten.

Die Auslieferung auf Speichermedien wie der CD ist da wesentlich einfacher. Meistens ist auf einer CD genügend Platz, um die benötigten Laufzeitbibliotheken ebenfalls unterzubringen. Je nach Art der Benutzerlizenz sollte man jedoch auch hier darauf achten, die Laufzeitdateien als externes Paket einzufügen und nicht als Teil des eigentlichen Setups, damit der Setup als solches besser weitergegeben werden kann – sofern dies überhaupt im Sinne der Benutzerlizenz ist.

Zusammenfassend kann man sagen: Sobald Laufzeitbibliotheken weit genug verbreitet sind (und dies ist bei VB und .NET der Fall) ist ihr Einsatz sinnvoll und für RAD genauso wenig wegzudenken wie das zu Grunde liegende Betriebssystem. Von einer Auslieferung der Laufzeitbibliotheken im Setup von Anwendungen über das Internet ist unbedingt abzusehen, da dies eine Verschwendung von Internetressourcen bedeutet und nicht im Sinne der Laufzeitbibliotheken liegt, sonst bräuchte man sie nicht. Eine Ausnahme stellt die Auslieferung auf der CD dar.

Hoffentlich ist es mir mit der Kolumne gelungen, einige der Ungläubigen zu überzeugen.
Konrad L. M. Rudolph.