This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2009)

xterm, a popular terminal emulator designed for the X Window System

A terminal emulator, terminal application, term, or tty for short, is a program that emulates a video terminal within some other display architecture. Though typically synonymous with a command line shell or text terminal, the term terminal covers all remote terminals, including graphical interfaces. A terminal emulator inside a graphical user interface is often called a terminal window.

A terminal window allows the user access to a text terminal and all its applications such as command line interfaces (CLI) and text user interface applications. These may be running either on the same machine or on a different one via telnet, ssh, or dial-up. On Unix-like operating systems, it is common to have one or more terminal windows connected to the local machine.

Terminals usually support a set of escape sequences for controlling color, cursor position, etc. Examples include the family of terminal control sequence standards known as ECMA-48, ANSI X3.64 or ISO/IEC 6429.

Early adopters of computer technology, such as banks, insurance companies, and governments, still make frequent use of terminal emulators. They typically have decades-old applications running on mainframe computers. The old "dumb" video terminals used to access the mainframe are long since obsolete; however, applications on the mainframe are still in use. Quite often, terminal emulators are the only way to access applications running on these older machines.

Local echo[edit]

Terminal emulators may implement a local echo function, which may be erroneously named "half-duplex" (see Duplex (telecommunications) for information on half-duplex), or still slightly incorrectly "echoplex" (which is formally an error detection mechanism rather than an input display option).^[1][2][3][4]

Line-at-a-time mode/Local editing[edit]

Terminal emulators may implement local editing, also known as "line-at-a-time mode". This is also mistakenly referred to as "half-duplex". In this mode, the terminal emulator only sends complete lines of input to the host system. The user enters and edits a line, but it is held locally within the terminal emulator as it is being edited and not transmitted until the user signals (usually with the ⌅ Enter key on the keyboard or a "send" button of some sort on the user interface) the completion of the line. At that point the entire line is transmitted. Line-at-a-time mode implies local echo, since otherwise the user will not be able to see the line as it is being edited and constructed.^[1][5] However, line-at-a-time mode is independent of echo mode and does not require local echo. When entering a password, for example, line-at-a-time entry with local editing is possible, but local echo is turned off (otherwise the password would be displayed).^[6]

The complexities of line-at-a-time mode are exemplified by the line-at-a-time mode option in the TELNET protocol. To implement it correctly, the Network Virtual Terminal implementation provided by the terminal emulator program must be capable of recognizing and properly dealing with "interrupt" and "abort" events that arrive in the middle of locally editing a line.^[7]

Synchronous terminals[edit]

This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research may be removed. (January 2011)

In asynchronous terminals data can flow in any direction at any time. In synchronous terminals a protocol controls who may send data when. IBM 3270-based terminals used with IBM mainframe computers are an example of synchronous terminals. They operate in an essentially "screen-at-a-time" mode (also known as block mode). Users can make numerous changes to a page, before submitting the updated screen to the remote machine as a single action.

Terminal emulators that simulate the 3270 protocol are available for most operating systems, for use both by those administering systems such as the z9, as well as those using the corresponding applications such as CICS.

Other examples of synchronous terminals include the IBM 5250, ICL 7561, Honeywell Bull VIP7800 and Hewlett-Packard 700/92.

Examples of terminals emulated[edit]

Many terminal emulators have been developed for terminals such as VT100, VT220, VT320, IBM 3270/8/9/E, IBM 5250, IBM 3179G, Data General D211, Hewlett Packard HP700/92, Sperry/Unisys 2000-series UTS60, Burroughs/Unisys A-series T27/TD830/ET1100, ADDS ViewPoint, Sun console, QNX, AT386, SCO-ANSI, SNI 97801, Televideo, and Wyse 50/60. Additionally, programs have been developed to emulate other terminal emulators such as xterm and assorted console terminals (e.g., for Linux). Finally, some emulations simply refer to a standard, such as ANSI. Such programs are available on many platforms ranging from DOS and Unix to GUI operating systems such as Windows and Macintosh, to embedded operating systems found in cellphones and industrial hardware. Terminal emulators for Windows operating system are often called console emulators.^{[8][not in citation given][9][not in citation given][10][not in citation given]}

See also[edit]

• Binary Synchronous Communications
• List of terminal emulators
• Online service provider
• Serial interface

Notes[edit]

References[edit]

External links[edit]

• Terminal Emulation at the Open Directory Project
• Terminal Window Definition by The Linux Information Project (LINFO
  )

VT100

From Wikipedia, the free encyclopedia

 

 

For other uses, see VT 100.

"VT102" and "VT103" redirect here. For the highways, see Vermont Route 102 and Vermont Route 103.

DEC VT100 terminal

The VT100 is a video terminal that was made by Digital Equipment Corporation (DEC). Its detailed attributes became the de facto standard for terminal emulators to emulate.

Contents

[hide] 

• 1 History
• 2 Variants
• 3 References
• 4 External links

History[edit]

