- Wine-Bugs - list.winehq.org

[Bug 59504] jscript: GetScriptDispatch("") returns E_INVALIDARG instead of global dispatch
by WineHQ Bugzilla March 11, 2026

March 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=59504 --- Comment #3 from Robert-Gerigk(a)online.de --- Created attachment 80532 --> http://bugs.winehq.org/attachment.cgi?id=80532 test program -- 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 59504] jscript: GetScriptDispatch("") returns E_INVALIDARG instead of global dispatch
by WineHQ Bugzilla March 11, 2026

March 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=59504 --- Comment #2 from Robert-Gerigk(a)online.de --- The list_empty check alone would not be sufficient. On native Windows, GetScriptDispatch("") returns the global dispatch even when named items are registered in the list. So if a host calls AddNamedItem("myobj", ...) first and then GetScriptDispatch(""), the list is non-empty, lookup_named_item runs, tries to find "", fails, and returns E_INVALIDARG. Verified on native Windows 11 (64-bit process): GetScriptDispatch(null): OK (dispatch=valid) GetScriptDispatch(""): OK (dispatch=valid) GetScriptDispatch("nonexistent"): FAILED (expected: 0x80070057) Windows treats GetScriptDispatch("") identically to GetScriptDispatch(null) — both return the global script dispatch object. Only a truly non-existent named item returns E_INVALIDARG. The minimal correct fix matching Windows behavior: if(pstrItemName && *pstrItemName) This treats empty string the same as NULL in all cases, regardless of whether named items exist. The same fix applies to dlls/vbscript/vbscript.c which has identical logic. The test program is attached to the initial bug report (TestGetScriptDispatch.cs). -- 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 59504] jscript: GetScriptDispatch("") returns E_INVALIDARG instead of global dispatch
by WineHQ Bugzilla March 10, 2026

