It's the same problem that you have, isn't it? You don't want to support two codebases, you just want to build your app once and have it run in two places. It costs time and development budget to maintain two different codebases, and you have to prioritize. Can you really blame Microsoft that they don't want to maintain both a modern codebase and a completely separate fork/back-port of it for a much older branch?

That said, it has been possible to share a lot of code (if not almost all of it) between a WPF and UWP app for a while now with PCLs, or after that targeting .NET Standard. That gets even easier once UWP support for .NET Standard 2.0 ships soonish. There's also been work recently on Xamarin.WPF for Xamarin's cross-platform code sharing, and the XAML Standard 1.0 work trying to converge much of the XAML across all the platforms Xamarin supports and UWP to get rid of a some of the dialectal nuances.

Maybe because Windows 7 lacks the sandbox features required?

That's a good argument for not having the app store on Win7, but APIs are a separate matter. If UWP API could be used to write something that is both a store app on Win10, but can also be deployed (let's say, in a manner similar to Electron apps, with the runtime packaged with the app) on Win7, I think we'd see a lot more of them. Even if you had to build it separately, so long as most of UI code could be shared, it's a boon.

As it is, it's easier to just target WPF.

All new APIs introduced since Windows 8 are mostly UWP ones, so basically you are asking for implementing Windows 10 on top Windows 7 kernel.

Yes.

And I know it's not an easy thing. But if e.g. the resources that went into Windows Mobile were spent there instead, I think the ecosystem would have been much further ahead, and we'd actually see more useful UWP apps.

It's a green field versus brown field problem. Windows Mobile was/is a green field where the only competition was exterior. Whereas UWP has to compete with Win32 on the desktop and tablet.

It's easy to armchair quarterback hindsight and wonder if they spent too much money in the green field, but it should be reasonable to see why the green field looked so appealing at the time.

It's also easy from 2017 to forget the real, hard, brown field battles that Microsoft did fight, particularly as Windows 8 and Windows 8.1 slowly become "forgotten" versions of Windows like Vista before them. Almost all of the missteps in Windows 8 that people yelled at Microsoft for direct consequences of building the UWP out and trying to make it competitive to Win32. Some of the features like the Charms were attempts to give the UWP some platform-wide features that would have really differentiated it from Win32, but found they added confusion because they weren't easily portable back to Win32, and that is just one example out of many. Brown field work is hard.

I don't get the impression that the green field work Microsoft tried in mobile ate resources that would have been better spent on the brown field work on the desktop. Win32 has such momentum at this point that had Microsoft thrown more resources at Windows 8, trying to bring UWP further ahead faster they might have only gotten more backlash from Win32 fans, and arguably there wasn't a much better plan for desktop than the uneasy truce between the two platforms/subsystems that Windows 10 is/has become.

If they had built a "UWP subsystem for Windows 7" at the time of Windows 8, people would have asked for it for the last remaining months of Windows XP. Asking for a "UWP subsystem for Windows 7" today is a bit like asking for that Windows XP subsystem. Windows 7 is feature complete; it may have security support for a bit longer, but it's out of support for new Windows features (it ended mainstream support in 2015; it ends extended support in 2020). It's now two released versions behind (8, 10) and more versions behind if you count "service packs" (8, 8.1, 10 (1506), 10 1511, 10 1607 (AU), 10 1703 (CU), and the new one (FCU) coming later this month/early next month).

Honest introspection: if you are a developer and someone asked for a feature to be backported to a version from 7 years ago that is 6 major versions back, would you support that or would you encourage them to pay for your hard work and upgrade to something more recent that already has that feature?

It's not just that the work is hard, it's ignoring years of hard work that you've already done.

It occurs to me that a lot of it is really the sunken cost fallacy.

(by the way, do check my HN profile...)

That's pretty much the summary of what I was trying to convey. It's fascinating how developers get stuck in it on one side ("we have to stick to this old version of Windows because IT has put so much work into getting it right"), but then get angry/fail to appreciate the other side ("why won't this cool new library support this old version of Windows I'm stuck in").

(The Python 2 versus Python 3 "war" is obviously very related. Sunk costs on developer/ecosystem side versus sunk costs on library/platform/language side. It's a fascinating dance that likely will always plague development.)

For what it is worth, to explore the other side, there probably were ways out of the development trap for Microsoft had they tried, and there probably are "Mexican stand-off" issues to blame and "throwing good money after bad". Silverlight (WPF/E) was meant to be a way around that standoff. I still think it was a mistake that the fork of Silverlight with desktop application support that Mesh had used to support XP and Vista was never productized. Silverlight was always meant to be a cross-platform bridge technology to WPF (and Avalon), and the .NET Core and UWP Stacks grew out of Silverlight in many respects.

The browser focus of Silverlight deployments may have been a mistake, and while Mobile realized it was exactly the transition tool they needed (using it for Windows Phone 7 and 8 while the proto-UWP was in development for 8.1 and 10), it probably was a mistake in hindsight that there wasn't a stronger "Silverlight for Desktop" option, even if it would have muddied the waters between WPF and eventually UWP. Because, yes Silverlight for Desktop could reach back to the developers stuck with sunk cost in XP or Die corporate environments (again, poor Mesh, RIP, being the poster child of that possibility), made code sharing between Mobile (Windows Phone 7) and Desktop possible/easy in the Windows 7+ transition period to Windows 8, etc.

Given Mobile seemed to recognize the importance of that transition, I'm inclined to believe that less money thrown at mobile wouldn't have helped in this particular case. Based on conversations I had at the time, my gut feeling is that some old guard C/C++ PMs had a lot more to do with the curmudgeonliness of Desktop through the transition era than the money thrown at Mobile. There certainly seemed to be a lot of distrust of any UI platform that wasn't directly developable from C/C++ and that sort of "COM or Die" Mexican standoff I feel (as mostly an outsider trying to make sense of crazy patterns, and some really bad, tangentially related interview feedback) had more to do with the rough transition to Windows 8 and UWP than Mobile did. Mobile at least tried to smooth that transition. (Arguably Mobile was in a better place to try to smooth that transition given the relative popularity of Compact Framework apps in WM 6.5, versus raw C/C++ development, but that's also a different argument.)

Anyway, armchair quarterbacking this is definitely fun, especially with hindsight and not having to actually fight any of the battles that were fought. I can very much appreciate why we are where we are at today, and yes can see some places where things could have been improved, but I also realize why they were such hard fought battles (the sunk cost fallacy is a big one that impacts most sides of all of these debates).