C++ Programm auf einem Pc ausführen der kein Compiler instlliert hat!
-
Fellhuhn schrieb:
Ein Nachteil des statischen Links ist das die Anwendung ohne einen Recompile nie von neueren Versionen einer DLL profitieren kann. Bei sicherheitskritischen Anwendungen kann das ein Problem werden.
... aber auch zu einer Stärke, weil Dir niemand eine gehackte DLL unterschieben kann.
DLLs koppeln eben unterschiedliche Anwendungen - mit allen Vor- und Nachteilen.
Wenn Dein Programm die DLL in der Version 1.0 braucht und ein anderes aber in der (inkompatiblen) Version 2.0, dann muss man schon seeehr fummeln, bis das vernünftig läuft.Ich will jetzt kein Plädoyer für/gegen das Eine halten, sondern nur meiner Meinung Ausdruck verleihen: Es kommt halt drauf an ...
Gruß,
Simon2.
-
DLLs koppeln eben unterschiedliche Anwendungen - mit allen Vor- und Nachteilen.
Wenn Dein Programm die DLL in der Version 1.0 braucht und ein anderes aber in der (inkompatiblen) Version 2.0, dann muss man schon seeehr fummeln, bis das vernünftig läuft.Hem, weiß jetzt nicht was du damit meinst? Die DLL-Hell gibts seit WinXP nicht mehr, da jede DLL versionierbar ist (echt versionierbar, nicht nur über den Dateinamen!). Natürlich sind alte DLLs davon nicht betroffen, da gibts die DLL weiterhin.
Aber jeder der mit einem aktuellen MS-Compiler arbeitet, kann versionierte DLLs erzeugen und benutzen. Wird auch alles fein und säuberlich in WinXP in einem System-Verzeichnis entsprechend verwaltet und man kann nur mit Admin-Rechten darin die DLLs ablegen.Das ist ja auch gerade der Grund, warum viele erst auf diese Probleme stossen, das die EXE auf einmal nicht läuft: genau die von der EXE geforderte DLL in genau der bestimmten Versionsnummer ist nicht vorhanden. Damals war das natürlich anderes. Da liefs wahrscheinlich zufällig.
Wie es unter Linux und Unix mit dynamischen Libs aussieht weiß ich dagegen leider absolut nichts. Kann nur für Windows sprechen.
-
Artchi schrieb:
Es geht nicht um .NET
Deshalb schwieg ich ja auch davon
Artchi schrieb:
sondern um vielleicht ein 2,7 MB Packet was man bei MS runter laden muß.
Es ist ein Umweg und wird unter Umständen als zusätzlicher Ballast auf dem Rechner empfunden. Daß es eigentlich völlig problemlos ist, heißt nicht, daß es auch so empfunden wird.
audacia schrieb:
Aber hier im Forum kommt jeden Tag einer an und fragt, warum seine EXE nicht auf dem PC des Kumpels läuft. Ja mein Gott, der hat die CRT nicht drauf und muß sie installieren. Wenn er kein DirectX hat, sagt ihr ihm ja auch nicht, er soll DirectX statisch linken. Warum? Weil DirectX auf dem PC vorhanden sein sollte. Wenn nicht, gibt man nen Link zum MS-Download oder liefert DX zum installieren mit.
Meinst du nicht, daß du dich da in der Kategorie etwas vertust? DirectX ist mit Sicherheit ein anderes Kaliber als eine RTL, und ein handelsübliches Spiel ist auch nicht mit den Anwendungen, die hier an Freunde weitergegeben werden sollen, zu vergleichen. Es bereitet einfach weniger Umstände, ein solches Programm statisch zu linken.
Artchi schrieb:
Und natürlich hat statisches Linken auch Nachteile zur Laufzeit. Z.B. wenn man Daten zwischen zwei Anwendungen austauscht, und jede Anwendung hat eine eigenen CRT-Instanz, kann der Datenaustausch nicht so gut funktionieren, wie wenn sie die gleiche CRT aus der selben DLL benutzen.
Wie tauschst du Daten zwischen zwei Anwendungen? Mit IPC? Wo sollen da die Vorteile liegen?
Oder meinst du die Vorteile, die sich ergeben, wenn z.B. Anwendung und DLL denselben Speichermanager benutzen, so daß im einen Modul allozierte Daten auch im anderen freigegeben werden können?Zudem hat eine statische CRT sogar geringe Laufzeitvorteile, da in Windows DLL-Funktionen über eine Jumptable angesprochen werden und somit ein CALL mehr nötig ist.
Dynamisches Linken ist insbesondere vorteilhaft, wenn ein Programm aus mehreren Modulen besteht, die alle dieselben Bibliotheken verwenden, so daß diese nur einmal geladen werden und das Working Set des Programmes kleiner bleibt, und zudem, da ein gemeinsamer Speichermanager benutzt werden kann.
Artchi schrieb:
Klar, die CRT ist zum Glück nicht so groß, aber da sie von jedem C und C++ Programm genutzt wird, macht sie als DLL Sinn. Es geht ja nicht um eine Library, die nur von einem speziellen Programm genutzt wird.
Angesichts der oben dargelegten Vielzahl von CRT-Versionen für verschiedene Sprachen, verschiedene Compiler und verschiedene Compilerversionen schätze ich die Überschneidungsrate als eher gering ein. Nur wenige Programme, die ich parallel verwende, sind mit der gleichen Compilerversion übersetzt. Zudem verwenden die meisten kleineren Programme nicht allzu viele Funktionen aus der RTL, so daß die RTL für den wahrscheinlichen Fall, daß sie von keinem laufenden Programm schon geladen wurde, das Working Set eher unnötig vergrößert.
Simon2 schrieb:
... aber auch zu einer Stärke, weil Dir niemand eine gehackte DLL unterschieben kann.
Keine Sorge, da gibts schon Mittel und Wege, die DLL trotzdem in das Programm zu bekommen :p
-
Ich will ja niemanden abhalten statisch zu linken. Aber ich fand es einfach nicht richtig, den Fragesteller nicht korrekt zu informieren. Es gibt nicht umsonst die unterschiedlichen Deployment-Verfahren. Und sicherlich gibt es auch nicht ohne Grund das statische Linken der CRT. Keine Frage.
-
jungs ich bin echt beeindruckt von euch das ging ja mal schnell:)
1aich habe jedenfalls gehört man kann sich ein installer basteln mit der exe und der dll datei die dann richtig abgespeichert werden...aber soll eigentlich nur ein kleines prog sein...
-
audacia schrieb:
...
Simon2 schrieb:
... aber auch zu einer Stärke, weil Dir niemand eine gehackte DLL unterschieben kann.
Keine Sorge, da gibts schon Mittel und Wege, die DLL trotzdem in das Programm zu bekommen :p
Was aber nur geht, wenn Du das binary hackst .... wenn Du das kannst, brauchst Du aber kein "DLL-Unterschieben" mehr.
Mit dem "DLL-unterschieben" aber kannst Du ALLE Programme, die diese nutzen, hacken, ohne Dich mühsam durch alle Binaries zu buddeln und zwar über den ganz normalen Installationsweg.Viel skeptischer bin ich bei DLL-Benutzung aber nicht bzgl der Sicherheits-, sondern bzgl. der Kompatibilitätsaspekte. Bugfixes über eine neue DLL: Prima !
Aber bei Versionsänderungen verheddert man sich sehr leicht.Gruß,
Simon2.
-
Simon2 schrieb:
Was aber nur geht, wenn Du das binary hackst .... wenn Du das kannst, brauchst Du aber kein "DLL-Unterschieben" mehr.
Mit dem "DLL-unterschieben" aber kannst Du ALLE Programme, die diese nutzen, hacken, ohne Dich mühsam durch alle Binaries zu buddeln und zwar über den ganz normalen Installationsweg.Der Aufwand ist meist nicht nötig; es gibt ja die Möglichkeit der DLL-Injektion. Aber da weichen wir vom Thema ab
Simon2 schrieb:
Viel skeptischer bin ich bei DLL-Benutzung aber nicht bzgl der Sicherheits-, sondern bzgl. der Kompatibilitätsaspekte. Bugfixes über eine neue DLL: Prima !
Aber bei Versionsänderungen verheddert man sich sehr leicht.Stimmt. Daher gibt es ja auch WinSxS, für jede Compilerrevision eine neue Version der RTL und die Angewohnheit, solche DLLs im Programmverzeichnis und nicht unter \system32 unterzubringen.
Außerdem zieht das Bugfix-Argument nur bedingt. Der durchschnittliche Benutzer würde sich vielleicht einen Bugfix beim Hersteller der Anwendung herunterladen, aber doch nicht eine neuere Version der RTL-DLL auf der Seite des Compilerherstellers.
-
audacia schrieb:
Simon2 schrieb:
Was aber nur geht, wenn Du das binary hackst .... wenn Du das kannst, brauchst Du aber kein "DLL-Unterschieben" mehr.
Mit dem "DLL-unterschieben" aber kannst Du ALLE Programme, die diese nutzen, hacken, ohne Dich mühsam durch alle Binaries zu buddeln und zwar über den ganz normalen Installationsweg.Der Aufwand ist meist nicht nötig; es gibt ja die Möglichkeit der DLL-Injektion. ...
Genau davon sprach ich doch....und das ist eben gar nicht notwendig, wenn man einfach direkt seine DLL auf's System schmeißen kann.Egal.
Gruß,
Simon2.
-
Du meinst mit "das binary hacken" DLL-Injection? Na dann...
-
audacia schrieb:
Du meinst mit "das binary hacken" DLL-Injection? ...
"DLL-Injection" ist für mich EINE Form von "binary hacken" (OK, ist ein wenig reißerisch formuliert, aber mir ist nichts Besseres eingefallen, zumal ich nicht nur Windows im Blick hatte). "Schön", wenn ein OS es zulässt, dass mit dem geladenen Prozess im Hauptspeicher zu tun, aber es ist ja nunmal nicht die einzige Möglichkeit.
Gruß,
Simon2.
-
Artchi schrieb:
Die CRT ist nämlich etwas essenzielles, das sollte eigentlich auf jedem PC drauf sein...
CStoll schrieb:
Zumindest die Release-Version der CRT...
... essenziell in diesem Sinne ist für mich exakt alles dass, was mit der
normalen Standard-Installation (Default-Einstellung) des Betriebssystems
auf dem Rechner landet, sonst nichts.Alles andere ist mein Bier, wenn ich eine Software entwickle und verteile.
Wenn die nun leider zusätzliche Bibliotheken benötigt, dann muß ich die
eben mitbringen bei der Installation - wie auch immer ich das löse.Artchi schrieb:
Ja mein Gott, der hat die CRT nicht drauf und muß sie installieren.
Macht ihr euch da nicht die Sache doch ein wenig zu einfach?
Hier nur mal ein kleines Beispiel - ganz passend zum Thema, habe ich zufällig in einem anderen Forum gefunden, unter:
http://www.tutorials.de/forum/c-c/301148-eckmaus-ein-kleines-konzept-c-zum-intelligenten-starten-von-anwendungen.htmlDort hat jemand stolz sein erstes C++ Programm gepostet, und ich hab's direkt mal runtergeladen und gestartet:
"Die Anwendung konnte nicht gestartet werden, weil CC3280MT.DLL nicht gefunden wurde."
"Neuinstallation der Anwendung könnte das Problem beheben."An der Fehlermeldung kann man schon gleich mal sehen, dass ich keine aktuelle Borland-IDE auf dem Rechner installiert habe.
Der zweite Teil der Fehlermeldung ist leider blanker Unsinn. Aber dafür kann natürlich keiner etwas, das ist eben der Standard-Fehlertext.
Nur wird eine Neuinstallation das Problem hier gerade nicht beheben, weil einfach die DLL im Package fehlt.Die muss sich der User dann eben halt besorgen - kann doch kein Problem sein. Was der "normale" Anwender an der Stelle machen würde, weiß ich nicht.
Allerdings glaube ich kaum, dass er direkt zu www.borland.com surfen wird. Woher sollte er auch wissen, dass er dort vielleicht die RTL finden kann?
(Kann euch aber beruhigen, findet er dort auch nicht. Jedenfalls nicht wenn er einfach nur nach "CC3280MT.DLL" sucht.)Der normale User würde wahrscheinlich einfach sagen "Schade, Programm runtergeladen - funktioniert aber nicht auf meinem Rechner".
Der etwas erfahrenere User würde vielleicht direkt mal probieren in Google nach "C3280MT.DLL" zu suchen.
... dort wird er dann zwar leider nicht wirklich die DLL finden,
... aber dafür einen Link zur Trial-Version des Entwicklerpaketes,
... und das wird er natürlich auch gleich runterladen, und sofort mal 'nen C++ Builder installieren,
... weil ihm ja augenblicklich klar wird, dass er dann vermutlich im Besitz der fehlenden RTL ist.
... und das alles wird er garantiert auch dann tun, wenn er mit dem C++ Builder selber, gar nix anzufangen weiß.
Wenn ihr nun immer noch eure Meinung so vertretet, wie ihr sie hier gepostet habt, dann solltet ihr genau so weitermachen.
Falls euch aber auch nur leiseste Zweifel kommen - wäre es vielleicht an der Zeit, einfach nochmal darüber nachzudenken.Grüße
napstix
-
Das statische linken ist hilfreich für kleinere 1file-Programme.
Gut, aber was ist, wenn man ein portables Programm hat, was auf dem USB-Stick laufen soll? Man kann doch nicht bei jedem Nutzer, bei dem man den Stick reindollt, die dlls nachladen!Deshalb sollte man, wenn man so ein Proggy hat, die DLL direkt beiliefern.
Aber woher weiß ich, welche DLL für welches Studio ist?
Kann ich dem Compiler sagen, er soll die DLL direkt in das Verzeichnis der Release kopieren? Wenn nicht, wie komme ich an die dll und woher weiß ich welche crts ich brauche?
-
Ehm, der User braucht doch nur die CRT installieren, wenn sie ihm fehlt. Spätestens beim starten oder installieren deiner Anwendung, bekommt er eine Fehlermeldung, das die CRT fehlt.
Ich weiss ned in was fuern umfeld Ihr programmiert, oder ob unsere Umgebung so der Exot ist, aber:
Unsere rechner werden zentral verwaltet. nen Installationsprogram ausfuehren ist nicht. Admin rechte, oder ueberhaupt Rechte um irgendwas zu installieren, gibts nur nach "Anfrage" und "Absegnung" des Verantwortlichen der Abteilung.Nur um mal so nen ueberblick zu verschaffen, was es "kosten" kann, die CRT zu installieren
Und jeder compiler, oder jede version bzw, jedes service pack, bringt ja nun wiederum neue CRT's mit.
Da werden exe's die ihre eigenen CRT's mitbringen richtig schick
Fuer unsere groessere Programme, klar schreiben wir auch setups, und da gibts die CRT auch als DLL, aber kritisiert wird regelmaessig, das das eingebettete MS Service update fuer die runtime unbedingt admin rechte haben will.
fuer kleine Progs, vorwiegend kommandozeilen programme, waer das nen ko kriterium ....
Ciao ...
-
XC++ schrieb:
Kann ich dem Compiler sagen, er soll die DLL direkt in das Verzeichnis der Release kopieren? Wenn nicht, wie komme ich an die dll und woher weiß ich welche crts ich brauche?
Einem Compiler kann man gewöhnlich nicht sagen, dass er etwas kopieren soll. Das kannst du deiner Entwicklungsumgebung sagen, indem du "Pre Build Steps" bzw. "Post Build Steps" definierst.
Man kann die Abhängigkeiten einer Assembly mit bestimmten Tools prüfen. Unter unixoiden Systemen wie Linux ist dafür normalerweise der Kommandozeilen-Befehl ldd vorinstalliert. Für Windows kann man sich das Tool Dependency Walker herunterladen, um die Abhängigkeiten zu überprüfen.
-
Lest euch doch einfach mal hier durch. Da steht eigentlich alles, was man wissen muß.