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.
T think it can only work as win kernel module from the app's view, and win32k can't send messages directly to threads, it can only put those to queues on the kernel side. So should we be doing probably? If that is WINE internal messages from user drivers, maybe it can be made an execption to receive those? Provided that thread's message processing won't reflect itself in any possible user hooks. Or they would need a special "kernel side" messaging mechanism that won't go through normal NtUserGetMessage / NtUserPostMessage with all the accompnying processing and hooking.
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.
Yes, user stack is not needed for it and I'd think not allocating it would be a good idea. PE code can't work there. First, even for "normal" apps, this thread doesn't have loader initialized (and initializaing it will immediately make it interfere with everything and very broadly visible), that alone puts a lot of unobvious restrictions on what the thread cannot do (starting from HeapAlloc even maybe), but that is only the top of that. Then, we should assume that any PE code can be hooked / injected and check specifically for unexpected threads doing things. Thread exection is the most commong hacking technique and DRMs / anticheats are most keen of detecting weird threads. Apart from all those concerns, I think we are sticking to strict architecture rules on this level. This is "kernel" thread which exists on Unix side only. The only differentce the new way is adding is allowing it to interact with server and otherwise use kernel side API. But not to present itself on the user / PE side anyhow. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129702