|We don't bite newbies here... much|
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...
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.
In reply to Re (tilly) 1: Better clarify : How do I find out the RAM memory address of a var in a program running on WIN ?