- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR2324: advapi32/tests: Fix the RegEnumValueA() tests in UTF-8 locales. - approved
by Alexandre Julliard (＠julliard) 06 Mar '23

06 Mar '23

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

1 0

[PATCH v3 0/9] MR106: vkd3d-shader/hlsl: packoffset() support.
by Francisco Casas (＠fcasas) 06 Mar '23

06 Mar '23

Support manually packing constant buffer elements through the `packoffset(·)` syntax. Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as: ```hlsl Texture2D tex; cbuffer buff { float4 a : packoffset(c0); sampler sam : packoffset(c0) : register(s1) : SEMANTIC; } float4 main() : sv_target { return tex.Sample(sam, float2(0, 0)) + a; } ``` but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`. -- v3: vkd3d-shader/hlsl: Consider register() as manual packing for resource fields. tests: Test packoffset() with resources inside cbuffers. vkd3d-shader/hlsl: Ignore packoffset() contents for SM1. vkd3d-shader/hlsl: Don't allow manual and automatic cbuffer offset packing. vkd3d-shader/hlsl: Detect overlaps in cbuffer offsets. vkd3d-shader/hlsl: Support packoffset(). vkd3d-shader/hlsl: Parse packoffset(). tests: Test packoffset(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106

3 12

[PATCH 0/12] MR2292: windows.perception.stub: Implement ISpatialSurfaceObserverStatics2::IsSupported()
by Mohamad Al-Jaf (＠maljaf) 06 Mar '23

06 Mar '23

Needed by the VR games Forewarned and Überlaüfer. I had to put the parameters of the header functions on newlines because they're too long. Did the same for the other headers for consistency. windows.security.cryptography.idl uses a similar style. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2292

3 18

[PATCH 0/5] MR2322: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) 06 Mar '23

06 Mar '23

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2322

4 7

[PATCH v2 0/3] MR115: vkd3d-shader/hlsl: Write sample count for multisampled resources declarations.
by Nikolay Sivov (＠nsivov) 06 Mar '23

06 Mar '23

-- v2: vkd3d-shader/sm4: Write sample count field for multisampled texture declaration. vkd3d-shader/hlsl: Parse multisample texture type names. vkd3d-shader/trace: Output sample count for multisampled resources. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/115

3 4

[PATCH 0/1] MR2332: ir50_32: Handle 24-bit output media type.
by Anton Baskanov (＠baskanov) 06 Mar '23

06 Mar '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47407 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2332

3 2

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Zebediah Figura (＠zfigura) 06 Mar '23

06 Mar '23

> Thinking of doing this x11 specific, I think that maybe we don't even need a special boolean flag if your MR !2217 gets in? Once we have a separate tracking of internal pixel format in WGL_WINE_pixel_format_passthrough we could just always fail setting internal pixel format once external is set. The extension itself will still work as if an app wants to use GL together with d3d it will be able to set GL pixel format (which will result in wined3d creating a backup context). I think that'd work, yeah. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26227

1 0

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Paul Gofman (＠gofman) 06 Mar '23

06 Mar '23

I looked a bit into winemac driver and some GL on Mac docs and I suppose that such an issue should not be happening on Mac. If I read that right pixel format is only bound to GL context and the pixel format set by Wine only influences the contexts created with the window. I don't have any Mac setup however to check that for sure. If anyone could check if that referenced games (Richman: Classic in opengl mode or Secondhand Lands or SPORE from Bug 51848 work now on Mac without issues that would be a good confirmation that set pixel format works fine there and doesn't impose issues like on winex11. Thinking of doing this x11 specific, I think that maybe we don't even need a special boolean flag if your MR !2217 gets in? Once we have a separate tracking of internal pixel format in WGL_WINE_pixel_format_passthrough we could just always fail setting internal pixel format once external is set. The extension itself will still work as if an app wants to use GL together with d3d it will be able to set GL pixel format (which will result in wined3d creating a backup context). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26224

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Jacek Caban (＠jacek) 06 Mar '23

06 Mar '23

On Wed Mar 1 12:24:02 2023 +0000, Alexandros Frantzis wrote: > > The last patch looks worrying in terms of forward-compatibility. > Looking at your wayland branch, you use a few unstable files. What > happens if/when they get promoted to stable? Will those files be moved > in wayland-protocols causing your branch to fail to build? > TL;DR: Not a problem. > When a protocol is moved to stable, a new copy is placed in that > directory (details are different depending on whether this copy is done > from 'staging' or the legacy 'unstable'), while the old xml file(s) > remain in place for backward compatibility. If the new copy requires a > protocol name change (e.g., from unstable->stable, but not > staging->stable) compositors tend to have a long deprecation period > during which both old and new names are supported. As an example, it > took compositors several years to drop support for unstable/xdg-shell > after the introduction of stable/xdg-shell. > FWIW, the Wayland community is *very* conservative concerning promotions > to stable, so a lot of functionality is still in unstable/staging. > Compare: 3 stable protocols vs 27 staging/unstable, some of them having > been there for many years. > More information about these topics can be found at https://gitlab.freedesktop.org/wayland/wayland-protocols/ > > Also, it would be better to have commit adding build system support > for protocol files together with at least a simple use of it in the same MR. > Ack. Moved to the next MR. Thanks for explanation, staging backward compatibility guarantees should do the trick. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26223

1 0

[PATCH v4 0/6] MR2303: uiautomationcore: Implement a few COM UI Automation condition interfaces.
by Connor McAdams (＠cmcadams) 06 Mar '23

06 Mar '23

-- v4: uiautomationcore: Implement IUIAutomation::get_RawViewCondition. uiautomationcore: Implement IUIAutomation::get_ControlViewCondition. uiautomationcore: Implement IUIAutomation::CreateOrCondition. uiautomationcore: Implement IUIAutomation::CreateNotCondition. uiautomationcore: Implement IUIAutomation::CreatePropertyCondition. uiautomationcore: Implement IUIAutomation::Create{True,False}Condition. https://gitlab.winehq.org/wine/wine/-/merge_requests/2303

3 9

[PATCH v2 0/1] MR113: vkd3d-shader/dxbc: Validate and skip the signature section header size.
by Conor McCarthy (＠cmccarthy) 06 Mar '23

06 Mar '23

Silences a very common warning. -- v2: vkd3d-shader/dxbc: Validate and skip the signature section header size. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/113

4 5

[PATCH v22 0/5] MR2091: Draft: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Mar '23

06 Mar '23

Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v22: windows.media.speech: Implement Vosk create and release functions in the unixlib. windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine. windows.media.speech/tests: Get rid of duplicated hresult. windows.media.speech: Add unixlib stub. windows.media.speech: Add Vosk checks to autoconf. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

3 6

[PATCH v21 0/7] MR2091: Draft: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Mar '23

06 Mar '23

Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v21: windows.media.speech: Implement Vosk create and release functions in the unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

3 8

[PATCH v20 0/7] MR2091: Draft: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Mar '23

06 Mar '23

Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v20: windows.media.speech: Implement Vosk create and release functions in the unixlib. windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine. windows.media.speech/tests: Get rid of duplicated hresult. windows.media.speech: Add unixlib stub. TEMP: Reconf. windows.media.speech: Add Vosk checks to autoconf. makedep: Better differentiate between compiling and linking commands. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

3 8

[PATCH v19 0/5] MR2091: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Mar '23

06 Mar '23

Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v19: windows.media.speech: Implement Vosk create and release functions in the unixlib. windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine. windows.media.speech/tests: Get rid of duplicated hresult. windows.media.speech: Add unixlib stub. windows.media.speech: Add Vosk checks to autoconf. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

4 12

[PATCH v2 0/4] MR2334: user32: Add some ActivateKeyboardLayout tests and send WM_INPUTLANGCHANGE.
by Rémi Bernon (＠rbernon) 06 Mar '23

06 Mar '23

-- v2: win32u: Send WM_INPUTLANGCHANGE when activating new layout. win32u: Move window query functions around. user32/tests: Add a WM_INPUTLANGCHANGE message test. user32/tests: Skip tests if layout failed to activate. https://gitlab.winehq.org/wine/wine/-/merge_requests/2334

3 6

[PATCH 0/4] MR2334: user32: Add some ActivateKeyboardLayout tests and send WM_INPUTLANGCHANGE.
by Rémi Bernon (＠rbernon) 06 Mar '23

06 Mar '23

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

3 5

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Jacek Caban (＠jacek) 06 Mar '23

06 Mar '23

Jacek Caban (@jacek) commented about dlls/winewayland.drv/wayland.c: > + > +/********************************************************************** > + * wayland_init > + * > + * Initialise a wayland instance. > + */ > +BOOL wayland_init(struct wayland *wayland) > +{ > + struct wl_display *wl_display_wrapper; > + > + TRACE("wayland=%p wl_display=%p\n", wayland, process_wl_display); > + > + wl_list_init(&wayland->thread_link); > + > + wayland->process_id = GetCurrentProcessId(); > + wayland->thread_id = GetCurrentThreadId(); Those are redundant for this commit. It's trivial to add when needed and introducing it later would make things much easier to review, because reviewer would need to jump between MR and your branch much less. I would suggest to leave thread_link, thread_id, process_id and initialized out of this MR. (Also, if process_id is always equal to `GetCurrentProcessId()`, I don't think there is much point in storing it). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26191

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Jacek Caban (＠jacek) 06 Mar '23

06 Mar '23

Jacek Caban (@jacek) commented about dlls/winewayland.drv/wayland.c: > +{ > + struct wl_display *wl_display_wrapper; > + > + TRACE("wayland=%p wl_display=%p\n", wayland, process_wl_display); > + > + wl_list_init(&wayland->thread_link); > + > + wayland->process_id = GetCurrentProcessId(); > + wayland->thread_id = GetCurrentThreadId(); > + wayland->wl_display = process_wl_display; > + > + if (!wayland->wl_display) > + { > + ERR("Failed to connect to wayland compositor\n"); > + return FALSE; > + } I think that this error condition can never happen, we fail to load the driver if process_wl_display is NULL. Also, if wl_display is always equal to process_wl_display, why do we need to store it in wayland struct? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26192

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Jacek Caban (＠jacek) 06 Mar '23

06 Mar '23

Jacek Caban (@jacek) commented about configure.ac: > [enable_winex11_drv]) > fi > > +WINE_NOTICE_WITH(wayland, [false], > + [Wayland ${notice_platform}development files not found, the Wayland driver won't be supported.], > + [enable_winewayland_drv]) > + This chunk makes little sense on its own, it could just be added in a commit that introduces wayland-client checks. This commit doesn't really need to modify configure more than what tools/make_makefiles does. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26190

1 0

[PATCH v5 0/5] MR1543: mmdevapi: Handle process_attach, process_detach and test_connect UNIX driver functions
by Davide Beatrici (＠davidebeatrici) 06 Mar '23

06 Mar '23

The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`. -- v5: wine{alsa,coreaudio,oss,pulse}: Move test_connect handling into mmdevapi. mmdevapi: Use UTF-16 for client name in "test_connect_params" and "create_stream_params" structs. winepulse: Move process_attach and process_detach handling into mmdevapi. mmdevapi: Query MemoryWineUnixFuncs virtual memory and store the resulting handle. wine{alsa,coreaudio,oss,pulse}: Return STATUS_SUCCESS for unused unixlib functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/1543

3 6

[PATCH v5 0/2] MR2168: win32u: Match second name when enum fonts.
by Keming Liang (＠Keming) 06 Mar '23

06 Mar '23

the patch can resolve the issue: https://bugs.winehq.org/show_bug.cgi?id=54483 and can also solve many crashed issue related to font(MS Shell Dlg etc.) -- v5: add font test for MS Shell Dlg when Language is Chinese. win32u: Match second name when enum fonts. https://gitlab.winehq.org/wine/wine/-/merge_requests/2168

2 2

[PATCH v3 0/3] MR2331: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze.
by Jinoh Kang (＠iamahuman) 04 Mar '23

04 Mar '23

-- v3: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze. https://gitlab.winehq.org/wine/wine/-/merge_requests/2331

3 4

[PATCH v2 0/3] MR2331: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze.
by Jinoh Kang (＠iamahuman) 04 Mar '23

04 Mar '23

-- v2: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze. riched20: Don't assume that TxDraw preserves the device context's brush selection. riched20/tests: Test for ITextDocument::Freeze and ITextDocument::Unfreeze. https://gitlab.winehq.org/wine/wine/-/merge_requests/2331

3 4

[PATCH 0/3] MR2331: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze.
by Jinoh Kang (＠iamahuman) 04 Mar '23

