Warum PE-Packer sehr fragwürdig sind ...

[phXql]

Zitat von bigg:

Zitat:

dann nimm 7z und mach ein SFX-Archiv draus...

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

PS: 7Zip benötigt min. 36 MB zum Entpacken bei höchster Stufe.

hab ich. 7z is um 24 KB kleiner, bei einer EXE-Größe von 1,32 MB. Wenn dus nich glaubst, dann kann ich die beiden Dateien gerne hochladen.

und wegen speicherverbrauch: das bei 7z is einmalig, bei den PE-Packern nicht!

[jfheins]

Zitat von bigg:

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

Ich habe menen Test jetzt noch auf 7ZIP erweitert:

Test:

Orginal: 3,38 MB
ZIP: 1,07 MB
UPX: 977 KB
ACE: 934 KB
RAR: 930 KB
7ZIP: 819 KB

ohne Sfx o.ä

Als Testobjekt diente Webweaver.exe in Version 1.68

[phXql]

Zitat von Olli:

@phXql: Das war ja gerade die Anforderung

jetz bin ich verwirrt

[Olli]

Zitat von phXql:

jetz bin ich verwirrt

Es war als Zustimmung gedacht. Denn oben wurde ja gesagt, daß man keine (normalen) Packer benutzen könne, weil die nicht jeder auf seinem System hat.

Nachtrag: @bigg: Ich weiß nicht, woher du die Zahl mit 36 MB nimmst, aber in der höchsten Stufe ist es bei mir nicht mehr ausführbar. Es wird deutlich die Größe des vorhandenen Speichers + Swap überschritten. Also höchste Stufe bei Dictionary und Kompression auf Ultra.

[bigg]

Okay, ich habe es selbst getestet und komme zu den gleichen Ergebnissen.
Allerdings fehlt dort der Entpacker und man benötigt nun 34 MB um die Daten wieder entpacken zu können.

/edit:
Bild angehängt.

[jfheins]

Ich könnte jetzt ja mal versuchen, aus diesem kontroversen Thema eine Bilanz zu ziehen ... Also:

PE-Packer, wie z.B. UPX, sind sinvoll, wenn man Exe-Dateien oder einfach benutzte dlls mit einer für den Endanwender einfachen Methode komprimieren möchte.
Sie sind nicht sinnvoll, wenn es auf maximale Kompression ankommt, oder auf einen geringen ständigen Speicherverbrauch der Anwendung. Weiterhin sind sie für mehrmals genutzte dlls ineffizient, da dann die dll jedesmal erneut geladen wird, und somit der Speicherverbrauch mit zunehmender Nutzung im Gegensatz zu einer unkomprimierten dll wächst.

einfach benutzte dlls = dlls, die nur von einem Prozess genutzt werden.

Richtig ? Noch Einwände ?

[Phoenix]

Zitat von Robert_G:

Zitat von Phoenix:

die unkrompimierte .exe allerdings knapp 20 MB gross

20MB?
Wäre es nicht schon 18MB früher an der Zeit gewesen, alles mögleich an Klassen in Packages auszulagern?
So hätten morgens nur Packages mit neuerer Revision gesaugt werden müssen... (Welches sich wohl meistens auf 0MB oder ein paar KB belaufen hätte...)
Kann ich irgendwie nicht als Vorteil von ExePackern sehen, eher als ineffiziente Herangehensweise...

Das war aus diversen Gründen nicht möglich und auch nicht gewollt.

Das Hauptproblem war, das einige Anwendungen mit der zum Teil gleichen Codebasis nicht den gleichen Releasezyklus haben / hatten als andere. Will heissen Anwendung 1 hätte Package A in Version 2.0 gebraucht, Anwendung 2 hätte Package A aber (weil noch nicht neu released) noch in Version 1.9 benötigt.

