- Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) Nov. 13, 2025

Nov. 13, 2025

> As it is right now, with all envars removed, then XDG_DATA_DIRS is always removed as well, right? It's remapped to WINE_HOST_XDG_DATA_DIRS so that Wine can access it. But of course if it's large that doesn't help, hence the possibility for the user to define it themselves to a more reasonable value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121894

1 0

[PATCH 0/6] MR9453: xactengine3/tests: Add many more tests.
by Elizabeth Figura (＠zfigura) Nov. 13, 2025

Nov. 13, 2025

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

2 6

[PATCH 0/8] MR9294: mf/tests: Fix test failures in Windows.
by Conor McCarthy (＠cmccarthy) Nov. 13, 2025

Nov. 13, 2025

The last commit in particular fixes the crashes in Windows. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9294

3 9

[PATCH v2 0/5] MR9451: d2d1: Add property data for the 3D Perspective Transform effect.
by Nikolay Sivov (＠nsivov) Nov. 13, 2025

Nov. 13, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: d2d1: Add property data for the Color Matrix effect. d2d1: Add property data for the Crop effect. d2d1: Do not use property getter for standalone properties. d2d1: Add property data for the Composite effect. d2d1: Add property data for the 3D Perspective Transform effect. https://gitlab.winehq.org/wine/wine/-/merge_requests/9451

2 5

[PATCH 0/6] MR9452: winevulkan: Introduce instance and device extension bitfields.
by Rémi Bernon Nov. 13, 2025

Nov. 13, 2025

Moving the client specific extension filtering to the PE side, and tracking supported and enabled extension lists as bitfields. This makes it possible to store the client/host supported/enabled extension list on the vulkan objects, making it easily available and shareable with win32u. The goal is to then move the Vulkan device and instance wrappers to win32u, to benefit from their infrastructure (function pointer loading, etc), but also because D3DKMT will have to create Vulkan objects on its own for timeline and shared D3D12 fences, and allowing it to create Vulkan wrapped objects will make things easier than having a mix of host handles (in the D3DKMT stack) and wrapped handles (in the Vulkan stack). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9452

1 6

[PATCH v4 0/8] MR9438: dsound: Various
by Matteo Bruni (＠Mystral) Nov. 13, 2025

Nov. 13, 2025

Some small dsound fixes I came up with while looking into Wine bug 30639 -- v4: dsound/tests: Mark weird DescriptionW propset failure on the AMD testbot machine. dsound: Return the mmdevapi endpoint ID as module. dsound: Fill all the DSPROPERTY_DIRECTSOUNDDEVICE_ENUMERATE data. dsound: Check data size in propset methods. dsound: Consistently trace locked byte count as an unsigned value. dsound: Print time as an unsigned value. dsound: Simplify check in DSOUND_RecalcFormat(). dsound/tests: Get rid of a crashing test. https://gitlab.winehq.org/wine/wine/-/merge_requests/9438

3 9

[PATCH 0/1] MR9405: dsound: Avoid use after free in DSOUND_WaveFormat (ASan).
by Bernhard Übelacker Nov. 13, 2025

Nov. 13, 2025

Contents of `mixwfe` is copied into `wfe` and `mixwfe` is freed by `CoTaskMemFree`. But then `mixwfe` is used again. This patch uses the values from `wfe`. [This is a testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=160647) [ASan details found by gitlab-CI](https://gitlab.winehq.org/bernhardu/wine/-/jobs/205270#L530) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9405

3 4

[PATCH v2 0/1] MR9439: mf: Return E_NOINTERFACE if service is missing
by Aric Stewart (＠aricstewart) Nov. 13, 2025

Nov. 13, 2025

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> -- v2: mf: Return E_NOINTERFACE if service is missing https://gitlab.winehq.org/wine/wine/-/merge_requests/9439

3 3

[PATCH 0/4] MR9443: comctl32/tab: Add a helper to draw the border background.
by Zhiyi Zhang (＠zhiyi) Nov. 13, 2025

Nov. 13, 2025

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

3 5

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 13, 2025

Nov. 13, 2025

As it is right now, with _all_ envars removed, then `XDG_DATA_DIRS` is always removed as well, right? Then, what about first sorting for size, and then doing a stable sort on whether it's a special envar? (So that while special envars like `XDG_DATA_DIRS` become high priority, the big envars that aren't special remains at the lowest priority.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121874

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) Nov. 13, 2025

