- wine-gitlab - winehq.org

Re: [PATCH v12 0/6] MR42: vkd3d-shader/hlsl: Some fixes.
by Francisco Casas (＠fcasas) 06 Dec '22

06 Dec '22

On Mon Dec 5 13:15:09 2022 +0000, Giovanni Mascellani wrote: > I just noticed that the the PE shader runner fails an assertion when > running this test inside Wine, using `VKD3D_TEST_PLATFORM=windows` and > native `d3dcompiler`: > ``` > Assertion failed: root_signature_desc.NumParameters <= > ARRAY_SIZE(root_params), file ../vkd3d/tests/shader_runner_d3d12.c, line 227 > ``` > @fcasas, could you have a look? That assertion happens when the `root_params` array, declared at the beginning of `d3d12_runner_create_root_signature()` is not big enough to hold all the resources in the shader. The solution is increasing the size of the array. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42#note_18835

1 0

[PATCH 0/1] MR1700: wldap32: Define LDAP_NEEDS_PROTOTYPES.
by Jacek Caban (＠jacek) 06 Dec '22

06 Dec '22

Fixes -Wstrict-prototypes warnings in clang builds. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1700

3 2

[PATCH 0/2] MR1698: win32u: Fixes for some regressions with 16-bit applications
by Sven Baars (＠sbaars) 06 Dec '22

06 Dec '22

This fixes the regressions mentioned in the following bugs Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53568 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53646 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1698

4 4

[PATCH 0/1] MR1688: ddraw: Sync draw textures even for hardware device.
by Paul Gofman (＠gofman) 06 Dec '22

06 Dec '22

Fixes a regression introduced by commit d2d9f713df7932aac4b137ec3bf647d5da7faaef. Fixes black screen in Exceed - Gun Bullet Children. The check in d3d_device_sync_surfaces() assumes that separate draw textures may be created and successfully bound for software device only. This turns out to be not always the case. The case which the game hits is that it creates a surface with DDSCAPS_TEXTURE | DDSCAPS_3DDEVICE, DDSCAPS2_TEXTUREMANAGE. Such surface creation is valid and the resulting surface is bindable as render target of a software device (we have a test for that). Such a texture effectively falls into the case when a separate draw texture is created and that looks correct. However this surface, while cannot be used as a render target on hardware device, can still be used as a texture. So for a general case syncing surfaces for software devices only is wrong (it still looks right for syncing render targets). Just always traversing all the bound textures in d3d_device_sync_surfaces() looks like a waste, while accurately tracking when there are bound textures requiring sync is possible while looks like an unnecessary complication. So triggering the sync by the fact a texture requiring a sync was ever bound (which is in fact not so common case) looks like a reasonable compromise to me. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1688

7 7

[PATCH v2 0/7] MR1697: localspl: Use print processor + SeekPrinter
by Piotr Caban (＠piotr) 06 Dec '22

06 Dec '22

-- v2: winspool: Add SeekPrinter implementation. localspl: Add partial SeekPrinter implementation. localspl: Use print processor in ScheduleJob. https://gitlab.winehq.org/wine/wine/-/merge_requests/1697

3 14

[PATCH 0/1] MR1699: configure: Use -Wl,-WX for clang configure checks in MSVC mode.
by Jacek Caban (＠jacek) 06 Dec '22

06 Dec '22

LLD by default emits only a warning for unknown arguments. This makes it pass -Wl,--disable-stdcall-fixup check, which is in fact an invalid option (and disabled by default anyway), causing warnings spam during the build. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1699

2 1

[PATCH 0/7] MR1697: localspl: Use print processor + SeekPrinter
by Piotr Caban (＠piotr) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1697

3 8

[PATCH 0/1] MR1696: msi: Use _O_* constants from fcntl.h instead of redefining them.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1696

3 2

[PATCH 0/4] MR1681: uxtheme: Avoid using lstrcmpiW.
by Rémi Bernon (＠rbernon) 06 Dec '22

06 Dec '22

This is called a huge number of time every time the module is loaded. The function does a lot of things, which I believe aren't necessary for uxtheme string comparison. The impact on process startup is noticeable, and this saves ~1min on the Gitlab CI test run. Instead, convert strings to uppercase beforehand in a locale-independent way, and compare with wcscmp. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1681

