January 2026 - Wine-Devel - list.winehq.org

Re: FOSDEM

by David Kahurani

On Tue, 27 Jan 2026, 18:40 Huw Davies via Wine-devel, < wine-devel(a)list.winehq.org> wrote: > Hi folks, > > Once again, many CodeWeavers folks will be in Brussels this weekend > attending FOSDEM. If anybody else is around please feel free to either > drop me an email or simply turn up to the BrewDog on Saturday evening > from 17:00. Many of us will be in Brussels Thursday, Friday and Sunday > evenings too, but our exact location is less certain; if you let me know > you’re interested, I can try to keep you in the loop. > Ty. Finally I am online! > Sorry for the late notice (again)! > > Huw > >

Jan. 27, 2026

FOSDEM

by Huw Davies

Hi folks, Once again, many CodeWeavers folks will be in Brussels this weekend attending FOSDEM. If anybody else is around please feel free to either drop me an email or simply turn up to the BrewDog on Saturday evening from 17:00. Many of us will be in Brussels Thursday, Friday and Sunday evenings too, but our exact location is less certain; if you let me know you’re interested, I can try to keep you in the loop. Sorry for the late notice (again)! Huw

Jan. 27, 2026

Wine staging 11.1 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download For the complete wine release notes https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0 Summary since last release * Rebased to current wine 11.1 (254 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [47015] msxml3: Photoshop CC2019 login screen content does not render without native msxml3 Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 24, 2026

Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by Hoshino Lina

On 1/21/26 6:02 PM, Rémi Bernon via Wine-devel wrote: > Hi Lina, > > On 1/17/26 10:35, Hoshino Lina via Wine-devel wrote: >> Hi! >> >> I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a >> windows-only frame-sharing technology widely used for video-streaming >> and mixing apps. It allows one app to send video to another, much like >> JACK does for audio on Linux (and now PipeWire for both A/V). For >> example, the majority of the VTubing/streaming world relies on Spout2 >> to stream avatars and graphics on screen. >> >> To make this work, the bridge needs to use unixlib to do the bridging >> between the Windows and Linux worlds. I got it to build outside the >> Wine source tree by using just a few headers outside the public wine >> headers (unixlib.h, server.h, server_protocol.h). Originally I >> intended to distribute it as a simple installable that users could >> throw into their WINEPREFIX, but it turned out that for unixlib to >> work, the exe needs to be marked as builtin and distributed as a Wine >> builtin exe in wine/ x86_64-windows with the .so file in the companion >> x86_64-unix directory. >> >> - Would it make sense for Wine to change its unixlib loading code to >> work with non-builtin binaries, such as looking for the .so in the >> same directory as the .dll/.exe? > > Regarding supporting unixlibs for non-builtin modules, it's probably a > up to Alexandre whether he thinks it's future proof and stable enough. > > I believe we are now distributing wine/unixlib.h as part of public Wine > headers, so it seems to me that this is indeed the directions we are > taking. > > It's perhaps then just a matter of time before it's officially > supported, or just a matter of someone proposing the changes to make it > work. Oh, I'd totally missed that! I just checked and indeed in the Wine 11 packages, unixlib.h is there so I don't have to ship it myself any more. I think at that point it just becomes a matter of changing the search path for .so files a bit, so WINEDLLPATH is not necessary. > > >> - Otherwise, would upstream Wine be interested in merging this >> feature? The main dependencies are PipeWire and libfunnel [3]. >> >> The app does rely on some Wine/DXVK internals (unixlib, >> KeUserDispatchCallback, \??\SharedGpuResource, >> ProcessWineMakeProcessSystem) but it's not strictly necessary for >> those to remain stable across all future Wine releases, as making >> updates to stay compatible is not a major issue. >> > > Please note that the Proton shared memory resource implementation (\?? > \SharedGpuResource) is now deprecated, it will be removed in future > Proton releases and replaced with Wine upstream implementation through > the D3DKMT API, which DXVK also supports now. Yeah, someone else also pointed this out to me the other day. I'll take a look and make sure I support both mechanisms. > >> At this time I plan to distribute it as a "patch" that can be applied >> to Proton installations (which just drops in the exe/so and adds it to >> wine.ini). Another option is using WINEDLLPATH, which should work for >> regular Wine (this one is problematic on Proton since the Proton >> launcher unconditionally clobbers that environment variable). >> > > Fwiw, we can consider preserving the variable if set externally, it's > not really intentionally overwritten. Feel free to open a Proton MR. Thanks! I've opened a PR here: https://github.com/ValveSoftware/Proton/pull/9420 ~~ Lina

Jan. 21, 2026

Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by Hoshino Lina

~~ Lina On 1/21/26 7:52 PM, Davide Beatrici via Wine-devel wrote: > On 2026-01-19 19:18, Michael Ost via Wine-devel wrote: > >> Hi Lina, >> >> I don't have an answer for your question (sorry), but also need to use >> a Linux library in a Windows app that will run under Wine. In my case >> I want to use Linux JACK in a Windows/Wine application. I'm glad to >> hear that unixlib is working for you. I'd heard about it, sounds like >> it will do the trick, but don't know how to use it. Have you come >> across any examples or docs for how to work with it? >> >> We could DM this side conversation if that makes more sense: >> imichaelost(a)gmail.com. >> >> Thanks! > > Hi Michael, > > A few years ago I worked on a PipeWire driver for Wine, but never found > the time to complete it after refactoring mmdevapi and friends. > > The idea is that Windows-side you shouldn't need anything other than > WASAPI, because: > > - IAudioClient3 allows to open low-latency streams in shared mode and we > now support it. > - All streams that are opened by the application show up Linux-side, > allowing you to route them as you like. > > Feel free to contact me in private. It's been a long time, but last time I poked around low-latency audio in wine, I used this: https://github.com/wineasio/wineasio It's similar to spout2pw in that it also uses the companion .so library (and needs to be installed into the wine prefix), though it doesn't use the unixlib.h mechanism but rather I think it builds all the actual code using the unix compiler and just creates a fake module for the dll (?) (I'm still a bit confused as to how wine/unix interop works myself at the binary/ABI level, to be honest). > > On 2026-01-17 10:35, Hoshino Lina via Wine-devel wrote: > >> Hi! >> >> I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a >> windows-only frame-sharing technology widely used for video-streaming >> and mixing apps. It allows one app to send video to another, much like >> JACK does for audio on Linux (and now PipeWire for both A/V). For >> example, the majority of the VTubing/streaming world relies on Spout2 >> to stream avatars and graphics on screen. > > Hi Lina, > > Let's also link the OBS plugin discussion, for reference: > https://github.com/Off-World-Live/obs-spout2-plugin/issues/83 > > In my opinion we should support bridging shared memory areas between > Windows and UNIX. > This would also allow games to interact with tools running outside of > Wine, such as Mumble's Link plugin. > > For Spout2 it would be "just" a matter of reading the shared memory area > on UNIX and sending the video into PipeWire. > > What do you think? This is already how the bridge works, except it cannot be shared memory because GPU textures are not shared (CPU) memory, they are dma-bufs. The way it works is it opens the shared GPU texture handle wine-side, pokes at wine/proton internals to get the corresponding UNIX file descriptor for it, and then uses it on the UNIX side. I recently published the bridge here: https://github.com/hoshinolina/spout2pw And the corresponding OBS plugin (which is generic and not specific to anything wine/spout2) here: https://github.com/hoshinolina/obs-pwvideo (Note that this is all very rough around the edges)

Jan. 21, 2026

Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by Davide Beatrici

On 2026-01-19 19:18, Michael Ost via Wine-devel wrote: > Hi Lina, > > I don't have an answer for your question (sorry), but also need to use > a Linux library in a Windows app that will run under Wine. In my case I > want to use Linux JACK in a Windows/Wine application. I'm glad to hear > that unixlib is working for you. I'd heard about it, sounds like it > will do the trick, but don't know how to use it. Have you come across > any examples or docs for how to work with it? > > We could DM this side conversation if that makes more sense: > imichaelost(a)gmail.com. > > Thanks! Hi Michael, A few years ago I worked on a PipeWire driver for Wine, but never found the time to complete it after refactoring mmdevapi and friends. The idea is that Windows-side you shouldn't need anything other than WASAPI, because: - IAudioClient3 allows to open low-latency streams in shared mode and we now support it. - All streams that are opened by the application show up Linux-side, allowing you to route them as you like. Feel free to contact me in private. On 2026-01-17 10:35, Hoshino Lina via Wine-devel wrote: > Hi! > > I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a > windows-only frame-sharing technology widely used for video-streaming > and mixing apps. It allows one app to send video to another, much like > JACK does for audio on Linux (and now PipeWire for both A/V). For > example, the majority of the VTubing/streaming world relies on Spout2 > to stream avatars and graphics on screen. Hi Lina, Let's also link the OBS plugin discussion, for reference: https://github.com/Off-World-Live/obs-spout2-plugin/issues/83 In my opinion we should support bridging shared memory areas between Windows and UNIX. This would also allow games to interact with tools running outside of Wine, such as Mumble's Link plugin. For Spout2 it would be "just" a matter of reading the shared memory area on UNIX and sending the video into PipeWire. What do you think?

Jan. 21, 2026

Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by Rémi Bernon

Hi Lina, On 1/17/26 10:35, Hoshino Lina via Wine-devel wrote: > Hi! > > I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a > windows-only frame-sharing technology widely used for video-streaming > and mixing apps. It allows one app to send video to another, much like > JACK does for audio on Linux (and now PipeWire for both A/V). For > example, the majority of the VTubing/streaming world relies on Spout2 to > stream avatars and graphics on screen. > > To make this work, the bridge needs to use unixlib to do the bridging > between the Windows and Linux worlds. I got it to build outside the Wine > source tree by using just a few headers outside the public wine headers > (unixlib.h, server.h, server_protocol.h). Originally I intended to > distribute it as a simple installable that users could throw into their > WINEPREFIX, but it turned out that for unixlib to work, the exe needs to > be marked as builtin and distributed as a Wine builtin exe in wine/ > x86_64-windows with the .so file in the companion x86_64-unix directory. > > - Would it make sense for Wine to change its unixlib loading code to > work with non-builtin binaries, such as looking for the .so in the same > directory as the .dll/.exe? Regarding supporting unixlibs for non-builtin modules, it's probably a up to Alexandre whether he thinks it's future proof and stable enough. I believe we are now distributing wine/unixlib.h as part of public Wine headers, so it seems to me that this is indeed the directions we are taking. It's perhaps then just a matter of time before it's officially supported, or just a matter of someone proposing the changes to make it work. > - Otherwise, would upstream Wine be interested in merging this feature? > The main dependencies are PipeWire and libfunnel [3]. > > The app does rely on some Wine/DXVK internals (unixlib, > KeUserDispatchCallback, \??\SharedGpuResource, > ProcessWineMakeProcessSystem) but it's not strictly necessary for those > to remain stable across all future Wine releases, as making updates to > stay compatible is not a major issue. > Please note that the Proton shared memory resource implementation (\??\SharedGpuResource) is now deprecated, it will be removed in future Proton releases and replaced with Wine upstream implementation through the D3DKMT API, which DXVK also supports now. > At this time I plan to distribute it as a "patch" that can be applied to > Proton installations (which just drops in the exe/so and adds it to > wine.ini). Another option is using WINEDLLPATH, which should work for > regular Wine (this one is problematic on Proton since the Proton > launcher unconditionally clobbers that environment variable). > Fwiw, we can consider preserving the variable if set externally, it's not really intentionally overwritten. Feel free to open a Proton MR. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Jan. 21, 2026

How do I unsubscribe from the mailing list?

by Kirill Mosorov

Hello! How can I unsubscribe from this mailing list? :)

