Content deleted Content added
ClueBot NG (talk | contribs) m Reverting possible vandalism by 5.158.93.54 to version by Guy Macon. Report False Positive? Thanks, ClueBot NG. (3776308) (Bot) |
|||
Line 11:
From [[console application|text application]]'s point of view, a text screen (and communications with it) can belong to one of three types (here ordered in order of decreasing accessibility):
# A genuine [[text mode]] display, controlled by a [[video adapter]] or the central processor itself. This is a normal condition for a locally running application on various types of [[personal computer]]s and [[mobile device]]s. If not deterred by the [[operating system]], a smart program may exploit the full power of a hardware text mode.
# A text mode [[emulator]]. Examples are [[xterm]] for [[X Window System]] and [[win32 console]] (in a window mode) for [[Microsoft Windows]]. This usually supports programs which expect a real text mode display, but may run considerably slower. Certain functions of an advanced text mode, such as an own [[raster font|font]] uploading<!-- BTW what about raw keyboard input? -->, almost certainly become unavailable.
# A remote [[text terminal]]. The communication capabilities usually become reduced to a [[serial line]] or its emulation, possibly with few [[ioctl]]()s as an [[Out-of-band data|out-of-band]] channel in such cases as [[Telnet]] and [[Secure Shell]]. This is the worst case, because software restrictions hinder the use of capabilities of a remote display device.
Under [[Linux kernel|Linux]] and other [[Unix-like]] systems, a program easily [[graceful degradation|accommodates]] to any of the three cases because the same interface (namely, [[standard streams]]) controls the display and keyboard. Also, [[#Under Unix-like systems|specialized programming libraries]] help to output the text in a way appropriate to the given display device and interface to it. See [[#Windows|below]] for a comparison to Windows.
| |||