Yes. They also rewrite stuff half way through and tell you it's the same project just to piss you off. Windows Workflow and Windows Communication Foundation for example.

I'm really disinclined to invest in any of their technology because my headspace is finite and I want to deliver business value, not change the unworn carpets once a year.

It's also just such a bad idea because they never get to mature their features, add uniqueness or allow 3rd party devs to build the ecosystem. They just build the same thing over and over again while their competitors keep refining, innovating and adding features. Really a bound to fail strategy

Exactly that.

The feedback loop is shit as well. Out falls a broken pile of shit for a CTP. No one accepts any feedback. It hits RTM, no one accepts any feedback. Two years down the line, the same bugs are open.

You should hear the partner reps wanting to cry when you report a bug in something that you NEED a fix for and are paying support for. You get fuck all other than a registry fix or a hack even if the mainline product is falling to bits across a thousand or so users (which is what happened to us).

Money where the mouth is as well. Typical shit:

https://github.com/Microsoft/SCVMMLinuxGuestAgent/issues/2 -> ignored. Regularly hoses our new VMs deploying windows on SCVMM.

https://github.com/dotnet/cli/issues/3093 -> fuck you go away we're just going to take your data unless you set a magic variable even though no one wants to give it away as indicated by the ticket and there are bugs in the configuration and it causes people massive audit problems.

From the second ticket

> It's only a matter of time before some enterprising journalist looking for a scoop picks up on this. The headlines here are not good: "Microsoft caught with sneaky program to spy on companies"

Let me take care of that...

Edit: Wrote several of germanys biggest tech sites with focus on dataprotection aswell as the german ministry for cyber security with a link to that ticket. Let's see what happens

Excellent, hopefully something positive comes from it. :)

On a similar note if they get back to you, Mozilla is testing the waters with dumb privacy invasion stuff in Germany soon too:

https://www.ghacks.net/2017/10/06/mozilla-to-launch-firefox-...

They're probably across that already though, but if not it might be useful to point out to them. :)

You do undrrstand thus is a one year old issue in a pre-release of .net core 1 (current version is 2.0)?

The issue is well documented and explained: https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

I applaud your vigilance, but you are a bit late.

Good work - thank you :)

Maybe MS and the FLOSS world aren’t as different as we thought. Look up CADT by Zawinski for details.

Difference is I’m not paying them. We pay Microsoft a metric fuck load of money.

Same here. I can't even imagine how 3rd party tool developers feel. Let's say you have a grid component. In the last few years you had to do a Winforms and several XAML versions( WPF, WinRT, Silverlight and now UWP). The XAML look superficially the same but all have their set of weird limitations and bugs. I am definitely done with Windows desktop.

Wow, imagine someone trying to make this statement 15 years ago...things have sure changed.

Indeed. 15 years ago I kind of enjoyed it. Win32/winforms is still less horrible than the web these days.

Win32 is in no way less horrible than the Web. Win32 doesn't have any device-independent layout, at all. Forget about handling HiDPI sensibly. RegisterClassEx/CreateWindowEx are incredibly verbose. WndProcs are a mess compared to individual event handlers. The mishmash of COM and inconsistently named C APIs is terrible. COM involves a monstrous amount of boilerplate. COM requires you to deal with apartment threading, legacy that exists primarily for compatibility with Visual Basic 6, which is of course no longer supported but still saddles the platform. Creating an OpenGL context with WGL, with the "false context" stuff, is a nightmare compared to WebGL. Memory management is a giant pain to deal with. The GDI APIs are archaic and slow. I could go on…

Yet I would rather take all of that than dealing with Frankenstein CSS/HTML/JavaScript programming, while making sure it is pixel perfect across all browsers and not making use of the OS features and computer hardware that made me buy it in first place, e.g. WebGL 2.0 on DX 12 GPU.

Most of the issues you mention are solved in .NET, WPF and UWP. COM is a breeze to use in Delphi, MFC/ATL, .NET, C++/CX.

Windows is much more than just Win32.

Apparently Windows event system is so bad, that the younger generation re-inventing it in the form of React.

Also Cocoa, UI Kit, Android and Qt are all better solutions than Web.

Despite the populist mindset that programming the web is a shitshow, it’s really not. Tooling these days is pretty incredible and the ecosystem is pretty great when you are found needing - issues get fixed, PR’s get accepted. It’s a much better experience than a 20 year old environment where everything is set in stone, yet bugs and inconsistencies still exist.