Jan. 21, 2026

Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by imichaelost＠gmail.com

Hi Lina, I don't have an answer for your question (sorry), but also need to use a Linux library in a Windows app that will run under Wine. In my case I want to use Linux JACK in a Windows/Wine application. I'm glad to hear that unixlib is working for you. I'd heard about it, sounds like it will do the trick, but don't know how to use it. Have you come across any examples or docs for how to work with it? We could DM this side conversation if that makes more sense: imichaelost(a)gmail.com. Thanks!

Jan. 21, 2026

UnixLib

by imichaelost＠gmail.com

Jan. 21, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Austin English

On Sun, Jan 18, 2026 at 2:26 AM Dmitry Timoshkov via Wine-devel <wine-devel(a)list.winehq.org> wrote: > > Elizabeth Figura via Wine-devel <wine-devel(a)list.winehq.org> wrote: > > > > On 1/17/2026 1:26 PM, Dmitry Timoshkov via Wine-devel wrote: > > > > Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > > > > > > > >> It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? > > > >> > > > >> FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. > > > > While the archives seem to be there they can't be downloaded. For example > > > > from https://www.winehq.org/pipermail/wine-devel an attempt try to download > > > > archive for August 2022 fails: > > > > https://www.winehq.org/pipermail/wine-devel/2022-August.txt.gz > > > > While it's only 35Kb in size it stucks at 14.7 Kb for me. > > > > Archives for gitlab, for instance > > > > https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/2022… > > > > can't be even browsed, and timeout for me. Do they work for you? > > > > Both of these links work fine for me (and I did test outside of any CW networks, just in case). > > Many thanks for the assistance! > > Do the following links also work for you? They hang for me after initial small chunk: > > https://www.winehq.org/pipermail/wine-devel/2022-June.txt.gz > https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/expo… > > -- > Dmitry. Both work for me: $ du -sh Downloads/*gz 4.2M Downloads/2022-June.txt.gz 3.0M Downloads/wine-gitlab(a)winehq.org-2024-09.mbox.gz -- -Austin GPG: 267B CC1F 053F 0749 (expires 2026-03-03)

