July 2023 - wine-gitlab

[PATCH v2 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. Native gdiplus seems to handle this gracefully so we probably also should. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41617 Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v2: gdiplus: Clip polygons before drawing them https://gitlab.winehq.org/wine/wine/-/merge_requests/3288

2 2

[PATCH v2 0/5] MR3302: Draft: gdiplus: Fix GdipGetPropertySize and GdipGetAllPropertyItems return values when no properties exist.
by Jeffrey Smith (＠whydoubt) 12 Jul '23

12 Jul '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54748 (I put this is draft, as there is something else in `test_image_properties` that should possibly be cleaned up first) -- v2: gdiplus: Fix GdipGetAllPropertyItems return value when no properties exist. gdiplus: Fix GdipGetPropertySize return value when no properties exist. gdiplus/tests: Use test context for test ran in a loop. gdiplus/tests: Add GIF to image properties tests gdiplus/tests: Use consistent no-alternate-value for image properties https://gitlab.winehq.org/wine/wine/-/merge_requests/3302

2 5

[PATCH v43 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 12 Jul '23

12 Jul '23

Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver. Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options: * Pass the Windows path to wineserver and do the conversion there. * This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons. * Obtain the current working directory of the requesting process and temporarily change directories to there. * This only handles relative paths and fails for absolute paths, UNC paths, etc. * Conditionally change directories based on whether the path is relative or not. * This is error-prone and wineserver does not have the requisite functions to do this cleanly. I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded. Abstract sockets are supported by this patch. -- v43: ws2_32/tests: Add test for AF_UNIX sockets fix. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/2786

3 8

[PATCH 0/2] MR3319: Draft: Leave critical section before waiting for streaming thread.
by Santino Mazza (＠tati1454) 12 Jul '23

12 Jul '23

This is just a draft to receive feedback, I'm not sure how could I test this behavior, right now the test I wrote works but there are times where it doesn't enter into the deadlock. Also I'm not sure if leaving the critical section before waiting for the streaming thread is the correct way to solve the problem. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3319

3 3

[PATCH v5 0/8] MR3050: msvcrt: Switch to using snames for create_locinfo.
by Victor Hermann Chiletto (＠vitorhnn) 12 Jul '23

12 Jul '23

This MR attempts to bring Wine's handling of `setlocale` and `_create_locale` more in line with the behavior of native >= `msvcr110`. It does this by replacing the usage of the LCID based `GetLocaleInfo` with the sname based `GetLocaleInfoEx`. `GetLocaleInfo` doesn't support neutral locales, even on native, which causes problems with neutral Chinese locales like `zh-Hans` and `zh-Hant`. It also improves the accuracy of the internal `__lc_locale_name_func`, as tests indicate that it returns `LOCALE_SNAME`s instead of ISO 639 language names. Potential future improvements: * Modifying the generation of the `pclmap` and `pcumap` fields of `threadlocaleinfostruct` to work on WCHARs. * I've done some changes to `__thread_data` which make it not fully match native, I'll submit a follow up which fixes this. -- v5: msvcrt: Use GetLocaleInfoEx to compare locale info. msvcrt: Remap synonyms to snames. msvcrt: Simplify set_lc_locale_name. msvcrt: Skip exhaustive locale search with valid snames. msvcrt: Convert locale_to_LCID to snames. msvcrt: Use snames instead of LCIDs in create_locinfo. msvcr120/tests: Check ___lc_locale_name_func with neutral Chinese locales. msvcr110/tests: Add tests for new setlocale behaviors. https://gitlab.winehq.org/wine/wine/-/merge_requests/3050

4 12

[PATCH v42 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 12 Jul '23

12 Jul '23

Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver. Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options: * Pass the Windows path to wineserver and do the conversion there. * This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons. * Obtain the current working directory of the requesting process and temporarily change directories to there. * This only handles relative paths and fails for absolute paths, UNC paths, etc. * Conditionally change directories based on whether the path is relative or not. * This is error-prone and wineserver does not have the requisite functions to do this cleanly. I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded. Abstract sockets are supported by this patch. -- v42: ws2_32/tests: Add test for AF_UNIX sockets fix. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/2786

2 7

Re: [PATCH v41 0/7] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) 12 Jul '23

12 Jul '23

On Wed Jul 12 18:13:28 2023 +0000, Zebediah Figura wrote: > I'm not particularly sure about patch 4/7 (opening and deleting Unix > sockets as files), but the socket parts of this look good to me now. I do agree that the file deletion code is a bit hacky, but a lot of the file handling code in wineserver depends on having a valid file descriptor, and we can't `open()` the socket file. This was the simplest way I could find to make socket file deletion work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_38815

1 0

[PATCH v2 0/1] MR253: vkd3d-shader/hlsl: Skip unallocated variables when looking for reservation conflicts.
by Zebediah Figura (＠zfigura) 12 Jul '23

12 Jul '23

-- v2: vkd3d-shader/hlsl: Skip unallocated variables when looking for reservation conflicts. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/253

3 2

[PATCH v3 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 ``` -- v3: vkd3d-shader/spirv: Emit variables for flat constant buffers. vkd3d-shader/ir: Normalise sm1-style constants. vkd3d-shader/ir: Move normalization code from spirv.c to ir.c. vkd3d-shader/d3dbc: Scan descriptors for constant register sets. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273

2 6

[PATCH v2 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 ``` -- v2: vkd3d-shader/spirv: Emit variables for flat constant buffers. vkd3d-shader/ir: Normalise sm1-style constants. vkd3d-shader/ir: Move normalization code from spirv.c to ir.c. vkd3d-shader/d3dbc: Scan descriptors for constant register sets. include: Define an API for d3dbc constants. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/273

3 7

2025

2024

2023

2022

wine-gitlab July 2023