The tools and software for traditional windows app programming have long been neglected and the newer ones throw you into a niche — and still don’t provide a cohesive story.

I would much rather pick up react and produce a working product in less time it takes to troubleshoot XAML databindng and styles, for instance. If my windows app needed something like a map component, I can drop one in my macOS, iOS app - the same one baked into the os - and on the web have an assortment of components to choose from — with WebGL support baked in.

Also, there isn’t such thing as a DX only gfx card - it happily runs OpenGL games and apps just fine

> Tooling these days is pretty incredible and the ecosystem is pretty great when you are found needing - issues get fixed, PR’s get accepted. It’s a much better experience than a 20 year old environment where everything is set in stone, yet bugs and inconsistencies still exist.

Try to make a CRUD SPA as fast as a Delphi one, including a nice L&F by default, just with mouse clicks and setting a few properties.

> Also, there isn’t such thing as a DX only gfx card - it happily runs OpenGL games and apps just fine

This statement means you don't have much experience in graphics programming, at least regarding the fun of dealing with drivers and how OEMs classify GPU features.

So if you prefer I will rephrase it as "WebGL 2.0 on OpenGL 4.6 GPU".

Now feel free to compare what it means in GPU features.

Hint, WebGL 2.0 is basically OpenGL ES 3.0, which maps to OpenGL 4.3.

https://www.khronos.org/developers/reference-cards/

> Try to make a CRUD SPA as fast as a Delphi one, including a nice L&F by default, just with mouse clicks and setting a few properties.

Use Bootstrap for the look and feel. The browser's painting stack is far faster than Delphi's '90s style GDI, so you don't have to do anything there.

You love to use the GDI example against native devs, a Win16 technology, long superceded by better alternatives on Windows.

I only used Delphi as an example, because in 2017 the Web is yet to produce anything that approaches it, even Web Components are yet to be fully done.

A RAD tool is much more than just rendering widgets, a simple CRUD application should be doable just by clicking and setting properties, including talking to the database backend.

Speaking of WebComponents, when will Mozilla support HTML Imports?

> Yet I would rather take all of that than dealing with Frankenstein CSS/HTML/JavaScript programming

I wouldn't.

> Most of the issues you mention are solved in .NET, WPF and UWP.

I wasn't talking about .NET, WPF, and UWP. I was responding to the claim that Petzold-style Win32 apps are better than the Web.

> Apparently Windows event system is so bad, that the younger generation re-inventing it in the form of React.

Huh? React is not WndProc.

> Also Cocoa, UI Kit, Android and Qt are all better solutions than Web.

Disagree.

I've written the same WebGL app twice now, once in Cocoa/Objective-C and once on the Web, with a TypeScript and Webpack stack. Once I got over the initial hump of learning the technology, it was a much nicer experience than my experience with Cocoa. TypeScript is a better language for UI development than C++, Java, or Obj-C, and the fact that the browser implementation of WebGL smooths over the issues with OpenGL on Mac was a huge relief.

Petzold-style Win32 apps were already out of fashion on Windows 95.

Apparently others with better knowledge of Web than me, think otherwise about React vs WndProc.

https://bitquabit.com/post/the-more-things-change/

As for your WebGL example, I would have used Swift with SceneKit instead, regarding productivity in native development on Apple systems.

You're assumptions are outdated

Please provide a link to a Delphi like tool for the Web, including components for backend comunication.

Allow me to present: https://anvil.works/

Visual interface editor? Check.

