EDIT: also, wondering why the above article says SetMenu requires a syscall, which is not mentioned in OP, I found this: http://www.fengyuan.com/article/win32ksyscall.html - looks like many GUI operations on Windows NT/2000 were implemented in kernel. That can't have been very good for performance to constantly context-switch to draw a window, no?
Moving bits of GDI and USER into the kernel was to improve performance in Windows NT 4.0, I think previously in NT 3.x they often needed user space context switches, whilst syscalls were cheaper (or something like that), especially for ones that ended up making driver / kernel calls anyway.
In hindsight a silly idea, trading off security for a speed boost.
In Windows NT 3, the graphics calls were stubs that sent LPC messages to the CSRSS, where the graphics drivers lived. At the time it was a very microkernel-like design, with message passing to server processes.
And the criticisms were the contemporary 1990s criticisms of microkernel designs, namely that all of this message passing was slow. (In reality, this is a red herring in most critiques of microkernels. In systems ranging from AT&T STREAMS to Windows NT today, I/O subsystems are built anyway around the idea of passing request packets around, be they mbufs or IRPs.) So it all got moved into the kernel, and then some of it in later versions got moved back out again, and rearchitected when windowing became more about compositing multiple whole bitmaps that could be constructed locally rather than drawing into a shared area with lots of clip rectangles.
> In reality, this is a red herring in most critiques of microkernels.
That’s true. I remember reading the L4 microkernel papers, showing how they achieved really decent message-passing performance on Intel 486 processors IIRC. I figure context switches are even more optimised on modern architectures.
In the early days, GDI was drawing directly into the framebuffer; making callers go through the kernel provides a limited amount of security against just drawing all over or reading the entire desktop, I suppose. Back in those days you had enough RAM to store one (1) copy of the framebuffer, the active one, and non-foreground windows or parts thereof simply got overpainted.
And WPF and subsequent toolkits follow a more modern model of "application draws into its own RAM region using DirectX which is then composited into the desktop".
EDIT: also, wondering why the above article says SetMenu requires a syscall, which is not mentioned in OP, I found this: http://www.fengyuan.com/article/win32ksyscall.html - looks like many GUI operations on Windows NT/2000 were implemented in kernel. That can't have been very good for performance to constantly context-switch to draw a window, no?