Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Win32 Handles and the SendMessage API

Every graphical component of the Win32/16 GUI (Windows, edit controls, list boxes, etc.) has a "handle" assigned to it by the operating system upon instantiation. This handle is somewhat like a pointer in that it contains a dynamic, integral value that designates some resource. But unlike a pointer, a handle's value is valid across process boundaries. If a process A gets the handle of a list box in Process B, then A can fill B's list box B by calling SendMessage with that handle:

SendMessage(<LB_HANDLE> , LB_ADDSTRING, 0, (LPARAM)
    (LPCTSTR)"New Item")

In Win32, almost every function or procedure that influences a Windows control (and almost everything on your screen is a windows control) ultimately boils down to a SendMessage function. SendMessage's first argument is the handle of the destination control/window and its second argument is the type of message you want to send. The third argument is a generic word length parameter (unused in this case). The fourth argument is a generic-32 bit value which can be used as a long, or cast to a pointer to a data type appropriate for the message being sent.

In the above example, the fourth parameter is cast to a pointer to a string object, since that's what the list box will expect when it interprets an LB_ADDSTRING message. It is this fourth parameter that severely limits a process's ability to influence handles whose associated controls are outside the process's space. For many types of messages the fourth parameter is a pointer to a structure, and this creates a problem. What typically happens is as follows: 1) Process B has the handle of a window or control that resides in Process A's address space; 2) Process B calls SendMessage to send a message that requires a pointer to a structure as the fourth parameter. 3) The window or control in Process A receives this message, and attempts to dereference the pointer in the fourth parameter. However, that address is only valid in Process B's address space, so the operating system raises an Access Violation and terminates Process A for trying to dereference a bad pointer. o

Previous Page | 1 | 2

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.