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

[Olli]

Da ja immer wieder versucht wird Leuten zu erklären wieso PE-Packer sehr fragwürdig sind, habe ich mich dazu entschlossen dies mal in anschauliche Form zu bringen. In dieser kurzen Abhandlung wird PE und EXE synonym verwendet. Es basiert auf einem fiktiven Beispiel um anhand von jeweiligen Rechnungen des Speicherverbrauchs vor der Ausführung der eigentlichen Datei (oder im gepackten Fall, Ursprungsdatei) die Nachteile zu verdeutlichen. Es ist völlig egal ob hier EXE-Packer oder EXe-Crypter besprochen werden, sie nehmen sich nichts!

Betrachtung für EXEs (PE)

Nehmen wir mal folgendes Szenario an. Wir haben eine 1 MB große EXE-Datei. Wir betrachten nur die Datei und nicht den Speicher, den der Prozess (im gepackten Fall, nach dem Entpacken) belegt!

Die Datei liegt einmal gepackt (0,3 MB) und einmal ungepackt (1 MB) vor. Nun wird sie vom PE-Loader jeweils einmal geladen.

Die ungepackte EXE enthält Segmente, die der PE-Loader ignoriert und nicht in den RAM lädt, sondern auf der Platte beläßt. Also lädt der PE-Loader 0,2 MB weniger -> das lauffähige Image der EXE im Speicher ist also 0,8 MB groß.

Nun die gepackte EXE. Da wir alles vor dem Entpacken besprechen, bitte ich zu beachten, daß sich die Allozierung im folgenden eben darauf bezieht!!! Die gepackte EXE wird also vom PE-Loader geladen. Da der Packer alles bestens ausnutzt, wird die EXE komplett in den Speicher geladen -> 0,3 MB.
Danach beginnt der enthaltene Entpacker Speicher in Größer der ursprünglichen Datei zu allozieren und die ursprüngliche EXE im Speicher dorthin zu entpacken -> 1 MB.
Macht summa summarum 1,3 MB.

Vergleich in meinem Beispiel -> 0,8 MB vs. 1,3 MB.

Wenn man das jetzt auf andere Dateigrößen hochrechnet wird's böse ...

Ich hoffe der Unterschied wird nun etwas deutlicher. Bei EXE-Cryptern ist es analog!!!

Betrachtung für DLLs

Und jetzt besprechen wir das Ganze nochmal für DLLs. Eine DLL ist immer eine Datei, deren Code im Kontext von einem Prozess ausgeführt wird. Nun ist es gerade so, daß sich unter NT alle Prozesse dieselbe Kopie einer DLL teilen, es sei denn, ein Prozess verändert Speicherseiten innerhalb dieser DLL (also innerhalb des gemappten Images). In diesem Fall (Copy-on-Write) wird die entsprechende Speicherseite für den entsprechenden Prozess kopiert und sie gehört nur ihm (er teilt sie sich also nicht mit anderen Prozessen!).

Wenn wir also einen Prozeß haben, der eine 0,5 MB große DLL benutzt, wird die DLL (xyz.dll) im schlechtesten Fall 0,5 MB Speicherplatz belegen. Wenn wir einhundert Prozesse haben, die die xyz.dll benutzen, wird der Speicherverbrauch im besten Fall bei 0,5 MB liegen (wenn man mal nur die DLL betrachtet!!!), statt bei 100 * 0,5 MB. Sollte verständlich und klar sein.
Fazit: summa summarum 0,5 MB

Nun ist es aber so, daß die DLL-Entpackroutine (analog zu der im oben besprochenen Fall einer EXE) Speicher (innerhalb des Prozesses - also unabhängig vom gemappten Image) reserviert um dorthin die DLL zu entpacken. Soweit so gut. Nun nehmen wir einmal an, ein beliebiger Packer hätte uns unsere xyz.dll auf 0,2 MB geschrumpft. Aufgrunddessen, daß Entpacker meist selbstmodifizierenden Code benutzen, ist es normal anzunehmen, daß die kompletten 0,2 MB im jeweiligen Prozess beschrieben werden und so ebenfalls pro Prozess benutzt werden. Aber lassen wir diese Betrachtung erstmal außen vor. Nehmen wir also an, daß geladene Image in der Größe von 0,2 MB wird in allen Prozessen gleichermaßen benutzt (also ohne Dopplungen), dann tut sich nun aber folgendes Problem auf.
Der Entpacker alloziert wie gesagt Speicher um das Orginal-Image in den Speicher zu entpacken. Dies geschieht auf einer Pro-Prozeß-Basis. Dieses entpackte Image teilen sich also nciht X Prozesse, sondern jeder der X Prozesse kommt hat seine eigene Kopie davon. Rechnen wir das mit unseren 100 Prozessen, welche die gepackte DLL xyz.dll benutzen also nochmal nach:
Gepacktes Image einmalig + Entpacktes Image Xmal
Macht summa summarum 50,2MB!

