That is not remotely true. Windows GUI messages are implemented as part of the win32k.sys device driver via traditional IPC and synchronization mechanisms.
> Other IPC systems you'd expect to be GUI independent like DCOM end up using this under the hood.
That's not entirely accurate either. Yes, DCOM on GUI threads use Windows messaging for IPC for compatibility reasons that go back to OLE on 16-bit Windows.
But the multithreaded apartment (ie, COM for a modern OS) is completely independent from the GUI; it is layered atop Microsoft RPC, which itself uses the NT kernel's ALPC mechanism for IPC.
If you're not creating and working with COM objects on a GUI thread, then you should not be using old-style single-threaded apartment COM. Yes, even if your program is only single threaded, you should still be initializing COM to use the multithreaded apartment.
Moreover this is the default mode. The CoInitialize API puts you in a STA by default. To get the GUIless MTA you must use the replacement CoInitializeEx API. Obviously COM programmers know this and it's not a big deal, but I don't understand this resistance to accepting that an OS literally called Windows might make windows and window messages an important part of the API.
And I did that window messages run in the kernel, which you accept - even in latest versions the (mandatory) win32k.sys driver implements the message syscalls. I'm not sure how you know what the implementation looks like, but I'm pretty sure it used to be well optimised. It'd be odd if it no longer was.
Now I haven't claimed every IPC primitive in Windows is GUI based, have I? But fundamental features use it, including features like RPC that you wouldn't imagine do so, and that supports my point that it's called Windows for a reason. The GUI aspects historically integrate deeply into everything. As yet one more example, if the dynamic linker encounters a problem during program startup, you get a GUI message box telling you so, even if the program was started from a console.