Basically you would still need some API to put your frame buffer on the screen on any modern OS. Then the framebuffer could be how it used to be in the old days (look up mode 13h or mode x -vga programming) a linear array of memory. The first element of the array corresponds to the top left corner of the screen and increasing addresses follows the pattern of the raster of CRT displays (scanning left to right - top going down). Then you could plot points by calculating the address of the pixel you wanted to draw. There were also line drawing, polygon filling, sprite drawing... The only book I can think of is Abrash's Zen of ...graphics? Have to check for the exact title. What exactly do you want to do?

You can write a software rasterizer -- basically you create a region in memory that's an array of pixels, and then you write your own individual pixels into it. When you're finished, you can use you host's windowing system to display it, or you can shuffle it off to OpenGL/Direct3D through the usual layers, but not using any of their drawing routines. In the old days of DOS that's how graphics were done, except DOS was single user so you could take direct ownership of the graphics adapter's memory and write straight into it.

Drawing pixels, lines, circles, elipses, and bitmaps this way is pretty typical of a 100-level course in computer graphics. A 150 or 200-level course often extends this to 3D, where you first transform the 3D geometry in a software rendering pipeline, and then you rasterize shaded and texture-mapped triangles to the bitmap.

On most platforms you can't easily talk directly to the GPU, and GPU vendors aren't terribly open about their drivers' API surfaces or hardware command registers (Though, they've started being more open lately with the call for open-source drivers) and even if they were you're talking about 2000 pages or more of datasheet to get your head around.

If you want to talk directly to a GPU, your best bet would be something like the DreamCast or Raspberry Pi, but understand that even those "simpler" systems are vastly complicated, and the act of talking to them at a low level doesn't look much like graphics programming, if that's the part that interests you.

I guess my question's bottom line is this: How does C++ communicate with the graphics drivers and hardware?

Without an OS getting in the way, talking to hardware still requires poking interrupt handlers and hardware registers and DMA transfers and so on, none of which can be done with pure C++.

Well, that's not quite true. You certainly *could* do those things if you had access to (and understood) the bare-metal. Its true of course that going through at least a BIOS is common and more than enough "to the metal" for most everyone's tastes, but there's nothing inherently special about a BIOS; its just machine code implementing an abstraction layer over the barest of hardware. All those interrupt handlers and hardware registers, including those that control DMA, can be reached from the CPU, so I don't understand how that would prohibit C++.

Agreed, though, that its entirely impractical to attempt talking to modern hardware and getting modern features out of it. If that's your hobby, take up driver development, but even that's done at a substantially higher level of abstraction (with the OS providing IOCTL interfaces and other necessary or useful primitives).