Jan. 18, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Dmitry Timoshkov

Elizabeth Figura via Wine-devel <wine-devel(a)list.winehq.org> wrote: > > On 1/17/2026 1:26 PM, Dmitry Timoshkov via Wine-devel wrote: > > > Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > > > > > >> It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? > > >> > > >> FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. > > > While the archives seem to be there they can't be downloaded. For example > > > from https://www.winehq.org/pipermail/wine-devel an attempt try to download > > > archive for August 2022 fails: > > > https://www.winehq.org/pipermail/wine-devel/2022-August.txt.gz > > > While it's only 35Kb in size it stucks at 14.7 Kb for me. > > > Archives for gitlab, for instance > > > https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/2022… > > > can't be even browsed, and timeout for me. Do they work for you? > > Both of these links work fine for me (and I did test outside of any CW networks, just in case). Many thanks for the assistance! Do the following links also work for you? They hang for me after initial small chunk: https://www.winehq.org/pipermail/wine-devel/2022-June.txt.gz https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/expo… -- Dmitry.

Jan. 18, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Elizabeth Figura

On Saturday, 17 January 2026 14:20:26 CST Jeremy Newman via Wine-devel wrote: > The old pipermail archives are provided as is. If you cannot access or > download them, that is between you and your ISP. I've not had any issues > loading them myself. > > The new mailman3 list archives are here: > https://list.winehq.org/archives/list/wine-devel@list.winehq.org/ > > I've updated the old mailman3 redirects on www.winehq.org so that they > go to the correct place. We never did that after the lists moved to the > new list.winehq.org home. Works now, thank you! > On 1/17/2026 1:26 PM, Dmitry Timoshkov via Wine-devel wrote: > > Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > > > >> It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? > >> > >> FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. > > While the archives seem to be there they can't be downloaded. For example > > from https://www.winehq.org/pipermail/wine-devel an attempt try to download > > archive for August 2022 fails: > > https://www.winehq.org/pipermail/wine-devel/2022-August.txt.gz > > While it's only 35Kb in size it stucks at 14.7 Kb for me. > > Archives for gitlab, for instance > > https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/2022… > > can't be even browsed, and timeout for me. Do they work for you? Both of these links work fine for me (and I did test outside of any CW networks, just in case).

