Warum sind *.exe's so groß

[MathiasSimmack]

Zitat:

Zitat von Robert_G

Unter Windows sollte man Installationen IMMER mit MSI machen alles andere sind nur billige Bastellösungen (sorry für die NSIS-Fans, ist leider so :? )
Nur MSI-Installationen bewahren ein System vor doppelt installierten Bibliotheken oder geklauten Bibliotheken bei einer Deinstallation. ;)
Außerdem schützt Windows dann deine Anwendung installiert beim Klick auf den ShortCut Bibliotheken, die zwischendurch gelöscht wurden (es reparariert eigentlich alles wieder, Registry, environment path,...)

Dem kann man nur zustimmen. Aber die Vorteile des MSI liegen wohl auch in seiner Verdrahtung im System. Nicht zu vergessen das eingebaute Patchsystem (MSP). Alles schöne Dinge. Mit kostenlosen Mitteln (Orca) leider nur etwas umständlich zu realisieren.

[Prof.Y]

Zitat:

Zitat von Robert_G

Nur MSI-Installationen bewahren ein System vor doppelt installierten Bibliotheken oder geklauten Bibliotheken bei einer Deinstallation.

wenn das "Nur" nur stimmen würde ;)

Zitat:

Zitat von MathiasSimmack

...Alles schöne Dinge. Mit kostenlosen Mitteln (Orca) leider nur etwas umständlich zu realisieren.

...wo alles so schön in 5 Minuten mit allem Schnickschnack unter InnoSetup erledigt ist ...
...und wo Delphi-progs selbst benutzt werden können, um InnoSetup bei Bedarf mit eigener "Funktionen" zu erweitern (eigene Krypto, eigene Setup-Dialoge usw) ...
...und wo so niedlich kleine ultra-komprimierten Setup.exe gebacken werden...
...und alles schön sauber mit Delphi geprogt ;)
...und Kylix kompatibel (ob das bei MSI auch so ist ?)...

Tsss tsss tss :o))

Grüße,

[Kernel32.DLL]

Zitat:

Zitat von Garfield

Eine Alternative:

Ich hatte mehrere Programme unter Delphi 3 Professional und Delphi 7 Personal compiliert und dabei festgestellt, dass die *.EXE unter Delphi 7 Personal deutlich größer geworden sind. Ich packe die *.EXE dann mit UPX. Dadurch werden sie zwischen 50 und 70 % kleiner. Der Bedarf an Arbeitsspeicher steigt allerdings etwas an. Ich hatte das bei einem Programm getestet und da waren es ~10 %.

Von EXE-packern halte ich ehrlich gesagt überhaupt nichts. Sie bringen das komplette Windows-Speichermanagement durcheinander. Da kannst du die Exe genausogut mit Win-RAR packen...

[edosoft]

Ihr müsst das mal bei delphi... glaub 8 oder 9 wars testen da sind die exes wen die vcl dabei ist schonmal anderthalb(1,5 für nichtschwaben) MB groß!
naja ich find die vcl trotzdem praktisch, ich hab D7 da ists 500kb des geht ja noch und ich denk wenn ich ein gutes programm bau dann kommts mir drauf an dasses funktioniert und ich hab keine zeit mit den windows apis noch ne oberfläche zu basteln wenn ichs doch auch mit ein paar klicks haben kann.
Und wegem traffic: ich zahl 50cent pro gb, da sind 500kb als dateigröße wohl noch zu verkraften.


Alternativ könnte man ja sowas machen:
Du baust dir ein programm OHNE visuellen elementen (also auch keine VCL) und dein eigentliches programm verpackst du.
Dann kannst dus einfach an die erste EXE hinhängen (wie wir ja alle wissen, du kannst einfach beliebige daten hinten anne exe reinhängen solang der eigentliche teil vom programm unverändert bleibt) und die kleine non-vcl exe hat die aufgabe dein programm zu entpacken und dann erst ausführen dann sollts auch wenigstens bissle kleiner sein.

[mirage228]

Zitat:

Zitat von edosoft

Ihr müsst das mal bei delphi... glaub 8 oder 9 wars testen da sind die exes wen die vcl dabei ist schonmal anderthalb(1,5 für nichtschwaben) MB groß!

Hi,

das ist nur bei der VCL.NET der Fall. Und auch nur, falls diese in die EXE mithineingelinkt wird (also falls die VCL.NET nicht auf dem Zielrechner vorhanden ist).

mfG
mirage228

