This is part of the huge and unending clusterfuck of vulnerabilities that people find in the Windows graphics stack, which was wisely moved to kernel space early on in NT's life, which makes all these vulnerabilities much more critical than they would be otherwise.
I recall getting stuck in a DLL hell back in Windows 3.11 ATMFD's granddaddy was still supposedly serviced more directly by Adobe themselves and it was a free for all across various application installers which versions they attempted to install. Windows 3.1 era Games had a bad habit of stuffing weird old versions of Adobe Type Manager into their installers. I forget details of the offenders, but there was a particular many-times-too-many repeated sequence of installing an application then immediately repairing/reinstalling Office to fix the Adobe Type Manager. Forgetting that last step IIRC was a very subtle problem until it wasn't, starting as weird message boxes and then eventually culminating in (days of application use later) Stop Codes that crashed Windows 3.1 back to DOS.
Moving things into the kernel is one heck of a sledgehammer solution to DLL Hell, at least.
(Windows 10 has slowly moved a lot of the graphics stack back out of kernel space. It appears to be moving the right direction, just very slowly.)
It was moved out in Vista with great fanfare. A side effect was GDI was no longer hardware accelerated. With windows 7 and later hardware acceleration was added back necessitating parts of it return to the kernel. For obvious reasons this wasn't as widely publicized.
I seem to recall having a discussion with you a while back where Windows would just leave kernel pointers out in userspace, which seemed to do with GDI as well.
You draw to a DirectX surface rather than the raw frame buffer but it is by no means translated to D2D. D2D has a "GDI" emulation mode, but it's more than worthless if you care about rendering fidelity with the real thing - and you probably do if your still on GDI these days.
Ah good to know - I was under the incorrect impression that the D2D "GDI" emulation mode was the only codepath remaining. Btw any pointers on how to keep track of the graphics stack in Windows? In the past there used to be a treasure trove of blogs and content in MSDN but over time that community has frittered away. Any pointers on how to keep track of what Microsofts graphics roadmap is going forward?
The simple answer is use D2D/Dwrite for low level render code in new projects. If you use C# there’s probably higher level wrappers over these. Some of the older C# APIs wrap GDI+ which is pretty slow and renders text really poorly so go with whatever new stuff they have now.
I don’t know of any specific blogs/resources. I used to work on Excel’s render code so had a bit of an inside view.
I worked on some inhouse tools similar to Excel (rendering highly customizable grids) so efficient 2D rendering is of high interest to me. This is from C++.
