Thread: using WM_SETTEXT between processes

This code finds a notepad window, and places the text in the edit control. But why does it work? Wouldn't the pointer to the string "hi" be invalid in the notepad process?

Code:

#include <windows.h>

int main()
{
	HWND hNote;
	HWND hChild;

	if (!(hNote=FindWindow("Notepad",NULL)))
		exit(1);

	if (!(hChild=FindWindowEx(hNote,NULL,"EDIT",NULL)))
		exit(2);

	SendMessage(hChild,WM_SETTEXT,NULL,(LPARAM)"hi");
	

	
	return 0;
}

Don't worry, I found the answer in google. I took me ages, but I eventually found this passage:

In the implementation of the Text property, I exploited a little-known feature of the Win32 edit controls. All Win32 controls cannot work across the process boundaries. For example, you cannot ask another application's rich edit box to return its content as a string. The problem with this is that any memory address makes sense only in the memory context of the process managing it. There are a few exceptions to this rule.

All the Windows standard controls (buttons, listboxes, and edit controls, among the others) don't obey this rule. Their content can be read and set across the process boundaries without limitation. This has been done since the times of Windows 95 to preserve the backward compatibility of existing Win3x applications using interprocess subclassing. This is still true in XP and Win2K.

As a result, you can use a few messages, such as WM_GETTEXT and WM_SETTEXT, to get and set the content of a textbox irrespective of the actual processes involved.

So it appears that standard controls are an exception to interprocess boundries. I'm going to do a little fiddling around, to see what pointer is actually received in the end by the target edit control.

I did my fiddling, and found out some things. Let's set the scene here:

In program A I have a string on the local stack. I pass the address of that string with WM_SETTEXT to an edit control in another window, in program B. In that window, I have subclassed the edit control's window procedure, intercepted the message, and displayed the value of lParam. The value passed by SendMessage() in program A doesn't match the value received in WM_SETTEXT by program B. This leads me to believe that when those certain messages are passed to another process by SendMessage(), some memory is allocated in the target process, and the relevant data is copied. Hence, the value of lParam is changed so that the right address is pointed to.

So this means that WM_SETTEXT in the target process doesn't actually have direct access to memory in process A, but rather, the memory in process A is copied to process B, and the message parameters are changed accordingly.

Would anyone agree with that?

Okay, I'm happy with the WM_SETTEXT part. But now I'm looking at WM_GETTEXT. It's a whole different game.

Again, the value passed as lParam in process A is not the same value received as lParam in process B. I found that the process B lParam location receives the window text, AS WELL AS the process A lParam location. Now what is going on here? The window text is written twice, in two different processes. Does anyone know how this works under the hood?

Thanks, that cleared it up.

Do you know of any resource that would have a complete explanation of how these Win32 API messages work? I'm willing to buy a book if it's worth it.

as does EM_REPLACESEL it seems! I've just been tearing my hair out over it! ( recent thread posted b4 I read this )