On Tue Nov 18 07:04:46 2025 +0000, Brendan Shanks wrote:
About a year ago I spent a while trying to make that work--my basic plan was to refactor NtCreateThreadEx so that rather than creating a new pthread, `start_thread` would be run by the main thread's runloop and then would do a unix call to a function that ran another runloop. This would run quite early (right after `signal_init_process()`) so that everything could assume that the main thread was a Wine thread, and winemac would be able to start its Cocoa runloop on the main thread later. For text-mode apps this worked, but running GUI apps would deadlock in `loader_init()`. IIRC loading imported DLLs would end up with win32u trying to load+initialize winemac, which would then block trying to start its runloop on the main thread, which is stuck trying to load winemac... I did see the `THREAD_CREATE_FLAGS_SKIP_LOADER_INIT` flag added recently, that could be a solution. I also wonder whether anticheats would be suspicious of a mysterious extra Win32 thread running that they didn't start. But even if we can get that working in the future, the non-Wine thread debug logging could still be nice to have (audio threads on Mac come to mind).
Okay, I don't have a strong opinion (although I would be very happy to get rid of non-Wine threads) and I think this MR is mostly up to @julliard appreciation.
Note that __wine_dbg_get_channel_flags will call and require NtCurrentTeb() on the very first trace call, so that cannot be coming from a non-Wine thread (even if it's unlikely to be).