3 ms·
> It was also the last OS I've used where an app had a central event loop. Windows is still like that if you use Win32 APIs directly. All GUI toolkits ever ma
by grishka 3y ago
> It was also the last OS I've used where an app had a central event loop.
Windows is still like that if you use Win32 APIs directly.
All GUI toolkits ever made are like that, but in most of the modern ones, this queue and loop are usually internal and you can only infer their existence by looking at the stack in a debugger or when something crashes.
- pjmlp 3y ago> Windows is still like that if you use Win32 APIs directly. Which is basically the only option for C and C++ developers, when using vanilla Visual Studio, unless they want to write libraries to be consumed by .NET instead, or use a third party framework. It is either raw Win32 or MFC, don't even bother with WinUI.
- p_l 3y agoWindows doesn't actually have a central event loop, which makes it pretty unique. macOS/iOS/etc have a central event loop in Cocoa - what more only initial thread is allowed to talk with windowserver! Xlib pretty much enforced single event loop per connection - XCB allowed more. In comparison, win32 applications can create an event loop ("message pump") per thread, and you can use GUI calls completely independently on them.
- kjs3 3y agoI recall there was an Ada X11 server (Mitre?) that used tasks instead of a single event loop, although they may have been papering over an event loop underneath.
- p_l 3y agoX11 server side is a bit different case - generally you control all message flows there in custom way. The windows message loop is essentially something you can create per thread, and "GUI" programs have one initialized for them (thus WinMain instead of main in C). But you need no special work to create more threads with more loops, in fact making every top-level window a separate thread is trivial (doing it for sub-windows like widgets might be slightly more complex though).