MS Windows is definitely a good counterpoint to this blog post. Whatever the kernel/userspace split (which has changed over time), the basic Windows model is that the logic & code of the windowing system is all in the 'server' (i.e. the OS libraries, sometimes including kernel-space code).
The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.
Actually the logic and windowing happens in each client in user space, which is why you can’t build alternative window managers, and Microsofts policy of compatibility ‘shims’ and hacks that allow chosen old software (and they choose a lot of software) to work on modern systems has nothing to do with it.
Have a quick search online, and you'll find plenty of alternative window managers for Windows. But it's besides the point, because both styles of graphical windowing systems can support alternative window managers.
The Windows ‘solution’ is really fragile and dangerous because it involves injecting code into all programs.
If there’s a vulnerability the whole system is compromised, if there’s instability the whole system crashes and if part of the system is separated out, like what Windows does with windows belonging to elevated processes, these windows follow the original rules set by Microsoft.
The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.