Komprimierungsprogramm für EXE-Dateien (Projektname: Catjia)

[Little John]

Ah ... danke!
Also das was man bei IncludeBinary angibt, wird nicht als Ressource eingebunden, richtig?

Gruß, Little John

[ts-soft]

> richtig?
richtig!

[Little John]

Ist ja wie beim Chatten hier.

Thorium, bist Du 100% sicher dass Du die Textdatei als Ressource eingebunden hast. Wenn ja, dann hat entweder Petzold einen groben Schnitzer gemacht, oder sich diese Sache in Windows seit 2000 geändert.

Gruß, Little John

[Danilo]

So habs grad nochmal verifiziert, was in dem Buch steht stimmt nicht.

Windows kann doch frei entscheiden was es macht. Hast Du genug
Speicher frei und nur kleine Resourcen in der .exe, lädt es dann halt
komplett. Sind 100MB Resourcen dran und nur noch 50MB frei, dann
kann es das auf der Platte lassen.
Das ist ja die Aufgabe des Betriebssystems, sich um solche Sachen
zu kümmern.
Wenn Du in Deinem Programm 1GB Speicher benutzt, dann können davon
auch Teile auf Disk ausgelagert sein. Wenn Du darauf zugreifst, wird dieser
Teil dann eben geladen und ein anderer Teil ausgelagert.

Das Programm bekommt davon garnichts mit, und es kann ihm auch
egal sein. Wenn man sauber und nach Dokumentation programmiert
hat, funktioniert es immer so wie es sein soll.

[Thorium]

@Danilo, nene. Das ist was anderes. Es kann natürlich sein das die Ressourcen erstmal im Swapfile liegen, bis sie benötigt werden. Damit liegen sie dann zwar im Prozesspeicher aber trotzdem auf der Festplatte allerdings nicht in jedem Fall! Es ist nicht das selbe die Daten auf der Platte zu lassen und später nachzuladen oder sie ins Swap-File zu laden. Die Sache ist die, das bei jemandem der z.b. den virtuellen Speicher deaktiviert hat oder stark begrenzt die Ressourcen dann in den physikalischen Speicher geladen werden. Also bleibt in dem Fall die Aussage falsch das Ressourcen von der Festplatte bei bedarf nachgeladen werden.

Thorium, bist Du 100% sicher dass Du die Textdatei als Ressource eingebunden hast. Wenn ja, dann hat entweder Petzold einen groben Schnitzer gemacht, oder sich diese Sache in Windows seit 2000 geändert.

Ja absolut sicher.
Ich denke eher mal das es sich um ein Missverständniss handelt. Das PE-Image wird immer komplett in den Prozessspeicher geladen (gemappt). Warscheinlich werden dabei die Ressourcen erstmal ins Swapfile geladen um den physikalischen Speicher nicht zu beanspruchen. Ist das der Fall, bleibt aus oben genannten Gründen die Aussage von Petzold falsch, bzw. falsch formuliert, da man in dem Fall nicht davon ausgehen kann, das sie tatsächlich nicht schon beim laden des PE in den physikalischen Speicher kommen.

[Danilo]

Ja absolut sicher.

Hast Du dazu gleich noch einen Link in der offiziellen Doku für
Windows-Programmierer, sprich MSDN?

Nicht das ich Dir nicht glaube, dass Du das entsprechend auf allen
bisherigen Windows-Versionen überprüft hast.
Nur bei so wichtigen Dingen wäre eine offizielle Quelle (wozu man den
Petzold von MS Press mitzählen kann, da quasi das Standardwerk)
IMO sehr wichtig, um es zu *verifizieren* und halt "offiziell zu machen".

Das Resourcen erst bei Bedarf nachgeladen werden, ist seit Win9x
verbreitetes "Standardwissen", was sich natürlich durch den Petzold
so ausgebreitet haben könnte. Wär ziemlicher Hammer, da sich jeder
auf die Korrektheit des Standardwerkes verlässt.

Für normales benutzen von Resourcen macht es eh keinen Unterschied
aus Programmierersicht. Sie sind da, und ich benutze bestimmte Funktionen
um auf sie zuzugreifen - was dahinter abläuft kann mir im Normalfall egal sein.

Das würde heissen das bei deaktiviertem Swapfile eine EXE mit vielen
Resourcen nicht starten kann, wenn nicht genügend Speicher für das
komplette Abbild frei ist...?