Nov. 13, 2025

Esme Povirk (@madewokherd) commented about dlls/ole32/filelockbytes.c: > > static HRESULT WINAPI FileLockBytesImpl_Flush(ILockBytes* iface) > { > + FileLockBytesImpl *This = impl_from_ILockBytes(iface); > + > + TRACE("(%p)\n", iface); > + > + /* verify a sane environment */ > + if (!This) return E_FAIL; > + > + if (!FlushFileBuffers(This->hfile)) > + return STG_E_WRITEFAULT; According to MSDN, this will fail if the file isn't opened with write permission (which, I think, shows that the tests aren't testing what you want). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121872

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) Nov. 13, 2025

Nov. 13, 2025

Esme Povirk (@madewokherd) commented about dlls/ole32/tests/storage32.c: > DeleteTestLockBytes(lockbytes); > } > > +static void test_lockbytes_flush_operation(void) > +{ > + static const WCHAR stmname[] = { 'T','E','S','T','S','T','R','E','A','M',0 }; > + TestLockBytes* lockbytes; > + HRESULT hr; > + IStorage* stg; > + IStream* stm; > + > + /* Test 1: Normal flush operation */ > + CreateTestLockBytes(&lockbytes); I don't think this tests what you want to test. `CreateTestLockBytes` uses the `TestLockBytes_Vtbl` implementation defined in the test itself. So calling the implementation of Flush defined in the test file doesn't really test anything about Windows. In fact, there doesn't seem to be a way to get the `ILockBytes` implementation from `filelockbytes.c` directly. I think that means that only the application-observable behavior matters. So, I think all we need the test to do is call `IStorage_Flush` on a storage file (and I think it needs to be a file, not an in-memory lockbytes) that was opened read-only. If that succeeds, then our internal ILockBytes should succeed in that case. If not, it'll depend on the behavior of `IStorage_Flush` in other situations. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121871

1 0

Re: [PATCH v3 0/1] MR9431: ole32: implement proper file flushing in FileLockBytes
by Esme Povirk (＠madewokherd) Nov. 13, 2025

Nov. 13, 2025

Esme Povirk (@madewokherd) commented about dlls/ole32/tests/storage32.c: > DeleteTestLockBytes(lockbytes); > } > > +static void test_lockbytes_flush_operation(void) > +{ > + static const WCHAR stmname[] = { 'T','E','S','T','S','T','R','E','A','M',0 }; I think we can just use `L"TESTSTREAM"` now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_121870

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) Nov. 13, 2025

Nov. 13, 2025

As has been pointed out, you can't decide which variables are important based on their size. Particularly since XDG_DATA_DIRS is one of the offenders, and it's used in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121869

1 0

