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

[Bug 55705] New: PDF Xchange editor crashes
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

https://bugs.winehq.org/show_bug.cgi?id=55705 Bug ID: 55705 Summary: PDF Xchange editor crashes Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: donescamillo(a)gmail.com Distribution: --- Wine 8.17 development branch. PdfXchange Editor free version i.e. not registered version. portable, version 10.0.1.371 Linux Mint 21.2 PdfXchange editor works OK, can highlight, add labels, images, whatever the free version allows. The problem is that after some time, when PdfXchange Editor is being closed, it hangs, and the dialog asking for forcing the application to close appears. This happens in previous versions, too. -- 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 28

[Bug 35456] New: Child window in a separate process dose not show
by wine-bugs＠winehq.org Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=35456 Bug ID: 35456 Summary: Child window in a separate process dose not show Product: Wine Version: 1.7.11 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: hwei.sy(a)gmail.com Classification: Unclassified Created attachment 47330 --> http://bugs.winehq.org/attachment.cgi?id=47330 source code The area of a child window from a separate process dose not show anything. While mouse events work correctly. Run the program in attachment. It will create a parent window and a child window in the same process and works fine. Then run a second instance of the program. It will create a child window in the previous parent window. This child windows dose not show. Resize the parent window, and you will see the white "shadow" of the "hidden" child window. You can still drag this "hidden" child window or 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.

2 10

[Bug 41161] New: Embedding child process' window in own window does not draw the child window properly
by wine-bugs＠winehq.org Oct. 13, 2026

Oct. 13, 2026

https://bugs.winehq.org/show_bug.cgi?id=41161 Bug ID: 41161 Summary: Embedding child process' window in own window does not draw the child window properly Product: Wine Version: 1.9.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wine(a)sagagames.de Distribution: --- OpenMPT (https://openmpt.org/) has a plugin bridge, which can be used to run VST plugins in a separate process. However, compared to a native Windows environment (or not bridging the plugins), there is a problem when drawing the plugin UI. The plugin UI window itself is a borderless window that belongs to the bridge process, and is then set as a child of the actual plugin window that belongs to the OpenMPT process using SetParent(...). This works just fine on Windows, but in Wine, the child window remains completely black. If parts of the child window are redrawn by the bridged process, they become visible, but as soon as a redraw for the parent window is issued (e.g. by setting the focus to it), these areas become black again. Steps to reproduce: 1) Install OpenMPT. 2) Create a new module. 3) Open the plugin manager ("Select" button at the bottom of the created module's window) and add any VST plugin that provides its own UI (e.g. http://www.geocities.jp/daichi1969/softsynth/index.html#down) 4) Be sure the "Use Plugin Bridge" checkbox is checked (it is also fine if it is checked but greyed out) 5) Click "Put in FX01" to load the plugin. 6) Click the "Edit" button next to the "Select" button to open the plugin's UI. 7) The UI will be completely black, with child controls becoming occasionally visible if you click them. Note that I am an OpenMPT developer, so I would be both happy with incorporating a Wine-specific fix in our codebase if there is a way to make this scenario work with Wine, or with a fix in Wine itself to make child windows from other processes work correctly. -- 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 10

[Bug 60499] New: The side panel disappears when minimizing and then maximizing the window
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=60499 Bug ID: 60499 Summary: The side panel disappears when minimizing and then maximizing the window Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: 599871338(a)qq.com Target Milestone: --- Distribution: --- This is a WinForm application, It's good on windows server. The linux version is ubuntu24.04, wine version is stable 11. I installed below components WINEPREFIX=~/.wine winetricks -q vcrun2010 vcrun2012 vcrun2013 vcrun2022 WINEPREFIX=~/.wine winetricks -q dotnet35sp1 dotnet48 WINEPREFIX=~/.wine winetricks -q dotnetdesktop7 dotnetdesktop8 dotnetdesktop9 dotnetdesktop10 WINEPREFIX=~/.wine winetricks -q corefonts cjkfonts WINEPREFIX=~/.wine winetricks -q gdiplus dxvk vkd3d WINEPREFIX=~/.wine winetricks webview2 launch cmd: WINEPREFIX=~/.wine wine myapp.exe When minimizing and then maximizing a WinForm application window, I can observe that the window repaints, yet the sidebar disappears. There is no logs for maximizing action. Hope from your help. -- 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 60498] New: crypt32: CryptQueryObject() reports some BER-encoded PFX files as CERT_QUERY_CONTENT_PKCS7_SIGNED
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=60498 Bug ID: 60498 Summary: crypt32: CryptQueryObject() reports some BER-encoded PFX files as CERT_QUERY_CONTENT_PKCS7_SIGNED Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- CryptQueryObject(CERT_QUERY_OBJECT_BLOB, ..., CERT_QUERY_CONTENT_FLAG_ALL, ...) returns CERT_QUERY_CONTENT_PKCS7_SIGNED (8) instead of CERT_QUERY_CONTENT_PFX (12) for some PKCS#12 files that use indefinite-length BER encoding, as written by BouncyCastle (C#, Pkcs12Store.Save()). .NET Framework's X509Certificate2 picks the import path from the CryptQueryObject() result, so the PFX import never runs for such a file and loading the certificate with its key fails. Seen with SALTO ProAccess Space 6.14, which loads such PFX files (EC keys) under .NET Framework 4.8. Cause: when CRYPT_QuerySignedMessage() fails to decode the blob as a ContentInfo-wrapped message, it falls back to decoding it as a bare SignedData (CryptMsgOpenToDecode(CMSG_SIGNED)). A PFX is SEQUENCE { INTEGER 3, SEQUENCE authSafe (ContentInfo), SEQUENCE macData }, and for some files the lenient SignedData decoder accepts that; a +crypt trace shows CryptDecodeObjectEx for the signed info returning 1 for the PFX. Whether it happens depends on the data: of two PFX files written by the same code, the 951-byte EC one is misdetected, the 2378-byte RSA one is not. Reproducer (attached): bc-ec.pfx (throwaway EC P-256 test certificate, CN=Test CA, empty password) and pfxcheck.c from bug 60497: wine pfxcheck.exe bc-ec.pfx Wine 11.19: CryptQueryObject content type: 8 with the patch: CryptQueryObject content type: 12 (The import of this particular file additionally needs the patches from bug 60497 and, for the EC key, bug 60486.) A suggested patch is attached (tested on Wine 11.19, applies to master too): only use the bare-SignedData fallback when the outer SEQUENCE starts with an INTEGER followed by a SET, as SignedData does (version, digestAlgorithms); a PFX has a SEQUENCE in that position. 32- and 64-bit tested; crypt32 conformance tests unchanged. This is a heuristic precheck; making the SignedData decoder itself stricter would arguably be the better fix. Not done yet: a conformance test with such a PFX blob in tests/object.c. -- 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 60497] New: crypt32: PFXImportCertStore() fails for a PFX with an empty password created by BouncyCastle (MAC verification failed)
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=60497 Bug ID: 60497 Summary: crypt32: PFXImportCertStore() fails for a PFX with an empty password created by BouncyCastle (MAC verification failed) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- PFXImportCertStore() with an empty password fails for PKCS#12 files written by BouncyCastle (C#, Pkcs12Store.Save() with an empty password; seen with BouncyCastle.Crypto 1.8): GnuTLS error: The Message Authentication Code verification failed. The same files import on Windows. In my case, SALTO ProAccess Space 6.14 stores such PFX files (per-device certificates, EC keys) and loads them with X509Certificate2 in .NET Framework 4.8. That works on Windows and fails under Wine. Cause: for an empty password BouncyCastle computes the MAC over a zero-length password, instead of a single BMPString null character (00 00). open_cert_store() always passes "" to gnutls_pkcs12_verify_mac(), which GnuTLS turns into 00 00, so the MAC check fails. gnutls_pkcs12_verify_mac(p12, NULL) succeeds. Windows accepts both encodings of an empty password, and OpenSSL also accepts these files with an empty password. Reproducer (attached): pfxcheck.c (plain C, mingw-w64: x86_64-w64-mingw32-gcc pfxcheck.c -lcrypt32) and bc-empty.pfx (throwaway RSA test certificate, CN=test, empty password, written with pfxgen.cs/BouncyCastle): wine pfxcheck.exe bc-empty.pfx Wine 11.19: PFXImportCertStore(""): FAILED with the patch: PFXImportCertStore(""): OK, cert 1, private key: yes The same file re-saved with the password "test" imports fine on unpatched Wine, so this concerns only the empty-password case. (Unpatched Wine also leaves the last error unset on this failure; that is bug 60234.) A suggested patch is attached (tested on Wine 11.19, applies to master too): if the MAC check fails and the password is empty, retry gnutls_pkcs12_verify_mac() with NULL, and if that succeeds use NULL for the bag decryption too. 32- and 64-bit tested; crypt32 conformance tests unchanged. For builds with the old WoW64 layout, the i386-unix crypt32.so needs it as well. Not done yet: a conformance test (a small BouncyCastle-style PFX with a zero-length-password MAC embedded in tests/store.c or tests/main.c would do 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.