Component-based UI model? Check. (It's all in Python, everything is an object, very Delphi-ish.)

Back-end communication? Check. (One-line RPC to call functions on the server.)

Database integration? Check.

(The built-in datastore runs on Postgres, and lets you do things like delegate views on a table directly to the client. Mix this with data bindings, and you can create CRUD apps with tiny amounts of code. Or you can start importing the appropriate Python libraries and go to town with your favourite DB.)

Thanks for proving me wrong, Anvil actually does look quite good.

That sounds exactly like the state of affairs the moment you pick a JavaScript framework, which was my point.

Yeah... because compatibility here is MUST.

What I find missing, compared to back-in-the-day, is the _maturity_ of that ecosystem.

Win32 has warts on warts, but around the year 2000 the MS development space was a monoculture and the COM-to-GUI story was increasingly mature and integrated.

.Net came along and, on the one hand, positioned MS to be a whole different kind of tool provider (F# on dotnet core on linux in kuberernetes is niiiiice), but they also lost a few hundred man-years worth of local improvements to their platform. This without providing a credible replacement for Win32 ensuring it would be around for decades.

That fracture fractured again with XAML, again losing tons of maturity, and then fractured even further with the UWP/Silverlight/Metro/WhoKnows. I've never been a bigger fan of MS's product line, but can't justify or defend using much on the client other than html for fancy things or standard winforms for deployability.

Most of the legacy stuff continues working long after it's the hot new thing, though.

Until you hit a bug. The one that killed us was we had to deploy a registry fix to 2000 workstations at hundreds of companies because they broke ClickOnce in IE9 and later. It still isn't fixed today. We still have to eat the administrative cost. Over time, that's a shit ton of cash leaked out on a mistake the vendor has made.

Clickonce is such garbage. I'm sorry I ever heard of it.

I can't believe an company so vested in the enterprise market can do such a terrible job of allowing companies to deploy enterprise software. Click once isn't supported in VS anymore, and was always horrible when it came to things like CI servers anyway. Windows 10 store requires running on azure which make it a no go, doesn't allow push updates anyway. The best options have always been third party ones like chocolatey or NSIS, but they are limited as well, chocolatey does not allow push based and NSIS is pretty weird.

19 years after the first release of apt-get and I'm still waiting for MS to give me something half as good.

Click-Once is like... the smartest idea that ever got built by people who have never worked in places that need something like Click-Once.

I am of the opinion that if they had dropped the "use apps over the web" angle and focused on small-medium-enterprise continuous deployment they woulda had a true game changer on their hands... Click-Once dovetails naturally into something like Apples launchpad, its "turn it off and turn it on again" workflow was ideal for 'Sue in Accounting', its simplified publishing model is great for ISVs with lots of customers, and its sandboxy requirements are a natural fit for the way dotnet core is coming together.

And, yeah, that the Windows ecosystem is still worseoff than apt-get forever ago is a) shocking, b) further proof that Richard Stallman was right about everything ;)

the next Windows update adds ClickOnce-like functionality to its app installer: https://blogs.msdn.microsoft.com/appinstaller/2017/09/27/aut...

perhaps doesn't solve your problems yet :)

Wix isn’t terrible. We use that for deploying two products. When I say not terrible it hides a lot of the design by committee ugliness of MSI packages.

Have you looked at chocolatey as a total replacement for apt-get? If you havent, be prepared for eye gouging disappointment! :(

That too!

But it never matures. You are stuck with half-assed stuff in many cases.

...sometimes to the extent where the hospitals in your country get crippled by malware :-/

Basically "Fire and Motion" in a situation where that strategy is NOT to their advantage.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Wow that was a great read.

As stupid as [my reply] may sound, thanks. Your comment prompted me to read that, and you were right, it was a great read.

I do get where you're coming from but I have a more moderate perspective.

I mean we can certainly point to examples where that's the case: Silverlight's a classic here, if that term's even appropriate, and then of course there's WP7, 8, and 10, as mentioned by the grandparent. And these are clearly not trivial examples.

Nevertheless, I must point out that large bodies of code I wrote in the mid-noughties are still running substantially unmodified today. What's perhaps interesting is that these codebases are desktop tools, where it can be argued that Microsoft have achieved true mastery (after WPF came out everything notably settled down, and unlike MFC and WinForms it really hasn't been replaced).

It tends to be other areas where the worst of the churn has occurred: web, mobile, database access (how many versions of EF to get it right?). Of course, these are areas that have seen significant growth over the past few years.

Still, even in their worst period Microsoft did not begin to approach the lunacy of framework churn in the JavaScript world.

My pet theory is that this is because the dev tools department at Microsoft is not a pure cost centre with the sole task of improving the platform, they have Visual Studio licenses to sell. If there is any truth in that, we should see a slow decline in "API of the year" as non-subscription licenses (where customers are prone to skip an update when it does not have enough "revolutionary must-haves") are slowly phased out.

    My pet theory is that this is because the dev 
    tools department at Microsoft is not a pure cost 
    centre with the sole task of improving the platform, 
    they have Visual Studio licenses to sell.

