Where did text file line ending characters begin?
lvi...@yahoo.com
vs carriage return newline situation. One of the participants claimed
that the use of 2 characters for text file line endings was long established
before Unix began using 1 character.
It got me to thinking. I know that on most of the IBM machines I have used,
there were no line endings in files - there were either carriage control
characters at the beginning of lines, or the carriage controls were added
as the lines were produced.
I seem to recall that VMS used some sort of line length in the early days -
but its been years since I even thought about VMS ...
I certainly remember how we needed to produce both carriage return and
linefeed characters for printing text. However, I don't know how far
back one has to go to find the first OS where it was standard procedure to
append one or more characters onto the end of a line of text to indicate
that the line had ended (as opposed to having fixed length lines or
some sort of line length at the beginning of the line...).
Anyone have some references?
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Hank Oredson
<lvi...@yahoo.com> wrote in message news:aenjhi$lrj$1...@srv38.cas.org...
Teletype.
CR moved the print head to the start of the current line, LF jogged
the paper up one line. One usually had to pad with a few NUL to
provide delay while the carriage finished moving the head all
the way to the left. 4 of them in the case of my old model 103 :-)
Some standard Altair TTY handlers only provided two NUL,
so I got a couple smudges when the print hammer fired as the
carriage was moving left. Had to patch those drivers ...
As I recall the problem went away once I got a nice ASR-33,
since it could slam the head back home ok with CR LF NUL NUL.
A lot of the "Teletype Art" made use of overprinting, using CR
to get back to the start of the line for a second, third or even
fourth pass.
--
... Hank
Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net
Stan Barr
>
><lvi...@yahoo.com> wrote in message news:aenjhi$lrj$1...@srv38.cas.org...
>> I was recently reading a discussion of the whole newline vs carriage return
>> vs carriage return newline situation. One of the participants claimed
>> that the use of 2 characters for text file line endings was long established
>> before Unix began using 1 character.
>>
[snip]
>
>Teletype.
Which merely automated the equivalent manual typewriter carriage return and
line-feed (yes, I know typewriters combined them into one lever...)
Presumably Murray's* machines of 1903 introduced this function into teletype,
IIRC Baudot's machines printed onto continous paper tape, so didn't need LF.
* The British equivalent of Baudot code is known as Murray code.
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
Larry__Weiss
> However, I don't know how far
> back one has to go to find the first OS where it was standard procedure to
> append one or more characters onto the end of a line of text to indicate
> that the line had ended (as opposed to having fixed length lines or
> some sort of line length at the beginning of the line...).
>
I like to think of it as when did the distinction between using
special characters for abstract record delineation become separated
from using special characters to control a printing device.
Literally, the CR/LF pair is in the device control category.
UNIX uses the LF more in the abstract sense (IMO).
I would have preferred to see a simple EOR (End of Record) or
EOL (End of Line) terminology without any reference to the needs
of particular display presentation machinery.
Sometimes you get a mixture of abstraction and fully-mapped concept
in any early specification. As a specification matures, you'll
see an evolution towards the abstract with some kind of a
"style-sheet" providing the "just-in-time" mapping to specifics.
I don't recall enough about the earliest OS's storage formats
of textual data to be able to add datapoints here. The scarcity
of permanent files in secondary storage in the early days probably
obscures the answer.
- LarryW
CBFalconer
>
> lvi...@yahoo.com wrote:
> > However, I don't know how far
> > back one has to go to find the first OS where it was standard
> > procedure to append one or more characters onto the end of a
> > line of text to indicate that the line had ended (as opposed
> > to having fixed length lines or some sort of line length at
> > the beginning of the line...).
>
> I like to think of it as when did the distinction between using
> special characters for abstract record delineation become separated
> from using special characters to control a printing device.
>
> Literally, the CR/LF pair is in the device control category.
>
> UNIX uses the LF more in the abstract sense (IMO).
>
> I would have preferred to see a simple EOR (End of Record) or
> EOL (End of Line) terminology without any reference to the needs
> of particular display presentation machinery.
I suspect the Unix usage grew out of the fact that one rarely
wants to advance the output device to the next line without
returning the carriage, but one does want to return the carriage
alone to overprint the line.
This becomes painfully obvious on dumping a raw Unix textfile to
an old fashioned ASR33. The hammers tend to pound away at the
right hand side of the platen and leave few meaningful marks on
the paper.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Dennis Ritchie
>
> I was recently reading a discussion of the whole newline vs carriage return
> vs carriage return newline situation. One of the participants claimed
> that the use of 2 characters for text file line endings was long established
> before Unix began using 1 character.
>
> It got me to thinking. I know that on most of the IBM machines I have used,
> there were no line endings in files - there were either carriage control
> characters at the beginning of lines, or the carriage controls were added
> as the lines were produced.
Moch of the strangeness comes because of a somewhat forced ccnvergence
of various approaches. Communications technology tended to use
character sequences (like CR/LF) that mapped into physical actions.
Computer technology tended to use often fixed-length records.
Ultimately there were physical artifacts (e.g. punched cards) behind
this too. If you have a "record" on a card (or on a magtape)
there may be an explicit or implicit count; there's no need for
an end-of-record character or characters.
By the 1960s, actually earlier I suppose, given that paper tape
has no natural record structure, these began to mix, especially
with the advent of interactive systems using terminals.
The specific example that influenced Unix was Multics, which did choose
a single character (the ASCII LF or NL, octal 012) to delimit lines
in text files. Eric Fischer has looked at and posted some material
on the usage of the character.
As Larry Weiss says later in this thread,
> UNIX uses the LF more in the abstract sense (IMO).
> I would have preferred to see a simple EOR (End of Record) or
> EOL (End of Line) terminology without any reference to the needs
> of particular display presentation machinery.
Fair comment on the terminology, but of course, having chosen
a single character as a line-delimiter, it was necessary to
tell people what it actually is. But he's right in seeing
that the NL character is somewhat of an abstraction.
Choosing a single character does mean that you can then specify
the mapping into what is needed to control the hardware.
Most Teletype terminals (and many others) did separate the
CR and LF functions into move-to-left and advance-paper.
Other terminals (like IBM 1050 and 2741) had a NL function,
no CR, but did have an "index" function character that was a pure LF:
just advance the carriage. On the other hand, the TTY 37
could be adjusted to understand NL directly as such.
Nowadays, of course, this is much more obviously a pure
software game--bit-map displays just understand the pixels.
(Incidentally, does anyone have display software that
performs a proper CR that ends up overstriking "abc\r___"
without a lot of help from the application?)
One advantage of using a single character (call it NL) is that
the necessary device control can be put just into the driver:
there is no problem in deciding whether a CR without its LF or
a LF without its CR delimits what you think of as a record.
There were truly mixed and truly repellent combinations as well.
In the GCOS system, as we used it in the early 1970s, a
record (for an ASCII file) as read from disk, had a character
count, and was also ended by CR-LF. What was the software
supposed to do when there was mutual disagreement?
> I seem to recall that VMS used some sort of line length in the early days -
> but its been years since I even thought about VMS ...
There are definitely advantages in pure counted records, especially
fixed-length. Once you know the rules, if you want to
communicate something, you can transform it algorithmically;
also seeking to a specific record is easier.
Dennis
Eric Fischer
> > > I was recently reading a discussion of the whole newline vs carriage
> > > return vs carriage return newline situation. One of the participants
> > > claimed that the use of 2 characters for text file line endings was
> > > long established before Unix began using 1 character.
> >
>
> Which merely automated the equivalent manual typewriter carriage return and
> line-feed (yes, I know typewriters combined them into one lever...)
>
> Presumably Murray's* machines of 1903 introduced this function into teletype,
> IIRC Baudot's machines printed onto continous paper tape, so didn't need LF.
I think the use of separate carriage return and line feed codes actually
came later than 1903, although I agree that it was Murray who made the
concepts relevant.
The earliest version of Donald Murray's printer (around 1899 to 1901)
printed on pages instead of on strips but didn't have any sort of
automatic carriage return or line feed mechanism. The operator who
hand-cranked the mechanism also had to pay attention and return the
carriage manually when a line filled up. This problem was corrected
by 1905 by the addition of a LINE control character that would return
the carriage and feed the paper. Murray continued to use this single
control to terminate lines at least through May, 1911.
As far as I've been able to determine, the separate line feed and
carriage return control characters appeared at around that time,
but on the Morkrum (later known as Teletype), not Murray, printing
telegraph. Probably the reason for their appearance was that the
Morkrum had to print characters in real time as they were received.
Murray's had the luxury of printing exclusively from paper tape,
so it apparently wasn't a problem to stop advancing the tape until
the carriage return had completed.
In March, 1912, Murray visited Morkrum's offices in Chicago and by
August his company had become Morkrum's European distributor. I think
it was because of this business arrangement that Murray's company
also eventually adopted separate carriage return and line feed codes.
> * The British equivalent of Baudot code is known as Murray code.
I think Murray himself may have been responsible for some of this
confusion. He seemed to think that the use of five bits per character
was more important than the details of what bit patterns corresponded
to what characters, so even he would refer to his own code as "Baudot."
I guess you can't really blame other people for doing the same.
Eric
Philip Homburg
Dennis Ritchie <d...@bell-labs.com> wrote:
>Nowadays, of course, this is much more obviously a pure
>software game--bit-map displays just understand the pixels.
>(Incidentally, does anyone have display software that
>performs a proper CR that ends up overstriking "abc\r___"
>without a lot of help from the application?)
The tek-mode in xterm does overstrike by default. Unfortunately, there
is no scrolling, so the display becomes a bit cluttered after a while.
Philip Homburg
Peter Ibbotson
news:Pine.BSO.4.43.020618...@arx.rog.eu.tc...
Thorsten, you have a line starting
"begin electrogrammati illius Hank Oredson"
in your message, those who use MS software aren't able to see this as the
matching mime header in the top confuses Outlook/outlook express into
thinking you started a uuencoded bit in your message.
This may of course not bother you even slightly however it will cause others
problems, and if you're doing on purpose[1] then I personally find it rude
(akin to setting line wrapping to greater than 80 characters or HTML in news
messages).
[1] If this was comp.os.linux.advocacy then it may excusable as a means of
avoiding trolling linux haters
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
Peter Ibbotson
news:3D0FF4C4...@bell-labs.com...
> There were truly mixed and truly repellent combinations as well.
> In the GCOS system, as we used it in the early 1970s, a
> record (for an ASCII file) as read from disk, had a character
> count, and was also ended by CR-LF. What was the software
> supposed to do when there was mutual disagreement?
Personally I think the text/binary modes on fopen was a mistake. When I
supported the early versions of TurboC it caused a lot of grief with
customers. The only problem is I can't think of better solution for those
who were trying to port code from a unix style box which made use of text
mode (possibly making the default binary mode as extra CR characters would
cause less pain than having missing LFs cause mysterious crashes).
In an ideal world deleting "fopen" and having "topen and bopen" functions
would have been better but I can understand the reasons why not.
Larry__Weiss
> (Incidentally, does anyone have display software that
> performs a proper CR that ends up overstriking "abc\r___"
> without a lot of help from the application?)
>
That visual effect seems to be only available in certain
terminal models (and of course on some hardcopy devices).
I tried MS apps "write" and "word" and they both created two
lines when given your example (those apps control their bit-mapped
presentation and so could have been written to do otherwise).
Simple copying to the console display under W98 results in text
replacement (leaving only the ___ visible). I'm sure that those
applications have to remain consistent with the old IBM-PC display
adapters as much as possible. IIRC the MDA/CGA/EGA/VGA display
adapters could not overstrike when in "text" mode.
Other than the older Tektronics terminals that I've used
(that could only erase the entire screen at a time), and some
custom software that I've written in the past, I can't
recall any soft-copy presentations that do the overstrike.
- LarryW
Russell P. Holsclaw
(Radio teletype on ham radio), I think I can add some insights here.
For one thing, there are very few TTY machines that could complete a
carriage return in the time it took to receive the next character, so
separating the function of the linefeed sort of gives the machine
something to do while the carriage is still flying back toward the
left margin. The TTY model 15, which I own one of, operating at
approx 6 cps, could just barely make it in two character times.
The 5-bit Baudot code is not quite as arbitrary as some here have
suggested. True, it's not related to alphabetical order or any notion
of binary sequencing. There was no reason for it to be... these
machines were not designed to communicate with computers. If you
study the code, however, you will notice that the most
frequently-occuring characters and commands have the fewest number of
1-bits. For example, the codes with only one 1-bit each are: Carriage
Return, Line Feed, Space, E, and T. Other common letters have two
1-bits, and less common ones have 3 or 4. The all-1's code is the
"letters shift" code, which restores the typebasket to the default
position for printing alpha characters, and doubles as a "delete" code
for "rubbing out" errors on a paper tape. (The all-ones in ASCII is
called "rub-out" because it serves the same purpose.) The motive
behind the Baudot arrangement is probably related to minimizing wear
on paper-tape punches and dies, as well as reducing the accumulation
of those annoying little paper dots called "chad".
On the issue of end-of-record indicators, it should be noted that on
IBM mainframes there are no end-of-record delimiters at all. Fixed
length records are simply concatenated together and distinguished
purely by byte-count. Variable-length records are always simply
preceded by a binary integer byte-count, usually a 16-bit integer with
a system-defined maximum of 32767 bytes (the integer being treated as
signed, mainly because the System/360 had no instructions for unsigned
half-word operations). New-line control codes and such were only used
with terminals. Even a printer, like the 1403, was a "unit record"
device, that printed one line per "record", with vertical spacing
being determined by a device command code that was not part of the
datastream. Although there was a common convention of putting a
"carriage control character" at the beginning of a print line, this
was not sent as data to the printer, but was used to select the CCW
(channel command word) command code used to print the line.
Record formats on IBM mainframe systems are a reflection of the IBM
punched-card heritage of IBM systems. The format of files on smaller
systems with a science/engineering lab/minicomputer heritage is more
influenced by the TTY machines that were used as the standard I/O on
early models of such systems. Although many people may think of Unix
as a large-scale industrial-strength OS today, clearly its heritage is
with the small laboratory mini-computer, not the mainframe.
--
Russ
Alan T. Bowler
> Fair comment on the terminology, but of course, having chosen
> a single character as a line-delimiter, it was necessary to
> tell people what it actually is. But he's right in seeing
> that the NL character is somewhat of an abstraction.
>
> Choosing a single character does mean that you can then specify
> the mapping into what is needed to control the hardware.
> Most Teletype terminals (and many others) did separate the
> CR and LF functions into move-to-left and advance-paper.
> Other terminals (like IBM 1050 and 2741) had a NL function,
> no CR, but did have an "index" function character that was a pure LF:
> just advance the carriage. On the other hand, the TTY 37
> could be adjusted to understand NL directly as such.
>
> Nowadays, of course, this is much more obviously a pure
> software game--bit-map displays just understand the pixels.
> (Incidentally, does anyone have display software that
> performs a proper CR that ends up overstriking "abc\r___"
> without a lot of help from the application?)
>
> One advantage of using a single character (call it NL) is that
> the necessary device control can be put just into the driver:
> there is no problem in deciding whether a CR without its LF or
> a LF without its CR delimits what you think of as a record.
The portability group at Waterloo, (Thoth operating system and some
decendants, and the languages Eh, Zed and Port), attempted to resolve
this by using the ASCII RS (record separator), as the new line
convention, and then let programs use CR and LF when needed to get
the specific effect of just carriage return or line feed. This avoided
the ambiguity over the ambiguous meanings of ASCII (012) which is
either NL or LF depending of an ill defined context. The Unix/C
conventions however had more momentum, and the whole idea of
"records" was seen of old fashioned.
> There were truly mixed and truly repellent combinations as well.
> In the GCOS system, as we used it in the early 1970s, a
> record (for an ASCII file) as read from disk, had a character
> count, and was also ended by CR-LF. What was the software
> supposed to do when there was mutual disagreement?
The situation did improve a little on Gcos with the move to
using the media 6 conventions for the media 5 one you describe.
However, since under Gcos the actual raw disk block formatting
into records is still done at the application level, and the
media 6 conventions (count for record length, assumed newline
for a record *unless* the last character is a CR or FF) are
not well documented, so many programs get it wrong.
greymaus
>
> And my good old Epson FX-80, built the same year as I was born...
>
>>CR moved the print head to the start of the current line, LF jogged
>>the paper up one line. One usually had to pad with a few NUL to
>>provide delay while the carriage finished moving the head all
>>the way to the left. 4 of them in the case of my old model 103 :-)
>
> I've never seen them though. I know XON/XOFF.
>
>>A lot of the "Teletype Art" made use of overprinting, using CR
>
>
> -Thorsten
Is there a book on all this ?. I find it all fascinating , how ideas
advanced from Baudot to UNICODE . And , I still haven't given up on
paper in favour of CD's . (One of the Internet boom propositions that
really irritated me).
Wouldn't have been a straight road , either , lot of byways , AMTOR ,
SATOR , RTTY , EBCDIC ..
--
Greymaus;
Follow up , don't e-mail , my killfile is savage ;
Next Year In , well , wherever ;
Eric Fischer
> Is there a book on all this ?. I find it all fascinating , how ideas
> advanced from Baudot to UNICODE .
As far as I know the only published book on the subject is Charles E.
Mackenzie's _Coded Character Sets, History and Development_. According
to Amazon the ISBN is 0201144603. It's the definitive account as far
as EBCDIC is concerned but has lighter coverage of other codes.
For ASCII there is Bob Bemer's article, "A View of the History of the
ISO Character Code," published in 1972 in the Honeywell Computer Journal.
The citation is at http://www.bobbemer.com/PUBS-A.HTM
Tom Jennings has an Annotated History of Character Codes on his web
site at http://www.wps.com/texts/codes/
I've been working on my own article on the history of character codes
for a long time, but it's not in publishable shape yet.
Eric
Charlie Gibbs
spa...@ibbotson.co.uk (Peter Ibbotson) writes:
>Personally I think the text/binary modes on fopen was a mistake.
I also disagree with the idea of separate text and binary modes,
but not just in fopen(). IMHO it's an evil concept altogether,
at least the way it's implemented in MS-DOS/Windows file systems.
For instance, I learned the hard way to never use fseek() on a
file opened in text mode. (And MS-DOS's text-mode EOF character,
0x1a, is so thoroughly vile that no amount of curses are sufficient
to describe it - but that's another topic.)
The Unix "string of bytes" model works so well for both text and
binary data that it stands as proof there is no need for separate
text and binary modes.
>In an ideal world deleting "fopen" and having "topen and bopen"
>functions would have been better but I can understand the reasons
>why not.
That would merely move the problem, not solve it.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Charlie Gibbs
rhol...@nospam.xxx.fatline.com (Russell P. Holsclaw) writes:
> New-line control codes and such were only used
>with terminals. Even a printer, like the 1403, was a "unit record"
>device, that printed one line per "record", with vertical spacing
>being determined by a device command code that was not part of the
>datastream. Although there was a common convention of putting a
>"carriage control character" at the beginning of a print line, this
>was not sent as data to the printer, but was used to select the CCW
>(channel command word) command code used to print the line.
This raises another question (and a wonderful opportunity for thread
drift :-). Why did FORTRAN-style carriage control characters at the
beginning of a line specify spacing before printing, when the hardware
command codes specify spacing after printing? The only reason I can
see is for the "skip to new page" code ('1' in FORTRAN), where you
want the current line to appear on a new page. In all other cases,
it's usually easier from a programming standpoint to specify the
spacing to be taken after the line prints.
This is doubly true when you consider the hardware. The printer
prints the line and signals completion as it begins to advance
the paper. Further processing (even if it's nothing more than
retrieving the next record to print) can proceed as the paper
advances, which makes for more efficient (and faster) use of
the hardware.
Specifying paper advance before printing means that you have to
issue two commands to the printer: first you have to tell it to
advance the paper without printing, then tell it to print. The
significent difference is that you have to wait until the paper
has advanced before you can issue the print command. Depending
on the hardware, this can cut the speed of a print routine by as
much as half.
>Record formats on IBM mainframe systems are a reflection of the IBM
>punched-card heritage of IBM systems. The format of files on smaller
>systems with a science/engineering lab/minicomputer heritage is more
>influenced by the TTY machines that were used as the standard I/O on
>early models of such systems. Although many people may think of Unix
>as a large-scale industrial-strength OS today, clearly its heritage is
>with the small laboratory mini-computer, not the mainframe.
This difference in record formats (fixed-length vs. variable-length
delimited) is to me one of the real differences between mainframes
and minicomputers. In fact, combined with the batch-vs.-interactive
mindsets, it pretty well sums it up IMHO. (The two points are
actually somewhat related.)
Alan T. Bowler
>
> The Unix "string of bytes" model works so well for both text and
> binary data that it stands as proof there is no need for separate
> text and binary modes.
Yes it does, withing the context of that operating system (Unix).
The problem comes when porting a program to a different existing
operating system which already has it's own I/O conventions and
paradigms. You can't just ignore them if a C program ever hopes
to work with existing software and data files. The text/binary
split for C I/O streams works moderately well for the most cases
of such cooperations. However special OS specific support is often
also needed.
Russell P. Holsclaw
> drift :-). Why did FORTRAN-style carriage control characters at the
> beginning of a line specify spacing before printing, when the
hardware
> command codes specify spacing after printing? The only reason I can
> see is for the "skip to new page" code ('1' in FORTRAN), where you
> want the current line to appear on a new page. In all other cases,
> it's usually easier from a programming standpoint to specify the
> spacing to be taken after the line prints.
I generally found that the ANSI carriage control characters (what you
refer to as
FORTRAN codes) were friendlier in every case: you specified where the
line
was to print, not the line after it. The OS/360 operating system also
supported
something called "machine" carriage control ("-M" in the DCB RECFM
field),
which meant that each line began with the CCW command code to be used
to print that line. In that case, it was Print-then-advance-paper,
rather than the
other way around. ANSI carriage control was indicated by an "A" suffix
in the
RECFM field.
>
> This is doubly true when you consider the hardware. The printer
> prints the line and signals completion as it begins to advance
> the paper. Further processing (even if it's nothing more than
> retrieving the next record to print) can proceed as the paper
> advances, which makes for more efficient (and faster) use of
> the hardware.
> Specifying paper advance before printing means that you have to
> issue two commands to the printer: first you have to tell it to
> advance the paper without printing, then tell it to print. The
> significent difference is that you have to wait until the paper
> has advanced before you can issue the print command. Depending
> on the hardware, this can cut the speed of a print routine by as
> much as half.
Not significantly different. The line was written with two CCW's
chained together, the first a control command that moved the paper,
and the second was a "print-no-space" command. Both of these executed
in the channel without CPU intervention ... no significant difference
to the application. Printing was usually disk-spooled, anyway.
In any case, the ANSI/FORTRAN carriage control characters pre-date the
design of the CCW opcodes in the System/360. On the 704/709/704x/709x
machines, printing was usually done off-line by another computer,
usually a 1401. Anyway, I don't know if the printing hardware on the
original FORTRAN machines worked like the 360 control units or not.
> This difference in record formats (fixed-length vs. variable-length
> delimited) is to me one of the real differences between mainframes
> and minicomputers. In fact, combined with the batch-vs.-interactive
> mindsets, it pretty well sums it up IMHO. (The two points are
> actually somewhat related.)
Records on mainframes do not have to be fixed-length. That's only one
of the supported formats.
Joe Pfeiffer
>
> The Unix "string of bytes" model works so well for both text and
> binary data that it stands as proof there is no need for separate
> text and binary modes.
If ASCII had adequately specified what character was used to mark the
end of the line (but that's not the character set's job! you say) and
if M$ had some concept of following standards, you'd be right.
The problem came about in trying to interoperate between Unix's idea
of EOL and M$'s idea of EOL. If you're dealing with transferring
files between the two, you have to have a notion of whether you're
dealing with text or with binary data.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
CBFalconer
>
... snip ...
>
> On the issue of end-of-record indicators, it should be noted that on
> IBM mainframes there are no end-of-record delimiters at all. Fixed
> length records are simply concatenated together and distinguished
> purely by byte-count. Variable-length records are always simply
> preceded by a binary integer byte-count, usually a 16-bit integer with
> a system-defined maximum of 32767 bytes (the integer being treated as
> signed, mainly because the System/360 had no instructions for unsigned
> half-word operations). New-line control codes and such were only used
> with terminals. Even a printer, like the 1403, was a "unit record"
> device, that printed one line per "record", with vertical spacing
> being determined by a device command code that was not part of the
> datastream. Although there was a common convention of putting a
> "carriage control character" at the beginning of a print line, this
> was not sent as data to the printer, but was used to select the CCW
> (channel command word) command code used to print the line.
Thus the tendency to write textfiles with one (or more) leading
blanks per line. These line images, when pumped directly into the
360 (or similar) maws would not do peculiar things when printed
out.
Gary Renaud
Actually, MS-DOS does not have separate text or binary modes. The text/binary split only
came when people started porting C to MS-DOS (what about CP/M?). Unfortunately, for a
"portable" language, C has a lot of UNIX-isms. The idea that '\n' is a single character
means you have to handle it differently for those systems in which it is two.
I know it's politically correct, when comparing OSs to always state that whatever UNIX
does is the One Right Way (and of course, anything MS does is that absolute worst of
all, which must cause problems if the two do something the same way); I'm hoping we
can move beyond that to actual merits.
--
Independence Day. More important then ever; look at the EU.
Gary Renaud (Cami too!) gre...@acm.org <--- Please use this
For contact info, see: http://home.earthlink.net/~sleepyjackal/contact.htm
Henry Churchyard
Charlie Gibbs <cgi...@sky.bus.com> wrote:
>In article <1024491308.2902.0...@news.demon.co.uk>
>spa...@ibbotson.co.uk (Peter Ibbotson) writes:
>>Personally I think the text/binary modes on fopen was a mistake.
> I also disagree with the idea of separate text and binary modes, but
> not just in fopen(). IMHO it's an evil concept altogether, at least
> the way it's implemented in MS-DOS/Windows file systems. For
> instance, I learned the hard way to never use fseek() on a file
> opened in text mode.
Hardly -- DOS doesn't make any distinction whatsoever between binary
and text files at the file-system level. What happened was that way
back when, Unix adopted a somewhat non-standard definition of "text"
(i.e. delimited by LF only), while MS-DOS fully followed the relevant
standards and adopted a standard definition of text (delimited by
CR-LF). (If you don't believe me, look at all the RFC's governing
Internet protocols -- if they're text-based, such as SMTP, then they
specify CR-LF line endings.) So this means that when a C compiler is
moved over to MS-DOS, it has to have two clunky file-handling modes,
one of which translates from standard MS-DOS text format to the
compiler's internal non-standard C/Unix text format -- but this is
completely internal to the "C" environment (not a feature of DOS
itself; the DOS file open/read function calls such as INT 21H AH=3DH,
AH=3FH etc. don't make any binary vs. text differentiation).
> (And MS-DOS's text-mode EOF character, 0x1a, is so thoroughly vile
> that no amount of curses are sufficient to describe it - but that's
> another topic.)
Again, that's pretty much nonsense. If your C-library chooses to
truncate at the first ^Z when reading a text-file from disk, then it's
implementing an old CP/M convention which has sometimes (by no means
always) been carried over into the DOS world -- but there's nothing
whatever in the basic DOS filesystem or DOS file open/read/write
function calls which requires or enforces this behavior. The only
places where the DOS function calls actually treat ^Z specially are in
some cases to mark the end of an input stream when reading in directly
from a "character device" (not a disk file); in this situation ^Z
(borrowed from DEC operating systems through CP/M) is equivalent to
Unix ^D.
--
Henry Churchyard chu...@crossmyt.com http://www.crossmyt.com/hc/
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> This raises another question (and a wonderful opportunity for thread
> drift :-). Why did FORTRAN-style carriage control characters at the
> beginning of a line specify spacing before printing, when the hardware
> command codes specify spacing after printing? The only reason I can
> see is for the "skip to new page" code ('1' in FORTRAN), where you
> want the current line to appear on a new page. In all other cases,
> it's usually easier from a programming standpoint to specify the
> spacing to be taken after the line prints.
>
use a style where the lines were printf("\nThis is a line of text");
type of style was used...
>
> This is doubly true when you consider the hardware. The printer
> prints the line and signals completion as it begins to advance
> the paper. Further processing (even if it's nothing more than
> retrieving the next record to print) can proceed as the paper
> advances, which makes for more efficient (and faster) use of
> the hardware.
>
left to right, like a typewriter would. Line printers have a hammer
for each character position...and each hammer fires when the right
character on the print chain is under it. So carraige control at the
beginning of the line is *not* so unusual IMHO...
>
> Specifying paper advance before printing means that you have to
> issue two commands to the printer: first you have to tell it to
> advance the paper without printing, then tell it to print. The
> significent difference is that you have to wait until the paper
> has advanced before you can issue the print command. Depending
> on the hardware, this can cut the speed of a print routine by as
> much as half.
>
characters as an out-of-band signal. This sort of divides the
carriage control from the lines of text in some ways...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> I suspect the Unix usage grew out of the fact that one rarely
> wants to advance the output device to the next line without
> returning the carriage, but one does want to return the carriage
> alone to overprint the line.
>
terminator in a file was mainly for saving storage when that
was a priority.
>
> This becomes painfully obvious on dumping a raw Unix textfile to
> an old fashioned ASR33. The hammers tend to pound away at the
> right hand side of the platen and leave few meaningful marks on
> the paper.
>
file directly to an ASR33. For looking at binary files, you
probably want to use a hex or octal dump routine to process it
before sending it to the ASR33. With the UNIX file, you need to
have a program fix it up before sending it to the ASR33...
This sort of comes in the catagory of *not* using your hair
dryer while you are in the shower...or *not* pouring molten
lead on your bare foot... It just requires a little thought...
*not* much, but a little. (;-))
Charles Richmond
>
> "Dennis Ritchie" <d...@bell-labs.com> wrote in message
> news:3D0FF4C4...@bell-labs.com...
> > There were truly mixed and truly repellent combinations as well.
> > In the GCOS system, as we used it in the early 1970s, a
> > record (for an ASCII file) as read from disk, had a character
> > count, and was also ended by CR-LF. What was the software
> > supposed to do when there was mutual disagreement?
>
> Personally I think the text/binary modes on fopen was a mistake. When I
> supported the early versions of TurboC it caused a lot of grief with
> customers. The only problem is I can't think of better solution for those
> who were trying to port code from a unix style box which made use of text
> mode (possibly making the default binary mode as extra CR characters would
> cause less pain than having missing LFs cause mysterious crashes).
> In an ideal world deleting "fopen" and having "topen and bopen" functions
> would have been better but I can understand the reasons why not.
>
because on UNIX boxen, there is *no* translation between "\n"
and CR/LF. Most UNIX systems that I have seen...will accept the
"b" in the mode string and ignore it...
Charles Richmond
>
> "Charlie Gibbs" <cgi...@sky.bus.com> writes:
> >
> > The Unix "string of bytes" model works so well for both text and
> > binary data that it stands as proof there is no need for separate
> > text and binary modes.
>
> If ASCII had adequately specified what character was used to mark the
> end of the line (but that's not the character set's job! you say) and
> if M$ had some concept of following standards, you'd be right.
>
> The problem came about in trying to interoperate between Unix's idea
> of EOL and M$'s idea of EOL. If you're dealing with transferring
> files between the two, you have to have a notion of whether you're
> dealing with text or with binary data.
>
of each line...as did CP/M, IIRC. After all, Mi$uck had to
steal it from somewhere...as Mi$uck does *not* innovate at
all.
CBFalconer
>
... snip ...
> >
> On UNIX boxen, there is no text/binary mode on fopen(). That's
> because on UNIX boxen, there is *no* translation between "\n"
> and CR/LF. Most UNIX systems that I have seen...will accept the
> "b" in the mode string and ignore it...
Yes there is (translation). It just happens in a different
location, i.e. the terminal driver. In both directions. When was
the last time you hit a linefeed key to terminate console entry?
CBFalconer
> CBFalconer wrote:
> >
> > [snip...] [snip...] [snip...]
> >
> > I suspect the Unix usage grew out of the fact that one rarely
> > wants to advance the output device to the next line without
> > returning the carriage, but one does want to return the carriage
> > alone to overprint the line.
> >
> I always thought the UNIX usage of <lf> to act as a line
> terminator in a file was mainly for saving storage when that
> was a priority.
> >
> > This becomes painfully obvious on dumping a raw Unix textfile to
this does NOT specify binary !! :-)
> > an old fashioned ASR33. The hammers tend to pound away at the
> > right hand side of the platen and leave few meaningful marks on
> > the paper.
> >
> Well, duh!!! You will see odd behavior if you "dump" a binary
> file directly to an ASR33. For looking at binary files, you
> probably want to use a hex or octal dump routine to process it
> before sending it to the ASR33. With the UNIX file, you need to
> have a program fix it up before sending it to the ASR33...
>
> This sort of comes in the catagory of *not* using your hair
> dryer while you are in the shower...or *not* pouring molten
> lead on your bare foot... It just requires a little thought...
> *not* much, but a little. (;-))
I said textfile, not binary. I have poured molten lead on my feet
- it is called splatter from a soldering iron. It is hard to
examine the (unknown format) textfile on your ASR33 terminal
without sending it to said terminal. Not impossible, but awkward.
Even today, some editors treat such files as one monstrously long
line, and barf strenuously on them.
Chris Hedley
> Let's *not* forget that VAX VMS also used cr/lf at the end
> of each line...as did CP/M, IIRC. After all, Mi$uck had to
> steal it from somewhere...as Mi$uck does *not* innovate at
> all.
I thought VMS usually used what it described as "implied CR," ie
not actually storing any "normal" end-of-line characters but
appending them as required to each record when the file was read.
Chris.
Peter Ibbotson
news:3D119D81...@ev1.net...
> Peter Ibbotson wrote:
> >
> > "Dennis Ritchie" <d...@bell-labs.com> wrote in message
> > news:3D0FF4C4...@bell-labs.com...
> > > There were truly mixed and truly repellent combinations as well.
> > > In the GCOS system, as we used it in the early 1970s, a
> > > record (for an ASCII file) as read from disk, had a character
> > > count, and was also ended by CR-LF. What was the software
> > > supposed to do when there was mutual disagreement?
> >
> > Personally I think the text/binary modes on fopen was a mistake. When I
> > supported the early versions of TurboC it caused a lot of grief with
> > customers. The only problem is I can't think of better solution for
those
> > who were trying to port code from a unix style box which made use of
text
> > mode (possibly making the default binary mode as extra CR characters
would
> > cause less pain than having missing LFs cause mysterious crashes).
> > In an ideal world deleting "fopen" and having "topen and bopen"
functions
> > would have been better but I can understand the reasons why not.
> >
> On UNIX boxen, there is no text/binary mode on fopen(). That's
> because on UNIX boxen, there is *no* translation between "\n"
> and CR/LF. Most UNIX systems that I have seen...will accept the
> "b" in the mode string and ignore it...
True, but there is a raw mode on tty drivers (and I assume for talking to
printers). I was talking here from the perspective of someone who had
support people who were moving C programs from a UNIX box to MSDOS. The idea
of a text and binary mode on files/drivers needs to be there as a concept to
allow relatively easy porting of trival programs from one OS to another.
However my complaint is about the overloading of the fopen modes stuff (and
certainly the default should have been binary) The problem otherwise is that
folks write out a binary bit pattern containg '\r' to a file and can never
read it back, causing all kinds of odd errors which are data dependant and
therefore difficult to debug.
I can however imagine that the ANSI folks picked text by default since stdin
and stdout etc start out in text mode by default.
Tim Shoppa
?? It *is* emulating a Tek4014, after all.
Tim.
Anne & Lynn Wheeler
> This difference in record formats (fixed-length vs. variable-length
> delimited) is to me one of the real differences between mainframes
> and minicomputers. In fact, combined with the batch-vs.-interactive
> mindsets, it pretty well sums it up IMHO. (The two points are
> actually somewhat related.)
an implicit part of the batch-vs-interactive paradigm was that batch
assumed that there was rarely or no human directly connected so that
errors and exception cases had to be automagically handled.
there was much more of a tendency in the interactive environment of
involving a human in the exception & error process.
a current situation can be seen in some of the dim/dark room web farms ...
is a human needed for care & feeding of every box?
a large financial transaction operation a couple years ago attributed
their 100 percent availability to
* automated operator
* ims hot-standby
ims hot-standy was a mainframe database replication technique.
there were a few things still left to these (human) operator in ibm
mainframes ... but as other forms of errors and exceptions either were
eliminated or had automated handling ... human (operator) mistakes
became one of the leading causes of failures/outages.
some amount of the automated exception & error mitigation technology
was the significantly higher focus on the area in batch environments
that evolved over 30 years or more.
it is possible to have all sorts of technology efforts to address
exception & error mitigation. however, a true test of a market focus
on the subject is if the information is openly audited and
reported. at least in some segments of the mainframe industry ... not
only is every error, exception, and fault recorded and reported ... on
a per machine basis ... but there is a service that gathers all such
data from a large segment of the installed customer base and publishes
reports with statistics broken out by vendor.
there is the tale i've repeated about being contacted regarding a
concern over one such report. a new machine was developed and a
certain type of error was projected to occur 3-5 times over a period
of a year for all customers (not avg. per machine per year .... but
the total aggregate number of errors across all operating machines for
a period of a year). The industry report showed that something like a
total of 15 such errors were recorded across all machines for a period
of a year. there was great concern that the total number was 15 rather
than 3-5 and an investigation launced.
It turns out that some software that I had been involved in many years
earlier would perform "local channel i/o" extension simulation over
telco lines. when the telco line had an uncorrectable error, the
software simulated the report of this other type of hardware error
(which basically resulted in higher level error handling retrying the
operation). On further investigation it turned out the increased
errors were in fact at installations running this software.
some past refs to the error reporting situation:
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
random automated operator &/or ims hot-standby refs:
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
http://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#13 Computer of the century
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#47 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Anne & Lynn Wheeler
> On the issue of end-of-record indicators, it should be noted that on
> IBM mainframes there are no end-of-record delimiters at all. Fixed
> length records are simply concatenated together and distinguished
> purely by byte-count. Variable-length records are always simply
> preceded by a binary integer byte-count, usually a 16-bit integer with
> a system-defined maximum of 32767 bytes (the integer being treated as
> signed, mainly because the System/360 had no instructions for unsigned
> half-word operations). New-line control codes and such were only used
> with terminals. Even a printer, like the 1403, was a "unit record"
> device, that printed one line per "record", with vertical spacing
> being determined by a device command code that was not part of the
> datastream. Although there was a common convention of putting a
> "carriage control character" at the beginning of a print line, this
> was not sent as data to the printer, but was used to select the CCW
> (channel command word) command code used to print the line.
i frequently contend that the use of explicit lengths for variable
length records results in a programming convention environment that
has much lower incidence of buffer-overruns. conversely, the
convention of implicit lengths in variable length records associated
with most C programming environments has contributed greatly to the
incidences of buffer-overruns errors (as well as associated security
exploits).
misc. past refs:
http://www.garlic.com/~lynn/99.html#85 Perfect Code
http://www.garlic.com/~lynn/99.html#163 IBM Assembler 101
http://www.garlic.com/~lynn/2000.html#25 Computer of the century
http://www.garlic.com/~lynn/2000b.html#17 ooh, a real flamewar :)
http://www.garlic.com/~lynn/2000b.html#22 ooh, a real flamewar :)
http://www.garlic.com/~lynn/2000c.html#40 Domainatrix - the final word
http://www.garlic.com/~lynn/2001b.html#47 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#58 Checkpoint better than PIX or vice versa???
http://www.garlic.com/~lynn/2001i.html#54 Computer security: The Future
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001l.html#49 Virus propagation risks
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2002.html#38 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
Ignatios Souvatzis
No and yes.
VMS has a concept of "record".
A record can have attributes - like implied cr, implied lf, implied
both, none, ...
VMS has a concept of file types.
A file can be sequential-records, a database, stream-lf, stream-cr, and
a couple of others.
When I started sharing text files between VMS and UNIX I quickly learned
that the easy way is to set their file type to stream-lf and their record
type to implied-crlf.
-is
Joel Gallun
> I thought VMS usually used what it described as "implied CR," ie
> not actually storing any "normal" end-of-line characters but
> appending them as required to each record when the file was read.
VMS had both, along with about a dozen other file formats.
Very much unlike unix, all VMS files had 'structure', even if it was
only 512 byte fixed length records.
IIRC "implied CR" files used a 16 bit word at the start of each record
to hold the length.
I'm scaring myself. I can't beleive I still remember this crap. It's
been over 10 years since I touched a VMS system
Joel - ex DEC
jmfb...@aol.com
igna...@tarski.cs.uni-bonn.de (Ignatios Souvatzis) wrote:
>In article <5d6sea...@teabag.cbhnet>,
> c...@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
>> According to Charles Richmond <rich...@ev1.net>:
>>> Let's *not* forget that VAX VMS also used cr/lf at the end
>>> of each line...as did CP/M, IIRC. After all, Mi$uck had to
>>> steal it from somewhere...as Mi$uck does *not* innovate at
>>> all.
>>
>> I thought VMS usually used what it described as "implied CR," ie
>> not actually storing any "normal" end-of-line characters but
>> appending them as required to each record when the file was read.
>
>No and yes.
>
>VMS has a concept of "record".
>
>A record can have attributes - like implied cr, implied lf, implied
>both, none, ...
>
>VMS has a concept of file types.
>
>A file can be sequential-records, a database, stream-lf, stream-cr, and
>a couple of others.
It didn't help that they treated all "foreign" data streams as
an RMS data base. I never understood the details of that.
>
>When I started sharing text files between VMS and UNIX I quickly learned
>that the easy way is to set their file type to stream-lf and their record
>type to implied-crlf.
It also used to have a concept of what it thought everybody else
(non-VMS) should have. If it weren't for an agreement (which
I cannot remember the detail) Phase III DECnet
on TOPS-10 and TOPS-20 would have not passed and we wouldn't
have shipped V7.02 or V5.0 (I think those are the correct version
numbers.)
Any talk of end of line definitions produces an immediate headache ;-).
/BAH
Subtract a hundred and four for e-mail.
Chris Hedley
> VMS had both, along with about a dozen other file formats.
True, I remember the plethora of formats available! ISTR that a "text"
file tended to default to implied CR with certain applications, though...
> Very much unlike unix, all VMS files had 'structure', even if it was
> only 512 byte fixed length records.
>
> IIRC "implied CR" files used a 16 bit word at the start of each record
> to hold the length.
Now I remember. I always had to be careful to specify "ascii" for FTP
transfers with UNIX systems otherwise the results were... unexpected (or,
after a while, entirely expected but no more desirable!)
> I'm scaring myself. I can't beleive I still remember this crap. It's
> been over 10 years since I touched a VMS system
>
> Joel - ex DEC
Chris, also ex DEC and currently ex-VAX (isn't that a laxative?)
Russell P. Holsclaw
> length records results in a programming convention environment that
> has much lower incidence of buffer-overruns. conversely, the
> convention of implicit lengths in variable length records associated
> with most C programming environments has contributed greatly to the
> incidences of buffer-overruns errors (as well as associated security
> exploits).
You are absolutely preaching to the choir here, Lynn. The combination
of indeterminate line/string lengths and finite buffer-sizes is such a
volatile mixture ... frequent explosions are almost guaranteed.
For many years, I worked with an online text-based system where we
handled text with very constrained buffer-sizes. And all of our users'
buffers resided together in the same address space (originally written
for non-virtual 360, of course, somewhat CICS-like). It was quickly
established as an iron-clad programming standard that NO ONE was
permitted to code any loop that moved data from one buffer to another
based solely on finding a delimiter character. The loop absolutely had
to be regulated by a pre-checked counter value computed from the known
amount of remaining buffer space, or less. No exceptions.
This programming principle was so deeply imprinted on my soul, early
in my career, that I find I can scarcely code in the C programming
language without breaking out in a cold sweat. I HATE it! Especially
the flimsy character strings.
On the other side of the ledger, I should point out that I spent the
last years of my IBM career trying to move that system (RETAIN) to a
new, less-constrained architecture. I found my efforts were thwarted
by fellow RETAINers who had grown so accustomed to working in a
confined space that they couldn't conceive of an environment where
there was more than 8K of memory-space available per user. Although
most of our data was text, it was stored in a home-grown file system
that only supported fixed-length records. (One record per screenful
... and it was a small screen, too) As confining as it was, though,
the system seldom crashed. It was a solid, industrial-strength
fortress of safe programming practices. (Yes, even though it was in
assembler).
We did some very innovative things with that system, including
automatic world-wide database replication combined with a real-time
indexing Boolean search capability. But, ironically, the actual
programming environment was like living in solitary confinement. The
programmers became like a bunch of cons, accustomed to prison walls. I
didn't fully realize how bizarre it was until I got away from it. I've
sometimes thought of writing a book about it, but don't know who would
find it interesting.
--
Russ Holsclaw
Brian Inglis
<cbfal...@yahoo.com> wrote:
>Charles Richmond wrote:
>>
>... snip ...
>> >
>> On UNIX boxen, there is no text/binary mode on fopen(). That's
>> because on UNIX boxen, there is *no* translation between "\n"
>> and CR/LF. Most UNIX systems that I have seen...will accept the
>> "b" in the mode string and ignore it...
>
>Yes there is (translation). It just happens in a different
>location, i.e. the terminal driver. In both directions. When was
>the last time you hit a linefeed key to terminate console entry?
A few years ago, whenever a raw mode terminal program (curses
based e.g. vi) got looped and I had to terminate it with
<ctrl-\>, then type blind '<ctrl-J>stty sane<ctrl-J>'.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> We did some very innovative things with that system, including
> automatic world-wide database replication combined with a real-time
> indexing Boolean search capability. But, ironically, the actual
> programming environment was like living in solitary confinement. The
> programmers became like a bunch of cons, accustomed to prison walls. I
> didn't fully realize how bizarre it was until I got away from it. I've
> sometimes thought of writing a book about it, but don't know who would
> find it interesting.
>
of Chillon". It talks about prisoners who are chained to the rocks
on a deserted island. The last four lines are:
"My very chains and I grew friends,
So much a long communion tends
To make us what we are:--even I
Regain'd my freedom with a sigh."
You can read the whole poem at:
<http://www.photoaspects.com/chesil/byron/chillon.html>
Roland Hutchinson
> When I started sharing text files between VMS and UNIX I quickly learned
> that the easy way is to set their file type to stream-lf and their record
> type to implied-crlf.
To this day, I still can't figure out what happened about ten years ago
when I moved a bunch of binary files from Macintosh to VMS and back via
Kermit in one direction and FTP in another. I quickly learned never to try
THAT again.
Mac, by the way, somehow latched onto using CR as the line separator in
files of finder type TEXT. Is this simply a case of "just like Unix only
different" (a design principle that would find fuller expression
fifteen-odd years later in Mac OS X), or was it imitated from the
convention of some other system?
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my_sp...@mac.com is heavily filtered to remove
spam. If your message looks like spam I may not see it.
Charles Richmond
>
> Charles Richmond wrote:
> > CBFalconer wrote:
> > >
> > > [snip...] [snip...] [snip...]
> > >
> > > I suspect the Unix usage grew out of the fact that one rarely
> > > wants to advance the output device to the next line without
> > > returning the carriage, but one does want to return the carriage
> > > alone to overprint the line.
> > >
> > I always thought the UNIX usage of <lf> to act as a line
> > terminator in a file was mainly for saving storage when that
> > was a priority.
> > >
> > > This becomes painfully obvious on dumping a raw Unix textfile to
> ^^^^^^^^
> this does NOT specify binary !! :-)
>
the dumping of an unknown text file to dumping a binary file. Bad
things can happen in both circumstances.
>
> > > an old fashioned ASR33. The hammers tend to pound away at the
> > > right hand side of the platen and leave few meaningful marks on
> > > the paper.
> > >
> > Well, duh!!! You will see odd behavior if you "dump" a binary
> > file directly to an ASR33. For looking at binary files, you
> > probably want to use a hex or octal dump routine to process it
> > before sending it to the ASR33. With the UNIX file, you need to
> > have a program fix it up before sending it to the ASR33...
> >
> > This sort of comes in the catagory of *not* using your hair
> > dryer while you are in the shower...or *not* pouring molten
> > lead on your bare foot... It just requires a little thought...
> > *not* much, but a little. (;-))
>
> I said textfile, not binary. I have poured molten lead on my feet
> - it is called splatter from a soldering iron. It is hard to
> examine the (unknown format) textfile on your ASR33 terminal
> without sending it to said terminal. Not impossible, but awkward.
>
it *is* hard to examine a file...but in UNIX I believe that there is
a utility to guess at the file type. Of course, if you were *not*
expecting a UNIX text file...that probably means that you were *not*
using a UNIX system.
>
> Even today, some editors treat such files as one monstrously long
> line, and barf strenuously on them.
>
and these days (to me) smacks of the PC-centric nature of some
editors. I use a nice editor on my Mac called BBedit. It will
edit Mac format (cr only), UNIX format (lf only), and PC format
(cr/lf) text files. The only difference you will see is if you
check into the file type explicitly.
The vi clone called vim also will allow you to edit PC and UNIX
format text files...and I *think* the Mac style, but I am *not*
sure. So some program authors are making the effort to accomidate
the different conventions...
Charlie Gibbs
rhol...@nospam.xxx.fatline.com (Russell P. Holsclaw) writes:
>I generally found that the ANSI carriage control characters (what you
>refer to as FORTRAN codes) were friendlier in every case: you specified
>where the line was to print, not the line after it.
Different strokes for different folks, I guess. What I like about
print before advancing is that the current line prints right where
you are. It's sort of like a typewriter - type the current line,
then hit the carriage return (which spaces one or two lines,
depending on the setting). Sort of like minicomputers. :-)
>> Specifying paper advance before printing means that you have to
>> issue two commands to the printer: first you have to tell it to
>> advance the paper without printing, then tell it to print. The
>> significent difference is that you have to wait until the paper
>> has advanced before you can issue the print command. Depending
>> on the hardware, this can cut the speed of a print routine by as
>> much as half.
>
>Not significantly different. The line was written with two CCW's
>chained together, the first a control command that moved the paper,
>and the second was a "print-no-space" command. Both of these executed
>in the channel without CPU intervention ... no significant difference
>to the application. Printing was usually disk-spooled, anyway.
Again, it depends on the hardware. I cut my teeth on a Univac
9300, which was Univac's answer to the 360/20. The 9300 didn't
have channels and CCWs like the larger 360s. Each command had to
be issued separately; a space-then-print required the equivalent
of two SIOs on a 360.
But the real kicker was the printer mechanism. The 9300 had a bar
printer. Unlike the 1403's chain, characters were on a long bar
which oscillated back and forth in front of the page, similar to
the printer in the IBM 2780 RJE terminal (1443?). Everything was
timed so that the paper could advance in the time it took the bar
to reverse direction at the end of the print cycle. If you issued
a space command without printing, the paper would advance quite
quickly, but now you'd missed the start of the cycle. You'd have
to wait until the bar moved to the end of its travel before the
next line could print. That 600-lpm printer could only print 300
lpm if you spaced before printing. Needless to say, this shifted
our priorities rather strongly toward printing before spacing.
>> This difference in record formats (fixed-length vs. variable-length
>> delimited) is to me one of the real differences between mainframes
>> and minicomputers. In fact, combined with the batch-vs.-interactive
>> mindsets, it pretty well sums it up IMHO. (The two points are
>> actually somewhat related.)
>
>Records on mainframes do not have to be fixed-length. That's only one
>of the supported formats.
True, but again this depends on the implementation. One file system
implemented variable-length disk records by slapping a length field
on the front of each record, much like on tape - but you had to specify
a maximum record size because each record still occupied a fixed-length
slot that long! Not suprisingly, few people bothered with this option.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Charlie Gibbs
(Joe Pfeiffer) writes:
>"Charlie Gibbs" <cgi...@sky.bus.com> writes:
>
>> The Unix "string of bytes" model works so well for both text and
>> binary data that it stands as proof there is no need for separate
>> text and binary modes.
>
>If ASCII had adequately specified what character was used to mark the
>end of the line (but that's not the character set's job! you say) and
>if M$ had some concept of following standards, you'd be right.
>
>The problem came about in trying to interoperate between Unix's idea
>of EOL and M$'s idea of EOL. If you're dealing with transferring
>files between the two, you have to have a notion of whether you're
>dealing with text or with binary data.
Sad but true. It really makes portability messy (although you don't
see M$ crying too much about that :-). The real irony is that the
separate CR/LF characters were designed to control hardware directly -
but Windows sticks with it even though, like Unix, it hides the
hardware behind device drivers. Sigh...
Charlie Gibbs
(Gary Renaud) writes:
>"...the idea of separate text and binary modes...the way it's
>implemented in MS-DOS..."
>
>Actually, MS-DOS does not have separate text or binary modes. The
>text/binary split only came when people started porting C to MS-DOS
>(what about CP/M?). Unfortunately, for a "portable" language, C has
>a lot of UNIX-isms. The idea that '\n' is a single character means
>you have to handle it differently for those systems in which it is two.
This isn't unique to C. I've never used BASIC or Pascal on a Unix
system, but I'm sure you'd see the same dichotomy there. (Consider
BASIC's OPEN "O"... vs. OPEN "R"... statements - text and binary
mode respectively.)
Text and binary modes are just two different ways of interpreting
the string of bytes in a file. If you open a file in text mode
in C, then tell it to write '\n', the run-time library will decide
what to do; in Unix it'll pass \n straight through, while in MS-DOS
it will convert \n to \r\n. (The reverse, of course, applies when
reading in text mode.)
A similar thing must happen on any language supported under both
MS-DOS and Unix; the BASIC statement PRINT #1,"foo" should write
"foo" followed by LF under Unix, and "foo" followed by CRLF under
MS-DOS. It's not a language convention. It's not even really an
OS convention, because most file systems will just write out whatever
string of bytes you (or, more commonly, the run-time library) give
them.
We must be careful to distinguish between the meaning of \n in
a C program and \n in a disk file. The former is a C convention
meaning "end of a text line", whose representation on disk can
vary according to the file system. The latter is a (potentially
ambiguous) bit of shorthand meaning an LF character. One is a
conceptual end of line, the other is the actual string of bits
used in a particular implementation.
The convenient thing about Unix is that there is no difference between
text and binary mode; the whole confusing discussion becomes moot.
But even though a Unix C run-time library ignores the text/binary
specification when you open a file, you should still meticulously
code it if you want your program to be portable.
There are probably file systems in other OSes where the differences
are much more pronounced. Maybe an old-time mainframer would take
a string like "foo\nbar\n", strip the \n characters, and write two
fixed-length 80-byte (or whatever) records to disk, padded with NULs
(or whatever). Perhaps you VMS types out there have other examples.
>I know it's politically correct, when comparing OSs to always state
>that whatever UNIX does is the One Right Way (and of course, anything
>MS does is that absolute worst of all, which must cause problems if
>the two do something the same way); I'm hoping we can move beyond
>that to actual merits.
Awww, can't we have a nice little flame war?
Roland Hutchinson
> I use a nice editor on my Mac called BBedit. It will
> edit Mac format (cr only), UNIX format (lf only), and PC format
> (cr/lf) text files. The only difference you will see is if you
> check into the file type explicitly.
A brilliant program. Even the free "lite" version will do this, and it
will also convert files from one format to another if you need to do this.
It's pulled my cookies out of the fire more than once.
Of course it's also considered the One True Tool for authoring web pages.
Charles Richmond
>
> Charles Richmond wrote:
> >
> ... snip ...
> > >
> > On UNIX boxen, there is no text/binary mode on fopen(). That's
> > because on UNIX boxen, there is *no* translation between "\n"
> > and CR/LF. Most UNIX systems that I have seen...will accept the
> > "b" in the mode string and ignore it...
>
> Yes there is (translation). It just happens in a different
> location, i.e. the terminal driver. In both directions. When was
> the last time you hit a linefeed key to terminate console entry?
>
mode in fopen() at this point...
Steve O'Hara-Smith
Brian Inglis <Brian....@SystematicSw.ab.ca> wrote:
BI> A few years ago, whenever a raw mode terminal program (curses
s/years/hours/ :)
BI> based e.g. vi) got looped and I had to terminate it with
BI> <ctrl-\>, then type blind '<ctrl-J>stty sane<ctrl-J>'.
A vital mantra - built in to the wrist nerves I think.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Eric Sosman
>
> The Unix "string of bytes" model works so well for both text and
> binary data that it stands as proof there is no need for separate
> text and binary modes.
The undifferentiated byte stream has proved useful -- or, at
the very least, usable -- for many applications. But it is
hardly the be-all and end-all of data organizations! For example,
it cannot support simple operations like "Insert the following
material just before the beginning of an existing file" or "Remove
so-and-so-much material starting at such-and-such position in
the middle of an existing file" or "Replace the umpty-leventh
line in an existing file with these three paragraphs." Unix
programs that perform such operations must resort to making a
new version of the file separate from the original, needlessly
copying all the unaltered material because the file organization
supports no alternative.
Eric Fischer
> Mac, by the way, somehow latched onto using CR as the line separator in
> files of finder type TEXT. Is this simply a case of "just like Unix only
> different" (a design principle that would find fuller expression
> fifteen-odd years later in Mac OS X), or was it imitated from the
> convention of some other system?
The Mac inherited the convention of terminating lines in text files
with CR from the Apple II. I'm not sure how it got established there.
Eric
Charlie Gibbs
rhol...@nospam.xxx.fatline.com (Russell P. Holsclaw) writes:
>We did some very innovative things with that system, including
>automatic world-wide database replication combined with a real-time
>indexing Boolean search capability. But, ironically, the actual
>programming environment was like living in solitary confinement. The
>programmers became like a bunch of cons, accustomed to prison walls. I
>didn't fully realize how bizarre it was until I got away from it. I've
>sometimes thought of writing a book about it, but don't know who would
>find it interesting.
All of us here. :-)
Jim Haynes
a narrow strip of tape obviously didn't need carriage returns and line
feeds. Those that printed on a page did, and for some long-established
reason there were separate characters for the two functions. Maybe because
it was useful to carriage return without line feeding and overstrike some
characters. Maybe because it was useful to line feed multiple times without
operating the carriage return mechanism. Whatever the reason the separate
carriage return and line feed characters came in very early and lasted a long
time.
Carriage returning is time-consuming, so it was normal operating procedure
to send a carriage return or two, then the line feed, and then maybe a
LTRS character for additional time delay before starting the next line.
It was long possible mechanically to use the same character for both CR and
LF; we just didn't do it. There are some non-overline schemes that involve
automatically returning the carriage if a carriage return character isn't
received before the end of a line, and automatically linefeeding if this
is done or a carriage return is received without a linefeed so as not to type
over the next line.
All this comes from Teletype Corp. and then Kleinschmidt Laboratories and
MITE Corp. that were all in the communication business making compatible
machines. The things derived from electric typewriters were a separate
part of industry and used a single key for carriage return and line feed,
because that is what an electric typewriter did.
When ASCII was being upgraded to upper and lower case, and when Teletype
was designing the ill-fated Model 38 and Model 38 machines, somebody in
the standardization process suggested there ought to be the option of a
single character to start a new line, so the provision was made that the
linefeed character could be used as a new line character if desired.
So - all the computers that came from the punched card and line printer
tradition have "records" of 80 or 120 or 132 characters plus a carriage
control perhaps and do not have carriage return and line feed concepts.
Computers designed to use communication terminals have variable-length
lines delimited by some combination of carriage returns and line feeds.
And when we got microcomputers Murphy got into the act so that each main
tradition (Unix, IBM PC, and Apple) uses a different end of line delimiter
in files.
Gary Renaud
the Reagan administration.
However, I *do* remember Pascal. You did a Write() to write "stuff" then a WriteLn to terminate the line, or just a
Writeln() to do it all at once. There was no concept of what the actual character(s) were to terminate the line.
I don't happen to have any source to any Pascal RTLs, but I suspect they have no concept of text vs. non-text.
Again, MS-DOS itself has no concept of text-vs-binary; it's only the RTL support routines on languages that have
a line termination represented as a single explicit character that this would occur. Of course, there is the matter
of whether there SHOULD be differences. I kind of like the idea of typed files. The idea of being unable to open
a file the wrong way (without some explicit override option) is very appealing after a little incident at work a
couple days ago. I have to agree with an earlier poster that perhaps the problem is that C is too low-level for
this kind of work.
I would really prefer if every system used the same convention, whichever it was. Heck, I would like everyone to
use the same instruction set and endian-ness, too. Just so long as everyone else switches to what I am most
comfortable with. [wag]
--
Independence Day. More important then ever; look at the EU.
Gary Renaud (Cami too!) gre...@acm.org <--- Please use this
For contact info, see: http://home.earthlink.net/~sleepyjackal/contact.htm
Charlie Gibbs
(Steve O'Hara-Smith) writes:
>On Thu, 20 Jun 2002 17:11:14 GMT
>Brian Inglis <Brian....@SystematicSw.ab.ca> wrote:
>
>> A few years ago, whenever a raw mode terminal program (curses
>
> s/years/hours/ :)
>
>> based e.g. vi) got looped and I had to terminate it with
>> <ctrl-\>, then type blind '<ctrl-J>stty sane<ctrl-J>'.
>
> A vital mantra - built in to the wrist nerves I think.
I have it written up in the documentation for logging into a few
customers from hell - the ones where I have to connect to one of
their Windoze boxes using PC-Anywhere, then telnet into the Unix
box from there, and then break out of the menu-driven user interface.
:-p
CBFalconer
> CBFalconer wrote:
> >
> >
> Understood...and certainly you are right here. It is ridiculous
> and these days (to me) smacks of the PC-centric nature of some
> editors. I use a nice editor on my Mac called BBedit. It will
> edit Mac format (cr only), UNIX format (lf only), and PC format
> (cr/lf) text files. The only difference you will see is if you
> check into the file type explicitly.
>
> The vi clone called vim also will allow you to edit PC and UNIX
> format text files...and I *think* the Mac style, but I am *not*
> sure. So some program authors are making the effort to accomidate
> the different conventions...
textpad <http://www.textpad.com> also 'self-adapts' and can be
forced into any of the three modes. It is so good at it that I
can be surprised by a file I have been modifying on and off for
some time.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Heinz W. Wiggeshoff
>
> --
> Independence Day. More important then ever; look at the EU.
Never mind the post's format.
aes
Roland Hutchinson
> Has boustrophedonic appeared in this thread yet?
?ksa uoy od yhW .tey toN
(Obviously I studied paleography more than printer
(.ngised
Stan Barr
<my_sp...@mac.com> wrote:
>
>Mac, by the way, somehow latched onto using CR as the line separator in
>files of finder type TEXT. Is this simply a case of "just like Unix only
>different" (a design principle that would find fuller expression
>fifteen-odd years later in Mac OS X), or was it imitated from the
>convention of some other system?
We had this discussion a while back in another n/g. AFAIR it comes from
the ASCII standard - a description of the Standard in one of my books says:
" CR ... Carriage Return
...
In some cases, the CR will incorporate an automatic line feed (LF) either
as a default or as an option This feature, called New Line (NL), is used
to make computer keyboards more like those of a typewriter."
If I could only find my copy of the Standard, I'd see what _it_ says...
Does anyone know what the Xerox Smalltalk system used - being as how
the Mac has it's roots in that system?
As someone who regularly transfers text between dos/Win, Linux and Mac
I wish they'd all agreed on one system!
--
Cheers,
Stan Barr st...@dial.pipex.com
The future was never like this!
Stan Barr
> I use a nice editor on my Mac called BBedit. It will
>edit Mac format (cr only), UNIX format (lf only), and PC format
>(cr/lf) text files. The only difference you will see is if you
>check into the file type explicitly.
>
One of the very best text editors available on _any_ platform!
>The vi clone called vim also will allow you to edit PC and UNIX
>format text files...and I *think* the Mac style, but I am *not*
>sure. So some program authors are making the effort to accomidate
>the different conventions...
AbiWord, available for many platforms, also copes with Unix/Mac/PC
line endings automatically.
glen herrmannsfeldt
>According to Charles Richmond <rich...@ev1.net>:
>> Let's *not* forget that VAX VMS also used cr/lf at the end
>> of each line...as did CP/M, IIRC. After all, Mi$uck had to
>> steal it from somewhere...as Mi$uck does *not* innovate at
>> all.
>I thought VMS usually used what it described as "implied CR," ie
>not actually storing any "normal" end-of-line characters but
>appending them as required to each record when the file was read.
I believe that "usually" is the word. VMS defines a number of
different record formats, and I believe that some have implied
CR and some don't.
-- glen
Peter Ibbotson
news:slrnah4e9l...@citadel.metropolis.local...
> On Thu, 20 Jun 2002 15:28:56 -0400, Roland Hutchinson
> <my_sp...@mac.com> wrote:
> >
> >Mac, by the way, somehow latched onto using CR as the line separator in
> >files of finder type TEXT. Is this simply a case of "just like Unix only
> >different" (a design principle that would find fuller expression
> >fifteen-odd years later in Mac OS X), or was it imitated from the
> >convention of some other system?
>
> We had this discussion a while back in another n/g. AFAIR it comes from
> the ASCII standard - a description of the Standard in one of my books
says:
> " CR ... Carriage Return
> ...
> In some cases, the CR will incorporate an automatic line feed (LF)
either
> as a default or as an option This feature, called New Line (NL), is
used
> to make computer keyboards more like those of a typewriter."
>
> If I could only find my copy of the Standard, I'd see what _it_ says...
>
> Does anyone know what the Xerox Smalltalk system used - being as how
> the Mac has it's roots in that system?
For the mac its almost certainly come from the Apple ][. Reading the ][
monitor source code shows that the standard character out routine had
seperate CR and LF but the CR routine fell through into LF routine giving a
CR->CR+LF translation.
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
Peter Ibbotson
news:Pine.BSO.4.43.020620...@arx.rog.eu.tc...
>>in your message, those who use MS software aren't able to see this as the
>This is a desired side effect.
>No further comment on this, since lusers which aren't clue-ful
>enough to read my messages this way aren't desired audience of mine.
Oh well, into the killfile you go. I would ask why you've changed the
followup but I won't see the answer so don't bother replying.
Tim Shoppa
I'm pretty sure the Apple II's monitor routine "COUT" by
default jumped through a vector in page 3 to a routine that treated CR's as
newlines (scrolling the screen up if necessary.)
The Apple II and //+ shipped with monitor source listings; does anyone know if
these are available online?
Tim.
Philip Homburg
Tim Shoppa <sho...@trailing-edge.com> wrote:
>Philip Homburg wrote:
>>
>> In article <3D0FF4C4...@bell-labs.com>,
>> Dennis Ritchie <d...@bell-labs.com> wrote:
>> >Nowadays, of course, this is much more obviously a pure
>> >software game--bit-map displays just understand the pixels.
>> >(Incidentally, does anyone have display software that
>> >performs a proper CR that ends up overstriking "abc\r___"
>> >without a lot of help from the application?)
>>
>> The tek-mode in xterm does overstrike by default. Unfortunately, there
>> is no scrolling, so the display becomes a bit cluttered after a while.
>
>?? It *is* emulating a Tek4014, after all.
Maybe it makes sense if you have used the real thing. At first glance,
it seems an odd way to add graphics support to a vt100 emulator.
Philip Homburg
Joe Morris
>Again, it depends on the hardware. I cut my teeth on a Univac
>9300, which was Univac's answer to the 360/20. The 9300 didn't
>have channels and CCWs like the larger 360s.
^^^^^^^^^^^^^^^^^^^^
ObNitpick: *all* S/360 systems had channels and CCWs; the concept was
part of the basic architecture. The big/small split involved whether
the channels were external boxes or built into the CPU (where they
used cycle-stealing to move data).
Joe Morris
jmfb...@aol.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>In article <1bn0tr3...@cs.nmsu.edu> pfei...@cs.nmsu.edu
>(Joe Pfeiffer) writes:
>
>>"Charlie Gibbs" <cgi...@sky.bus.com> writes:
>>
>>> The Unix "string of bytes" model works so well for both text and
>>> binary data that it stands as proof there is no need for separate
>>> text and binary modes.
>>
>>If ASCII had adequately specified what character was used to mark the
>>end of the line (but that's not the character set's job! you say) and
>>if M$ had some concept of following standards, you'd be right.
>>
>>The problem came about in trying to interoperate between Unix's idea
>>of EOL and M$'s idea of EOL. If you're dealing with transferring
>>files between the two, you have to have a notion of whether you're
>>dealing with text or with binary data.
>
>Sad but true. It really makes portability messy (although you don't
>see M$ crying too much about that :-). The real irony is that the
>separate CR/LF characters were designed to control hardware directly -
>but Windows sticks with it even though, like Unix, it hides the
>hardware behind device drivers. Sigh...
>
characters that weren't there. I can't deal with voluntary
insertions.
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
The next time I go to Circuit City to see what the kiddies are
buying, I'm going to see if the powers-that-be removed the
<CRLF> key...
jmfb...@aol.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>In article <dpnQ8.25$wT1....@news.uswest.net>
>rhol...@nospam.xxx.fatline.com (Russell P. Holsclaw) writes:
>
>>We did some very innovative things with that system, including
>>automatic world-wide database replication combined with a real-time
>>indexing Boolean search capability. But, ironically, the actual
>>programming environment was like living in solitary confinement. The
>>programmers became like a bunch of cons, accustomed to prison walls. I
>>didn't fully realize how bizarre it was until I got away from it. I've
>>sometimes thought of writing a book about it, but don't know who would
>>find it interesting.
>
>All of us here. :-)
Yup. I know a few who would like the technical stuff too.
CBFalconer
>
> >This is a desired side effect.
> >No further comment on this, since lusers which aren't clue-ful
> >enough to read my messages this way aren't desired audience of mine.
>
> Oh well, into the killfile you go. I would ask why you've changed the
> followup but I won't see the answer so don't bother replying.
It may be purely a language barrier, but he does come across as a
superior supercilious SOB.
jmfb...@aol.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>In article <9U6Q8.362$wq3.1...@news.uswest.net>>>I generally found that the ANSI carriage control characters (what you
>>refer to as FORTRAN codes) were friendlier in every case: you specified
>>where the line was to print, not the line after it.
>
>Different strokes for different folks, I guess.
I suppose it is a style. I never depended on the other
guy ending in the correct position. If you don't have a standard
of position, maintenance gets pretty hairy. One tends to
end up with a pre-positioning output, then the real output, then
"back to old-style positioning" output. This is done in those
cases when, no matter what tool is chosen, only a hammer will work.
> ... What I like about
>print before advancing is that the current line prints right where
>you are. It's sort of like a typewriter - type the current line,
>then hit the carriage return (which spaces one or two lines,
>depending on the setting).
That means you're "correcting" for the last output who didn't
position at the LM.
[impish emoticon here]...If you were thinking typewriter style,
how did you line feed? Typewriters line fed if you didn't use
a lot of force to throw the platen.
/BAH
> ...Sort of like minicomputers. :-)
>
>>> Specifying paper advance before printing means that you have to
>>> issue two commands to the printer: first you have to tell it to
>>> advance the paper without printing, then tell it to print. The
>>> significent difference is that you have to wait until the paper
>>> has advanced before you can issue the print command. Depending
>>> on the hardware, this can cut the speed of a print routine by as
>>> much as half.
>>
>>Not significantly different. The line was written with two CCW's
>>chained together, the first a control command that moved the paper,
>>and the second was a "print-no-space" command. Both of these executed
>>in the channel without CPU intervention ... no significant difference
>>to the application. Printing was usually disk-spooled, anyway.
>
>Again, it depends on the hardware. I cut my teeth on a Univac
>9300, which was Univac's answer to the 360/20. The 9300 didn't
>have channels and CCWs like the larger 360s. Each command had to
>be issued separately; a space-then-print required the equivalent
>of two SIOs on a 360.
>
>But the real kicker was the printer mechanism. The 9300 had a bar
>printer. Unlike the 1403's chain, characters were on a long bar
>which oscillated back and forth in front of the page, similar to
>the printer in the IBM 2780 RJE terminal (1443?). Everything was
>timed so that the paper could advance in the time it took the bar
>to reverse direction at the end of the print cycle. If you issued
>a space command without printing, the paper would advance quite
>quickly, but now you'd missed the start of the cycle. You'd have
>to wait until the bar moved to the end of its travel before the
>next line could print. That 600-lpm printer could only print 300
>lpm if you spaced before printing. Needless to say, this shifted
>our priorities rather strongly toward printing before spacing.
>
>>> This difference in record formats (fixed-length vs. variable-length
>>> delimited) is to me one of the real differences between mainframes
>>> and minicomputers. In fact, combined with the batch-vs.-interactive
>>> mindsets, it pretty well sums it up IMHO. (The two points are
>>> actually somewhat related.)
>>
>>Records on mainframes do not have to be fixed-length. That's only one
>>of the supported formats.
>
>True, but again this depends on the implementation. One file system
>implemented variable-length disk records by slapping a length field
>on the front of each record, much like on tape - but you had to specify
>a maximum record size because each record still occupied a fixed-length
>slot that long! Not suprisingly, few people bothered with this option.
CBFalconer
> "Charlie Gibbs" <cgi...@sky.bus.com> wrote:
> >
> > ... snip ...
> >
> >print before advancing is that the current line prints right
> >where you are. It's sort of like a typewriter - type the
> >current line, then hit the carriage return (which spaces one
> >or two lines, depending on the setting).
>
> That means you're "correcting" for the last output who didn't
> position at the LM.
>
> [impish emoticon here]...If you were thinking typewriter style,
> how did you line feed? Typewriters line fed if you didn't use
> a lot of force to throw the platen.
That works on the 1928 Underwoods, but not for the 'modern' kids
using Selectrics and golfballs. They have to twist that platen
knob. And they don't have that return bar on which to take out
their frustrations - whunk, tap tap TAP tap, WHUNK... One more
lost art.
Peter Ibbotson
news:3D1326BF...@yahoo.com...
> Peter Ibbotson wrote:
> > "Thorsten Glaser" <ty...@netcologne.de> wrote in message
> >
> ... snip ...
> >
> > >This is a desired side effect.
> > >No further comment on this, since lusers which aren't clue-ful
> > >enough to read my messages this way aren't desired audience of mine.
> >
> > Oh well, into the killfile you go. I would ask why you've changed the
> > followup but I won't see the answer so don't bother replying.
>
> It may be purely a language barrier, but he does come across as a
> superior supercilious SOB.
Hmm... Probably a bit too young to appreciate courtesy. I can't easily find
out when an FX80 (1981/2?) was introduced but since the MX80 was 1978 he has
to be under 24.
Rupert Pigott
news:1024652005.27066....@news.demon.co.uk...
[SNIPPETY SNIP SNIP]
> For the mac its almost certainly come from the Apple ][. Reading the ][
> monitor source code shows that the standard character out routine had
> seperate CR and LF but the CR routine fell through into LF routine giving
a
> CR->CR+LF translation.
Didn't the old "BBC Micro" use 'CR' for it's line
termination ?
Mine was given away some years ago, still working
apparently. Like I believe them... :P
Cheers,
Rupert
aes
Roland Hutchinson <my_sp...@mac.com> wrote:
> > Has boustrophedonic appeared in this thread yet?
> ?ksa uoy od yhW .tey toN
> (Obviously I studied paleography more than printer
> (.ngised
I'm not sure if the above is a suoires noitseuq or not, but
assuming it is:
* I believe there were at one time something akin to
boustrophedonic printers on the market, where the print head
printed across right to left, then back left to right on the next
line (my memory is that they were actually called "boustrophedic"
printers, but I can only find "boustrophedonic" in my online
American Heritage).
* There are apparently boustrophedonic languages, about which I
know essentially nothing.
In either case, the complexities associated with both the logical
design and the practical implementation of CR and LF concepts
would seem to be substantially increased.
jmfb...@aol.com
CBFalconer <cbfal...@yahoo.com> wrote:
>jmfb...@aol.com wrote:
>> "Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>> >
>> > ... snip ...
>> >
>> >print before advancing is that the current line prints right
>> >where you are. It's sort of like a typewriter - type the
>> >current line, then hit the carriage return (which spaces one
>> >or two lines, depending on the setting).
>>
>> That means you're "correcting" for the last output who didn't
>> position at the LM.
>>
>> [impish emoticon here]...If you were thinking typewriter style,
>> how did you line feed? Typewriters line fed if you didn't use
>> a lot of force to throw the platen.
>
>That works on the 1928 Underwoods,
My folks have one of those old ones. I meant to carry it
back with me but forgot.
> ...but not for the 'modern' kids
>using Selectrics and golfballs. They have to twist that platen
>knob.
Uh-uh..oh no. Not in my typewriter class. She would whack us
if we did that way. There was a linefeed key. One used it
to load the paper. hmmm...or did we get whacked if we used the
linefeed key instead of the platen? My brain is really mush today.
> .. And they don't have that return bar on which to take out
>their frustrations - whunk, tap tap TAP tap, WHUNK... One more
>lost art.
That's why you need to take up baking bread.
/BAH
jmfb...@aol.com
aes <sie...@stanford.edu> wrote:
>In article <aeu9tt$a55ba$1...@ID-99522.news.dfncis.de>,
> Roland Hutchinson <my_sp...@mac.com> wrote:
>
>> > Has boustrophedonic appeared in this thread yet?
>
>> ?ksa uoy od yhW .tey toN
>> (Obviously I studied paleography more than printer
>> (.ngised
>
>
>I'm not sure if the above is a suoires noitseuq or not, but
>assuming it is:
Will you guys stop it? I keep walking to the back of the
terminal so I can read what you wrote...except you've got
me running around in circles. Do it one way or do it the
other.
>
>* I believe there were at one time something akin to
>boustrophedonic printers
Good grief. Nobody ever called them that in my hearing.
> .. on the market, where the print head
>printed across right to left, then back left to right on the next
>line (my memory is that they were actually called "boustrophedic"
>printers, but I can only find "boustrophedonic" in my online
>American Heritage).
LA36s could do that.
<snip>
Floyd Davidson
>
>Teletype.
>
>CR moved the print head to the start of the current line, LF jogged
>the paper up one line. One usually had to pad with a few NUL to
However, Teletype machines could be, and commonly were, optioned
to do a newline any time there was a linefeed. Or was it when
there was a carriage return??? I don't remember now which one
triggered it...
>provide delay while the carriage finished moving the head all
>the way to the left. 4 of them in the case of my old model 103 :-)
What was a "model 103"???
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Steve O'Hara-Smith
Eric Sosman <Eric....@sun.com> wrote:
ES> line in an existing file with these three paragraphs." Unix
ES> programs that perform such operations must resort to making a
ES> new version of the file separate from the original, needlessly
ES> copying all the unaltered material because the file organization
ES> supports no alternative.
The alternative is to use something other than a flat file
for this purpose - say a dbm file or an ISAM or even an RDBMS. Unix
programs often do so. At one level it is just a stream of bytes, at
a lower level it may be sectors on a disc while at a higher level it
may be an RDBMS. It's all just bits and interpretations.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Simon Bowring
>When was
>the last time you hit a linefeed key to terminate console entry?
Last week! When a unix program exits (usually unexpectely) leaving
the tty in a funny state. "stty sane" sorts this out usually,
but you sometimes have to hit ^J (LF) rather than the normal CR to
get the tty to understand you're committing the line!
Simon
some w
Nick Spalding
I have an old Citizen 120D, a near-clone of an FX80, upstairs which
normally works like that. You can send it a control option to print
one way only if you want to make sure everything lines up right at the
left margin.
--
Nick Spalding
Kevin Handy
The LA36 didn't (too slow to need to) unless you added one of the
DataSouth speedup kits (which were really hard on the print heads),
but the LA120 and later did.
I always heard it called bi-directional printing, not
boustrophedonic. Most current dot matrix printers do it when
printing in text mode. Windows prints in graphics mode, which
requires the dots to line up better than bi-directional can
usually handle, so it's normally disabled in graphics mode.
Steve O'Hara-Smith
aes <sie...@stanford.edu> wrote:
A> * I believe there were at one time something akin to
A> boustrophedonic printers on the market, where the print head
A> printed across right to left, then back left to right on the next
I think nearly all dot matrix printers do this, unless disabled by
the code to force uni-directional printing.
Steve O'Hara-Smith
Roland Hutchinson <my_sp...@mac.com> wrote:
RH> aes wrote:
RH>
RH> > Has boustrophedonic appeared in this thread yet?
RH> ?ksa uoy od yhW .tey toN
What are you supposed to if the line going right
? thgir ot tfel gniog enil eht rof gnol oot si tfel ot
I can't make it stick out at the left like I can at the
(: thgir
Charles Richmond
>
> jmfb...@aol.com wrote:
> > "Charlie Gibbs" <cgi...@sky.bus.com> wrote:
> > >
> > > ... snip ...
> > >
> > >print before advancing is that the current line prints right
> > >where you are. It's sort of like a typewriter - type the
> > >current line, then hit the carriage return (which spaces one
> > >or two lines, depending on the setting).
> >
> > That means you're "correcting" for the last output who didn't
> > position at the LM.
> >
> > [impish emoticon here]...If you were thinking typewriter style,
> > how did you line feed? Typewriters line fed if you didn't use
> > a lot of force to throw the platen.
>
> That works on the 1928 Underwoods, but not for the 'modern' kids
> using Selectrics and golfballs. They have to twist that platen
> knob. And they don't have that return bar on which to take out
> their frustrations - whunk, tap tap TAP tap, WHUNK... One more
> lost art.
>
to find out...but IIRC, there is an "index" key that will give
you only line-feeds without carriage returns... I am sure that
this is the case with my wife's Brother electronic daisy-wheel
typewriter.
But you are right...I wager that *most* people have *never* used
a manual typewriter. (Okay, maybe most people in *this* newsgroup
have...but *not* the general population.) If fact, if you find
10-year-olds using their computers...you may have to explain to
them what a typewriter is...and what a vinyl record album is also.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> * I believe there were at one time something akin to
> boustrophedonic printers on the market, where the print head
> printed across right to left, then back left to right on the next
> line (my memory is that they were actually called "boustrophedic"
> printers, but I can only find "boustrophedonic" in my online
> American Heritage).
>
It was possible because the printer would cache the incoming text.
This allowed it to scan the next print line backwards through its
internal memory buffer.
>
> * There are apparently boustrophedonic languages, about which I
> know essentially nothing.
>
<http://www.translexis.co.uk/new_page_2.htm>
Has the following:
"The earliest users of the alphabet wrote from left to right or
right to left as the mood took them. The more indecisive used a
curious system known as boustrophedon in which the text would
run from left to right (or vice versa), reach the end of the
line and double back to run right to left like the furrows of a
plough! Boustrophedon is Greek for 'turning of the ox'. These
experiments were abandoned long ago in antiquity and Modern Greek,
like Classical Greek, is written from left to right."
Sam Yorko
>
> In article <3456.936T2...@sky.bus.com>,
> "Charlie Gibbs" <cgi...@sky.bus.com> wrote:
> >Different strokes for different folks, I guess.
>
> I suppose it is a style. I never depended on the other
> guy ending in the correct position.
Just >what< are we talking about here?
;-) ;-)
Sam
Charlie Gibbs
sie...@stanford.edu (aes) writes:
>In article <aeu9tt$a55ba$1...@ID-99522.news.dfncis.de>,
>Roland Hutchinson <my_sp...@mac.com> wrote:
>
>> > Has boustrophedonic appeared in this thread yet?
>
>> ?ksa uoy od yhW .tey toN
>> (Obviously I studied paleography more than printer
>> (.ngised
:-)
>I'm not sure if the above is a suoires noitseuq or not, but
>assuming it is:
>
>* I believe there were at one time something akin to
>boustrophedonic printers on the market, where the print head
>printed across right to left, then back left to right on the next
>line (my memory is that they were actually called "boustrophedic"
>printers, but I can only find "boustrophedonic" in my online
>American Heritage).
"Boustrophedon" (with the extra syllable) is correct. Maybe
"boustrophedic" was another IBM-style attempt to create a
proprietary language by dropping syllables, as in "pel" or
"alphameric". (Does anyone else get the image of Kate Smith
belting out "God Bless Alphamerica"?)
The word I remember seeing used a lot was "bidirectional", but
that's not really right. "Boustrophedonic" is questionable as
well, but at least it's a lot more fun.
One April 1st I wrote a program that intercepted printer calls and
reversed each line image (as well as intercepting the end-of-job
call to print "LOOF LIRPA STRIKES AGAIN" at the end of each report).
I added a boustrophedon option just in case I was feeling really
nasty.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
I don't read top-posted messages. If you want me to see your reply,
appropriately trim the quoted text and put your reply below it.
Charlie Gibbs
(Gary Renaud) writes:
>However, I *do* remember Pascal. You did a Write() to write "stuff"
>then a WriteLn to terminate the line, or just a Writeln() to do it
>all at once. There was no concept of what the actual character(s)
>were to terminate the line. I don't happen to have any source to
>any Pascal RTLs, but I suspect they have no concept of text vs.
>non-text.
But what does WriteLn put on the disk? Under MS-DOS it must be
CRLF, while under Unix it must be simply LF. An MS-DOS RTL will
do something different than a Unix RTL.
I don't know Pascal myself - does Write() work for both text and
binary data? It would make sense that it would just pass any data
through unchanged (i.e. the way the C fwrite() function does if the
file is opened in binary mode). I presume that any end-of-line
coding in Pascal has been isolated in WriteLn (and called at the
end of Writeln()).
Here's a C equivalent of Writeln. Open "fp" in binary mode and
don't use \n anywhere else in your program.
void WriteLn (FILE *fp)
{
#ifdef MSDOS
fwrite ("\r\n", 2, 1, fp);
#endif
#ifdef UNIX
fwrite ("\n", 1, 1, fp);
#endif
#ifdef MAC
fwrite ("\r", 1, 1, fp);
#endif
}
>Again, MS-DOS itself has no concept of text-vs-binary; it's only
>the RTL support routines on languages that have a line termination
>represented as a single explicit character that this would occur.
If my hunch is correct, WriteLn is implicitly a "text-mode" function.
A file written by a Pascal program is text or binary depending on the
presence or absence of WriteLn statements. Hmmm... this would suggest
that Pascal has separate Read (for binary) and Readln (for text)
statements. Is this true? What happens if you use the wrong one?
Fascinating stuff. My brain hurts.
>Of course, there is the matter of whether there SHOULD be differences.
I think many of us like Unix's lack of differences because it avoids
these thorny issues.
>I kind of like the idea of typed files. The idea of being unable to
>open a file the wrong way (without some explicit override option) is
>very appealing after a little incident at work a couple days ago. I
>have to agree with an earlier poster that perhaps the problem is that
>C is too low-level for this kind of work.
On the other tentacle, I'd hate to work with such a file system if
it _didn't_ have some sort of explicit override for when things go
sideways.
>I would really prefer if every system used the same convention,
>whichever it was. Heck, I would like everyone to use the same
>instruction set and endian-ness, too.
So would Intel.
>Just so long as everyone else switches to what I am most comfortable
>with. [wag]
:-)
This message went through a lot of revisions as I wrote it.
Thanks for the thought-provoking discussion.
Charlie Gibbs
(Joe Morris) writes:
Even the model 20? Wow. I never got to play with one (saw one
once), but considering its funky instruction set I just assumed
IBM cut corners on it.
Chris Hedley
> On Fri, 21 Jun 2002 00:26:30 -0400
> Roland Hutchinson <my_sp...@mac.com> wrote:
>
> RH> aes wrote:
> RH>
> RH> > Has boustrophedonic appeared in this thread yet?
> RH> ?ksa uoy od yhW .tey toN
>
> What are you supposed to if the line going right
> ? thgir ot tfel gniog enil eht rof gnol oot si tfel ot
> I can't make it stick out at the left like I can at the
I already had a headache before I tried to read that; now it's
much worse. Thanks.
I can see why boustrophedonic writing didn't catch on.
Chris.
Tim Shoppa
>
> In article <3D1177DA...@trailing-edge.com>,
> Tim Shoppa <sho...@trailing-edge.com> wrote:
> >Philip Homburg wrote:
> >>
> >> In article <3D0FF4C4...@bell-labs.com>,
> >> Dennis Ritchie <d...@bell-labs.com> wrote:
> >> >Nowadays, of course, this is much more obviously a pure
> >> >software game--bit-map displays just understand the pixels.
> >> >(Incidentally, does anyone have display software that
> >> >performs a proper CR that ends up overstriking "abc\r___"
> >> >without a lot of help from the application?)
> >>
> >> The tek-mode in xterm does overstrike by default. Unfortunately, there
> >> is no scrolling, so the display becomes a bit cluttered after a while.
> >
> >?? It *is* emulating a Tek4014, after all.
>
> Maybe it makes sense if you have used the real thing. At first glance,
> it seems an odd way to add graphics support to a vt100 emulator.
The Tek4014 and its near-relative the Tek4010 are amazing
pieces of engineering. Electronics consists of a handful (as
opposed to a bucketful or wheelbarrowfull) of early 70's TTL, yet
thanks to the storage tube you get a really nice high-resolution
graphics terminal.
I only had a Tek4010 for my research use; the lab next to us
had some Tek4014's, which look far more futuristic due to their
bulbous screen.
These were extremely common graphics terminals through the 70's
and into the early 80's, and I think xterm support for them
(considering the wide range of applications that used them) makes
perfect sense.
Tim.
CBFalconer
>
... snip ...
>
> * I believe there were at one time something akin to
> boustrophedonic printers on the market, where the print head
> printed across right to left, then back left to right on the next
> line (my memory is that they were actually called "boustrophedic"
> printers, but I can only find "boustrophedonic" in my online
> American Heritage).
The MX-80, LX-80, RX-80 dot matric printers from Epson (and
others) routinely did this. The result was some odd/even line
misregistration, but not too noticeable. It could be inhibited,
and usually was for graphics output.
Sedulously inscribe "eschew pernicious obfuscation" with
boustrophedonic mechanisms.
Simon Slavin
> Choosing a single character does mean that you can then specify
> the mapping into what is needed to control the hardware.
> Most Teletype terminals (and many others) did separate the
> CR and LF functions into move-to-left and advance-paper.
> Other terminals (like IBM 1050 and 2741) had a NL function,
> no CR, but did have an "index" function character that was a pure LF:
> just advance the carriage. On the other hand, the TTY 37
> could be adjusted to understand NL directly as such. [snip]
>
> One advantage of using a single character (call it NL) is that
> the necessary device control can be put just into the driver:
> there is no problem in deciding whether a CR without its LF or
> a LF without its CR delimits what you think of as a record.
Choosing LF as the single character indicating end-of-record
is fortuitous, nevertheless. Apart from 'curses' I can't think
of any use for feeding a line in today's technology whereas CR
is perfectly useful inside multiline text fields such as street
addresses.
Of course, that use of CR would actually make just as much
sense if it used LF -- after all, it does represent a jump to
the next line -- but people hit the 'Return' key for it, so it's
best that it's represented as the 'Carriage Return' character.
Therefore it's best that 'Record Separator' be indicated by LF.
> There were truly mixed and truly repellent combinations as well.
> In the GCOS system, as we used it in the early 1970s, a
> record (for an ASCII file) as read from disk, had a character
> count, and was also ended by CR-LF. What was the software
> supposed to do when there was mutual disagreement?
I agree: it's a very nasty situation. How do you feel about
languages which have a terminator character for strings so
that the space allocated for the string may not correspond to
the amount of space it takes up ? What is the software
supposed to do if there's no terminating character in the
allocated space ?
Simon.
--
http://www.hearsay.demon.co.uk | [One] thing that worries me about Bush and
No junk email please. | Blair's "war on terrorism" is: how will they
| know when they've won it ? -- Terry Jones
THE FRENCH WAS THERE
Rupert Pigott
news:3D136A5E...@trailing-edge.com...
[SNIP]
> These were extremely common graphics terminals through the 70's
> and into the early 80's, and I think xterm support for them
> (considering the wide range of applications that used them) makes
> perfect sense.
Do you know of any app which thrashes the Tek mode
of Xterm ? I've always wondered what it looked like
when it was doing something. :P
>
> Tim.
Henry Churchyard
Roland Hutchinson <my_sp...@mac.com> wrote:
>Ignatios Souvatzis wrote:
>> When I started sharing text files between VMS and UNIX I quickly
>> learned that the easy way is to set their file type to stream-lf
>> and their record type to implied-crlf.
> To this day, I still can't figure out what happened about ten years
> ago when I moved a bunch of binary files from Macintosh to VMS and
> back via Kermit in one direction and FTP in another. I quickly
> learned never to try THAT again.
I had problems uploading binary files from my home PC to a VMS system
using Kermit until I figured out that VMS Kermit had three file
transfer modes (not two) -- ASCII, BINARY, and also FIXED (different
from BINARY). I'm not sure what the heck BINARY did, but it was the
Kermit FIXED mode which had the result that the uploaded file was of
"Fixed-512" type on the VMS system -- and FTP could only successfully
transfer binary files from a VMS system if those files were Fixed-512
(that's why you had to use the annoying BILF program to transfer a ZOO
archive file from a VMS system to another system).
In my limited range of experience with VMS, almost all the files I
dealt with were plain-text files of default type or Fixed-512 files --
and if they weren't either one or the other, then it was probably bad
news.
--%!PS
10 10 scale/M{rmoveto}def/R{rlineto}def 12 45 moveto 0 5 R 4 -1 M 5.5 0 R
currentpoint 3 sub 3 90 0 arcn 0 -6 R 7.54 10.28 M 2.7067 -9.28 R -5.6333
2 setlinewidth 0 R 9.8867 8 M 7 0 R 0 -9 R -6 4 M 0 -4 R stroke showpage
% Henry Churchyard chu...@crossmyt.com http://www.crossmyt.com/hc/
Russ Holsclaw
> >part of the basic architecture. The big/small split involved whether
> >the channels were external boxes or built into the CPU (where they
> >used cycle-stealing to move data).
>
> Even the model 20? Wow. I never got to play with one (saw one
> once), but considering its funky instruction set I just assumed
> IBM cut corners on it.
ISTR that the Model 20 even integrated the printer control unit into the
processor box, as well. I also recall that the machine had an instruction
called "Transfer I/O" or some such, instead of the usual Start I/O and other
instructions. I don't know if CCW's were still involved or not, but I'm
pretty sure that some shortcuts were involved in I/O on such boxes and that
these differences made themselves powerfully known to the Model 20 Operating
System. In fact, if I'm not mistaken, the 20 even had something weird like
a 4-bit data bus.
A later machine, the Model 25, came along in time that was more of a "true
360" machine, and could execute normal 360 code, like DOS/360 and such. It
was an odd duck among 360s.
Another odd member of the 360 family was the model 44, which was designed
for scientific work. It had none of the storage-to-storage instructions of
the othe models -- NONE!. But it was supposed to be hot on floating point.
It required its own operating system, too, because most SS instructions were
usually part of the Standard Instruction Set, and were therefore used in the
OS. I believe that the Mod44 OS had the ability to fake the SS instructions
via a program-check interrupt handler. I saw one of these boxes near
Washington, DC one late night... in fact, I installed some engineering
changes on it. At least, counting pins on the SLT boards was the same as
other models. :-)
In any case, all the line printer on a normal 360 channel were buffered, and
the first thing they did on receiving a Print CCW was to get the entire
print line into the internal print buffer. This was an all-electronic
operation that happened very quickly, and didn't require any waiting for
anything mechanical to happen (apart from waiting for the previous line to
print, of course.)
--
Russ Holsclaw
Dennis Ritchie
...
> The Tek4014 and its near-relative the Tek4010 are amazing
> pieces of engineering. Electronics consists of a handful (as
> opposed to a bucketful or wheelbarrowfull) of early 70's TTL, yet
> thanks to the storage tube you get a really nice high-resolution
> graphics terminal.
Yes. I should have mentioned them in remarking on typical
lack of modern support for "abc\r___" at the lower level
of graphics--of course, the storage-tube design is rather different
from a bit-mapped screen. We had several of them. Pretty
nice for the time, though quite pricy.
I haven't looked at what xterm does in its 4014 mode, but
it's at least possible that it was put in as an amusing
hack. Bart Locanthi did a 4014 emulator for the Jerq/Blit
terminals at Bell Labs, and it was amusingly slavish in its
emulation, including the remarkable full-screen flash when
you erased the screen. Every time it happened you felt that you
were getting a bit of a sunburn.
Dennis
Dennis Ritchie
> Choosing LF as the single character indicating end-of-record
> is fortuitous, nevertheless. Apart from 'curses' I can't think
> of any use for feeding a line in today's technology whereas CR
> is perfectly useful inside multiline text fields such as street
> addresses.
Fortuitous in that that particular character was chosen, I suppose.
As I said, CTSS (late on), Multics, and then Unix happened to
choose it, apparently in some belief that the ASCII LF character
had an alternate explanation as NL. There certainly were terminals
that could be made to understand one single code as doing the
NL function, others that couldn't. The more important point
really is that choosing one single character--once a decision
has been made not to use a counted or record-formatted scheme--
is a good choice. Then the device driver can sort things out.
...
Dennis