July 2018 - Wine-Bugs - list.winehq.org

[Bug 45230] New: wine 3.8: gdi32.dll failed to initialize
by wine-bugs＠winehq.org Aug. 16, 2018

Aug. 16, 2018

https://bugs.winehq.org/show_bug.cgi?id=45230 Bug ID: 45230 Summary: wine 3.8: gdi32.dll failed to initialize Product: Wine Version: 3.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: countstarlight(a)gmail.com Distribution: --- Created attachment 61460 --> https://bugs.winehq.org/attachment.cgi?id=61460 wine error log System: Archlinux wine: 3.8 Upgrade wine from 3.7 to 3.8, the installed application not work. The Archlinux aur package repository at https://github.com/countstarlight/deepin-wine-tim-arch, and log in attachment After downgrading wine to version 3.7, the application can work, and not see "gdi32" in log. -- 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 14

[Bug 40412] New: When opening the game Stardew Valley, I get an error message and it never opens
by wine-bugs＠winehq.org Aug. 12, 2018

Aug. 12, 2018

https://bugs.winehq.org/show_bug.cgi?id=40412 Bug ID: 40412 Summary: When opening the game Stardew Valley, I get an error message and it never opens Product: Wine Version: 1.9.4 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: goodman.jaime(a)gmail.com Created attachment 54149 --> https://bugs.winehq.org/attachment.cgi?id=54149 backtrace file I get the message "This program has encountered a serious problem and needs to close" Logs 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 12

[Bug 44597] New: Window rendering com pletely breaks after interacting with the “Desktop Integration” section of winecfg with enabled GTK3 themeing
by wine-bugs＠winehq.org Aug. 10, 2018

Aug. 10, 2018

https://bugs.winehq.org/show_bug.cgi?id=44597 Bug ID: 44597 Summary: Window rendering completely breaks after interacting with the “Desktop Integration” section of winecfg with enabled GTK3 themeing Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexander-winehq(a)xmine128.tk CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 60584 --> https://bugs.winehq.org/attachment.cgi?id=60584 Changes in HKCU registry # Background & Steps to reproduce Window rendering will show bizare artifacts, up to becoming totally useless (tiny transparent window frames that cannot be interacted with), after following the below steps: 1. In WINE staging enable GTK3 themeing 2. Open `winecfg` again (things should be themed now) 3. Select the “desktop integration” tab 4. Change the “theme” from “GTK-3” to “(No Theme)” and click “Apply” 5. Do the above two times for noticable rendering issues and crashes 6. Do the above three (or more) times to break *any window rendering in WINE* (see attachment 2) # Underlying issue I'm not exactly sure what `winecfg` happens to do here, but it somehow manages to calculate and store some completely wrong values for several entries inside the HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics registry key (see attachment 1) that then result in this behaviour. # Workaround Open `${WINEPREFIX}/user.reg` in a text editor and delete the entire HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics registry key section before launching WINE again. -- 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 31741] New: python-2.7.3.amd64.msi fails to install
by wine-bugs＠winehq.org Aug. 9, 2018

Aug. 9, 2018

http://bugs.winehq.org/show_bug.cgi?id=31741 Bug #: 31741 Summary: python-2.7.3.amd64.msi fails to install Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tahoar(a)gmail.com Classification: Unclassified I tried installing Python 64-bit 2.7.3 on wine1.5-amd64. The installer loads but will not progress after the introduction page. When clicking "continue", the installer does nothing. Clicking "cancel" exits the installer. -- 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.

1 21

[Bug 45316] New: [Mansions of Madness] When character is missing from font it is not rendered, while on windows it is rendered with default font instead
by wine-bugs＠winehq.org Aug. 7, 2018

Aug. 7, 2018