1 4

[Bug 58921] New: WebView2 does not work with Windows version setting 8.1 or newer
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=58921 Bug ID: 58921 Summary: WebView2 does not work with Windows version setting 8.1 or newer Product: Wine Version: 10.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: felixhaedicke(a)web.de Distribution: --- Created attachment 79605 --> http://bugs.winehq.org/attachment.cgi?id=79605 webview.log (log created by WebView2) For testing WebView2, I am using my "SimpleWebView2Browser", see https://github.com/felixhaedicke/SimpleWebView2Browser for source code and binaries. Steps to get it running on a fresh wineprefix: * Install WebView2 runtime using the "Evergreen Standalone Installer" for x64 from Inst https://developer.microsoft.com/en-us/microsoft-edge/webview2 * Set Windows version to Windows 7 or 8. * Use my "SimpleWebView2Browser" binaries from https://github.com/felixhaedicke/SimpleWebView2Browser/releases/tag/v0.1 It is sufficient to set the Windows version for "msedgewebview2.exe" (which is part of the WebView2 runtime): wine reg add "HKEY_CURRENT_USER\Software\Wine\AppDefaults\msedgewebview2.exe" /v Version /t REG_SZ /d win8 It does not work with Windows version set to 8.1, 10 or 11. The problem is probably that WebView2 tries to use the DirectComposition API on Windows 8.1 or newer. Message in the WebView2 debug log: DCompositionCreateDevice failed: Not implemented. (0x80004001) The attached WebView2 debug log was captured using the WebView2 logging functions, which can be enabled using the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable. Command line used to start the browser process, and to capture the attached logs: WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS="--enable-logging --v=1 --log-file=c:/webview.log" wine SimpleWebView2Browser.exe 2> wine-output.txt -- 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 23

