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

[Bug 59893] New: ws2_32: libcurl uploads throttled to ~140 KB/s
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59893 Bug ID: 59893 Summary: ws2_32: libcurl uploads throttled to ~140 KB/s Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: wine-bugtrack(a)forryan.co.uk Distribution: --- Created attachment 81216 --> http://bugs.winehq.org/attachment.cgi?id=81216 Standalone C reproducer: select() writability vs send() acceptance Overview Single-stream uploads from a libcurl-based application run far slower under Wine than on Windows; roughly 140 KB/s regardless of available bandwidth. Found with Backblaze Personal Backup (its bztransmit uploader uses libcurl), where a large backup checkpoint could not finish within the client’s 600s upload timeout. The same operation completes in ~80s with the socket behaviour corrected. Steps to reproduce (self-contained; no application or account needed) A minimal reproducer is attached (sock_writable_test.c). It: 1. Creates a connected loopback TCP pair and sets the sender non-blocking. 2. Without ever reading from the receiver, repeatedly does a zero-timeout select() for writability on the sender, then a send() of a small buffer. 3. Counts iterations where select() reported the socket NOT writable yet the following send() still succeeded. Build: x86_64-w64-mingw32-gcc -O2 -o sockw.exe sock_writable_test.c -lws2_32 Run: wine sockw.exe Actual results On unmodified Wine (built from official source, ./configure && make, clean WINEPREFIX): the sender shows many iterations where select() reports not-writable while send() still succeeds (e.g. ~230 of ~660 sends), and the program prints FAIL. A real libcurl uploader that does a select() writability pre-check before waiting on FD_WRITE therefore stalls on its poll timeout between bursts. Expected results On Windows, the same program reports zero such iterations (PASS): select() reports a connected stream socket writable whenever send() would still accept data. Wine should match this. Analysis Wine appears to derive writability from the host poll(), and on Linux POLLOUT is only set once the send queue drains below ~2/3 of SO_SNDBUF, whereas Windows reports writable while the send buffer has any room. A fix and a ws2_32:sock conformance test are being submitted via a merge request. Environment * Wine: 11.10 Unmodified, built from official source (no Staging, no third-party wrapper, no DLL overrides, clean ~/.wine). * Distribution/architecture: Ubuntu 24.04, x86_64 * WINEARCH win64/64-bit prefix. See also curl issue #6146 (“Poor upload performance in Windows”) https://github.com/curl/curl/issues/6146 and https://github.com/curl/curl/pull/5634 - the Windows FD_WRITE/select-writability semantics involved. Bug 41379 (https://bugs.winehq.org/show_bug.cgi?id=41379) is the read-side (FD_READ) analogue; this is the write side. -- 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 54963] New: Adobe Lightroom needs Windows.Storage.Streams.InMemoryRandomAccessStream
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=54963 Bug ID: 54963 Summary: Adobe Lightroom needs Windows.Storage.Streams.InMemoryRandomAccessStream Product: Wine Version: 8.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bugs(a)bzatek.net Distribution: --- Essentially any newer functionality like the advanced masking and object detection fails on unimplemented InMemoryRandomAccessStream: 0a78:fixme:combase:RoActivateInstance (00007F110172E538, 00007F110172E4F8): semi-stub 0a78:fixme:combase:RoGetActivationFactory (L"Windows.Storage.Streams.InMemoryRandomAccessStream", {00000035-0000-0000-c000-000000000046}, 00007F110172E498): semi-stub 0a78:err:combase:RoGetActivationFactory Failed to find library for L"Windows.Storage.Streams.InMemoryRandomAccessStream" I haven't managed to find the required library anywhere, any advice appreciated. -- 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 32461] New: Evolve client (.NET 4.0 app) crashes on startup due to broken libgcrypt AES-NI support (misaligned stack for SSE operations, upstream)
by wine-bugs＠winehq.org Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=32461 Bug #: 32461 Summary: Evolve client (.NET 4.0 app) crashes on startup due to broken libgcrypt AES-NI support (misaligned stack for SSE operations, upstream) Product: Wine Version: 1.5.19 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, continuation of bug 32408 Adding this bug for documentation purposes. Prerequisite: 'winetricks -q dotnet40' (32-bit WINEPREFIX) Optional (the client will download/install on its own): 'winetricks -q msxml6' The app crashes in libgcrypt. With proper debug symbols for i686 libgcrypt we get: --- snip --- $ winedbg --gdb ./Updater.exe Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 62] 0x7e29453d in do_aesni_enc_aligned ( a=0x7e2cb398 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>, b=0x577d3a4 "\360R'~o\004", ctx=0x577d1a8) at rijndael.c:710 710 asm volatile ("movdqu %[src], %%xmm0\n\t" /* xmm0 := *a */ Wine-gdb> bt #0 0x7e29453d in do_aesni_enc_aligned ( a=0x7e2cb398 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>, b=0x577d3a4 "\360R'~o\004", ctx=0x577d1a8) at rijndael.c:710 #1 do_aesni (ctx=0x577d1a8, decrypt_flag=0, bx=0x577d3a4 "\360R'~o\004", ax=0x7e2cb398 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>) at rijndael.c:1132 #2 0x7e294946 in rijndael_encrypt (context=0x577d1a8, b=0x577d3a4 "\360R'~o\004", a=0x7e2cb398 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>) at rijndael.c:1155 #3 0x7e294f58 in selftest_basic_128 () at rijndael.c:1660 #4 0x7e294aff in selftest () at rijndael.c:1749 #5 do_setkey (keylen=16, key=0x7c906678 "!\312{\226\200j\356\030\247\256S\241\344\202", <incomplete sequence \304>, ctx=0x7c908670) at rijndael.c:209 #6 rijndael_setkey (context=0x7c908670, key=0x7c906678 "!\312{\226\200j\356\030\247\256S\241\344\202", <incomplete sequence \304>, keylen=16) at rijndael.c:444 #7 0x7e278df8 in cipher_setkey (c=0x7c9085f0, key=<optimized out>, keylen=16) at cipher.c:896 #8 0x7e26e5b4 in gcry_cipher_setkey (hd=0x7c9085f0, key=0x7c906678, keylen=16) at visibility.c:521 #9 0x7e39743c in wrap_gcry_cipher_setkey (ctx=0x7c9085f0, key=0x7c906678, keysize=16) at cipher.c:115 #10 0x7e31e462 in _gnutls_cipher_init (handle=0x7c901c64, cipher=GNUTLS_CIPHER_AES_128_CBC, key=0x7c901c5c, iv=0x7c901c54) at gnutls_cipher_int.c:71 #11 0x7e3294f7 in _gnutls_init_record_state (params=0x7c901c38, read=1, state=0x7c901c4c) at gnutls_constate.c:299 #12 0x7e329ac8 in _gnutls_epoch_set_keys (session=0x7c901290, epoch=1) at gnutls_constate.c:431 #13 0x7e32a198 in _gnutls_write_connection_state_init (session=0x7c901290) at gnutls_constate.c:602 #14 0x7e31280d in _gnutls_send_handshake_final (session=0x7c901290, init=1) at gnutls_handshake.c:2888 #15 0x7e315e41 in _gnutls_handshake_common (session=0x7c901290) at gnutls_handshake.c:3121 #16 0x7e31781e in gnutls_handshake (session=0x7c901290) at gnutls_handshake.c:2690 #17 0x7e4c1a1a in schan_imp_handshake (session=0x7c901290) at /home/focht/projects/wine/wine-git/dlls/secur32/schannel_gnutls.c:162 #18 0x7e4bff6c in schan_InitializeSecurityContextW (phCredential=0x188ed0, phContext=0x54ad0b0, pszTargetName=0xfc01bc, fContextReq=524572, Reserved1=0, TargetDataRep=16, pInput=0x12da3bc, Reserved2=0, phNewContext=0x577d7f0, pOutput=0x12da3d0, pfContextAttr=0x11c3138, ptsExpiry=0x577d8e8) at /home/focht/projects/wine/wine-git/dlls/secur32/schannel.c:766 #19 0x7e4c9180 in InitializeSecurityContextW (phCredential=0x577d8f0, phContext=0x577d9f4, pszTargetName=0xfc01bc, fContextReq=524572, Reserved1=0, TargetDataRep=16, pInput=0x12da3bc, Reserved2=0, phNewContext=0x11c6bfc, pOutput=0x12da3d0, pfContextAttr=0x11c3138, ptsExpiry=0x577d8e8) at /home/focht/projects/wine/wine-git/dlls/secur32/wrapper.c:346 ... --- snip --- Source: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/rij… --- snip --- 1626 /* Run the self-tests for AES 128. Returns NULL on success. */ 1627 static const char* 1628 selftest_basic_128 (void) 1629 { 1630 RIJNDAEL_context ctx; 1631 unsigned char scratch[16]; 1632 ... 1672 1673 rijndael_setkey (&ctx, key_128, sizeof (key_128)); 1674 rijndael_encrypt (&ctx, scratch, plaintext_128); 1675 if (memcmp (scratch, ciphertext_128, sizeof (ciphertext_128))) 1676 return "AES-128 test encryption failed."; 1677 rijndael_decrypt (&ctx, scratch, scratch); 1678 if (memcmp (scratch, plaintext_128, sizeof (plaintext_128))) 1679 return "AES-128 test decryption failed."; 1680 1681 return NULL; 1682 } --- snip --- "RIJNDAEL_context ctx" was not properly 16-byte aligned on stack, hence the crash in encrypt using SSE instructions. Using big brother I found some reports about this problem: --- Gentoo "dev-libs/libgcrypt-1.5.0-r2 - aes-ni segfaults" buglink: https://bugs.gentoo.org/show_bug.cgi?id=442568 patch: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/… --- Debian "libgcrypt11: New 1.5.0 version segfaults with NSS/PAM LDAP" buglink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643336 --- Upstream libgcrypt buglink: https://bugs.g10code.com/gnupg/issue1452 patch: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=a969… --- The "final" patch (using __attribute__ ((aligned (16))) on "RIJNDAEL_context" structure) did not fix the issue for me. At least on my Fedora 16, gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) still misaligned context buffers, causing segfault. I added "-mpreferred-stack-boundary=2" to CFLAGS to force gcc to realign the stack in function prolog. Fixed prolog code: --- snip --- .text:08001EE0 selftest_basic_128: .text:08001EE0 push ebp .text:08001EE1 mov ebp, esp .text:08001EE3 lea esp, [esp-0Ch] .text:08001EE7 and esp, 0FFFFFFF0h .text:08001EEA lea esp, [esp-22Ch] ... --- snip --- I suspect there are various other distros still broken regarding this bug hence you need to build a fixed libgcrypt version on your own. Regards -- 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.

