Notepad, the text editor that ships with Windows, is not a complicated application. For many, this is its major advantage—by having virtually no features, it cannot go wrong—but especially for software developers, it has often proven an annoyance.
That's because Notepad has traditionally only understood Windows line endings. Windows, Unix, and "classic" MacOS all use different conventions for indicating the end of a line of text. Windows does things correctly: it uses a pair of characters, the carriage return (CR) followed by the line feed (LF). Two characters are needed because they do different things: the CR moves the print head to the start of a line; the LF advances the paper by one line. Separating these is valuable, as it allows for effects such as underlining to be emulated: first print the text to be underlined, then issue a CR, and then print underscore characters.
Unix, however, uses a bare line feed to denote that a new line should be started. Classic MacOS (though not modern macOS) uses a bare carriage return for the same purpose. Given the meaning behind the CR and LF characters, these operating systems are both obviously wrong, but sometimes wrongness is allowed to prevail and persist.
Notepad, being a Windows application, has always demanded the CRLF pair. When faced with Unix files—quite common for source code and similar things—it sees the bare-naked LFs and prints them as black squares. Because it doesn't start a new line when faced with a naked LF, it shows the entire contents of the file as a single lengthy line, which makes it hard to read, much less edit.
But in the next update to Windows (likely to arrive in October or thereabouts), Notepad will handle Unix and classic MacOS line endings in addition to the Windows kind. This will make the editor much more useful than it currently is.
And if you don't like the idea, there's a registry setting to make it stick with its traditional behavior.
[contf] [contfnew] 
Ars Technica
[contfnewc] [contfnewc]
