I don't understand all the negativity in this thread.
Is this Microsoft's crowning achievement? No, it's just a stupid little historic decision that someone remembered and decided to fix. They even took the time to enable admins and power users to use the old behavior. I too don't see who'd want it, but who knows? People do unexpected things sometimes.
Why bash them for that? There are enough good reasons to bash Microsoft... There are Microsoft products that fill me with a fiery rage of a thousand suns. But they did something cute here, someone there deserves a good word.
I think it's mostly humor. Bugsmithing and interoperability impedance of this form was almost Microsoft's raison d'etre in the 90's. Stuff that was simple and obvious everywhere else just didn't work on windows, even though the fix would be 100% trivial and probably result in better standards compliance. And MS liked it that way.
So sure, this is good. It doesn't exactly undo all those decades of grief. So we're laughing grimly at the "progress".
Because PC's were maybe only 60% of the actual software development market and there were a lot of us hackers whose "parochial" needs involved getting stuff to work across both platforms. Were you actually there?
I mean, Notepad is a silly thing, sure. But the crazy spec incompatibilities between MSVC and the C9x and C++03 standards were a huge source of grief for me personally. And the mess caused by Microsoft's "Java" implementation was straight up evil.
To be fair, U*nix editors in the 90's had problems with line endings other than strictly newline. Even agnostic editors like Emacs had problems. It was a three-way mutually cultivated impedance.
What is "bugsmithing" - did you just make this word up?
(I googled "define bugsmithing" without quotes, and this HN thread I'm typing in was the top result behind only an unrelated site called the bugsmith, an exterminator. I didn't see any relevant hits.)
"Smithing" in English refers to making something, in the sense of a blacksmith forging iron. So in this context "bugsmithing" refers to making bugs -- deliberately (more or less) doing things differently or incorrectly so as to increase the impedance required to do work on less popular platforms. Microsoft was famous for this.
As far as I understand, it's a site criticizing HN, by summarizing in a satirical tone the discussion on some of the top stories.
The about page:
About this webshit
[...]
Hacker News is an echo chamber focusing on computer posturing and self-aggrandizement. It is run by Paul Graham's investment fund and sociopath incubator, Y Combinator.
In general, content that can be submitted is defined as "anything that gratifies one's ineffectual curiosity".
The interesting thing is this change was almost without a doubt done by some random developer at Microsoft rather than an institutional luminary for certain, and yet here we judge the change based on the institution rather than who may have produced it.
The backwards-compatibility is probably an institutional thing.
I've dealt with a Microsoft storage library for Java once that had an absolutely idiotic bug - you'd store a certain value, but would get something slightly different when retrieving it in 100% of cases [0]. I reported the bug and it was quickly fixed. But what amazed me was that the next version came out with a page long description [1] and analysis of the bug, its meaning for compatibility with other storage clients in different cases, the fix, and astonishingly a new flag you could enable if you want to keep retrieving screwed up values.
> The backwards-compatibility is probably an institutional thing.
And the apparent routing of all bug reports and feature requests to /dev/null -- er, the recycling bin -- certainly seems to be an institutional thing. I have no doubt that thousands of their paying customers have complained about this to Microsoft over the years and it had to have been ridiculously simple to address.
I have a really hard time believing that this is the first time some random developer at ms has gotten fed up with notepad's lack of line ending support and tried to do something about it.
This is the first time Microsoft has actually released it though. And that's an institutional thing.
I suspect some of the less positive comments are folks commenting are likely on their 15th or 20th laptops, over just as many years.
When the death count gets that high - it's easier to call it buying the eventual death of a new laptop. Buying a new laptop has become a somber affair to go along with the eventual reinstall of your entire setup far too soon.
Luckily there are tools today that make this much less painful.
This particular bug, however, required use of Notepad++ instead for years. Repeat for every other missing or broken piece of MS tech. Vista was so bad I was willing to suffer on the spot switching to Mac.
I'll accept this is as a symbolic peace offering - years of having to install a separate text editor and lots of other unnecessary won't get back that time.
There's a lot of innovation coming out from MS, something we normally wouldn't have said even 3-4 years ago.
Looking forward to the increased linux integration to continue, and have a good look. Until then, MacOS, despite it's aging warts, just works and stays invisible for the most part.
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!
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.
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.
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.
>> 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.
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.)
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 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.
It doesn't matter that the combined time was equal. What mattered was that both operations completed before the next character was printed. The carriage return and the line feed could happen in parallel, but I'm pretty sure that carriage return could take longer than line feed, at least in the worst case when the carriage was near the end of the line. So if you did the line feed first, the next character could print while the carriage was still returning.
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.
I see what you're getting at. That the next character would start to be printed before the carriage return had completed with the sending side not respecting the fact that it had just sent a carriage return by waiting for a bit.
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.
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.
The head wouldn't start moving until it got the CR, and if the LF comes after it would have 2/10 of a second to traverse the page. If the LF comes first it would only have 1/10 of a second.
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.
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.
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.
Microsoft really goes the extra mile when it comes to backward compatibility. "Just in case you depend on Notepad being broken, we added a setting for you!"
Indeed, the registry is actually a good feature, it's a configuration database rather than relying on flat files as in the "just go to /etc/<package>/<package>.config or /home/<user>/.package/<package>.config" of the linux world.
The problem is that when it was first introduced in windows 95 the registry would easily and often corrupt causing many issues so some people still associate the registry with being a bad design, when it was actually just a bad implementation of a good design.
The windows registry is absolutely terrible at its job. The namespace is polluted from day #1 after installation and this only gets worse as a box gets older. The number of places the same key could appear are baffling and you never really knew when you had exterminated the last instance of HKEYsomethingorother to achieve the desired effect.
Yes, but this is because third-party developers don't know what the hell they're doing in regards to the Registry. The Registry was never supposed to be a persistent storage location for application configuration data. INI files were doing very well when the Registry was created, and Windows still used INI files for most things even as it exposed some things in the registry. The INI API was the official application configuration API. (And today, application manifests are the official configuration API: essentially INIs in XML.)
No, actually, the Registry was supposed to effectively be the place to find and manipulate the same sort of data you'd get from Linux pseudo-filesystems. HKEY_CURRENT_CONFIG is essentially Linux's /sys, for example. HKEY_LOCAL_MACHINE\System\CurrentControlSet is equivalent to Linux's /dev. Etc.
The nice thing is that each Registry hive could be implemented with a different backend, and thus impose its own constraints on the format of the data. HKEY_CLASSES_ROOT, for example, could just be an interface into the shell's filetype database, and require that the data you put in there conform to the columns of that database, and their types.
HKEY_LOCAL_MACHINE\Software, though, was where things went wrong. The HKLM hive, and especially the Software key under it, was essentially a sort of... asynchronous RPC. It was there to allow system daemons to have their configuration changed at runtime, without needing to be restarted. They could just re-read Registry keys directly each time they do something, and so writing to the HKLM keys would change what happens as soon as their next message loop.
But HKLM was also persisted as its own free-floating database file, just because it was much more convenient to write the key once, rather than having to write it once for immediate runtime effect and then another time to an INI file for persistence (like how, say, Linux's sysctl(2) + sysctl.conf(5) work.)
And third-party developers came along and noticed that they could just write whatever they liked into HKLM under some random key (at least during install-time in NT; or all the time in 9x), and then be able to get it back later. So they did. Oops.
Everything since then has been patches to try to fix the problem this caused (because, from Microsoft's perspective, you do still have to keep these programs working, despite their faux pas.) HKEY_CURRENT_USER was created because applications were just writing their config system-globally to HKLM and thus a multiuser system would have each copy of the software retaining its config from other users' sessions. (It was easier to get them to change the target hive, than to get them to rewrite their code to use INI files for config.)
The job of the registry is to be a reliable structured storage with access control and other features. It is not responsible for the things that go into itself.
If you put together a structure like that and leave the sordid details up to the implementer and you supply a mostly confusing example as the set shipped with the OS, and subsequently mess it up even further with your own application installs you own the mess.
An upvote isn't always enough, so I just want to say I support your holistic view of engineering and find the "not a bug, not my problem" approach detrimental to the broader success and acceptance of technology in society.
I'm unable to extract anything specific from your comments. Are you still talking about the registry or about something else? Its cathartic to vent, but the registry is not the source of your frustration.
Okay.. call me small-picture-minded but I much rather prefer - "I press a button M and Feature X doesn't work when I choose option Y" - over "Feature X is terrible at its job"
The problem is not that they don't work as intended, the problem is what is intended. You can't just throw application developers an API like a system wide key value store and expect the whole worlds ecosystem of applications to organize itself around it. Android and iOS solve this much better by sandboxing application settings within the app. Uninstalling the app is guaranteed to remove any traces of it (unless you give access to "all files and photos"), whereas on windows there is always some remains.
Its just a database. Using the registry is not a requirement for any app. They can store their configuration in a text file, they can store it in the cloud, they can do whatever they want, they can even create a C:\etc and store it there :)
Sure, there exist badly behaving apps that don't clean up after themselves when they're uninstalled. Windows gives apps the freedom to choose their own method of installation, but some vendors abuse those freedoms. I don't quite know what the OS is supposed to do about that. Windows already does an insane amount of work trying to keep buggy apps running, something that macOS or iOS or Android or Linux don't. The fundamental goal of any consumer OS should be making sure that the software a user purchased continues to work.
>Android and iOS solve this much better by sandboxing application settings within the app.
So, multiple users on a device = separate settings = multiple app installs? That might work OK for consumer devices, but won't really fly in the IT world.
We live in a world where MongoDB is at the butt-end of all Database and ACID jokes.
But the award should go the Windows Registry, a Key-Value store that combines the drawbacks of a half-assed filesystem with the advantages of piping your database to /dev/null.
A Database would be capable of using an index to traverse all the keys. The Registry does a linear lookup at each pathnode.
I think the macOS User Defaults system is still my favorite config system. Unified api (`defaults` and NSUserDefaults), but stored in user-editable (and easily cleaned up) files with standardized naming and formatting. It's not perfect (kooky and unwieldy XML syntax, no standard equivalent of conf.d), but it solves the pain points I've seen with the Windows Registry (monolithic inscrutable database) and unix commands (random config files each with their own custom place and format)
I think the major problem with the registry - besides being obscure - is that it can grow really slow as it fills up, and many programs do not clean up their registry data when being uninstalled. I think this is one of the major factors why Windows grows so slow after a couple of years on machines where lots of software is being installed and uninstalled.
Granted, but the presence of those files does not slow down the system significantly. With leftover registry keys, you pay the price until you install the system from scratch.
(Windows might have improved the registry handling code since Windows 95/98, I think it's not quite as bad these days... but that might also have to due with computers being much faster than 20 years ago.)
if it's trying to be a database, it's doing a terrible job. all the problems of not being files (can you do "find HKEY_CURRENT_USER -name mypackage" to see what the uninstaller left behind?) with none of the benefits of a database (ACID).
When they were working on Windows 7, Microsoft tried to be more open about the development process in order to repair some of the damage Vista had done. So one day, I came across this video, an interview of a few Windows developers.
At one point, the person doing the interview asks, "So, what do you guys think of the Registry?". Awkward silence, followed by uncomfortable laughter. Finally, one of the programmers says, "I think it's fair to say it was far more [widely used] than any of its designers had anticipated."
(Quoting from memory from a video I saw once, ~10 years ago, so the wording might not be perfectly accurate, but that's how I remember it.)
This is not correct, Windows Registry updates are atomic and transactional. There may be other problems with the registry model, but it is a "real" database.
ACID means more than atomic updates, though. To be ACID-compliant, you'd have to be able to group several changes to the registry and have them take effect either all at once or not at all.
In cases when I need to write several values atomically (e.g. in a program with persistent window positions, after user moved a window I want to write all 4 coordinates of the rectangle), I just keep them in a single value, either string or binary. Even without KTM, registry API already guarantees value writes are atomic.
Weird settings are supposed to be hidden in weird places. There's no reason that a setting like "use broken line endings" should be in a nice easy to find place.
It's really surreal to see how far behind basic Windows tools are compared to counterparts in other operating systems. Compare Notepad to something like Gedit or Kate that comes with most Linux distros and are much more advanced. I just assumed any programmers still on Windows would be using Notepad++ or some sort of IDE. It's also pretty silly that you have to hack registry keys just to change some basic settings.
Notepad is a very basic editor. Likewise, most Linux distros come with nano or some other very feature-limited editor.
While I did once know a developer who used notepad as his primary editor, it was never intended to be anything but a very simple editor for INI files and the like.
Yeah, I think it's safe to say most Linux and macOS systems don't have an editor as basic as Notepad (even ed has regex support!) The closest equivalent I can think of is Mousepad from Xfce. I don't really see the need for it either. If your distro comes with something like nano, gedit or KWrite out of the box, why would you need something like Notepad?
The registry key hacking is to support backwards compatibility... for those workflows that require opening Unix text files in Notepad and inexplicably NOT seeing linebreaks...
This is the wrong comparison. Notepad is like nano or ed. More powerful editors are available on Windows too.
> I just assumed any programmers still on Windows would be using Notepad++ or some sort of IDE.
Usually we do. But notepad can be invoked quickly from the command line, tends to handle huge files better than N++ or other IDEs, and is opened by default by a lot of utilities like git (you can change this, of course, but you might miss one). So it ends up getting used a lot for quick one-line changes and improvements are still welcome.
tends to handle huge files better than N++ or other IDEs
That's been my experience too --- I've opened several hundred MB files (mostly logs) in Notepad, mostly for searching through, and it handles it quite well. Inserting characters at the beginning can get a little laggy, but that's still nothing compared to a lot of other IDEs/"industrial strength" editors that choke on much smaller files.
...and yet the standard Windows edit control that Notepad is based on does nothing fancy at all; its data structure is basically one array that holds the entire file contents. No ropes, gap buffers, or other "advancedness" --- just one big buffer. It also means extremely low memory usage, a tiny amount of fixed overhead + file size.
(I am one of those programmers whose main source code editor on Windows is Notepad. I also mainly use the cmd for compilation. I've never felt the need for anything more complex, and I do use an IDE (VS) mainly as a debugger, but if I just want to open source code and read or edit it, I use Notepad. Then again, I don't use those languages where an IDE is almost mandatory for navigating through source code, so it works well. In the time it takes for an IDE to load, parse, and display a file, I could've opened, edited, saved, and compiled with Notepad.)
> Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!
There was a thread on here at the weekend criticising Windows 10 for not making enough progress, and also MS for not properly testing updates. I hope this silences those critics. A thoroughly tested change that is fully backwards compatible, but also adding genuinely useful new features. If you were wondering whether to upgrade to Windows 10 I think this settles it.
Not sure how you go from "finally catching up with support of a basic text format that's around for decades" to "making enough progress". This won't silence anyone - it just shows that Microsoft is finally starting to do things it should have done 20 years ago.
I see it more as a platform war that's finally settled. No more Mac/Linux/Windows linebreaks, now we can at last talk about "Linebreak".
I mean there is only so many ways of putting together two different characters. Is it supposed to be \n\r or \r\n? Or just \n? Or mabe it's \r? So much of the last 35 years have gone to writing the wrong line endings for the intended platform...
If you were wondering whether to upgrade to Windows 10 I think this settles it.
As long as the telemetry/phoning home is still pervasive and difficult to disable completely, no. Ever since ~2K/XP or so it's always been one step forward, many steps back.
The criticism was that they had failed to test updates which proceeded to crash machines and break applications. That they managed to test this one feature is hardly a persuasive argument to the contrary.
So, today the Google news is "robots that automatically phone businesses and have conversations on your behalf", and the Microsoft news is "Notepad can now cope with Unix line endings". Symbolic or what?
Pretty sure that Google is advertising a service that you might pay for, whereas Microsoft is adding a new feature (in reality, many features) to an OS you already paid for.
Full disclosure, I work for Microsoft, this post doesn't reflect my employer in any official capacity, etc.
Take a look at their other keynote(s) yesterday. Much more impressive demos for developing consumer and Enterprise experiences. Today's keynote was about the windows and office platform specifically.
For pretty much as long as I can remember, it's been a fact of life that Windows had these little embarrassments, and Microsoft was too dysfunctional to address them. Everyone just sort of learned that Notepad didn't work and you weren't supposed to use it, then forgot it was there.
I think Notepad is used pretty extensively. A lot of people are joking about it and its quirks, but use it at the same time. Its like this little weird thing people become fond of.
The most common case for needing an external editor on Windows Server is default Notepad not supporting non-CRLF line endings. Unfortunately licensing would not allow transplanting the insider Notepad.exe to Windows Server, preventing the need for installing external software on the OS.
I thought wordpad was also part of a standard windows install? It does support the unix style line endings. Or am I misremembering and wordpad was an add-on?
Wordpad is part of Windows Server, but it is a rich text editor not a plain text editor. Therefore there are some file formats that it will interpret and corrupt on save.
I dual boot on my work and home computers (Windows 10, Linux). I use a lot of txt files as todo list, reminders, quick notes, etc. This are good news for me.
It's worth pointing out that CR-LF is the original ascii standard behavior, from electro-mechanical teletype. It took two characters worth of time to return the print carriage to the left of the paper. Rather than implement buffering (expensive at the time) the designers split the operation into two characters (Carriage Return and Line Feed).
You sort of answered your own question. People's workflows tend to morph around the idiosyncrasies of their tools. There'll be somebody doing something weird like using LF to keep lines separate for Linux but wanting them condensed to fit on one screen in Notepad. Notepad does preserve LF characters, just doesn't display them, so you can think of it as a no-wrapping display mode.
We developed an open source notepad clone (feature, keyboard shortcut, and look compatible) replacement basically to address this one gripe with an otherwise fast and barebones text editor. It’s nice to (mostly) no longer need this!
Nice, I actually had a customer ask about a configuration file (that one of our product produced) as not being readable anymore.
Turns out that an update did not properly write out "\r\n" but rather "\n". Looked fine in Notepad++ of course, but sure enough in MS Notepad ... things look garbled.
This change will eliminate most of my need for Notepad++.
It feels a bit wrong that it supports old MacOS CR though. Isn't that thoroughly obsolete, and encouraging its use only going to prolong its death, making it harder for everyone else to have to keep supporting it?
No because it already supported CRLF so that would be a step backwards for CRLF users. CR is a new feature so it would be no worse than before if they didn't add it.
Notepad seems like the perfect candidate for open-sourcing. It provides no competitive advantage to Windows. So might as well have the OSS community improve it. It's possible it might be too hard to remove it from the Windows code base and put it online.
Notepad is literally just the Windows EDIT control with some trivial code to transfer the data in it to/from files, and a menu to change some of the edit control's options.
I don't think it needs much improvement, really. Anything besides fixing bugs in its own code (i.e. this "extended line endings support" is in the edit control) would go against its core principle. There's Notepad++ and all the other "heavier" editors if you want more features.
Backward compability really matters. Windows has been always obsessed with compability. Guys in MS keeps max 255 characters long path just because of backward compability.
Right after Windows give up CRLF line endings, it will be immediate compability disaster.
(I slightly kid; that's the official Unicode "line separator". Never actually seen it in the wild, and not entirely sure how the Unicode consortium expected it to come into usage.)
I could have really used this feature when editing php back in the day.. Now, not so much. It's mildly amusing that such a trival feature took this long.
Is this Microsoft's crowning achievement? No, it's just a stupid little historic decision that someone remembered and decided to fix. They even took the time to enable admins and power users to use the old behavior. I too don't see who'd want it, but who knows? People do unexpected things sometimes.
Why bash them for that? There are enough good reasons to bash Microsoft... There are Microsoft products that fill me with a fiery rage of a thousand suns. But they did something cute here, someone there deserves a good word.