Jan. 17, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Dmitry Timoshkov

Hi Jeremy, thanks for looking at this. Jeremy Newman via Wine-devel <wine-devel(a)list.winehq.org> wrote: > The old pipermail archives are provided as is. If you cannot access or > download them, that is between you and your ISP. I've not had any issues > loading them myself. It seems that I'm not the only one who can't download archives, it looks like archive.org has the problem archiving them too since the archives are missing there. > The new mailman3 list archives are here: > https://list.winehq.org/archives/list/wine-devel@list.winehq.org/ > > I've updated the old mailman3 redirects on www.winehq.org so that they > go to the correct place. We never did that after the lists moved to the > new list.winehq.org home. Thanks. -- Dmitry.

Jan. 17, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Jeremy Newman

The old pipermail archives are provided as is. If you cannot access or download them, that is between you and your ISP. I've not had any issues loading them myself. The new mailman3 list archives are here: https://list.winehq.org/archives/list/wine-devel@list.winehq.org/ I've updated the old mailman3 redirects on www.winehq.org so that they go to the correct place. We never did that after the lists moved to the new list.winehq.org home. On 1/17/2026 1:26 PM, Dmitry Timoshkov via Wine-devel wrote: > Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > >> It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? >> >> FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. > While the archives seem to be there they can't be downloaded. For example > from https://www.winehq.org/pipermail/wine-devel an attempt try to download > archive for August 2022 fails: > https://www.winehq.org/pipermail/wine-devel/2022-August.txt.gz > While it's only 35Kb in size it stucks at 14.7 Kb for me. > Archives for gitlab, for instance > https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/2022… > can't be even browsed, and timeout for me. Do they work for you? > > -- > Dmitry. -- CodeWeavers, Inc. 🐉 Jeremy Newman ⛭ Director of IT ────────────────────────────────────────────────────── 📧 jnewman(a)codeweavers.com 🌐 https://www.codeweavers.com/about/people/jnewman

