Die Community zu .NET und Classic VB.
Menü

Die Laufzeitbibliotheken

 von 

Einleitung 

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

Laufzeitbibliotheken und Laufzeitumgebung  

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.

Weitergabe  

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.

Schlusswort  

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.

Ihre Meinung  

Falls Sie Fragen zu diesem Artikel haben oder Ihre Erfahrung mit anderen Nutzern austauschen möchten, dann teilen Sie uns diese bitte in einem der unten vorhandenen Themen oder über einen neuen Beitrag mit. Hierzu können sie einfach einen Beitrag in einem zum Thema passenden Forum anlegen, welcher automatisch mit dieser Seite verknüpft wird.

Archivierte Nutzerkommentare 

Klicken Sie diesen Text an, wenn Sie die 15 archivierten Kommentare ansehen möchten.
Diese stammen noch von der Zeit, als es noch keine direkte Forenunterstützung für Fragen und Kommentare zu einzelnen Artikeln gab.
Aus Gründen der Vollständigkeit können Sie sich die ausgeblendeten Kommentare zu diesem Artikel aber gerne weiterhin ansehen.

Kommentar von Philipp Stephani am 24.05.2007 um 19:51

Doch, du darfst die Runtimes auf jeden Fall mitliefern. MS bietet dafür extra Redistributable-Packages an.

Kommentar von said am 24.05.2007 um 11:28

wie jetzt? habs nicht so richtig kappiert?

ich habe ein eigenes setuppacket entworfen, mit der sich die wichtigen vb6 runtimedateien und einige von mir hergestellte ocx auf dem zielsystem installiert lassen. diesen setup verwende ich als subsetup in allen meiner setups, damit die software rasch installiert werden kann und sofort zu verfügung steht.

darf ich das denn jetzt nicht oder wie? ich meine die runtimedaten mit meiner software mitliefern?

ich meine das wäre doch total bescheuert, weil man beim erstellen des setups selbstverständlich alle nötigen komponente einbeziehen muss. sonst installiert sich doch kein mensch ein solches programm, bei dem die halbe abhängigkeit fehlt!

und wie soll das dem kunden zumutbar sein? die meisten anwender haben grundsätlich keine ahnung vom programmieren geschweige denn von irgendwelchen fehlenden komponenten oder sowas in der art. wenns nicht läuft, dann läufts halt nicht! dann wirds auch nie wieder installiert. damit hat man dann einen kunden weniger.

ich meine wenn man sich die vbstudio kauft, so wird man sie dann doch vernünftig einsetzen dürfen.

ich bitte um aufklärung.

mfg
kurt

Kommentar von Philipp Stephani am 13.09.2006 um 19:54

Hallo,
die Kolumne ist ja schon etwas älter, und beim nochmaligen Durchlesen sind mir doch noch einige Unstimmigkeiten aufgefallen:
- Angeblicher Nachteil der Vergrößerung der Anwendungsdatei: Für große Funktionen kann das durchaus stimmen; kleine, oft verwendete Funktionen sollte der Compiler dagegen ohnehin automatisch inlinen. Dadurch wird eine Geschwindigkeitssteigerung erzielt, ohne die Ausgabedatei übermäßig zu vergrößern. Es werden natürlich nur die benötigten Funktionen eingebunden und nicht ganze Bibliotheken.
- Vorhandensein der VB6-Runtime und des .NET Frameworks in Windows: Die Realität sieht anders aus. Kein einziges System außer Windows XP enthält die VB6-Runtime, und auch in Windows XP nicht in der aktuellen Version. Das .NET Framework ist sogar auf überhaupt keinem einzigen heute verfügbaren Produktivsystem vorhanden. Das heißt, dass die meisten der hier präsentierten Argumente nicht zählen, weil sie von einem Vorhandensein der Runtimes ausgehen, was in keinem einzigen Fall von Haus aus gewährleistet ist.
- Komaptibilität des .NET-Framework: Schön wär's. In der Regel sind Programme nicht kompatibel (z.B. Paint.NET). Es müssen also sämtliche Versionen des .NET Frameworks gleichzeitig installiert sein, was die Festplatte nicht gerade schont. Von einer Festverdrahtung des .NET Frameworks in Vista kann, so weit ich weiß, auch keine Rede sein; das Framework ist wohl weiterhin ein einfacher Aufsatz auf die Windows-API mit ein paar zusätzlichen Klassen (sonst könnte es nicht unter Windows XP laufen). Wenn ich mir die Änderungen in Vista so anschaue, erscheinen sie mir geradezu marginal und rechtfertigen kaum eine neue Hauptversionsnummer.

Kommentar von Tornado am 19.03.2005 um 23:45

