3 ms·

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 com

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. >:(

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. >:(