04 Mar '23

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

2 3

[PATCH 0/1] MR2326: kernelbase: Add DiscardVirtualMemory() stub.
by Brendan Shanks (＠bshanks) 04 Mar '23

04 Mar '23

This is required by the latest versions of Chromium. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2326

4 4

[PATCH 0/1] MR115: vkd3d-shader/trace: Output sample count for multisampled resources.
by Nikolay Sivov (＠nsivov) 04 Mar '23

04 Mar '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/115

2 1

[PATCH v3 0/6] MR2303: uiautomationcore: Implement a few COM UI Automation condition interfaces.
by Connor McAdams (＠cmcadams) 03 Mar '23

03 Mar '23

-- v3: uiautomationcore: Implement IUIAutomation::get_RawViewCondition. uiautomationcore: Implement IUIAutomation::get_ControlViewCondition. uiautomationcore: Implement IUIAutomation::CreateOrCondition. uiautomationcore: Implement IUIAutomation::CreateNotCondition. uiautomationcore: Implement IUIAutomation::CreatePropertyCondition. uiautomationcore: Implement IUIAutomation::Create{True,False}Condition. https://gitlab.winehq.org/wine/wine/-/merge_requests/2303

3 12

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Zebediah Figura (＠zfigura) 03 Mar '23

03 Mar '23

> Do you see any other way out of this? I mean specifically the case when an app sets GL pixel format itself on a window. I was thinking about whether it is possible to make setpixelformat quicker in winex11 instead and I don't see how. If keeping direct presentation it will require some X window reconfigure which is not going to be anywhere quick. Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context. > > The other different (but a bit complicated) way would be to: > > * count statistics of GL pixel format switches; > * introduce switching back from backup context and switch between resetting pixel format or switching to backup context or back based on that. Assuming that recreating the GLX drawable is always worse than a GDI blit, I think this patch is the right direction. I just don't want to regress performance in backends other than x11. So maybe the right approach here is to add some boolean flag saying "return an error if changing the pixel format would be expensive". Or maybe things are already broken on winemac and the right approach is just to punt. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26147

1 0

[PATCH 0/1] MR2323: gdiplus: Use transparency instead of background color if transparent color flag is set in GIF GCE.
by Piotr Caban (＠piotr) 03 Mar '23

03 Mar '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54563 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2323

3 5

Re: [PATCH v2 0/1] MR2321: windowscodecs: Don't reorder gif extension blocks in GetReaderByIndex. - approved
by Alexandre Julliard (＠julliard) 03 Mar '23

03 Mar '23

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

1 0

Re: [PATCH v2 0/2] MR2319: explorer: Fix systray window creation failure with nulldrv. - approved
by Alexandre Julliard (＠julliard) 03 Mar '23

03 Mar '23

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

1 0

Re: [PATCH v2 0/3] MR2318: win32u: Fix a few nulldrv failures in ToUnicode and GetDeviceCaps(dc, BITSPIXEL). - approved
by Alexandre Julliard (＠julliard) 03 Mar '23

03 Mar '23

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

1 0

Re: [PATCH v2 0/2] MR2315: d3d8, d3d9: WM_SYSCOMMAND test fixes. - approved
by Alexandre Julliard (＠julliard) 03 Mar '23

03 Mar '23

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

1 0

Re: [PATCH v2 0/1] MR2317: include: Add more Windows.Foundation.Numerics structs. - approved
by Alexandre Julliard (＠julliard) 03 Mar '23

03 Mar '23

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

1 0

