One would think the whole LFCR discussion would have been documented and saved throughout the decades. One should really be warned about thinking.
Despite what you will read in Google’s always right <cough><cough><hack><hack> AI as well as other places online, way more than Acorn BBC Micro use LFCR for line endings in text files. During the heyday of Midrange computers it was the wild wild west. Lots of names you don’t hear anymore, DEC, Singer, Sperry, MAI, Prime and so many others were all vying to be the last one standing. You had to have both a gimmick and a niche to make money. Eventually software would be written on cheaper platforms to serve your niche and one trick ponies found out that other ponies could learn the trick.
Serial vs Propietary
The best gimmick (for the day) was to support high speed printers using your own proprietary cable. If you supported serial companies would try to get by purchasing cheaper third party printers. At least they could once ASCII became ASCII. Well, they could if and only if your computer had 8-bit bytes and 16-bit words. Many computers of the day and 36-bit words and used 7-bit ASCII to stuff multiple characters into a word. This, actually was a performance thing.
Cheap (for the day) serial printers had a single printhead. Many also doubled as paper terminals. This printhead was slow. 8 or 9-pin dot-matrix. When communications was only 150 BAUD (or less) the printer didn’t care which order the line ending characters came in. Despite having only a single character buffer, the print head could make it back to the left margin. At 300 BAUD or higher it didn’t have a chance. When the next printable character came in the printer would start printing wherever the printhead was on the line. The time the print head required to get back to the left end of the platen dictated sending CRLF.
LF = 0XOA
CR = 0X0DDespite green newbies spouting “Carriage Return Line Feed.” Hex editors reveal many of today’s data files actually have 0x0a 0x0d for line ending bytes. With today’s printers not a big deal. This will fry your eggs if you are writing data communications software expecting 0x0d 0x0a.
Proprietary
Proprietary printers had high speed (for the day) proprietary communications cables and ports. These were highly profitable. DEC used to have Data Products making printers for it. The Data Products near perfect clone of the DEC printer retailed for half or a little over half the DEC branded version. DEC wasn’t alone in milking this revenue stream.
Most proprietary printers were drum, band, or page.
Page printers were just amazing. You could hit the FormFeed button on your cheap printer as fast as you wanted and you couldn’t shove paper through it as fast as a page printer printed. Some were rumored to use a near page sized dot-matrix head with massive ribbon. Others were laser like the Xerox 9700 black & white that could duplex print 120 pages per minute. Keep in mind that printer was introduced in 1977.
The lesser high throughput drum and band printers needed to receive LF first. This was the most expensive (time wise) operation. All the carriage return did was tell it which hammer to hit first.
FORTRAN CR
FORTRAN had a lot to deal with. FORTRAN programs had to read data files (on tape) from IBM, DEC, insert-manufacturer-here. It had to convert on the fly from EBCDIC, 7-bit ASCII, 8-bit ASCII, a few other short lived encoding schemas, oh, and computers storing data in 36-bit words. There was actually a performance reason to use 7-bit ASCII and 36-bit words. It allowed you to wedge 5 characters into a single memory transfer unit. 36-bit word machines (generally) wouldn’t let you move one byte at a time from RAM to the CPU.
I don’t know about new FORTRAN standards, but FORTRAN IV and 77 defaulted to CR control text files. With everything else it had to deal with, FORTRAN wanted one constant to make the rest smoother. Yes, the original macOS used CR. Most likely because FORTRAN did. Hardware engineers would have studied FORTRAN in college.
Seismic Testing
By law in America, possibly around the world, any company engaging in Seismic testing for oil & gas exploration had to provide that data to whoever asked for it. In the 1960s this would have been on paper tape. During the 1970s it would have been 2400 foot reels of magnetic tape. Somewhere those tapes are still in storage because you don’t do another round of blasting in the same area, you change the algorithms that analyze the data.
Oh, the testing itself. A company gets a permit, drills a bunch of shot holes, puts dynamite down them, scatters a bunch of sensors around the area, hooking them up to some kind of computer. They will then either detonate all of the dynamite at the same time, or in a particular sequence to get the data they want. The sensors record how the shockwave/force/sound moved through the ground underneath them. Soil and rock are different than oil and gas. Really all I know about that. The reason I’m telling you this is so you understand why FORTRAN had to deal with all this shit. In the 1960s you had FORTRAN or Assembly. COBOL was not useful for scientific programming. Probably still isn’t.
LF
Modern macOS and Linux use only the LF character. As to why Linux does this, who knows. Other than the fact Linus was trying to make a UNIX-like free operating system and UNIX (most if not all variants) used LF, I don’t have an answer. Modern macOS, on the other hand, is built on BSD (Berkley Software Distribution). BSD is a Unix, not a Linux.
Summary
Don’t just spout “Carriage Return Line Feed,” look at the file in a HEX editor. If you see 0x0A 0x0D it is LFCR. Now you know there is a reason for that.