4 14

[PATCH v2 0/1] MR1694: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

And delete the ones we don't need. -- v2: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/1694

2 2

[PATCH 0/1] MR1694: setupapi: Move prototypes not in Windows's setupapi.h to setupapi_private.h.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

And delete the ones we don't need. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1694

3 2

[PATCH 0/1] MR1695: setupapi: Use _S_I(READ|WRITE) from sys/stat.h instead of redefining them.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1695

2 1

[PATCH v6 0/5] MR1588: Add windows.system.profile.systemmanufacturers DLL.
by Mohamad Al-Jaf (＠maljaf) 06 Dec '22

06 Dec '22

The test for ISmbiosInformationStatics_get_SerialNumber is broken on Window 10 testbot VMs, presumably because they don't have a serial number? It results in an HRESULT of E_UNEXPECTED. I added a broken test case for it. I'm assuming that normal installations of Windows return a valid serial number or at least something like "Not Specified" and not NULL. Also, on my Linux OS running cat /sys/class/dmi/id/product_serial returns "To be filled by O.E.M". So I added a fallback to return 0 as the number. Or is it fine to just return whatever string is found? On the Windows 8 VMs, the test crashes at line 75, hr = ISmbiosInformationStatics_get_SerialNumber( smbios_statics, &serial ). Not sure what I should do in this case. I was hoping for a flag that checks if the VM is Windows 8, but there doesn't seem to be one. Should I wrap the test in if (0) or is there an alternative way? Another weird thing is the test fails prematurely on only the 32-bit version of debian11b, saying that the runtimeclass is not registered. I'm assuming it's an issue with the testbot. Debian11 32 bit runs fine. -- v6: windows.system.profile.systemmanufacturers: Implement ISmbiosInformationStatics_get_SerialNumber. windows.system.profile.systemmanufacturers/tests: Add ISmbiosInformationStatics_get_SerialNumber tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/1588

3 10

[PATCH v2 0/10] MR1582: winhttp: Read server reply in send_request().
by Paul Gofman (＠gofman) 06 Dec '22

06 Dec '22

It turns out that WinHttpReceiveResponse() completes synchronously in async mode (unless recursive request for handling authorization or redirect is involved). Some apps depend on that and do not wait for WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE, calling WinHttpQueryHeaders() or WinHttpWebSocketCompleteUpgrade() right after calling WinHttpReceiveResponse, relying on that to finish synchronously. My initial out of tree testing shows that no network communication is performed during WinHttpReceiveResponse() call (when recursive request is not involved). I tested that by inserting a wait between WinHttpSendRequest and WinHttpReceiveResponse and disabling network connection during the wait. WinHttpReceiveResponse still succeeds on Windows. I think the above means that the actual response receiving from server is performed during WinHttpSendRequest. WinHttpReceiveResponse is not a complete no-op however. As shown by the existing tests the notifications related to receiving response are still delivered during WinHttpReceiveResponse (albeit in the same thread). Also WinHttpReceiveResponse affects request state: querying headers or upgrading to websocket without calling WinHttpReceiveResponse does not succeed. When redirect is involved, all the WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE, WINHTTP_CALLBACK_STATUS_RESPONSE_RECEIVED and WINHTTP_CALLBACK_STATUS_REDIRECT notifications are delivered synchronously from the calling thread. Then, the new request send notifications and response receiving notifications are delivered from the new thread. An interesting case is when WinHttpReceiveResponse is called from SendRequest callbacks in async mode. If WinHttpReceiveResponse is called from WINHTTP_CALLBACK_STATUS_SENDING_REQUEST or WINHTTP_CALLBACK_STATUS_REQUEST_SENT (i. e., when request is not complete yet), calling WinHttpReceiveResponse() suddenly succeeds an shows the following message sequence (that is partially reflected in the tests I am adding): - calling WinHttpReceiveResponse from WINHTTP_CALLBACK_STATUS_SENDING_REQUEST (which is already called on the async thread on Win10, thread A). Win8 queues WINHTTP_CALLBACK_STATUS_SENDING_REQUEST synchronously and goes async a bit later. - WINHTTP_CALLBACK_STATUS_RECEIVING_RESPONSE, thread A; - WinHttpReceiveResponse() returns to the caller WINHTTP_CALLBACK_STATUS_REQUEST_SENT callback; returning from user callback; - WINHTTP_CALLBACK_STATUS_REQUEST_SENT, thread A; - WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE (another thread, although the sequence is probably synced; I am not implementing this part and calling this callback from the same thread A); - WINHTTP_CALLBACK_STATUS_RESPONSE_RECEIVED in thread A; - WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE in thread A. So the receive_response() state RECEIVE_RESPONSE_SEND_INCOMPLETE is primarily needed to handle this case. -- v2: winhttp/tests: Test calling WinHttpReceiveResponse() recursively from various send callbacks. winhttp/tests: Test WinHttpReceiveResponse() synchronous behaviour. winhttp: Execute receive_response() synchronously when possible. winhttp: Wait for WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE in request_send(). winhttp: Call receive_response() recursively instead of looping. winhttp: Factor out queue_receive_response(). winhttp: Receive server reply in send_request(). winhttp: Send notifications from receive_response() directly. winhttp: Don't refill buffer after receiving server response. winhttp: Do not open connection in handle_redirect(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1582