[PATCH 0/2] MR2329: loader: In macOS preloader, move the top-down allocations area down and stop using mincore()
by Brendan Shanks (＠bshanks) 03 Mar '23

03 Mar '23

`mincore()` is not a reliable way to determine whether a region is empty. This could result in an already-in-use region being mapped with `MAP_FIXED`, and Wine conflicting with its original owner (i.e. dyld). With the `mincore()` check removed, a special case was added to allow zero-fill sections to be mapped. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2329

2 2

[PATCH 0/5] MR2328: winevulkan: Update to VK spec version 1.3.242.
by Georg Lehmann (＠DadSchoorse) 03 Mar '23

03 Mar '23

Not trivial this time because VulkanSC was added to the xml. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2328

2 5

[PATCH 0/1] MR2327: kernel32: Implement GetFirmwareType().
by Brendan Shanks (＠bshanks) 03 Mar '23

03 Mar '23

Chromium used to resolve this function through GetProcAddress(), but now calls it directly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2327

2 1

[PATCH 0/1] MR2321: windowscodecs: Don't reorder gif extension blocks in GetReaderByIndex.
by Piotr Caban (＠piotr) 03 Mar '23

03 Mar '23

The code that reorders extension blocks is broken and causes some extensions to be not reported (when GCE is not the last extension block). This fixes GCE blocks reading from gifs attached in [bug 54563](https://bugs.winehq.org/show_bug.cgi?id=54563). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2321

3 2

[PATCH 0/2] MR2319: explorer: Fix systray window creation failure with nulldrv.
by Rémi Bernon (＠rbernon) 03 Mar '23

03 Mar '23

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

3 3

[PATCH 0/3] MR2318: win32u: Fix a few nulldrv failures in ToUnicode and GetDeviceCaps(dc, BITSPIXEL).
by Rémi Bernon (＠rbernon) 03 Mar '23

03 Mar '23

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

3 4

[PATCH v2 0/6] MR2303: uiautomationcore: Implement a few COM UI Automation condition interfaces.
by Connor McAdams (＠cmcadams) 03 Mar '23

03 Mar '23

-- v2: uiautomationcore: Implement IUIAutomation::get_RawViewCondition. uiautomationcore: Implement IUIAutomation::get_ControlViewCondition. uiautomationcore: Implement IUIAutomation::CreateOrCondition. uiautomationcore: Implement IUIAutomation::CreateNotCondition. uiautomationcore: Implement IUIAutomation::CreatePropertyCondition. uiautomationcore: Implement IUIAutomation::Create{True,False}Condition. https://gitlab.winehq.org/wine/wine/-/merge_requests/2303

2 7

[PATCH 0/1] MR111: vkd3d-shader/hlsl: Improve handling of "technique" tokens.
by Nikolay Sivov (＠nsivov) 03 Mar '23

03 Mar '23

This change only implements case-sensitivity of technique keywords and related checks when corresponding profile is used. My immediate plan is to add some synthetic type for technique variables, for example as {object, void}, then add named techniques as variables. This is useful because these names are participating in global scope, and should not collide with normal variables. After that "pass_list" will be split, at least in two variants because of how much d3d9 syntax differs. Some trivial changes will be need later to have some top level fx compilation helper that considers only fx objects and calls ps/vs/gs compiler to create inner shader blobs on same original source. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/111

4 17

[PATCH 0/1] MR2324: advapi32/tests: Fix the RegEnumValueA() tests in UTF-8 locales.
by Francois Gouget (＠fgouget) 03 Mar '23

03 Mar '23

On Windows RegEnumValueA() is buggy such that when the value name buffer is too small, it may way overestimate the required data buffer size, sometimes returning more than the sufficiently large buffer it was provided, in which case that buffer is untouched and thus not NUL-terminated. So modify the tests to accept this broken result and avoid checking out-of-bounds data. Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=53172 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2324

2 1

[PATCH 0/5] MR2316: ddraw: SetSurfaceDesc() refactoring, part 2.
by Zebediah Figura (＠zfigura) 03 Mar '23

03 Mar '23

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

4 7

[PATCH 0/1] MR2312: nsi: Simplify and better document NsiAllocateAndGetTable().
by Francois Gouget (＠fgouget) 03 Mar '23

03 Mar '23

Return directly in case of success so exiting the loop only happens in case of error. Better identify which statements prepare the next attempt / set things up in case the table allocation failed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2312

3 4

[PATCH v5 0/1] MR1987: webservices/tests: Move firewall code to a common header.
by Hans Leidekker (＠hans) 03 Mar '23

03 Mar '23

-- v5: webservices/tests: Move firewall code to a common header. https://gitlab.winehq.org/wine/wine/-/merge_requests/1987

3 2

[PATCH v4 0/2] MR2168: win32u: Match second name when enum fonts.
by Keming Liang (＠Keming) 03 Mar '23

03 Mar '23

the patch can resolve the issue: https://bugs.winehq.org/show_bug.cgi?id=54483 and can also solve many crashed issue related to font(MS Shell Dlg etc.) -- v4: add font test for MS Shell Dlg when Language is Chinese. https://gitlab.winehq.org/wine/wine/-/merge_requests/2168

3 6

[PATCH 0/1] MR113: vkd3d-shader/dxbc: Validate and skip the signature section header size.
by Conor McCarthy (＠cmccarthy) 03 Mar '23

03 Mar '23

Silences a very common warning. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/113

2 1

[PATCH v2 0/1] MR2320: ntdll: Handle aarch64 pointer authentication in unwind info
by Martin Storsjö (＠mstorsjo) 03 Mar '23

03 Mar '23

These were docmented in [1] (with the user-facing name of the opcode adjusted later in [2]). Since MSVC 2022, the precompiled runtimes (both runtimes such as vcruntime140*.dll and the statically linked code from e.g. libcmt.lib) are built with pointer authentication enabled. To correctly handle unwinding through such functions, even on HW that don't support the pointer authentication mechanism itself, wine needs to at least be aware of it (for handling the cases with packed unwind info with CR==2 simiarly to CR==3). This patch has been tested on Linux on HW supporting pointer authentication too, with binaries built with MSVC. [1] https://github.com/MicrosoftDocs/cpp-docs/commit/f510c83085d9764b3c7b522219… [2] https://github.com/MicrosoftDocs/cpp-docs/commit/cac237d3f370a06b71f6c314a6… -- v2: ntdll: Handle aarch64 pointer authentication in unwind info https://gitlab.winehq.org/wine/wine/-/merge_requests/2320

2 1

[PATCH 0/1] MR2320: ntdll: Handle aarch64 pointer authentication in unwind info
by Martin Storsjö (＠mstorsjo) 03 Mar '23

03 Mar '23

These were docmented in [1] (with the user-facing name of the opcode adjusted later in [2]). Since MSVC 2022, the precompiled runtimes (both runtimes such as vcruntime140*.dll and the statically linked code from e.g. libcmt.lib) are built with pointer authentication enabled. To correctly handle unwinding through such functions, even on HW that don't support the pointer authentication mechanism itself, wine needs to at least be aware of it (for handling the cases with packed unwind info with CR==2 simiarly to CR==3). This patch has been tested on Linux on HW supporting pointer authentication too, with binaries built with MSVC. [1] https://github.com/MicrosoftDocs/cpp-docs/commit/f510c83085d9764b3c7b522219… [2] https://github.com/MicrosoftDocs/cpp-docs/commit/cac237d3f370a06b71f6c314a6… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2320

2 1

[PATCH v3 0/1] MR1009: winemenubuilder: Skip desktop integration for certain associations.
by Alex Henrie (＠alexhenrie) 03 Mar '23

03 Mar '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41275 A version of this patch has been in Wine Staging since March 2020. -- v3: winemenubuilder: Skip desktop integration for certain associations. https://gitlab.winehq.org/wine/wine/-/merge_requests/1009

3 2

[PATCH v4 0/8] MR1259: gitlab: Run some tests with nulldrv driver.
by Rémi Bernon (＠rbernon) 03 Mar '23

03 Mar '23

Allowing the job to fail to avoid failing the pipeline. Some new tests are failing with it, and some are succeeding todo_wine. -- v4: gitlab: Run user32 32-bit tests with nulldrv driver. user32/tests: Update todos specific to the X11 display driver. user32/tests: Check graphics driver and add todos for nulldrv. win32u: Check GUID_NULL display device if desktop atom is missing. explorer: Use GUID_NULL display device GUID for nulldrv. win32u: Return the current display mode depth with nulldrv. win32u: Map VK_MENU / KBDALT in kbdus_tables pCharModifiers. user32/tests: Test VK_MENU effect on ToUnicode. https://gitlab.winehq.org/wine/wine/-/merge_requests/1259

2 9

[PATCH v4 0/5] MR1543: mmdevapi: Handle process_attach, process_detach and test_connect UNIX driver functions
by Davide Beatrici (＠davidebeatrici) 03 Mar '23

03 Mar '23

The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`. -- v4: wine{alsa,coreaudio,oss,pulse}: Move test_connect handling into mmdevapi. mmdevapi: Use UTF-16 for client name in "test_connect_params" and "create_stream_params" structs. winepulse: Move process_attach and process_detach handling into mmdevapi. https://gitlab.winehq.org/wine/wine/-/merge_requests/1543

3 6

[PATCH 0/2] MR2315: d3d8, d3d9: WM_SYSCOMMAND test fixes.
by Zebediah Figura (＠zfigura) 03 Mar '23

03 Mar '23

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

3 3

[PATCH 0/1] MR2317: include: Add more Windows.Foundation.Numerics structs.
by Mohamad Al-Jaf (＠maljaf) 03 Mar '23

03 Mar '23

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

3 4

[PATCH 0/1] MR2314: user32/tests: Do not stop checking the message list when skipping an optional or unsupported message.
by Zebediah Figura (＠zfigura) 03 Mar '23

03 Mar '23

This was either added by accident, or in an attempt to stop checking the message list once we hit a winevent hook todo [and accidentally given too wide of a scope]. However, the same commit also uses a global counter to ensure that only one winevent todo is printed, so we don't need to break here anyway. Fixes: a72bffe768c9fe462010d7e40e20226322fb82c7 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2314

3 2

Re: [PATCH v11 0/1] MR1892: ntoskrnl.exe/tests: Add Driver Object Extension Tests. - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v2 0/5] MR2309: ddraw: SetSurfaceDesc() refactoring, part 1. - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v2 0/5] MR2310: wined3d: move stubs out of state tables - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v2 0/2] MR2313: shlwapi/tests: Fix the date formatting tests when the locale does not match the code page. - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v10 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v3 0/2] MR2302: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile(). - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

Re: [PATCH v10 0/1] MR2153: win32u: Invalidate all cached keys after input. - approved
by Alexandre Julliard (＠julliard) 02 Mar '23

02 Mar '23

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

1 0

[PATCH v2 0/9] MR106: vkd3d-shader/hlsl: packoffset() support.
by Francisco Casas (＠fcasas) 02 Mar '23

02 Mar '23

Support manually packing constant buffer elements through the `packoffset(·)` syntax. Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as: ```hlsl Texture2D tex; cbuffer buff { float4 a : packoffset(c0); sampler sam : packoffset(c0) : register(s1) : SEMANTIC; } float4 main() : sv_target { return tex.Sample(sam, float2(0, 0)) + a; } ``` but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`. -- v2: vkd3d-shader/hlsl: Consider register() as manual packing for resource fields. tests: Test packoffset() with resources inside cbuffers. vkd3d-shader/hlsl: Ignore packoffset() contents for SM1. vkd3d-shader/hlsl: Don't allow manual and automatic cbuffer offset packing. vkd3d-shader/hlsl: Detect overlaps in cbuffer offsets. vkd3d-shader/hlsl: Support packoffset(). vkd3d-shader/hlsl: Parse packoffset(). tests: Test packoffset(). tests: Test cbuffer element offsets. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106

4 36

[PATCH v5 0/2] MR1746: setupapi: Use MultiByteToUnicode and UnicodeToMultiByte instead of reimplementing them.
by Alex Henrie (＠alexhenrie) 02 Mar '23

02 Mar '23

-- v5: setupapi: Use MultiByteToUnicode and UnicodeToMultiByte instead of reimplementing them. setupapi: Handle NULL in string allocation functions and add tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/1746

2 2

[PATCH 0/5] MR2309: ddraw: SetSurfaceDesc() refactoring, part 1.
by Zebediah Figura (＠zfigura) 02 Mar '23

02 Mar '23

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

4 7

[PATCH 0/5] MR2310: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) 02 Mar '23