Hi, super Kolumne,
aber ich kann dir leider nicht zustimmen. Ich habe schon einige Programme programmiert, auch für eine Spielecommunity, die verschiedene Funktionen hatte, und weniger als 5% hatten die Runtime!!! Annähernd jeder musste sie erst installieren, obwohl ALLE winxp hatten.
Ich würde mir wünschen, dass VB verschiedene Runtimes in die exe integriert, die es zumindest möglich machen, die benötigten runtimes zu identifizieren und zu kopieren.
Dabei denke ich vor allem an non-visuelle funktionen, also keine Formen, buttons o.Ä., zur kommunikation nur msgbox / inputbox.
das würde VB um einiges benutzerfreundlicher und vor allem entwicklerfreundlicher machen.

gruß florian

Kommentar von Daniel Pramel am 17.01.2005 um 11:57

Zitat: "[...]allerdings sollte man hier den Fehler eher beim Benutzer suchen"
Konrad, der Fehler liegt nie beim Benutzer. Schon vergessen?

Kommentar von UnbeaTable am 01.01.2005 um 13:30

sehr coole Kolumne! :)

Kommentar von Philipp Stephani am 18.11.2004 um 19:11

Das geht in VB leider überhaupt nicht, deswegen müssen bei "ernsthaften" Anwendungen die Laufzeitbibliotheken immer mit ausgeliefert werden. Es kann einfach nicht vorausgesetzt werden, dass der Benutzer die benötigte Version (auch mit richtigem SP) schon hat.

Kommentar von Wolfgang Wolf am 15.09.2004 um 15:29

Warum Runtime-Aufrufe? Das ist es ja was ich mir von VB wünsche: die von mir gepostete Funktionen (If, NotExistVBRuntime, MsgBox und Shell) in der Exe verfügbar machen, ohne dass dazu die Runtime benötigt wird. Hätte den Vorteil, dass man dem Benutzer zumindest eine vernünftige Fehlermeldung ausgeben könnte. Wenn das Programm von CD gestartet wird, könnte man bei Bedarf sogar die Installation der Runtime anbieten.
Warum ist der Anwendungsstart nur über eine Runtime sinnvoll? Ein C Programm kann ich doch auch ohne MFC starten. Beim Start kann ich dann prüfen ob die MFC vorhanden ist und fordere ggf. den Benutzer auf diese zu installieren. Mit dieser Funktionalität (eine Prise PB in VB) würde ich nie wieder über die VB-Runtime lästern ;-)

Kommentar von Konrad L. M. Rudolph am 15.09.2004 um 14:28

W. Wolf: ähm. Du hast sicher Recht, die Fehlermeldung von VB ist nicht gerade sehr hilfreich für Normalbenutzer, es ist eben eine Standard-Fehlermeldung.
Aber der von Dir gepostete Aufruf macht mich stutzig. In diesem kurzen Code werden bereits mindestens drei Runtime-Aufrufe getätigt -- wie bitte sollte dieser Code also ohne Runtimes laufen?
Außerdem hinkt diese Idee sowieso, da bereits der ganze Anwendungsstart nur über die Runtimes funktioniert und das ist auch extrem sinnvoll so. Wenn das nicht so wäre, dann wäre VB längst nicht so komfortabel, wie es eben ist.
Fazit: es geht einfach nicht -- auch nicht in der Theorie!

Kommentar von W. Wolf am 09.09.2004 um 19:22

Hallo Konrad,
nichts gegen Laufzeitbibliotheken, auch nichts gegen die VB-eigenen. Das Problem dabei ist eben nur, dass ohne Runtime rein gar nichts geht. Ich wäre schon mit einem VB glücklich dass mir gewisse Gundfunktionalität bietet, z.B.:

If NotExistVBRuntime
If MsgBox("Auf Ihrem System fehlen die VB-Runtime-Dateien. Solle diese Laufzeitbibliotheken auf Ihrem System aktualisiert werden?", vbYesNo) Then
Shell "vbruntime.exe"
Exit Sub
End If
Else
Exit Sub
End If

Leider vermag VB in keiner Version diesen einfachen Code zu runtimefreinen Nativ-Code kompilieren. Wer seine Anwender nicht mit einer nichts sagenden "Die DLL xyz.dll wurde im angegebenem Pfad nicht gefunden"-Meldung konfrontieren will, muss auf ein Setup mit integrierter Runtime bestehen oder vor die eigentliche Exe ein C, Delphi- oder PB-Dummy-Programm schalten (wie unter www.ww-a.de\vbcd1.htm beschrieben), dass die Existenz der Runtime in der richtigen Version prüft, ggf. den Benutzer über dessen fehlen informiert und Gegenmaßnamen anbietet. Unter diesen Umständen kann ein VB-Programm sogar von CD-ROM starten.

Kommentar von Philipp Stephani am 30.08.2004 um 00:45

@Marco:
Ja, das mit dem .NET Framework stört mich auch etwas. Auch, dass es so groß sein muss und nur komplett ausgeliefert werden kann. Ich denke, dass eine Standard-.NET-Anwendung nur ein paar Prozent der Klassen benutzt, die anderen bräuchte man eigentlich nicht. Man kann auch weder Longhorn noch DSL voraussetzen, damit schließt man ungefähr 100% aller Benutzer aus (weil es Longhorn noch nicht gibt...). Ich fände es auch nicht schlecht, wenn MS eine kostenlose CD mit dem Framework rausgeben würde, wie es das ja schon mit vielen Paketen macht.