It was introduced in August 1978, following its predecessor, the VT52, and communicated with its host system over serial lines using the ASCII character set and control sequences (a.k.a. escape sequences) standardized by ANSI. The VT100 was also the first Digital mass-market terminal to incorporate "graphic renditions" (blinking, bolding, reverse video, and underlining) as well as a selectable 80 or 132 column display. All setup of the VT100 was accomplished using interactive displays presented on the screen; the setup data was stored in non-volatile memory within the terminal. The VT100 also introduced an additional character set that allowed the drawing of on-screen forms.

The control sequences used by the VT100 family are based on the ANSI X3.64 standard, also known as ECMA-48 and ISO/IEC 6429. These are sometimes referred to as ANSI escape codes. The VT100 was not the first terminal to be based on X3.64—The Heath Company had a microprocessor-based video terminal, the Heathkit H-19 (H19), that implemented a subset of the standard proposed by ANSI in X3.64.^[1]In addition, the VT100 provided backwards compatibility for VT52 users, with support for the VT52 control sequences.^[2]

In 1983, the VT100 was replaced by the more-powerful VT200 series terminals such as the VT220.

In August 1995 the terminal business of Digital was sold to Boundless Technologies.^[3]

Variants[edit]

VT101

The VT100 was also the first of Digital's terminals to be based upon an industry-standard microprocessor (in this case, the Intel 8080). Options could be added to the terminal to support an external printer, additional graphic renditions, and more memory (the "AVO" 'Advanced' Video Option — without this option, the VT100 could not display a full 24 lines of text when in 132 column mode). The VT100 became a platform on which Digital constructed related products.

The VT101 and VT102 were cost-reduced non-expandable follow-on products, with the VT102 including the AVO and serial printer port options of the VT100. The VT105 contained a simple graphics subsystem mostly-compatible with the earlier VT55. The VT125 added an implementation of the byte-efficient Remote Graphic Instruction Set (ReGIS.) The VT103 included a backplane socket for an LSI-11 minicomputer board and supported dual TU58 DECtape II block addressable tape drive which behaved like a very slow disk drive. The VT180 (codenamed "Robin") added a single-board microcomputer using a Zilog Z80 to run CP/M. The VT278 added a built-in PDP-8 processor, allowing the terminal to run Digital's WPS-8 word processing software.

References[edit]

1. Jump up^ Shuford, Richard S. (2005), DEC Video Terminals—The VT100 and Its Successors, retrieved 2012-12-08
2. Jump up^ http://ascii-table.com/ansi-escape-sequences-vt-100.php
3. Jump up^ http://www.boundlessterminals.com/history.html

External links[edit]

• DEC video terminal history
• VT100 user guide
• VT100 Series Technical Manual
• ECMA-48

[hide] v t e Digital Equipment Corporation video terminals   VT05 (1970) VT50/VT52 (1975) VT55 VT62 VT100 (1978) VT101 VT102 VT103 VT105 VT110 VT125 VT131 VT132 VT180 VT220 (1983) VT240 VT241 VT320 (1987) VT330 VT340 VT340+ VT420 (1990) VT510 (1993) VT520 (1994) VT525 VT LAN40

Categories:

• DEC hardware
• Character-oriented terminal

De facto standard

From Wikipedia, the free encyclopedia

 

 

A de facto standard is a custom, convention, product, or system that has achieved a dominant position by public acceptance or market forces (such as early entrance to the market). De facto is a Latin phrase that means "concerning fact." De facto means "existing in fact,"^[1] or "in practice but not necessarily ordained by law" or "in practice or actuality, but not officially established."

The term "de facto standard" is used in contrast with obligatory standards (also known as "de jure standards"); or to express the dominant voluntary standard, when there is more than one standard available for the same use.

In social sciences, a voluntary standard that is also a de facto standard is a typical solution to a coordination problem.^[2] The choice of a de facto standard tends to be stable in situations in which all parties can realize mutual gains, but only by making mutually consistent decisions. In contrast, an enforced "de jure standard" is a solution to the prisoner's problem.^[2]

Contents

[hide] 

• 1 Examples
• 2 Standards battles
• 3 See also
• 4 References

Examples[edit]

A selection of well-known and illustrative examples of de facto and de jure standards:

• with consolidation by tradition of use:
  • The driver's seat side in a given country starts as a user/industry preference, turning to a local tradition, then a traffic code local norm.
  • The QWERTY system was one of several options for the layout of letters on typewriter (and later keyboard) keys. It was developed to prevent adjacent keys from jamming on early and later mechanical typewriters, often attributed to the typist's speed.^[3] It became a de facto standard because it was used on the most commercially successful early typewriters.
  • The MP3 audio format started as an alternative to CD WAV (lossless format) for Internet music distribution, then replaced it — it is now supported by the vast majority of music players, audio transport,audio storage and noncommercial media. WAV and MP3 are also "de jure ISO formats".

• with consolidation by uniqueness and efficiency:
  • HTML (computer file format) started as "de facto" (1993-1995) and became the "de jure" standard (1995-present-day).
  • The PDF (computer file format) was first created in 1993 by Adobe. Adobe internal standards were part of its software quality systems, but they were neither published nor coordinated by a standards body. With the Acrobat Reader program available for free, and continued support of the format, PDF eventually became the de facto standard for printable web documents and e-books. In 2005, PDF/Abecame a de jure standard as ISO 19005-1:2005.^[4] As of 2007, PDF 1.7 is under development as ISO/DIS 32000.^[5][6]