https://bugs.winehq.org/show_bug.cgi?id=45316 Bug ID: 45316 Summary: [Mansions of Madness] When character is missing from font it is not rendered, while on windows it is rendered with default font instead Product: Wine Version: 3.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: konserw(a)gmail.com Distribution: --- Created attachment 61601 --> https://bugs.winehq.org/attachment.cgi?id=61601 sample screen from mansions of madness When character is missing from custom application's font it is not rendered at all, so it is hard to read words with such characters. On windows such characters are rendered with default font (times new roman?) instead. I know it's applications fault and windows does ugly workaround, but at least text is readable. In particular I stumbled on this when I've tried "Mansions of madness" with polish translation - application's fancy font doesn't have polish letters, like ąśćżźłę - in screenshot attached first option should read "Język: Polski" instead of "Jzyk: Polski" "Mansions of madness" are companion-app for board game and it is free on steam. First I've encountered this bug on Ubuntu Bionic x64 and wine-development from repository. For this bug I've reproduced this bug on Arch Linux x64 and wine-3.9 (Staging)(clean 32bit prefix, steam from winetricks, no overrides) -- 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 44373] New: cmd's %0 path variables (e.g. %~dp0) don' t match those of Windows (w.r.t. case and quoting)
by wine-bugs＠winehq.org Aug. 5, 2018

Aug. 5, 2018

