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

[Bug 50109] New: 0414:fixme:conhost:write_console beep
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=50109 Bug ID: 50109 Summary: 0414:fixme:conhost:write_console beep Product: Wine Version: 5.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: azraeladdy(a)gmail.com Distribution: --- Created attachment 68600 --> https://bugs.winehq.org/attachment.cgi?id=68600 Output from a simple C program. Along with its code. Occurs when outputting the BEL ASCII character. Nothing huge, but a worthy thing to keep track of? Not much else to say, possibly other ASCII characters that wine has a fix me statement for? -- 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 7

[Bug 37896] New: EM_SETPASSWORDCHAR ineffective when edit control does not have WS_BORDER set
by wine-bugs＠winehq.org Aug. 8, 2026

Aug. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=37896 Bug ID: 37896 Summary: EM_SETPASSWORDCHAR ineffective when edit control does not have WS_BORDER set Product: Wine Version: 1.7.33 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: winehq-bugzilla(a)richardpayne.name Distribution: --- I have two identical edit controls with ES_PASSWORD set via EM_SETPASSWORDCHAR. Identical, that is, apart from 1 having WS_BORDER set and the other not. The one without WS_BORDER does not conceal its contents as it should when a password char is specified. The one with WS_BORDER set works as expected. -- 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 22

[Bug 23319] New: cmd thinks shift.exe is an internal command
by wine-bugs＠winehq.org Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=23319 Summary: cmd thinks shift.exe is an internal command Product: Wine Version: 1.2-rc4 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com On Windows, 'shift' is an internal command, and 'shift.exe' is an external command. Wine's cmd mistakenly thinks 'shift.exe' is a synonym for 'shift'. This makes it somewhat hard to play EA's Need For Speed: Shift. -- 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 17

[Bug 55447] New: wine cannot parse valid javascript
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=55447 Bug ID: 55447 Summary: wine cannot parse valid javascript Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: jscript Assignee: wine-bugs(a)winehq.org Reporter: yshuiv7(a)gmail.com Distribution: --- jscript cannot parse the code below: var O = { continue: 1 }; var x = { label: O.continue }; it reports: 0024:warn:jscript:script_parse parser failed around L"bel: O.continue\n };\n});\n" in line L"sync_test(\"ASDF\", function() {" Native Windows jscript doesn't have a problem with this. The cause, I believe, is jscript inserted a semicolon after the "continue". -- 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 2

[Bug 60120] New: Amnesia: Rebirth crashes after the splash screens
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60120 Bug ID: 60120 Summary: Amnesia: Rebirth crashes after the splash screens Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: c6ce266a68a9c588547ef44571f0b43ba25bec03 Distribution: --- Created attachment 81682 --> http://bugs.winehq.org/attachment.cgi?id=81682 backtrace After loading bar, logos, just before the main menu. -- 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 59998] New: import_dll does not find ddraw.dll
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59998 Bug ID: 59998 Summary: import_dll does not find ddraw.dll Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: jenngra505(a)roadrunner.com Target Milestone: --- Distribution: --- Created attachment 81405 --> http://bugs.winehq.org/attachment.cgi?id=81405 Log when opening a program Upon updating to the newest Wine version, the import_dll module stopped detecting ddraw.dll which is needed for every program that requires DirectX. -- 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 23

