OK...let's unhook the printer and let's replace it with an "old fashioned" "dumb terminal". A terminal like the DEC VT-100 or WYSE-150. Again with dumb terminals we deal with escape sequences. There are sequences to blank the screen, position the cursor, reverse video, blink, underscore, etc.
What do we have to do from an OS perspective to make this terminal work? The answer is--NADA--or at least not much. We already have a serial device driver to set parity and baud rate and send/receive characters. At the application level we need to learn a new "terminal control language" pertaining to the installed terminal (VT100, Wyse150)...but that's about it.
5. The Original Hayes Smart Modem...the PINNACLE of Escape Sequences
OK, let's take off the terminal and now attach an original 300-Baud Hayes External Modem. The Hayes "Smart Modem" represents the pinnacle of the power and ingenuity of escape sequences. Before Hayes modems, all modem phone calls were dialed with a handset. When the far end answered, either the handset was placed in "a cradle", or a button on the modem was pushed to "take over the call".
In the Hayes modem, touch-tone capabilities were embedded into the modem itself (for embedded dialing capability) and the modem operated in one of two modes. "AT-command mode"...or..."pass-through connected mode". When first powered on, the modem was in command mode, ready to accept all characters in what amounted to "a string of escape sequence control characters". They wer more commonly known as "AT dial command strings". In this mode the modem could "dial all by itself" as well as send back return/progress codes of the dial/connect process. When the far end answered and "Carrier Was Established", the modem switched into pass-through mode.
Other modem manufacturers copied the idea with their own but different command sets--IBM being the best example. However, IBM's modems failed miserably in the marketplace. They were good modems, but, the "command set non-compatibility issue" lead to their downfall.
Again, from the OS perspective, the driver for a serial port was accomplished back at the printer example. It's only the "modem command language" that presents a one-time challenge. And if all modems utilize the identical command set language, the challenge needs only be faced a single time.
6. The Moral of the Story
These examples show how a single physical connection and physical OS device driver can be leveraged over multiple hardware devices. The "Physical" device driver development needs to occur ONLY ONCE. And if the higher level command languages are standardized for each device type--those devices essentially become Plug n Play accross any conceivable combination of... computer, OS and programming language.
7. How Powerful Concepts Tend to Repeat Themselves
We've alluded to the power of escape sequences as they relate to hardware connectivity. What
other manifestations of this concept can we identify in the general computing scene?
What about Ethernet? Couldn't we consider the header of the Ethernet message a form of escape
sequence (containing control info--specifically destination address)? Extending on this theme
of enveloping data--what about IP? The entire Internet runs on this concept. Has the architecture
of the Internet ever had to worry about the trivialities of what kind of computer hardware, OS,
or applications are running at the host/user endpoints? Of course not -- the Internet as we know it would never be possible!
What about the "markup" in HTML or XML. Markup sure looks like escape sequences. The whole Web and HTML Browser technologies are based on it. And again, all of them are there tofacilitate functionality...A One Size Fits All environment!
- "Open Peripheral Hardware Connectivity, Part I"
- "Open Peripheral Hardware Connectivity, Part II"
- "Open Peripheral Hardware Connectivity, Part III"
- "Open Peripheral Hardware Connectivity, Part IV"