[MathiasSimmack]

Oh schön, ich werde herausgefordert.

Zitat:

Zitat von Prof.Y

Zitat:

Zitat von MathiasSimmack

...Alles schöne Dinge. Mit kostenlosen Mitteln (Orca) leider nur etwas umständlich zu realisieren.

...wo alles so schön in 5 Minuten mit allem Schnickschnack unter InnoSetup erledigt ist ...

Alles? Leider falsch. Inno Setup bringt von Haus aus weder Reparaturmodus noch Feature-Nachinstallation mit (wobei das Setup so clever ist, die schon installierten Features auch als solche zu kennzeichnen). Ganz zu schweigen vom erwähnten Patch-Management, mit dem man klitzekleine MSPs erzeugt, die die vorhandenen Produkte aktualisieren. Da braucht man bei Inno Setup leider externe Hilfstools dafür bzw. jede Menge Codezeilen.

Zitat:

...und wo Delphi-progs selbst benutzt werden können, um InnoSetup bei Bedarf mit eigener "Funktionen" zu erweitern (eigene Krypto, eigene Setup-Dialoge usw) ...

Du hast nie mit dem MSI gearbeitet, oder? Die Dialoge stecken als Tabellen in der MSI-Datei drin. Ich habe die Standarddatei des Installer-SDK (UISample.msi) damit vergrößert und dem Design der MSI von Office XP (glaube ich) angeglichen. Du musst lediglich die Größenwerte ändern, und du kannst die Buttons verschieben, usw. usw. Das einzige, das tatsächlich schwieriger ist, ist das Einbinden eigener Seiten. Aber das liegt in dem Fall an Orca. Mit einem Profi-Tool, das die visuelle Gestaltung des Setups erlaubt, dürfte das Entwickeln und Integrieren eigener Seiten leichter sein.

Zitat:

...und wo so niedlich kleine ultra-komprimierten Setup.exe gebacken werden...

Punkt für Inno Setup und NSIS. Speziell für NSIS.

Zitat:

...und alles schön sauber mit Delphi geprogt ;)

Nicht wirklich ein Argument. Ich wäre nicht hier, wäre ich kein Delphi-Programmierer, aber dennoch maße ich mir nicht an, andere Sprachen abzuwerten, nur weil ich nicht mit ihnen arbeite.

Zitat:

...und Kylix kompatibel (ob das bei MSI auch so ist ?)...

Ich kenne gar keine Kylix-Version von Inno. :oops: Sorry, muss mir wohl entgangen sein.


Wie dem auch sei, ich darf wohl ohne schlechtes Gewissen behaupten, dass ich ein bisschen Erfahrung mit dem MSI und Inno habe. Hätte ich ein Tool wie bspw. das, was es im Adventsgewinnspiel der DP zu gewinnen gab, dann würde ich mehr mit dem MSI machen. Allein schon wg. der oben angesprochenen Möglichkeiten.

[Robert_G]

Zitat:

Zitat von Prof.Y

Zitat:

Zitat von Robert_G

Nur MSI-Installationen bewahren ein System vor doppelt installierten Bibliotheken oder geklauten Bibliotheken bei einer Deinstallation.

wenn das "Nur" nur stimmen würde ;)

:gruebel: Ich wüsste kein zweites System, dass das auf die Reihe bringt.
Wobei auch MSI nicht zaubern kann.
Angenommen:
Jemand installiert eine 3rd-Party Assembly in den GAC (benutzt dabei aber so Bastelsetup)
-> allles schön und gut
Jetzt kommst du und versuchst deine Installation mit bestem Wissen und Gewissen (also mit MSI ;) ) zu erstellen.
Auch du benötigst diese Assembly und installierst sie.
Der Datenbank von Windows wird jetzt gesagt: Product Code {XXX-123-ABC} hat sich für die Assembly XXX.dll eingetragen.

Da Installation 1 nur ein Billig-XCopy&RegistryMerge-Setup verwendet hat, hat Windwos keine Ahnung, dass die erste Installation auch diese Assembly braucht.

Wenn der User deine Anwendung deinstalliert, wird der MSI diese Assembly sang- & klanglos mit wegschmeißen. (ein seiner Aufgaben ist es ja das System von Altlasten freizuhalten ;) )
Die erste Anwendung schaut also in die Röhre. :mrgreen:
Was wäre, wenn die erste Anwendung vor der 2. deinstalliert werden würde?
Nunja, das erste Setup führt keine Datenbank wer welche Assembly benötigt -> Es würde sie sowieso wegschmeißen.
Deine Anwendung hat aber Windows, das über sie wacht. :) Der User klickt auf den Shortcut und prompt erscheint ein kurzes "preparing Installation", man sieht kurz eine Progressbar aufblitzen und schon ist deine Assembly wieder genau dort, wo du sie brauchst.

