UPX-Packer ja oder nein?

[jaenicke]

Zitat von EWeiss:

Nein keine Anwendung von mir verbraucht mehr Speicher als gewöhnlich. (Ungepackt)

bsp.
AnimatePNG benötigt 34MB gepackt und genau so viel wenn sie nicht mit UPX gepackt ist.

Das hat in der Form auch niemand behauptet. Wenn du noch einmal nachliest, wirst du sehen, dass der SpeicherVerbrauch nur dann als höher angegeben ist, wenn du das Programm mehrfach startest, besondere bei Nutzung von DLLs.

Und da kann ich bei mir durchaus feststellen dass der Speicherverbrauch deutlich höher ist. Nicht so viel höher, wie die Größe der Exe oder DLL, aber der Unterschied ist trotzdem deutlich.

[Hobbycoder]

Was dafür spricht ist sicherlich die Größe der Datei hinterher.

Bei einigen Projekten lade ich Dateien direkt bei einem oder mehreren Kunden hoch. Mit D7 war das noch gut machbar. Jetzt bei Berlin sind die Exe-Dateien um einiges gewachsen, was die Uploadzeit doch um einiges verlängert, was nicht sehr schön ist.

Was aber dagegen spricht ist, den Kunden immer wieder erklären zu müssen, dass es sich bei dem Programm nicht um eine Virus handelt und es virenfrei ist. Und bei den vielen verschiedenen Virenscannern kommt man dagegen gar nicht mehr an. Und noch viel schlimmer ist der Imageverlust, den man sich einhandelt, wenn sich herumspricht, dass von xxx virenverseuchte Dateien kommen (auch wenn's dann gar nicht stimmt). Solche Aussagen halten sich hartnackig, und die dann zu widerlegen wird schwer.

[Sherlock]

Man kann die Diskussion ziemlich kurz zur allgemeinen Zufriedenheit auflösen: UPX taugt nicht für kommerzielle Software. Für den Heimgebrauch jedoch ist es eine nette wenn auch nicht mehr allzu sinnvolle Sache.

Wer Platz bei der Auslieferung sparen will, der packt seine Dateien in ein Inno-Setup oder ähnliches. Bei mir ist das Installationspaket (verpackt sind 32-Bit und 64-Bit Exen) kleiner als auch nur eine der ausführbaren Dateien.

Sherlock

[Codehunter]

Also ich habe ein (wenn auch seltenes) Szenario wo UPX durchaus Sinn ergibt:

Einige unserer Business-Programme werden direkt vom Netzlaufwerk gestartet. Filialen hängen per VPN über DSL da drauf. Hier hat es durchaus Vorteile, die Binaries mit UPX zu packen. Es verkürzt die Ladezeiten ungemein.

[bra]

Ich würde auch von UPX abraten. Ich nutze es hier nur, um unseren Installer zu testen, indem ich die Dateien für den Installer vorher komprimiere und die Installerkomprimierung selbst deaktiviere. Damit geht das Erstellen des Installerpakets deutlich schneller. Beim Kunden würde ich aber keine UPX-Dateien ausliefern, weil die immer mal wieder von Virenscannern angemeckert werden.

Den einzigen sinnvollen Nutzen bei halbwegs aktuellen Rechner sehe ich bei dem Szenario von Codehunter, wo ein lahmes Netzwerk entlastet werden soll.

[Uwe Raabe]

Zitat von Codehunter:

Einige unserer Business-Programme werden direkt vom Netzlaufwerk gestartet. Filialen hängen per VPN über DSL da drauf. Hier hat es durchaus Vorteile, die Binaries mit UPX zu packen. Es verkürzt die Ladezeiten ungemein.

Ich kenne auch Fälle, wo dieses Verfahren zur Anwendung kommt (was nicht heißt, das ich das befürworte).

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Alternativ könnte man die EXE auf einen simplen Package-Loader reduzieren, der dynamisch die benötigten Packages lädt (im Extremfall ist das nur eins). Die Packages kann er dann vorher bei Bedarf (wenn es ein neueres gibt) in gepackter Form herunterladen und entpacken. Da in dem Fall nur veränderte Packages gepackt über die Leitung gehen, sollte das potentiell performanter sein. Die System-Packages (RTL, VCL,...) müssen ja nur bei einem Wechsel der Delphi-Version aktualisiert werden.

[Codehunter]

Zitat von Uwe Raabe:

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Letztendlich ist das eine Frage von Aufwand und Nutzen. Unser Virenscanner schlägt bei UPXen jedenfalls nicht an, daher Ruhe zumindest an der Front. Mit einer Umstellung auf Builds mit Runtime-Packages wäre bei vorhandenen Projekten ein größerer Aufriss verbunden, für den es aus Sicht der Entscheider keine schlagenden Argumente gibt. Und vom Anspruch eines eleganten Softwaredesigns musste ich mich schon vor längerer Zeit verabschieden...

[mensch72]

wir verwenden quasi unseren eigenen "Installer", das ist ein einmal mit echtem Zertifikat signiertes Programm, was durch alle Virentests durchgeht und auch im Sicherheitsbereich von Banken&Kraftwerken bisher immer die Freigabe bekam.

Erstaunlicher Weise erben auch ausfürbare Dateien die von diesem Prozess abgepeichert werden oft selbst lokale Rechte, mindestens aber bekommen sie nie das Flag "aus dem Inet oder von Wechselmedium heruntergeladen"... damit können wir z.B. unsere Softwareupdates relativ ungestört realisieren. Nebenbei Packen(zuerst) und verschlüsseln(dannach) wir unsere Distributionen, weil wir es bevorzugen auf allen Kundeninstallation möglichst immer die Komplettsoftware aufzuspielen. Je nach Lizenz lässt sich eben nicht alles entpacken und nutzen, aber wenn es sein muss hat unser Support Remote immer gleich alles per Codeeingabe selbst zur Verfügung (einfach hin kopieren ginge eh nicht, weil der Installer in die Programmfiles an passenden Stellen einen lokalen Systemhash einsetzt)

Standard-RunTime EXE Packer/Entpacker wie Upx nutzen wir nicht. Auf eigene/spezielle Programme, welche direkt selbst nach expand/decrypt dann per WinApi einen Speicherbereicht als "ausführbar" deglarieren und dort was anspringen, reagieren viele Sicherheitstools und Security Verantwortliche sehr allergisch.

[bra]

Zitat von Uwe Raabe:

Hast du mal überlegt, ob man nicht einen kompakten Loader starten kann, der dann die eigentliche Anwendung als zip, 7zip, rar oder sonstwas herunterlädt, entpackt und startet.

Das bringt aber nichts, wenn die Anwendung auch noch DLLs u.ä. aus dem Netzlaufwerk benötigt bzw. nachladen muss. Dann müsste man die ja auch alle mit lokal kopieren.