Well, the actual point where you meet hardware depends on what you are doing, of course. But to take your (excellent) example of "displaying text":
From abstract to hardware:
- user types letters into her word processor (wp)
- wp software first stores the letters in memory as part of the document being edited
- wp software then tells the user interface library it uses that it wants to display the text being edited in a window (this happens continually, of course). The UI library will be system-dependent (the Windows API on MS Windows, X Windows or QT etc. on Linux, AWT/Swing on Java etc.)
- The UI library will pass the data through a few more abstraction layers. In particular, it will perform rasterization (convert the information "show an A" into the pixel grid that represents an A)
- Eventually, the information will be passed to the device driver of the graphic card. This is where we meet "real" hardware :-). Normally, the graphic card exposes "video memory", i.e. memory on the card that the CPU can write to. The graphic card driver (which runs on the CPU) will write the pixels for an A to video memory.
- The graphic card's circuits will read the video memory and convert the data there into a video signal that goes out the video connector on the card and to the monitor.
- The monitor will display what looks hopefully like an A :-)
