mallard wrote:
Well, in the beginning, there were teletype machines (that's where the name "TTY" comes from). They were basically electronic typewriters (to the point that they often shared major components), but rather than have the printer connected directly to a keyboard as an electronic typewriter, they'd have a communications port such that anything typed would be sent over the port and anything received would be printed. Teletype machines actually pre-date computers, being used for various forms of text-based communication for decades before someone realised a computer could interface with that communications port and provide a ready-made "interactive terminal".
Terminals with screens (or "Glass TTYs" as they were often called in their earliest days) were the second generation devices, first appearing in the mid-late 1960s, with paper-based units continuing to be common (because they were cheaper) well into the early UNIX era.
The first computer terminal had a keyboard and blinkenlights; teletypes found their way to computers after that and were also known as
hard-copy terminals, which technically makes glass TTYs the third generation, but this history lesson is an unnecessary tangent.
Quote:
Anyway, the whole idea of a "TTY" or "PTY" these days is very much a legacy UNIX concept that I'd strongly suggest not copying verbatim in a new-build OS (if you're just writing a classical UNIX clone, you can stop reading here). IMHO, out-of-band signalling (i.e. have "control" calls entirely separate to "write to the display" calls) is far superior to the old concept of "escape sequences" (they were invented solely because there was no other way to send commands to a physical terminal connected via a single serial communications port) for controlling a text-based interface and it's full of legacy cruft (the "terminfo" system, used to attempt to make applications less dependent on the exact type of terminal in use contains literally thousands of definitions for slightly different types of terminals; I'd estimate that well over 99% of them haven't been seen outside of a museum/collection for 20+ years).
In-band signaling has a lot of benefits, such as being able to pass things with control sequences all the way through a Unix pipeline, and the ability to treat something like a socket as an equivalent bytestream to a terminal output. Personally, I would have liked to have
more in-band signalling for TTYs, but we ended up with out-of-band control of bitrates, echo modes, etc. The biggest benefit, in my mind, is that no synchronization is needed if you have only one in-band output stream.
Terminfo and the
former lack of standardization in control sequences was an unfortunate reality of having dozens of manufacturers building new products in a highly competitive landscape, but as someone who has built terminal applications in the modern era that employ raw escape sequences, I've found the problem doesn't really exist anymore. There's a standard set of DEC sequences popularized by Xterm that everyone is expected to implement now.
Quote:
My OS uses a much more modern terminal concept; out-of-band control (no "native" escape sequences), graphics mode support and built-in pointing device support. My GUI runs entirely within a full-screen terminal, as could any graphical application. I even have a userspace library to provide emulation of an old-fashioned escape-sequence controlled terminal entirely within a process that wishes to output that way (i.e. nothing in kernelspace knows anything about such sequences).
You're fighting a bogeyman here, as this is never something a kernel should concern itself with. (That a handful of OSes implement terminal emulators in their kernels is an amusing aside, but even in Linux there have been efforts to remove the kernel's "console" emulator)