On Tue Nov 18 07:04:46 2025 +0000, Rémi Bernon wrote:
How hard would it be to initialize a proper wine thread for the main thread? I think it would make many things easier in winemac and not just traces.
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).