[molo_]

This is more than just a quirk. Lets go through the bogons here:

1. Signal system confuses notifications with commands

2. API ties windows to threads

3. System allows you to send WM_DESTROY from one thread to another even though it provides undefined behavior

4. DestroyWindow() can only be called from a particular thread (related to item #2)

5. The API doesn't detect that the window has been destroyed as far as the application is concerned (whatever happens in ForgetWorkerThread() or PostQuitMessage(), the window actually goes away) without a DestroyWindow() call.

In short, WTF.

[edit: format]

[roel_v]

"2. API ties windows to threads"

OK, so what's the alternative? Automatic locking at OS-level? How can the performance penalty in those many cases where it is not needed be justified? Same goes for your arguments 3, 4 and 5 btw. Why should such low-level functionality impose important design decisions on those who follow the documentation, just to protect the beginners who don't? I much prefer my raw control, thanks - and I'll happily take the few times I shoot myself in the foot with it, err, with it.

Despite its warts and its legacy cruft, the win32 is quite flexible, and easy to understand - at a very basic level, not much studying of under-the-hood stuff required. For an OS-level API, it packs a lot of power into a small set of concepts.

[molo_]

You argue for more control, but tying windows to threads at the OS layer is actually enforcing less control.

[innes]

2. API ties windows to threads

What UI APIs are there that don't have a concept of UI thread(s)? Coming from Windows, I'm used to UI work needing to be done on a UI thread.

I randomly googled these comments:

"Never, ever, touch the UI from outside your UI thread, in any version of Qt."

"Android UI toolkit is not thread-safe and must always be manipulated on the UI thread."

google "iOS 'non-UI thread'": 60 million results.

javascript: everything UI-related runs on one thread.

Do you do much UI coding?

[molo_]

This is about an OS-layer API, not a windowing toolkit API. Tying the window to a thread at this layer makes it impossible to have a single-threaded UI application. It is inflexible.