Der User bekommt (bis auf das kurze Fensterchen) nix davon mit. Er merkt nur eins: Deine Anwendung funktioniert immer, während andere schonmal rumzicken können.

Aufgrund dieses Technologievorsprunges kann ich persönlich alle andere Setup engines nur als billige oder hoffnungslos veraltete Bastellösungen abtun. ;)

Zitat:

...und wo Delphi-progs selbst benutzt werden können, um InnoSetup bei Bedarf mit eigener "Funktionen" zu erweitern (eigene Krypto, eigene Setup-Dialoge usw) ...

MSI kann man nicht nur alles mögliche als "Custom Action" hinzufügen (dll, JavaScript, VB Script, .Net Assemblies).
Als .Net-Entwickler (was ich nunmal vorrangig bin ;) ) kann man ganz einfach von System.Configuration.Install.Installer ableiten.
Dadurch hat man eine absolute Kontrolle über das Setup, ohne seine "Muttersprache" verlassen zu müssen.

OK, Linux kompatibel ist es natürlich nicht. Aber wenn juckt das schon. :P

[tommie-lie]

Zitat:

Zitat von Robert_G

OK, Linux kompatibel ist es natürlich nicht. Aber wenn juckt das schon. :P

Das erste Mal, daß jemand Linux ablehnt und ich ihm zustimme :mrgreen:
Wenn man sich an die üblichen Vorgehensweisen hält, ist Deployment unter Linux sowieso anderster...

Zitat:

Zitat von edosoft

Alternativ könnte man ja sowas machen:
Du baust dir ein programm OHNE visuellen elementen (also auch keine VCL) und dein eigentliches programm verpackst du.
Dann kannst dus einfach an die erste EXE hinhängen (wie wir ja alle wissen, du kannst einfach beliebige daten hinten anne exe reinhängen solang der eigentliche teil vom programm unverändert bleibt) und die kleine non-vcl exe hat die aufgabe dein programm zu entpacken und dann erst ausführen dann sollts auch wenigstens bissle kleiner sein.

Und wo ist der Unterschied zu UPX? :gruebel:
Aber noch alternativer könnte man es so machen:
.NET: WinForms benutzen, wie man das normalerweise macht.
Win32: Die Routinen benutzen, die Windows dir gibt.
In beiden Fällen ist alles, was benötigt wird, schon auf dem Zielsystem installiert, oder es ist mächtig was schief gegangen :mrgreen:

[edosoft]

mir ist nochmal ne geile idee eingefallen:
ein "prelauncher", eventuell auch so dass er die exe mit reinpackt nur mit dem unterschied:
das erste programm enthält zwar ein fensterle das müsste man mit der winapi machen :-( und das 2. programm mit vcl und die vcl extern verlinken.

das 2. programm dann eventuell auch unverschlüsselt in das erste rein dann wirds wohl trotzdem net so groß, ohne vcl.

und das 1. programm prüft jetzt beim starten ob die vcl-datei da ist wenn nicht kommt so ein datei runterladen fensterle wo er die vcl irgendwo(von deinem server oder so) runterlädet und installiert und dann erst das 2. programm startet.

-Dominik

[tommie-lie]

Zitat:

Zitat von edosoft

mir ist nochmal ne geile idee eingefallen:
ein "prelauncher", eventuell auch so dass er die exe mit reinpackt nur mit dem unterschied:
das erste programm enthält zwar ein fensterle das müsste man mit der winapi machen :-( und das 2. programm mit vcl und die vcl extern verlinken.

das 2. programm dann eventuell auch unverschlüsselt in das erste rein dann wirds wohl trotzdem net so groß, ohne vcl.

und das 1. programm prüft jetzt beim starten ob die vcl-datei da ist wenn nicht kommt so ein datei runterladen fensterle wo er die vcl irgendwo(von deinem server oder so) runterlädet und installiert und dann erst das 2. programm startet.

Und wo ist jetzt der Unterschied zu jedem beliebigen setuptool, das das Nachladen von Paketen erlaubt (kann MSI das? Rooobeeeert?!?)? :gruebel: