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