4 ms·
Wow, thanks for exposing me to how braindamaged win32 really is.
by molo_ 15y ago
Wow, thanks for exposing me to how braindamaged win32 really is.
- mattmanser 15y agoI'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_ 15y agoThis 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]
- innes 15y ago2. 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_ 15y agoThis 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.
- to3m 15y agoWhat exactly is the problem with the approach?
- innes 15y agoSorry. 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.
- roel_v 15y ago"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++?
- roel_v 15y ago"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_ 15y agoYou argue for more control, but tying windows to threads at the OS layer is actually enforcing less control.
- amalcon 15y agoDoing 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 15y agoWow, 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.