Ich hoffe, daß durch diesen Riesenunterschied noch deutlicher wird, wo's hakt. Das heißt, während man sich bei EXE-Dateien "nur" drauf einläßt einen jeweils an Größe der Datei und Packrate festzumachenden Nachteil zu bekommen, wird der Nachteil bei DLLs unermeßlich groß!

[edit=alcaeus]Titel auf Wunsch von Olli angepasst: "sinnlos" in "sehr fragwürdig" geaendert, um "eine Debatte um Worthülsen" (Zitat Olli) zu vermeiden. Mfg, alcaeus[/edit]

[bigg]

Welch einseitige Begründung. :roll:

Hast du auch mal Zeitmessungen durchgeführt, in wie weit Prozesse schneller geladen werden?
Festplattenzugriffe werden verkürzt.

PS: Das komprimierte Dateien mehr Speicher belegen ist nicht neu,
das ist ein Laster der Kompression.

[Olli]

Zitat:

Zitat von bigg

Welch einseitige Begründung. :roll:

"*plonk*"?

Zitat:

Zitat von bigg

Hast du auch mal Zeitmessungen durchgeführt, in wie weit Prozesse schneller geladen werden?
Festplattenzugriffe werden verkürzt.

Nein habe ich nicht. Die kannst du dann gern per NTFS-Komprimierung minimieren, deine Festplattenzugriffe. Die Nachteile sind eindeutig.

[marabu]

Hi Olli,

deine Darstellung des Sachverhaltes halte ich für didaktisch gelungen, aber

Zitat:

Zitat von Olli

Die kannst du dann gern per NTFS-Komprimierung minimieren, deine Festplattenzugriffe. Die Nachteile sind eindeutig.

das steht jetzt so eng beieinander... Ich erwarte eigentlich, dass die Nutzung eines compressed file system nicht auf die von dir beschriebene Prozessebene durchschlägt - oder liege ich da falsch?

Grüße vom marabu

[bigg]

Zitat:

Welch einseitige Begründung.

Ironie!

[Olli]

Zitat:

Zitat von bigg

Zitat:

Welch einseitige Begründung.

Ironie!

Nächstes Mal bitte markieren :mrgreen: ...

Zitat:

Zitat von marabu

das steht jetzt so eng beieinander... Ich erwarte eigentlich, dass die Nutzung eines compressed file system nicht auf die von dir beschriebene Prozessebene durchschlägt - oder liege ich da falsch?

Naja, ich ging davon aus, daß bigg von den Plattenzugriffen spricht, weil diese um Größenordnungen langsamer sind als Speicherzugriff oder gar CPU-Speicher-Transfers. In diesem Sinne hat auch bei komprimierten NTFS-Dateien die Festplatte weniger zu lesen und es wird schneller. Übrigens etwas, das Robert immer wieder anspricht.

Will heißen, unsere gepackte EXE aus dem Beispiel oben, mit 0,3 MB, wird (wahrscheinlich) viel schneller von Platte gelesen und entpackt (zusammen betrachten!!!) als die gleiche ungepackte EXE aus einer unkomprimierten Datei (Entpacken im Speicher fällt weg) oder auch die gleiche ungepackte EXE aus einer komprimierten Datei (zB 0,5 MB - NTFS-Kompression ist nicht perfekt ...) - dann aber auch ohne Entpacken im Speicher.

[Pr0g]

Was aber ist, wenn es nicht auf den Speicherverbrauch ankommt, sondern nur auf die Größe der Exe (wofür die Packer ja da sind) und das Programm eh nur in einer Instanz läuft. Bei den Dlls das gleiche. Wenn ich sie nur für mein Programm brauche, welches nur einmal gestartet wird, dann nützt mir die Optimierung seitens des Systems nicht viel, dass sich Prozesse die Kopie im Speicher teilen.

MfG Pr0g

[Olli]

Zitat:

Zitat von Pr0g

Was aber ist, wenn es nicht auf den Speicherverbrauch ankommt,