3 5

[Bug 54695] New: Adobe Premiere Pro CS6: Fails to load msxml3
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=54695 Bug ID: 54695 Summary: Adobe Premiere Pro CS6: Fails to load msxml3 Product: Wine Version: 8.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: ericxiang456(a)gmail.com Distribution: --- Created attachment 74204 --> https://bugs.winehq.org/attachment.cgi?id=74204 Terminal output when running Adobe Premiere CS6 When running Adobe Premiere CS6 in Wine with the msxml3 library override to "Native" (installed via Winetricks), Premiere will fail to run because the msxml3 library fails to load (terminal output attached below). When overriding the msxml3 library to "Builtin then native", Premiere will launch, however the user interface will be displayed incorrectly (UI elements in black will appear as white). -- 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 60225] New: FL Mafia Desktop 2.1.2 (Tauri app) crashes with page fault in ole32 at window creation
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60225 Bug ID: 60225 Summary: FL Mafia Desktop 2.1.2 (Tauri app) crashes with page fault in ole32 at window creation Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: germanshtyrov(a)gmail.com Target Milestone: --- Distribution: --- FL Mafia Desktop 2.1.2 is a Tauri-based application (Rust + WebView2). On startup it consistently crashes with an unhandled page fault inside ole32, in the main thread, while the window is being created. No window is ever shown. The WebView2 child processes and DXVK initialise correctly; the crash happens in the main application thread, independently of the WebView2 renderer. The faulting instruction dereferences RAX, which holds an invalid pointer: ole32+0x35e48: movq (%rax), %rdx The backtrace shows the fault occurring inside ole32 while a window message is being dispatched through user32 into the application's window procedure. Suspected call path: the application vendor states that Tauri on Windows calls OleInitialize followed by RegisterDragDrop during window creation, before WebView2 is initialised, and that this is the code path executing at the point of the crash. This is consistent with the observed backtrace. Since this OleInitialize + RegisterDragDrop sequence is standard Tauri boilerplate on Windows rather than anything specific to this application, this may affect Tauri-based applications in general. Steps to reproduce: 1. Install a WebView2 runtime into the prefix 2. Install FL Mafia Desktop 2.1.2 (FL Mafia_2.1.2_x64-setup.exe) 3. Run flmafia-desktop.exe 4. No window appears; the process dies with a page fault Expected result: the application window opens. Tested Wine builds - all crash identically in ole32, always in the main thread: - wine-11.0 (vanilla, distro package): ole32+0x35e48 - wine-experimental.bleeding.edge.11.0.411656.20260810 (TkG "soda"): ole32+0x33aeb - wine-11.0 with "explorer /desktop=" virtual desktop: ole32+0x35e48. The application survives noticeably longer here (EdgeUpdate and the WebView2 GPU process both come up) but it still hits the same fault at the same offset. Possibly relevant observation: across three separate crash dumps the faulting pointer in RAX was 00001f04009ba070 00003b7400d21680 00004b5400ec83f0 In each case the low 32 bits look like a plausible heap address while the upper 32 bits look like unrelated garbage. This may suggest a value losing its upper half somewhere before being dereferenced as a pointer. System: Arch Linux, kernel 7.1.9-arch1-2, Intel Core i5-8350U, Intel UHD Graphics 620 (KBL GT2), Mesa 26.1.6. 64-bit prefix in Windows 10 mode, DXVK 3.0.2. Reproduced both under Bottles (flatpak) and with a plain wine invocation. Full logs and backtraces are attached. -- 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 59749] New: sapi: ISpVoice::SetPriority and GetStatus return E_NOTIMPL, breaking Overwatch 2 Audio Captions (and likely any SAPI app that polls status or checks SetPriority's HRESULT)
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59749 Bug ID: 59749 Summary: sapi: ISpVoice::SetPriority and GetStatus return E_NOTIMPL, breaking Overwatch 2 Audio Captions (and likely any SAPI app that polls status or checks SetPriority's HRESULT) Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: sapi Assignee: wine-bugs(a)list.winehq.org Reporter: bohdan(a)tkachenko.dev Distribution: --- dlls/sapi/tts.c has three ISpVoice methods still stubbed out with FIXME(...stub...); return E_NOTIMPL; - spvoice_SetPriority (line 1231) - spvoice_GetPriority (line 1238) - spvoice_GetStatus (line 1212) SetPriority and GetStatus are both on the hot path for Overwatch 2's "Audio Captions" accessibility TTS feature (Steam AppID 2357570, runs under Proton - which ships unmodified upstream Wine SAPI). They cause two distinct failure modes: 1. During voice setup, OW2 calls ISpVoice::SetPriority(SPVPRI_NORMAL) and checks the HRESULT. E_NOTIMPL makes it abort TTS init entirely - PLAY SAMPLE produces silence and the in-game UI gives no error. 2. If SetPriority is forced to return S_OK (verified by binary-patching the stub), the engine successfully synthesizes the first sample. The game then calls ISpVoice::Speak(text, SPF_ASYNC, ...) and tight-polls ISpVoice::GetStatus waiting for SPVOICESTATUS.dwRunningState == SPRS_DONE. Stock GetStatus returns E_NOTIMPL and writes nothing into the status struct, so the game polls forever and subsequent PLAY SAMPLE clicks silently do nothing. Other SAPI apps that use Speak(SPF_DEFAULT) or Speak(SPF_ASYNC) + WaitUntilDone(INFINITE) never hit these methods and work fine on stock Wine, which is why this hasn't been reported before despite the stubs being old. OW2's accessibility code is unusually defensive. Steps to reproduce ================== 1. Install Wine 11.8+ (or any current Proton - same upstream code: ValveSoftware/wine branch proton_11.0 dlls/sapi/tts.c is byte-identical to wine-mirror/wine master, MD5 verified). 2. Install Overwatch 2 (free-to-play, Steam AppID 2357570) - or any SAPI app that checks SetPriority's HRESULT. 3. In game settings -> Accessibility, enable Audio Captions and select a Proton voice (e.g. "Proton Voice - English (United States) - LIBRITTS-R 14"). 4. Click PLAY SAMPLE. Actual: silence; in-game UI gives no error. With WINEDEBUG=+sapi: spvoice_SetVoice -> picks ProtonTTS_libritts-r_3 spvoice_SetOutput(NULL) -> default audio out spvoice_SetRate(3) -> S_OK spvoice_SetVolume(100) -> S_OK spvoice_SetPriority(0) -> STUB -> E_NOTIMPL [BUG #1] spvoice_Release -> game gives up here After binary-patching SetPriority to return S_OK: spvoice_Speak(text, SPF_ASYNC=1) -> audio plays once loop: spvoice_GetStatus(&status, NULL) -> STUB -> E_NOTIMPL, status untouched ... [BUG #2 - tight poll forever] Expected: PLAY SAMPLE plays the voice sample, and the button works again on every subsequent click. Workaround: binary-patch the two E_NOTIMPLs, or use a locally-built Wine with the patches below. Fix === A patch is being prepared for wine-devel implementing all three methods plus tests. Sketch: - SetPriority/GetPriority: store value on struct speech_voice, validate against SPVPRI_NORMAL/ALERT/OVER. - GetStatus: populate SPVOICESTATUS from cur_stream_num (last queued), a new last_stream_num/last_hr updated in speak_proc, and async_wait_queue_empty(&queue, 0) for dwRunningState. Patch verified against Wine's existing dlls/sapi/tests/ suite (new tests added) and end-to-end in OW2: both PLAY SAMPLE clicks play correctly with no wedge. -- 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 60217] New: Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60217 Bug ID: 60217 Summary: Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: loic.simond(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 81919 --> http://bugs.winehq.org/attachment.cgi?id=81919 Terminal output of the reproduction steps on wine-11.16 (clean prefix) A font substitute set by the user for "MS Shell Dlg 2" under HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes is reset to Tahoma every time the prefix is updated, that is at the first start of Wine after any Wine upgrade, or with "wineboot -u". The sibling "MS Shell Dlg" substitute survives the same update. Steps to reproduce, in a clean 64-bit prefix: export WINEPREFIX=~/wine-bugtest-fontsubst wineboot -i K='HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes' wine reg add "$K" /v "MS Shell Dlg" /t REG_SZ /d "DejaVu Sans" /f wine reg add "$K" /v "MS Shell Dlg 2" /t REG_SZ /d "DejaVu Sans" /f wineboot -u wine reg query "$K" | grep "MS Shell Dlg" Observed (wine-11.16, full terminal output attached): MS Shell Dlg REG_SZ DejaVu Sans MS Shell Dlg 2 REG_SZ Tahoma Expected: both values keep what the user set. A prefix update should not undo a font configuration, as it already doesn't for "MS Shell Dlg"; on Windows, FontSubstitutes is a system setting that upgrades leave alone. I hit this on a prefix where both substitutes had been changed to another face: after the upgrade to wine-11.16, dialogs asking for "MS Shell Dlg 2" were back to Tahoma, with nothing in the logs to explain it. The only way to notice is to re-read the registry after every upgrade. Analysis: the two values are written by two different mechanisms. "MS Shell Dlg" is written by win32u, in update_codepage() (dlls/win32u/font.c, lines 3105-3110 in wine-11.16), and only when the stored "Codepages" value changes — the code carries the comment "Only update these if the Codepage changed". "MS Shell Dlg 2" comes from loader/wine.inf.in, line 515: HKLM,%FontSubStr%,"MS Shell Dlg 2",,"Tahoma" with an empty flags field, so setupapi rewrites it on every DefaultInstall: a value is left alone only when the entry carries FLG_ADDREG_NOCLOBBER (dlls/setupapi/install.c, line 384). wine.inf.in already uses that flag (",2,") for more than a hundred entries users are expected to customise, such as file associations, but for none of the FontSubstitutes entries. Marking the entry NOCLOBBER ("MS Shell Dlg 2",2,"Tahoma") keeps the default for new prefixes and makes the two substitutes behave the same way. Alternatively the value could be written next to "MS Shell Dlg" in update_codepage(), under the same guard. Tested on wine-11.16 (Arch Linux package, x86_64, unmodified); the wine.inf.in line and the update_codepage() code are identical on current git master. -- 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 31655] New: SlingPlayer 1.5 fails to show video if Wine is upgraded
by wine-bugs＠winehq.org Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=31655 Bug #: 31655 Summary: SlingPlayer 1.5 fails to show video if Wine is upgraded Product: Wine Version: 1.5.12 Platform: x86-64 URL: http://download.slingmedia.com/player/pc/SlingPlayer-S etup-EU-1.5.1.343.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Classification: Unclassified Created attachment 41616 --> http://bugs.winehq.org/attachment.cgi?id=41616 Wine 1.5.6 console output SlingPlayer 1.5 fails to show video if Wine is upgraded. Sound works fine. I have tested this over and over and it is the act of upgrading Wine that appears to be causing the problem. Native quartz, qcap and gdiplus needed to get this far. Tested: 1.4.1 --> 1.5.6 1.5.6 --> 1.5.12 1.5.12 --> wine-1.5.12-157-gbdf9a9f Following the upgrade there is some new output in the console: err:ddraw:ddraw7_QueryInterface (0x1ee6f8)->({aca12120-3356-11d1-8fcf-00c04fc29b4e}, 0x16d554): No interface found And this line disappears: err:ole:CoGetClassObject class {7d8aa343-6e63-4663-be90-6b80f66540a3} not registered 7d8aa343-6e63-4663-be90-6b80f66540a3 is related to quartz.dll (http://mikolajapp.appspot.com/uuid/query?q={7d8aa343-6e63-4663-be90-6b80f66…) and this somehow becomes registered during the transition, and stops video from being shown in the SlingPlayer. I cannot understand what would cause this. Attempting to unregister fails: Failed to unregister DLL c:\windows\system32\quartz.dll No known workaround: I have to reinstall SlingPlayer every time, or lock the upgrades on my system. -- 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 12

[Bug 59188] New: wayland: Photoshop menu is overlapped by canvas (wrong z-order)
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59188 Bug ID: 59188 Summary: wayland: Photoshop menu is overlapped by canvas (wrong z-order) Product: Wine Version: 11.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: bigfoothart(a)gmail.com Distribution: --- Created attachment 80052 --> http://bugs.winehq.org/attachment.cgi?id=80052 photoshop menu is overlapped by canvas wayland mode: Photoshop menu is overlapped by canvas (wrong z-order). Reproduced in all wine versions. And when the focus switches to other apps, the menu appears in foreground (see in video) -- 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 60204] New: AcceptEx broken for Unix-domain sockets
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60204 Bug ID: 60204 Summary: AcceptEx broken for Unix-domain sockets Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)purplesyringa.moe Target Milestone: --- Distribution: --- sockaddr_from_unix [1] is unimplemented for the AF_UNIX family. Normally that's not a problem, most callees ignore the -1 output silently, but fill_accept_output validates that it's non-negative and returns an error if so. Since errno is not set explicitly on this path, this just ends up forwarding the last native error, i.e. garbage. I'm not sure if the moral of the story is that sockaddr_from_unix should be validated everywhere else (from a quick glance at least IOCTL_AFD_WINE_GETPEERNAME seems to misbehave and return STATUS_BUFFER_TOO_SMALL in this case) and implemented for AF_UNIX, or if fill_accept_output should ignore errors just like other callers. [1]: https://gitlab.winehq.org/wine/wine/-/blob/9306b8e8de4efe3a6035bc5df878e750… -- 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