On Mon Feb 9 15:38:17 2026 +0000, Paul Gofman wrote:
If you mean component-specific threads, like, e. g, what dinput threads, those are different. They are spawned much later in initialization process, only after that component initialization. At this point Windows also has a bunch of various service threads, even if those don't exactly match what we are doing DRMs have to consider those possibility. This thread is going to be active at the process start without loading any specific WINAPI components yet, at this point Windows doesn't have any extra service threads. Then, those threads have some meaningful start address in, e g. dinput.dll and backtrace to that start, and not the bogus start address duplicating the app's main thread. Well the start address is mostly a detail, we could very well put some ntdll address there if necessary. The necessity to keep that thread absolutely hidden on startup is more of an issue. I know it's not happening on Windows but how confident are we that it needs so be like that? At what point is it okay to spawn a thread?
That thread needs to be able to communicate with other application threads, especially it needs to be able to send window messages, otherwise it becomes a bit pointless to have and cannot replace Wayland thread, or be used to simplify macOS driver much either. We could maybe use only Wine internal hardware messages, trying to not leak anything into user space but that becomes tricky and error prone. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129212