This is the single most baffling thing about Windows to me, and it always has been. Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?

It doesn't even seem like they're acting in rational self-interest by doing that.

I suppose their rationale is that they give a lot of development tools away for free, and you only really have to pay for the really enterprise-y editions. I guess? Still dumb to me.

MS DOS used to come with a Basic interpreter, if that's what you mean ;)

Later, when the PC platform became what we know today, there wasn't really a channel for free (small f) software except shareware magazines and Microsoft surely would not be seen with that crowd! In those days, Microsoft wasn't concerned with losing the heads and minds to another platform but with losing the revenue to Borland. Since then, more and more has been made available (I still fondly remember laying my hands on the first Windows SDK day came with a free command line version of the MSVC compiler), but it is a culture shift that won't be rushed as long as there are no really pressing reasons.

> Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?

For a while now they haven't been doing that. Community editions are just as good as paid ones and before that Express versions were still comparable if not better than open source IDEs.

Licensing their dev toools gives discounts on tools for development which pushes orgs to buy for-realsies licenses.

Partnering with them gives rebates on their dev tools licenses and gives you kickback when you push your customers to buy for-realsies licenses.

VS is just the fishermans hook, the haul are the 600 SQL server CPU licenses you have ticking all day, every day.

> The thing about the MS platforms that has always been an issue is that they change the developer APIs around all the time.

There was a time when MS would detecting the binary name, and change core kernel functionality just to provide bug-compatibility to older versions of Windows. By that time they got an unbeatable market dominance...

That’s because you don’t get promoted there unless you do something new and super complicated. That’s also part of the reason why Android SDK is such a pile of garbage, the other part being they rush half baked shit to market all the time.

In Microsoft's defense, they also tend to support their stuff for a long time. I work with MFC every day. It's 20+ years old and still being developed.

I stumbled over a few bugs in WPF (worked in WPF3.5, would hang in WPF4), which were, for at least 4 years, documented and "WONTFIX" with no acceptable workaround (workaround provided slows things down by a factor of 10 under some circumstances).

Maybe it's fixed with the reinvigorated WPF on Win10. I don't care anymore, but I do caution anyone to ever use any MS Technology younger than 15 years.

I'd say .Net Core is worth considering, but no real UI story as of yet... pretty nice for services though.

OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?

Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996.

In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.

Kind of, OWL and VCL were much better technology but Borland's management...

Oh man, I remember those now. You're right - they were better. It reinforces my point about how difficult it is to choose a long-term technology. It feels a little like picking stocks.

Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.

As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name.

If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.

At the mean time we are celebrating 10 years with the same UI engine: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...

The only major thing: added Direct2D H/W accelerated backend to support high-DPI and multi-DPI systems. Yet incremental addition of CSS features.

You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.

That's why I mentioned semver. APIs change all the time, backwards compatibility gets broken. Yes, conversions weren't always straight forward, but often were possible, and there was an evolutionary arc to it all, and a migration story to follow, even when sometimes that story was a bit rougher than anyone wanted.

They couldn't have done that because these technologies are not exactly for the same things and don't have the same features.

Silverlight was mainly for apps embedded in the browser. It was very limited compared to WPF and not meant to replace it.

Similarly, Metro was not meant to replace WPF. It was extremely limited in what you can do. You couldn't build serious desktop apps with that.

The fact that all those technologies use XAML does not mean they're newer versions of the same thing. The difference in APIs is not what matters, it's the difference in what they can actually do and how that makes them different.

The family tree seems pretty clear to me, yes, Silverlight was a sideways jag, but it wasn't originally "just" for embedding in the browser, it was a cross-platform WPF subset. (In the family tree both WPF and Silverlight, sometimes codenamed WPF/E for Everywhere, split from different goals of the original Avalon project.)

I think you can tell that WinRT/Metro/UWP was/is meant to replace WPF. It used to be extremely limited, but A) had a bigger cross-platform reach that WPF (ARM is/was a big deal), so started with the cross-platform subset, B) was essentially "Win64" from scratch so had a lot of pieces to build.

Starting next month-ish UWP supports .NET Standard 2.0 and the hard work of the re-convergence of classic desktop .NET and cross-platform .NET APIs has happened (huzzah), and it will be a lot harder to argue that UWP is "extremely limited" compared to WPF because 70% of NuGet will just work.

