UPX-Packer ja oder nein?

[nahpets]

Danke.

Kenn' ich auch nicht anders.

[EWeiss]

Zitat von nahpets:

Danke.

Kenn' ich auch nicht anders.

Jo wie ich sagte Mundpropaganda ist geduldig.. erzählen kann man viel.
Die Fakten hingegen sagen etwas anderes.
Und ja wir leben in einer verschwenderischen Zeit.

gruss

[hoika]

Haloo,
lade die komprimierte Exe doch mal auf Virustotal.com hoch.

[a.def]

Zitat von nahpets:

Danke.

Kenn' ich auch nicht anders.

Mein Test zeigt

ungepackt
- Abeitsspeicher: 14,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

gepackt
- Abeitsspeicher: 23,1 MB
- E/A-Bytes (Lesen): 408.XXX
- E/A-Bytes (Schreiben): 114.XXX

[bra]

Ich habe das mal mit unserer Anwendung getestet und da ist der Unterschied deutlich zu sehen:


Ungepackt (exe 47 MB)
Max. Arbeitssatz (Speicher): 104.468K
Arbeitsspeicher (privater Arbeitssatz): 61.520K

Mit UPX gepackt (exe 18 MB)
Max. Arbeitssatz (Speicher): 137.900K
Arbeitsspeicher (privater Arbeitssatz): : 107.880K

[a.def]

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

[nahpets]

Interessant, da scheint es ja dann auch Abhängigkeiten von Programm zu Programm geben.

Bei meinen Programmen ist mir sowas bisher noch nicht aufgefallen, allerdings nutze ich UPX auch nicht mehr wirklich.

Es war interessant, als USB-Sticks noch nicht im GB-Bereich waren und vor allem zu Zeiten, als Disketten durchaus noch ein üblicher Datenträger für Rettungssysteme waren.

Aber das passt dann wohl doch besser zu diesem Thema: http://www.delphipraxis.net/192506-m...wird-wenn.html

[Uwe Raabe]

Zitat von a.def:

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

Diese Frage bei StackOverflow gibt, trotz immer noch fehlender Antworten, einen Einblick in die dahinter steckende Komplexität: Size of exe file vs available memory

Demnach müsste der Effekt z.B. schon unterschiedlich sein, je nachdem ob Debug-Info in der EXE enthalten ist oder nicht.

[himitsu]

EXE/DLL/BPL sind standardmäßig als MMF mit CopyOnWrite in den Arbeitsspeicher gemapt. (jede der benötigten PE-Sectionen hintereinander)

Sie können also ausgelagert werden und belegen im Prozess nur den virtuellen Speicher, aber im realen Speicher sind sie vernachlässigbar.
Erst wenn ein Prozess an den gemapten Daten im RAM was ändert, bekommt er für jeweils den umgebenen 4KB-Block eine eigene Kopie.

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.
Stell dir mal vor jeder der 10000 aktiven Prozesse müsste seine eigenen Kopieen der System-DLLs in den Speicher laden.
Bei nur 1000 Prozessen wären das alleine 1,5 GB für die ntdll.dll .

[jaenicke]

Zitat von himitsu:

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.

Und wenn die Exe bzw. DLL nicht mit UPX gepackt ist. Ansonsten würde jedesmal ein neuer Speicherbereich reserviert werden...