Die Betrachtung leistest du dir auch nur, weil du im Usermode programmierst. Die Sichtweise könnte sich (dramatisch) ändern, wenn du auch Kernelmode-Sachen schreiben würdest. Aber das ist eine andere Geschichte.
Woher nun plötzlich diese Großzügigkeit in Sachen RAM rührt, bleibt mir auch ein Rätsel. Schließlich sind RAM-Riegel pro MB noch um ein Vielfaches teurer als Festplattenplatz. Schon von daher rechnet es sich wirtschaftlich nicht einen EXE-Packer einzusetzen! Laß es mal von deinem Lieblingsökonomen durchrechnen.

Zitat:

Zitat von Pr0g

sondern nur auf die Größe der Exe (wofür die Packer ja da sind)

Packer <> EXE-Packer

Zitat:

Zitat von Pr0g

und das Programm eh nur in einer Instanz läuft. Bei den Dlls das gleiche. Wenn ich sie nur für mein Programm brauche, welches nur einmal gestartet wird, dann nützt mir die Optimierung seitens des Systems nicht viel, dass sich Prozesse die Kopie im Speicher teilen.

Das ist richtig, dennoch läufst du auch in diesem Falle suboptimal, bis schlecht. Denn wenn wir obiges Beispiel mal annehmen, selbst wenn der PE-Loader die 1-MB-EXE komplett lädt, fährst du mit der gepackten schlechter. Sowohl in Hinsicht auf Speicher als auch auf CPU-Zeit (zum Entpacken bspw.).

Nachtrag:
Und nochmal auf den ökonomischen Nerv: wenn ich eine EXE und die DLLs transportiere (gepackt mit einem normalen Dateipacker), so habe ich den Nachteil (CPU-Last, RAM-Last) nur 2mal (Packen und Entpacken) - um den Vorteil eines kostengünstigen weil kleinen Transports. Wenn ich nun die Dateien mit einem PE-Packer gepackt habe, habe ich den Nachteil bei jedem Mal!

[jfheins]

Ich möchte hier trotz der CodeLib-Sparte meine Meinung sagen, und zwar ist die Nutzung von Exe-Packern für Exen durchaus von Vorteil.

Olli, du als ISDN-Nutzer kannst es dir sicher vorstellen:

Ohne Exe-Packer:
Du ziehst dir ein 4 MB Programm aus dem Netz und führst es aus, vielleicht werden dann auch nur 3 MB geladen.

Mit:
Du ziehst dir 1 MB, und dafür wird 0,2% des Arbeitsspeichers mit dem Exe-Packer "zugemüllt" und ausserdem 1 MB zuviel entpackt. Es werden im Endeffekt vielleicht 0,4% des Arbeitsspeichers unnötig verbraucht - ein verschwindend geringer Nachteil im Vergleich zur Dateigröße.

(Gerechnet mit 500 MB RAM und ohne Auslagerungsdatei)

Und für dlls, die nur von einem Programm (oder 2) verwendet werden, halte ich dieses Verfahren ebenfalls für annehmbar.

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. :oops: ;) Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

Test:

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

ohne Sfx o.ä

Ich bin übrigens DSL Nutzer ;-)

[Dax]

Wenn man aber eine Selbstextrahierende Archivdatei erstellt, die für das gegebene Programm die beste Kompressionsrate hat, oder besser: gleich einen Installer, ist der Vorteil PE-Packer effektiv nullifiziert ;)

[Phoenix]

Also als Sinnlos würde ich die echt nicht bezeichnen.

Beispiel: Eine .exe liegt (komprimiert) auf einem Fileserver für den zentralen Zugriff für Clients in der Größenordnung von mindestens 50 Stück.

Das macht in Deinem Beispiel morgens früh wenn alle darauf zugreifen 50 * 0,7 MB = 35 Mb Netzwerkverkehr weniger. In unserer damaligen Produktivumgebung beim Kunden war die unkrompimierte .exe allerdings knapp 20 MB gross und die gepackte nur 4,5. Ergo: 775 MB weniger Daten zu schaufeln. Das macht morgens früh schon einiges aus - zumal ja auch noch anderer Netzwerkverkehr wie Datenbankzugriffe etc. pp. dort laufen.

Im übrigen war die komprimierung der .exen zwingend notwendig. Dank des bescheidenen opportunistic locking des Windows NT 4 Servers kam es bei mehrfachen zeitgleichen Zugriffen auf eine Datei unter Umständen dazu, das die Datei sogar für weitere lesezugriffe gesperrt wurde, weswegen dann viele Clients morgens auf das Timeout warten mussten um eine Fehlermeldung zu erhalten und es dann nochmal probieren durften.

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Ich gebe zu dies ist kein Fall der bei jedem alltäglich vorkommt. Aber es gibt eben auch für Exe-Packer Anwendungsbereiche die deutlichst Sinn machen.