You still don't have a clear path forward from WPF. I don't understand why they even needed UWP. Why not improve WPF?

I think .NET Standard 2.0 is about the clearest path you could get forward from WPF.

> I don't understand why they even needed UWP. Why not improve WPF?

The short story: 1) To first-class support more platforms/architectures (ARM). 2) To support C/C++ and other COM developers, bringing everyone COM [WinRT] [1] and Managed (.NET) to the same table. (Microsoft still has a lot of teams invested in C/C++; it shouldn't be a surprise that they couldn't just focus on .NET and leave C/C++ devs behind.)

The full story I think is pretty fascinating, but that's the executive summary.

[1] Crazy aside: the tech still sort of known as WinRT is closer to the original goal of .NET as a COM replacement than .NET became. It's also close enough to COM that I'm still surprised no one's admitted to building a UWP Delphi or VB6 app. (Not that I'd admit to doing so if I built such a beast.)

That's a very charitable explanation that I find hard to accept. I think it's more that MS .Net development is organized in way that it's easy to do new stuff but hard to maintain an effort long time. In other areas they are able to make progress without breaking everything all the time. C# has stayed backwards compatible while still moving forward quickly. SQL server doesn't release a new version every 2 years that breaks old stuff.

Somehow they seem to lack leadership.

Keep in mind that .NET Core is almost the same .NET runtime/framework (little-f) that powers UWP. It's been a huge hurdle across the board, web and desktop alike. I'm sure if the .NET team had had a magic wand to shrink the .NET Framework (cap-f) down to a smaller size and remove all the legacy Win32 code without breaking so much compatibility they would have.

It's easy to say in hindsight that they should have tried for something like what .NET Standard 2.0 is today earlier, but I, at least, can't blame them for attempting to try to clean house and remove terrible dev experiences like AppDomains and DataTable. Those APIs are terrible and should have died.

But again they have no upgrade path. They just produce something new and expect everyone to jump on board. My expectation is that UWP will last 2-3 years and then they will have something else that does the same but in a different way and UWP is in maintenance mode.

You may be confused. .NET Standard 2.0 support for UWP means the upgrade path is (finally) here today. Start a UWP project in VS 2017.4, make sure the project targets the Fall Creator's Update (the Windows 10 feature update to be released at the end of this month), and from that UWP app you can now add a reference to almost anything on NuGet you want. .NET Standard 2.0 support means that if it ran on the .NET Framework 4.x, it likely runs on UWP now (with rarer but obvious exceptions like using old WPF or WinForms libraries, some of which will still "work" as no-ops not actually doing anything).

Again, I'm not sure how much clearer of an upgrade path you could want? If you have a WPF app today, everything but the XAML will work in Fall Creators Update UWP. The XAML may even be trivial to convert to UWP XAML, they are related like family.

Wait so are you saying UWP apps can now access the machine they're running on in a sane manner (so, limited only by the privileges of the user who ran the app, without additional limitations enforced by the platform itself)?

Because that was the main limitation of Metro apps, you couldn't really do anything useful with them, you couldn't even access the hard drive normally or edit the windows registry. This is why you couldn't "upgrade". It wasn't an upgrade to any previous tech, it was a downgrade as the platform literally had less capabilities. It is, or at least was, basically a platform for making sandboxed mobile apps that you can run on the desktop...

This is why they clearly weren't (at least Metro, I haven't worked with UWP) an "upgrade" to anything. Silverlight wasn't an "upgrade" to WPF for the exact same reason. It was a more limited platform and you couldn't switch WPF apps over. So MS calling Silverlight or Metro a new version of WPF would have been retarded.

Things are still sandboxed, but the sandbox has grown a lot since early Windows 8 ("Metro" era). Depending on your definition of "sane", it seems rather "sane" to me to have at least some sandbox protection of the applications to run. Yes, Windows 8 felt like a straight-jacket more than a sandbox to some, but current UWP, especially with .NET Standard 2.0 support in the FCU, at least builds with most of the libraries even if some of them are essentially no-ops or (security) exceptions at runtime.

So, you still can't touch the registry by default, but why would you want to? There are much better places to store stuff.

The UWP is meant to be a replacement for Win32, so it shouldn't be a shock that a lot of Win32 components aren't available by default.

