August 2026 - Wine-Bugs - list.winehq.org

[Bug 60128] Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60128 Ned M <empcomputer(a)outlook.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=60224 -- 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.

Aug. 25, 2026

[Bug 59431] Project Egg Launcher Interface Does Not Render

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59431 --- Comment #5 from Robert T <robertthesable(a)gmail.com> --- (In reply to Robert T from comment #4) > On wine 11.5, this can be worked around by installing the dotnet48 and > webview2 verbs. Apologies, I meant wine 11.15. -- 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.

Aug. 25, 2026

[Bug 59431] Project Egg Launcher Interface Does Not Render

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59431 --- Comment #4 from Robert T <robertthesable(a)gmail.com> --- On wine 11.5, this can be worked around by installing the dotnet48 and webview2 verbs. -- 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.

Aug. 25, 2026

[Bug 12425] win16 test suite: user32 comm16 test crashes/hangs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=12425 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.59. -- 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.

Aug. 25, 2026

[Bug 60227] Legacy Family Tree 10 crashes on exit

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60227 --- Comment #6 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- mfc42 requirement is Bug 657. Does the crash still occur with just mfc42 installed? In theory this app is available to download for testing, just not in an obvious manner without giving all of your details. -- 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.

Aug. 25, 2026

[Bug 60165] Multisim - Graphical Issues with the Interface.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60165 ghepardoman <ssh.ghepardoman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ssh.ghepardoman(a)gmail.com --- Comment #10 from ghepardoman <ssh.ghepardoman(a)gmail.com> --- (In reply to GDD71 from comment #9) > New Information - A Simple, Automated Process for Installing MultiSIM 14.3 > https://github.com/ghepardoman/NI-Multisim-14-for-Linux-and-MacOS > > best regards Thank you for sharing my project, I really appreciate it. :) -- 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.

Aug. 24, 2026

[Bug 60223] IMFTimedText and related APIs missing

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60223 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Nikolay Sivov <bunglehead(a)gmail.com> --- Most of the types were merged to Wine headers now with https://gitlab.winehq.org/wine/wine/-/merge_requests/11734. Someone will need to notify mingw-w64 developers to re-import mfmediaengine.idl. -- 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.

Aug. 24, 2026

[Bug 45746] Import pfx fails. Metatrader 5 cannot connect to broker

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=45746 --- Comment #15 from nayuta65535(a)gmail.com --- (In reply to Hans Leidekker from comment #14) > PFXImportCertStore() may work now but as described in this bug a password > dialog should be shown for password protected PFX files. I think we should > focus this bug on that part. Happy to. One clarification about what the bug describes, and one thing I found while looking at it. The password dialog in comments #6, #10 and #11 is MetaTrader's own, not Wine's, and it only appeared once native crypt32 had been installed through winetricks. With builtin crypt32 the reporter got no password prompt at all, because the file was not recognised as a PFX in the first place - that is the CryptQueryObject part, fixed by 962aed51205. The wine control reproducer in comment #8 also stops at "file did not recognized", before any password could be entered. So if the bug is to be about Wine's own import wizard prompting for a PFX password, that is a fair thing to track, but it is not something the wizard is close to doing today: it cannot get as far as needing a password. CryptQueryObject identifies a PFX but hands back a NULL store. Measured on an unmodified wine-11.16 build with a fresh prefix, against two PKCS#12 files generated with openssl, one with a password and one without: secret.pfx ret=1 contentType=12 (CERT_QUERY_CONTENT_PFX) store=0000000000000000 nopass.pfx ret=1 contentType=12 (CERT_QUERY_CONTENT_PFX) store=0000000000000000 That is CRYPT_QueryPFXObject in dlls/crypt32/object.c, which sets *phCertStore to NULL for a PFX and only reports the content type. cryptui's import path takes only that store handle: dlls/cryptui/main.c open_store_from_file() -> CryptQueryObject(..., &store, ...) dlls/cryptui/main.c import_file() -> if (!source) return FALSE so import_file() fails for any PFX, password protected or not. There is no PFXImportCertStore call anywhere in dlls/cryptui; the PFX support there is export-only (save_pfx, PFXExportCertStore and the IDD_EXPORT_PASSWORD page). The import side has no counterpart. The remaining work therefore looks like a PFX branch in the import wizard: a password page, and a PFXImportCertStore call with what the user typed, rather than relying on the store handle from CryptQueryObject. I have not checked what Windows returns for phCertStore on a PFX, so I do not know whether the NULL store is itself a deviation or just something cryptui has to work around. The original MetaTrader symptom I still cannot confirm - comment #12 asked for the broker's certificate and it was never provided, and I do not have one. -- 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.

Aug. 24, 2026

