Do you have any specific example what are you planning to do from this thread message wise other than sending HW input messages (which just go to server, delivered to message queues differently and originate from "system" on Windows)?
Well for a start it is meant to run macOS host GUI integration, and similarly on Wayland would replace the existing Wayland compositor dispatcher thread. On macOS right now we use a custom event dispatch mechanism from the GUI thread to other window threads (ofc because that thread is not a Wine thread yet) and it would be better to get rid of this and use window messages directly. On Wayland the compositor dispatcher thread already uses window messages, some Wine internal, some not. Even if we can hope that we would only use internal messages eventually, various feedback and interaction from user drivers to win32u still *probably* rely on sending normal window messages. On Windows I assume these would be coming from dwm.exe, or some other system process, or are generated by the win32k kernel module. Similarly, it may be difficult to rule out PE callbacks entirely, although I'm not completely sure which part would need them it's hard to be sure that there are none. Maybe we can try not allocating a user stack for that thread and see what breaks, but overall that sounds like a lot of restriction when the threads it's meant to replace didn't have them. Another way perhaps, would be to park this thread until some module would need it, and then when it does, make it as if it was a newly created thread. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129701