Writing directly to system memory

Discussion in 'Perl Misc' started by Rob, Jul 14, 2005.

  1. Rob

    Rob Guest

    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.
    Rob, Jul 14, 2005
    #1
    1. Advertising

  2. Rob

    Sisyphus Guest

    "Rob" <> wrote in message
    news:...
    > 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
    Sisyphus, Jul 15, 2005
    #2
    1. Advertising

  3. Rob

    Rob Guest

    Sisyphus wrote:
    > "Rob" <> wrote:
    >
    >>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 :)

    >
    >>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.


    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.
    Rob, Jul 16, 2005
    #3
  4. Rob

    Sisyphus Guest

    "Rob" <> wrote


    > >
    > >>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
    Sisyphus, Jul 16, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark

    Re: writing HTML directly

    Mark, Jul 8, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    388
  2. darrel
    Replies:
    1
    Views:
    322
    Joerg Jooss
    May 13, 2006
  3. Benjamin de Waal
    Replies:
    5
    Views:
    1,293
    Benjamin de Waal
    Mar 3, 2005
  4. onetitfemme

    directly writing to JARs

    onetitfemme, Sep 7, 2006, in forum: Java
    Replies:
    1
    Views:
    334
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Sep 7, 2006
  5. galapogos

    Directly reading/writing a HDD

    galapogos, May 7, 2007, in forum: C Programming
    Replies:
    5
    Views:
    298
    Kenny McCormack
    May 16, 2007
Loading...

Share This Page