EA Desktop depends on that when tries to run the game with elevated privileges (which is performed from a process started by a service and running in a service session on Windows).
The improved stub only returns interactive ("Console") session, while Windows at least starting from Win Vista also always have "Services" session. While we could probably return "Sevices" as well, I think it is safer not to while we don't really have services running in "Services" session (along with all the winstation, token etc. info).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3756
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v5: vkd3d-shader: Validate source parameters.
vkd3d-shader: Validate destination parameters.
vkd3d-shader: Validate register types.
vkd3d-shader: Validate instruction handlers.
vkd3d-shader: Introduce a boilerplate to validate the generated IR.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317