Wie werden ausführbare win32-Ressourcen behandelt?

Ich weiß nicht, warum es so schwierig ist, die Antwort auf diese Frage bei Google zu finden, aber ich möchte etwas klarstellen.Wie werden ausführbare win32-Ressourcen behandelt?

Werden win32-Ressourcen auf dieselbe Weise behandelt wie statische Daten, wenn diese Daten für die gesamte Laufzeit eines Prozesses im RAM gehalten werden oder bis sie in den Speicher geladen werden? Funktionen wie LoadResource/LoadString implizieren Letzteres, aber ich möchte absolut sicher sein, dass ich nicht durch Abstraktion getäuscht werde.

Quelle

2013-12-19 NmdMystery

Im Allgemeinen bleiben sie auf der Festplatte, bis geladen, aber ... betrachten Sie es als ein Implementierungsdetail. Aus Gründen der Leistung kann das Betriebssystem entscheiden, eine ausführbare Datei vollständig in den Arbeitsspeicher zu laden (wenn sie klein genug ist). Warum nicht? –

Es ist ziemlich wahrscheinlich, dass die ausführbare Datei speicherplatziert ist, daher bewirkt LoadResource, dass der Teil der ausführbaren Datei seitenweise ausgetauscht und dann ausgetauscht wird, wenn der RAM für etwas anderes benötigt wird. So würde ich es zumindest tun. – Gene

@Gene: So wird es heutzutage gemacht. Sie werden genau wie Ihr Code nachfragegesandt. Der Grund für den merkwürdigen Funktionsnamen ist, dass er in den Win16-Tagen tatsächlich die Daten geladen hat und die Basis-API aus Kompatibilitätsgründen stecken geblieben ist. Wie auch immer, LoadString "lädt" den Text tatsächlich (er nimmt einen Pufferparameter) – doynax

In den alten Tagen (wie Windows 3.1 und früher) wurden Ressourcen beim Laden in den Arbeitsspeicher kopiert, und Sie haben gerade ein Handle zu ihnen. Der Speichermanager könnte Dinge tun, wie zum Beispiel die Kopie im Speicher verschieben, um Platz zu defragmentieren, oder sogar die Ressource heimlich entladen, bis sie sie wieder benötigt. Wenn Sie die Ressource benötigten, gab es einen zweiten Schritt, um sie in den Speicher zu "sperren". Dies gab Ihnen einen Zeiger auf die Kopie und stellte sicher, dass der Ressourcenmanager sie nicht verschoben hat, bis Sie ihn wieder entsperrt haben.

In 32-Bit-Versionen von Windows werden Ressourcen nicht kopiert. Die ausführbare Datei (oder DLL) wird dem Speicher zugeordnet, und wenn Sie die Ressource berühren, stellt der Manager für den virtuellen Speicher sicher, dass sie für Sie da ist.

Die APIs (FindResource, LoadResource, LockResource) spiegeln die alten Zeiten mit Griffen für Ressourcen und Sperren von Handles usw. wider. Die Implementierungen sind jedoch jetzt viel einfacher, da das Handle nur ein Zeiger auf den Anfang der Ressource ist und Sperren ist effektiv ein No-Op, den Griff zu einem Zeigertyp umwandeln und es zurückgeben.

Quelle

2013-12-20 18:28:46

Möglicherweise stellen Sie fest, dass alle Ressourcen-APIs ein hModule Argument akzeptieren - dies ist in der Tat ein Zeiger auf den PE-Header des Moduls im Speicher und nicht das Handle zu der Datei auf der Festplatte. Daher muss der Ressourcenabschnitt der PE-Datei (.rsrc) im Speicherbereich des Programms vorhanden sein, damit diese APIs funktionieren. Natürlich werden die Daten wie bei allen im Speicher abgebildeten Dateien wahrscheinlich nicht wirklich in den physischen RAM gepuffert, bis sie benötigt werden.

Quelle

2013-12-20 14:30:35

Mit ['GetModuleFileName'] (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197.aspx) ist Ihre strikte Anforderung, dass der Ressourcenabschnitt ** im Speicher für diese vorhanden sein muss APIs funktionieren nicht. – IInspectable

@Intspectable: das ist keine Ressourcen-API. –

Ich habe nicht angedeutet, dass es war. Mein Punkt ist, dass das Modul-Handle und ein Handle auf den Dateiträger austauschbar verwendet werden können. Ich sage nicht, dass deine Schlussfolgerung auch falsch ist. Die Begründung für diese Schlussfolgerung lässt jedoch Raum für Verbesserungen. – IInspectable

Wie werden ausführbare win32-Ressourcen behandelt?

Antwort

Verwandte Themen