The correct statement is therefore:
Move(functionCode[1], FBlock^.code^, len);
It would also be cleaner to use a dynamic array instead of a string
to store arbitrary binary data (in that case, you'd have to use
functionCode[0] above though).
I have tried yours and other combinations. The following one works at
last in Delphi6 PE. This will keep me occupied some time updating my
32 bits programs, so that they will be DEP safe. Thanks to you all.
Note that I have dropped the use of Move. As for fpc-Lazarus 64 bits,
it does not work yet: more about this in another thread.
{--------------code snippet begins--------------}
len:= Length(cod); { cod is the ansiString containing
the opcodes to be executed}
SetLength(ba, len); { ba is an auxiliary array of bytes}
for i:= 0 to len-1 do
ba[i]:= ord(cod[i+1]);
{ exeBlock has been declared as PChar }
exeBlock:= VirtualAlloc(nil, len + SizeOf(exeBlock), MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
for i:= 0 to len-1 do
exeBlock[i]:= chr(ba[i]);
@F:= @exeBlock[0]; { F is the function whose code is
here assigned to cod}
ba:= nil;
cod:= '';
{----------code ended---------------}
For people interested in details: the use of an AnsiString for storing
the opcodes, that is for building "cod", eases this by the use of the
special procedures to treat strings (adding them, etc.).
The use of exeBlock as PChar serves to guarantee that a contiguous
chunk of memory starting in exeBlock[0] becomes reserved for the
exclusive use of exeBlock and cannot overlap another variable: this is
my interpretation of the failure that did happen when, after assigning
the code to F, I did put cod = ''.
--
montesin at uv dot es
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
