Hi! What I have run across in regards of ReactOS send message subsystem, ros is not packing before co_MsqSendMessage and unpacking after co_IntCallWindowProc! Instead packing before co_IntCallWindowProc with send message. Does that not raise any questions? co_IntSendMessageWithCallBack seems to do it almost right, but IntCallWndProc/Ret should be called when calling the client via co_IntCallWindowProc and should pack before the call to MsqWakeQueue and then unpack after the call to co_IntCallWindowProc. Confused?
Basing this on IntCallLowLevelEvent and co_IntCallLowLevelHook when the lParam is used to save information that could get lost in a stack switch or release.
Setting up the pattern; Pack before co_MsqSendMessage or related friends and Unpack after calling co_IntCallWindowProc to client. Have co_MsqDispatchOneSentMessage call something other than co_IntSendMessage so the Packed data can be handled correctly when calling to the client via co_IntCallWindowProc.
I'm sure Michael Martin has brought this up to me on many occasions. Let's see where this goes! Thanks, James
Hi there, this document describes how messages are marshaled in win32k: http://mista.nu/blog/2011/02/11/thread-desynchronization-issues-in-windows-m...
imo SendMessage should works fine now. this is how it should work: in case we send the message to the same thread, call hooks, and call the window proc . Calling the window proc requires to pack the parameters. If we send the message to another process we queue the message and when the other process gets the message, it packs it in order to give it to user mode. ie: packing is only needed when we marshal a message from kernel mode to user mode.
ReactOS Development List ros-dev@reactos.org wrote on Fri, November 4th, 2011, 6:04 AM:
Hi! What I have run across in regards of ReactOS send message subsystem, ros is not packing before co_MsqSendMessage and unpacking after co_IntCallWindowProc! Instead packing before co_IntCallWindowProc with send message. Does that not raise any questions? co_IntSendMessageWithCallBack seems to do it almost right, but IntCallWndProc/Ret should be called when calling the client via co_IntCallWindowProc and should pack before the call to MsqWakeQueue and then unpack after the call to co_IntCallWindowProc. Confused?
Basing this on IntCallLowLevelEvent and co_IntCallLowLevelHook when the lParam is used to save information that could get lost in a stack switch or release.
Setting up the pattern; Pack before co_MsqSendMessage or related friends and Unpack after calling co_IntCallWindowProc to client. Have co_MsqDispatchOneSentMessage call something other than co_IntSendMessage so the Packed data can be handled correctly when calling to the client via co_IntCallWindowProc.
I'm sure Michael Martin has brought this up to me on many occasions. Let's see where this goes! Thanks, James
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi! The experiment failed. I already tested this last night. We allocate in co_IntDoSendMessage and doing it again made things worse and the system ran out of memory. ATM we are eating a lot of page pool and that is why win32k kicks out before the stack is full, when inside a message recursion. Still need to reposition IntCallWndProc/Ret when calling the client. Thanks, James PS. Good info!
On Fri, Nov 4, 2011 at 12:43 PM, Giannis Adamopoulos giannis.adamopoulos@reactos.org wrote:
Hi there, this document describes how messages are marshaled in win32k: http://mista.nu/blog/2011/02/11/thread-desynchronization-issues-in-windows-m...
imo SendMessage should works fine now. this is how it should work: in case we send the message to the same thread, call hooks, and call the window proc . Calling the window proc requires to pack the parameters. If we send the message to another process we queue the message and when the other process gets the message, it packs it in order to give it to user mode. ie: packing is only needed when we marshal a message from kernel mode to user mode.
-
Giannis Adamopoulos -
James Tabor