stan423321
Member
Saying that "UWPs could be sold on Steam" is both true and untrue. "UWPs could be sold by Valve" would be technically true. Both are incredibly misleading.
The way Steam works is that it processes program directory of a game to some level - for some games it basically copies most files, for other ones it actually manages data archives by itself. This data is then send out to the client which recreates something functional - again, sometimes the exact files sent by developers, sometimes something similar. For games both making use of Steam APIs for e.g. server browsers and not making use of these but under control of additional Steam features such as screen home overlay, custom controller support and so on, game executable is fused at runtime with code files supplied by the Steam client. An element of account lockout is that files, executable ones in particular, are customized by Valve servers on per-account basis.
The UWP installation, as far as I'm aware, works as follows: you hand Windows a complete installation package that is signed by someone who got their credentials signed by MS and it installs, as of now to an encrypted folder so that no one messes with this previously signed package data. This doesn't allow simple use of currently installed data as a baseline for deriving slightly different files delivered by a patch package, assuming patch packages are even in. You could make a lot of files just regular files laying around somewhere, but this is not allowed for code files, and is somewhat of a subversion of packaging system in the first place. This assumes MS's signature credential signing agreement even allows such things as generating a signature for every user's copy of a package, otherwise the whole authentication system needs to be rebuilt from scratch. An interesting question that I don't know the answer to is whether a regular UWP app can request installation of another UWP app provided by file, or whether the client would have to keep using WinAPI nonetheless.
UWP by design doesn't allow things such as subverting existing executable's code to support input overriding, so for each such feature Valve would probably have to patch every individual game at installation point or build something in right from the get go instead of doing it once for client and then finishing some things at runtime. Just patching every installation point would still require usage of "unpure" UWP API, though. This gets very interesting when you get delisted games into the mix, since it possibly has different legal implications. Additionally a lot of code for server connections and such would have to be rebuilt or heavily redesigned due to UWP's design discouraging communication between different processes. It wouldn't be unimaginable that a game would have to be patched in sync with a patch to the Steam client.
This doesn't cover why would Valve want to support this program format in the first place. There is very little "big evolution" here. You can't JIT code, you can't talk to other processes as easily, you can't use some old APIs which were sometimes outdated and sometimes not. The APIs that are exclusive to UWPs and do something as opposed to dealing with UWP specific problems tend to be either gated off arbitrarily (hello, Xbox One controller trigger rumble... last I heard of you) or connected to MS accounts.