[Thorium]

Ja absolut sicher.

Hast Du dazu gleich noch einen Link in der offiziellen Doku für
Windows-Programmierer, sprich MSDN?

Das abolut sicher bezog sich auf die Frage ob ich die Textdatei tatsächlich als Ressource eingebunden habe und nicht etwa per IncludeBinary.

Ich bin mir nicht absolut sicher das die Ressourcen tatsächlich ins Swap-File kommen. Das ist eine Vermutung. Aber das ein PE-Image komplett in den Speicher geladen wird, ob nun physikalisch oder Swap-File ist der Dokumentation des PE-Formats zu entnehmen. Jedenfalls soweit ich mich richtig erinnere. Wenn man das Alignment beachtet kann man ja auch ganz normal auf die Datei im Speicher zugreifen so wie als wenn sie auf der Platte liegen würde mit allem drumm und drann. Deswegen bringen Exe-Packer beim PE-Format ja auch immer etwas Speicher-Overhead mit sich.

Ich werd mal schauen ob ich das in der offiziellen Doku finde.

[Danilo]

Ja absolut sicher.

Hast Du dazu gleich noch einen Link in der offiziellen Doku für
Windows-Programmierer, sprich MSDN?

Das abolut sicher bezog sich auf die Frage ob ich die Textdatei tatsächlich als Ressource eingebunden habe und nicht etwa per IncludeBinary.

Sorry, mein Fehler.

Ich werd mal schauen ob ich das in der offiziellen Doku finde.

Danke Dir, das wäre sehr nett und gleichzeitig nützlich, wenn man dadurch
einen "Bug im 'Standardwissen'" ausbügeln könnte.

[Little John]

The LoadResource function uses the resource handle returned by FindResource to load the resource into memory.

http://msdn.microsoft.com/en-us/library ... S.85).aspx
(PureBoard kann die URL anscheinend nicht "anklickbar" darstellen.)

Wenn sowieso immer alle Resourcen in den Speicher geladen werden, wozu gibt es dann die LoadResource()-Funktion?

Gruß, Little John

[Thorium]

Das hochoffizielle Dokument zum PE und COFF Format sagt garnix zu dem Thema. Dort ist lediglich vermerkt das in der Datenstruktur der Ressourcenheader platz für Flags reserviert ist, diese aber nicht unterstützt werden.

Ich arbeite jetzt erstmal die halboffiziellen Sachen in der MSDN durch.

Aus dem Artikel: Peering Inside the PE

The first important thing to know about PE files is that the executable file on disk is very similar to what the module will look like after Windows has loaded it. The Windows loader doesn't need to work extremely hard to create a process from the disk file. The loader uses the memory-mapped file mechanism to map the appropriate pieces of the file into the virtual address space. To use a construction analogy, a PE file is like a prefabricated home. It's essentially brought into place in one piece, followed by a small amount of work to wire it up to the rest of the world (that is, to connect it to its DLLs and so on). This same ease of loading applies to PE-format DLLs as well. Once the module has been loaded, Windows can effectively treat it like any other memory-mapped file.

Ok, also Filemapping.
Wenn ich unter Filemapping suche, dann bekomme ich nicht viele Informationen in der MSDN. Da wird einige male daraufhingewiesen das Executables eine "Sonderbehandlung" haben. Also sagt im endeffekt nix aus.

Schon interessant. Ich kann ja z.b. den Code im Speicher überschreiben, dadurch wird er aber nicht im File überschrieben. Also nehmen wir mal an das die Ressourcen in den Prozessspeicher gemappt werden und so praktisch im File bleiben und der Speicher nur auf das File verweist. Dann ist die nächste Frage wie man die Ressourcen komprimieren kann so das sie im File nicht zugänglich sind aber nach der Dekomprimierung im Speicher zugänglich sind, wenn es keine Flags gibt, die zwischen File und Speicher unterscheiden. Mit umbiegen is da auch nix. Vieleicht machbar, macht aber keine, erkennbar daran das ein dekomprimiertes PE ohne Probleme dumpbar ist. Also wieder als normales PE auf die Platte geschrieben werden kann. Esseiden es sind irgendwelche anti-crack Tricks eingebaut.

Tjo, keine Ahnung.