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.
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.
amalcon|14 years ago
Lagged2Death|14 years ago
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|14 years ago
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_|14 years ago
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]