From: Pavel Lebedinsky (m_pll)
Date: Sat, 8 Jan 2005 19:19:48 -0800
Read/WriteProcessMemory are already documented as debugging
There's no mention of them in the list of supported IPC methods:
I think the docs are pretty clear as they are.
"Sam Hobbs" wrote:
> Thank you, Pavel. What you say is what I thought is the situation, but in
> order to convince others, I need to get people such as you to say things
> such as you say. Okay, so that was rather general. The following are
> sample posts from the two people I mentioned.
> The first one is a discussion that is still on-going; see:
> VBForums.com - send info between apps
> That discussion is quite lengthy, and that is the main reason I omitted it
> from my original question. If you search that thread for
> "WriteProcessMemory" then I hope you will find the relevant parts without
> too much inconvenience. Note that I posted a message ("Is WM_COPYDATA
> special?") in the microsoft.public.vb.winapi newsgroup concerning the
> issue of the WM_COPYDATA message.
> Another relevant discussion is older and is in another forum; see:
> CodeGuru Forums - Memory problem in C
> where Mick says "otherwise use OpenProcess(...) and
> ReadProcessMemory(...)" to which I say "I think that ReadProcessMemory is
> not normally considered an IPC solution". So the subject there is
> ReadProcessMemory, not WriteProcessMemory, although I used
> WriteProcessMemory for the subject here. Note that Mick is a Forums
> Moderator and is respected for his knowledge. He is very knowledgeable
> about many very technical Windows subjects, but that is greater
> justification to ensure he does not mislead people.
> So I created another thread; see:
> CodeGuru Forums - Debate: Is ReadProcessMemory normally considered an IPC
> That thread did help, but it still did not get the point well enough that
> ReadProcessMemory and WriteProcessMemory are not as useful as Mick
> If we are correct that ReadProcessMemory and WriteProcessMemory should not
> be used for normal IPC, and should not be suggestged for use without
> sufficient cautions at least, then I think the MSDN needs to be much more
> clear about that.