4 ms·

I've completely given up on Notepad compatibility. I can only assume that the reason Notepad in 2016 can't handle '\n' is due to pure spite by someone high up i

by byuu 11y ago

I've completely given up on Notepad compatibility. I can only assume that the reason Notepad in 2016 can't handle '\n' is due to pure spite by someone high up inside Microsoft, Hanlon's Razor be damned. The sad part is it's not even just Notepad. It's the underlying "EDIT" HWND class itself. So anyone coding in raw Win32 APIs has to basically capture paste events from the clipboard to transform text into the "\r\n" state, and upon reading text out of it, potentially convert it back to "\n". Probably a five-line patch to that class would eliminate so much extra work for developers. And we could drop the whole ridiculous "text mode" for working with files while we were at it. Plus I'm sure there must have been thousands upon thousands of external requests to Microsoft to be able to use Notepad with all their non-Notepad text/configuration files over the years. It's hard to believe this is anything but very deliberate at this point. Add to this, the mess Microsoft perpetuates with not supporting UTF-8 (std::wstring, wchar_t, _wfopen, non-standard iostream extensions for Unicode filenames, etc), and one really begins to have a deep seething hatred for Microsoft.

dkopi 11y ago
"The sad part is it's not even just Notepad. It's the underlying "TEXT" HWND class itself. " That's it. Notepad is only a wrapper over a text edit. Nothing more.
unlinker 11y ago
That's like asking why does Windows use \ instead of /. It's not hatred, it's just... the way things work. Changing it would be very costly and would create compatibility problems for decades presumably, so why do it?
- lomnakkus 11y ago
  The parent poster stated the advantages, but just in case: The CRLF vs. LF is essentially technical debt that millions of developers pay -- as long as Windows remains an interesting target for developers (or Microsoft fixes the CRLF thing). It's basically a continual downside vs., say, 10-20 years of compatibility problems. (I don't buy the "decades" bit, but I'll accept it just for argument's sake.)
- byuu 11y ago
  \ vs / is an interesting example. fopen() and family from MinGW can use / in paths on Windows. I use that feature all the time. cmd.exe can't, and I understand that would break things due to the use of / instead of - for flags in the Windows world. Whenever it comes to something programming-related that might improve code portability between different OSes (C99, LF, UTF-8, etc), there's a mountain of after-the-fact justifications for why it would break backward compatibility and other such tripe. But honestly, what would making "EDIT" accept "\n" alone do to break backward-compatibility? "\r\n" would still work, of course. Is there a group of people inserting stray "\n"s alone into text files, and expecting Notepad to silently ignore them and dump all of that text onto the same line? If so, those people are absolutely horrible :P But okay, fine. Require a program .Manifest flag to opt-in, then another special ES_ACCEPT_LF flag with a caveat that it's Windows 10+. Even all the people that have jumped through hoops with things like hooking paste operations to transform "\n" into "\r\n" for "EDIT" ... that would still work just fine, it would just be unnecessary. The only cost would be that there's a short time where people are trying to use these "\n" only text files on older versions of Windows. But we've been dealing with the fallout of that anyway for the past 21+ years now. You can't possibly tell me that supporting "\n" alone is an immense burden for a company with as much money and developers as Microsoft. No, I'm sorry, but this, C99, UTF-8, things like _wfopen, WSAPoll over poll, etc are all very much intentional: they're designed to maximize vendor lock in. Microsoft doesn't want your code easily moving between Windows and Linux. Even though they're a convicted monopoly with a mountain of evidence of their abusive actions, they still have so many white knights ready to defend their actions as benign =(
  - simoncion 11y ago
    IIRC, '/' as a path component separator works just fine in every Windows API call that matters that takes a path and (unless I'm remembering wrong) has for a really long time. It works just fine in Windows 10's version of Windows Explorer. I would be surprised if it didn't work in W7's Explorer, too. CMD.EXE is -sadly- a bucket of suck. > ...WSAPoll over poll... Don't fucking get me started about the WinSock API. >:(

by byuu 11y ago

dkopi 11y ago

"The sad part is it's not even just Notepad. It's the underlying "TEXT" HWND class itself. " That's it. Notepad is only a wrapper over a text edit. Nothing more.

unlinker 11y ago

That's like asking why does Windows use \ instead of /. It's not hatred, it's just... the way things work. Changing it would be very costly and would create compatibility problems for decades presumably, so why do it?

lomnakkus 11y ago
The parent poster stated the advantages, but just in case: The CRLF vs. LF is essentially technical debt that millions of developers pay -- as long as Windows remains an interesting target for developers (or Microsoft fixes the CRLF thing). It's basically a continual downside vs., say, 10-20 years of compatibility problems. (I don't buy the "decades" bit, but I'll accept it just for argument's sake.)
byuu 11y ago
\ vs / is an interesting example. fopen() and family from MinGW can use / in paths on Windows. I use that feature all the time. cmd.exe can't, and I understand that would break things due to the use of / instead of - for flags in the Windows world. Whenever it comes to something programming-related that might improve code portability between different OSes (C99, LF, UTF-8, etc), there's a mountain of after-the-fact justifications for why it would break backward compatibility and other such tripe. But honestly, what would making "EDIT" accept "\n" alone do to break backward-compatibility? "\r\n" would still work, of course. Is there a group of people inserting stray "\n"s alone into text files, and expecting Notepad to silently ignore them and dump all of that text onto the same line? If so, those people are absolutely horrible :P But okay, fine. Require a program .Manifest flag to opt-in, then another special ES_ACCEPT_LF flag with a caveat that it's Windows 10+. Even all the people that have jumped through hoops with things like hooking paste operations to transform "\n" into "\r\n" for "EDIT" ... that would still work just fine, it would just be unnecessary. The only cost would be that there's a short time where people are trying to use these "\n" only text files on older versions of Windows. But we've been dealing with the fallout of that anyway for the past 21+ years now. You can't possibly tell me that supporting "\n" alone is an immense burden for a company with as much money and developers as Microsoft. No, I'm sorry, but this, C99, UTF-8, things like _wfopen, WSAPoll over poll, etc are all very much intentional: they're designed to maximize vendor lock in. Microsoft doesn't want your code easily moving between Windows and Linux. Even though they're a convicted monopoly with a mountain of evidence of their abusive actions, they still have so many white knights ready to defend their actions as benign =(
- simoncion 11y ago
  IIRC, '/' as a path component separator works just fine in every Windows API call that matters that takes a path and (unless I'm remembering wrong) has for a really long time. It works just fine in Windows 10's version of Windows Explorer. I would be surprised if it didn't work in W7's Explorer, too. CMD.EXE is -sadly- a bucket of suck. > ...WSAPoll over poll... Don't fucking get me started about the WinSock API. >:(