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.

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

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

You may also try a pseudo client-server architecture by grabbing info on pipes. In that case, the address is irrelevant (as it should be) and you an copy the info in the pipe's buffer directly to the variable that you wanted to alter "remotely". Then you can close the pipe or wait for another "change value" instruction.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.