https://bugs.winehq.org/show_bug.cgi?id=44373 Bug ID: 44373 Summary: cmd's %0 path variables (e.g. %~dp0) don't match those of Windows (w.r.t. case and quoting) Product: Wine Version: 3.0-rc6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: ryan.prichard(a)gmail.com Distribution: --- I'm filing this issue at Fabian Maurer's suggestion, after filing https://bugs.winehq.org/show_bug.cgi?id=44369. When %0 starts with a quote character, Windows tends to evaluate the %0 path variables (%~d0, %~p0, ...) strangely. I think the Wine behavior makes more sense, but it could also make sense to match Windows bug-for-bug. Test program (you might have to fix up the C:\bin for your machine): C:\>mkdir Bin C:\Bin\ShowArg0.Cmd: @echo [%0] -------------------- [%~d0] [%~p0] [%~n0] [%~x0] C:\Bin\RunScript.Cmd @echo off setlocal set PATH=C:\bin;%PATH% cd \ echo --- Wine and Windows roughly do the same thing. call showarg0 call SHOWARG0 call showarg0.cmd call SHOWARG0.CMD call C:\bin\showarg0 call C:\bin\showarg0.cmd call c:\bin\showarg0.CMD call showarg0".cmd" call showarg0."cmd" call showarg0.c"md" call s"ho"warg0.cmd call s"ho"warg0 call "C:\bin\showarg0.cmd" call "c:\bin\showarg0.CMD" echo --- Wine and Windows diverge here. call "showarg0" call "SHOWARG0" call "showarg0.cmd" call "SHOWARG0.CMD" call "showarg0".cmd call "sho"warg0.cmd call "sho"warg0 call "C":\bin\showarg0.cmd call "C:"\bin\showarg0.cmd call "C:\"bin\showarg0.cmd call "c:\"bin\showarg0.CMD call "C:\bin\showarg0" (I edited the script output to align the columns.) Windows behavior (tested on XP and Win10.0.16299.125): C:\Bin>RunScript --- Aside from case, Wine and Windows roughly do the same thing. --- ... Using c:\bin in PATH [showarg0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd] [SHOWARG0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd] --- ... Using C:\bin in PATH [showarg0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd] [SHOWARG0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd] [showarg0.cmd] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd] [SHOWARG0.CMD] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd] [C:\bin\showarg0] ---------- [C:] [\Bin\] [ShowArg0] [.Cmd] [C:\bin\showarg0.cmd] ------ [C:] [\Bin\] [ShowArg0] [.Cmd] [c:\bin\showarg0.CMD] ------ [c:] [\Bin\] [ShowArg0] [.Cmd] [showarg0".cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd] [showarg0."cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd] [showarg0.c"md"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd] [s"ho"warg0.cmd] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd] [s"ho"warg0] --------------- [C:] [\Bin\] [ShowArg0] [.Cmd] ["C:\bin\showarg0.cmd"] ---- [C:] [\Bin\] [ShowArg0] [.Cmd] ["c:\bin\showarg0.CMD"] ---- [c:] [\Bin\] [ShowArg0] [.Cmd] --- Wine and Windows diverge here. ["showarg0"] --------------- [C:] [\] [showarg0] [] ["SHOWARG0"] --------------- [C:] [\] [SHOWARG0] [] ["showarg0.cmd"] ----------- [C:] [\] [showarg0] [.cmd] ["SHOWARG0.CMD"] ----------- [C:] [\] [SHOWARG0] [.CMD] ["showarg0".cmd] ----------- [C:] [\] [showarg0"] [.cmd] ["sho"warg0.cmd] ----------- [C:] [\] [sho"warg0] [.cmd] ["sho"warg0] --------------- [C:] [\] [sho"warg0] [] ["C":\bin\showarg0.cmd] ---- [C:] [\C":\bin\] [showarg0] [.cmd] ["C:"\bin\showarg0.cmd] ---- [C:] [\"\bin\] [showarg0] [.cmd] ["C:\"bin\showarg0.cmd] ---- [C:] [\"bin\] [showarg0] [.cmd] ["c:\"bin\showarg0.CMD] ---- [c:] [\"bin\] [showarg0] [.CMD] ["C:\bin\showarg0"] -------- [C:] [\Bin\] [showarg0] [] Behavior on wine-3.0-rc6: C:\Bin>RunScript --- Aside from case, Wine and Windows roughly do the same thing. --- ... Using c:\bin in PATH [showarg0] ----------------- [c:] [\bin\] [showarg0] [.CMD] [SHOWARG0] ----------------- [c:] [\bin\] [SHOWARG0] [.CMD] --- ... Using C:\bin in PATH [showarg0] ----------------- [C:] [\bin\] [showarg0] [.CMD] [SHOWARG0] ----------------- [C:] [\bin\] [SHOWARG0] [.CMD] [showarg0.cmd] ------------- [C:] [\bin\] [showarg0] [.cmd] [SHOWARG0.CMD] ------------- [C:] [\bin\] [SHOWARG0] [.CMD] [C:\bin\showarg0] ---------- [C:] [\bin\] [showarg0] [.CMD] [C:\bin\showarg0.cmd] ------ [C:] [\bin\] [showarg0] [.cmd] [c:\bin\showarg0.CMD] ------ [c:] [\bin\] [showarg0] [.CMD] [showarg0".cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd] [showarg0."cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd] [showarg0.c"md"] ----------- [C:] [\bin\] [showarg0] [.cmd] [s"ho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd] [s"ho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD] ["C:\bin\showarg0.cmd"] ---- [C:] [\bin\] [showarg0] [.cmd] ["c:\bin\showarg0.CMD"] ---- [c:] [\bin\] [showarg0] [.CMD] --- Wine and Windows diverge here. ["showarg0"] --------------- [C:] [\bin\] [showarg0] [.CMD] ["SHOWARG0"] --------------- [C:] [\bin\] [SHOWARG0] [.CMD] ["showarg0.cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd] ["SHOWARG0.CMD"] ----------- [C:] [\bin\] [SHOWARG0] [.CMD] ["showarg0".cmd] ----------- [C:] [\bin\] [showarg0] [.cmd] ["sho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd] ["sho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD] ["C":\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd] ["C:"\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd] ["C:\"bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd] ["c:\"bin\showarg0.CMD] ---- [c:] [\bin\] [showarg0] [.CMD] ["C:\bin\showarg0"] -------- [C:] [\bin\] [showarg0] [.CMD] I see two differences: - In most cases, when a path starts with a quote, Windows somehow doesn't parse the path correctly and/or doesn't find the batch file in the PATH. - As long as Windows *does* find the batch file, it uses the canonical case for the path, filename, and extension. It doesn't canonicalize the drive; instead it uses the drive from the PATH or %0. I also tested a SMB share on XP and Win10 (\\nAs\nAs and \\NaS\NaS), and Windows didn't canonicalize the server name or share name. (Maybe it never does.) -- 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 34893] New: LaTale Launcher gives WSASocketW Failed to create a socket of type SOCK_RAW, this requires special permissions
by wine-bugs＠winehq.org Aug. 4, 2018

