Writing directly to system memory

[Rob]

If I have an SV that contains a real (valid) memory address I can read
bytes from that memory address using:

unpack("I", unpack("P4", pack("L", $address)));

Is there a similar perl mechanism that would allow me to write bytes
back at that memory address?


Background:

Using Win32::GUI a number of callback functions for windows GUI events
pass the a win32api lParam value to the callback. For some events the
lParam value is a pointer to windows memory, and for some of those
events it is necessary to change parts of the structure pointed to in
order to get specific behaviour.

I am currently using Win32::API and the win32api RtlMoveMemory function
to achieve what I need, but I would like to remove the Win32::API
dependency.

Perhaps the best solution is to deal with this XS-side in the Win32::GUI
source?

TIA for any pointers or advice,
Rob.

 

[Sisyphus]

If I have an SV that contains a real (valid) memory address I can read
bytes from that memory address using:

unpack("I", unpack("P4", pack("L", $address)));

I use the same to unpack an integer value from a perl object. Given that an
integer consists of a number of bytes, I guess it's correct to say that
"bytes from that memory address" are being read. In the simple little
(Inline::C) demo that I have, the integer value is being set by an xsub
(Inline::C function), and I have another xsub (Inline::C function) that can
assign a new value.

Is there a similar perl mechanism that would allow me to write bytes
back at that memory address?

I really don't know - but I'm damned if I can do it by any means other than
calling the afore-mentioned xsub. (I hope someone will answer that
question.)

Background:

Using Win32::GUI a number of callback functions for windows GUI events
pass the a win32api lParam value to the callback. For some events the
lParam value is a pointer to windows memory, and for some of those
events it is necessary to change parts of the structure pointed to in
order to get specific behaviour.

I am currently using Win32::API and the win32api RtlMoveMemory function
to achieve what I need, but I would like to remove the Win32::API
dependency.

Perhaps the best solution is to deal with this XS-side in the Win32::GUI
source?

In general, the simplest way to get away from Win32::API is to use
Inline::C - which writes the xs code (from the C code that you've inlined),
then compiles that code and executes your script. In terms of functionality,
it's essentially the same as xs, but saves you the trouble of writing the xs
file, the Makefile.PL, etc.

If you're interests are mainly based around Win32::GUI then it might be
easier for you to hack at the Win32::GUI source than mess with Inline::C.
It's difficult to tell from here

Inline::C does work nicely with the Windows API. For a simple example, see
'perldoc Inline::C-Cookbook' and search the document for "windows" (minus
the quotes).

Cheers,
Rob

 

[Rob]

If I have an SV that contains a real (valid) memory address I can read
bytes from that memory address using:

unpack("I", unpack("P4", pack("L", $address)));

Is there a similar perl mechanism that would allow me to write bytes
back at that memory address?

I really don't know [snip] (I hope someone will answer that
question.)

Me too

In general, the simplest way to get away from Win32::API is to use
Inline::C - which writes the xs code (from the C code that you've inlined),
then compiles that code and executes your script. In terms of functionality,
it's essentially the same as xs, but saves you the trouble of writing the xs
file, the Makefile.PL, etc.

Right, but I really want to get away from all external dependencies -
particularly those that require the user to have a compiler.

If you're interests are mainly based around Win32::GUI then it might be
easier for you to hack at the Win32::GUI source than mess with Inline::C.
It's difficult to tell from here

I know my way round the Win32::GUI XS code pretty well (I'm a regular
contributor at the moment) - but Win32::GUI tends to have quite long
intervals between releases at the moment (although we're working on
getting that shorter), and I'm looking for a way that I can release some
code between releases without having to 'roll my own' distribution
(although this is looking like the best solution).

Thanks for your observations and suggestions,
Regards,
(another) Rob.

 

[Sisyphus]

Is there a similar perl mechanism that would allow me to write bytes
back at that memory address?

I really don't know [snip] (I hope someone will answer that
question.)

Me too

Not looking too promising ....

I know my way round the Win32::GUI XS code pretty well (I'm a regular
contributor at the moment) - but Win32::GUI tends to have quite long
intervals between releases at the moment (although we're working on
getting that shorter), and I'm looking for a way that I can release some
code between releases without having to 'roll my own' distribution
(although this is looking like the best solution).

Yeah - sounds like the best plan. Just produce 'development' releases in
between the 'stable' releases.

And it's probably easier and safer to modify the values at those specific
memory locations via xsubs, as opposed to pure-perl means (assuming that
such is even possible). It should also be safer and easier to *read* from
those locations using xsubs, rather than that unpack(unpack(pack()))
convolution - which is not portable, btw (though portability might not be an
issue since we're limited to Win32 in this case).

I guess you'll also release a ppm package for those who don't have a
compiler.

Cheers,
Rob