Introducing extended line endings support in Notepad
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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'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.
[0]: https://github.com/Azure/azure-storage-java/issues/30
[1]: https://github.com/Azure/azure-storage-java/wiki/Java,-Andro...
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.
This is the first time Microsoft has actually released it though. And that's an institutional thing.
So sure, this is good. It doesn't exactly undo all those decades of grief. So we're laughing grimly at the "progress".
From Microsoft's point of view, when they held >90% of the PC market, what would be the point of even thinking about interop?
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.
(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.
The sort of term I'd expect on n-gate.com like "bike shedding"
But now that you mention it - what is n-gate.com? (I visited the site - I didn't get it.)
Could you informally summarize what that site is / about?
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".
Confession: This is the one I care about.
Granted that's mostly because I already knew what to expect going into Google IO.
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.
Kudos to them, interoperability is always nice. Maybe they can acknowledge the existence of (and respect) other bootloaders, while they are at it.
Unfortunately, it seems their hearts are set on running everything inside windows, including GNU/Linux minus Linux (WSL).
Side note: I think we should just start referring to WSL as GNU/Windows.
Sharepoint?
Take a look at the first screenshot on the announcement page and then tell me it's working as intended.
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".
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.
And of course Mac OS wasn't Unix then, and used a different (third) line ending style.
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.
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.
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.
> Today, we’re excited to announce that we have fixed this issue!
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.
You've managed to encapsulate about 35 years of frustration with software in a single sentence.
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.
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.)
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.
I expect Windows to become more Linux friendly.
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.
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.
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.
You mean transactions? Windows registry supports them since Vista when they added Kernel Transaction Manager: https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
See CreateTransaction, RegCreateKeyTransacted, RegOpenKeyTransacted, CommitTransaction[Async], RollbackTransaction[Async] APIs.
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.
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.)
Could you point out which of these doesn't work as intended?
Powershell comes with a kind of FUSE mount for the registry:
PS C:\> Set-Location HKCU:
PS HKCU:\> Get-ChildItem -Recurse | where-object { $_.Name -match "HeidiSQL" } PS C:\> cd hkcu:
PS HKCU:\> ls -r | ? name -m 'HeidiSQL' cd HKCU:
ls -r -i *HeidiSQL*
ls -r | ? {$_.Name -match "HeidiSQL"}Here is the API.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
Could you point out which one of these doesn't work as intended?
That's ok.
Unless you are totally convinced that your chosen platform is the only one that matters, this behavior is a problem.
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.
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.)
(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.)
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.
There is a good blogpost [https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...] that details the insanity of a database that managed to be worse than MongoDB at the lowest level of jokes before MongoDB was even invented.
I can only assume that requiring an ops team to change a setting in a basic text editor is pretty standard in the Windows world, too?
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.
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.
SCNR
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.)
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...
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.
Full disclosure, I work for Microsoft, this post doesn't reflect my employer in any official capacity, etc.
Just a tad less dramatic that a robotic telephone assistant, but still :)
It has been 25+ years in the making.
Too bad about the telemetry and lack of privacy, or I might actually be tempted to use it. :-/
https://neosmart.net/blog/2017/hello-betterpad/
(Only other features iirc are hyperlinked URLs and unsaved document persistence after reboot/kill a la text edit on macOS.)
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.
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?
I am so sick of having to tell people not to use Notepad because it is badly broken and always has been.
You shouldn't have to tell people to download Notepad++ or use WordPad if they want to read a text file.
Edge, WSL, open source powershell, open source dotNet Core, VS Code and now a Notepad with line endings.
Windows is consistently getting better as a developer's Operating System.
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.
https://stackoverflow.com/questions/7812142/how-to-toggle-cr...
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.)