March 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=59504 Maotong Zhang <zmtong1988(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zmtong1988(a)gmail.com --- Comment #1 from Maotong Zhang <zmtong1988(a)gmail.com> --- Check if the list is empty: if(pstrItemName && !list_empty(&This->ctx->named_items)) -- 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 35315] New: Jewel of the Oracle: crashes at start
by wine-bugs＠winehq.org March 10, 2026

March 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=35315 Bug ID: 35315 Summary: Jewel of the Oracle: crashes at start Product: Wine Version: 1.7.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: legluondunet(a)free.fr Classification: Unclassified Created attachment 47100 --> http://bugs.winehq.org/attachment.cgi?id=47100 JOTO backtrace Hello, the game Jewel Of The Oracle crashes at start. In the terminal I obtained: wine: Unhandled page fault on read access to 0xffffffff at address 0x131f:0x00002782 (thread 0029), starting debugger... fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} and I joined you the backtrace. It seems to be a 16 bits game and should have Director 4 technology (Macromedia). LGDN. -- 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 4

[Bug 59506] New: IMFMediaEngine video playback fails: no MFT_CATEGORY_VIDEO_PROCESSOR registered for NV12→RGB32 color conversion
by WineHQ Bugzilla March 10, 2026

March 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=59506 Bug ID: 59506 Summary: IMFMediaEngine video playback fails: no MFT_CATEGORY_VIDEO_PROCESSOR registered for NV12→RGB32 color conversion Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: Loong.0x00(a)gmail.com Distribution: --- IMFMediaEngine video playback fails because no MFT_CATEGORY_VIDEO_PROCESSOR transform is registered to handle color space conversion (NV12 → RGB32). On Windows, the Color Converter DSP (CLSID_CColorConvertDMO) handles this. Wine does not register any equivalent MFT in this category. == Failure chain (traced with WINEDEBUG=+mf,+mfplat,+mfmediaengine) == 1. IMFMediaEngine::SetSourceFromByteStream("video.mp4") → OK 2. Source resolver creates media source from byte stream → OK 3. topology_loader_Load runs (real implementation, not a stub despite FIXME string) 4. MFTEnumEx(MFT_CATEGORY_VIDEO_DECODER, H264) → finds h264_decoder, activates OK 5. GStreamer pipeline: h264parse → avdec_h264 → videoconvert, all linked successfully 6. H264 decoder outputs NV12 7. video_frame_sink expects RGB32 (MFVideoFormat_RGB32, GUID {00000020-0000-0010-8000-00aa00389b71}) 8. MFTEnumEx(MFT_CATEGORY_VIDEO_PROCESSOR, NV12→RGB32) → returns 0 results ← ROOT CAUSE 9. topology_branch_connect returns 0xc00d5212 (MF_E_TRANSFORM_NOT_POSSIBLE) 10. session_set_topology fails with 0xc00d36b9 (MF_E_TOPO_UNSUPPORTED) 11. MEError 0xc00d3e85 (MF_E_TOPO_CODEC_NOT_FOUND) propagated to application == Additional stubs == IMFMediaEngineEx::SetAutoPlay() and SetLoop() store the flag internally but the playback engine never consumes it, so video looping does not work. == Affected application == Wallpaper Engine (Steam AppID 431960). Scene wallpapers with embedded video textures use IMFMediaEngine::SetSourceFromByteStream() to decode .mp4 files as texture layers. All such wallpapers fail with grey/blank video layers. == Relevant trace excerpt == topology_loader_Load iface ..., input_topology ..., ret_topology ..., current_topology 0x0 stub! MFTEnumEx MFT_CATEGORY_VIDEO_DECODER, 0x3f, {MFMediaType_Video,MFVideoFormat_H264}, ... → found h264_decoder h264_decoder_create ... wg_transform_create: input caps video/x-h264, output caps video/x-raw, format=I420, 1920x1080 gst_pad_link_full: linked avdec_h264-0:src and videoconvert0:sink, successful MFTEnumEx MFT_CATEGORY_VIDEO_PROCESSOR, 0x3f, {MFMediaType_Video,MFVideoFormat_NV12}, {MFMediaType_Video,{00000020-...}} → 0 results topology_branch_connect returning 0xc00d5212 topology_branch_connect returning 0xc00d36b9 session_set_topology failed to load topology ..., hr 0xc00d36b9 == System == Wine 11.4 (also reproduced with Valve's wine-staging 10.0 via GE-Proton10-32) Arch Linux x86_64, kernel 6.19.6 GStreamer 1.22.5, h264 decoders available (avdec_h264, openh264dec, nvh264dec) == Suggested fix == Register a GStreamer-backed MFT_CATEGORY_VIDEO_PROCESSOR that wraps videoconvert for NV12/I420 → RGB32 conversion. The GStreamer videoconvert element is already used internally by the decoder pipeline. -- 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 47302] New: Not recognized float point in Saturn Design Toolkit
by wine-bugs＠winehq.org March 9, 2026

March 9, 2026

https://bugs.winehq.org/show_bug.cgi?id=47302 Bug ID: 47302 Summary: Not recognized float point in Saturn Design Toolkit Product: Wine Version: 4.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hildogjr(a)gmail.com Distribution: --- After install the Saturn PCB ToolKit http://www.saturnpcb.com/download-our-pcb-toolkit/ and tried to start. I get the message: '4,6' is not a valid float point value. My installed system is a Ubuntu 16 with wine 4.9 English but with a latin input method (keyboard), using "," as decimal separator. Just comment this if is related to the issue. -- 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 58750] New: SierraChart chart windows fail to render with OpenGL enabled
by WineHQ Bugzilla March 9, 2026

March 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=58750 Bug ID: 58750 Summary: SierraChart chart windows fail to render with OpenGL enabled Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)winehq.org Reporter: justin.guidroz(a)gmail.com Distribution: --- Wine versions > 10.9 fail to render SierraChart chart windows when OpenGL is enabled. Disabling OpenGL, the chart windows render as expected. Manjaro Linux provided updates of Wine 10.11 and 10.15 after version 10.9. On 10.11, chart windows inside the main application window would fail to render, while chart windows detached from the main window would still render with OpenGL enabled. On 10.15, all chart windows (both inside the main window and detached from the main window) fail to render with OpenGL enabled. -- 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 1

[Bug 45999] New: Opening File dialog in Micrographx Windows Draw 4.0 causes Unhandled exception
by wine-bugs＠winehq.org March 9, 2026

March 9, 2026

https://bugs.winehq.org/show_bug.cgi?id=45999 Bug ID: 45999 Summary: Opening File dialog in Micrographx Windows Draw 4.0 causes Unhandled exception Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jklaas(a)appalachian.dyndns.org Distribution: --- Created attachment 62564 --> https://bugs.winehq.org/attachment.cgi?id=62564 Backtrace saved after application crash Installation of Micrographx Windows Draw 4.0 works without issue. Micrographx Windows Draw 4.0 starts without any difficulty. I can drag a file from a file manager onto the open application to open a file. However, if I attempt to open or save a file from any of the file management dialogs, the application crashes with an Unhandled exception. -- 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 5

[Bug 59500] New: Scrivener 3 (Qt 6.4.3) crashes silently when opening RTF documents containing emoji encoded as UTF-16 surrogate pairs
by WineHQ Bugzilla March 9, 2026

March 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=59500 Bug ID: 59500 Summary: Scrivener 3 (Qt 6.4.3) crashes silently when opening RTF documents containing emoji encoded as UTF-16 surrogate pairs Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)list.winehq.org Reporter: golfsmarts(a)gmail.com Distribution: --- Wine version: wine-10.0 (Ubuntu 10.0~repack-6ubuntu1+zorin5) Distribution: Zorin OS 18 (Ubuntu 24.04 noble base) Architecture: 64-bit Application: Scrivener 3.1.6.0 for Windows (Literature & Latte) Description: Scrivener 3 crashes silently when opening any document whose underlying RTF file contains emoji characters. The emoji are encoded in RTF as sequences of the form: \loch\af2\hich\af2\dbch\af2\uc1\u55356\'3F\u57130\'3F These are UTF-16 surrogate pairs (high surrogate U+D800–U+DBFF followed by low surrogate U+DC00–U+DFFF) used to encode Unicode codepoints above U+FFFF. Scrivener uses Qt 6.4.3, confirmed via strings on the binary (build tag ScrQt643-rel1). The crash does not occur on native Windows. Stripping the \dbch...\uc1\uXXXXX sequences from the affected RTF files completely eliminates the crashes, confirming surrogate pair handling as the root cause. This appears to be the same class of issue reported for LOOT v0.20.0 (Qt 6.5.1) crashing under Wine after upgrading from Qt5: https://github.com/loot/loot/issues/1886 Reproducer: Any Qt 6.x application that renders a string containing Unicode codepoints above U+FFFF (emoji, supplementary CJK, etc.) Expected behavior: Application renders or ignores the characters without crashing Actual behavior: Silent crash, no error dialog -- 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 7

[Bug 59274] New: Win Fox game renders solid colors as black after switching to windowed mode once
by WineHQ Bugzilla March 9, 2026

March 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=59274 Bug ID: 59274 Summary: Win Fox game renders solid colors as black after switching to windowed mode once Product: Wine Version: 11.0 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Steps to reproduce: 1. In winecfg, enable the virtual desktop (the game crashes on start without it) 2. Run D:\foxbear\foxbear.exe from the Windows 95 Game SDK CD 3. Press Alt+Enter to switch to windowed mode On Wine, the solid blue of the sky and the solid greens of the trees and grass change to black. Interestingly, the solid colors are still black even after pressing Alt+Enter again to switch back to fullscreen mode. When I run the game on Windows 95 on my 486, the colors remain correct when switching between fullscreen and windowed mode. The game's source code is included on the CD in the D:\sdk\samples\foxbear directory. $ sha256sum 'Windows 95 Game SDK Featuring DirectX.iso' 3dc115445572cba4488eeb25f70f0c3a4d53109f4952ea6274f0538a3d39295b -- 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