Addressing the "bug" is not simple - the edit controls behaviour could be changed in which case it could cause existing programs to behave differently, or extra code would have to be written for notepad to do its own text editing. Microsoft takes backwards compatibility very seriously.
Anyone curious about the Microsoft side of this should find Raymond Chen's Old New Thing blog interesting (about 5 posts a week). For example here is content tagged history: https://blogs.msdn.microsoft.com/oldnewthing/tag/history and here is how there are actually two copies of Notepad on each system: https://blogs.msdn.microsoft.com/oldnewthing/20090312-00/?p=...
You just add a new mode to the control that enables the new behaviour. Existing programs using it would work fine.
> Today, we’re excited to announce that we have fixed this issue!
You've managed to encapsulate about 35 years of frustration with software in a single sentence.
So the intended behavior was to incorrectly display the file contents?
Also, I don't know why you quoted "An issue (as perceived by a user)", since I can't find that in the article anywhere.
> So the intended behavior was to incorrectly display the file contents?
I would argue that you're getting hung up on the author's lack of precision. Does the file look garbled in that screenshot? Sure, I think that's a reasonable interpretation of things. Is it incorrect? That depends on what Notepad was intended to be used for. I suspect Notepad was intended from day one to be a simple means of read and editing "plain text" files written on Windows, and under that premise Notepad has always functioned perfectly.
To the author's credit, belaboring the distinction between incorrect behavior (a property of the object with respect to the intentions of its creator) and undesired behavior (an attribution given by a user with respect to their needs) would make for boring reading.
> Also, I don't know why you quoted "An issue (as perceived by a user)", since I can't find that in the article anywhere.
But the word bug has been coopted by the masses to have the wider meaning of “doesn’t meet user expectations”.
In any case, bugs need not be only in software. As as earlier comment says, bugs can be in specs, too. Here, the spec was buggy and that has been resolved.
Or to put it another way, the defect was in the spec, and that has been resolved.
(Note that many specs are implicit and best derived from the software in question. If that is the case for Notepad, then fixing the bug in the spec requires one to fix the code. I somewhat doubt Microsoft follows that practice, but it's certainly not beyond the realm of the possible.)
Take a look at the first screenshot on the announcement page and then tell me it's working as intended.
As a Notepad developer, I might agree with you that Unix line ending support is a new feature.
As a user, I double-click a text file and it opens in Notepad. It opens fine in all of my other editors, but is garbled in Notepad. That feels like a bug.
I don't try to open .xlsx files in Notepad, so it isn't very relevant to me as a user that Notepad won't open them. If I did open one accidentally, I'd think "D'oh! That's not a text file!"
But this is just terminology. Files that Notepad couldn't open usefully before will now work. That's a good thing, whatever we call it.
The standard line ending format in the '60s, which was the height of the mainframe era, would probably have been the newline character in IBM's EBCIDC encoding, which differs from the value used for ASCII (https://en.wikipedia.org/wiki/Newline). Unix didn't really start taking off until around the early '80s IIRC.
Windows properly supported the newline format for its platform of lineage (CP/M + DOS) which also didn't start taking off until the early '80s. Not sure that Unix has any real claim to precedence here.
Probably the same way it still works on today's Unix systems: it converts NL to CR+NL on output. See the manpage for the stty command:
Output settings:
[-]onlcr
translate newline to carriage return-newlineBut (in §4.1.2.2) it "strongly recommended" that people "use CR and LF to obtain the effect of New Line".
These are just holdovers from teletype days and with Notepad being solidly GUI based it could have simply had a backwards compatibility mode for 'DOS' style files.
Incidentally, CR-LF and LF-CR are interchangeable on a teletype, but various windows software would respond totally unpredictable to that alternative, including some spectacular crashes.
Very old filesystems didn't track file sizes in bytes, just blocks, so a literal EOF byte was needed to know where to stop reading in the middle of the last block of 128 bytes or so.
So any device that uses it usually requires a special adapter that converts CR-LF to LF-CR otherwise the printer could be damaged and buffers input while the printhead lock the linefeed.
The device was to my knowledge not very popular, incredibly old and irreplaceable as part of a legacy application written for an old 8bit computer system.
http://hans.presto.tripod.com/scan/teletype/28_02.html
"Dependable carriage returns with only one carriage return and one linefeed signal" at 100 wpm.
Now I'm curious :)
I don't have a teletype handy though, I'm sure other HN'ers do.
We always played it safe anyway, by punching CR LF RUBOUT at the end of each line on a paper tape. The RUBOUT added a bit more delay before the next character was printed, so you could feel sure that it would print at the correct position.
From what I remember most TTY drivers would automatically insert an appropriate delay after a CR because the LF is optional, you can happily overprint a line if you want.
The NUL character was useful for inserting a delay into the serial stream.
And in sync links (not TTY's those were mostly async with start and stop bits, more like HDLC style stuff) those nuls were mandatory, you had to send something.
* http://jdebp.eu./FGA/dos-character-26-is-not-special.html
And SUB was ASCII's equivalent of U+FFFD.