On Sat Feb 14 10:17:32 2026 +0000, Rémi Bernon wrote:
YW, then there's still the concern you raised about sending window messages. Do you have something specific in mind about the functions that may be used to figure the thread the messages are coming from? Would this be about window message hooks? Thinking of this part, I came to another question to previous part: if app does OpenThread() with this thread ID, will it still succeed or not? Looks like there is another point of leaking this thread info, get_ptid_entry() doesn't use thread lists. I think to be fully correct that should properly fail as will non-existent thread ID.
I think that in the first place under no circumstances this thread can execute any PE code (do any user callbacks). If a hook would execute in that thread that can't be happening. Then, I am not sure I understand the intention what this thread would do which would imply sending "not system originated" messages directly to other threads. First, regardless of all these low level issues, it can't probably do SendMessage() anyway, even with timeout, it is not supposed to block ever? Then, in general, thread ID of this thread should never appear anywhere user visible, it is like it doesn't exist (it makes no sense to have thread id somewhere for thread which doesn't exist from app's standpoint). 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)? I don't yet understand why that general thread would want to behave as a normal thread in window messages exchange at all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10058#note_129698