5 ms·

> poll and select That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have

> poll and select That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead. Is that correct?

quotemstr 13y ago
Between threads, you rely exclusively on PostMessage anyway. You can't directly call into a routine on a different thread, so SendMessage to a window owned by another thread just posts the message to a special queue that's serviced before the regular message queue, then blocks until the other thread's window procedure processes the message. In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
- wfunction 13y ago
  Hmm... yeah, that does sound very similar. Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
  - deleted 13y ago
    [deleted]
  - quotemstr 13y ago
    You may be interested in http://mista.nu/research/mandt-win32k-slides.pdf http://mista.nu/research/mandt-win32k-slides.pdf
    - wfunction 13y ago
      Thanks, I took a look at that... but it doesn't seem to quite explain what I meant. I was thinking more like, there's no need for SendMessage() to go from user->kernel->user, even when it's on the same thread. It could just do a system call to get the wndproc for the given window, then call the wndproc from user-mode directly. Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
      - yuhong 13y ago
        It does this already when the window is on the same thread if no window hooks are installed. When the window is on a different thread, it is GetMessage or PeekMessage on the target thread that notices the sent message and does the user-mode callback to call the window procedure.

quotemstr 13y ago

Between threads, you rely exclusively on PostMessage anyway. You can't directly call into a routine on a different thread, so SendMessage to a window owned by another thread just posts the message to a special queue that's serviced before the regular message queue, then blocks until the other thread's window procedure processes the message. In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.

wfunction 13y ago
Hmm... yeah, that does sound very similar. Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
- deleted 13y ago
  [deleted]
- quotemstr 13y ago
  You may be interested in http://mista.nu/research/mandt-win32k-slides.pdf http://mista.nu/research/mandt-win32k-slides.pdf
  - wfunction 13y ago
    Thanks, I took a look at that... but it doesn't seem to quite explain what I meant. I was thinking more like, there's no need for SendMessage() to go from user->kernel->user, even when it's on the same thread. It could just do a system call to get the wndproc for the given window, then call the wndproc from user-mode directly. Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
    - yuhong 13y ago
      It does this already when the window is on the same thread if no window hooks are installed. When the window is on a different thread, it is GetMessage or PeekMessage on the target thread that notices the sent message and does the user-mode callback to call the window procedure.