| | | | The issue of interprocess communication is a very important one to those of us who like to hack. After all, much of what we want to do involves invading a foreign process sending commands and sending or receiving data. | | | | | | Referring to the ExtractFromListbox procedure, the LB-GETTEXTLEN message works across process boundaries because the only data returned is the return value of the function. This value is returned on the calling process's stack. In particular, it does not require allocating a memory buffer. | | | | | | On the other hand, the LB_GETTEXT message requires the address of a memory buffer. Now, the calling process can allocate a memory buffer only its own memory space, not in the address space of the process that contains the listbox. But the window procedure of the foreign process thinks that the address in the 1Param parameter is in its own address space (that is, the only address space it knows about), so it will try to place the item at that location in its address space. It would certainly seem that this will cause an access violation. In any case, it certainly won't return the item text to the calling process. However, the code works, and the listbox item is in fact placed in the buffer of the calling process! | | | | | | The reason is that Windows actually watches out for certain messages, such as LB_GETTEXT, and is kind enough to marshall the data (in this case the listbox item) from the target address space to the calling address space. (Marshalling means packaging data and sending it across process boundaries. This happens a lot in OLE Automation.) | | | | | | It is not clear exactly which messages are automatically marshalled by Windows and which are not, so you need to experiment. For instance, buffers for messages sent to older-style 16-bit controls, such as listboxes and combo boxes, appear to be marshalled in order to preserve compatibility with 16-bit Windows, where marshalling was not even an issue (it was not required). | | | | | | However, Windows does not marshall data extracted from a new 32-bit ListView control, since in this case there is no compatibility issue. The Control Extractor application will need to find another approach. Indeed, we will need to find some way to allocate memory in the foreign process and then copy data to and from this foreign memory, in particular, when we come to write the rpiControlExtractor code for extracting from a foreign ListView control. | | | | | | Actually, the hard part can be the allocation of foreign memory. Note that under Windows NT, this is not difficult, because Windows NT implements the function VirtualAllocEx: | | LPVOID VirtualAllocEx( HANDLE hProcess, // process within which to allocate memory LPVOID lpAddress, // desired starting address of allocation DWORD dwSize, // size, in bytes, of region to allocate DWORD flAllocationType, // type of allocation DWORD flProtect // type of access protection ); |