[Bug 60334] New: Steam: UI stops responding after repeatedly launching games due to rpcrt4 wait handle limit
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60334 Bug ID: 60334 Summary: Steam: UI stops responding after repeatedly launching games due to rpcrt4 wait handle limit Product: Wine Version: 11.17 Hardware: x86-64 URL: https://cdn.akamai.steamstatic.com/client/installer/St eamSetup.exe OS: Linux Status: NEW Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Target Milestone: --- Distribution: ArchLinux *The analysis in this bug report was assisted by ChatGPT, and all results were verified through my own testing.* This may be related to bug #46871, which contains the same 'rpcrt4_protseq_np_wait_for_new_connection' error for a different application. I am filing this separately because the affected application, the user-visible failure and the reproduction steps are different and in this case I was able to confirm that the wait handle count reaches 65. I have been experiencing this bug for years with vanilla Wine as well, not just Wine-Staging. During the operation of the Windows Steam client, after launching and closing about 11–13 games consecutively, the Steam UI stops responding to left-clicks. In every instance, the following error appears in the terminal: 017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 Interestingly, the top menu bar options can still be opened with the mouse, but none of the menu items can be clicked or activated. If the bug occurs while a game is currently running, the game itself is unaffected. However, after exiting the game, Steam continues to show the status as "Running" because the window no longer updates. No new game could be launched anymore because Steam became unresponsive. The only workaround at this point is to terminate the entire Wine environment along with Steam using the wineserver -k command. Restarting Steam/Wine resets the problem temporarily, but it returns after repeatedly launching and exiting games. Tested with wine-11.17-250-g14947569cf7. To reproduce: The Steam Overlay was disabled globally in the Steam client. I also disabled both GameOverlayRenderer.dll and GameOverlayRenderer64.dll through DLL overrides. I repeatedly launched and exited the same game, with only one game running at a time. After every exit, I waited 5–10 seconds for the game process to terminate completely and for Steam Cloud synchronization to finish. After exiting the game for the 13th time, the following error appeared and the Steam UI stopped responding: 33434.271:0020:017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 I started Steam with: WINEDEBUG=-all,+pid,+timestamp,err+rpc \ WINEPREFIX=... wine steam.exe &> steam-rpc-error.log *Analysis* The process ID in the log is 0020. wine tasklist confirmed that Windows PID 32 (0x20) belongs to steam.exe, so the error is emitted by the main Steam process rather than by a game or steamwebhelper.exe. The number of steamwebhelper.exe processes did not increase after launching and exiting games. The game processes also terminated correctly. To determine the number of handles passed to WaitForMultipleObjectsEx(), I temporarily changed this line in dlls/rpcrt4/rpc_transport.c ERR("wait failed with error %ld\n", GetLastError()); to: ERR("wait failed with error %ld, wait handle count %u\n", GetLastError(), count); The resulting output was: 33434.271:0020:017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87, wait handle count 65 The failure occurs when the RPC named-pipe wait array in steam.exe reaches 65 handles, exceeding MAXIMUM_WAIT_OBJECTS (64). Wine's rpcrt4_protseq_np_wait_for_new_connection() passes the complete array to a single WaitForMultipleObjectsEx() call, which then returns ERROR_INVALID_PARAMETER (87) This appears to be an accumulation of RPC named-pipe listeners in the long-running Steam process combined with Wine's inability to wait for more than 64 of them in this code path. Once the wait fails, the RPC server thread terminates and the Steam client becomes unusable. -- 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 6

[Bug 36958] New: Wine emulates file creation time instead of fetching it from the underlying filesystem
by wine-bugs＠winehq.org Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=36958 Bug ID: 36958 Summary: Wine emulates file creation time instead of fetching it from the underlying filesystem Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P5 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: t.artem(a)mailcity.com Created attachment 49071 --> http://bugs.winehq.org/attachment.cgi?id=49071 Far2 showing file modification/creation/lass access times. In Linux at least ext4 supports file creation time field (crtime), but Wine doesn't use it. Instead it uses mtime. Please, implement crtime for filesystems which impelement this field. -- 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.

3 14

