July 2023 - wine-gitlab

[PATCH v3 0/3] MR271: Draft: Introduce a GitLab pipeline for vkd3d
by Giovanni Mascellani (＠giomasce) 12 Jul '23

12 Jul '23

With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though: * A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail). * The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too. * While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!). * One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway). * Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future. * Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback. -- v3: ci: Introduce a CI pipeline for GitLab. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271

4 6

[PATCH 0/3] MR3318: include: Update Kerberos related headers
by Maxim Karasev (＠mxkrsv) 12 Jul '23

12 Jul '23

Required to build KList example authorization program from Windows SDK examples. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3318

2 3

[PATCH 0/1] MR3288: gdiplus: Clip polygons before drawing them
by David Kahurani (＠kahurani) 12 Jul '23

12 Jul '23

Validate user data before passing it to PolyDraw. The program in the bug requests to draw figures outrageously outside the DC's region after presumably some uninitialized values happen as a result of a missing font. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

3 7

[PATCH 0/1] MR3316: windows.globalization: Use separate AddRef/Release methods for the language factory.
by Nikolay Sivov (＠nsivov) 12 Jul '23

12 Jul '23

This currently works only because refcount field is at the same offset between structures. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3316

2 1

[PATCH 0/1] MR3315: ntdll: Fix NtContinue from within exception context on ARM64
by Billy Laws (＠bylaws) 12 Jul '23

12 Jul '23

When handling an exception, NtContinue can be called from within the signal handler, in which case the raise(SIGUSR2) call ends up getting eaten and integer register context gets restored. Switch to the method used on X86 to avoid these issues. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3315

2 1

[PATCH 0/1] MR3312: programs/start: Allow Ctrl-C to terminate GUI applications (/exec mode).
by eric pouech (＠epo) 12 Jul '23

12 Jul '23

Since dcf0bf1f, one could no longer kill a GUI application launched from unix shell (with start.exe /exec) with ctrl-c. (depends on https://gitlab.winehq.org/wine/wine/-/merge_requests/3310 to be fully functional). Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3312

2 2

[PATCH 0/1] MR3314: wow64win: Skip WM_CREATE/WM_NCCREATE lParam conversion if NULL
by Billy Laws (＠bylaws) 12 Jul '23

12 Jul '23

lParam being NULL is handled in win32u/defwnd.c so make sure to pass the NULL through rather than relying on the pointer always being valid since it may not be in this case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3314

2 1

[PATCH 0/1] MR3313: gdiplus/tests: Fix mangled test output when dumping data in hex format.
by Jeffrey Smith (＠whydoubt) 12 Jul '23

12 Jul '23

Some tests in gdiplus output hex-formatted data chunks, but it is very hard to read EXAMPLE BEFORE FIX: ``` image.c:4831: Test marked todo: 16: data should match image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 80i mage.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 80image.c:4837: 40image.c:4837: 40im age.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4837: 40ima ge.c:4837: 40image.c:4837: 40image.c:4837: 40image.c:4838: ``` EXAMPLE AFTER FIX: ``` image.c:4802: Test marked todo: 16: data should match image.c:4804: 40 40 40 40 40 40 80 80 80 80 80 80 40 40 40 40 40 40 40 40 40 40 40 40 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3313

2 1

[PATCH 0/5] MR273: vkd3d-shader: sm1 constants.
by Zebediah Figura (＠zfigura) 12 Jul '23

12 Jul '23

Most of the interesting part is the API (first patch); the rest is implementation. The basic idea is that we have predefined fixed numbers for the float, integer, and boolean constant arrays, and treat each of the three like a constant buffer. Implementation-wise, we lower sm1-style constant registers to sm4-style constant buffers and immediate constants, which are capable of expressing a strict superset of the same functionality. Note that use of immediate constants is *not* the way that wined3d currently handles DEF instructions, but rather those are uploaded via uniforms. Is there a reason for this? Relative addressing is not yet implemented. In theory it should be simple enough to either translate it directly, for external constants, or use sm4-style immediate constant buffers, for internal constants. There may be a snag if an application depends on relative addressing to cover a range of both internal and external constants; this surely would require manual assembly or an application bug, but we could implement it by copying to a temporary array using a private TEMP-like register type. -- Because API is easiest to review when there's a concrete user, I have functional patches hooking this up to wined3d, in the following branches: https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5 https://gitlab.winehq.org/zfigura/wine/-/commits/himavant_cb The vkd3d branch contains some extra commits necessary to compile basic shaders; I intend to submit these as soon as possible after the important API parts have been reviewed. I tested this patch series by building a mingw vkd3d tree with that branch, and running the shader runner through Wine, with a test that uses both internal and external constants: make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/writemask-assignop-0.shader_test I actually originally wrote the API without a user in mind, and later hooked up the implementation in Wine, and was surprised to find how straightforward it ended up being, so I think that speaks quite strongly in favour of this API. Granted, I had already written "wined3d: Store push constants in wined3d_buffers in struct wined3d_state." by that point, but that was something I anticipated needing for Wine anyway, without thinking of vkd3d. -- I actually originally did the implementation all in spirv.c, mostly because this was before we had infrastructure in place to do passes on the middle IR. I much prefer this version, it's quite centralized in one place and I think ends up being simpler than the spirv.c version anyway, but I can retrieve the spirv.c version if anyone wants to see it. That said, we may not want to lower to VKD3DSPR_CONSTBUFFER for GLSL without UBOs (but then again, we could also just emit VKD3DSPR_CONSTBUFFER registers as plain GLSL arrays). The actual declaration of flat constants is kept in spirv. I suppose the alternative here is to instead declare buffers from the reflection information and simply ignore dcl_constantbuffer. I submitted the patch as-is since it seemed simple enough and I didn't want to block this work further on rewriting that part, but we may want to rewrite it in the future regardless. ``` After the torchlight red on sweaty faces After the frosty silence in the gardens After the agony in stony places The shouting and the crying Prison and palace and reverberation Of thunder of spring over distant mountains ``` -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273

3 8

[PATCH v5 0/1] MR3294: wow64win: Always use NtUserSetWindowLongPtr() for GWLP_WNDPROC.
by Sven Baars (＠sbaars) 12 Jul '23

12 Jul '23

This fixes SetWindowLongPtr on WoW64. On 32-bit, we have ``` #define SetWindowLongPtrA SetWindowLongA #define SetWindowLongPtrW SetWindowLongW ``` meaning that on WoW64, all pointers passed would be padded with `0xffffffff` (because they are treated as LONG), and this is the cause of many of the failing WoW64 tests. This fixes that behavior. I'm not sure if this is the right place to fix it though. -- v5: wow64win: Always use NtUserSetWindowLongPtr() for GWLP_HINSTANCE and GWLP_WNDPROC. https://gitlab.winehq.org/wine/wine/-/merge_requests/3294

3 2

2025

2024

2023

2022

wine-gitlab July 2023