A better example would be file line endings, where Microsoft did get it right (\r\n) and all the other OS's screwed up using just \r or \n.
The biggest problem is that each OS went its own way (Mac started with \r but of course uses \n now). If they all had the same line ending all along, whatever it was, no one would think much about it.
\r\n has the obvious disadvantage of being twice the size, along with making it possible to land in the middle of a line ending instead of before or after one.
Of course one advantage would be if you're controlling physical equipment where carriage return and line feed are independent of each other. I learned to program in 1968 on a Teletype ASR33 where CR and LF were literal commands to return the carriage to column 1 and advance the paper. You had to use both because they did two different things. Or on occasion you might use CR by itself to overprint a line. LF by itself was pretty rare, but would do what you expect if you used it: advance the paper without moving the print carriage.
CR LF was fine if you were typing interactively - in fact you just had to hit the CR key and the remote system would provide the LF. But usually we would punch our programs on paper tape, dial in, run the tape through and get the printout, and hang up right away. At $30/hour in 1968 dollars, this saved a lot of money. And of course you would run your tape through locally to print out and proofread your program before testing it online.
To be able to print a tape locally, you needed both CR and LF, but even that wasn't quite adequate. You really wanted to allow a little extra time for the machinery to settle, so the standard line ending we punched on a tape was CR LF RUBOUT.
RUBOUT was a character that punched out all the holes in a row of the paper tape. It was ignored by convention, so you could erase a typing error when punching a tape by pushing the backspace button on the tape punch and hitting the RUBOUT key.
Because it was ignored, RUBOUT was also useful as a "delay" character in the newline sequence. So I guess I'll never get over the feeling that the One True Line Ending is: \r\n\x7F
(Nah, I'm happy with \n, but it makes a good story.)
For example, you could define that your file was fixed length records (like the old punch cards); at that point each line doesn't have a line separator at all; the \n or\r is not stored on disk. But when you read a line using the C routines, one will be added.
I am not sure what C or RMS has to do with this
* http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
[1] https://en.wikipedia.org/wiki/Internet_Explorer_box_model_bu... [2] https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing [3] https://css-tricks.com/international-box-sizing-awareness-da...
Well, IE implemented their version of the box model in '97 (coincidently, NN4 did the same); the box-sizing property was first proposed in 1999[1], and first appeared in a draft in 1999[2], and implemented in Gecko in 1999[3] and in IE5/Mac in 2000[4].
That's two years from IE/NN shipping the non-standard box model (the standard one was defined before IE4 and NN4 shipped) to having a property to toggle between them. To me, that isn't "many years".
Really what makes it seem like many years is the fact that IE didn't implement box-sizing until IE8 which shipped in 2009.
[1]: https://lists.w3.org/Archives/Member/w3c-css-wg/1999JanMar/0... (sorry, W3C MO space, but I think at this point nobody cares if I mention that publicly)
[2]: https://www.w3.org/TR/1999/WD-css3-userint-19990916#box-sizi...
[3]: https://github.com/mozilla/gecko/commit/3ee32d59158a036bd667...
IE was stupid to not implement the spec, the spec was stupid for not doing it the way IE did.
Other than that, I don't see it being any more right. But it is a convention that is far older than Windows or MS-DOS. I saw it myself first on CP/M but it was there on VAX/VMS and I expect the Teletypes had it from 1960's.
* H. McGregor Ross (1964-01-01). "The I.S.O. character code". DOI 10.1093/comjnl/7.3.197. The Computer Journal. Volume 7, Issue 3. pp. 197–202.
* Jerome H. Saltzer and J. F. Ossanna (1970). "Remote terminal character stream processing in Multics." DOI 10.1145/1476936.1477030. Proceedings of the AFIPS Conference 36. pp. 621-627.
But mostly I was just reacting to the silly idea that CRLF would be right and lone LF not: Microsoft didn't come up with that idea. It was there already in 1960's and perhaps useful when you didn't want to do any line drivers for converting strings at output. But that's not really any more "right" than other conventions.
You left out a key qualifier: CR/LF is the semantically correct way to represent a newline on a physical device that has a physical carriage that has to move back to x=0 and advance one line in the y direction in order to start a new line. What devices connected to any computer today have that property? Answer: none.
In fact, even on computers that have such devices connected, the semantic meaning of "newline" in any file the user actually edits is most likely not to actually cause a CR/LF on the device. Word processing programs for decades now have separated the in-memory and on-disk file data from the data that actually gets sent to a printer. So the file you are editing might not even have any hard "newlines" in it at all, except at paragraph breaks--and that's assuming the file format uses "newline" to mark paragraph breaks, instead of something else.
Neither world is clean, pure, and free of weirdness that's only properly understood when looking decades in the past.
Dot matrix printers are surprisingly common as they are still cheaper to run than the alternatives. That's at least one.
It's worse than that. His position was: MS's understanding and implementation of the box model is the correct interpretation of the W3C specs (yeah, I know).
IMHO, what SHOULD happen is that if you have a device that has special timing requirements (like the old fashioned printers with no memory), then the driver is responsible for the handling the timing. Adding in weird bits to everyone's files is a bad idea.
And yes, I know the difference between carriage-return and new-line. And I know that in the old C specs, "\n" didn't have a guaranteed mapping to either.