[Bug 59396] New: Tabbed UI in proprietary IDE broken after update – tabs are shown as separate windows
http://bugs.winehq.org/show_bug.cgi?id=59396 Bug ID: 59396 Summary: Tabbed UI in proprietary IDE broken after update – tabs are shown as separate windows Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: Wagner.a18@yahoo.com Distribution: --- Since a recent update of a proprietary Windows-based IDE from my automation/control system vendor, the tabbed user interface no longer works correctly when running under Wine. Previously, the IDE displayed its editors and views as tabs within a single main window (similar to applications like Visual Studio Code). After the update, these tabs are now opened as separate top-level windows instead of being embedded as tabs in the main application window. This behavior only occurs when running the application with Wine. On native Windows systems, the IDE still behaves correctly and shows tabs as expected. Expected behavior: Editors and views should be displayed as tabs within the main IDE window, as before the update. Actual behavior: Each tab is opened as an individual window, breaking the intended tabbed workflow and making the IDE difficult to use. Regression: Yes. The tabbed interface worked correctly with earlier versions of the IDE under Wine. The issue appeared immediately after the vendor updated the application. Additional notes: The application is proprietary, so source code is not available. The issue seems related to how the updated IDE handles tabbed/docked windows or window embedding under Wine. Environment: Wine version: v11.1 Wine architecture: win64 / win32 Distribution: arch linux Desktop environment / window manager: kde plasma Application version: proprietary ide for control systems -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 --- Comment #1 from Wagner.a18@yahoo.com --- Created attachment 80358 --> http://bugs.winehq.org/attachment.cgi?id=80358 Actual-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.
http://bugs.winehq.org/show_bug.cgi?id=59396 Wagner.a18@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Tabbed UI in proprietary |dispatch_user_callback |IDE broken after update – |ignores handled SEH |tabs are shown as separate |EXCEPTION_ACCESS_VIOLATION |windows |(c0000005) in 32-bit | |WndProc, breaking | |MFC/ToolkitPro MDI tab | |initialization Version|11.1 |11.6 --- Comment #2 from Wagner.a18@yahoo.com --- Summary When a 32-bit MFC application uses SEH (__try/__except) to handle an EXCEPTION_ACCESS_VIOLATION (0xc0000005) inside a Windows callback (WndProc), Wine's dispatch_user_callback logs ignoring exception c0000005 and does not pass control to the SEH handler. On Windows the exception is caught correctly, the MDI/tab layout initializes, and documents open in tabs. Under Wine the MDI client window never properly initializes and all documents open as floating windows instead of tabs. Steps to reproduce Minimal reproduction with a 32-bit MFC + Codejock ToolkitPro application compiled with MSVC 2019 / mfc140.dll. The new code path calls msvcp140.dll code at RVA 0x157C3 from within a WndProc, which reads a NULL pointer intentionally (pattern: __try { *ptr } __except(EXCEPTION_EXECUTE_HANDLER) { ... initialize ... }). On Windows the __except block runs 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 --- Comment #3 from Wagner.a18@yahoo.com --- Summary When a 32-bit MFC application uses SEH (__try/__except) to handle an EXCEPTION_ACCESS_VIOLATION (0xc0000005) inside a Windows callback (WndProc), Wine's dispatch_user_callback logs ignoring exception c0000005 and does not pass control to the SEH handler. On Windows the exception is caught correctly, the MDI/tab layout initializes, and documents open in tabs. Under Wine the MDI client window never properly initializes and all documents open as floating windows instead of tabs. Steps to reproduce Minimal reproduction with a 32-bit MFC + Codejock ToolkitPro application compiled with MSVC 2019 / mfc140.dll. The new code path calls msvcp140.dll code at RVA 0x157C3 from within a WndProc, which reads a NULL pointer intentionally (pattern: __try { *ptr } __except(EXCEPTION_EXECUTE_HANDLER) { ... initialize ... }). On Windows the __except block runs 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 --- Comment #4 from Wagner.a18@yahoo.com --- Expected: File opens as a tab in the MDI workspace (same as on Windows, same as with the previous binary from 2025-12). Actual: File opens as a floating MDI child window. Console shows: 0358:err:seh:dispatch_user_callback ignoring exception c0000005 Technical details The exception occurs at eip=77cd57c3 (msvcp140.dll+0x157C3, 32-bit syswow64 version installed via winetricks vcrun2019, dated 2024-08-16). The SEH chain has multiple handlers registered at: 0x01C209CF — Lasal2.exe internal handler 0x792C7018, 0x792C6EF5, 0x792B80B2 — mfc140.dll handlers 0x753B4D30 — vectored handler All handlers return EXCEPTION_EXECUTE_HANDLER (1) — indicating they want to handle the exception. Yet dispatch_user_callback still logs the "ignoring" message and the exception is not handled in user code. Relevant log extract (WINEDEBUG="+seh"): 0358:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) addr=77CD57C3 0358:trace:seh:dispatch_exception eip=77cd57c3 esp=03b4e0e8 ebp=03b4e10c eflags=00210282 0358:trace:seh:call_vectored_handlers calling handler at 753B4D30 code=c0000005 flags=0 0358:trace:seh:call_vectored_handlers handler at 753B4D30 returned 0 0358:trace:seh:call_seh_handlers calling handler at 01C209CF code=c0000005 flags=0 0358:trace:seh:call_seh_handlers handler at 01C209CF returned 1 0358:trace:seh:call_seh_handlers calling handler at 792C7018 code=c0000005 flags=0 0358:trace:seh:call_seh_handlers handler at 792C7018 returned 1 0358:err:seh:dispatch_user_callback ignoring exception c0000005 Memory layout at time of crash: msvcp140.dll 0x77CC0000 (32-bit, from winetricks vcrun2019) mfc140.dll 0x79000000 (32-bit, from winetricks vcrun2019) ToolkitPro* 0x76DB0000 (Codejock ToolkitPro 24.10 for MSVC 17.0) The same binary works correctly on Windows — all SEH handlers fire, the MDI client is initialized with tabbed document mode, files open as tabs. Regression: Previous build of the same application (binary date 2025-12-17) does not trigger this code path and works correctly under Wine. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 Wagner.a18@yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker Component|-unknown |mfc -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal --- Comment #5 from Austin English <austinenglish@gmail.com> --- Not a blocker. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59396 --- Comment #6 from Alexandre Julliard <julliard@winehq.org> --- Actually a return value of 1 from the handler means ExceptionContinueSearch. There must be something else going on here. -- 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.
participants (1)
-
WineHQ Bugzilla