wine-devel

wine-devel@winehq.org

10 participants
84486 discussions

Introducing the list.winehq.org domain
by Alexandre Julliard 10 Nov '25

10 Nov '25

Folks, Just a heads up that we are starting the process of moving the various Wine mailing lists to a new 'list.winehq.org' domain. So for instance the wine-devel list is going to be at <wine-devel(a)list.winehq.org>. This is necessary to make it possible to host the lists on a different server in the future. Sending mail to the existing @winehq.org addresses will still work, so the change should be mostly transparent, but you may see the list.winehq.org domain start creeping up in the mail headers, and may need to adjust your filters. Note that the recommended way is to filter on the List-Id: header; that one is not expected to change. Thank you for your understanding, -- Alexandre Julliard julliard(a)winehq.org

2 1

64-Bit twain data source manager should be named twaindsm.dll instead of twain_32.dll
by Bernd Herd 10 Nov '25

10 Nov '25

Hello, for 64-Bit, the code in dlls/twain_32 should be compiled into a library installed as twaindsm.dll instead of twain_32.dll, since Windows applications do expect a 64-Bit Data Source Manager to be named twaindsm.dll. How could that be done? Background: wine includes an interface from the TWAIN interface common in Windows to the SANE interface common on Linux. This is dlls/sane.ds, which is in TWAIN speak a "Data Source". This allows to use most scanners supported by SANE from WINE, without caring about any special drivers. Which is a pretty cool thing. 64 Bit TWAIN is somewhat exotic, since Microsoft is pushing towards their WIA interface and does not include a 64-Bit Data Source Manager with Windows. The 32-Bit Data Source Manager shipped with Windows is TWAIN_32.DLL. This DLL is under control of Microsoft and the TWAIN organization cannot update it, so they choose to name their update DSM "twaindsm.dll". I found some more information on that here: https://github.com/twain/twain-dsm/blob/master/TWAIN_DSM/src/readme.doc](ht… This twaindsm.dll is available in 32-Bit and 64-Bit. And so the only 64-Bit DSM that application programs expect is twaindsm.dll. There are hardly any 64-Bit TWAIN drivers available on Windows. Irfanview 64-Bit uses twaindsm.dll if installed and spawns a 32-Bit EXE if not. Older versions of 64-Bit Libreoffice for Windows used twaindsm.dll. New Versions start a 32-Bit process to use 32-Bit TWAIN. The code in the dlls/sane.ds searches for "twain_32", and I know two ways to solve this. What I don't know is how to change wine so that it compiles dlls/twain_32 to twaindsm.dll for 64-Bit Builds only and deploy that dll to the wine prefix. Any suggestion of how to do that? Yours Bernd Herd :-)

3 2

RoResolveNamespace and winmd
by James McDonnell 06 Nov '25

06 Nov '25

Hello, I see the winmd File generation work has landed in wine. In order for affinity to run, it needs to map winrt namespaces to winmd files. These are defined in the idl files afaict. I am looking for guidance of looking up this information in RoResolveNamespace. I see in the widl tool we generate the files. I did not find any parser for winmd files. Is there somewhere I should look? Or is this new ground. Would it be acceptable to have an override in the registry that RoResolveNamespace uses such that wine prefixes can customize if needed? Thank you, James

1 0

Submitting patches to staging
by light gray 06 Nov '25

06 Nov '25

Hi! On the condition that I de-anonymize myself, would it be possible for me to submit my patches over at https://github.com/Weather-OS/WineGDK to wine staging? My repository fully complies with Wine's cleanroom guidelines, and more importantly, I *do not, and under no circumstances,* use AI generated code to implement API functionality. I solely rely on tests written and compiled within a Windows environment and Microsoft's own documentation. Best Regards.

4 5

Wine staging 10.18 release
by Alistair Leslie-Hughes 01 Nov '25

01 Nov '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.18 (283 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * scrrun: Implement MoveFolder(). * scrrun: Check for null and empty arguments in MoveFolder. * scrrun: Test MoveFolder with already existing destination. * scrrun: Check for non-existant source in MoveFolder(). * scrrun: Check that source is directory in MoveFolder(). * scrrun: Move source dir into destination dir if destination ends with separator in MoveFolder(). * scrrun: Support wildcards in MoveFolder(). * scrrun: Move directories only in MoveFolder(). * scrrun: return path not found error if source ends with path separator in MoveFolder(). * scrrun: Return path not found error if no folders were moved in MoveFolder(). * user32: Implement CascadeWindows. * user32: Implement TileWindows * wineboot: Initialize proxy settings registry key. * ws2_32/tests: Add test for AF_UNIX sockets. Removed (No longer required). * None Added: * None 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.

1 0

Wine staging 10.17 release
by Alistair Leslie-Hughes 18 Oct '25

18 Oct '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.17 (295 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * draw: Return correct devices based off requested DirectX version. * odbc32: SQLGetData handle ANSI driver * odbc32: Record loaded driver SQL_ATTR_ODBC_VERSION * comctl32: Bump version to 6.0. * d3dx10/tests: Add tests for the D3DX10_IMAGE_LOAD_INFO structure argument. * d3dx10: Create 3D textures for images representing 3D textures. * shell32: Improve semi-stub SHGetStockIconInfo, try find existing iconhandle * shell32: Set SFGAO_HASSUBFOLDER correctly for normal shellfolders. * winex11.drv/window: Query the X server for the actual rect of the window before unmapping it Removed (No longer required). * None Added: * [58786] - iccvid: Support ICM_DECOMPRESSEX_BEGIN message * [36208] - d3drm: Stops crash when Star Wars Rebellion battles. * [58418] - wininet: Stop crash in InternetQueryOptionW when NULL buffer is provided. 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.