[bigg]

durchschn. Zugriffszeit eines Speicherriegels: 1,6 - 60 ns
durchschn. Zugriffszeit einer Festplatte: 3 - 12 ms


Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version? :gruebel:



@olli:
Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

[Olli]

Zitat:

Zitat von jfheins

Olli, du als ISDN-Nutzer kannst es dir sicher vorstellen:

56k-Modem. ISDN kommt frühestens im September (Danke T-Com!) und auch dann laufe ich weiterhin mit dem Analogmodem.

Zitat:

Zitat von jfheins

Ohne Exe-Packer:
Du ziehst dir ein 4 MB Programm aus dem Netz und führst es aus, vielleicht werden dann auch nur 3 MB geladen.

Mit:
Du ziehst dir 1 MB, und dafür wird 0,2% des Arbeitsspeichers mit dem Exe-Packer "zugemüllt" und ausserdem 1 MB zuviel entpackt.

Im Vergleich sind es 2 MB zuviel.

1. 4 MB, davon 3 geladen ... und ungepackt -> 3 MB
2. 1 MB + 4 MB vom Entpacken -> 5 MB

Zitat:

Zitat von jfheins

Es werden im Endeffekt vielleicht 0,4% des Arbeitsspeichers unnötig verbraucht - ein verschwindend geringer Nachteil im Vergleich zur Dateigröße.

Das muß jeder für sich entscheiden, ob das für ihn viel ist. IMO ist es das. Da beipielsweise eine VM im Gegensatz zu einem normalen Programm echten Speicher (weil im K-Mode) anfordert, ist jedes MB für mich wichtig. Da kann ich mir nicht einfach 2 MB leisten, die einfach verschwendet werden. Abgesehen davon halte ich Leute, die ihre Programme ungepackt ins Netz stellen (ob nun als Installer oder als RAR, 7Z, ZIP, GZ oder sonstwas gepackt ... mach keinen Unterschied) für doof. Also lade ich deren Programme nicht runter. Und wenn dein EXE-Packer die 5-MB-EXE auf 1 MB schrumpft, schafft der 7z-Packer zB 0,7 oder noch weniger. Also habe ich wieder alle Vorteile und keinen Nachteil (außer dem einmaligen Entpacken).

Zitat:

Zitat von jfheins

Und für dlls, die nur von einem Programm (oder 2) verwendet werden, halte ich dieses Verfahren ebenfalls für annehmbar.

Ich stelle mir gerade vor, wie aussähst, wenn die Toolbar-Hersteller genauso dächten (angenommen du arbeitest mit dem IE). Dort laufen nämlich oft mehrere Instanzen ... und bei COM-Objekten in gepackten DLLs nimmt das Chaos seinen Lauf. :lol:

Zitat:

Zitat von jfheins

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. ;) Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

Das das klassische ZIP nicht mehr auf der Höhe der Zeit ist, mag sein. Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

[phXql]

Zitat:

Zitat von jfheins

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. ;) Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

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

abgesehen davon versagt mein UPX irgendwie bei .NET-Assemblies ;)

[jfheins]

Zitat:

Zitat von Oliver

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat:

Zitat von phXql

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

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ... :oops:

[Olli]

@Phoenix: Ungepackter Transfer übers Netz und schlechte Fileserver würde ich ungern als Argument für eine Sache gelten lassen, welche permanent einen Nachteil bringt. Hier könnte allein ein transparentes Kompressionsverfahren während der Übertragung Abhilfe schaffen.

Zitat:

Zitat von Phoenix

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Jupp.

Zitat:

Zitat von Phoenix

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Spätestens bei DLLs sind sie sinnlos.

Zitat:

Zitat von bigg

Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version? :gruebel:

Dank fehlenden Nachteils dürfte NTFS-Komprimierung hier schneller und besser sein als ungepackt.

Zitat:

Zitat von bigg

Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

Nein ... ich weiß aber auch nicht so recht, wie du auf die Idee kommst verlustbehaftete Kompressionsverfahren mit einem EXE-Packer zu vergleichen. Nur weil eine BMP RLE-kodiert ist, ist sie ja nicht gleich schlecht. Aber bei RLE, oder auch NTFS-Kompression sind Kompressionsrate und CPU-Last gut ausbalanciert.

