Per Jessen said the following on 03/01/2013 05:57 AM:
Anton Aylward wrote:
Per Jessen said the following on 02/28/2013 03:15 PM:
There is also the little matter of two completely different environments - a IBM 3270 terminal vs the DEC VT100 (essentially). The former is screen based, the latter is line based.
Eh? The KSR-33 was line based but not the VY-100. As far back as 1982 I was using VI on VT100 and clones (made by Wyse or someone) in full screen mode. That's what TERMCAP was for. Thank you Bill Joy.
Not the interface, the technology. Everything you send to a VT-100 is line base, one long string, optionally with ANSI control characters. A 3270 is more like a directly addressable full screen. Well, I guess whatever comes down the line is a string too, but that's what a 3270 looks like to a programmer.
And its just the same with VI and other applications that used the ncurses package and the like (ncurses was 'extracted' from the original VI's mechanisms). They maintain a internal screen logical image. IIR Bill Joy's VI kept this as a linked list. I once had to work on that code and boy was it crufty! One man's really optimized work and almost unintelligible to mere mortals. the code-base for VIM is so much nicer. So, to the programmer working with ncurses the programming model was a directly addressable full screen. You updated it and then did a 'sync' -- "refresh()', and the algorithms worked out the best/optimal/minimal stuff to send to the terminal. http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#updating And there in is the difference. TERMCAP tried to support cursor addressing and such things as as region (not just single line) updates. Some terminals could update a region in the middle of the screen: specify a bounding box and fill it thusly. So using ncurses was efficient on bandwidth (great over a slow modem). The programming reality was that there were higher level layers of code that made the manipulation of such easier, all the way up to 'layers' which implemented a text-based windows system. (e.g. http://osr507doc.sco.com/en/man/html.M/layers.M.html, http://osr507doc.sco.com/en/man/html.C/layers.C.html) You might also find the referred to as 'panels' http://frank.harvard.edu/~coldwell/ncurses/ncurses-intro.html#panels Of course this got rapidly replaced when the IBM PC came out and made cheap graphics and eventually GEM and MS-Windows available. I still have the SVR4 and USG manuals .. moment. Here we are: AT&T System V Interface Definition Volume 2, Part VI Terminal Interface Extension Definition. P426 Curses - CRT screen handling and optimization package. ISBN: 0-932764-10-X
One funny thing is - the standard IBM line length is 80 chars, which goes all the way back to punchcards. I have not worked with punchcards myself, but IBM JCL is nothing but "screen" punchcards.
I had to for a very short time. I hated it and soon found a PDP-11 running RSTS that supported RJE. That PDP-11 was then knobbled by some post-grads to run UNIX version 5, and I didn't want to let go, so they took me along as test case for their work on compiler development and I got to play with the new languages they were dreaming up. And UNIX. Eventually I did system and kernel hacking on V6 and V7, then on System III and System V commercially.
However, think about how often we limit ourselves to 80 chars - in email, in code, everywhere. If it wasn't for punchcards, we wouldn't have a continuation character.
Yes, but there's a lot about UNIX and the 'Net which doesn't acknowledge line length.
Definitely.
Strictly speaking email doesn’t limit itself to 80 columns. Much of the mail I get seems to have been composed with long lines - one line per paragraph, and its up to the display to do the soft line wrap. So if I shrink or grow the width of the window the individual lines alter in length. Well, maybe. I've set Thunderbird to wrap at 79 no matter what, but its easy to see this behavior if you use a word processor such as OpenOffice/LibreOfice. Oh, right, that's cos its HTML mail. EVIL!
Again, as far bask as the 1980s protocols such as NEWS/NNTP the concatenation of the sites the message had passed though produced lines that were of indefinite length,
Hmm, don't they follow email standards? I'm sure USENET is where we first saw base64 encoding folded into neat lines of 76 bytes.
I'm talking about the HEADERS not the body. See http://www.tldp.org/LDP/nag/node258.html <quote> A site may find out about all other sites the article has already traversed by looking at the Path: header field. This header contains a list of all systems the article has been forwarded by in bang path notation. </quote> I'm not talking about 'source based routing' as with UUCP, though that might apply a well. No, I'm talking about Henry's code in C-News that read lines of indefinite length with NO BUFFER OVERFLOW.
Even the linux kernel likes the 80 character limit:
"The limit on the length of lines is 80 columns and this is a strongly preferred limit."
That's about readability of the sources. The kernel itself has no such requirement.
Anyway, we're way OT.
Getting there .... -- In view of the stupidity of the majority of the people, a widely held opinion is more likely to be foolish than sensible. --Bertrand Russell, Marriage and Morals -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org