Windows Notepad fixed after 33 years: Now it finally handles Unix, Mac OS line endings Windows Notepad users, rejoice! Microsoft's text editing app, which has been shipping with Windows since version 1.0 in 1985, has finally been taught how to handle line endings in text files created on Linux, Unix, Mac OS, and macOS devices. "This has been a major annoyance for developers, IT Pros, administrators, and end …
Open the file in wordpad instead of notepad.
Last time I tried that (I admit, it was many years ago) I found that Wordpad had "intelligently" changed the text when I saved it.
It's a long time back, but I have a vague memory of it seeing something it thought was HTML (it wasn't) so it added extra tags to make it comply to Microsoft's standards. Something like that. It saw something in there that made it decide it needed to add its own secret mix of herbs and spices instead of just saving the fucking text AS I WROTE IT (apologies for going full bob-mode there).
Oh, the memories just came flooding back. It decided, for no damned reason at all, to add Microsoft half-baked DTP formatting to it. Something like that. These are repressed memories, after all. Notepad (back then) couldn't handle the "large" (over 32K) file, so I used Wordpad. I thought I could trust it because it wasn't Tord¹.
I never used it again. For anything. That wasn't much of a hardship because back then (as now, and all times in between) I rarely used Windows anyway.
¹ Rhymes with "Word" but describes that piece of crap much more accurately.
This post has been deleted by its author
And when the s**t hits the fan you need stuff you don't have to p**s about with installing that does what you expect when you expect it.
Interesting this this fix got the biggest cheer.
"Bout f**king time" it took so long to do it.
I'd say the fact it took 30 years to fix means they did have better things to worry about ;-)
I do agree though, if I have to reinstall Windows, Notepad++ is always one of the first slew of utilities to go on there.
"News of the change at Microsoft's Build developer conference on Tuesday prompted the loudest cheer of any of the announcements."
When the announcement of fixing a simple issue in a text editor gets the biggest cheer, you've clearly (as an organisation) got your priorities wrong.
Still, this sums up MS perfectly. Windows 10 is full of annoyances that could be fixed without too much trouble, yet MS prefers to focus on improved AI, 3D Paint and other gimmicks instead of fixing core things like the Control Panel/Settings mess etc.
OMG they might even fix the UI they screwed up completely with digit sized controls, but no, there's even more UI nonsense to come with 'Fluent Design'.
It wasn't broken, M$ borked it and now there's more white on platinum white on bright white coming. Makes my eyes hurt and gives me a headache trying to find buttons that HAD colour but now look like everything else.
Oh and don't get me started on Edge perpetually hijacking PDF file associations.
Yes, this is what I do. I only use notepad to actually take notes. If I'm opening text files in Windows, I always use wordpad because I work in a mixed-OS environment and you never know what sort of file it might be. I'd rather use notepad, though, so yay!
Others have mentioned Notepad++. Not only for CR versus LF versus CRLF but for ASCII versus UTF-8 or UTF-16.
I also use One Note - the useful version that comes with Office rather than the free version limited to the cloud. Makes tables trivially easy, for example.
"Yeah. The guy thinks using a sequence of two characters is superior to using one to tell us the line ends there. Clearly pre-stone age stuff! LOL!"
Well, if you're going to be anal about it, CR is Carriage Return and without a Linefeed, LF, will cause the next line to overprint the first. Likewise, LF, Linefeed alone means drop down to the next line at the same character position so you keep printing till you reach the physical end of line and then lose everything following. If anything is odd, it was whoever decided that only one of CR or LF should act as both CR and LF in the days when many people were still using Teletypes.
Character 10 could mean drop down to the next line at the same character position, as you say. It could also mean feed a line and return the carriage - either were permitted by the ISO standard for teletypes. IBM used character 15 to do the same two jobs. But that misses the main point: these are printer or teletype codes, and there is no particular reason why the OS should use the convention of one variety of printer internally. These days we would use device drivers to abstract that away, and even in early Unix, there were ways of removing that device dependence. Which is obvious, if you think about it, otherwise printers wouldn't have worked with Unix.
"And I suppose I'd have to install Win-10-nic to get the notepad fix, right? No back-ports to 7?"
Not sure what your network card has to do with it, but as Windows 7 is in extended support, yes no new features. However if you copy the executable it will probably work.
No because Geany on windows can't handle some exotic encodings unless you do a unix2dos first. Of course now you can just open it in Notepad and resave it as well (do actual work in Notepad not so much). Still prefer to drop into a cygwin command line to fix it than open through UI.
‘people too lazy to download better software‘
... or working for a company with 30k+ servers built over the last 15 years, strict restrictions on software downloads, where the only thing you can be sure will be there are the default Windows tools.
Some commenters really do seem to demonstrate a cluelessness as to real-world limitations sometimes!
"lol! does anyone still use that old thing?"
Well, I know you probably meant that tongue-in-cheek, but a lot of us are stuck with it at work and for gaming and whatnot. I personally have a love/hate relationship with it, as it does keep me employed.
That said, Microsoft can't seem to release an update these days without shooting itself in the foot. And using Win10, I can say that Microsoft seems to have lost its grip on what is important: the user experience. Look at all the mindless garbage included with each release, and the way you're forced to use whatever menu system MS wants you to use when it would have been trivial to include the functionality offered in 3rd-party apps like "Classic Shell" as options and you'll see what I mean.
I personally feel that MS's developers and management are so bound up in bureaucracy and appeasing upper management on the warpath, that no one communicates and things are rushed to market (even more than usual) before they've been fully vetted.
The sad thing is, MS's marketing is so efficient that they've got most companies to sign their contracts in blood, and companies are so deep in bed with them that there is no escape. Linux is a great alternative, but not many are willing to take a leap of faith like that and restructure their company's IT systems.
"700 million of those on Windows 10."
how many of them by CHOICE?
Consider that GWX had to shove Win-10-nic "up"grades UP OUR AS DOWN OUR THROATS to get people to "up"grade not so long ago, and if Windows 7 were STILL available, I bet you'd see a lot of machines being sold with THAT on them, instead.
Don't forget what REALLY killed the PC market: Windows "Ape" and Win-10-nic
I've never quite understood why Notepad has this problem with line endings.
To the best of my recollection, the standard multiline edit box in the WinAPI has always dealt with Unix-like line endings correctly, so whatever they did in Notepad can't have used that control.
I'm sure I remember knocking up a rough-and-ready text editor in Visual C++ back in the nineties, using the standard Edit control, in order to edit conf files without destroying their formatting.
>The standard multiline edit box in the WinAPI has always dealt with Unix-like line endings correctly, so <
Yes, and when you use the standard multiline edit box, the product is called "wordpad". That's what wordpad is: a wrapper around the standard multiline edit box. As you could see from the MFC example of how to use the multiline edit box.
And notepad? The backward-compatible utility for Win3.11 users.
The real news? MS has dropped notepad, and used the name for some new app.
Yes, and when you use the standard multi-line edit box, the product is called "wordpad". That's what wordpad is: a wrapper around the standard multi-line edit box.
No it isn't, Wordpad is a wrapper around the RichEdit control, which allows rtf formatting and so on. That's a very different beast to the basic multi-line edit box.
And notepad? The backward-compatible utility for Win3.11 users.
What nonsense, Notepad was present in the Windows 1.0 release, in fact it pre-existed Windows, as it started life as a DOS program with mouse support.
Handling three types of line endings requires one character of look-back. And with one character of look-back, you have to make sure you don't look at index -1 if the first character is a LF. That's complicated stuff for the poor new hire that has to work on the default text editor. Look at all those parenthesis! I don't even know if I got it right. Now, 33 years later, there's Stack Overflow.
Personally, I'd avoid indexing backwards at all costs and instead I'd be looking ahead. That's exactly how you start breaking stuff, not to mention messing up caches and whatnot.
Not at all difficult to look for CR alone and then ignore any single following LF when dealing with it.
I think it stems more from Notepad used to use a certain type of control that only ever handled plain text and (initially) had a limit of 32Kb, and lived entirely in memory. It then grew up and ended up in Windows 95, but was never really developed on properly. Load a large file in Notepad and you still have to have however-much free RAM to hold the entire file to even look at the first page of it, and wait while it parses it all (do it with a binary and see what happens!). Do the same in anything else and it might decide to parse the whole file (and will handle it like a text file, not just a bunch of ASCII characters) but it probably won't stick it all in RAM over reading from the relevant index as it goes.
I can't even remember the name of the control now, but back in VB 2/3 days you could make your own Notepad in about a minute... it was a textbox control and a couple of menus. Wordpad etc. was very different and required per-line / per-character formatting to be applied programmatically and wasn't subject to the 32Kb limit.
You can still technically open a 2Gb file with Notepad nowadays, but good luck waiting for it.
Yeah. This is the sort of article that makes me want to ask, like a passive-aggressive millennial, "You mean you don't use Unix-style line endings?"
I may be biased due to my environment, but I've never encountered a situation where one would want anything else.
(My editors save with Unix line endings, and my git environment is set to check in files with Unix line endings regardless of the file's original line endings. I've never used Notepad.)
Opening files is not the issue though. No editor I've used has ever been confused by DOS-style line endings.
I can conceive of a situation where one would have to share files with people who only use Notepad, but... honestly, I'd just set up a converter script rather than break mine and everyone else's environment. And I'd at least try to point out to the person in question that they might want to switch to a better editor.
One of the first things I do on Linux is install vim, nano and mcedit. Vi is dreadful.
To be honest, CR/LF makes more sense. The CR moves the cursor back to the beginning of the line and Line Feed moves the cursor down a line, without returning to the beginning of the line. So Windows "does it right", in theory. ;-)
As an aside, I can remember a story from a very early Practical Computing...
A UNIX guy was working on a teleprinter and booked 4 hours overtime every night, using the system log as proof...
He attached a piece of string between the printer's carriage and the on-off switch of the computer.
He then typed all the commands for the evening run in, one after the other, each terminated by Line Feed, which just rolled the carriage, pulling the next "line" of paper in front of the fixed print head.
The last command was a shutdown and that was followed, after a short pause, by a carriage return, which then shot the carriage back to the starting position, thus flipping the power switch on the computer.
I bet he really hated it, when they replaced his teletype terminal with a VDU terminal!
>Windows "does it right", in theory.
yeah right I was thinking about that just then when i was in the brew room making a cuppa... but then, I thought, even a mechanical typewriter (yes we had one of those at home I am of a certain age) has some sort of "automation" that combines carriage return and line feed into one operation for the user, only prehistoric line printers don't want that feature: they alternate between printing backwards and forwards to be a bit faster.
"but then, I thought, even a mechanical typewriter (yes we had one of those at home I am of a certain age) has some sort of "automation" that combines carriage return and line feed into one operation for the user,"
All the pure mechanical ones I used had separate line feed and carriage return mechanisms, but the line feed lever was always on the carriage so if (as you almost always did) operated the line feed lever by pulling it all the way over, you got a line feed and carriage return in one physical action by operating two distinct mechanisms. You would, of course, quite regularly use carriage return on it's own to do underlining or bold or after Tippexing out the inevitable mistakes.
It makes more sense if you are using a mechanical teletype, perhaps, but with any software using a cursor addressable terminal it is at best an anachronism and generally a pain in the posterior. Unix, which was used extensively on systems with mechanical teletypes found no need for it but windows, born on a PC, introduced it ... probably with the same malice as changing the / directory delimiter to \ and thus causing grief to this day.
@Sebastian
"even a mechanical typewriter (yes we had one of those at home I am of a certain age) has some sort of "automation" that combines carriage return and line feed into one operation for the user"
As @DavCrav says, the functions in a mechanical typewrite were separate, but in the one lever. You pushed the lever to line feed without moving the carriage, you pushed hard to return the carriage to the margin stop you set. So you could just LF, LF, LF and IIRC, there was a bypass key that let you CR without LFing, so you could overtype.
I used to have an old TeleType Type 33.
That is when I found out why it is CR-LF, and not LF-CR.
The Type 33 was completely electromechanical, with exactly one transistor (presumably for the receive side of the 20mA current loop interface).
Each character was printed as soon as it was decoded.
When the CR is interpreted, the carriage is released from its position towards the right of the platen, and a big clock spring hurls it towards the left. A piston on the carriage enters a cylinder at the left, and that cushions the impact against the end stop. Meanwhile, the LF has been decoded, and the paper is moved up one line.
From all-the-way-to-the-right to the home position takes more than one character time at 75baud, so the carriage was still moving as the paper was advanced - it had settled in the leftmost position by the time the first printable character on the next line had been decoded.
I successfully drove mine from my ZX81, and I sent LFCR. The first character on each line was actually blatted on the the paper an inch or so the the right of the home position!
DOS and Windows treat text files as though they are going to be printed by a teletype, which did use separate line feed and carriage return characters to move to the next line and then the beginning of the line respectively. This was because early teletypes were simple electro mechanical devices, and at the baud rate they operated it took the same time to line feed and carriage return as it did to print two characters.
Interestingly, although Unix came from a telecoms background, it didn't have this requirement for text files. I assume that when sending data to a mechanical teletype via a phone line a carriage return character would be transmitted before each line feed.
<blockquote>
Re: Vi
It makes more sense if you are using a mechanical teletype, perhaps, but with any software using a cursor addressable terminal it is at best an anachronism and generally a pain in the posterior. Unix, which was used extensively on systems with mechanical teletypes found no need for it but windows, born on a PC, introduced it ... probably with the same malice as changing the / directory delimiter to \ and thus causing grief to this day.
</blockquote>
Actually, the CR/LF convention was copied [like much of MS-DOS] from CP/M-80 version 2 conventions. Adapting a stock ASR-33 teletype for unix compatibility required a hardware change to fire off both actions on receipt of a \n 'newline character' [the \r was handled normally, allowing for overprinting to render text on paper as *bold*]
The replacement of the standard path separator '/' with the billslash '\' character was a result of many Microsoft tools [compilers, linker] reserving the slash as it options 'switch character'. MS & PC DOS 2.x had a 'switchchar' environment variable so you could try to set it to '-' instead of '/' - but only the CCP ['console command processor, the DOS prompt command processor] and some third party software [e.g. MicroFocus COBOL] honored the swithchar setting.
Hey Microsoft, thanks for having your programmer spend the last 33 years fixing Notepad.
Now he's got some time spare, maybe he could fix the decades-old bug in your File Explorer, that means it cannot handle Long File Paths THAT IT ITSELF CREATES ?!
If you want to be ridiculously cautious, it could use a flag to check if it should not crash.
Maybe,oooh, THE FLAG YOU ADDED LAST YEAR AND THEN IGNORED ?
Could be worse... they could completely screw the file system or have a drive encryption with a password hint...thats the actual password... dumb mistakes and infuriating design isn't the preserve of Windows exclusively.
That said I forgot notepad had this problem since I carry a usb exe with notepad++ set just how I like it.
Did they ever fix the issue where it automatically tried to expand Zip files as part of the directory structure? Just navigating to a folder with a zip file was enough to effectively kill the system, if the zip file was large; it hung the system requiring a reboot.
Even so I assume that it will continue to be the case that if one wishes to distribute, say, a set of notes for which .txt would be perfectly adequate the only way to be sure the recipient will be able to read them easily is to use the overhead of a PDF as older machines will probably never get the revised Notepad.
... I've had Windows people doing things in notepad after I've asked them not to, ignoring the newline statutes of whatever it is they're trying to edit and then looking upset when the final result is completely munged up and I've told them they'll have to do it again only this time with a different tool. I think 2unlimited were in the charts the first time I had that conversation.
Yeah, nice try Redmond - do you really think we're going to fall for this one?
It's not "just' for that, though. That's really the least of Notepad++'s many excellencies. Tabs, character counts, syntax highlighting, decent default font, ability to launch with multiple files already opened - these are things that even the most naive user will discover and appreciate very quickly. That's without even touching on the 'power user' features.
Except that Notepad++ has many 'features' turned on by default, like Tabs, character counts, syntax highlighting, minimalistic font and expecially launching with the files that you had open last time you had it open.
Well, actually, my biggest gripe is the syntax highlighting and opening with the files you used last time. When I open an editor, I expect to see either a blank file, or the file I passed as an argument or I opened it with.
I know I'm a Luddite in some respects, but I really dislike having coloured text supposedly highlighting something with the choice of colours that the developer thought was a good idea, especially when, like the default alias for 'ls' set up on many Linuxes, I run with a different background colour which makes the developers choice stupid.
I said 'by default'.
Of course you can change these things. What modern software doesn't allow you to change everything about it!
But I just like to do the work I'm paid for, rather than fiddling around configuring the tools I have to use (note, I use about 12 different locked down windows environments using Citrix, and I would have to change them all separately). And, as I'm a UNIX/Linux person (and have been UNIX since long before DOS, let alone Windows existed) without huge amounts of in-depth Windows experience (yes, I use Linux exclusively on my home systems), I do not find Windows and Windows software intuitive to configure.
And, yes again, all systems have to have a default set of settings. I just don't agree with a significant number of those made by modern developers (like hard-coding ANSI escape sequences into scripts and documents!)
"It's not "just' for that, though."
In the context of the comment I was replying to, it is "just" for that. Notepad++ does have other features, and if you want to have those, then install it! But if you are just trying to address the line ending issue, there is a solution that's already installed with Windows.
Downloading a special program just to properly handle line endings is a bit overkill when there's an alternative already installed.
You could say the same for many Linux users, they override vi with vim straight away or if they don't know better, they get a new machine and vim hasn't been pre-installed, they come running, saying that vi isn't working!
So, Windows is just another system in a world full of systems, it is no longer Master of the Universe. Consumers have caught up with reality at long, long last.
Long may the slow slide into oblivion continue, it was - and still is - the crappiest environment I ever had the "privilege" to use.
Yeah yeah, but when you just want to view the text of a file, it's nice that Notepad will now at least just display it.
Wordpad's biggest problem is line wrap, which makes test almost more unreadable than not understanding the line endings.
If I want to edit a file, then yes, Emacs, N++, TextPad, UltraEdit, whatever the the editor-du-jour happens to be at my employer.
"This has been a major annoyance for developers, IT Pros, administrators, and end users throughout the community"
Yes Microsoft.
It's Notepad. One of the shittest programs of the known universe, might have been hot on 8-bit "32 KiB free" computers.
I can understand the laughing disdain for "end users throughout the community", they are just deplorables to be herded into the milking shed.
But "Developers" and "IT Pros"? Please.
Its good news - that MS are actually acknowledging more common file formats, however I can't see anyone really using Notepad what with the superior better alternatives of Notepad++ and Atom.
It also says something more worrying - all the outstanding defects in Windows 10 are lower priority than this one - so adding the flag to turn off slurp is clearly not a priority.
"I can't see anyone really using Notepad what with the superior better alternatives of Notepad++ and Atom"
I can. The millions upon millions of Windows users who just use the PC as it came without realising that a text editor is something for which there are alternatives other than a full-blown word processor.
Almost, Sun threatened to sue which saw the creation of C# and the CLR (the .NET equivalent of the JVM). J++ became J# and provided a compatibility layer between the Java API and CLR.
It got discontinued not long after, probably for the same reason.
https://en.wikipedia.org/wiki/J_Sharp
Notepad was changed years ago to allow using and saving Unicode, this caused it to leave artifacts in the documents that interrupted some internet web browsers so if you wrote you web pages using notepad as I did and viewed the page in the older notepad or other editor you discovered invisible remnants courtesy of non-visible font characters. It has stayed this way up until now.
Will be interesting what crap they introduce this time and if they fix the existing problem.
How about a few standards, maybe, even possibly ?. Oh they don;t follow them anyway !
>How about a few standards, maybe, even possibly ?.<
Not like say, unix, where they unsuccessfully tried to change the ASCII standard for line endings, then went ahead and ignored it anyway.
Look, I understand: they were in a commercially competitive situation, where their technology was different from that of their competition. They tried to capture the standards process, and when that failed they just ignored it. It's not an usual story.
Sorry, what?
UNIX's newline convention came from Multics', Windows' came from DOS' which came from CP/M which came from DEC.
No standard describes which newline convention is right, however the good thing about one byte (including old-style Mac's CR) is that it's easier to program with and the printer driver decides what characters to send for new line, whereas DEC was wedded to one particular teletype.
By definition:
Newline - move the carriage up a line
Carriage Return - return the carriage / print head to the start of a line.
So, with just NL, you would move down the page and never return the print head / carriage / cursor to the left hand side of the screen, until you go wrap-around.
With just CR, you would return the print head to the beginning of the line and overwrite what was previously there.
CR/LF makes sense to me. But, there again, I grew up on teletypes and VDUs that did just that. In fact most of them had an additional Line Feed key, as well as the Carriage Return key.
As to why they did it, perhaps with the introduction of the WSL last year, they are finding users who use WLS and Notepad together and were having problems? A sudden influx of Linux files on a Windows system.
But... You could simply cat the file to the screen or teletype (there were no printer drivers for them) and the file would be correctly represented.
If it just has LF, you need to "interpret" the end of the line and add a CR as well (a lot of serial terminals needed both). Also, what if the output actually "needs" a LF as a LF and not as a CR?
For a script or source code, not a problem, but for "formatted" output, using an LF could be simpler than CR/LF + Tab + Tab + Tab (or God forbid dozens of spaces) to get the cursor back to the correct position.
And see my anecdote on the first page to see why LF without a virtual CR can be useful!
Not all teletypes were just CR + LF though, some were CR + LF + a few NULs depending on the amount of time it took for that model's print head to move.
So you might as well just have the screen accept one byte and the printer driver accept one byte which it expands to the right codes.
"
Using a printer driver format for internal file representation makes no sense at all.
A byte wasted for every line was significant wastage back in the day.
"
"Back in the day" the printer driver was effectively a physical interface, not a software program. The data would simply be fed directly to the printer one byte at a time. You could specify what physical port to send the data to, but the "driver" was not designed to reformat that data in any way. You may well want the printer to do only a CR or only a LF and would not want your computer adding or deleting characters or control codes.
"
Even "back in the day", I'm sure there were some filtering to perform pagination, etc. An escape character in the source file can tell the filter not to process (expand to CR/LF for example) that character.
"
No, not even that. You had to tell the printer what size paper it had by loading a "vertical format" tape (or file). You used the formfeed character (0x0C) to tell the printer to do a page break.
"
No standard describes which newline convention is right, however the good thing about one byte (including old-style Mac's CR) is that it's easier to program with and the printer driver decides what characters to send for new line, whereas DEC was wedded to one particular teletype.
"
You assume that CR always denotes a new line. I once used line printers and telex machines a great deal, and it was often necessary to do a CR without a LF in order to overtype the same line. Many printers could not do a backspace, so using CR was the only way to achieve an overprint. And overprinting was the only way to create certain character and effects. e.g. to underline, or to double-print the line so that it appeared in bold. Or to add accents or strike-through etc. You always added a non-printable character after a CR because most printers took longer than 1 character period to perform the carriage return. Usually the letter-shift character was used, or a double CR was sent.
"You assume that CR always denotes a new line. I once used line printers and telex machines a great deal"
You are muddying the waters by getting mixed up the printer control needed to get a certain result with the storage format for a document. I bet you don't want to edit a document by inserting printer instruction to go back, then space forward, then print some underline, then go back and linefeed..
"
You are muddying the waters by getting mixed up the printer control needed to get a certain result with the storage format for a document.
"
Makes sense in this age of Unicode characters and different software drivers for every printer, some of which are far more complex than an editor.
But this came from a time when editors were simple affairs, and printer drivers essentially just copied the file to a printer port. Heck, the "file" could well be a length of punched paper tape that would be physically fed into the printer.
Much later came formatted documents and printer drivers that could do clever things such as automatically overprinting words marked to be underlined with "_" characters or translating "£" into "L" backspace "-" and similar kludges.
"But this came from a time when editors were simple affairs, and printer drivers essentially just copied the file to a printer port. Heck, the "file" could well be a length of punched paper tape that would be physically fed into the printer."
I'm sure you have a point. However, I have used line printers with perforated blue-white paper, and formatting applied to your text documents by filtering software. I know for sure I didn't put in page numbering, headers, footers, etc, but it all came out with that. Both on Unix systems, and CMS/VM.
The printer itself and the OS didn't do page numbering or anything like that. The printer "driver" was simply an RS-232 port and the "driver" part was the configuration of the baud rate and flow control.
Some wordprocessing packages managed page numbering and programs that generated reports kept track of how many lines had been output and how large long a page was and they put a form feed in at the right time and printed the header for the next page, including page number.
And somewhere along the line, you would always miscalculate something and end up going one line over the length of the page and form-feeding a page with just one line on it. And then going back, going through the code one line at a time, trying to find out where you miscalculated - ususally because on one of the sub-sections you forgot you added an extra heading or blank line to separate it. Then recompile and try again...
And if you were feeling particularly clever, you would embed a couple of escape codes, if your printer supported them, to make it print bold or to re-type a line to make it bold or to underline it. There were no "drivers" for doing such things, the printer printed exactly what your program sent to it.
Even with MS-DOS that was the case, each application, like WordPerfect, Lotus 1-2-3 etc. came with their own printer drivers, which allowed them to compile a program and use parameter files to adjust its output to the type of printer connected.
It was only when Windows and X came along that this started to change and your program could start chucking out standardized codes for bold, italic, line feed etc. and the system interpreted what to do with it. But you still needed to work the pagination for yourself, which is where tools like Crystal Reports started to crop up, you gave them a template and then just bunged the data at them and they took care of the formatting for you.
I must admit, while I am an avid user of Linux, I have never understood why the end-of-line delimiter is solely Line Feed in that operating system. To my mind, reaching back to the use of teletypes, the Carriage Return character caused the print head to return to the start of the line, and Line Feed caused the paper to advance by one line. The reason they were separate was so you could execute a Carriage Return and overprint the already printed line - e.g. if you wanted to strike-out certain characters with a horizontal bar. (This is also why Backspace and Delete are subtly different - Backspace sends the printer head backwards by one character (if possible) and it is then subsequently followed by Delete which overtypes the character you have just backspaced over, rendering it unreadable)
Obviously, you can choose to interpret the Line Feed character in whichever way you want, and load it up with the meaning of terminating a line rather than just advancing the (virtual) paper output, but it does rather muck up the printing of files to dumb printers. You can, of course, run a filter to add Carriage Return characters at each Line Feed, but you also have to deal with the complexity of entirely legitimate files that contain lines that have a Line Feed part way along the line, where adding a Carriage Return is the wrong thing to do.
Possibly, a case could have been made for using ASCII character 30 (Record Separator) as a line separator in text files, but obviously that never happened.
I must admit, while I am an avid user of Linux, I have never understood why the end-of-line delimiter is solely Line Feed in that operating system.
Saves space. And you will anyway always have a required conversion in terminal or printer input or output of the file, no matter which choice you make: If your line separator is LF, you have to convert it to CR LF when printing, but if you choose CR LF, you must convert CR when someone types into CR LF before storing. Of course the LF regime must also convert here, but from CR to LF.
Also note that when processing the file in a prorgram, dealing with a single character separator is much easier. It is telling that the C library and many other language runtime systems simulate single LF line endings also on Windows.
On balance, I think using a single LF is the superior convention.
I can see the argument for a single character delimiter, but I still would have thought that the ASCII Record separator (RS) character (hex 1E) might have been a more appropriate choice. (See Stack Overflow: What are the file-group-record-unit separators and their usage? ). Obviously it wasn't used, but it might have solved a lot of heartache if it had been.
"Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual."
So, I have to give up my privacy and submit to potentially system-bricking forced updates to take advantage of a feature that should have been included decades ago? With dozens of free Notepad replacements available, it's nice to see MS devoting resources to useful updates.
I am using Notepad++. And before that: Notetab Pro and UltraEdit.
Note to Microsoft: fix calc.exe, restore the vintage classic Calculator. Keep it simple, don't try to be too clever.
Now Windows 10 users have to install this to get rid of your 'innovative' monstrosity:
https://winaero.com/blog/get-calculator-from-windows-8-and-windows-7-in-windows-10/
"Now that I hardly use Windows at all, you mean that I won't have to open/edit text files with the Norton/Midnight Commander editors?"
Usually one of the first things I do to my new computers is install Midnight Commander on it. Currently the computing devices sitting on my desk are - Linux desktop, Mac desktop, Windows desktop, Android phone, dumb phone, PlayStation 3, and an embedded device I sometimes get paid to work on. The only one of those without Midnight Commander on it is the dumb phone, coz you can't install software on it.
I would say that a much more annoying issue with Notepad is that it insists on marking a UTF-8 file with a BOM ("byte-order marker"). Many text-processing tools choke on this BOM. In contrast, most Unix tools handle CRLF transparently.
Wish that Microsoft had done what Apple does and just included Vim in the base system.
Notepad does not insist on adding BOM (=byte order mark or zero width, none-breaking space) . If you save as ANSI, it won't add BOM. It adds BOM just for Unicode files where it is critical for portability and for the ability to know, when the file is opened again, what encoding the file used.
In this aspect, Notepad as actually doing a great job - much better than other editors.
Or better yet, they could finally EOL serial-attached-mouse support. Or at least provide an off-switch that actually works.
We keep losing USB-UART dongles. Once they've been recognized as a mouse, they will never work as an UART dongle again. Have to get a new one, that this particular Windows installation has not YET deemed to be a mouse. Again and again. A real BOHICA.
I believe that requires setting an environment variable to show hidden (disconnected) devices in the device manager, then uninstalling them so it forgets the serial number.
I install Emacs ASAP on any Windows system I have to edit anything on.
That Wordpad, or whatever it's called, doesn't it open things with a variable width font per default?
Anyway, it's pretty typical of MS to fix nothing, no matter how trivial, unless there's money in it.
Still don't know why Explorer hangs doing feck all for ages (looking for God knows what on the network) every now and then. Not something MS will fix within the next few decades, it seems. It's been like that for a couple of decades, at least.
I haven't done any Microsoft programming in many years, but when I did do assembly programming in the days of DOS, I could not find a Microsoft editor that reliably would edit and save a file. The saved file would have a significant percentage of the lines ending with <CR><CR><LF> instead of <CR><LF>. The assembler (also Microsoft) would see the first <CR> as the end of line, as it should, then ignore the next <CR>, then when it saw the <LF>, it would treat the next line as a comment and not compile. This is just one of the many data points why I follow the philosophy that any Microsoft solution is not a solution, but the problem.
This isn't just a Windows thing, it goes back through DOS, but the alternatives are older.
Back in the day, it might have been problematic to handle the different styles, code size was an issue and RAM could be very limited. Once we got Win95 it was time to fix this. Win98 looks to be the big missed chance.
33 years... It should have been fixed 30 years ago
Going back to my Windows programming days, I guess that the fix should be also in any application using standard Windows edit box control. Because Notepad is nothing else but an application wrapper for this control, hence the fix would be in text rendering of the control itself. Which also explains why it took Microsoft so long to fix it - they have large problem with making changes in the behaviour of existing APIs, controls etc. (which also explains why they come up with new ones so often).
ES_PROPERNEWLINES:
The edit box will understand LF as a newline in text. This flag must be specifically set and the software must be recompiled to take advantage of this feature. Note: If this flag is given on versions of Windows previous to Windows 10 build whatever-it-is, your flag will be ignored and your edit box will still look like crap.
In short, you've probably already solved this problem in a more compatible way.
Thank you for flying MSDN.
If you'd read my comment three pages back, you would see that the standard Windows edit box does indeed handle Unix-like line endings correctly, but Notepad is NOT a wrapper for that control, and was developed prior to the standard WinAPI controls.
Which makes it even more unbelievable that Microsoft haven't re-written Notepad to be a wrapper for the standard edit control before now.
I lament the lost TTY,
how we yearn for your 3 row keyboards
and the glory of 8 level baudot tape.
Glorious hours of hitting CAR RET, CAR RET
followed by a lovely LINE FEED.
Long lost is FIGS & LTRS keys and
voluminous piles of chaff.
Ask not for whom the BELL dings
for it dings for thee Teletype Model 28 ASR.
I seem to remember that everything : LF to LF, CR and vice versa was done in the tty driver. You could also set delays in there as well to allow for the head moving back to the start of line as well.
Look at termios.
The LF was simply a convention to keep the number of bytes low.
For people talking of CR/LF sequence on a TTY, just take note that even that sequence may need transformation for actual device working properly. In fact, physical carriage return takes time, and it happen this is not managed internally by device, forcing driver to create a delay with a limited count of NUL characters.
And as soon as a driver has to inspect and slightly transform characters stream, there is no longer need for EOL character to be tied to TTY.
Won't this result in many Unix/Mac text files end up being mangled with a mix of line ending types, at least with the old notepad you were less likely to pollute a Unix file by editing it with notepad.
now it will display correctly but all the new lines you add will have windows cr/lf at the end.
Over 4 pages of replies, must be a major fix for MS then :-/. Never used much here, but PFE in the old days, then NP++, which has a the essential rectangular cut and paste. On PDP & VAX, EDT for 5 or 6 years. On several unix variants, still using NEDIT, does every thing this programmer needs from an editor and can be built from source in minutes...
"Opening a file written on macOS, Mac OS, Linux, or Unix-flavored computers in Windows Notepad therefore looked like a long wall of text with no separation between paragraphs and lines."
Which was quite a useful warning to naive users that there was something different about that file they downloaded that is mysteriously breaking their other application. Now it will be 'There's nothing wrong with the text file, it looks fine in Notepad!'. Experienced users who know about things like line endings will, of course, have ditched Notepad a long time ago.
>> Microsoft acknowledged in a blog post today, without touching on why the issue was allowed to fester for more than three decades.
We must recall that 'bash', the most popular Linux shell, still does not support the Windows line ending of CR+LF (carriage return followed by line feed (new line) even today.
So it seems Windows got to its senses faster...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
