Debate: Is ReadProcessMemory normally considered an IPC solution?

[Sam Hobbs]

ReadProcessMemory is a Debugging and Error Handling function, right?

See Memory problem in C, in which I say that ReadProcessMemory is not normally considered an IPC solution. My definition of "normally considered an IPC solution" is something in the Interprocess Communications section of the Platform SDK. Is it reasonable for me to say that ReadProcessMemory is not normally considered an IPC solution?

The reason I ask is because there are a few CodeGuru members that I can't get through to, so instead of continuing to get into useless debates, I would prefer to create more productive discussions to resolve issues such as the above. I really, really, really think I am being reasonable, and if I am, then it would be more productive if more members are involved, since I would have much less need to bother the other members and myself as much as I have had to lately.

I only want to discuss issues relevant to this forum though; that is, the question of ReadProcessMemory is normally considered an IPC solution.

[Mick]

Since a lot of other members can't seem to get through to Sam

Here is the other side of the 'argument' for lack of a better word.

Any method by which data is exchanged between two processes is a Inter Process Communication, you cannot change the definition of the word.

And normally wasn't the point of the converstation.

[Sam Hobbs]

Originally posted by Mick
And normally wasn't the point of the converstation.

It is the subject of this conversation.

[Mick]

Originally posted by Sam Hobbs
It is the subject of this conversation.

then don't reference a thread where it wasn't

[Mick]

btw what does 'normally' have to do with anything?

normally...

readprocessmemory/writeprocessmemory:

The process whose address space is read is typically, but not necessarily, being debugged.

should we start talking about normally typically necessarily?

Quite a bit of code out there uses Read/Write process memory.

box...me...outside

box...sam...inside

[filthy_mcnasty]

i agree with sam *erie silence*

i do not consider Read/Write process memory to be IPC. There is no doubt it can be used for such things *i've considered it a time or two but always gone another route instead* but that's not its INTENDED use (then again how often IS it used as it's intended to be) so yes i think it is reasonable for you to say that sam.

[Mick]

Originally posted by filthy_mcnasty
i agree with sam *erie silence*

i do not consider Read/Write process memory to be IPC. There is no doubt it can be used for such things *i've considered it a time or two but always gone another route instead* but that's not its INTENDED use (then again how often IS it used as it's intended to be) so yes i think it is reasonable for you to say that sam.

So by that you mean if you post a message to another processes window, and that process performs some action based on that message, you haven't just used a form of IPC as defined by the word IPC?

[filthy_mcnasty]

See Memory problem in C, in which I say that ReadProcessMemory is not normally considered an IPC solution

i'm saying it IS IPC mick but that i also agree with this statement of Sam's

[Mick]

Originally posted by filthy_mcnasty
i'm saying it IS IPC mick but that i also agree with this statement of Sam's

I never disagreed with Sam's statements, I said they were microsofts "definitions" of their set of API's that use IPC.

mailslots use IPC
pipes use IPC
filemappings use IPC

key word, USE.

But I think there is too much focus on 'this is what microsoft says is an IPC' there is no such thing as a singular set of IPC methods.

[Mick]

just one more thing about intended use. Again it's stated that ReadProcessMemory(...)/WriteProcessMemory are 'normally' used inside of a debugger. But that is not their only use.

My god if we pigeon hole people into only using API's as they are defined, eg: it's in the debug API library so you can't use it for anything else, neener neener, then I pity the featureless restricted code that we would be using today. I mean the Native API isn't documented by mickeysoft, so are we to say we cannot use it? I know nobody is making this argument, but sometimes it sure seems that way....

[dimm_coder]

It's not usually the appropriate approach to use them like IPC and U can advise to use something other (standard ("normally") IPC , according to your words).
But I can point U to the case when ReadProcessMemory/WriteProcessMemory
aren't Debugging and Error Handling functions.

So,

ReadProcessMemory is a Debugging and Error Handling function, right?

IS false.

[Kheun]

I hope that the following list of criterions qualifys what defines an IPC.

1. Providing a means for communication between two or more processes.
2. Creating a channel that, must at least, identify the server.
3. Allows reading and writing of data via the channel.
4. Allows sychronous and/or asychronous communication.

If I am missing anything, please help me to complete the list.

By comparing Read/WriteProcessMemory() against the list, it passes all the criterions except (1). Unlike the IPCs listed by MS, the default capability of Read/WriteProcessMemory() doesn't allows multiple client processes to write data into the server simultaneously. This is because it doesn't provide any sychronization nor queue that distinguish one message from another. In other words, data can be overwritten before the server act on it. Of couse, we can always add named mutexes or even create a queue to overcome the shortcoming. That's not the point as its default capabilities doesn't do that. So I believe that it is still sort of "use at your own risk" and probably why MS doesn't qualify it as an IPC.

[Mick]

filemappings do not provide sync objects either. But sync objects are used. if you look at OutputDebugString(...) you'll see it creates a mutant, and signals it if a debugger is not attached, after it writes the debug string to the filemapping.

so...a filemapping is not an IPC??? mickeysoft says it is...

File mapping enables a process to treat the contents of a file as if they were a block of memory in the process's address space. The process can use simple pointer operations to examine and modify the contents of the file. When two or more processes access the same file mapping, each process receives a pointer to memory in its own address space that it can use to read or modify the contents of the file. The processes must use a synchronization object, such as a semaphore, to prevent data corruption in a multitasking environment.

You can use a special case of file mapping to provide named shared memory between processes. If you specify the system swapping file when creating a file-mapping object, the file-mapping object is treated as a shared memory block. Other processes can access the same block of memory by opening the same file-mapping object.

File mapping is quite efficient and also provides operating-system–supported security attributes that can help prevent unauthorized data corruption. File mapping can be used only between processes on a local computer; it cannot be used over a network.

Key Point File mapping is an efficient way for two or more processes on the same computer to share data, but you must provide synchronization between the processes. For more information, see File Mapping and Synchronization.

[Kheun]

Originally posted by Mick
filemappings do not provide sync objects either. But sync objects are used. if you look at OutputDebugString(...) you'll see it creates a mutant, and signals it if a debugger is not attached, after it writes the debug string to the filemapping.

so...a filemapping is not an IPC??? mickeysoft says it is...

Good point!

One difference between file mapping and Read/WriteProcessMemory() that I can see is the former provide a restricted access while the latter can access virtually every part of the process memory. The latter is very much more powerful and if not use properly can lead to many problems. As for the former, the problem is more isolated.

[Mick]

Originally posted by Kheun
Good point!

The only difference between file mapping and Read/WriteProcessMemory() that I can see is the former provide a restricted access while the latter can access virtually every part of the process memory. The latter is very much more powerful and if not use properly can lead to many problems. As for the former, the problem is more isolated.

yep, because it gets right down into ZwReadVirtualMemory(...) with very little exteranous calls, eg: effiecent.

Now, lets clarify, would I use it as an IPC, maybe, it all depends, but to dismiss it out of hand is IMHO not very logical.

but the whole point of this exercise is just a matter of definition eg: semantics...

whereas I think the majority of people would say, it's not a microsoft IPC because they don't list it as such. Where I would say, umm ok, keep having that narrow focus...

btw: is LPC an IPC...even though it's called Local Procedure Call...yep...it's an IPC....

but it's not listed in the microsoft IPC's, yet it's one of the most often called API's in the OS...