Memory problem in C

[guiemjulia]

Hi:

I'm trying to do this:

-A C program write the memory pointer to one of its structures in a file (ex: 00278F92). And after that, he waits in execution.

-Another C Program begins its execution, open the file, catch 00278F92, and use it to point the structure (which is defined too in this second program of course). Then it begin to search in this structure, but it fails. At one moment i see that he's pointing to FFFFFFFF.

If I write exactly the same code in the first program, something like this

newstruct=0x00278F92;
search(newstruct);

It works fine! So I think this is a problem with shared memory or similar, the first program don't let the second to see "its" memory.

Anybody knows how to work like this? What to doing?

Thanks. A lot of thanks!

[Yves M]

This depends on your operating system. Most OSes these days give each process a virtual memory layout, which means that program a) can think its data is at 0x00278F92 and program b) thinks its data is at 0x00278F92, but yet these two adresses physically map to different memory.

[guiemjulia]

and any idea about what to do?

[Mick]

well it depends on what you are attempting to do...just use a filemapping (CreateFileMapping(...) etc) if you want to transfer data back and forth via an IPC, otherwise use OpenProcess(...) and ReadProcessMemory(...)

[Yves M]

Originally posted by guiemjulia
and any idea about what to do?

Tell us which OS you are using and we may be able to help

[guiemjulia]

XP, but i want to make it work at 2000 server.

I'll look at the fuctions Micks say me.

[Sam Hobbs]

My Processes and Address Spaces might help you to understand about memory.

There are many Interprocess Communications (IPC) capabilities, and Mick mentioned a couple. (Actually I think that filemapping is the only IPC capability that Mick mentioned; I think that ReadProcessMemory is not normally considered an IPC solution.) The best solution depends on your requirements; the easiest is the WM_COPYDATA message.

[Mick]

Originally posted by Sam Hobbs
My Processes and Address Spaces might help you to understand about memory.

There are many Interprocess Communications (IPC) capabilities, and Mick mentioned a couple. (Actually I think that filemapping is the only IPC capability that Mick mentioned; I think that ReadProcessMemory is not normally considered an IPC solution.) The best solution depends on your requirements; the easiest is the WM_COPYDATA message.

because a filemapping is the most effiecent form of IPC.

[Sam Hobbs]

The WM_COPYDATA message uses filemapping. The WM_COPYDATA message is definitely the most efficient for us (the programmer). So it depends on requirements, but an individual WM_COPYDATA message seems to me to be as efficient for Windows as if we were to code the filemapping ourselves and the WM_COPYDATA message would be immensely more efficient for us to program.

[Mick]

Originally posted by Sam Hobbs
The WM_COPYDATA message uses filemapping. The WM_COPYDATA message is definitely the most efficient for us (the programmer). So it depends on requirements, but an individual WM_COPYDATA message seems to me to be as efficient for Windows as if we were to code the filemapping ourselves and the WM_COPYDATA message would be immensely more efficient for us to program.

there are alot of things that use a filemapping, but it is more effiecnet to cut out the middle man and associated calls with the middle man, and the processing overhead.

[Mick]

Originally posted by Sam Hobbs
I think that ReadProcessMemory is not normally considered an IPC solution

IPC is any process via software by which data is exchanged without human intervention.

WriteProcessMemory(...)
Signal write sync object (Mutex)
other proc process data, signal read sync object.
ReadProcessMemory(...)

rinse and repeat

I-P-C

[Sam Hobbs]

Sometimes the savings in machine time do not justify the cost of people time. It depends on the situation and the programmer. Are you saying that the WM_COPYDATA message is never practical?

[Mick]

Originally posted by Sam Hobbs
Are you saying that the WM_COPYDATA message is never practical?

of course not.

[Sam Hobbs]

Originally posted by Mick
IPC is any process via software by which data is exchanged without human intervention.

Are you denying that ReadProcessMemory is a Debugging and Error Handling function? I don't know if ReadProcessMemory has more restrictive security requirements, but if it does, then that should be made clear when it is suggested as a solution.

My definition of "normally considered an IPC solution" is something in the Interprocess Communications section of the Platform SDK. If you want to use a different definition of IPC, then you can, as long as it is clear that it differs from the Platform SDK definition.

[Mick]

Originally posted by Sam Hobbs
Are you denying that ReadProcessMemory is a Debugging and Error Handling function? I don't know if ReadProcessMemory has more restrictive security requirements, but if it does, then that should be made clear when it is suggested as a solution.

My definition of "normally considered an IPC solution" is something in the Interprocess Communications section of the Platform SDK. If you want to use a different definition of IPC, then you can, as long as it is clear that it differs from the Platform SDK definition.

sam, get off the tin foil hat details, the definintion of IPC is just what I stated. Microsofts definition of it's IPC api's is just that.