Featured post
c++ - How can I cope with 32bit/64bit mismatches when doing IPC via SendMessage? -
i have piece of c++ code reads out text of tree item (as contained in plain common controls tree view) using tvm_getitem window message. tree view receives mesage in different process, i'm using little bit of shared memory structure pointed 1 of arguments window message. have work since remote process not under control (i'm writing application similiar spy++).
this works in principle, fails in case target process substantially different:
if code of target process built unicode defined own code wasn't, 2 processes have different ideas structure of string members in tvitem structure. solved using iswindowunicode call , explicitely sending either
tvm_getitema
ortvm_getitemw
(recoding result if necessary).if calling process built in 32bit mode , target process 64bit (or other way round), layout (and size) of tvitem structure structure different since pointers have different size.
i'm trying find way solve second issue. particular use case (getting tree item text) example, same issue exists other window messages code sending. right now, i'm considering 2 approaches:
- build code twice , execute either 32bit or 64bit code depending on target process does. requires changes our build- , packaging system, , requires factoring code architecture specific out dedicated process (right it's in dll). once done, should work nicely.
- detect image format of target process @ runtime , use custom structs instead of tvitem structure structure explicitely use 32bit or 64bit wide pointers. requires writing code detect architecture of remote process (i hope can calling getmodulefilename on remote process , analyzing pe header using image library) , hardcoding 2 structs (one 32bit pointers, 1 64bit). furthermore, have make sure shared memory address in 32bit address space (so own code can access it, if it's compiled in 32bit mode).
did else have solve similiar problem? there easier solutions?
i ended checking whether remote process 32bit or 64bit @ runtime, , writing right structure shared memory before sending message.
for instance, here's how can use tvm_getitem
message if there's 32bit <-> 64bit mixup between caller , receiver of message:
/* template copy of tvitem struct except * fields return pointer have variable type. allows * creating different types different pointer sizes. */ template <typename addrtype> struct tvitem_3264 { uint mask; addrtype hitem; uint state; uint statemask; addrtype psztext; int cchtextmax; int iimage; int iselectedimage; int cchildren; addrtype lparam; }; typedef tvitem_3264<uint32> tvitem32; typedef tvitem_3264<uint64> tvitem64; // .... later, can use above template this: lparam _iteminfo; dword pid; ::getwindowthreadprocessid( treeviewwindow, &pid ); if ( is64bitprocess( pid ) ) { tvitem64 iteminfo; zeromemory( &iteminfo, sizeof( iteminfo ) ); iteminfo.mask = tvif_handle | tvif_text; iteminfo.hitem = (uint64)m_item; iteminfo.psztext = (uint64)(lptstr)sharedmem->getsharedmemory( sizeof(iteminfo) ); iteminfo.cchtextmax = maxtextlength; _iteminfo = (lparam)sharedmem->write( &iteminfo, sizeof(iteminfo) ); } else { tvitem32 iteminfo; zeromemory( &iteminfo, sizeof( iteminfo ) ); iteminfo.mask = tvif_handle | tvif_text; iteminfo.hitem = (uint32)m_item; iteminfo.psztext = (uint32)(lptstr)sharedmem->getsharedmemory( sizeof(iteminfo) ); iteminfo.cchtextmax = maxtextlength; _iteminfo = (lparam)sharedmem->write( &iteminfo, sizeof(iteminfo) ); }
the sharedmem->getsharedmemory
function little helper function pointer shared memory region; optional function argument specifies offset value. what's important shared memory region should bee in 32bit address space (so 32bit remote process can access it).
- Get link
- X
- Other Apps
Comments
Post a Comment