Introducing extended line endings support in Notepad(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
Introducing extended line endings support in Notepad
https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/
198 comments
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".
So sure, this is good. It doesn't exactly undo all those decades of grief. So we're laughing grimly at the "progress".
It's a very parochial read of the 1990s that remembers Microsoft Windows as a place where 'obvious things' just 'didn't work'.
From Microsoft's point of view, when they held >90% of the PC market, what would be the point of even thinking about interop?
From Microsoft's point of view, when they held >90% of the PC market, what would be the point of even thinking about interop?
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.
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 had lots of hair pulling fun trying to write portable C and C++ code across commercial UNIXes back then (hello aCC). Microsoft wasn't alone.
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.)
(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.)
It just, uh, some wordsmithing.
"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.
"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.
I like "bugsmithing", it actually made me laugh out loud in the quiet office which drew weird looks.
The sort of term I'd expect on n-gate.com like "bike shedding"
The sort of term I'd expect on n-gate.com like "bike shedding"
(Bikeshedding is a very well-known, standard term though.)
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?
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?
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:
https://news.ycombinator.com/item?id=13759706
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".
https://news.ycombinator.com/item?id=13759706
ohhhhh. Got it. Thanks! This is really clever :D Thanks.
[deleted]
Thanks for the explanation!
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.
[0]: https://github.com/Azure/azure-storage-java/issues/30
[1]: https://github.com/Azure/azure-storage-java/wiki/Java,-Andro...
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...
> 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.
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.
This is the first time Microsoft has actually released it though. And that's an institutional thing.
I think it's hilarious this announcement is in the middle of 30 different huge GoogleIO AI and Machine Learning announcements.
Confession: This is the one I care about.
Confession: This is the one I care about.
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.
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.
> No, it's just a stupid little historic decision that someone remembered and decided to fix.
Kudos to them, interoperability is always nice. Maybe they can acknowledge the existence of (and respect) other bootloaders, while they are at it.
Kudos to them, interoperability is always nice. Maybe they can acknowledge the existence of (and respect) other bootloaders, while they are at it.
Now that would be wonderful.
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.
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.
> There are Microsoft products that fill me with a fiery rage of a thousand suns.
Sharepoint?
Sharepoint?
Personally I think this should have been done decades ago. Its simply too little too late.
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!
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 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=...
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.
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!
> 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.
> 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.
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
> 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”.
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.)
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.
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.
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 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?
> I wonder how that worked on the first Unix systems?
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:
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-newlineThe 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".
But (in §4.1.2.2) it "strongly recommended" that people "use CR and LF to obtain the effect of New Line".
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.
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.
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.
>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.
And of course Mac OS wasn't Unix then, and used a different (third) line ending style.
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.
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.
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.
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.
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.
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.
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.
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.
I remember a system that overprinted about 5 characters to black out a password after you entered it. Good times.
The NUL character was useful for inserting a delay into the serial stream.
The NUL character was useful for inserting a delay into the serial stream.
Hehe, security by obscure it y.
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.
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.
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.
* 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.
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.
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.
[deleted]
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.
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.
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.
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!"
And they even made the setting easily accessible, just hit [HKEY_CURRENT_USER\Software\Microsoft\Notepad] and change some registry key
I don't know if this is sarcasm or not but that's pretty standard in the Windows world. Your ops team wouldn't blink at tweaking reg values.
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 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.)
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.
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?
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?
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.
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.
That's because it's about the bigger picture.
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"
When a platform is purposefully incompatible with another platform, that effectively devalues the other platform for users.
Unless you are totally convinced that your chosen platform is the only one that matters, this behavior is a problem.
Unless you are totally convinced that your chosen platform is the only one that matters, this behavior is a problem.
> I'm unable to extract anything specific from your comments.
That's ok.
That's ok.
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.
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.
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.
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.
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 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)
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.)
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.)
> can you do "find HKEY_CURRENT_USER -name mypackage"
Powershell comes with a kind of FUSE mount for the registry:
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" }Or for those who come from Unixland and see way too much typing, PowerShell has aliases that make this much shorter:
cd HKCU:
ls -r -i *HeidiSQL*
ls -r | ? {$_.Name -match "HeidiSQL"}Just to make sure everyone on HN knows you can get real pithy with PowerShell, this also works:
PS C:\> cd hkcu:
PS HKCU:\> ls -r | ? name -m 'HeidiSQL'> with none of the benefits of a database (ACID)
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.
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.
> 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.
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.
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.
I stand corrected. Good to know, thank you!
To be fair, I’ve never used KTM in my apps.
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.
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.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
Could you point out which of these doesn't work as intended?
Could you point out which of these doesn't work as intended?
GNOME provides a registry called gconf, now dconf (binary format). Many applications outside of the GNOME project use this registry.
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.
Most Linux programs don't remove their files from /etc/, ~/.local, ~/.config on uninstall either.
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.)
(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.)
That's what the purge option to apt/dpkg is for.
>I don't know if this is sarcasm or not but that's pretty standard in the Windows world. Your ops team wouldn't blink at tweaking reg values.
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?
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?
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.
I was pretty surprised that editing the registry to change stuff like this is still a thing.
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.
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.
Nano has syntax highlighting, auto-indent, spellcheck, regex search/replace, and overwrite prevention. It's clearly in a class beyond Notepad.
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...
> Compare Notepad to something like Gedit or Kate
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.
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.)
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.)
notepad isn't even close to ed in functionality
There's a reason ed is the standard text editor. Everything is possible in ed.
> 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!!!!!!
SCNR
SCNR
For the uninitiated: https://www.gnu.org/fun/jokes/ed-msg.html
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 think the person you were responding to was being sarcastic.
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...
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...
Only if you ignore mainframes.
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.
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.
Using a Google OS?
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.
The day I can set the font in cmd.exe without editing the registry is the day I will miss your sarcasm.
[deleted]
People don't actually use notepad, do they? The last reason I'd think of to upgrade a Windows OS is "I'll be able to use notepad".
Sure we do, quick editing txt, cfg and ini files.
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?
FWIW, Microsoft also made an AI related announcement today about their new, OSS, cross platform machine leaning framework, ML.NET: https://blogs.msdn.microsoft.com/dotnet/2018/05/07/introduci...
Just a tad less dramatic that a robotic telephone assistant, but still :)
Just a tad less dramatic that a robotic telephone assistant, but still :)
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.
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.
Definitely part of a "normal" Windows install, but I don't know if it's part of Windows Server too.
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).
It's a welcome addition but all was not lost on a Windows install before. write.exe has managed to do this even if notepad.exe couldn't.
I cannot fathom a reason why someone would disable this feature.
It has been 25+ years in the making.
It has been 25+ years in the making.
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.
More practically, it could be as simple as checking whether text files actually have CRLF line endings. That's one thing I personally use Notepad for.
Hard to believe, but the neglected issues of DOS/Windows are being squashed one by one, almost thirty years later.
Too bad about the telemetry and lack of privacy, or I might actually be tempted to use it. :-/
Too bad about the telemetry and lack of privacy, or I might actually be tempted to use it. :-/
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!
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.)
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.)
Microsoft was clearly upset at the number of SysAdmins installing Notepad++ onto their freshly-imaged Windows PC's.
I imagine the reason this was done after all these years is to improve compatibility with Bash for Windows/WSL.
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.
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?
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?
You could say the same about using CRLF instead of just LF.
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.
Hallelujah!
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.
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.
MS is on track.
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.
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.
This will, surprisingly, make my life easier. Awesome.
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.
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.
Can't understand why Window still uses CRLF line endings. Just to be different?
Why not? If something works, why break it? HTTP uses CRLF as well. Should we redesign it?
> HTTP uses CRLF as well. Should we redesign it?
We did: https://en.wikipedia.org/wiki/HTTP/2
We did: https://en.wikipedia.org/wiki/HTTP/2
Because thats what people did on serial terminals, which preceeded CP/M which preceeded Windows.
https://stackoverflow.com/questions/7812142/how-to-toggle-cr...
https://stackoverflow.com/questions/7812142/how-to-toggle-cr...
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.
Right after Windows give up CRLF line endings, it will be immediate compability disaster.
No love for U+2028?
(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 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.
Will I be able to find an exe download and fix my old PC?
Now just let us change the tab width.
No! Just add elastic tabstops support!
http://nickgravgaard.com/elastic-tabstops/
http://nickgravgaard.com/elastic-tabstops/
I appreciate this gesture of heterogeneity.
This is huge.
Welcome to 1974, Microsoft.
[FIXED] « The default editor can't read text files »
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.