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

[Bug 46736] New: Doom 3: BFG Edition freezes when using gnome shortcut or fails with error when running from terminal
by wine-bugs＠winehq.org Oct. 9, 2020

Oct. 9, 2020

https://bugs.winehq.org/show_bug.cgi?id=46736 Bug ID: 46736 Summary: Doom 3: BFG Edition freezes when using gnome shortcut or fails with error when running from terminal Product: Wine-staging Version: 4.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: linards.liepins(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 63734 --> https://bugs.winehq.org/attachment.cgi?id=63734 terminal log doom3bfg114 gog Game crashes with ID error window. Error message similar to the one. as shown in the following thread(s): https://steamcommunity.com/app/208200/discussions/0/864949037819880093/ https://www.gog.com/forum/doom_series/doom_3_bfg_edition_is_not_working_wit… Attaching error logs for both steam and GOG versions. -- 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 11

[Bug 40735] New: Midnight Mysteries: The Edgar Allan Poe Conspiracy (Steam ) fails to start (probably needs msscript)
by wine-bugs＠winehq.org Oct. 9, 2020

Oct. 9, 2020

https://bugs.winehq.org/show_bug.cgi?id=40735 Bug ID: 40735 Summary: Midnight Mysteries: The Edgar Allan Poe Conspiracy (Steam) fails to start (probably needs msscript) Product: Wine Version: 1.9.11 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com Distribution: --- This is the only game from the Midnight Mysteries series on Steam which refuses to start. The game displays an error message after start: 'Exception EOleSysError in module Midnight Mysteries - Edgar Allan Poe Conspiracy.exe at 0008B9AD. OLE error 80004002.' In the terminal: >fixme:msscript:ScriptControl_QueryInterface (0x177000)->({00000112-0000-0000-c000-000000000046} 0x33fca8) >fixme:ole:CoCreateInstanceEx no instance created for interface {00000112-0000-0000-c000-000000000046} of class {0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc}, hres is 0x80004002 I installed msscript.ocx with winetricks, and now the game window is opened and sound begins to play for a second then the game throws a different error: 'Access violation error at address....'. The error dialog box can't be dismissed, it's popping up continuously. This is the terminal output with native msscript.ocx: >err:ole:CoCreateInstanceEx apartment not initialised >fixme:jscript:JScript_SetScriptState unimplemented SCRIPTSTATE_INITIALIZED >fixme:win:EnumDisplayDevicesW ((null),0,0x33f7e8,0x00000000), stub! >fixme:win:EnumDisplayDevicesW ((null),0,0x33f638,0x00000000), stub! wine-1.9.11-112-gd864119 -- 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 52

[Bug 48233] New: In a 64-bit app, GetSyscolor(COLOR_BTNSHADOW) returns a darker value than on windows
by WineHQ Bugzilla Oct. 9, 2020

Oct. 9, 2020

https://bugs.winehq.org/show_bug.cgi?id=48233 Bug ID: 48233 Summary: In a 64-bit app, GetSyscolor(COLOR_BTNSHADOW) returns a darker value than on windows Product: Wine Version: 3.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: ryampolsky(a)yahoo.com Distribution: --- Created attachment 65879 --> https://bugs.winehq.org/attachment.cgi?id=65879 Screenshot, showing shadow drawn with GetSysColor(COLOR_BTNSHADOW) I recently converted my 32-bit app to 64-bits, and when I run either the 32-bit version or the 64-bit version under a wine64 WINEPREFIX, the only difference I notice is the value returned by GetSyscolor(COLOR_BTNSHADOW). On Windows in both the WIN32 and WIN64 versions of my app, it returns 0xa0a0a0, but on WINE64, it returns 0x4c4c4c. On WINE, I'm using the Ubuntu Light theme. With that theme in effect, on WINE32, GetSysColor(COLOR_BTNSHADOW) returns 0xa5a9ad. But on WINE64, both the WIN32 and WIN64 versions get 0x4c4c4c. So the shadow looks too dark. Again, the WIN32 exe gets the right color under WINE32, but the same wrong color as the WIN64 exe under WINE64 - which is why I think it's a WINE64 bug and not my app. Everything else seems to look the same between WINE32 and WINE64. The attached screenshot shows the About dialog from my app. There's a 3D frame around the logo at the top - BTNSHADOW on top and left, BTNHIGHLIGHT on bottom and right. The text below it shows that this is the X64 version of the app, and prints out the value returned by GetSysColor(COLOR_BTNSHADOW). -- 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 43947] New: Disk size in Wine is not correct
by wine-bugs＠winehq.org Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=43947 Bug ID: 43947 Summary: Disk size in Wine is not correct Product: Wine Version: 2.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: christoph.heilmann(a)gmx.de Distribution: --- Created attachment 59586 --> https://bugs.winehq.org/attachment.cgi?id=59586 disk size windows Dual Xeon E5-2630v4 (!!) Ubuntu 17.04 Server Kernel 4.10.0-37 Wine 2.0.3 WINEARCH=win64 WINEPREFIX=/home/christoph/.wine64 christoph@:/$ df -h Filesystem Size Used Avail Use% Mounted on udev 126G 0 126G 0% /dev tmpfs 26G 11M 26G 1% /run /dev/sda2 450G 166G 262G 39% / tmpfs 126G 0 126G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 126G 0 126G 0% /sys/fs/cgroup /dev/sda1 226M 58M 153M 28% /boot The disk size in Wine is not correct (see attachment). -- 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 17