However, you can use the Desktop Bridge and request permission in your app manifest for more privileges, including things like registry access. The Desktop Bridge has a lot of examples out there on things you can do. You can use the Desktop Bridge to transition a WPF app slowly to UWP over time. For instance, you could launch UWP screens from your WPF app, allowing you to move piece-at-a-time if you wanted. There are even samples on how to migrate settings currently stored in the registry (ugh, why) over to Local AppData storage like a proper application, to transition away from Win32 bad practices. (Of course, the parts of the application that need the Desktop Bridge will only work on Windows with a Win32 subsystem.)

There was no migration story. Usually an API gets more features but in this case they took away a lot of critical stuff. A lot of us write applications that need the full power of the OS and not just a small arbitrarily chosen subset.

These frameworks are by no way equivalent. Silverlight was running on multiple versions of Windows and Mac OS. It should have being kept just for that awesome feature.

On the other hand Win8/10 apps don’t run on anything than the OS they were released on. Which is totally laughable because it means choosing the MS stack allow one to target less Windows OSes than third party tools. So these SDK were doomed from the beginning as thay couldn’t leverage the existing Windows userbase.

> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?

If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff?

You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.

They support the stuff they can't kill for a long time.

You can still run VB6 apps but try running a .net framework 1.0 app!

Easy, just get the runtime from here.

https://www.microsoft.com/de-de/download/details.aspx?id=162...

I'm not sure it requires a rewrite, the old stuff still works. The trouble is the constant churn is draining, I've pretty much abandoned the platform because of it. We keep hearing about new JavaScript frameworks but we had exactly the same from MS: win32 => MFC => WTL => VB => WFC => Winforms => WPF => Metro => UWP, no doubt there is something else just around the corner.

Calling that "constant churn" is a massive exaggeration. First, using WTL or WFC were just bad decisions because those were side-projects and MS never told companies to switch to that and definitely didn't encourage rewrites into that. They were not replacements of anything by any stretch of imagination. That's like complaining that MS made you rewrite your app in Lightswitch or IronPython. It is just a side-project, not something ever intended to become the main MS dev stack.

So realistically for most MS stack devs it was MFC -> VB -> WinForms -> WPF -> Metro -> UWP. And MFC was released 25 years ago. So they switched 5 times in 25 years. You could possibly add Silverlight in there (which is extremely similar to WPF so only half-counts for churn purposes).

Now, I agree that the Metro -> UWP part was unnecessary because they were doing the same thing twice so they should have gotten it right the first time (and I think the whole UWP concept is worthless anyway).

If we look at MFC -> VB -> WinForms -> WPF, all those technologies provided a lot of value to us and it was very useful to have them. Would you want to still be programming in MFC today? I am pretty sure you wouldn't. I do not feel any "churn" from this (note: I never switched to Metro/UWP because I considered it a step backwards, unlike the previous "switches", so I stopped at WPF when it comes to desktop), I can barely remember programming in VB 6.0 because it was such a long time ago.

Saying that's "exactly the same" as the situation with web is ridiculous.

Your 5 times in 25 years suggests an overhaul every 5 years. Context matters. WPF became mainstream in 2007

WPF, Metra, UWP, and Silverlight in 2007 -> 2017 is 4 overhauls in 10 years or an overhaul every 2.5 years.

Also not fixing bugs in earlier tech creates a compulsion to switch to the next tech.

metro/winrt -> uwp wasn't really an overhaul, it was just a new name for the next version of the same thing more or less.

Microsoft used to only make money selling software licenses. This has changed with Azure cloud stuff, but the majority of their incentives still don't align with their developer/customers.

With Azure they can bill you for the licenses and the computing platform, while also ensuring a pretty impressive degree of lock-in once the platform is sold.

Not only are their incentives still out of alignment, the massive consultant eco-system they maintain is still incentivized to push the same-old lock in in a new costume.

SOAs are like partners in bed... it's not just about who you're sleeping with, you gotta think about who they have slept with too.

Picking Apple as an example, other are possible.

Object Pascal, Powerplant, Quickdraw, Java Bridge, Quicktime, QuicktimeVR, Carbon, OpenGL, ...

Apparently only Microsoft does it.

This is exactly what made me quit desktop development on Windows. MFC, ATL, COM+ learning going to waste was a bridge too far.