1 0

Upcoming vkd3d 1.18 release
by Henri Verbeet 15 Oct '25

15 Oct '25

Hi all, The planned release date for vkd3d 1.18 is Thursday November 20. That means the public API will become frozen next week on October 23, and features will be frozen two weeks before the release, on November 6. 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 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 1.19 is Thursday February 19. 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

1 0

Wine staging 10.16 release
by Alistair Leslie-Hughes 04 Oct '25

04 Oct '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.16 (281 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Implement NtSetLdtEntries. * ntdll/tests: Add some tests for NtSetLdtEntries. * vbscript: redim without dim. * wscript: return TRUE for /d and /u stub switches. * Fix calculation of listbox size when horizontal scrollbar is present. * ddraw: Set dwZBufferBitDepth in ddraw7_GetCaps. * wineboot: Add some generic hardware in HKEY_DYN_DATA\Config Manager\Enum * odbc32: SQLDriverConnectW fallback to SQLDriverConnect when required. * odbc32: SQLGetInfoW support ANSI fallback. * odbc32: SQLExecDirectW call fallback SQLExecDirect Removed (No longer required). * user32-FlashWindowEx (already fixed). * eventfd_synchronization (NTSYNC is upstream now). Added: * [48598] d3dx9: Improve Rendering in MudRunner. Updated: * vkd3d-latest * d3dx11_43-D3DX11CreateTextureFromMemory 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.

1 0

ALSA MIDI is not working under NixOS
by Yuxuan Shui 01 Oct '25

01 Oct '25

Hi, I have an interesting bug (maybe?) for you. I don't know what's the best way to explain so I will just retrace how I found out what's happening. I was investigating Bug 58216 (completely unrelated, but this is how I encountered this problem). When I started the game, it just hangs with a black screen. It didn't crash but it didn't start either. Nothing stood out in the logs, so I attached winedbg. It showed a thread stuck in mmdevapi.dll::DriverProc, handling a DRV_FREE. The notify_thread wasn't stopping, clearly the midi_release call isn't causing the midi_notify_wait to return. So I added debug logging to alsamidi.c, and they weren't being hit. Turning on +mmdevapi debug channel shows winealsa.drv was being loaded as the MIDI driver. What is going on? I was perplexed. Single stepping into the unix call to midi_release showed it somehow called into pulse_not_implemented. Turning on +module and I found this: 0024:trace:module:load_native_dll found L"C:\\windows\\system32\\winepulse.drv" for L"\\??\\C:\\windows\\system32\\winealsa.drv" This is bizarre. Reading the code I saw a few server calls for memory mapping stuff, so I turned on +server. And I saw a create_mapping call made with a file handle for winealsa.drv, but a later get_mapping_info call on that mapping returned winepulse.drv. Okay, I was reading wineserver code now. In the create_mapping function we have: mapping->fd = get_fd_object_for_mapping( ... ) And get_fd_object_for_mapping can replace the given fd with another fd of the same underlying inode#. Ah ha! I look at the inode of winealsa.drv and winepulse.drv, and yeah they are identical. * * * But how? I run NixOS. On NixOS all installed software packages come out of the "nix store", and nix store has an "optimise" feature which replaces identical files in the nix store with hardlinks. winealsa.drv and winepulse.drv are empty dlls only there for loading their corresponding .so unixlibs, that's why they are identical, and were replaced by hardlinks. Question: what's the right thing to do here? Considering hardlinked files indistinguishable for mapping purposes seems reasonable, and I won't be surprised if there are testcases testing specifically this. But adding unixlibs to the mix and things change. Now the path from which a module is accessed becomes significant too, because it will be used to find the .so. In this case the result was the wrong unixlib being used. Help? Thanks. -- Regards Yuxuan Shui

7 13

WineConf 2025 Videos
by Jeremy Newman 29 Sep '25

29 Sep '25

WineConf 2025 videos now available on our WineHQ YouTube channel: https://www.youtube.com/@wine-hq Keynote - Alexandre Julliard https://youtu.be/zsdukp8xfv4 Framework Mono – Esme Povirk https://youtu.be/l3d68YJtYxY State of crypto support in Wine – Hans Leidekker https://youtu.be/eQOz1nD0VGI Emulation / ARM64 session https://youtu.be/BTraz8LDU8E Minimal Protonification – Arkadiusz Hiler https://youtu.be/U8Xq6jgijos Upholding the LGPL in Wine: Next Steps in Our Journey – Bradley M. Kuhn + Denver Gingerich https://youtu.be/IUE95tVTmO4 Wine on macOS State of the Union – Brendan Shanks https://youtu.be/ftqwLHQveq4 Wine Stable – Michael Stefaniuc https://youtu.be/x6eP56UmxiE llvm-mingw: How to QA a toolchain on a zero budget – Martin Storsjö https://youtu.be/NpxO3DGDxKE The video links along with the slides are also available via our WineConf Wiki page: https://gitlab.winehq.org/wine/wine/-/wikis/WineConf/WineConf-2025 -- CodeWeavers, Inc. 🐉 Jeremy Newman ⛭ Director of IT ────────────────────────────────────────────────────── 📧 jnewman(a)codeweavers.com 🌐 https://www.codeweavers.com/about/people/jnewman

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel