Hacker News new | ask | show | jobs
by joshuaeckroth 2970 days ago
Almost feels like an April Fool's joke. For 30 years Notepad had this bug and I've always wondered why they never fixed it. It was just "one of those things" like the unusual arguments to Unix find or tar commands. I find it very surprising that someone finally bothered to fix it!
6 comments

I see it as a natural result of the "Windows Subsystem for Linux" effort. Also Azure Sphere uses Linux.

I expect Windows to become more Linux friendly.

I would not consider it a bug. It was working as intended. This is a new feature.
Correct. The existing Notepad is top level Window and menu bar around the existing [edit control](https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...). It has always had the same limitations - eg in way earlier versions of Windows it was limited to 64kb of text.

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=...

>…the edit controls behaviour could be changed in which case it could cause existing programs to behave differently…

You just add a new mode to the control that enables the new behaviour. Existing programs using it would work fine.

Adding new features to an existing Windows control, particularly one that has existed since the dawn of time, is a much bigger deal than adding to a simple utility. The last time that happened they added a whole new control, the Rich Edit.
Oh come on, framework libraries add new features to controls in a backwards compatible way all the time.
There's a quick fix on all existing systems, just open in wordpad.
The article disagrees:

> Today, we’re excited to announce that we have fixed this issue!

Users can take issue with intended behavior, as in this case. This resolves that issue, despite the old behavior working as (previously) intended. “An issue (as perceived by a user)” is not equivalent to a bug.
> “An issue (as perceived by a user)” is not equivalent to a bug.

You've managed to encapsulate about 35 years of frustration with software in a single sentence.

People don't seem to understand that a bug in the spec is just as bad (or worse) than a bug in the code.
> As you can see, Notepad is incorrectly displaying the file’s contents, making the file look garbled.

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.

>> As you can see, Notepad is incorrectly displaying the file’s contents, making the file look garbled.

> 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.

https://en.wikipedia.org/wiki/Scare_quotes

Quotes are not solely used for citation. They are also used for emphasis or indirection. You can also use quotes to set off something that someone explicitly did not say as a way of indicating a paraphrasing.
I think “bug” used to be slang shorthand for the more professional term “defect”, and under that definition the Notepad change would accurately be described as a new feature.

But the word bug has been coopted by the masses to have the wider meaning of “doesn’t meet user expectations”.

"Defect" always seems like a johnny-come-lately polishing of the word "bug", rather than vice versa. I would be surprised if "defect" is truly the original term for a software bug, and "bug" was chosen as shorthand.

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.)

When "working as intended" means "doesn't work at all", I consider it a bug.

Take a look at the first screenshot on the announcement page and then tell me it's working as intended.

Is it a bug that opening an excel spreadsheet in notepad gives something unreadable? Linux line endings are a type of file that notepad was never designed for.
I suppose it depends on whether I'm wearing my "user hat" or my "Notepad developer hat".

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.

To be more precise, they're Unix line endings. So yeah, I'd consider it a bug if it didn't support what has been the standard line ending format since the 60's.
> So yeah, I'd consider it a bug if it didn't support what has been the standard line ending format since the 60's.

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.

The standard line ending of the '70s was CR/LF, because the printers commonly used as interactive terminals required them both. I wonder how that worked on the first Unix systems?
The standard in the 1960s, USAS X3.4-1968, actually prescribed both forms.

But (in §4.1.2.2) it "strongly recommended" that people "use CR and LF to obtain the effect of New Line".

I'd entertain an explanation of how the original behavior was a feature :)
The crlf line ending has been the standard on the PC going back to the days of DOS. That's what notepad was supporting when it was developed. Unix was strictly a server or esoteric workstation OS at the time. So there was never a requirement for Notepad interoperability with Unix files on Windows.
A double byte end-of-line sequence was a bug to begin with. Just like ending files on ctrl-Z (yes, it is End-Of-File, but filesystems know where the end of the file is already).

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.

> Just like ending files on ctrl-Z (yes, it is End-Of-File, but filesystems know where the end of the file is already)

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.

Actually, I had to work with a line printer that didn't handle CR-LF but LF-CR. The printer was designed to have people rip of paper cleanly and the easiest way to do that is to have a button that locks the printer head on the left side, which causes it to engage a gearing on the line feeder which prevents it from moving. That allows a human to press the button and rip of the paper. The process was fairly fast and without it the linefeed would slip and you would rip out half of the paper from under the printer head. Unfortunately this also means if you issue a CR-LF you will first hear the printer head moving and then a jamming noise from the line feed followed by the printer blowing a fuse.

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.

Are they really interchangeable? Moving the print head from the right side to the left could easily take two character times, and a teletype didn't have any buffering.
The combined time is equal, why would it matter what the order is?

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.

Actually, no it isn't End-Of-File.

* http://jdebp.eu./FGA/dos-character-26-is-not-special.html

And SUB was ASCII's equivalent of U+FFFD.

Nice link, but even COMMAND.COM would see CTRL-Z as special, so I'm not sure why the author saw fit to make that claim, it's fairly well documented that plenty of DOS utilities did that and together with the core they make up the OS.
>Unix was strictly a server or esoteric workstation OS at the time.

And of course Mac OS wasn't Unix then, and used a different (third) line ending style.

On 32-bit versions of Windows, EDIT (the MS-DOS Editor) reads Unix file endings fine. So finally notepad reached feature-parity with that one...

I am not sure, when they introduced it. It might be that it happened in Windows 95, when edit became a stand-alone program. Not sure if the QBasic-based editor in DOS 6.22 or earlier supported it.

It would be more unreal if they introduce "Windows 9x" desktop shell, probably for me it would be reason even to consider to dual boot to windows
How much would it cost Microsoft to buy Notepad++ and Classic Shell, and remove two of the biggest annoyances in modern Windows?

Meaning, of course, that they would use them in Windows, so there would be a text editor and a start menu that work. Not buy and kill.

They did it for sysinternals
for notepad++, they already have vscode
Plus, I think Windows strives to not be "batteries-included" in some ways, perhaps in order to encourage a healthy third-party software ecosystem (and perhaps to follow the spirit of the anti-trust ruling.) Windows 10 has fewer bundled apps than Windows 98 did. Nothing is an "optional feature" any more; it's all App Store packages [that happen to be made by Microsoft] now.
Windows 10 still has plenty of "optional features". Two ways of viewing these - Settings/Apps/Manage Optional Features (For instance, if you want to install openSSH, this is where you'd do it). Also, Control Panel/Programs and Features/Turn Windows Features On or Off. This is where you'd install the telnet client, container support, Hyper-V, tftp, etc.
VS Code seems like less of a general-purpose text editor, though (and is also much "heavier")
heavier sure, general purpose I'm not convinced
Not really comparable in term of resource utilization
It wasn't a bug. I actually liked the predictable nature of notepad, even if it did support a line ending I never use and run on an OS I never use.
It was never a bug. For \r\n you had WordPad, for more you had Word.