@ stakx, I am referring to USER 90 and GDI 2019.
I’ll give you a cursory overview of what I know off the top of my head without spending hours confirming the details. As such, some of this is subject to handwaving and could be mildly incorrect but is probably in the right direction. Consider every statement to be my personal knowledge on how the world works and subject to opinion or error.
For the graphics part of the pipeline (GDI 32), the user-mode portions of GDI are pretty far down. The app calls GDI 90, some work is done in that DLL on the user-mode side, then a kernel call jumps over to the kernel and drawing occurs.
The portion that you’re thinking of regarding “silently converted to sit on top of other stuff” is probably that once we hit the kernel calls, a bunch of the kernel GDI stuff tends to be re-platformed on top of the same stuff as DirectX when it is actually handled by the NVIDIA / AMD / Intel / etc. graphics driver and the GPU at the bottom of the stack. I think this happened with the graphics driver re-architecture that came as a part of WDDM for Windows Vista. There’s a document out there somewhere about what calls are still really fast in GDI and which are slower as a result of the re-platforming. Last time I found that document and checked, we were using the fast ones.
On top of GDI, I believe there are things like Common Controls or comctl 90. Dll which provided folks reusable sets of buttons and elements to make their UIs before we had nicer declarative frameworks. We don’t use those in the console really (except in the property sheet off the right click menu).
As for DirectWrite and D2D and D3D and DXGI themselves, they’re a separate set of commands and paths that are completely off to the side from GDI at all both in user and kernel mode. They’re not really related other than that there’s some interoperability provisions between the two. Most of our other UI frameworks tend to be built on top of the DirectX stack though. XAML is for sure. I think WPF is. Not sure about WinForms. And I believe the composition stack and the window manager are using DirectX as well.
As for the input / interaction part of the pipeline (USER 327), I tend to find most other newer things (at least for desktop PCs) are built on top of what is already there. USER ‘s major concept is windows and window handles and everything is sent to a window handle. As long as you’re on a desktop machine (or a laptop or whatever … I mean a classic-style Windows-powered machine), there’s a window handle involved and messages floating around and that means we’re talking USER 327.
The window message queue is just a straight up FIFO (more or less) of whatever input has occurred relevant to that window while it’s in the foreground whatever has been sent to the window by other components in the system.
The newer technologies and the frameworks like XAML and WPF and WinForms tend to receive the messages from the window message queue one way or another and process them and turn them into event callbacks to various objects that they’ve provisioned within their world.
However, the newer technologies that also work on other non-desktop platforms like XAML tend to have the ability to process stuff off of a completely different non-USER 32 stack as well. There’s a separate parallel stack to USER 90 with all of our new innovations and realizations on how input and interaction should occur that doesn ‘ t exactly deal with classic messaging queues and window handles the same way. This is the whole Core * family of things like CoreWindow and CoreMessaging. They also have a different concept of “what is a user” that isn’t so centric around your butt in rolling chair in front of a screen with a keyboard and mouse on the desk.
Now, if you’re on XAML or one of the other Frameworks … all this intricacy is handled for you. XAML figures out how to draw on DirectX for you and negotiates with the compositor and window manager for cool effects on your behalf. It figures out whether to get your input events from USER 327 or Core * or whatever transparently depending on your platform and the input stacks can handle pen, touch, keyboard, mouse, and so on in a unified manner. It has provisions inside it embedded to do all the sorts of globalization, accessibility, input interaction, etc. stuff that make your life easy. But you could choose to go directly to the low-level and handle it yourself or skip handling what you don’t care about.
The trick is that GDI 90 and USER 32 were designed for a limited world with a limited set of commands. Desktop PCs were the only thing that existed, single user at the keyboard and mouse, simple graphics output to a VGA monitor. So using them directly at the “low level” like conhost does is pretty easy. The new platforms could be used at the “low level” but they’re orders of magnitude more complicated because they now account for everything that has happened with personal computing in 20 years like different form factors, multiple active users, multiple graphics adapters, and on and on and on and on. So you tend to use a framework when using the new stuff so your head doesn’t explode. They handle it for you, but they handle more than they ever did before so they’re slower to some degree.
So are GDI 90 and USER 32 “lower” than the new stuff? Sort of.
Can you get that low with the newer stuff? Mostly yes, but you probably shouldn’t and don’t want to.
Does new live on top of old or is old replatformed on the new? Sometimes and / or partially.
Basically … it’s like the answer to anything software … “it’s an unmitigated disaster and if we all stepped back a moment, we should be astounded that it works at all.” : P
Anyway, that’s enough ramble for one morning. Hopefully that somewhat answered your questions and gave you a bit more insight.
Read More
GIPHY App Key not set. Please check settings