December 2025 - Wine-Bugs - list.winehq.org

[Bug 67] Test Bug DELETE ME!
by WineHQ Bugzilla Dec. 8, 2025

Dec. 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=67 --- Comment #6 from Jeremy Newman <jnewman(a)codeweavers.com> --- Testing a bug email with new mailman mailing list changes. Ignore me please. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 59105] New: resizing window causes Vulkan swap chain to always be SUBOPTIMAL
by WineHQ Bugzilla Dec. 8, 2025

Dec. 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=59105 Bug ID: 59105 Summary: resizing window causes Vulkan swap chain to always be SUBOPTIMAL Product: Wine Version: 10.20 Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winevulkan Assignee: wine-bugs(a)list.winehq.org Reporter: mizvekov(a)gmail.com Created attachment 79909 --> http://bugs.winehq.org/attachment.cgi?id=79909 the application which reproduces the wine bug This bug can only be observed on wine running on MacOS, as installed through homebrew. When running the attached application, any attempts to resize the window to a different size than the initial size will make the application have incorrect visuals and enter a loop recreating the swap chain every frame. Steps to reproduce: 1) Run the attached application 2) Try to resize the window by dragging one of the corners. It seems like the newly created swap chains will be immediately considered SUBOPTIMAL upon first use. Not even device recreation will be enough to put the application back in a good state. I believe a surface recreation would be necessary, but this does not match the behavior on windows. This can be observed by going into main menu "Options" -> "Graphics" -> "Reload" -> "Instance". Another odd behavior which can be observed, by going to the same menu as above but reloading the "Swapchain" instead, is that the swap chain will be recreated twice instead of once, because the first time it will be SUBOPTIMAL as well, and then it will be okay the second time. None of these problems occur on any windows machine I could test. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 58962] New: WINE-TWAIN: multiple loading of twain_32.dll spoils in memory variables
by WineHQ Bugzilla Dec. 8, 2025

Dec. 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=58962 Bug ID: 58962 Summary: WINE-TWAIN: multiple loading of twain_32.dll spoils in memory variables Product: Wine Version: 10.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lenar.shakirov(a)gmail.com Distribution: --- Created attachment 79663 --> http://bugs.winehq.org/attachment.cgi?id=79663 wine-dlls-twain_32-tests-dsm_c.patch I have a problem with my scan utility that can use WIA or TWAIN interactively and loads twain_32.dll on the fly. Problem reproduced when 2 or more scanners used (sane-devices) It's looks like that: 1. loads twain_32.dll on the start, when it needs list of devices 2. loads twain_32.dll every time when try to scan 3. on the first scan I get my first scanner 4. on the second scan I get my first scanner 5. on the third scan I get my second scanner 6. on the four scan I get my first scanner again You can reproduce it by 3 steps: 1. Configure any 2 scanners, for example virtual sane-test and sane-pnm: a) echo -e 'pnm\ntest' > /etc/sane.d/dll.conf b) sed -i 's/number_of_devices 2/number_of_devices 1/' /etc/sane.d/test.conf c) scanimage -L device `test:0' is a Noname frontend-tester virtual device device `pnm:0' is a Noname PNM file reader virtual device 2. Now you need to patch wine/dlls/twain_32/tests/dsm.c by simple patch wine-dlls-twain_32-tests-dsm_c.patch , build this test and get i386-windows/twain_32_test.exe 3. Now when you run: WINETEST_INTERACTIVE=1 wine /tmp/twain_32_test.exe &>/tmp/twain32.log You get twain32.log, that contains interesting lines: grep -a Manufacturer /tmp/twain32.log dsm.c:779: [Scanner 1|Version 0.0()|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family frontend-tester|ProductName test:0] dsm.c:779: [Scanner 2|Version 0.0()|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family PNM file reader|ProductName pnm:0] dsm.c:779: [Scanner 1|Version 64380.17(t)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family frontend-tester|ProductName test:0] dsm.c:779: [Scanner 2|Version 64380.17(t)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family PNM file reader|ProductName pnm:0] dsm.c:779: [Scanner 1|Version 64380.17(t)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family PNM file reader|ProductName pnm:0] dsm.c:779: [Scanner 2|Version 64380.17(t)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family frontend-tester|ProductName test:0] dsm.c:779: [Scanner 1|Version 64380.17(l)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family frontend-tester|ProductName test:0] dsm.c:779: [Scanner 2|Version 64380.17(l)|Protocol 1.8|SupportedGroups 0x40000003|Manufacturer Noname|Family PNM file reader|ProductName pnm:0] As you can see, there is 2 problems: 1. On first and second twain_32.dll loading there is a "Family frontend-tester" on first place, but on third loading "Family PNM file reader" moved on first place 2. "Version" was '0.0()' on first loading, but changed to "64380.17(t)" after that For me I fix this behavior by changing logic of get_identity() from sane.ds: --- a/wine/dlls/sane.ds/unixlib.c +++ b/wine/dlls/sane.ds/unixlib.c @@ -213,7 +213,15 @@ static NTSTATUS get_identity( void *args ) static int cur_dev; detect_sane_devices(); - if (!device_list[cur_dev]) return STATUS_DEVICE_NOT_CONNECTED; + + if (!device_list[cur_dev] || !device_list[cur_dev]->model || + !device_list[cur_dev]->vendor || + !device_list[cur_dev]->name) + { + cur_dev = 0; /* wrap to begin */ + return STATUS_DEVICE_NOT_CONNECTED; + } + id->ProtocolMajor = TWON_PROTOCOLMAJOR; id->ProtocolMinor = TWON_PROTOCOLMINOR; id->SupportedGroups = DG_CONTROL | DG_IMAGE | DF_DS2; @@ -222,11 +230,6 @@ static NTSTATUS get_identity( void *args ) lstrcpynA (id->ProductFamily, device_list[cur_dev]->model, sizeof(id->ProductFamily) - 1); cur_dev++; - if (!device_list[cur_dev] || !device_list[cur_dev]->model || - !device_list[cur_dev]->vendor || - !device_list[cur_dev]->name) - cur_dev = 0; /* wrap to begin */ - return STATUS_SUCCESS; } Current get_identity() implementation increments cur_dev more than necessary, this is especially noticeable when there are 2 (or more scanners) and twain_32.dll loads multiple times. Because of this, twain_add_onedriver() function from dlls/twain_32/dsm_ctrl.c adds 3 device instead of 2 Everything works fine when twain_32.dll loads one time, but multiple loading of twain_32.dll spoils in memory variables I don't really sure that it good idea to return "not success code", because as I understand TWAIN specification awaiting only "success code" from DG_CONTROL/DAT_IDENTITY/MSG_GET https://github.com/twain/twain-specification/blob/master/versions/2.4/TWAIN… Page 7-60 DG_CONTROL / DAT_IDENTITY / MSG_GET (from Source Manager to Source) Return Codes: TWRC_SUCCESS /* This operation must succeed. */ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 59066] New: Legacy Family Tree much slower under 10.20 compared with previous version
by WineHQ Bugzilla Dec. 8, 2025

