7 ms·
Joel Spolsky famously praised this policy of backward-compatibility at all costs which he called "The Raymond Chen Camp"[1]. Many agreed with him, but I always
by unscaled 9y ago
Joel Spolsky famously praised this policy of backward-compatibility at all costs which he called "The Raymond Chen Camp"[1]. Many agreed with him, but I always thought that Microsoft compatibility ideals were too radical to be real wisdom. At some point the list of features you try to keep compatibility with grows large enough that the Raymond Chen Way becomes unmaintainable.
The received wisdom of the 90s is wrong. Most users don't care about compatibility, as Apple's success has clearly shown, and most companies are now out following the Apple road.
Large enterprise care about compatibility, and they pay a lot, but this is not a forward-looking market. They'll keep using buying new versions of your software because of the compatibility, but if compatibility is the only story you have to offer, you'll slowly lose that market.
I completely agree with you that Microsoft should have had a strategy for deprecating these features back in the 90s, when they were already old.
In this specific case of outdated filename restrictions, you could start with what they already did:
Windows NT 3.5 - Allow accessing all filenames with a special prefix (which they already did).
Windows NT 4.0 - Make it easy to migrate to sane filenames by providing an opt-in per-process flag that makes all APIs use them by default.
At this point they can easily dogfood and migrate all Microsoft software to the new APIs, so you would be able to delete these pesky files in explorer.
Windows 2000 - Make the new API flag default for all versions compiled with the latest version of the Windows SDK.
Windows XP - Make the new API default for any app without a special entry in the compatibility database.
Somewhere along the road, batch files (which is the only place where compatibility with the old filenames was necessary) could be easily made compatible by modifying the batch parser to replace redirections to NUL with redirections to \\?\devices\null or something akin. You may see some breakage in scripts which use NUL and CON in non-standard way (e.g. as an argument), but the migration pain won't be huge, and you could still save an old script with a compatibility flag.
Microsoft obviously didn't take that way, and yeah, all the batch files written back in 1981 may still work without hitch, but newer things keep breaking in strange ways.
[1] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
- tjalfi 9y agoMicrosort has taken a similar approach for adding long filename support to Windows 10[0]. [0] https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-...
- to3m 9y agoNewer things only break in strange ways because they're broken. So rather than break the old stuff, why not fix the new stuff?? - because after all, approximately the only criticism you can't level at the Windows NUL/PRN/COMx/etc. special names is that they're some kind of surprise that appeared suddenly out of nowhere! It's been this way for a very long time. (I wonder if part of this is the rage of Unix fans discovering that portable means actually, you know, making an effort... and that there's more too it than just checking it builds on x86 Debian as well as x64 Ubuntu...)
- loa_in_ 9y agoYou can't just say it's been that way for a long time so it's acceptable, because the industry (and for that matter the Internet) is getting fresh new people every day. You can't expect them not to be surprised, and you can't just arbitrarily require them to know something they haven't stumbled upon until after it caused problems.
- paulddraper 9y ago"portable means actually, you know, making an effort" When I hear portable, I immediately think of the Portable Operating System Interface.
- wnevets 9y ago> Most users don't care about compatibility, as Apple's success has clearly shown, by having 3% of the desktop market and 10% of the smartphone market?
- adrianN 9y agoApple market cap: ~700B, Microsoft market cap ~500B.
- iamaelephant 9y agoIt's almost like they are both successful but for different reasons.
- mamon 9y agoMarket cap is a meaningless metric. It tells more about state of mind of general public (greed vs. fear) than about company's well-being
- hawski 9y agoMarket cap is a lottery ticket. I would assign more meaning to cash hoard: Microsoft: ~$100 billion. Apple: ~$250 billion.
- wnevets 9y agoHow does having a higher market equal cap users don't care about compatibility?
- bluejekyll 9y agoApple has 18% of the smartphone market: http://www.idc.com/promo/smartphone-market-share/vendor http://www.idc.com/promo/smartphone-market-share/vendor And 7% of the PC market: https://www.google.com/amp/s/amp.businessinsider.com/apple-mac-lost-most-pc-market-share-in-2016-chart-2017-1 https://www.google.com/amp/s/amp.businessinsider.com/apple-m... And greater than 10% in the US.
- wnevets 9y ago
- mastazi 9y ago> Most users don't care about compatibility, as Apple's success has clearly shown Apple is not exactly big in the same markets where MS is big, e.g. enterprise. So while I agree that "most" users don't care, the very few who do care might be important customers for MS. EDIT: grammar
- deleted 9y ago[deleted]
- brianwawok 9y agoI can't think of a single enterprise where devs don't use MacBook pros. Sure they exist but I haven't run into it.
- mathw 9y agoThey exist in large quantities - try every .NET shop for starters.
- elechi 9y agoThe government, federal, state, and local.
- sobani 9y agoI can't think of a single enterprise where devs don't use a Dell supplied by the IT department. The only MacBooks I've seen at the various meetups I've been to were at 'hip' dev shops.
- baq 9y agotake this post to /r/sysadmin and watch them bring out the pitchforks.