This is nonsense on stilts. There aren't UWP versions of half of Office, and the ones with UWP versions aren't as full-featured as the Win32 versions. There's no UWP version of Visual Studio. Look at the revenue from those two things, look at Microsoft's gaming revenue, look at Valve's revenue... what is the evidence that Microsoft is willing to sabotage their Windows, Office and Visual Studio product lines all to get a rounding error's worth of additional profit?
It's a very long term thing. It'll probably happen because new APIs will be on UWP and not on Win32. I think VR might be the "next thing" that'll only get in-OS support in UWP.
Windows' thing has always been backwards compatibility (not counting programs with questionable code in the first place), and the entire OS is win32 as well.
They'd practically be telling all their casual, professional, and enterprise userbase to not update. Their prior support for win32 has locked them into it, even if they want to leave it
> Windows' thing has always been backwards compatibility
I think they are realizing that it's holding them back and I suspect they will be less afraid of breaking things in the name of progress.
When I updated my laptop from Windows 7 to Windows 10, it just uninstalled the things it thought was incompatible (a Cisco VPN client was the big problem).
In fact, the sneaky and slimy strategy that they used to get people to update to Windows 10 feels almost like contempt for customers that don't want the things Microsoft is pushing.
Is the PC gaming market a big one? Is there an opportunity here for Linux to become a gaming contender?
There certainly is an opportunity, it's just still very questionable how things will play out.
Current state is that 25% of the Steam library is Linux-compatible. That's about 2500 games, so definitely enough to keep you entertained, unless you're the type of gamer who always has to play the newest AAA titles.
With Vulkan slowly picking up adoption, this will probably increase even more rapidly in the future, too.
Next thing is that Vulkan as well as DX12 make it so that drivers for graphics cards will be much smaller and therefore the resulting drivers will be much less likely to be broken, which has been a big problem on Linux in the past.
But Nvidia has now pretty good Linux drivers anyways and AMD has recently started investing more resources into it. Among other things, AMD open-sourced their drivers, so now the Linux-community can help to fix up their drivers instead of maintaining an own driver.
I also figure that the growing machine learning market gives a good incentive for Nvidia and AMD to have good support for Linux, so that should translate back to the desktop, too.
The only problem is that all of this can serve as reason to not avoid Linux, but unless Microsoft really does continue making such great arguments against using Windows, we won't really see many people change operating system...
It means that the developers marked it as Linux-compatible on Steam.
I don't know, if Valve requires anything for that, but it's specifically not the percentage of titles which you can get to work through any combination of black magic. It's the percentage of titles where the developers offer you support, if it doesn't work on your system.
And I know that some of those games do use WINE internally for the port, but it's properly pre-configured in a wrapper and should work just as well as a native Linux-game. So, you don't need WINE installed separately on your system for those.
I would love to see them bring containers to the consumer OS. It would be possible to launch a base container that has it's own win32k and csrss, and another that only does UWP or .net native apps. The containers themselves might only speak NTAPIs and see a small segment of the full NT filesystem. Windows would be displayed through a shared-memory version of rootless RDP. DirectX and GL/Vulkan would support direct rendering. When running a game non essential processes could be checkpointed and suspended.
If the UWP-only APIs are "too interesting", a way will be found around this. For example, you could funnel API calls from a Win32 app into a UWP-app receiver via a local TCP connection.
So I currently work at Microsoft as a researcher and I was recently forced into doing a UWP app/prototype because it has the best inking support that hasn't been back ported to WPF. I had to give up a lot to use it however: the DLR doesn't JIT in UWP, which I was using heavily, while compile times are slow when debugging (seconds rather than the typical tens/hundreds of milliseconds), atrocious when deploying (an hour for a small app). But as a benefit, I can deploy to UWP-only devices like SurfaceHub, which was pretty sweet!
Sad that we have to make gut wrenching choices these days, even within Microsoft's own platforms. But elsewhere as well, e.g. go with JavaScript to accept third party code and deploy on web or go iOS native to get access multiple shared memory threads (which I know how to use) for an app I've been thinking about.
And aren't UWP apps a walled garden (apps need to be signed unless you enable developer mode, which has all kinds of side effects, requires a Microsoft account and can be revoked?)?
Apps can be sideloaded by default since last November. It takes a one-line PowerShell command and that's it (no Settings changes, nothing). They do need to be signed, but the signatures aren't much different than any prior "Authenticode" signing options: find a CA that sells code signing certificates and buy a certificate. (Certificates can be revoked by your CA, yes, but your CA doesn't have to be Microsoft.) If you are selling games on PC outside of Steam (MSI/NSIS/et al installers), you should already have code signing certificates and there's nothing really new there on that front.
At some point (I don't recall if it will make it into the Anniversary Update or not), the install process for a UWP app won't even need the one line of PowerShell and will support just double-clicking the .appx package, and will have suitable UAC-like install prompts.
Microsoft has already told Steam they should encourage UWP app installs, and supposedly the Play Anywhere stream of games from Microsoft in the next few months will also be sold via Steam as UWP installs under the hood as an option to game buyers that prefer Steam (but the expectation is that buying from Steam will not count for multi-platform cross-buy, as opposed to buying from the Windows Store).
(Microsoft does provide to verified developer Microsoft accounts short term keys for developer testing, but you wouldn't want to use those for sideloading simply because they are so short term. The Windows Store also handles long term code signing for you at no additional cost ["in the cloud"], and yes that can be revoked if they kick your app out of the Store, but that shouldn't be surprising.)
(Developer Mode doesn't really have "side effects" and I don't think you need a Microsoft Account to switch to Developer Mode, but I still wouldn't recommend it to non-technical friends.)
But, this is predicated on the suggestion that UWP will kill Steam or is meant to be a walled garden. Even though, people including Tim Sweeney are WELL AWARE (he was notified about it, and responded) that the new version of Windows 10 on August 2nd (literally in less than a week) specifically adds more features to make third party install of UWP apps easier. You'll be able to just double click APPX files to install them, they'll have icons and properties visible in the UI. Microsoft has stated multiple times they intend UWP to be the safer, more secure, way to write apps going forwards, but that they will be workable with third party stores and installation methods.
The point seemed to be that killing existing Win32 APIs would hurt Microsoft more than it helps the UWP, but for gaming the only thing that needs to happen is a new graphics or peripheral API that's UWP only and is substantial enough for developers to drop Win32 support.
But that's not what Tim said. What Tim said was is that Microsoft, over time, is going to start damaging Steam's current functionality by locking down the Win32 API. Which, given how many Win32 API apps are cash cows for Microsoft or Microsoft's major partners (Adobe, for instance), it's ridiculous to think that Microsoft is going to start tampering with those APIs just to cut off Steam. Even if you believe Microsoft is evil, they're not cartoon villains from Captain Planet, they're not evil for evil's sake, they act according to what they believe is their self-interest. They're not about to start tampering with things their core business relies upon in order to benefit their barely-break-even games business.