Examples of long-time de facto but never de jure standards (for computer file formats):

• AutoCAD DXF: a de facto ASCII format for import and export of CAD drawings and fragments in the 1980s and 1990s. In the 2000s, XML based standards emerged as de facto standards.
• Microsoft Word DOC (over all other old PC word processors): one of the best known de facto standards. Due to the market dominance of Word, it is supported by all office applications that intend to compete with it, typically by reverse engineering the undocumented file format. Microsoft has repeatedly internally changed the file specification between versions of Word to suit their own needs, while continuing to reuse the same file extension identifier for different versions.

Other examples:

• The 1/2-inch (12.7 mm) spacing of the rollers in a bicycle chain.
• The IBM Personal Computer format, which used MS-DOS and Microsoft Windows operating systems, gained a large share of the personal computer market. Competing products like the Rainbow 100 were eventually withdrawn.
• Interpreted programming languages such as PHP that have multiple implementations tend to also have a de facto standard. In PHP's case the de facto standard is the binaries available from php.net, rather than the Phalanger implementation for example.

Standards battles[edit]

There are many examples of de facto consolidation (of a standard) by market forces and competition, in a two-sided market, after a dispute. Examples:

• Alternating current over direct current: see War of Currents.
• VHS over Betamax (see videotape format war): when the VHS format for videotape recording was introduced, other recording formats were already available in the market. Regardless of whether Betamax was superior from a technical point of view or not, the VHS format won the format war due to superior marketing tactics by its proponents. The market could not support two competing formats; VHS became the de facto standard and Betamax was eventually withdrawn.
• Blu-ray Disc over HD DVD (see high definition optical disc format war).

Examples of standards that are "in dispute" for turns de facto:

• OASIS's OpenDocument format (a de facto standard for UNIX users (Apache OpenOffice, LibreOffice, Calligra, KOffice et al. use it as default file format) vs Microsoft's Office Open XML format (a de factostandard for MS-Windows users).
• Adobe Flash vs Scalable Vector Graphics (SVG), for vector graphics web page animations.

See also[edit]

• Dominant design
• Free market
• Format war
• Real versus nominal value

References[edit]

1. Jump up^ thefreedictionary.com/de+facto adv; in fact, adj; existing in fact, whether legally recognized or not
2. ^ Jump up to:^a b Edna Ullmann-Margalit: The Emergence of Norms, Oxford Un. Press, 1977. (or Clarendon Press 1978)
3. Jump up^ QWERTY
4. Jump up^ ISO 19005-1:2005 - Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF 1.4 (PDF/A-1)
5. Jump up^ ISO/DIS 32000 - Document management - Portable document format - PDF 1.7
6. Jump up^ Adobe - Release PDF for Industry Standardization FAQ

http://technet.microsoft.com/zh-cn/library/cc778233.aspx

VT-UTF8、VT100+ 和 VT100 约定

 

VT-UTF8、VT100+ 和 VT100 约定

行业终端定义约定为您提供了一个从远程管理控制台（通常为特殊管理控制台 (SAC)）向服务器发送命令的平滑途径。这些终端定义约定确保了机制的一致性，可用于管理处于所有运行和失败状态的系统。

VT100 终端定义是用来对基于 UNIX 的服务器进行配置和执行紧急管理任务的标准约定。但是，VT100 不支持标准 PC 101 键盘布局中的所有键。对于 PC 101 键盘，VT-UTF8 约定使 VT100 不提供的其他键可用。使用 VT-UTF8，还可以使用通常用于管理任务的颜色和某些标准化的转义序列。使用 VT-UTF8，发送到串行端口的输出可以进行本地化，同时也保持了英语的 UNIX 可互操作性。

VT100+ 是 VT-UTF8 的子集，它只处理可兼容 VT100 的字符 -- 即 American National Standards Institute (ANSI) 字符 0 到 127。VT-UTF8 是用于通过终端模拟器（如 HyperTerminal）查看紧急管理服务输出，以及用于查看固件和服务处理器输出的首选终端类型。在这两种情况中，如果 VT-UTF8 不可用，则下一个最佳选择是按顺序尝试 VT100+ 然后尝试 VT100。

VT-UTF8 和 VT100+ 键盘到转义序列映射

如果计划使用 VT100、VT100+ 或 VT-UTF8 终端模拟器来与“紧急管理服务”或某些其他管理控制台通讯，则按下相关的键时应当自动发生该主题随后提供的键盘映射。

例如，要从一个使用 VT100+ 或 VT-UTF8 终端定义的终端向一个远程管理服务器发送 F2 键击，请按 F2。但是，如果使用并不支持所有按键映射或管理转义序列的 VT100 仿真软件或终端模拟器，则可以在终端中直接键入转义序列。例如，要从一个 VT100 终端发送 F2，请键入 <ESC>，然后键入 2。