[Bug 30239] New: Adobe Photoshop CS6 beta installer "failed to initialize"
by wine-bugs＠winehq.org Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=30239 Bug #: 30239 Summary: Adobe Photoshop CS6 beta installer "failed to initialize" Product: Wine Version: 1.5.0 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified Downloaded http://labsdownload.adobe.com/pub/labs/photoshopcs6/photoshopcs6_p1_win_032… unzipped, ran Set-up.exe Log shows ... Exiting Installer with Code: 0 ... trace:text:X11DRV_GetTextExtentExPoint L"I" 1 trace:text:X11DRV_GetTextExtentExPoint L"n" 1 trace:text:X11DRV_GetTextExtentExPoint L"s" 1 trace:text:X11DRV_GetTextExtentExPoint L"t" 1 trace:text:X11DRV_GetTextExtentExPoint L"a" 1 trace:text:X11DRV_GetTextExtentExPoint L"l" 1 trace:text:X11DRV_GetTextExtentExPoint L"l" 1 trace:text:X11DRV_GetTextExtentExPoint L"e" 1 trace:text:X11DRV_GetTextExtentExPoint L"r" 1 trace:text:X11DRV_GetTextExtentExPoint L" " 1 trace:text:X11DRV_GetTextExtentExPoint L"f" 1 trace:text:X11DRV_GetTextExtentExPoint L"a" 1 trace:text:X11DRV_GetTextExtentExPoint L"i" 1 trace:text:X11DRV_GetTextExtentExPoint L"l" 1 trace:text:X11DRV_GetTextExtentExPoint L"e" 1 trace:text:X11DRV_GetTextExtentExPoint L"d" 1 (+relay shows that message whole, 0028:Call gdi32.GetTextExtentPoint32W(00000438,01fdd2e0 L"Installer failed to initialize. This could be due to a missing file.",00000001,0033cfc4) ret=00d2caaa ) The log also shows a fair bit of XML, so I tried "winetricks msxml3", and it got further. -- 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 32