[Bug 60232] advapi32: GetCurrentHwProfileA crashes on a NULL argument, and the profile guid is hardcoded

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60232 --- Comment #2 from nayuta65535(a)gmail.com --- Not in the sense of an application failing to work. I went and checked, and the answer turned out to be no, so I am posting what I measured even though it argues against part of my own report. iZotope's Product Portal, the client that installs and activates their plug-ins, calls GetCurrentHwProfileA once at startup and uses the guid it gets back as the identity of the machine. On a pristine wine-11.16 built from the release tarball (../configure --enable-archs=i386,x86_64 --with-x --with-dbus, no staging, no DLL overrides), with the Portal's HTTP cache emptied first so that only that run's traffic was in it: fixme:advapi:GetCurrentHwProfileA (00007FFFFE20B560) semi-stub https://productportal.izotope.com/api/entitlements?hostID=12340001123412341… which is the hardcoded {12340001-1234-1234-1234-123456789012} with the braces and dashes stripped. With a locally patched advapi32 that generates a guid and stores it in the registry, the same request carries that machine's own guid instead. But it still works. On that same pristine build I completed machine-bound ("comp") authorizations of two products against that constant, and the vendor accepted both. One of them, with the check before and after in the same log: 04:23:26 AUTHCHECK | iZotope Ozone 8 Elements | Not Authorized | (LicenseType: 0, AuthType: 3) 04:24:25 AUTHORIZE | AuthorizeProduct | Ozone 8 Elements | AuthType: 'comp' 04:24:25 AUTHORIZE | iZotope Ozone 8 Elements | Result: Success 04:24:34 AUTHCHECK | iZotope Ozone 8 Elements | AUTHORIZED | (LicenseType: 3, AuthType: 0) Products authorized earlier also still validate under the stub value. So no application is blocked by this, and I should not have implied otherwise. What remains is that every Wine installation presents the same machine identity to that licensing server, and machine-bound authorizations are all issued against it, where MSDN says the system generates the guid per hardware profile at install time. Whether that is worth implementing is your call. The other three, no. The NULL crash, GetCurrentHwProfileW always failing, and dwDockInfo all came out of running the same test binary on Windows 11 and on Wine on this machine, so they are mismatches with Windows rather than application reports. The crash does still reproduce on 11.16, at dlls/advapi32/advapi.c:87: =>0 GetCurrentHwProfileA+0x18 [dlls/advapi32/advapi.c:87] in advapi32 87 pInfo->dwDockInfo = DOCKINFO_DOCKED; If a narrower bug is more useful, I am happy to reduce this one to the crash alone, or to close it. -- 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.

Aug. 24, 2026

[Bug 48534] 32-bit MSXML 6.0 package fails to install in 64-bit WINEPREFIX 'package is not supported on the current processor type.'

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=48534 --- Comment #3 from Anastasius Focht <focht(a)gmx.net> --- Hello Hans, thanks for the test. It seems the 32-bit MSXML 6.0 redist installer skips itself on Vista+ via a custom action. The package sequences a custom action 'SkipInstallCA' (condition 'VersionNT>502') before 'LaunchConditions': Dumping of relevant msi installer tables: 'InstallExecuteSequence' table: --- snip --- Action Condition Sequence SkipInstallCA VersionNT>502 1 LaunchConditions 2 --- snip --- 'CustomAction' table: --- snip --- SkipInstallCA 1 redistca SkipInstall --- snip --- 'LaunchCondition' table: --- snip --- (NOT VersionNT64) [WrongPackage] --- snip --- That custom action 'SkipInstall' (redistca.dll) is a stub that unconditionally returns 0x103 = ERROR_NO_MORE_ITEMS (259). Microsoft documentation, custom action return values: https://learn.microsoft.com/en-us/windows/win32/msi/custom-action-return-va… ("Custom Action Return Values") --- snip --- ERROR_NO_MORE_ITEMS Skip remaining actions, not an error. --- snip --- So the sequence must stop at 'SkipInstallCA' with success on Vista and newer ('VersionNT>502'), regardless of prefix bitness. Wine instead continues to 'LaunchConditions'. That is only fatal in a 64-bit prefix, where 'VersionNT64' is set, '(NOT VersionNT64)' is false and yields [WrongPackage] -> 1603. In a 32-bit prefix 'VersionNT64' is undefined, the condition passes, and the same misbehaviour goes unnoticed. Looks like Wine msi swallows the return code: https://gitlab.winehq.org/wine/wine/-/blob/wine-11.16/dlls/msi/custom.c#L322 --- snip --- static UINT custom_get_thread_return( MSIPACKAGE *package, HANDLE thread ) { DWORD rc = 0; GetExitCodeThread( thread, &rc ); switch (rc) { case ERROR_FUNCTION_NOT_CALLED: case ERROR_SUCCESS: case ERROR_INSTALL_USEREXIT: case ERROR_INSTALL_FAILURE: return rc; case ERROR_NO_MORE_ITEMS: return ERROR_SUCCESS; case ERROR_INSTALL_SUSPEND: ACTION_ForceReboot( package ); return ERROR_SUCCESS; default: ERR( "invalid Return Code %lu\n", rc ); return ERROR_INSTALL_FAILURE; } } --- snip --- ERROR_NO_MORE_ITEMS becomes ERROR_SUCCESS, hence ITERATE_Actions() continues with the next action and runs 'LaunchConditions': https://gitlab.winehq.org/wine/wine/-/blob/wine-11.16/dlls/msi/action.c#L404 --- snip --- 0168:trace:msi:ACTION_PerformAction Performing action (L"SkipInstallCA") 0168:trace:msi:ACTION_PerformAction Performing action (L"LaunchConditions") 0168:err:msi:ITERATE_Actions Execution halted, action L"LaunchConditions" returned 1603 --- snip --- You need to propagate ERROR_NO_MORE_ITEMS. MSI_IterateRecords() already maps it back to ERROR_SUCCESS, so the sequence ends successfully: https://source.winehq.org/git/wine.git/blob/wine-11.16:/dlls/msi/msiquery.c… --- snip --- if( r == ERROR_NO_MORE_ITEMS ) r = ERROR_SUCCESS; --- snip --- The existing Wine test case already exercises ERROR_NO_MORE_ITEMS but only checks the overall return value. It should also verify that a subsequent sequence action is not executed. $ wine --version wine-11.16 Regards -- 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.

Aug. 24, 2026