Re: [PATCH v5 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Esme Povirk (＠madewokherd) Nov. 13, 2025

Nov. 13, 2025

Esme Povirk (@madewokherd) commented about dlls/winex11.drv/clipboard.c: > + XSelectInput( display, win, attrs.your_event_mask | PropertyChangeMask ); > + > + /* Generate a PropertyNotify event to get server time */ > + XChangeProperty( display, win, x11drv_atom(__wine_timestamp_prop), XA_INTEGER, 8, PropModeReplace, NULL, 0 ); > + XSync( display, False ); > + > + /* Wait for the PropertyNotify event */ > + for (i = 0; i < SELECTION_RETRIES; i++) > + { > + if(XCheckIfEvent( display, &event, timestamp_predicate, (XPointer)win )) > + { > + timestamp = event.xproperty.time; > + break; > + } > + selection_sleep(); > + } I'm not sure how we should handle the case where we don't see the event we're expecting. It's unclear to me from the documentation whether `XSync` should guarantee that we see the event (no other client is involved so.. maybe?). And I don't know whether we need a timeout or not, since we should get the event as long as the server is functioning properly and no one destroys the selection window in the small amount of time between creating it and calling this. It's also unclear to me whether we need to temporarily change our event selection, or whether we could just do it at window creation time. Since I'm not actually the maintainer in this area and am only reviewing out of interest anyway, I think it's best for me to just bring these up as a unresolved questions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121867

1 0

Re: [PATCH v5 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Esme Povirk (＠madewokherd) Nov. 13, 2025

Nov. 13, 2025

Esme Povirk (@madewokherd) commented about dlls/winex11.drv/x11drv_main.c: > "text/plain", > "text/rtf", > "text/richtext", > - "text/uri-list" > + "text/uri-list", > + "__wine_timestamp_prop" I think these are supposed to be sorted? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121866

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 13, 2025

Nov. 13, 2025

I'm fine on having a workaround, but not if it's too invasive, which IMO right now it is. So, I'm fine with only removing the biggest envars (which are much less likely to be important), like !6140 does It's just only around 40 lines added, and it has no performance impact if the envars block is small, so I don't really see why not that instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121864

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) Nov. 13, 2025

Nov. 13, 2025

Well, I don't think the warning makes any difference, so basically your solution is to do nothing and ignore the problem. That's certainly an option, but I was hoping we could do better... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121863

1 0

[PATCH 0/2] MR9451: d2d1: Add property data for the 3D Perspective Transform effect.
by Nikolay Sivov (＠nsivov) Nov. 13, 2025

Nov. 13, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9451

2 2

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 13, 2025

Nov. 13, 2025

> there would be a clear message pointing out the issue I don't want to accuse you of https://xkcd.com/2501/, but the average user doesn't launch Wine from the terminal, and may not know what environment variables are (if they blindly follow guides, they won't understand that the log is related to their issue). > as opposed to an obscure crash [it actually isn't a crash, it's an error message] Which is what the logs of my MR are about (which I could make more specific so that they explicitly specify EA app). So, back to the beginning: better to not change anything and add a logs that explain an old problem, or to add a workaround and add logs to explain new problems created by it? Due to all the reasoning I already gave, I'd prefer the former. Now, I know you may accuse me of https://xkcd.com/1172/, but > To me it seems like an improvement. let's consider the effect of the change to the population of users who have a large environment block: - They don't use EA App -> The change may only be negative - They do use EA App -> The change is positive... but still has the negative side effects (so it's a sidegrade, not an upgrade) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121859

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) Nov. 13, 2025

Nov. 13, 2025

I'm not convinced that it would break all that much, and if it does, there would be a clear message pointing out the issue, as opposed to an obscure crash. To me it seems like an improvement. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121853

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 13, 2025

Nov. 13, 2025

I'm aware that this is a lose-lose scenario, due to EA not fixing their issue on the end, since it's either: - Workaround the issue, but cause breaking changes outside of it - Do nothing, but EA app remains not working without manual intervention And IMO, the second choice is better. And many things can still be done, like having better documentation about the issue. For instance, Wine's wiki has a [Known Issues page](https://gitlab.winehq.org/wine/wine/-/wikis/Known-Issues), where this definitely belongs. Or maybe it could be added to the Arch Wiki as well. Or [make changes to systems that set huge environment variables to be less wasteful](https://github.com/NixOS/nixpkgs/pull/451031) (which is nice even outside of this). (And if there is still intention of doing a workaround for the issue... would it be possible to unset environment variables only if the executable `EADesktop.exe` is launched, to minimize the impact of breaking changes elsewhere?) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121852

1 0

[PATCH 0/3] MR9427: combobox: Adjust MEASUREITEMSTRUCT.itemHeight by 2 instead of 6.
by Paul Gofman (＠gofman) Nov. 13, 2025

Nov. 13, 2025

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

3 6

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) Nov. 13, 2025

Nov. 13, 2025

> It's a change that breaks configurations for little gain Obviously the gain is that a commonly-used app no longer crashes. How would you suggest to achieve that otherwise? Printing a warning may make it easier to determine the cause of the crash, but it doesn't improve the user's experience. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121847

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) Nov. 13, 2025

Nov. 13, 2025

Your change would be nice even with the warning I'm proposing, considering that it helps with trimming the environment block. I don't understand why it should still not import the environment block at all. I'll reiterate why I think conditionally not importing it is a bad idea: - If modern Windows allows unlimited environment block size, Wine should allow it too - It's a change that breaks configurations for little gain - Because it's conditional, documentation becomes much more cumbersome. Think of all the resources online saying something like "set this environment variable", which will now need to be updated with "unless your environment block is too big, you'll also have to trim the environment block too" (which is more complicated than this sentence). And that's assuming it gets updated at all. Add in users why follow guides and then don't notice the log (either because they don't use the terminal or because they are newbies and can't see that this log is related to why the guide is not working), and you get a mess. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121846

1 0