Kommentar von Marco am 18.08.2004 um 11:25

Hi Konrad,

dieses Thema wurde ja schonmal (vielleicht auch des öfteren) im VB-Forum angesprochen. Und die Sache mit dem .NET-Framework bleibt dennoch ein Problem für viele Programmierer, bzw. stellt es vielleicht die letzte Hürde dar. - Wie du schon geschrieben hast, wird das .NET-Framework vermutlich in Longhorn "fest verdrahtet" sein. Und dann dürfte die Ausrede mit dem "noch zu downloadenden Framework" nich mehr ziehn. Was ist aber wenn sich die Version dieses Frameworks ändert? Bei mir war es so: Ich hab mir ein Tool runtergeladen und wollte es starten. Dieses verlangte aber das .NET-Framework. Intelligenterweise hatte ich bereits eines installiert. Dummerweise aber die falsche Version. Ergo mußte ich mir die neueste Version mir über 20MB laden, die für mich als 56k-Modem-User nich gerade klein ist. Ok, bei VB6 gibts auch verschiedene Runtimes, aber wenn ich noch eine veraltete VB6-Runtime installiert hatte, lief das Programm trotzdem und hat nicht von mir verlangt, ich solle 20MB aus dem Netz schaufeln.
In sofern is das mit dem fetten .NET-Framework und der Philosophie: "Wenn eine neue Version, dann komplett!" echt sch****...
PS: Keiner kann erwarten, dass ich einen ISDN/DSL-Internetzugang nutze, wie auch du keine 60GB-Platte hast. ;)

Kommentar von Hendrik am 18.08.2004 um 10:19

Hallo zusammen,

erstmal ein großes Dankeschön an Konrad für diese ausführliche und interessante Kolumne :-)

Ich gehörte ursprünglich auch zu den Leuten, die lieber ein Setup mit einkompilierter Runtime erstellt haben, einfach deshalb, weil ich selbst die leidvolle Erfahrung gemacht habe, das ein Programm nicht lief, weil irgendeine Komponente fehlte.

Nachdem man aber nun (z.B. hier im Forum) gehört hat, dass es bei einigen Betriebsystemen (ich glaube Win95, NT4) zu Problemen kommen kann, sofern man da bei der Installation einfach die VB6 Runtimes SP6 installiert, werde ich auch dazu übergewechseln ein kleines Setup zu erstellen und den Link für die Runtimes bereitzustellen.

OK. Anders sieht das vielleicht bei "professionellen" Anwendungen aus, die eine Menge Geld kosten. Da kann man vielleicht nicht unbedingt verlangen, dass der Kunde zusätzlich noch Dateien herunterlädt; der will einfach die CD einlegen, das Setup starten und fertig.

@Jürgen:
Ich stimme Dirr im Großen und Ganzen voll zu. Selbstverständlich kann man mit VB excellente Anwendungen schreiben (auch wenn andere da eine andere Meinung vertreten..). OK, ob man komplett auf Zusatzkomponenten verzichten kann hängt natürlich immer von dem Programm ab.


Gruß,
Hendrik

Kommentar von Florian Rittmeier am 18.08.2004 um 10:08

Hallo am,
wenn jemand keine Setups ausführen darf, dann hat das sehr gute Gründe. Es gibt nämlich Umgebungen, in denen es unerwünscht ist, wenn Betriebsfremdeanwendungen eingesetzt werden.

Gruß Florian

Kommentar von am 18.08.2004 um 09:59

Hallo,

ich würde mir ein VB wünschen, das per Option auch ohne Laufzeitbibliotheken auskommt. Wie in der guten alten DOS-Zeit. Für schlanke Applikationen, z.B. zum Lesen und schreiben von Daten im Dateisystem. Oder immer dann, wenn keine grafische Ein- und Ausgabe notwendig ist. Oder zum direkten Ansteuern der Hardware....

Weitere Gründe:
- damit eine Anwendung möglichst unabhängig von der Windows-Umgebung und von anderen Applikationen eingesetzt werden kann
- um zu gewährleisten, dass eine Applikation alles zur Verfügung hat, was sie für die Ausführung benötigt
- um auch Programme ausliefern zu können, die ohne Setup-Routine auskommen
- weil man dem Anwender nicht immer zumuten kann, dass er wegen einer bestimmten Applikation fehlende Runtimes installiert
- weil nicht jeder Anwender dazu in der Lage ist (oder es nicht darf), selbständig ein Programm-Setup zu starten.

Man sollte nicht ausser Acht lassen, dass auch Heute noch zu einem erstaunlich hohen Prozentsatz ältere Windows Versionen eingesetzt werden, die eben nicht die erforderlichen Runtime-Versionen "im Bauch haben".

Eric Apholte