I think this is fundamentally incorrect. Windows certainly allows processes and threads to exist with no GUI. The process doesn't need to have message loop, etc.
I suggest you check your other facts as well. Windows Internals is a good book to start.
Also just look at the definition of the PEB and TEB. There's plenty of slots for GUI stuff that's just left empty for headless apps, but the space is still allocated. In the end Windows is GUI first with non GUI apps a second class citizen.
As you can see the primary OS per thread structure has fields like "GDI pen" and "GDI brush". There's no separation of GUI specific stuff from other kinds of apps. Even the EXE file format distinguishes between "an app that will open a window to run in the background" and "a command line app". There's no notion of a program that could be used as both a GUI or a command line app depending on how it's run.
You make that sound like that was some kind of accidental leaky abstraction, when in fact it was by design. COM STAs were designed to work with GUI threads, full stop. If you aren't a GUI thread, you shouldn't be initializing yourself with STA COM.
> Also just look at the definition of the PEB and TEB. There's plenty of slots for GUI stuff that's just left empty for headless apps, but the space is still allocated.
I am perfectly fine with that, as it essentially removes thread-local GUI data from the application's TLS namespace. So a few extra pointers exist in the PEB and TEB, big deal.
> In the end Windows is GUI first with non GUI apps a second class citizen.
I don't really see how you can conclude that from STA COM and a couple of TLS slots reserved for the GUI.
But the whole thing is nevertheless backed in and coupled with low layers, including the kernel. There is just a kind of lazy init of GDI resources and the like so that the init is skipped for those processes which don't use them ever. It is fundamentally different from a general purpose OS like Linux which does not care that much (or even at all? I haven't checked) about graphic shits for processes.
The Windows NT kernel has been carefully designed like that from the start. In fact, the Windows part of NT is called a Windows subsystem. Windows kernel DOES NOT do windowing. The Executive, Kernel, Device drivers and the HAL are cleanly separated.
In fact, Microsoft provides Windows Nano Server which is a totally headless installation with no GUI components.
So of course it is unlikely there is something that e.g. draws pixels in the scheduler.
But for example there is still some space reserved in the TEB for GDI things. And kernel space code for graphic purposes related to processes and threads -- a kind of graphic "kernel" if you want. I mean: you just cannot take Windows and change all the low level graphics support code to a kind of WinWayland or WinAndroid. Even just programming raw NT processes is not officially supported IIUC, so you are bound to using e.g. Win32, and there definitively are some pieces of code all over Win32 (and not just in trivially graphic related APIs) which is aware of the existence of graphics related features on the OS.
So while it might be possible to recompile and/or rewrite parts of NT if you work at Microsoft to actually obtain a graphic agnostic OS (which is not even exactly what Nano Server is despite the re-engineering effort, because it is explicitly graphicless, not just graphic agnostic, and actually it now does not even exist anymore in a standalone form but only for containers, so you stick with your regular host kernel), that's not what I had in mind.
It depends what level of the OS you’re talking about, but the clean separation is not so clear.
CreateWindowEx does not run in the Kernel, yet it has parts that run in kernel space.
Linux also implements most features as separate modules that are linked together, that doesn't mean they aren't all part of the kernel.