Jan. 17, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Dmitry Timoshkov

Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? > > FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. While the archives seem to be there they can't be downloaded. For example from https://www.winehq.org/pipermail/wine-devel an attempt try to download archive for August 2022 fails: https://www.winehq.org/pipermail/wine-devel/2022-August.txt.gz While it's only 35Kb in size it stucks at 14.7 Kb for me. Archives for gitlab, for instance https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/2022… can't be even browsed, and timeout for me. Do they work for you? -- Dmitry.

Jan. 17, 2026

Re: Availability of wine-devel/wine-gitlab archives

by Elizabeth Figura

On Saturday, 17 January 2026 09:15:20 CST Dmitry Timoshkov via Wine-devel wrote: > > Hi all, > > recently I tried to lookup some previously discussed things in wine-devel > archives and was surprised that neither winehq.org nor archive.org provide > something useful, all the links I tried don't work. The things get a bit > more complex due to transition from pipermail to hyperkitty and current > system. Is it possible to make old archives available again and fix access > to current wine-devel/wine-gitlab archives? It seems the archives are all still there, but the domain was changed from www.winehq.org to list.winehq.org. Perhaps we could set up some forwards? FWIW all the mailman2 (pipermail) links do still exist as a read-only archive, up until the point when we transitioned to mailman3. --Zeb

Jan. 17, 2026

Availability of wine-devel/wine-gitlab archives

by Dmitry Timoshkov

