November 2025 - Wine-Devel - list.winehq.org

Wine staging 10.20 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 10.20 (252 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * kernelbase: Add support for moving reparse points with MoveFile*. * x3daudio1_7: Create import library * xactengine3_7/tests: Add Global settings test * kernel32: Implement CreateSymbolicLink[A|W] with ntdll reparse points. * kernel32: Add reparse support to FindNextFile. * user32: Add a workaround for Windows 3.1 apps which call LoadImage(LR_LOADFROMFILE) with a resource id. (v2) 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.

Nov. 29, 2025

(no subject)

by None

Nov. 27, 2025

None

by None

by Pony.ns.zel.ru with ESMTP id i38KgMrt059607 for <wine-devel(a)winehq.org.KAV>; Fri, 9 Apr 2004 00:42:22 +0400 (MSD) (envelope-from deepfire(a)sic-elvis.zel.ru) Received: from mailserver sic-elvis by Pony.ns.zel.ru with ESMTP id i38KgMrt059598 for <wine-devel(a)winehq.org>; Fri, 9 Apr 2004 00:42:22 +0400 (MSD) (envelope-from deepfire(a)sic-elvis.zel.ru) Date: Thu, 08 Apr 2004 23:43:44 +0400 Message-ID: <87wu4qdzm7.wl(a)canopus.ns.zel.ru> From: Samium Gromoff <deepfire(a)sic-elvis.zel.ru> To: wine-devel(a)winehq.org Subject: Re: ANNOUNCE: CVS to arch gateway User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: wine-devel-admin(a)winehq.org Errors-To: wine-devel-admin(a)winehq.org X-BeenThere: wine-devel(a)winehq.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: <http://www.winehq.org/mailman/listinfo/wine-devel>, <mailto:wine-devel-request(a)winehq.org?subject=unsubscribe> List-Id: Wine Developer's List <wine-devel.winehq.org> List-Post: <mailto:wine-devel(a)winehq.org> List-Help: <mailto:wine-devel-request(a)winehq.org?subject=help> List-Subscribe: <http://www.winehq.org/mailman/listinfo/wine-devel>, <mailto:wine-devel-request(a)winehq.org?subject=subscribe> List-Archive: <http://www.winehq.org/hypermail/wine-devel/> Perphaps it might be interesting, that there exists a gtk2 frontend to tla, called tlator. Well, it might sound like a shameless plug, because that`s me who actually wrote it, but the perphaps the main incentive behind this mail is to widen arch acceptance among people, so who knows... ;-) The tlator arch repository is located at James Blackwell`s sourcecontrol crossroad-like place: http://sourcecontrol.net/~sgromoff/%{archives}/deepfire(a)betelheise.deep.n… regards, Samium Gromoff

Nov. 27, 2025

Wine staging 10.19 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 10.19 (256 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Add support for creating reparse points. * ntdll: Add support for reading reparse points. * ntdll: Add support for deleting reparse points. * Return correct status value if handle is not a reparse point * ntdll: Always report symbolic links as containing zero bytes. * ntdll: Succeed with no data for NtReadFile on reparse points. * ntdll: Add support for testing for reparse points with GetFileAttributes. * server: Implement FILE_OPEN_REPARSE_POINT option. * ntdll: Add support for FileAttributeTagInformation. * kernelbase: Add support for deleting reparse points with RemoveDirectory. * kernelbase: Add support for deleting reparse points with DeleteFile. * ntdll: Follow reparse points during path resolution. * d3dx11: Implement D3DX11CreateTextureFromMemory() using shared code. Removed (No longer required). * ntdll: Allow reparse points to target the applicable Unix file/directory. * ntdll: Add an intermediary prefix symlink in reparse point metadata. 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.

Nov. 15, 2025

Re: Extended test suite

by Gabriel Ivăncescu

Hi, For what it's worth, I'm personally in favor of this, if people need it. It could be a mode like WINETEST_INTERACTIVE=1 but for extended tests. The problem, of course, is that initially you won't have many users of this in the test suite so it's hard to justify it. And it won't have until it's available. The classic chicken-and-egg problem.

Nov. 13, 2025

Extended test suite

by Giovanni Mascellani

Hi, some time ago I was asked by a reviewer to modify a MR I had submitted to remove some of the conformance tests I had added with it. The concern, which I find completely valid, was that since the tests are run on each MR submission we should try to reduce (or, at least, do not increase too much) the run time, otherwise it becomes too much inconvenient for everybody. As I said, that totally makes sense for me, and in that particular occasion I ended up removing some cases, hopefully keeping enough to cover all the common test cases. But corner cases exist too, and they can make a developer waste a lot of time chasing them down. And at least in my experience it's often hard to predict which specific cases are going to be somehow critical in the future. So giving up some tests bears most of the times if not always the risk of having to waste time on something that would have been simpler if only we had kept that specific test case. So I'm curious to know whether anybody else experiences this problem, and possibly brainstorm some ideas about how to work it around. What I'd like to propose is to introduce an extended test suite, which in practice means adding a flag to our current test suite and gating some tests to be executed (at all, or to be executed on a larger number of cases) only if the flag is set. The regular test suite could be run on all MRs, and the extended test suite could be run perhaps once per day or so. The feedback is less immediate, but it still looks better than dropping those tests at all. The terms "pre-merge test" and "post-merge tests" are sometimes used, I think they essentially mean the same thing. Is there any interest for this? Or alternative solutions? Gio.

Nov. 13, 2025

Re: Introducing the list.winehq.org domain

by Jeremy Newman

We've also changed the reply-to field on outgoing emails from the mailing lists. It is now set it to the new host of @list.winehq.org. On 11/6/25 02:34, Alexandre Julliard wrote: > 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, > -- CodeWeavers, Inc. 🐉 Jeremy Newman ⛭ Director of IT ────────────────────────────────────────────────────── 📧 jnewman(a)codeweavers.com 🌐 https://www.codeweavers.com/about/people/jnewman

Nov. 10, 2025

Re: 64-Bit twain data source manager should be named twaindsm.dll instead of twain_32.dll

by Elizabeth Figura

On Monday, 10 November 2025 09:23:37 CST Esme Povirk wrote: > We can't just disable in configure based on host arch, because in the > case of new wow64 we'll be building for i386 and x86_64 in the same tree. > > I think we want to do two things: > > Use the PARENTSRC feature to create two dlls, twain_32 and twaindsm, > that share the same source files. > > Disable one or the other dll by default, based on architecture. In > theory, this can be done in configure. One can, if I'm reading this > right, use a configure switch like --enable-twain_32=i386 > --enable-twaindsm=x86_64,arm64ec,arm,aarch64. Although, it seems like > twaindsm.dll exists in 32-bit as well, so it should probably be built > for all architectures. > > As for how to actually do that, I think we want to set enable_twain_32 > in configure.ac, only when it hasn't been already set by the user. See > enable_dpnsvr for an example of this. If I'm not mistaken, we can do much simpler, and just rename it from wine.inf. As of ad9dfe8bcc we look for the builtin by its export name, which will still be twain_32 in that case. That was meant for comctl32, but I think it works in the reverse direction as well. Whether we should actually do this seems a bit questionable to me, if Windows doesn't actually ship twaindsm.dll, and if twaindsm.dll is presumably a different piece of software that is even LGPL 2.1 licensed.

Nov. 10, 2025

Re: 64-Bit twain data source manager should be named twaindsm.dll instead of twain_32.dll

by Esme Povirk

We can't just disable in configure based on host arch, because in the case of new wow64 we'll be building for i386 and x86_64 in the same tree. I think we want to do two things: Use the PARENTSRC feature to create two dlls, twain_32 and twaindsm, that share the same source files. Disable one or the other dll by default, based on architecture. In theory, this can be done in configure. One can, if I'm reading this right, use a configure switch like --enable-twain_32=i386 --enable-twaindsm=x86_64,arm64ec,arm,aarch64. Although, it seems like twaindsm.dll exists in 32-bit as well, so it should probably be built for all architectures. As for how to actually do that, I think we want to set enable_twain_32 in configure.ac, only when it hasn't been already set by the user. See enable_dpnsvr for an example of this. On 2025-11-08 12:42, Bernd Herd wrote: > 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 > > :-) > >

Nov. 10, 2025

64-Bit twain data source manager should be named twaindsm.dll instead of twain_32.dll

by Bernd Herd

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 :-)

Nov. 8, 2025