Basically !427, but in the form of a custom test driver script.
If I am not mistaken, for the driver script to run properly it is necessary to run
"autoreconf" in the source directory and call the configure script again in the build directory.
The output when running tests would be the same we currently have except for tests that don't PASS,
in that case, detailed information for each failing line will appear. Make a failing test to try it!
--
v3: tests: Get detailed information on failing tests.
tests: Copy autotool's testsuite driver script.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/661
On Fri Feb 23 13:38:55 2024 +0000, Conor McCarthy wrote:
> Indeed it's a bit fragile. It could instead copy up to four components
> to the temp, if available, just in case, but I don't like the idea of
> doing that each time a scalar is loaded. It's pretty spammy in SPIR-V
> code, and the temp is often used for other purposes later, where the
> written values could still be floating around if not overwritten. That's
> unlikely to interfere with optimisation, but I'm not sure.
It's a fair concern. Although if it only matters for clip/cull—not even stores, but *loads*—maybe we don't need to worry about optimization anyway? I'd be (naïvely) surprised if those are frequent.
Longer term we should think about storing this information in a friendlier format at parse time...
I would at least advocate for not using an empty default: case like that; vsir is awfully extensible and we should have a FIXME for unhandled instructions.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564#note_62432
Wine currently runs all processes with an elevated administrator token. As
described in bug 40613, some applications refuse to be run with such a token.
This patch set addresses the situation by creating all processes with an
unelevated adminstrator token by default. When a process attempts to elevate
itself through one of several mechanisms—which would show a UAC prompt on
Windows—we instead silently elevate the process, as if the user had granted
access through the UAC prompt.
This works for almost all applications. I have found only one application which
didn't get the memo, and actually asks the user to right click and run as
administrator, namely PaintTool SAI. Fortunately, 063a377df4f, combined with the
shell32 patch in this series, allows a Wine user to elevate that process by
opening explorer.exe, right-clicking, and selecting Run as Administrator, just
like on Windows.
This patch series has been in Wine-Staging for about three years. This was
partly to try to find and fix all the different creative ways that applications
tried to elevate themselves, but mostly because I needed to find a solution for
PaintTool SAI, and never quite got the time to implement run-as-administrator in
shell32.
--
v2: server: Create processes using a limited administrator token by default.
winetest: Elevate test processes on Wine.
ntdll: Always start the initial process through start.exe.
ntdll: Elevate processes if requested in RtlCreateUserProcess().
kernelbase: Elevate processes if requested in CreateProcessInternal().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5118