02 Mar '23

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2310

4 7

[PATCH 0/1] MR2260: wined3d: Initialise GLSL outputs to avoid nVidia warning
by David Gow (＠sulix) 02 Mar '23

02 Mar '23

nVidia's GLSL compiler spits out a warning if a value is potentially used without being initialized. This affects many of wined3d's GLSL shaders, as either some element of the (e.g.) vs_out array are not initialized, or individual vector components remain unwritten to. As a quick way of working around this, initialize all vs_out, gs_out, and temporary Rn registers to vec4(0,0,0,0). This gets rid of all of the warnings in the cases I tried. (A more complete solution would probably track if we're initialising these, and only add what is required. Or would just disable the warning somehow.) Some example warnings (from a shader in the 'Pharaoh: A New Era' demo): ``` 0264:fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #3: 0264:fixme:d3d_shader:print_glsl_info_log Vertex info 0264:fixme:d3d_shader:print_glsl_info_log ----------- 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[2].zw" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[5].w" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[7]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[8]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[9]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[10]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[11]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[12]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[13]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[14]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[15]" might be used before being initialized ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260

5 10

[PATCH v9 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) 02 Mar '23

02 Mar '23

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v9: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for non-indexed instancing drawing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

3 4

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Henri Verbeet (＠hverbeet) 02 Mar '23

02 Mar '23

> Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context. It wouldn't need to go through CPU memory though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26016

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 02 Mar '23

02 Mar '23

On Thu Mar 2 13:50:13 2023 +0000, **** wrote: > Marvin replied on the mailing list: > ``` > Hi, > It looks like your patch introduced the new failures shown below. > Please investigate and fix them before resubmitting your patch. > If they are not new, fixing them anyway would help a lot. Otherwise > please ask for the known failures list to be updated. > The tests also ran into some preexisting test failures. If you know how > to fix them that would be helpful. See the TestBot job for the details: > The full results can be found at: > https://testbot.winehq.org/JobDetails.pl?Key=130177 > Your paranoid android. > === debian11 (32 bit report) === > dinput: > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected FFFFFFFF > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 00000002 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 0000000A > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected FFFFFFFF > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 0000000B > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > device8.c:496: Test failed: WaitForSingleObject returned 0x102 > device8.c:500: Test failed: WaitForSingleObject returned 0x102 > device8.c:520: Test failed: got data size 0, expected 1 > device8.c:521: Test failed: got action uAppData 0046BAAF, expected 00000002 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:531: Test failed: WaitForSingleObject returned 0x102 > device8.c:535: Test failed: WaitForSingleObject returned 0x102 > device8.c:551: Test failed: GetDeviceData returned 0 > device8.c:555: Test failed: got data_size 0, expected 1 > ``` These seem unrelated to the changes in this MR, rebasing on latest master and trying again... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26010

1 0

[PATCH 0/2] MR2313: shlwapi/tests: Fix the date formatting tests when the locale does not match the code page.
by Francois Gouget (＠fgouget) 02 Mar '23

02 Mar '23

In particular, February dates contain an e-acute in French, the representation of which depends on the code page being used, which in SHFormatDateTimeA() is CP_ACP. Also there are only three months that triggered this bug in French: February, August and December. So also make sure to test this issue year round. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2313

2 2

[PATCH 0/1] MR2311: include: Add more Windows.Foundation.Numerics type declarations.
by Jacek Caban (＠jacek) 02 Mar '23

02 Mar '23

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

3 4

[PATCH 0/1] MR988: dmloader/tests: Mark tests failing randomly on Windows as flaky.
by Francois Gouget (＠fgouget) 02 Mar '23

02 Mar '23

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

3 6

[PATCH 0/1] MR1138: gitlab: Add winetest checksums to the build artifacts.
by Francois Gouget (＠fgouget) 02 Mar '23

02 Mar '23

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

3 5

[PATCH v3 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 02 Mar '23

02 Mar '23

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information. -- v3: winewayland.drv: Introduce wayland_mutex. winewayland.drv: Initialize basic per-thread Wayland instance. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 9

[PATCH v2 0/5] MR1543: mmdevapi: Handle process_attach, process_detach and test_connect UNIX driver functions
by Davide Beatrici (＠davidebeatrici) 02 Mar '23

02 Mar '23

The goal is to eventually move all interfaces from each driver's `mmdevdrv.c` into `mmdevapi`. -- v2: wine{alsa,coreaudio,oss,pulse}: Move test_connect handling into mmdevapi. winepulse: Move process_attach and process_detach handling into mmdevapi. mmdevapi: Query MemoryWineUnixFuncs virtual memory and store the resulting handle. wine{alsa,coreaudio,oss,pulse}: Return STATUS_NOT_IMPLEMENTED for unused unixlib functions. include: Add missing "winternl.h" include to unixlib.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/1543

3 11

[PATCH v8 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) 02 Mar '23

02 Mar '23

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v8: d3d9: Always draw only a single instance for non-indexed draws. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

2 2

[PATCH v7 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) 02 Mar '23

02 Mar '23

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v7: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for non-indexed instancing drawing. https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

2 2

[PATCH v2 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 02 Mar '23

02 Mar '23

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information. -- v2: winewayland.drv: Introduce wayland_mutex. winewayland.drv: Initialize basic per-thread Wayland instance. winewayland.drv: Add stub for per-thread data. winewayland.drv: Perform basic per-process Wayland initialization. winewayland.drv: Add initial unixlib stub. winewayland.drv: Add initial driver stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 16

Re: [PATCH v2 0/3] MR2304: widl: Add parameterized signatures for more basic types.
by Mohamad Al-Jaf (＠maljaf) 02 Mar '23

02 Mar '23

On Wed Mar 1 08:06:29 2023 +0000, Huw Davies wrote: > @rbernon, note that you should explicitly approve this as it contains > commits from another author. I see, yeah, I tried to add the correct strings to the types, but couldn't find anything on array. The others were pretty straightforward. Also, the build error was misleading and I think it'd be helpful to add the equivalent of `TRACE` in widl. The existing debug parameters were not helpful. Thanks for the link, good info. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2304#note_25975

1 0

Re: [PATCH v7 0/2] MR2044: ntoskrnl.exe: Implement acquiring and releasing guarded mutexes
by Etaash Mathamsetty (＠etaash.mathamsetty) 02 Mar '23

02 Mar '23

tests failing for unrelated reasons -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2044#note_25966

1 0

[PATCH v6 0/2] MR2282: d3d9: Disable instancing for not-indexed drawing
by Illia Polishchuk (＠illia.a.polishchuk) 01 Mar '23

01 Mar '23

d3d9 does not do instancing for not-indexed draw calls on Windows Original issue in DXVK repo: https://github.com/doitsujin/dxvk/issues/3157 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54570 -- v6: d3d9: Always draw only a single instance for non-indexed draws. d3d9/tests: Add test for not-indexed instancing drawing https://gitlab.winehq.org/wine/wine/-/merge_requests/2282

3 9

[PATCH v2 0/2] MR2302: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile().
by w-flo (＠w-flo) 01 Mar '23

01 Mar '23

ZusiDisplay sometimes loads the same font file into two different PrivateFontCollections using two threads, so there is a race condition when the file is opened without the FILE_SHARE_READ sharing mode. The second call to GdipPrivateAddFontFile() might fail if the first one hasn't closed the file handle yet. -- v2: gdiplus: Use FILE_SHARE_READ in GdipPrivateAddFontFile(). gdiplus/tests: Test for GdipPrivateAddFontFile() sharing violation. https://gitlab.winehq.org/wine/wine/-/merge_requests/2302

4 9

Re: [PATCH v2 0/5] MR2256: wined3d: move stubs out of state tables - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v7 0/8] MR2098: mshtml: Implement synchronous XMLHttpRequests. - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v3 0/2] MR2308: mfreadwrite/reader: Release device manager in source_reader_release. - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v2 0/1] MR2307: dlls/dwrite: Pass correct font key when adding glyph to cache. - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v5 0/1] MR2033: ntoskrnl: Add ExGetPreviousMode and test. - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v5 0/1] MR2046: server: Annotate allocation functions with __WINE_(ALLOC_SIZE|DEALLOC|MALLOC). - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

