What I personally do not enjoy as a developer about MS products is that eventually they hit end of life and you are left hanging. With open source stuff, if the project is used enough there will always be some maintainer.
It seems to me like it’s the other way around. Microsoft keeps comparability forever, which also has tons of negative consequences. With Linux it seems almost like you have to recompile everything anew for each system and each updates, where tiny differences in distributions can break things.
A statically compiled application will run for just about forever on linux. glibc has extensive backwards compatibility too. If you pack your application with its libraries, there's very little to worry about.
Kernel modules need constant recompilation but that's a very separate issue from programs.
Backwards compatibility across releases of the same product, sure. But some products hit their end of life and that's it.
If a product is deprecated, it may not receive security updates or fixes and such. As a user that puts you in a tough situation.
Unfortunately as a user there's not a lot you can do to influence the governance of those products or try to do something to keep them around. If the vendor decides to sunset a product that's it. That's all I am trying to say.
Depends on your choice of distribution. Some distribution will distribute compiled binaries for each architecture. And there are flatpaks that are distribution agnostic.
For your own applications you will most likely use a container anyways and that gives you fairly reproducible builds.
Besides the fact that you're simply not right (COM, MFC, ATL, SWF, WPF, etc are all deprecated yet still supported and maintained), how is this on topic?
As extra info, COM became central after Longhorn's failure.
Many of the .NET APIs became COM based ones on Vista, with plain C Win32 ones being less and less common until we got WinRT, as the sibling comment points out.
Interesting enough WinRT shares many ideas with the genesis of .NET, before they decided to go the CLR route.
The flavor-of-the-day is UAP/UWP, which actually has awesome APIs. The only problem is that it's Windows 10+ and can't make universal or standalone binaries.
UWP also is like Silverlight more so in that it is missing a lot of stuff from the original WPF, you have to basically relearn it. However, Win2D is pretty good, nice performance.
Two different meanings of the word. I meant a single binary that can run on multiple versions of Windows. They mean universal as in one codebase that will deploy to PC, phone, and Xbox.
The main problem with Microsoft in the past is that they didn't make money except by selling more software licenses. Things have begun to change with the cloud stuff, but the mentality is still there in the dev tools and frameworks - instead of "if it ain't broke, don't fix it" it winds up being "every time we move the cheese we make more money".
Microsoft's incentives still don't quite align with their developer/customers, but Microsoft does an amazing job pushing toward whatever is tossed out for sale as the new & shiny each year. The entire company is an amazing marketing machine.
Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? [...] The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
a) not true for reasons already given here b) they are(have) open sourcing a lot of developer stuff; I didn't check but would not surprise me if this ends up on github too if it didn't already with a good OSS license
