[molo_]

Wow, thanks for exposing me to how braindamaged win32 really is.

[amalcon]

Doing this is more-or-less like calling a signal handler directly in a UNIX program: you're not likely to get the result you want.

[Lagged2Death]

Wow, thanks for exposing me to how braindamaged win32 really is.

To be perfectly fair, this arrangement (which I don't like either) is actually inherited from the Windows 3 API (Win16) and very likely goes back all the way to Windows 1.

[mattmanser]

I'm sure every operating system has weird quirks like this.

The odd thing about this article is it tries to pretend it's the user's fault. Which is doubly odd as Raymond Chen's stuff is usually pretty good.

[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.

[chollida1]

Just a quick meta response because i see you're new.

You don't need to sign your posts as your user name appears above your post.

[molo_]

Well it seems that we hit the nesting limit, so I will reply to this post. I'm not including a URL, I'm just signing my name. Please keep in mind that is a guideline.

[molo_]

Hi, thanks but that is what I've been doing for ages.

[roel_v]

How?

[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.

[roel_v]

"This is about an OS-layer API, not a windowing toolkit API"

What does that even mean? Of course you can have single-threaded UI applications in Windows, the majority of them are. Have you ever written a Windows application in C or C++?

[to3m]

What exactly is the problem with the approach?

[innes]

Sorry. I've read your comment a couple of times and am unable to make any sense of it. Win32 is a (dated, clunky) API for writing GUIs (in part). "OS-layer" is babble in this context.

And yeah, i would stop signing your posts - it comes across as conceited somehow; like each comment is a big deal.