[Bug 60088] New: ole32/storage: extra trailing NUL byte written into name of stream nested in a substorage (breaks MS Publisher .pub file portability)
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60088 Bug ID: 60088 Summary: ole32/storage: extra trailing NUL byte written into name of stream nested in a substorage (breaks MS Publisher .pub file portability) Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: veliga99(a)gmail.com Target Milestone: --- Distribution: --- When a Microsoft Publisher 2003 (.pub) document containing embedded pictures is saved under Wine, the OLE compound-file stream named "EscherDelayStm" — nested inside the "Escher" substorage — is written with an extra trailing NUL character as part of its name: "EscherDelayStm\x00" (15 UTF-16 units) instead of the correct "EscherDelayStm" (14 UTF-16 units). The directory entry's "Name Length" field is internally consistent with this wrong name (32 instead of 30), so the file remains structurally valid and is read back fine by Wine itself, by the Python `olefile` library, and by the independent `libmspub` parser — but real Windows/Publisher, which resolves this stream by an exact name lookup, fails to find it. Notably, the sibling stream "EscherStm" in the very same substorage is always written correctly, with no extra byte — this points to something specific to how this particular stream (or streams nested in a substorage more generally) gets created/named, rather than a blanket string-length bug affecting every stream. Impact: if the stream is empty (no embedded pictures), the bug has no visible effect. If it holds real picture data (any Publisher document with at least one embedded image), the resulting .pub file: - crashes Publisher 2003 silently on open (native Windows), and - is flatly refused by Publisher 2016+ ("a problem was detected with this file", Office File Validation). This makes any Publisher document with pictures, edited under Wine, unopenable once transferred back to a real Windows machine. Reproduction: 1. Under Wine, open/create a Publisher 2003 (.pub) document containing at least one embedded picture, and save it. 2. Compare the OLE stream names in "Escher/*" against a reference file saved by native Windows Publisher (e.g. with `olefile` in Python, or any compound-file browser) — the Wine-saved file will show "EscherDelayStm\x00" (note the visible extra byte) where Windows shows "EscherDelayStm". 3. Attempt to open the Wine-saved file with native Windows Publisher: it fails (silent crash on 2003, explicit rejection on 2016+). Confirmed fix: manually correcting only the 2-byte "Name Length" field of this stream's directory entry (32 -> 30, no other byte touched) makes the file open correctly again under native Windows Publisher — verified on multiple real documents. A minimal reproduction script and full write-up (including a working Python-based post-hoc fix, for anyone hitting this before it's fixed in Wine itself) is available at: https://github.com/veliga-syutkin/mspub-wine-escherdelaystm-fix -- 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 9

[Bug 59926] New: kernelbase: CharPrevA/CharPrevExA crash on NULL start pointer (MapleStory 216150 fails to launch)
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59926 Bug ID: 59926 Summary: kernelbase: CharPrevA/CharPrevExA crash on NULL start pointer (MapleStory 216150 fails to launch) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: f0rm4tm3(a)gmail.com Distribution: --- MapleStory (Steam app 216150) fails to launch under Wine: the process crashes with an access violation (0xc0000005) during startup. Root cause: CharPrevA() and CharPrevExA() in dlls/kernelbase/string.c dereference the start pointer in their loop condition without a NULL guard: LPSTR WINAPI CharPrevExA(WORD codepage, const char *start, const char *ptr, DWORD flags) { while (*start && (start < ptr)) /* crashes when start == NULL */ The game passes a NULL start pointer at launch, triggering the crash. CharPrevA() has the same bug. Suggested fix: return NULL early when start is NULL, matching how other kernelbase string helpers (e.g. StrChrA) already handle NULL input: if (!start) return NULL; while (*start && (start < ptr)) ... Reproduce: 1. Steam -> MapleStory (216150) under any recent Wine/Proton. 2. Launch -> process crashes at startup (0xc0000005 in kernelbase, inside CharPrevExA). Patch: two commits attached as git format-patch files (git am them): 1. kernelbase/tests: Add tests for CharPrevA. 2. kernelbase: Don't dereference NULL in CharPrevA/CharPrevExA. (I would have opened a merge request, but my gitlab.winehq.org account is awaiting validation and cannot fork; attaching the patch here instead.) -- 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 18

[Bug 59436] New: Wayland/EGL: Washed-out colors caused by double sRGB conversion on default framebuffer (GL_FRAMEBUFFER_SRGB)
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59436 Bug ID: 59436 Summary: Wayland/EGL: Washed-out colors caused by double sRGB conversion on default framebuffer (GL_FRAMEBUFFER_SRGB) Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: tpaniaki(a)protonmail.com Distribution: --- Created attachment 80417 --> http://bugs.winehq.org/attachment.cgi?id=80417 Patch Fixes https://bugs.winehq.org/show_bug.cgi?id=59073 Summary When running Wine with the Wayland driver (winewayland.drv) using EGL, colors may appear washed out / desaturated in OpenGL applications. The issue is caused by GL_FRAMEBUFFER_SRGB remaining enabled while rendering to the default framebuffer (FBO 0), leading to a double gamma/sRGB conversion in some Wayland/EGL pipelines. Disabling GL_FRAMEBUFFER_SRGB only when rendering to the default framebuffer fixes the color output. Environment Wine: wine-git (tested on 11.x, reproducible on current master) Backend: winewayland.drv (Wayland native, not XWayland) GPU: AMD (Mesa) Compositor: wlroots-based (qtile Wayland) EGL backend in use Application tested: Roon (Chromium/CEF-based UI, OpenGL rendering) Observed behavior Colors appear faded / washed out Gamma looks incorrect (as if double sRGB conversion occurs) Issue only occurs under Wayland/EGL Colors are correct: Under X11/XWayland Or if GL_FRAMEBUFFER_SRGB is manually disabled for FBO 0 Root cause hypothesis Some Wayland/EGL compositors already perform colorspace handling for the window surface. If GL_FRAMEBUFFER_SRGB remains enabled when rendering to the default framebuffer, the pipeline applies sRGB conversion twice: App → GL_FRAMEBUFFER_SRGB → EGL/Compositor colorspace → Display This results in desaturated output. Minimal fix Disable GL_FRAMEBUFFER_SRGB only when binding the default framebuffer (FBO 0), while preserving the application's requested sRGB state for non-default FBOs. Example patch (conceptual) Inside framebuffer binding path: if (!framebuffer && gl_info->supported[ARB_FRAMEBUFFER_SRGB]) { TRACE("glBindFramebuffer disabling GL_FRAMEBUFFER_SRGB on default framebuffer\n"); glDisable(GL_FRAMEBUFFER_SRGB); } else if (framebuffer && app_framebuffer_srgb_enabled) { TRACE("glBindFramebuffer restoring GL_FRAMEBUFFER_SRGB on non-default framebuffer\n"); glEnable(GL_FRAMEBUFFER_SRGB); } Results Colors become correct under Wayland/EGL No regression observed in tested OpenGL apps Behavior matches X11 output sRGB still works correctly for offscreen FBO rendering -- 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 16