Ach übrigens, wenn dank der Speicherverschwendung mit EXE-Packern das Speicherauslagern beginnt, dann hat euch das System aber einen Strich durch eure 12ns-Rechnung gemacht!

[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.

[Robert_G]

Zitat:

Zitat von Phoenix

die unkrompimierte .exe allerdings knapp 20 MB gross

20MB? :shock:
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... ;)

[phXql]

Zitat:

Zitat von jfheins

Zitat:

Zitat von Oliver

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat:

Zitat von phXql

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

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ... :oops:

wenn du ein SFX-Archiv machst, dann können sie doch von jedem geöffnet werden...

[Olli]

Zitat:

Zitat von bigg

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

:shock: was für ein Quatsch.

Abgesehen davon, daß ich "--force" benutzen mußte um UPX überhaupt zu überzeugen, komme ich bei UPX und WinDirStat 1.1.2 (Unicode) einer normalen Allerweltsanwendung auf einen Unterschied von etwa 270kB!

Zitat:

Zitat von bigg

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

Und das auch nur einmal nach dem Transport.

@phXql: Das war ja gerade die Anforderung ;)

[phXql]

Zitat:

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:

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:

Zitat von Olli

@phXql: Das war ja gerade die Anforderung ;)

jetz bin ich verwirrt ;)

[Olli]

Zitat:

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:

Zitat von Robert_G

Zitat:

Zitat von Phoenix

die unkrompimierte .exe allerdings knapp 20 MB gross

20MB? :shock:
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:

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:

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:

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:

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 :mrgreen: ... und entfernt sie für dich auf Nimmerwiedersehen (Vgl. verlustbehaftete Kompression :lol: ).

/Edit:/ falsch zitiert, danke Julius!

[TeronG]

Zitat:

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 :gruebel:

[DP-Maintenance]

Dieses Thema wurde von "Chakotay1308" von "Neuen Beitrag zur Code-Library hinzufügen" nach "Tutorials und Kurse" verschoben.
Verzeih mir, Olli, ist aber eher ein Tutorial. :zwinker:

[mh166]

Zitat:

Zitat von TeronG

Zitat:

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 :gruebel:

[Robert_G]

Was willst du uns mit diesem Quote sagen? :gruebel:

[barf00s]

ich bin auf olli's seite -.-°

[brechi]

der Titel ist bisschen fürn arsch ;P

PE-Packer haben den zweck die Datei zu verkleinern -> das gelingt denen auch also sind sie nicht "sinnlos".
Hattest das besser nennen sollen "schlechte Eigenschaften von PE-Packern".

Ansonsten kannste auch schreiben "Warum sind PE-Crypter sinnlos". Fürs Speichermanagement vielleicht, aber der "Sinn" liegt halt im verschlüsseln.

Von daher is der Thread "sinnlos", da durch die Argumentationen nicht unterlegt werden kann das Packer Sinnlos sind.
:wink:

Edit:
Ich weiß nicht ob ihr euch UPX angeschaut habt, aber der komprimiert verlusstfrei d.h. nachm entpacken mit upx.exe -d <name.exe>
ist es wieder genau die selbe Ausgangsdatei.

[Pr0g]

Zitat:

Zitat von brechi

Ich weiß nicht ob ihr euch UPX angeschaut habt, aber der komprimiert verlusstfrei d.h. nachm entpacken mit upx.exe -d <name.exe>
ist es wieder genau die selbe Ausgangsdatei.

Wäre ja wohl auch schlimm, wenns nicht so wäre :lol:

[Olli]

Zitat:

Zitat von brechi

PE-Packer haben den zweck die Datei zu verkleinern -> das gelingt denen auch also sind sie nicht "sinnlos".

Der Unterschied zwischen Sinn und Zweck sind dir schon geläufig, oder?

Sie sind durchaus nicht zwecklos, aber schon sinnlos.

Den Rest kommentiere ich nicht weiter.

[mschaefer]

Moin, Spitze! Klasse!

Mir hat man mal beigebracht zielorientiert zu arbeiten, aber das heiligt letztlich auch nur einem Zweck. Jetzt kommt die Philosophie ins Spiel. Olli wenn Generationen von Philosophen nach dem Sinn des Lebens suchen, dann wird es fast unmöglich sein den Sinn in einem Computerprogramm zu finden, aber auch schwer den Sinn in diesem Thread. Stimme Dir voll zu, das es wohl besser ist nach dem Zweck zu suchen. Nun gut ich werde mich hier zurückhalten, aber bin gespannt wie das weiterläuft.