[Bug 57031] New: Mouse "tremble" in Robin Hood: The Legend of Sherwood (GoG).
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=57031 Bug ID: 57031 Summary: Mouse "tremble" in Robin Hood: The Legend of Sherwood (GoG). Product: Wine-staging Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: flaubertSt(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Installed GoG version of Robin Hood: The Legend of Sherwood. All works, but mouse tremble when in game (it DOESN'T with menu screens). Tried "mouse warp override -all options-but it didnt solve. Strangely, I changed from WINE-9.1-staging to 9.0 stable version and it doesn't tremble anymore, but now it has some lag when exit from pause: see Bug 39513). -- 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 16

[Bug 60189] New: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60189 Bug ID: 60189 Summary: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: fcasas(a)codeweavers.com Target Milestone: --- Distribution: --- Created attachment 81874 --> http://bugs.winehq.org/attachment.cgi?id=81874 Screenshot with highlighted artifacts. Recent upstream vkd3d-shader updates allow the game shaders to compile correctly. However I noticed that updating Wine itself (on a Wine with custom vkd3d build) introduces small, previously unseen, visual artifacts. These artifacts consist in some flickering black stains that can be easily seen in the characters in the intro animation. They are easier to spot in motion but I attach a screenshot highlighting them. I ran a bisection and concluded that this bug is introduced in commit 306c3af83faca8bd384df24d370a863cab5ed394 d3dx9: No longer prefer native. So it might be considered a regression. -- 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 8

[Bug 60487] New: wbemprox: Win32_Service lacks Description, PathName, StartName and ChangeStartMode()
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60487 Bug ID: 60487 Summary: wbemprox: Win32_Service lacks Description, PathName, StartName and ChangeStartMode() Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Programs that manage Windows services through WMI (System.Management in .NET) fail: - reading Win32_Service.Description, .PathName or .StartName returns WBEM_E_NOT_FOUND (0x80041002); - invoking Win32_Service.ChangeStartMode returns WBEM_E_METHOD_NOT_IMPLEMENTED (0x80041055). Steps (.NET 4.8): foreach (ManagementObject s in new ManagementObjectSearcher( "SELECT * FROM Win32_Service WHERE Name='Spooler'").Get()) { Console.WriteLine(s["PathName"]); // 0x80041002 s.InvokeMethod("ChangeStartMode", new object[] { "Manual" }); // 0x80041055 } Suggested patch attached (tested on Wine 11.19, applies to master): - new columns Description (QueryServiceConfig2W(SERVICE_CONFIG_DESCRIPTION)), PathName (lpBinaryPathName) and StartName (lpServiceStartName, "LocalSystem" when empty, as Windows reports it); - new method ChangeStartMode(in StartMode, out ReturnValue) using ChangeServiceConfigW(); unknown mode returns 21, other errors go through map_error(). wbemprox conformance tests: unchanged (the one query failure seen is present without the patch too). Open points: Description costs an extra OpenService()+QueryServiceConfig2W() per service during table fill; Change(), DelayedAutoStart, ErrorControl, ExitCode etc. are still missing; no new tests yet. -- 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 60488] New: httpapi: only one URL per URL group, HttpWaitForDisconnectEx() unimplemented (HTTP Server API 2.0 servers fail)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60488 Bug ID: 60488 Summary: httpapi: only one URL per URL group, HttpWaitForDisconnectEx() unimplemented (HTTP Server API 2.0 servers fail) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Self-hosted HTTP servers built on HTTP Server API 2.0 (for example ASP.NET Core 1.x WebListener on .NET Framework 4.8) do not work: 1. A second HttpAddUrlToUrlGroup() on the same URL group returns ERROR_CALL_NOT_IMPLEMENTED, so a server listening on more than one prefix refuses to start. 2. HttpSetUrlGroupProperty(HttpServerTimeoutsProperty) returns ERROR_CALL_NOT_IMPLEMENTED (bug 49819); other tuning properties likewise. 3. HttpWaitForDisconnectEx() is only a spec-file stub; the server calls it for every request to build its "request aborted" token, the stub raises, and every request answers HTTP 500. HttpCancelHttpRequest(), HttpShutdownRequestQueue() and the Http*Query*Property() functions are missing as well. Suggested patch attached (tested on Wine 11.19, applies to master): - URL groups keep an array of (URL, context) and add/remove/bind all of them; - HttpSetUrlGroupProperty / HttpSetServerSessionProperty / HttpSetRequestQueueProperty: FIXME and succeed for properties that only tune behaviour; - HttpWaitForDisconnect(Ex): semi-stub - with OVERLAPPED return ERROR_IO_PENDING and never complete, otherwise ERROR_NOT_SUPPORTED; - HttpCancelHttpRequest / HttpShutdownRequestQueue: stubs returning success; Http*Query*Property: stubs returning ERROR_CALL_NOT_IMPLEMENTED; - removes 7 todo_wine in tests/httpapi.c that now pass (additional invalid/duplicate URLs in a group return the same errors as on Windows). httpapi tests: 0 todo, 0 failures on i386 and x86_64. This is a suggestion, not upstream-ready: a real HttpWaitForDisconnectEx() needs an http.sys IOCTL that completes when the connection closes (the semi-stub leaves one pending operation per connection until the queue closes); silently accepting properties may hide differences; the 32-URL array is arbitrary. -- 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 60486] New: crypt32: PFXExportCertStoreEx() and PFXImportCertStore() do not support ECDSA (CNG) keys
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60486 Bug ID: 60486 Summary: crypt32: PFXExportCertStoreEx() and PFXImportCertStore() do not support ECDSA (CNG) keys Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Exporting or importing a PFX whose private key is an ECDSA key fails. 1. Export: X509Certificate2.Export(X509ContentType.Pfx) in .NET Framework 4.8 for a certificate with a CNG ECDSA P-256 key crashes. PFXExportCertStoreEx() always asks NCrypt for BCRYPT_RSAFULLPRIVATE_BLOB, which ends in bcrypt's RSA export code with an EC key (page fault inside the RSA key accessor). 2. Import: new X509Certificate2(pfxBytes, password, flags) with an EC key fails with CRYPT_E_BAD_ENCODE (0x80092002). The unix side (open_cert_store) rejects every key that is not GNUTLS_PK_RSA, and the PE side only knows how to import RSA keys into a CAPI provider. Steps (any .NET 4.8 program, 32- or 64-bit): var ec = ECDsa.Create(ECCurve.NamedCurves.nistP256); var req = new CertificateRequest("CN=test", ec, HashAlgorithmName.SHA256); var cert = req.CreateSelfSigned(DateTimeOffset.Now, DateTimeOffset.Now.AddYears(1)); var pfx = cert.Export(X509ContentType.Pfx, "pw"); // crash var back = new X509Certificate2(pfx, "pw", X509KeyStorageFlags.Exportable); // 0x80092002 (CreateSelfSigned itself needs the ncrypt changes from bug 60443.) A suggested patch is attached (tested on Wine 11.19, applies to master too): - PFXExportCertStoreEx(): read NCRYPT_ALGORITHM_GROUP_PROPERTY and export BCRYPT_ECCPRIVATE_BLOB for ECDSA/ECDH; unix export_cert_store builds the key with gnutls_x509_privkey_import_ecc_raw(GNUTLS_ECC_CURVE_SECP256R1). - open_cert_store accepts GNUTLS_PK_ECDSA; import returns a BCRYPT_ECCPRIVATE_BLOB built with gnutls_x509_privkey_export_ecc_raw(). - PFXImportCertStore(): ECC blobs are imported with NCryptOpenStorageProvider(MS_KEY_STORAGE_PROVIDER) + NCryptImportKey() and attached with CERT_NCRYPT_KEY_HANDLE_PROP_ID plus a CNG CERT_KEY_PROV_INFO, so HasPrivateKey is true and CryptAcquireCertificatePrivateKey() returns the NCrypt handle. RSA keeps the existing CAPI path. With it, export/import round trip and signing with the imported key work (32- and 64-bit); crypt32 conformance tests are unchanged. Limitations, why this is a suggestion rather than a finished patch: P-256 only; the CERT_KEY_PROV_INFO names a container that does not exist (Wine has no persisted NCrypt keys); PKCS12_ALWAYS_CNG_KSP is still ignored; no new tests yet. Possibly related: bug 59038. -- 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 3

[Bug 60489] New: http.sys: responses larger than 4 MiB are truncated (short send() on non-blocking socket ignored)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60489 Bug ID: 60489 Summary: http.sys: responses larger than 4 MiB are truncated (short send() on non-blocking socket ignored) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- With HttpSendHttpResponse()/HttpSendResponseEntityBody(), responses larger than about 4 MiB arrive truncated: Content-Length is correct but the body stops at exactly 4,194,304 bytes and the client waits until it times out. Cause: the connection socket in http.sys is non-blocking (WSAEventSelect()), and http_send_response() does a single send() and ignores a short write. Suggested patch attached (tested on Wine 11.19, applies to master): loop until the whole buffer is sent; on WSAEWOULDBLOCK wait with select() (30 s) and continue; on timeout or error fail as before. With it a 4.4 MB file is served completely. Open point: the wait happens while holding http_cs, so a slow client can stall the other connections for up to the timeout. A cleaner design would queue unsent data on the connection and resume on FD_WRITE before completing the IRP. No new test yet (suggestion: send a several-MiB response and check the received length). -- 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 5

[Bug 60473] New: ncrypt: NCryptEncrypt rejects NCRYPT_PAD_OAEP_FLAG (NTE_NOT_SUPPORTED), NCryptDecrypt is a stub
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60473 Bug ID: 60473 Summary: ncrypt: NCryptEncrypt rejects NCRYPT_PAD_OAEP_FLAG (NTE_NOT_SUPPORTED), NCryptDecrypt is a stub Product: Wine Version: 11.19 Hardware: x86-64 URL: https://github.com/re-codesys/codesys-wine OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: strucc.c(a)gmail.com Target Milestone: --- Distribution: Debian Symptom: Recent versions of CODESYS IDE are using encrypted communication to the Gateway and PLC devices. On WINE however, initiating online connection fails with Unknown error "-2146893783". Affected application: CODESYS V3.5 SP22 Patch 4 (64-bit, .NET Framework 4.8; installer "CODESYS 64 3.5.22.40.exe") Download: https://store.codesys.com/en/codesys.html Description On Windows11 NCryptEncrypt with an RSA key and NCRYPT_PAD_OAEP_FLAG (0x4) encrypts with RSA-OAEP. In WINE NCryptEncrypt rejects the flag with NTE_NOT_SUPPORTED (0x80090029), and NCryptDecrypt is a stub that fails the same way, so RSA-OAEP through the CNG key storage API is not usable. Trace (WINEDEBUG=+ncrypt): trace:ncrypt:NCryptImportKey (..., L"RSAPUBLICBLOB", ..., 283, 0) trace:ncrypt:NCryptEncrypt (..., 60, ..., 0x4) fixme:ncrypt:NCryptEncrypt No padding and oaep padding not supported Code: dlls/ncrypt/main.c (wine-11.19, same on master) Bcrypt handles RSA-OAEP since 11.5 (https://bugs.winehq.org/show_bug.cgi?id=58342) so ncrypt seems to lack only the pass-through of the OAEP padding information (BCRYPT_OAEP_PADDING_INFO) to BCryptEncrypt and BCryptDecrypt. Additional information See: https://github.com/Re-CODESYS/codesys-wine for 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.

1 4

[Bug 60474] New: shell32: IShellLinkDataList::RemoveDataBlock is a stub (E_NOTIMPL)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60474 Bug ID: 60474 Summary: shell32: IShellLinkDataList::RemoveDataBlock is a stub (E_NOTIMPL) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)list.winehq.org Reporter: strucc.c(a)gmail.com Target Milestone: --- Distribution: Debian Symptom: Programs that build a shortcut through IShellLink and then remove one of its data blocks fail with "The method or operation is not implemented" (.NET: NotImplementedException from IShellLinkDataList.RemoveDataBlock). Affected application: CODESYS V3.5 SP22 Patch 4. PackageManagerCLI.exe (3.5.22.40 Description: When package installer (PackageManagerCLI.exe) creates "Start menu" links for Executables from add-on packages, it's calling RemoveDataBlock(EXP_SZ_ICON_SIG) on each link. The package installation stops at the first link, or without --cancelOnException. The links are not created. On Windows IShellLinkDataList::RemoveDataBlock removes the extra data block with the given signature from the link (S_FALSE when there is none). In WINE it returns E_NOTIMPL. Trace (WINEDEBUG=fixme+shell): fixme:shell:ShellLink_RemoveDataBlock (...)->(2684354567): stub 2684354567 = 0xA0000007 (EXP_SZ_ICON_SIG). Code: dlls/shell32/shelllink.c Additional information, fix See: https://github.com/Re-CODESYS/codesys-wine for 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.

1 3

[Bug 44382] New: Overcooked: Right shift is detected as left shift instead
by wine-bugs＠winehq.org Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=44382 Bug ID: 44382 Summary: Overcooked: Right shift is detected as left shift instead Product: Wine Version: 3.0-rc6 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)winehq.org Reporter: paradigmsort(a)gmail.com Created attachment 60304 --> https://bugs.winehq.org/attachment.cgi?id=60304 wine stdout and stderr In the Steam version of Overcooked, pressing right shift is interpreted as left shift instead. $ gsha1sum ~/.wine/drive_c/Program\ Files/Steam/steamapps/common/Overcooked/Overcooked.exe 23c37601e4b4a85b3e8fb6dc74393693dd805137 /Users/paradigmsort/.wine/drive_c/Program Files/Steam/steamapps/common/Overcooked/Overcooked.exe This occurs with built-in Macbook Pro 2015 keyboard, as well as with both external USB keyboards I own. Right shift is registered correctly in mac application on my system. I reproduced with both devel 3.0-rc6 and stable 3.0. Left shift is also reported as right shift in other windows applications, for example this simple key press display app: http://www.dcmembers.com/skrommel/download/showoff/# $ gsha1sum ShowOff.exe 3357fa8259c79d4fcdfa7c14309edefe6622a074 ShowOff.exe It does NOT occur (in either application) when I set the key "graphics" HKCU/Software/Wine/Drivers to "x11" and use X11 graphics instead. I don't believe this is a duplicate of 33142; that was about right shift key having no functionality at all (and is from 2013 and a very old version of wine). Running MacOS Sierra 10.12.6 -- 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 3

[Bug 39618] New: TeamViewer 11 "File Not Found" info window during installation
by wine-bugs＠winehq.org Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=39618 Bug ID: 39618 Summary: TeamViewer 11 "File Not Found" info window during installation Product: Wine Version: 1.7.55 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sasha969(a)hotmail.com Distribution: --- Created attachment 52789 --> https://bugs.winehq.org/attachment.cgi?id=52789 Info copied from trminal using winedbg. Installation starts fine. At the end of folders creation process Wine shows "File not Found" error but after that installation continues and finish without a problem. -- 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 15

[Bug 60263] New: winemac.drv: cross-process child window Metal swapchains not implemented (Steam client renders black); the CAContext/CALayerHost route already exists and is only reached from vulkan.c
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60263 Bug ID: 60263 Summary: winemac.drv: cross-process child window Metal swapchains not implemented (Steam client renders black); the CAContext/CALayerHost route already exists and is only reached from vulkan.c Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv contains this FIXME: Cross-process child window Metal swapchains are not implemented This is the whole reason Steam's client renders as a black window under Wine on macOS, and the route to fix it already exists in the tree — it is simply never reached from the Metal side. ## What happens Steam's CEF GPU process asks for a Metal view for a child window whose root lives in the *browser* process. `get_win_data()` returns NULL by construction for a foreign HWND — `win_datas` is a process-local CFDictionary — and the caller aborts on the null view by design. Chromium restarts the GPU process, it dies identically, and after ~6 attempts it gives up. Black window. Two things make this hard to spot: - The `CreateSwapChain` cross-process guard never fires for this window, because `GetWindowThreadProcessId()` says the *child* belongs to us. The Win32 process check and winemac's realization check disagree, and the path trusts the first. - It is backend-independent: forcing `--use-angle=swiftshader` (no Metal, no GPU driver at all) produces the same crash count and a byte-identical black capture. ## The route already in the tree `macdrv_client_surface_acquire_metal_swapchain()` builds a `CAContext`-backed offscreen swapchain and posts `WM_MACDRV_CREATE_REMOTE_LAYER` to the window's owning process, which hosts it via `CALayerHost`. That is exactly the cross-process case. In stock Wine only `vulkan.c` reaches it. Wiring the Metal side to fall back to that route when `get_win_data()` returns NULL makes Steam's client render completely, out-of-process, with text, no injected switches and 0 GPU crashes. ## Working implementation, for reference A working version of both halves is public here, under MIT: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/wi… Notes from getting it working, in case they save someone time: - **Do not add a member to `macdrv_functions_t`** to expose the entry point — that struct is `C_ASSERT`-ed at a fixed size, so a client built against a larger struct would read past the end of an older winemac's and call whatever followed. A standalone exported symbol degrades safely. - **Convert Win32 pixels to Cocoa points at the CALayerHost entry points.** `CALayer.frame` is in points; unconverted frames are 2x too large on retina and the content is pushed down and right. - **Stack the hosted layers by Win32 paint order, not insertion order.** CEF recreates a swapchain on every resize, so insertion order puts whichever browser was recreated last on top. Steam runs two sibling browsers and the client goes black. - **An empty child rect is not "no rect".** CEF keeps an inactive browser in the z-order at 0x0; treating that as "no rect supplied" and stretching the layer over the view blacks the window. - **Retire a superseded layer on CREATE, not on destroy**, or the child is unhosted between the two and the window blinks through during a resize. ## Disclosure This was investigated with heavy AI assistance, so I am filing a report rather than a patch, and the implementation above is offered only as a reference someone may or may not want to look at. I am also aware of the relicensing discussion in 3Shain/dxmt#152 and am not asking for anything to be taken as-is. -- 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 6

[Bug 60494] New: macOS: 32-bit programs crash or hang at random in WoW64 mode under Rosetta; wow64cpu's 64-bit thunk code runs in 32-bit mode (wine-mono, Direct3D 9)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60494 Bug ID: 60494 Summary: macOS: 32-bit programs crash or hang at random in WoW64 mode under Rosetta; wow64cpu's 64-bit thunk code runs in 32-bit mode (wine-mono, Direct3D 9) Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: alice.easterdevelops(a)gmail.com Target Milestone: --- **Wine:** 11.18 (Gcenx build, stock), 11.0 (Gcenx stable) · **wine-mono:** 11.3.0, 10.4.1, 9.0.0 · **macOS:** 15.5, Apple M1 (Rosetta 2) **Symptom:** a 32-bit .NET program never starts. - On 11.18 one thread spins at 100% CPU and no window appears. - On 11.0 wine-mono prints "Native Crash Reporting … Got a UNKNOWN while executing native code". The same source compiled for x64 runs fine. Native 32-bit programs (D3D8/D3D9 test programs, the Irrlicht engine demos) also run fine on 11.18. **Repro:** ``` // hello.cs class P { static void Main() { System.Console.WriteLine("hello from " + (System.IntPtr.Size * 8) + "-bit"); } } ``` ``` wine 'Z:\…\share\wine\mono\wine-mono-11.3.0\lib\mono\4.5\mcs.exe' -platform:x86 -out:hello32.exe hello.cs wine 'Z:\…\share\wine\mono\wine-mono-11.3.0\lib\mono\4.5\mcs.exe' -platform:x64 -out:hello64.exe hello.cs wine hello64.exe # prints "hello from 64-bit" wine hello32.exe # hangs (11.18) / mono native crash (11.0) ``` Real-world case: Secrets of Grindea (Steam 269770, an XNA 4.0 game with CLR flags ILONLY|32BITREQUIRED) shows the same hang. **What `+seh` shows (11.18):** exactly one exception, then the spin: ``` trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=7BF21135 trace:seh:dispatch_exception info[0]=00000000 trace:seh:dispatch_exception info[1]=00002EC5 trace:seh:dispatch_exception eip=7bf21135 … cs=0107 ds=0023 es=0023 fs=010f gs=0023 ss=0023 ``` `7BF20000` is `wow64cpu.dll`. At +0x1135 is the 64-bit syscall entry path (just after `xchg %rsp,%r14` at +0x110c): ``` 7a401135: 8b 15 c5 2e 00 00 mov 0x2ec5(%rip),%edx ``` The fault address 0x2EC5 is how that instruction decodes in **32-bit** mode, where it reads an absolute address. So the 32-bit thread reached the 64-bit syscall entry without switching to 64-bit mode. With `+relay`, the fault comes right after `wow64cpu.BTCpuResetToConsistentState` → `RtlWow64SetThreadContext`, i.e. after Mono's first handled exception, when the 32-bit context is restored. **Comparison:** CrossOver 24.0.7 (Wine 9-based, also "starting … in experimental wow64 mode", also using `wow64cpu.dll`) runs `hello32.exe` and the game. Swapping wine-mono 9.0.0 into an 11.18 prefix still hangs, so the regression is on the Wine side, somewhere between Wine 9 and 11.0. **Guess:** after `RtlWow64SetThreadContext` restores a 32-bit context on macOS, the code segment used for the next 32→64 far transition is wrong (`cs=0107`), so the jump to the 64-bit syscall entry stays in 32-bit mode. **Update (2026-10-11, Wine 11.18 stock and patched, macOS 27.0.1): not specific to .NET.** Native 32-bit programs hit the same fault intermittently. Minimal repro (no .NET, ~30 lines): a 32-bit program whose second thread loops `Direct3DCreate9` → `GetAdapterIdentifier` → `GetDeviceCaps` → `Release` (wined3d's OpenGL adapter setup) for 15 s, while the main thread sleeps (`d3dprobe adapterloop`, https://github.com/codeWonderland/neutron/blob/main/tools/d3dprobe/d3dprobe…) | Build | 32-bit runs failing | 64-bit runs failing | |---|---|---| | Wine 11.18 stock (Gcenx wine-devel) | 4 of 8 (3 crashes, 1 thread stuck) | — | | Wine 11.18 + our patches | 4 of 8 (2 crashes, 2 stuck) | 0 of 4 | | CrossOver 24 (Wine 9, Sikarugir engine) | 0 of 8 | — | The crash is the same decode-in-the-wrong-mode fault at the neighbouring entry point: ``` wine: Unhandled page fault on read access to 00002DC1 at address 7BF21239 7a401239: 8b 15 c1 2d 00 00 mov 0x2dc1(%rip),%edx ; wow64cpu +0x1239, after xchg %rsp,%r14 at +0x1210 ``` with `cs=002b ss=0000` in the record and "Exception frame is not in stack limits => unable to dispatch exception" in other runs; stuck runs have a thread under `_sigtramp` → ntdll.so while Rosetta's exception-server thread spins. A real game, Dungeon Defenders 2's 32-bit build, fails the same way at the same address in most launches. A plain stress of 1M+ handled access violations (`IsBadReadPtr`) plus system calls on other threads does **not** reproduce it, so the OpenGL adapter setup (Apple's OpenGL, itself translated) seems to be the trigger. **Tried (doesn't fix it):** generating the 32→64 thunks as `push cs64; push target; lret` instead of `ljmp *m16:32` (same stack effect). With that wow64cpu.dll, `adapterloop` still failed 3 of 12 runs (vs 4 of 8), some now dying silently with no Wine fault message or macOS crash report. So it's not specific to the far-jump encoding; the mode state itself seems to be lost around these transitions under Rosetta (possibly when a signal is delivered or returns during or right after a switch). (Analysis and testing were done with AI assistance; the measurements are from my own Mac. Patches are linked for reference.) -- 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 60493] New: winemac.drv: deadlock between macdrv_surface_flush and macdrv_WindowPosChanged (Unreal Engine games hang on splash screen)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60493 Bug ID: 60493 Summary: winemac.drv: deadlock between macdrv_surface_flush and macdrv_WindowPosChanged (Unreal Engine games hang on splash screen) Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: alice.easterdevelops(a)gmail.com Target Milestone: --- **Wine version:** 11.18 (Gcenx macOS build); code unchanged on master as of 2026-10-09 **OS:** macOS 15.5, Apple Silicon (Rosetta 2) **Summary** Since commit 1a1d1f3f ("winemac.drv: Hide client_view when flushing window surfaces"), `macdrv_surface_flush` calls `get_win_data`, which blocks on `win_data_mutex`. Window surface flushes can run while win32u holds its user lock, and `macdrv_WindowPosChanged` takes the same two locks in the opposite order, so two threads can deadlock. Seen with Deep Rock Galactic (UE4): its launcher splash is a layered window updated from one thread while the main thread creates the game window. The game stays on the splash forever (roughly 6 of 6 launches here). Attaching a debugger unsticks it. **Stacks (macOS `sample`)** Thread A (splash): ``` NtUserSetLayeredWindowAttributes update_window_state apply_window_pos (get_win_ptr: user lock held) update_surface_region window_surface_set_shape window_surface_flush macdrv_surface_flush (surface.c:125) get_win_data -> waits for win_data_mutex ``` Thread B (main thread, creating the game window): ``` NtUserCreateWindowEx ... macdrv_WindowPosChanged (holds win_data_mutex) set_cocoa_window_properties (window.c:248) NtUserGetWindowLongW -> waits for the user lock ``` **Possible fix** Don't block on `win_data_mutex` in the flush path. For example, a `try_get_win_data` that uses `pthread_mutex_trylock` (the mutex is recursive, so a thread that already holds it still succeeds); if it's busy, hiding `client_view` is left to the next flush. A patch doing this (about 25 lines) fixes the hang here: 4 of 4 launches reach the game window. ```diff --- a/dlls/winemac.drv/surface.c +++ b/dlls/winemac.drv/surface.c - if ((data = get_win_data(window_surface->hwnd))) + if ((data = try_get_win_data(window_surface->hwnd))) ``` (full patch: tools/wine-dxmt/winemac-flush-deadlock.patch in https://github.com/codeWonderland/neutron) **Patch (for reference):** https://github.com/codeWonderland/neutron/blob/main/tools/wine-dxmt/winemac… (Analysis and testing were done with AI assistance; the measurements are from my own Mac. Patches are linked for reference.) -- 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 60492] New: winemac.drv: wglCreateContextAttribsARB fails for WGL_CONTEXT_OPENGL_NO_ERROR_ARB and for 3.2+ core profiles without the forward-compatible bit
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60492 Bug ID: 60492 Summary: winemac.drv: wglCreateContextAttribsARB fails for WGL_CONTEXT_OPENGL_NO_ERROR_ARB and for 3.2+ core profiles without the forward-compatible bit Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: alice.easterdevelops(a)gmail.com Target Milestone: --- **Wine:** 11.18 (Gcenx build) · **macOS:** 27.0.1, M1 **Symptom:** Idle Colony (Steam 2843640) asserts `m_glContext` (Render/Window.cpp:38) because `wglCreateContextAttribsARB(hdc, NULL, {MAJOR 3, MINOR 3, PROFILE_MASK CORE, 0x31B3 (NO_ERROR) 0})` returns NULL. Windows drivers (and winex11, which maps the attribute to GLX) accept it. Two separate refusals in `macdrv_context_create` (dlls/winemac.drv/opengl.c): 1. `WGL_CONTEXT_OPENGL_NO_ERROR_ARB` hits `default:` → "Unknown attribute", ERROR_INVALID_PARAMETER. CGL has no no-error mode; the attribute is a hint (KHR_no_error allows reporting errors anyway), so it can be accepted and ignored. 2. Once past that, "OS X only supports forward-compatible 3.2+ contexts": a 3.2–4.1 **core** profile request without WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB is refused. A macOS core context is what the app gets either way, and Windows drivers grant it; only compatibility profiles 3.2+ really can't be created. **Patch:** https://github.com/codeWonderland/neutron/blob/main/tools/wine-dxmt/winemac… (accept/ignore 0x31B3; require the FC bit only for non-core profiles). **Repro:** `d3dprobe glcore` (https://github.com/codeWonderland/neutron/tree/main/tools/d3dprobe) creates exactly that context: "FAILED (error 87)" on stock 11.18 in 32- and 64-bit, "created" (GL 4.1 Metal) with the patch. (Related, but a compatibility shim rather than a bug: macOS core contexts reject GLSL `#version 130`/`140`, which Windows core contexts compile; Dear ImGui's OpenGL3 backend uses 130. Neutron raises them to 150 in opengl32's glShaderSource for core contexts: tools/wine-dxmt/opengl32-glsl-version.patch.) (Analysis and testing were done with AI assistance; the measurements are from my own Mac. Patches are linked for reference.) -- 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 60491] New: bcrypt: implement DES and 3DES encryption (ECB/CBC/CFB) with SymCrypt
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60491 Bug ID: 60491 Summary: bcrypt: implement DES and 3DES encryption (ECB/CBC/CFB) with SymCrypt Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: alice.easterdevelops(a)gmail.com Target Milestone: --- **Wine:** 11.18 · **Problem:** `BCryptOpenAlgorithmProvider(L"DES")` fails, so .NET's `DES` class throws `CryptographicException: Unknown error (0xc1000002)` in `DesBCryptModes.OpenDesAlgorithm`. Seen with Resonite (Steam 2519830, .NET 10), which DES-obfuscates an ID while creating its local world. (Wine also lists 3DES but implements only AES for BCryptEncrypt/BCryptDecrypt.) **Patch:** https://github.com/codeWonderland/neutron/blob/main/tools/wine-dxmt/bcrypt-… - `ALG_ID_DES`, the builtin algorithm entry and the DES_CBC/ECB/CFB pseudo-handles. - Properties: block length 8, key lengths 64/64, chaining mode get/set. - Symmetric keys carry their SymCrypt block cipher and expanded key; the existing AES ECB/CBC/CFB code paths run through them, so DES reuses them (`SymCryptDesExpandKey`, `SymCryptDesBlockCipher`). - BCryptDuplicateKey for DES. **Tested (32- and 64-bit):** FIPS 46 example (key 133457799BBCDFF1, 0123456789ABCDEF → 85E813540F0AB405), padded CBC round trip through a duplicated key, AES-128 FIPS 197 C.1 unchanged. Tests for dlls/bcrypt/tests would follow the existing AES ones. **3DES too:** the same patch makes `BCRYPT_3DES_ALGORITHM` keys work (`SymCrypt3DesExpandKey`, ECB/CBC/CFB; Wine 11.18 opens the algorithm but BCryptGenerateSymmetricKey/BCryptEncrypt fail). Checked against OpenSSL 3.4: NIST SP 800-67 sample (keys 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123, "The qufck brown fox jump" → A826FD8CE53B855F CCE21C8112256FE6 68D5C05DD9B6B900) and padded CBC with IV 0102030405060708, in 32- and 64-bit. (Analysis and testing were done with AI assistance; the measurements are from my own Mac. Patches are linked for reference.) -- 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 60490] New: d3dx9: D3DXCheckVersion rejects D3D_SDK_VERSION with the D3D_DEBUG_INFO bit (Dungeon Defenders 2 crashes at startup)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60490 Bug ID: 60490 Summary: d3dx9: D3DXCheckVersion rejects D3D_SDK_VERSION with the D3D_DEBUG_INFO bit (Dungeon Defenders 2 crashes at startup) Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d-util Assignee: wine-bugs(a)list.winehq.org Reporter: alice.easterdevelops(a)gmail.com Target Milestone: --- **Wine version:** 11.18 (Gcenx macOS build); `dlls/d3dx9_36/main.c` unchanged on master as of 2026-10-10 **OS:** macOS 27.0.1, Apple Silicon (Rosetta 2); the code path is platform-independent **Summary** Programs compiled with `D3D_DEBUG_INFO` defined get `D3D_SDK_VERSION` as `(32 | 0x80000000)` from d3d9.h, and pass that to both `Direct3DCreate9` and `D3DXCheckVersion`. Wine's `Direct3DCreate9` accepts it, but `D3DXCheckVersion` only returns TRUE for exactly 32: ```c BOOL WINAPI D3DXCheckVersion(UINT d3d_sdk_ver, UINT d3dx_sdk_ver) { return d3d_sdk_ver == D3D_SDK_VERSION && d3dx_sdk_ver == D3DX_SDK_VERSION; } ``` Dungeon Defenders 2 (Unreal Engine 3, Steam app 236110; both its Win32 and Win64 exes) calls `D3DXCheckVersion(0x80000020, 43)` from d3dx9_43 right after creating its D3D9 object, and on FALSE writes to address 3 (Unreal's assert crash), every launch, on any D3D backend. The game runs on Windows, so native d3dx9_43 accepts the value. **Disassembly at the crash (Win64 build)** ``` 140c22c8e: movl $0x2b, %edx ; D3DX_SDK_VERSION 43 140c22c93: movl $0x80000020, %ecx ; D3D_SDK_VERSION | 0x80000000 140c22c98: callq d3dx9_43!D3DXCheckVersion 140c22c9d: testl %eax, %eax 140c22c9f: jne ok 140c22ca1: movl $0xd, 0x3 ; crash ``` **Fix** Ignore the debug bit, as native does (verified with the game's 64-bit build: with this change it gets past the check and renders its intro and menu): ```diff BOOL WINAPI D3DXCheckVersion(UINT d3d_sdk_ver, UINT d3dx_sdk_ver) { - return d3d_sdk_ver == D3D_SDK_VERSION && d3dx_sdk_ver == D3DX_SDK_VERSION; + /* Programs built with D3D_DEBUG_INFO pass D3D_SDK_VERSION | 0x80000000. */ + return (d3d_sdk_ver & ~0x80000000u) == D3D_SDK_VERSION && d3dx_sdk_ver == D3DX_SDK_VERSION; } ``` A test in `dlls/d3dx9_36/tests/core.c` could check `D3DXCheckVersion(D3D_SDK_VERSION | 0x80000000, D3DX_SDK_VERSION)` on Windows to confirm native's exact rule (e.g. whether other high bits are ignored too). **Patch (for reference):** https://github.com/codeWonderland/neutron/blob/main/tools/wine-dxmt/d3dx9-c… (Analysis and testing were done with AI assistance; the measurements are from my own Mac. Patches are linked for reference.) -- 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