Where is the frame-buffer nowadays in the 2020s?!

The autonomous sharing video memory between CPU and GPU, where the GPU writes to frame-buffer. That is graphics processing is done independently, without stealing too much processor cycles, writing of the contents of GPU card memory to Mother-board frame-buffer memory.

Since the dawn of time, the frame-buffer has always been in the same place on an Intel-Box. You know if I write stuff to this area via a pointer, things will of course appear on the screen. If I were to copy all of the data in the frame-buffer I will have a copy or screen-dump of the display. Obviously when programs or subroutines write directly to the frame-buffer bypassing the OS, things appear on screen. For example, when opening an MS-Office document in Edge or Mozilla browser, Office component appears in the Browser window. For example, converting the contents of the frame-buffer to JPEG or GIF data stream to create screen snapshot.

An application or component running on Windows or X Box whose graphics or GUI routines write to video via Direct-X, could its coordinates for example from a Windows-Type API call. Such as "Client Area" or "PaintDC" event.

You've answered my question, Direct-X is not dead, but .. there is so much stuff, I mean APIs in Direct-X. I want to drill down to the essence. Suppose I have a pointer or hook directly to the frame buffer, if I write directly to the frame-buffer via this pointer, stuff will appear on the screen right? The old IBM-PC specification which goes back to the early 80s, defines always the location frame buffer in the same place. In the eqrly 90s, the coder would write just a single UI for example, Acrobat or Netscape. You could write a component with its own that addresses the frame-buffer which will run regardless of OS provided UI responds to mouse events.

The X Box concept as one where there is no operating-system, but a set of system calls and vectors that permit the direct writing of data to frame-buffer.