Re: [PATCH v2 0/3] MR2304: widl: Add parameterized signatures for more basic types. - approved
by Alexandre Julliard (＠julliard) 01 Mar '23

01 Mar '23

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

1 0

[PATCH v2 0/3] MR2274: ntdll: Add source file and line to debug traces.
by Rémi Bernon (＠rbernon) 01 Mar '23

01 Mar '23

-- v2: ntdll: Add return address information in __wine_debug_context. ntdll: Add file and line information in __wine_debug_context. ntdll: Introduce struct __wine_debug_context for extensible debug info. https://gitlab.winehq.org/wine/wine/-/merge_requests/2274

3 7

[PATCH 0/6] MR2303: uiautomationcore: Implement a few COM UI Automation condition interfaces.
by Connor McAdams (＠cmcadams) 01 Mar '23

01 Mar '23

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

3 11

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Paul Gofman (＠gofman) 01 Mar '23

01 Mar '23

Do you see any other way out of this? I mean specifically the case when an app sets GL pixel format itself on a window. I was thinking about whether it is possible to make setpixelformat quicker in winex11 instead and I don't see how. If keeping direct presentation it will require some X window reconfigure which is not going to be anywhere quick. Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context. The other different (but a bit complicated) way would be to: - count statistics of GL pixel format switches; - introduce switching back from backup context and switch between resetting pixel format or switching to backup context or back based on that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25906

