Runtime instrumentation and tracking of DefWindowProc() / win32/x64

See detailed reqs. ## Deliverables Hello, The idea behind this project is as follows: 1. Since DefWindowProc() which resides in [login to view URL] is already mapped into my process's address space, it must be possible to examine, copy, relocate etc. parts of the DefWidnowProc() function. 2. Given (1) the proposal here is to write a function which - perhaps using a library such as [login to view URL] - when DefWindowProc() is called for the first time with a given message value (DWORD_PTR) sized second param, logs every instruction (machine code level) that is executed right up to the point that DefWindowProc() returns. 2a. The actual machine code sequence is stored in VirtualAlloc()'d executable memory. 3. It should then be possible to identify where DefWindowProc() compares the UINT message value (same said second param) to determine what action to take, i.e. DefWindowProc()'s own equivalent of a switch(iMsg){} 4. From (3) it should then be possible for the function to return the exact address (as DWORD_PTR) of DefWindowProc()'s 'handler' for the message value passed to it as it appears in the VirtualAlloc()'ed block. 5. Then, without bothering to remove the redundant portion of the code from the VirtualAlloc()'d block, another function accepting a single param which is the address of the original call to DefWindowProc() to overwrite the original call with a jmp directly to the VirtualAlloc()'d copy of the 'handler' for the message value in question, effectively replacing the C++ coded call to DefWindowProc() within a specific window procedure, handing a specifric message with that jmp instruction (i.e. thunking it). 6. The first function must then be modified so that - having executed the relocated handler directly - jmp's straight back to the instruction following what was the original call to DefWindowProc() after any function epilogue. If this works, it will mean any window procedure can be speeded up at runtime by performing the thunking as described, so that the message value is not evaluated twice. So what I need are the following two functions: 1. GenerateDirectDWPW_Handler(UINT iMsg, (DWORD_PTR)label_address_post_call); 2. ThunkDWPW_Handler((DWORD_PTR)label_address_pre_call); Potentially, this could be extended to produce direct copies of DWPW()'s handlers for specific WPARAM and LPARAM values where its (DWP()'s) behaviour is determinsitic with a discrete number of possibilities for those values. This should be possible, so if you fancy a really nuts and bolts challenge, this project is for you. Serious bids only please. Many thanks.