Dec. 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=59066 Bug ID: 59066 Summary: Legacy Family Tree much slower under 10.20 compared with previous version Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: mice(a)duck.com Distribution: --- Since updating to WINE 10.20, Legacy Family Tree v10 is taking much longer to open than under previous versions. It uses an old MS database system (Jet?) so that might be a clue. After updating WINE I had to reboot the system before legacy would open at all. Even now it crashes randomly. Apologies I don't have the skills to do regression testing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 58684] New: AutoIt Tooltip multiple lines fail to display all the text properly
by WineHQ Bugzilla Dec. 8, 2025

Dec. 8, 2025

http://bugs.winehq.org/show_bug.cgi?id=58684 Bug ID: 58684 Summary: AutoIt Tooltip multiple lines fail to display all the text properly Product: Wine Version: 10.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: torchrish(a)gmail.com Distribution: --- Created attachment 79279 --> http://bugs.winehq.org/attachment.cgi?id=79279 Testreport, test program, test result images 1. When inserting @CRs in the display text string the with of the display is not adjusted to hold the longest line 2. The inserted @CRs cuts off display of the text at the last @CR or third @CR attached files: Test program source: tooltip_linux.au3 (includes function description as comments) Testreport: system setup information Test screen dumps: 3 images from windows tests 3 images from WINE tests -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 25535] New: .NET Framework 4.0 Fails to install with HRESULT 0x80070643
by wine-bugs＠winehq.org Dec. 7, 2025

Dec. 7, 2025

http://bugs.winehq.org/show_bug.cgi?id=25535 Summary: .NET Framework 4.0 Fails to install with HRESULT 0x80070643 Product: Wine Version: 1.3.9 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: pjdowson(a)gmail.com Wine version is 1.3.9, compiled with no parameters on Fedora 13. Installing dotNetFx40_Full_x86_x64.exe downloaded from the MS website, the installer will open and verify the integrity of files. The next stage will attempt to install the .NET Framework 4.0 Client Profile. Towards the end of this install the installer will fail with HRESULT 0x80070643, leaving little or no information in the %TEMP% folder as to the cause. The installer will only run if wine is set to WinXP. Process used to reproduce: WINEPREFIX=~/.wine-net40 sh winetricks gecko WINEPREFIX=~/.wine-net40 sh winetricks windowscodecs ie7 msxml3 WINEPREFIX=~/.wine-net40 wineboot WINEDEBUG=+relay WINEPREFIX=~/.wine-net40 wine Downloads/net40/dotNetFx40_Full_x86_x64.exe &> net-out I also attempted to install the .NET Framework 4.0 Client Profile prior to installing the Full package. This provides the same error, the only difference to the above process used was the filename of the Client Profile installer dotNetFx40_Client_x86_x64.exe. Each time I attempted to install I used a clean WINEPREFIX, deleting the prior one before attempting again. Screenshot of error: http://www.stimpy.org/wine/net-error.png Logs referenced in above screenshot, in %TEMP% dir: http://www.stimpy.org/wine/net-install-logs.tar.gz Output of installer debug: http://www.stimpy.org/wine/net-out.tar.gz This is my first bug report, I apologize if I have missed anything out. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 48

[Bug 56647] New: ntdll-Junction_Points prevent rustup from correctly installing a toolchain
by WineHQ Bugzilla Dec. 7, 2025

Dec. 7, 2025

https://bugs.winehq.org/show_bug.cgi?id=56647 Bug ID: 56647 Summary: ntdll-Junction_Points prevent rustup from correctly installing a toolchain Product: Wine-staging Version: 9.8 Hardware: x86-64 URL: https://rustup.rs/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lorenzofer(a)live.it CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: ArchLinux Created attachment 76423 --> https://bugs.winehq.org/attachment.cgi?id=76423 return STATUS_NOT_A_REPARSE_POINT instead of STATUS_INVALID_PARAMETER Hi. With the recent rustup 1.27.0 using wine-staging with the ntdll-Junction_Points patches, the toolchain installation doesn't complete properly, failing to write to the settings.toml under the prefix home .rustup directory info. A bug with the same root cause is also present on rustup 1.26.0 where while the installation was completing properly, it was failing to remove the .rustup/tmp/* directories, causing issues with subsequent installations. Both bugs express the same behavioral pattern with few differences. I investigated the directory bug firstly, so I will detail this, and confirmed that the problem and the expected solution are the same. Rustup (or one of it's dependency managing files) get the handle of the temporary directory using CreateFileW and then checking if it's a reparse point using DeviceIoControl with FSCTL_GET_REPARSE_POINT. The directories (and the file) aren't reparse points at all, so the readlink fails returining EINVAL. This EINVAL is then mapped to an NT_STATUS using errno_to_status that map EINVAL to STATUS_INVALID_PARAMETER. However this mapping is incorrect for FSCTL_GET_REPARSE_POINT as in this case applications that handle this case like rustup try to handle this case by epxecting STATUS_NOT_A_REPARSE_POINT. Returning STATUS_NOT_A_REPARSE_POINT in this case allow rustup to work (both versions ) Attaching a patch to show the change in the file.c code (and restored also the out_buffer check) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 33997] New: win86emu needs Unimplemented function KERNEL32.dll.CreateSymbolicLinkA
by wine-bugs＠winehq.org Dec. 7, 2025

Dec. 7, 2025

http://bugs.winehq.org/show_bug.cgi?id=33997 Bug #: 33997 Summary: win86emu needs Unimplemented function KERNEL32.dll.CreateSymbolicLinkA Product: Wine Version: 1.6-rc4 Platform: arm URL: http://forum.xda-developers.com/showthread.php?t=20959 34 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: nerv(a)dawncrow.de CC: focht(a)gmx.net Classification: Unclassified PostInstall.exe from win86emu says: wine: Call from 0xb6b71868 to unimplemented function KERNEL32.dll.CreateSymbolicLinkA, aborting I already checked that it doesn't try to import something from kernel32 per ordinal. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 32523] New: CreateSymbolicLinkW() is not implemented
by wine-bugs＠winehq.org Dec. 7, 2025

Dec. 7, 2025

http://bugs.winehq.org/show_bug.cgi?id=32523 Bug #: 32523 Summary: CreateSymbolicLinkW() is not implemented Product: Wine Version: 1.5.17 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: alexey.pushkin(a)mererand.com Classification: Unclassified It looks like Vista+ CreateSymbolicLinkW() is not implemented: wine: Unimplemented function KERNEL32.dll.CreateSymbolicLinkW called at address..., starting debugger... I suppose it's fairly trivial to implement it with normal unix symlinks, isn't it ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 9

[Bug 4309] Directory-chooser GUI component is confused by directories named "..."
by WineHQ Bugzilla Dec. 7, 2025

Dec. 7, 2025

http://bugs.winehq.org/show_bug.cgi?id=4309 --- Comment #11 from Janne <janne.kekkonen(a)gmail.com> --- Hello, Last item on section Naming Conventions states that file or directory should not end to space or period. https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0