[Bug 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow
by WineHQ Bugzilla Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=2155 --- Comment #28 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68359 --> https://bugs.winehq.org/attachment.cgi?id=68359 Rebased user32-rawinput-mouse-experimental series -- 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 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow
by WineHQ Bugzilla Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=2155 --- Comment #27 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68358 --> https://bugs.winehq.org/attachment.cgi?id=68358 Rebased user32-rawinput-mouse series -- 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 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow
by WineHQ Bugzilla Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=2155 --- Comment #26 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68357 --> https://bugs.winehq.org/attachment.cgi?id=68357 Rebased user32-rawinput-hid series -- 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 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow
by WineHQ Bugzilla Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=2155 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #25 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 68356 --> https://bugs.winehq.org/attachment.cgi?id=68356 Patch series addressing several focus inconsistencies. I spent some time digging into focus issues lately and I believe this issue has several root causes. First of all of course, Wine currently doesn't implement any mechanism to activate other windows on the X11 side. This is implemented by the staged patch, but I believe it can then trigger other focus problems that Wine suffers from. With or without the patch, the root issues are: 1) I believe there's a race condition in the SetForegroundWindow / SetActiveWindow implementation. When multiple threads are involved, SetActiveWindow requests from other threads are only applied when the thread checks its messages, possibly overwriting changes that were done by the thread itself. 2) The asynchronous nature of the focus handling code: Wine applies the Win32 focus state changes immediately, but processes -- and applies -- the results of the X11 activation requests only later, during window message processing. 3) Windows allows hidden windows to be focused and foreground, X11 doesn't allow unmapped windows to be. This is a fundamental difference and it is pretty hard to solve, we currently implement hidden windows as unmapped X11 windows, as it is probably the only way to have truly invisible windows, but it makes it impossible to keep the X11 state consistent in that case. The solutions are either to map hidden windows, using some other mechanism to hide them as much as possible, bottom-most attribute being perhaps the least brittle. Or, as a possible mitigation, force change X11 focus when hidden window is supposed to be focused, so that X11 will send focus change events when it changes back to another window. 4) SetForegroundWindow is not supposed to always succeed, although Wine always pretend it does. The _NET_ACTIVE_WINDOW request also not always succeed, but as we can't wait for its possible result, it is hard to return a reliable success status. This is especially the case with the staged patch, that sends activation requests to be applied later, but it is also the case with user focus changes. Having the X11 events processed and applied only when message processing can trigger a race condition where X11 related focus changes will overwrite the already executed Win32 focus changes, possibly ending up in an inconsistent state. Also, because of 1), when focus events come on several threads, SetActiveWindow messages coming from other threads may be applied at the same as the X11 events are processed and applied, making things even more inconsistent. The attached patch series should help fixing these issues. First of all, it fixes the incorrect message processing order in 1). Then it should try to make 2) work better by tracking X11 focus globally in explorer.exe, so that we don't rely on application processing their messages anymore, and by discarding old SetForegroundWindow requests based on their timestamp. Last, it also implements a similar feature as the staged _NET_ACTIVE_WINDOW patch to send X11 activation requests, but it adds a mitigation for 3) and 4), where SetForegroundWindow returns failure if X11 focus is not on another Wine window, and where SetActiveWindow forcefully unsets X11 focus when hidden window is activated. It is still not completely matching Windows behavior, as SetForegroundWindow should probably return FALSE in more cases, but the details are a little bit more complicated and it may also break some currently working cases. I'm currently trying to upstream the first patches, but the way internal messages gets discarded needed some discussion. The whole series also could benefit from more extensive testing. This is also probably going to conflict with the rawinput patch series, as there are changes in the XInput2 code to get Focus messages with timestamps if possible. I'll attach rebased versions next in the eventuality this goes into staging. -- 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 49959] New: Error 430 class does not support automation
by WineHQ Bugzilla Oct. 8, 2020

Oct. 8, 2020

https://bugs.winehq.org/show_bug.cgi?id=49959 Bug ID: 49959 Summary: Error 430 class does not support automation Product: Wine Version: unspecified Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: handzdwn(a)protonmail.com Error 430 when trying open 911.re -- 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 4977] Mindstar Script Editor aborts on startup with "Runtime Error 430: Class does not support Automation..."
by WineHQ Bugzilla Oct. 7, 2020

Oct. 7, 2020

https://bugs.winehq.org/show_bug.cgi?id=4977 Methodmanx6 <handzdwn(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |handzdwn(a)protonmail.com -- 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