I'm confused when looking into graphics - specifically with operating systems.

I mean, how can a computer render a CLI/console along with a GUI?

GUI's are completely different from text. And how can we have GUI windows that display text interfaces, ie how can we have CLI in modern Graphics Operating system - that's what I'm mainly trying to grip on to.

How does graphics get rendered to display? Is there some sort of memory address that a GPU access which holds all pixel data, and there system's within OS's that gather the pixel position of windows and widgets, along with the Z Index and rasterize them to that memory address, which then the GPU loads to the screen?

How about the CLI's integrated with Graphics? How does the OS tell the GPU that a certain part of the screen wants to display text while the rest wants to display pixel data?

  • Too technical for Programmers, maybe? Mar 28, 2012 at 22:49
  • 3
    How can a piece of paper render Mona Lisa and Hamlet? Remember that text is no more than a subset of graphics. For me the hard question would be: how does a VT100 terminal render a glyph from an ASCII code.
    – mouviciel
    Mar 29, 2012 at 7:45
  • You may find the old post Why aren't console windows themed on Windows XP? over on The Old New Thing interesting. While it doesn't directly address your question, it (and the ensuing discussion in the comments) does talk about some of the design decisions that go into displaying pure text inside a GUI.
    – user
    Mar 29, 2012 at 11:35

1 Answer 1


It seems like your main question is how GUIs and CLIs can exist together at the same time, such as the Windows command console (cmd.exe).

It's actually not as complicated as you might think. First, remember that even a GUI needs to be able to render text, so you can read filenames, labels on controls, or work with text inside of programs. It does this by having font files that contain descriptions of how to turn various characters into glyphs (shapes) on-screen or in a printout.

Once you understand that basic principle, the answer is obvious: you can make a console program on top of a GUI by having an emulation layer that renders the text the way a CLI would and a font file that looks like console text. (Note: I'm not actually claiming that that's the way Windows does it. I don't know how it works under the hood. But it could easily be done that way.)

As for the second part of your question, as to how graphics get rendered, yes, there's a special memory location somewhere that holds pixel data. That's called a frame buffer. Back in the old days, you could get direct access to the frame buffer and play around with its pixels directly. Nowadays, that's highly discouraged if not impossible, for various reasons. Instead, you go through higher-level graphic-drawing APIs, where you describe to the system what you want to do and it takes care of the details.

This has several advantages. First, it means that you don't need to know where the framebuffer is in memory or how exactly its data is formatted. Second, and closely related to the first point, different video card manufacturers can set up their framebuffers in different ways, and you don't need to know how to write specific graphics code for each version. You let the graphics APIs take care of that. And third, (and closely related to the second point,) it means that things can change in the future without breaking existing code.

For example, there was a major change in the way Windows handles forms ("windows") when they introduced Vista, that you probably never noticed unless you do graphics programming. It used to be that every form got drawn directly to the screen. This meant, among other things, that if you dragged a second form over a visible form and then away again, the form on the bottom would have to repaint itself because that image data was lost.

But Vista introduced a compositing window manager, which basically means that each form gets its own virtual framebuffer somewhere in memory, and it just draws everything to the screen based on position and Z-order. Now you can drag one form in front of another all you want and it won't invalidate the other form's pixel data; forms only need to be repainted when their own content changes. And they were able to implement that and make it work just fine on existing programs because the existing programs all use predefined drawing APIs.

  • So, It doesn't really matter if a console is displayed in text mode of graphics mode, just as long as there's a representation of the console that is getting rendered. In essence, cmd and bash arn't true cmd lines. I just don't get how OS's can use a higher resolution then what the bios VESA resolution is, but I believe google can help me out with that, thanks :D Mar 29, 2012 at 6:37
  • @Nathaniel Bennett: bash most definitely is a "true command line"; the rendering as a window is done by separate programs like xterm or konsole. However, cmd.exe in windows does seem to combine both functionalities. Mar 29, 2012 at 8:10
  • @NathanielBennett BIOS is just a standard interface available at a very early stage on a PC. Most GUI rendering does not use BIOS at all.
    – user1249
    Mar 29, 2012 at 8:23
  • 1
    @MichaelBorgwardt: No, the equivalent rendering in Windows is done by CSRSS.EXE.
    – MSalters
    Mar 29, 2012 at 8:27
  • @Nathaniel: The BIOS's text output is just another standardized API. OS's use a higher resolution than that by talking to the graphics card's hardware-specific driver directly instead of going through the BIOS. Mar 29, 2012 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.