Hi all, recently I tried to lookup some previously discussed things in wine-devel archives and was surprised that neither winehq.org nor archive.org provide something useful, all the links I tried don't work. The things get a bit more complex due to transition from pipermail to hyperkitty and current system. Is it possible to make old archives available again and fix access to current wine-devel/wine-gitlab archives? Thanks. -- Dmitry.

Jan. 17, 2026

Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

by Hoshino Lina

Hi! I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a windows-only frame-sharing technology widely used for video-streaming and mixing apps. It allows one app to send video to another, much like JACK does for audio on Linux (and now PipeWire for both A/V). For example, the majority of the VTubing/streaming world relies on Spout2 to stream avatars and graphics on screen. To make this work, the bridge needs to use unixlib to do the bridging between the Windows and Linux worlds. I got it to build outside the Wine source tree by using just a few headers outside the public wine headers (unixlib.h, server.h, server_protocol.h). Originally I intended to distribute it as a simple installable that users could throw into their WINEPREFIX, but it turned out that for unixlib to work, the exe needs to be marked as builtin and distributed as a Wine builtin exe in wine/x86_64-windows with the .so file in the companion x86_64-unix directory. - Would it make sense for Wine to change its unixlib loading code to work with non-builtin binaries, such as looking for the .so in the same directory as the .dll/.exe? - Otherwise, would upstream Wine be interested in merging this feature? The main dependencies are PipeWire and libfunnel [3]. The app does rely on some Wine/DXVK internals (unixlib, KeUserDispatchCallback, \??\SharedGpuResource, ProcessWineMakeProcessSystem) but it's not strictly necessary for those to remain stable across all future Wine releases, as making updates to stay compatible is not a major issue. At this time I plan to distribute it as a "patch" that can be applied to Proton installations (which just drops in the exe/so and adds it to wine.ini). Another option is using WINEDLLPATH, which should work for regular Wine (this one is problematic on Proton since the Proton launcher unconditionally clobbers that environment variable). One potential issue is that due to the less than ideal design of Spout2, there is no way to know when apps start using Spout2 other than polling for the existence of a named shared memory segment. So if this is merged unconditionally, the service would have to always run even if not needed, unless some kind of hack is added to `CreateFileMappingA` to watch for the "SpoutSenderNames" mapping and launch the service on demand when it is created. On top of that, once PipeWire -> Spout2 support is added, it would mean the daemon is bridging every possible PipeWire stream to Spout2 as soon as any Spout2 app runs regardless of whether any Spout2 consumer exists for it. The only way I can think of avoiding this (other than manual config) is, again, some kind of Wine hook that only triggers the bridge for a stream when some Spout2 consumer app has the specific stream shared memory and/or mutex opened to a handle... it really isn't a well designed protocol, unfortunately, but it is what is in use on Windows. [1] https://spout.zeal.co/ [2] https://github.com/leadedge/Spout2 [3] https://github.com/hoshinolina/libfunnel ~~ Lina

Jan. 17, 2026

Upcoming vkd3d 1.19 release

by Henri Verbeet

Hi all, The planned release date for vkd3d 1.19 is Thursday February 19. That means the public API will become frozen next week on January 22, and features will be frozen two weeks before the release, on February 5. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure that any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 2.0 is Thursday May 21. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

Jan. 15, 2026

