From Standard Out to My PC Screen [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 7 years ago.

Improve this question

In any introductory course the first thing you learn is that System.out.println, printf, etc. prints to Standard Out and pops up on your screen. I would like to know all of the detailed steps in that process. In short I know the following are involved but I don't know all the specifics:

• A system call is made to the kernel
• The text is rasterized
• The CPU is executes program instructions (using a shared library right?)
• Drivers for the screen are involved
• The CPU talks to some bus (PCI? or PCIe?) on the motherboard
• The bus sends data to the screen

Some specific questions I have are:

• How does the computer know Standard Out means put on screen? What if there's more than one screen connected? How does it know a screen from a hard drive or an Ethernet jack?
• How does the video driver get involved in the equation? How does it know what driver to use?
• How does the CPU put the data on the bus? For example, how does it know what address to write to? How is that address used to send the data to the write place? Can you provide some example CPU instructions that are used in this process?

Thanks!

Answer 1

Also, stdout is just that. The concept of a "screen" is an OS abstraction. For example, in Linux and some other UNIXes, your process is associated with TTY or PTY (teletypewriter and psudoteletypewriter), which is where stdout can point, but it doesn't have to. Stdout can point to a file, a network, anything! And you have to make the distinction of a true terminal (think Ctrl-Alt-F1 on Ubuntu) and a pseudo-terminal (think Konsole, CMD, Terminal.app). When you have a pseudo terminal, that lives in a window, which makes things 10 times more complicated. If you have a psuedo-terminal, here might be the steps (Linux):

1. Make a system call (write) to write to FD 0 a string.
2. write will write to the file associated with FD 0, which is most likely attached to your PTY's slave controller. Then, the terminal emulator (the master controller) receives the output.
3. It uses some sort of graphics library (GTK, Qt, SDL, OpenGL, etc.) to render to it's window buffer. This is where font fancies will happen.
4. The window buffer is passed to the window manager and the X window system, who draw it along with all of the other windows and things.

As for the video driver, the video driver is used by two parts of this system: X windows and OpenGL. The video driver is set by configuration files and hardware discovery, in which the OS (or the BIOS) probes the system to find all available hardware and load drivers.

How does the CPU put data in the bus? (the following, to the best of my knowledge, is x86 and Linux specific). Well, the data has to get to the graphics card somehow. It can happen in a few ways. Either the video card maps some video memory into CPU memory, or you use x86 I/O ports (the in and out instructions).

Lets look at the first situation. All video cards map a text video buffer at the segment address 0xb800 (and some also map some sort of 3d data buffer somewhere, but I'm not sure). So if I want to write the string "Hello, world" to the video buffer, here's some x86 ASM:

mov es, B800H ;Set the extra segment to the video buffer
mov ds, cs ;Set the data segment
mov esi, hellomsg ;Set the source index to the hellomsg
mov edi, 0 ;Video buffer offset
mov ecx, [hellolen] ;How many characters
rep movsb ;Copy

;;Data
hellomsg db "Hello, world!" ;Null terminated hello world
hellolen dw 13

By the way, that's driver or OS level ASM -- it requires access to the video buffer directly, or at least, to have the video buffer mapped into your address space. The other option, I/O ports, is where the driver gets involved. Because what ports and what to write to them is graphics card dependent, I won't give an example, but you can look into it.