1 0

[PATCH 0/5] MR2256: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) 01 Mar '23

01 Mar '23

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2256

4 7

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Zebediah Figura (＠zfigura) 01 Mar '23

01 Mar '23

> It's probably worth pointing out that this has quite some potential for causing regressions in performance. swapchain_blit_gdi() is not fast, and ideally we'd work on reducing the number of cases where it's needed. The fundamental idea here is that setting and restoring the pixel format is even worse, since we always need to recreate the GLX drawable when we do that. And as far as I can tell, this patch doesn't force GDI blitting in any other circumstance. That said, what about Mac? I don't really know what's going on here; set_pixel_format() seems to be cheap, but I can't easily tell if that's because it really is cheap, or because setting the pixel format just doesn't work. Either way this patch is questionable as-is. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_25904

1 0

[PATCH v8 0/1] MR2153: win32u: Invalidate all cached keys after input.
by Henry Goffin (＠AMZN-hgoffin) 01 Mar '23

01 Mar '23

This patch addresses an issue in Second Life and potentially other multi-threaded applications which process WM_KEYDOWN in one thread and then verify that the key is "still down" with GetAsyncKeyState from another thread. Wine uses a per-thread key cache, resulting in inconsistent views of key status. Caches are now invalidated when an input event is injected by the driver or via SendInput. -- v8: win32u: Invalidate all cached keys after input. https://gitlab.winehq.org/wine/wine/-/merge_requests/2153

