VirtualAlloc + VirtualLock

[Sebastian Grabert]

Hallo,

ich habe ein kleines Verständnissproblem mit den API Funktionen der Speicherverwaltung.
Vielleicht kann mir jemand folgendes erklären:

<PRE>
SnapMemory := GlobalAlloc(GPTR, size);
temp := GlobalLock(SnapMemory);
.. Speicher benutzen ..
GlobalUnlock(SnapMemory);
GlobalFree(SnapMemory);
</PRE>
Das funktioniert hervorragend. Nun würde ich den Speicher aber gerne direkt um "realen" Speicher anlegen, dazu verwende ich die Funktion VirtualAlloc:
<PRE>
SnapMemory := GlobalAlloc(GPTR, size);
temp := GlobalLock(SnapMemory);
SnapPointer := VirtualAlloc(temp, size, MEM_COMMIT, PAGE_READWRITE OR PAGE_NOCACHE);
</PRE>

Ich erhalte einen gültigen Pointer und kann den Speicher auch ganz normal benutzen.
Aber ich kriege aus der Hilfe nicht wirklich heraus, wie der Befehl funktioniert und was hier passiert.

Außerdem würde ich gerne den Speicher "final sperren" und dafür
<BR> VirtualLock<BR>
benutzen, dieser Befehl schlägt aber immer fehl. Warum???

Danke, Danke

[Hagen Reddmann]

Weil du mit MEM_COMMIT diesen Speicher schon vom "virtuellen" Speicher zum "realen" Speicher gelockt hast. VirtualLock() sperrt also NICHT den Speicher sondern im Gegenteil macht aus einem nur als virtuell allozierten Speicher einen tatsächlich existenten.<br>
Was Du versuchst geht mit VirtualProtect(). ABER, da gibts Unterschiede zwischen den OS'en.<br>

Gruß Hage

[Sebastian Grabert]

Die Frage bezieht sich vor allem auf Win2K und XP...
wie genau wirkt VirtualProtect(

[Hagen Reddmann]

Jeder Memorychunk besizt Zugriffsattribute, also Lesen,Schreiben,Ausührbarer Code,Beweglich,Fester Speicher usw.<br>
VirtualProtect() verändert diese Attribute wenn man Zugriffsrechte besitzt. Man kann so z.b. mit VirtualProtect() das Speicherattribut "ReadOnly" vom Programmcode eines processes löschen, dann schreiben den Code patchen, und mit VirtualProtect() das Original Attribut wieder restaurien. Man hat sozusagen dynamisch den Code des Processes verändert.<br>

Unter echten 32Bit OS'es, wie Window NT/2k gibts noch Attribute die Benachrichtigungen ermöglichen. D.h. man kann den VMM so einrichten das Schreibzugriffe/Attributänderungen eines Speicherblockes eine externe Exception auslösen, BEVOR diese Opcodes ausgeführt werden. Der Excpetionhandler hat nun die Möglichkeit das Schreiben in den Speicher zu verhindern "re-raise" oder aber zu erlauben.<br>

Gruß Hage