3 12

[PATCH 0/1] MR1691: kernel32/tests: Use the strcasecmp function instead of reimplementing it.
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1691

3 2

[PATCH 0/2] MR1686: include/msvcrt: Add __WINE_(ALLOC_SIZE|DEALLOC|MALLOC) attributes to strdup, wcsdup, _aligned_malloc
by Brendan Shanks (＠bshanks) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1686

4 6

[PATCH 0/1] MR1690: include: Annotate CreateThreadpool* with __WINE_(DEALLOC|MALLOC).
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1690

2 1

[PATCH 0/1] MR1689: dbghelp: Annotate allocation functions with __WINE_(ALLOC_SIZE|DEALLOC|MALLOC).
by Alex Henrie (＠alexhenrie) 06 Dec '22

06 Dec '22

Apart from performance benefits, this gets us a nice warning if memory allocated by one of these functions is freed incorrectly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1689

2 1

[PATCH v2 0/2] MR54: vkd3d-shader/hlsl: Initialize static variables to 0 by default.
by Francisco Casas (＠fcasas) 05 Dec '22

05 Dec '22

We are currently not initializing static values to zero by default. Consider the following shader: ```hlsl static float4 va; float4 main() : sv_target { return va; } ``` we get the following output: ``` ps_5_0 dcl_output o0.xyzw dcl_temps 2 mov r0.xyzw, r1.xyzw mov o0.xyzw, r0.xyzw ret ``` where r1.xyzw is not initialized. This patch solves this by assigning the static variable the value of an uint 0, and thus, relying on complex broadcasts. This seems to be the behaviour of the the native compiler, since it retrieves the following error on a shader that lacks an initializer on a data type with object components: ``` error X3017: cannot convert from 'uint' to 'struct <unnamed>' ``` -- v2: vkd3d-shader/hlsl: Allow uninitialized static objects, as long as they are not referenced. vkd3d-shader/hlsl: Initialize static variables to 0 by default. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/54

3 8

Re: [PATCH v4 0/1] MR1630: wineusb.sys: Add support for TransferBufferMDL. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1630

1 0

Re: [PATCH v2 0/6] MR1664: Actually start enabling long integral types in wined3d. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1664

1 0

Re: [PATCH v5 0/1] MR1602: rpcrt4: Use standard C functions for memory allocation. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1602

1 0

Re: [PATCH v2 0/1] MR1677: quartz/tests: Remove redundant null check from testfilter_JoinFilterGraph. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1677

1 0

Re: [PATCH v5 0/3] MR1529: winegstreamer: Implement media_object_SetInputType for WMV decoder. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1529

1 0

Re: [PATCH v4 0/1] MR1660: mstask: Don't assume a ONCE trigger is on the current day. - approved
by Alexandre Julliard (＠julliard) 05 Dec '22

05 Dec '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1660

1 0

2025

2024

2023

2022

wine-gitlab