Send Messages

[James Tabor]

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

[Giannis Adamopoulos]

Hi there,
this document describes how messages are marshaled in win32k:
http://mista.nu/blog/2011/02/11/thread-desynchronization-issues-in-windows-…
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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

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(a)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-…
>  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.
>