5 ms·
The other problem is that after they finally showed a direction (xaml/UWP) no backwards compatibility was offered, you had to choose between the now deprecated
by flukus 9y ago
The other problem is that after they finally showed a direction (xaml/UWP) no backwards compatibility was offered, you had to choose between the now deprecated libraries and have an app that worked on windows 7+, or you could choose the new ones and have it only work on windows 10.
Had UWP run on windows 7 we might have seen some more take-up.
- pjmlp 9y agoUWP cannot run on Windows 7 because it requires a container model, which I doubt they could just patch on Windows 7.
- icebraining 9y agoThey probably couldn't just port the patches, but there's no reason why they couldn't write a runtime environment on W7, even if it didn't provide the same security guarantees.
- deleted 9y ago[deleted]
- WorldMaker 9y agoXAML/WPF is close enough to XAML/UWP that you could keep a codebase for both relatively clean and easy to support. (As someone that had to do a bunch of work to maintain a codebase with both XAML/WPF and XAML/Silverlight front-ends, I have very little sympathy to give to anyone that thinks otherwise.) These days it's getting even easier with Xamarin adding support for WPF, but even without that sort of hand-holding there have always been options. XAML/WPF is much better than "no backwards compatibility" if you needed to support a UWP-first application on Windows 7. Certainly there were more issues moving the other direction, but particularly/mostly if you had skipped architecting for Silverlight as an intermediate step.