in reply to How do I find out the RAM memory address of a var in a program running on WIN ?

Your question is quite a bit unclear to me. I'll try several interpretations and answers :

  1. I want to pass the address of a variable to another program. How ?
    This question is answered by the Zen of interpreted languages : Even if you had the address, what would you do with it ? You don't know in what binary format variables are stored and cross-process memory access does not work, not even under Windows 9x (at least, reliably).
  2. I want to change a variable from another program. How ?
    Interprocess communication is best done by reading perlman:perlipc. I suggest Win32::Semaphore if working under Win32, but you might also find success in using read/write pipes.
  3. I want to patch another program currently running in memory. How ?
    While this is thinkable in Perl, it's quite a non-trivial task. To patch other running programs under Windows, you must attach the current process as a debugger to the running process, something which needs deep tinkering with the Windows API and callbacks/threading, two things with levels that range from "advanced" to "black magic". Forget about using Perl in that case, unless you want to prove a point.

  • Comment on Re: How do I find out the RAM memory address of a var in a program running on WIN ?

Replies are listed 'Best First'.
Better clarify : How do I find out the RAM memory address of a var in a program running on WIN ?
by DarkGoth (Acolyte) on Jan 30, 2001 at 16:22 UTC

          First, I'd like to obtain the memory address of a var from another program curently running on win.
       Moreover, I'd to obtain the value (in HEX for instance) of this variable in order to modify it ...

    I hope to be more clear.
    thanks for the clue : I will read perlman:perlipc .
      You expect to be able to go into another running program, find the memory that corresponds to a particular named variable (taking into account the fact that with closures and lexical variables there might be many such), plan on getting around the operating system stopping you from doing this (which it is supposed to do and will do with NT and 2K)...?

      It ain't happening.

      Oh, the trick is technically possible under the right circumstances. Debuggers can do this. But the trick involves quite a bit of work, and having the description of what the debugger can show you be related to the source involves considerable internal knowledge about the program in question. And often requires that program to either be launched in a special way, or to carry descriptive debugging symbols. The former is how the Perl debugger works, you launch a program in the debugger and trace it. The latter requires information that is customarily stripped from Windows programs because it slows startup time. (On Unix it isn't an issue because the OS uses mmap and can lazily page in parts of the program only when they are needed. Windows doesn't pull this trick.)

      This is not even getting into questions of how quickly you can render a program unstable by changing internal data unexpectedly...

      Now if you describe the problem you are trying to solve (and not the technique you hoped to use), we can probably offer some useful suggestions on how to do that. The odds are very high that it will involve interprocess communication or shared memory regions...

      saucepan tells me that win32 does use file mappings to demand page segments of exe files, though he suspects that win9x has to copy the mapped file entirely to swap first (making startup for a non-stripped binary slower). My bad.

      But still a lot of executables and libraries are stripped, and if it is then it will be significantly harder to map information in the source to the running executable.