2 2

Re: [PATCH v7 0/1] MR2153: win32u: Invalidate all cached keys after input.
by Zebediah Figura (＠zfigura) 01 Mar '23

01 Mar '23

This is missing the change to protocol.def. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2153#note_25897

1 0

[PATCH v6 0/8] MR2098: mshtml: Implement synchronous XMLHttpRequests.
by Gabriel Ivăncescu (＠insn) 01 Mar '23

01 Mar '23

wine-gecko does actually support synchronous XMLHttpRequests, even if they are deprecated, but unfortunately it is very broken compared to IE or all the other major browsers (more details [here](https://bugzilla.mozilla.org/show_bug.cgi?id=697151)). Thankfully, it still provides us with the event message loop, which is enough to fix it on mshtml side and act like IE. For sync XHRs, send() is supposed to block all script code, except for notifications sent to the sync XHR. This is because when send() blocks, no other piece of code in the script should execute other than the sync XHR handlers. Unfortunately, that's not the case in Gecko's broken implementation, which can execute handlers as if they were APCs while it's "blocked" in send(). Note that it doesn't actually block, though, because we still process the message loop (non-event related tasks such as navigation, paints, and other stuff), and that's normal. Gecko doesn't block everything related to script events, only some things on the document and timers, but that's far from enough and not even enough for our purposes since we use our own timer tasks. And not even message events are blocked, even though we *also* use our own message event dispatchers (but it doesn't block Gecko ones either). So what we have to do is we need to track all the timers and events dispatched that result in script handlers being executed, while "blocking" inside of a sync XHR send(), and queue them up to defer them to be dispatched later, after send() unblocks. But this is easier said that done. There are many corner cases to consider here, for example: * Events dispatched *synchronously* from within a sync XHR handler or other piece of code called from it. * Nested sync XHR send() calls (called during handler of another sync XHR). * Async XHRs having their events dispatched during a blocking sync XHR send() are complicated. `readyStateChange` for example needs to have the async XHR's readyState at the time it was sent, **not** at the time it was actually dispatched, since we're going to delay it and dispatch it later. It's similar with other XHR states, such as responseText (which can be partial). * Aborts of async XHRs during such handlers. These patches hopefully should address all the issues and, on a high level, work like this: * Track the `readyState` and `responseText` length manually, so we can override / force them to specific values. * "Snapshot" the async XHR at the time we encounter an event for it, and queue this event with such information. When later dispatching this event (after being deferred), we temporarily set the state of the async XHR to the snapshot. * To deal with nested event dispatches, keep track of a "dispatch depth" (everytime we dispatch an event we increase the depth, and when it returns we decrease it). * For sync XHRs, we note the depth when send() is called, and defer events at that depth, since they're dispatched during the "blocked" message loop and need to be delayed (except for sync XHR events, which is a special case since it must be dispatched synchronously). When it returns, we restore the previous blocking depth. -- v6: mshtml: Send all readystatechange events for synchronous XHRs in IE9 mshtml: Implement synchronous XMLHttpRequest. mshtml: Add separate task list for tasks dispatching events. mshtml: Track readyState in XHRs and report it manually. mshtml: Register all event handlers when creating the XMLHttpRequest. mshtml: Pass optional args to XMLHttpRequest.open() correctly. mshtml: Free the task after the destructor. mshtml: Use proper types for readystate_locked and readystate_pending. https://gitlab.winehq.org/wine/wine/-/merge_requests/2098

4 12

2025

2024

2023

2022

wine-gitlab