Und dann verwalte mal 8 - 12 Anwendungen die ggf. verschiedene Package-Versionen benötigen sinnvoll und effizient in einem Kundensystem. - Ohne das Pro Anwendung wieder alle Packages im Anwendungsverzeichnis liegen und die somit zig mal dort liegen würden. Und dann lass bei einem Update denjenigen der das zusammenstellt mal ein Package in der neuen Version vergessen. Und dann Suche diesen Fehler mal...

Zudem hatte ich keinen Einfluss auf die Handhabung der Versionen, ich musste mich nur mit der Problematik des lockings beschäftigen das einen Kunden zeitweise unproduktiv gehalten hat. Ich hätte da einiges geändert... aber ich war ja 'nur' BA-Student und hatte ja keine Ahnung... :-/

Aber back to topic:

Olli: Stimmt, wenn das System das Swappen anfängt ist eh alles zu spät.

Zur Sache mit der Transfermenge im Internet: UPX komprimiert .exen einfach genial klein. Ich kenne spontan keinen Packer der eine ähnliche Rate erzielt.

Allerdings lassen sich UPX'te exen aber auch wieder entpacken. Von daher kann man UPX als einen Download-Verkleinerer durchaus sinnvoll nutzen - sofern es nur um die reine .exe geht die Übertragen werden muss. Hinterher wieder entpacken und man hat den Memory-Overhead beim ausführen auch nicht mehr.

[Olli]

Zitat von jfheins:

Richtig ? Noch Einwände ?

Statt "sinnvoll" würde ich "vertretbar" sagen, aber ansonsten durchaus. Wobei man sich fragen sollte, welche DLL existert denn um nur in einen Prozess geladen zu werden? Ab 2 Instanzen des gleichen Programms wird's nämlich schon wieder unschön.

Zitat von Phoenix:

Olli: Stimmt, wenn das System das Swappen anfängt ist eh alles zu spät.

Wenn ein Server richtig skaliert ist, läuft er aber oft unter Volllast (sowohl Speicher als auch CPU). Daher meine Einwände. Denn auch die niedlichen kleinen Utilities werden auf Servern manchmal genutzt.

Zitat von Phoenix:

Zur Sache mit der Transfermenge im Internet: UPX komprimiert .exen einfach genial klein. Ich kenne spontan keinen Packer der eine ähnliche Rate erzielt.

...keinen ähnlichen Executable-Packer? Ansonsten wüßte ich eine Menge

Zitat von Phoenix:

Allerdings lassen sich UPX'te exen aber auch wieder entpacken. Von daher kann man UPX als einen Download-Verkleinerer durchaus sinnvoll nutzen - sofern es nur um die reine .exe geht die Übertragen werden muss. Hinterher wieder entpacken und man hat den Memory-Overhead beim ausführen auch nicht mehr.

So gesehen hast du recht. Aber sei dir bewußt, daß die wiederhergestellte EXE nicht identisch ist mit der vorher. UPX legt nämlich fest, daß bestimmte Sachen "einfach nicht benötigt" werden ... und entfernt sie für dich auf Nimmerwiedersehen (Vgl. verlustbehaftete Kompression ).

/Edit:/ falsch zitiert, danke Julius!

[TeronG]

Zitat von Olli:

Woher nun plötzlich diese Großzügigkeit in Sachen RAM rührt, bleibt mir auch ein Rätsel.

Früher: war der Speicher soo klein/knapp, daß z.B. Programmierer von Spielen Programm-Code in Grafiken "versteckt" haben ...

Heute:
aber wenn man "nur" kleine Windows-Tools (für Einzelanwender) macht ist das nicht so wild .. wenn ich aber Größere oder auf kleinenren Systremen Anwendungen schreiben müsste würde ich mir das mit dem Packern lieber genauer anschauen.
Wo investiere ich lieber Recourcen Arbeitsspeicher/CPU-last oder Festplatte/ladezeit .... naja muss wohl jeder für sich entscheiden