Wine staging 11.0 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.0 (252 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * None Updated: * None Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 13, 2026

Re: List unsubscribe.

by Jeremy Newman

As we reported back when we migrated, the login accounts were not migrated. This is a limitation when you move Mailman3 services to a new server. It only has the ability to import a flat list of subscriber emails. Account data is not transferred unfortunately. This means if you were subscribed with the "no email" option, it would import you and start emailing you. I also wish Mailman3 was better at server migration, but it isn't. You can also unsubscribe by using the wine-devel-leave(a)list.winehq.org email address without creating an account. I'd point to where this is mentioned in the Mailman docs, but it isn't. Mailman3 needs better docs on this. On 1/13/26 03:21, klightspeed--- via Wine-devel wrote: > That being said, I'm guessing that the delivery preferences were associated > with accounts and not with subscriptions, and that this is the first move > since around 2012 in which accounts (and/or their preferences) were not > migrated.

Jan. 13, 2026

Re: List unsubscribe.

by klightspeed＠netspace.net.au

On Tuesday, January 13, 2026, Luke Kenneth Casson Leighton wrote: > hello Philippe, looks like I am not the only one > > On Tuesday, January 13, 2026, Philippe Groarke wrote: > > Hello, > > Could you please re-unsubscribe my email from the wine-devel list? It’s > > been recently reactivated, the lost password functionality doesn’t work > > and I couldn’t find support emails. > > likewise, I had "nomail" set and that option has > been lost somehow [I post and read archives > online to reduce my mailbox traffic] > > could "nomail" please either be re-set manually or > my email address also unsubscribed, thank you. >From the email detailing the move to the new list server On Wednesday, December 10, 2025, Alexandre Julliard wrote: > Also as mentioned, subscriptions have been transferred, but not > individual user accounts, so if you had created an account on the old > server to change your preferences, you'll need to create a new one at > https://list.winehq.org. Going through "Sign up" with your subscribed email address will link the newly created account with your subscriptions, wherein you can either unsubscribe or disable email delivery. Alternatively, from the List-Unsubscribe header, you can send an email to <wine-devel-leave(a)list.winehq.org> to unsubscribe without creating an account. That being said, I'm guessing that the delivery preferences were associated with accounts and not with subscriptions, and that this is the first move since around 2012 in which accounts (and/or their preferences) were not migrated.

Jan. 13, 2026

Re: List unsubscribe.

by Luke Kenneth Casson Leighton

hello Philippe, looks like I am not the only one On Tuesday, January 13, 2026, Philippe Groarke via Wine-devel < wine-devel(a)list.winehq.org> wrote: > Hello, > > > > Could you please re-unsubscribe my email from the wine-devel list? It’s > been recently reactivated, the lost password functionality doesn’t work and > I couldn’t find support emails. > likewise, I had "nomail" set and that option has been lost somehow [I post and read archives online to reduce my mailbox traffic] could "nomail" please either be re-set manually or my email address also unsubscribed, thank you. l. -- --- geometry: without it life is pointless the fibonacci series: easy as 1 1 2 3

Jan. 13, 2026

List unsubscribe.

by Philippe Groarke

Jan. 13, 2026

Re: 11.0 release notes (please review)

by Alex Henrie

On Mon, Jan 12, 2026 at 12:59 PM Alexandre Julliard via Wine-devel <wine-devel(a)list.winehq.org> wrote: > > Here are the tentative release notes for 11.0. Please review them and > let me know if anything is incorrect or missing. Under "Synchronization / Threading", you might want to mention the big CancelIo refactor: https://gitlab.winehq.org/wine/wine/-/merge_requests/7797 But the list of improvements is already very impressive even without mentioning that one ;-) -Alex

Jan. 12, 2026

Re: 11.0 release notes (please review)

by DodoGTA GT

> Here are the tentative release notes for 11.0. So are the release notes like the existence of /dev/ntsync on upstream kernel distros (aka non-existent)? /j

Jan. 12, 2026

Re: 11.0 release notes (please review)

by Alexandre Julliard

Second attempt at attaching the file... -- Alexandre Julliard julliard(a)winehq.org

Jan. 12, 2026

11.0 release notes (please review)

by Alexandre Julliard

Folks, Here are the tentative release notes for 11.0. Please review them and let me know if anything is incorrect or missing. Many thanks to Esme, Jacek, Michael, Piotr, Rémi, Vibhav and Zeb for their contributions! I'm planning to release the final 11.0 tomorrow. -- Alexandre Julliard julliard(a)winehq.org

Jan. 12, 2026

Wine staging 11.0-rc5 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.0-rc5 (252 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * None Updated: * None Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 9, 2026