Die Suche nach dem Sinn und der Wahrheit werden uns noch lange beschäftigen...42...das wird ein langer Thread...

Grüße // Martin

[Kedariodakon]

Was sind schon 0,5 MB Ram bei einer kleinen Anwendung, wenn man 2GB davon hat? :gruebel:

Wir sind nicht mehr im Zeitalter man nur 1 MB Ram hatte...

Bye

[Olli]

Zitat:

Zitat von mschaefer

Jetzt kommt die Philosophie ins Spiel. Olli wenn Generationen von Philosophen nach dem Sinn des Lebens suchen, dann wird es fast unmöglich sein den Sinn in einem Computerprogramm zu finden, aber auch schwer den Sinn in diesem Thread. Stimme Dir voll zu, das es wohl besser ist nach dem Zweck zu suchen.

Ich gestehe, daß man es auch auf eine "Glaubensfrage" herunterbrechen kann. Aber wie oben erwähnt, würde wohl so ziemlich jeder Ökonom bei den Preisverhältnissen auf eine Lösung ohne EXE-Packer setzen! RAM und CPU sind beispielsweise bei Servern viel zu wertvoll.

Zitat:

Zitat von mschaefer

Die Suche nach dem Sinn und der Wahrheit werden uns noch lange beschäftigen...42...das wird ein langer Thread...

*g* wir sind erst bei 39 :lol:

@Christian: Aua!

Danke an Alcaeus, der so freundlich war den Titel anzupassen, damit ihr euch nicht dran aufhängt ...

[mschaefer]

Hallo Olli,

eins muß man Dir lassen Du bist beharrlich, eine Eigenschaft die man bei größeren EDV-Projekten braucht, sonst steht man diese nicht durch. Werde hier jetzt nicht in eine größere Diskussion mit einsteigen, aber da Du den Ökonomen ansprichst habe ich doch noch etwas für Dich. Also Ökonomen sind wunderliche Menschen, die beschäftigen sich mit Chaosthoerie, Effizienzanalysen, Spieletheorie und zum Beispiel Monte-Carlo-Methoden. Für was sich solch ein Kandidat entscheiden würde ist zunächst unklar.
Aber die Ökonomie hat ein Verfahren für die Messung von Nutzen ( ein anderes Wort für Zweckdienlichkeit), die Nutzwertanalyse:

Das kann hier helfen, ist übrigens nichts abgehobenes, sondern eine Art Punktesystem unter Berücksichtigung verschiedener Ziele.
Man kennt sowas von Testberichten bei der Stiftung-Warentest, oder trivial auch in Notensystemen. Auf der einen Seite baut man seine Ziele auf, auf der anderen seine Umweltumgebungen/technische Voraussetzungen. Und jetzt kommt das letztlich auch etwas willkürliche: Die Vergabe der Noten in den Schnittpunkten.

10-upx geeignet und sinnvoll bis hinunter zu 1- upx völlig ungeeignet und nicht sinnvoll

········································· UPX auf Server·····UPX·Profikundenpc·····UPX·Gelgenheitsan wender-PC·····
·················································· ·················································· ····························
Ziel·1: Ramoptimierung·····························01····· ··············01·························01······· ························
Ziel·2: HD-Platzoptimierung············ ·········02···················04·················· ·······06································
Ziel·5: Platzoptimierung Agabemedium··· ·00···················04·························0 6································
Ziel·6: einfache Userhandhabung········ ····00···················04······················· ··08································
Ziel·7·Virenfreiheit······························ ·······00···················01···················· ·····01································
--------------------------------------------------------------------------------------------------------------------------------
Summe············································· ·····03···················14······················ ··22·······························

Das ist nun nich die heilige Kuh, aber es macht den Entscheidungs- und Gedankenweg nachvollziehbar und zeigt Deinen Wertmaßstab.
Das Ergebnis, die Zahlen kann ja jeder für sich mal setzten, wäre hier: Finger weg von UPX auf dem Server, etwas undefiniert für den Profianwender und der Kandidat der ehedem unerfahren ist mit Packprogrammen (gibt es!) eine kleine Festplatte hat und kaum
Programme gleichzeitig nutzt, einen hohen Nutzen.

PS: Jetzt ist der Titel übrigens sehr gut gewählt den fraglich, also zu hinterfragen, ist die Benutzung von UPX allemal...


Viele Grüße und einen schönen Abend // Martin