Aug. 4, 2018

http://bugs.winehq.org/show_bug.cgi?id=34893 Bug #: 34893 Summary: LaTale Launcher gives WSASocketW Failed to create a socket of type SOCK_RAW, this requires special permissions Product: Wine Version: 1.7.6 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: iyeru42(a)gmail.com Classification: Unclassified tried using the regnum fix: sudo setcap CAP_NET_RAW=ep /usr/bin/wine sudo setcap CAP_NET_RAW=ep /usr/bin/wineserver sudo setcap CAP_NET_RAW=ep LaTaleLauncher.exe Also applied it to the ogplauncher, Still gave the error. LaTale also requires GC_DONT_GC=1 before the wine command on the downloader for the client, since it's pandomediabooster. Get the client here: http://latale.ogplanet.com/en/download/client.og Pastebin: http://pastebin.com/FTT71zb1 -- 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.

1 6

[Bug 45211] New: Steam LTE 4G connection, instability
by wine-bugs＠winehq.org Aug. 3, 2018

Aug. 3, 2018

https://bugs.winehq.org/show_bug.cgi?id=45211 Bug ID: 45211 Summary: Steam LTE 4G connection, instability Product: Wine Version: 3.0.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shitman71(a)hotmail.com Distribution: --- Created attachment 61429 --> https://bugs.winehq.org/attachment.cgi?id=61429 Steam.exe log With 4G-internet on steam or with wine in general i am having troubles with my connection, using virtualisation and playing games works flawlessly. Its only wine making problems. Starting steam sometimes doesn't work and if it works it only runs a few minutes and then crashes. Iam getting the message: 0073:err:ntdll:RtlpWaitForCriticalSection section 0x603375c "?" wait timed out in thread 0073, blocked by 006e, retrying (60 sec) My firewall is having no problems, it just sometimes work and sometimes not. The signal is very good and it is also working on everything else except of wine. Iam guessing something is wrong the way wine handles network-connections. So far i only got this error-message. -- 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 44951] New: Add neon/xenial to your repository
by wine-bugs＠winehq.org Aug. 3, 2018

Aug. 3, 2018

https://bugs.winehq.org/show_bug.cgi?id=44951 Bug ID: 44951 Summary: Add neon/xenial to your repository Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: roadriverrail(a)gmail.com Distribution: --- Created attachment 61058 --> https://bugs.winehq.org/attachment.cgi?id=61058 Error when I add the repository I use KDE Neon installed on my Ubuntu xenial setup, and Neon requires a different entry in the repository. Could you please replicate your existing xenial entries for neon/xenial? -- 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 43436] New: Would it be possible to add Mageia 6 back to the Install page?
by wine-bugs＠winehq.org Aug. 3, 2018

Aug. 3, 2018

https://bugs.winehq.org/show_bug.cgi?id=43436 Bug ID: 43436 Summary: Would it be possible to add Mageia 6 back to the Install page? Product: Wine-staging Version: 2.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: arichter(a)lobo.net CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- I would sure like to see Mageia added back to the wine-staging Install page, Mageia has been very good about keeping up with the stable releases but staging is where all the fun is. I have been successfully building RPMS for both i586 and x86_64 under Mageia 6 and would be glad to submit RPMS or SRPMS for both architectures. Mageia 6 also now supports mock, which is what I have been using to build the i586 RPMs under x86_64. I apologize for submitting this as a bug since it's not a bug but I would either like to see Mageia back under the Install page or contribute built RPMS and SRPMS to help make it happen. I'm a bit new to this RPM building thing but the stuff I've made has worked out for me, and I've tried to be more active in the winedb. Thank you for your time and efforts, I only want to help on the Mageia side of things. -- 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 15