Similar to what https://gitlab.winehq.org/wine/wine/-/merge_requests/9579 and https://gitlab.winehq.org/wine/wine/-/merge_requests/10058 were doing. This is just for winemac, the magic happens in ntdll where CFRunLoopRun start proc is treated specifically by `spawn_thread` and doesn't actually spawns a new thread but schedules a server_init_thread call in the pre-existing main loop, initializing Wine thread data and recursively calling the macOS main loop without (I think?) returning from it. It then makes it possible at least to use Wine tracing subsystem in winemac main thread, and ultimately should make it possible to call some win32u functions directly from it too. We cannot process window messages there, it's a system thread without a user stack, but it can interact with win32u state and post messages to other threads. It's still going to be a long road ahead if we want to replace winemac internal events (which I think would be nice), because many things still expect some winemac specific threading, but it would be possible at least. Ultimately I still think that it would be nice to generalize this "main" system thread into a ntdll "sched"-uling subsystem that could back all of the win32u drivers host fd polling / UI event processing / scheduling needs, including for an in-process window compositor, as well as any extra unixlib fd polling / timer / scheduling we might find useful to have. There was for instance some discussion about how to integrate DBus connection polling nicely, and this could use it. On macOS this would be the main thread, on other platforms a system thread would be spawned as needed. -- v2: ntdll: Allow converting the macOS main thread into a Wine thread. winemac: Return early on failures in macdrv_start_cocoa_app. https://gitlab.winehq.org/wine/wine/-/merge_requests/11333