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

[Bug 30641] New: wine silently replaces requests for thexture formats not supported by hardware with invalid requests
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

http://bugs.winehq.org/show_bug.cgi?id=30641 Bug #: 30641 Summary: wine silently replaces requests for thexture formats not supported by hardware with invalid requests Product: Wine Version: 1.5.1 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: hramrach(a)gmail.com Classification: Unclassified When running a d3d application using s3tc on drivers that don't have support for that texture format wine gives lots of complaints like: err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2566 err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexSubImage2D @ surface.c / 2349 GL trace shows: 37923 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_ZERO, width = 64, height = 64, border = 0, format = GL_ZERO, type = GL_ZERO, pixels = NULL) 37923: warning: glGetError(glTexImage2D) = GL_INVALID_VALUE This is totally useless and bogus. 1) no message is logged about the application using a format that is not supported. 2) bogus format is used instead so nobody outside of wine can figure out WTF it is the application tried to do that did not work. -- 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 9

[Bug 37773] New: Handel-C compiler extremely slow under WIne compared to Windows
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

https://bugs.winehq.org/show_bug.cgi?id=37773 Bug ID: 37773 Summary: Handel-C compiler extremely slow under WIne compared to Windows Product: Wine Version: 1.7.33 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: felix.huber(a)schyf.de Distribution: --- Handel-C (a C to FPGA synthesis tool) compiles a typical design in 15 minutes when using Win 7 in a Virtualbox. When run under wine, no special error messages appeared, but after 10h the compilation was still not finished and I aborted it. I re-ran it with operf and stopped after some 15minutes. The result was that 95% of the time was spent in heap.c of ntdll.dll.so in function HEAP_FindFreeBlock. So I ran wine with WINEDEBUG=trace+heap,+relay and I see a lot of malloc() and free(), but execution is so slow that I can't really see what's going on. The problem might not be related to Handel-C but the way wine manages the heap, as I see also lots of malloc/free with other windows applications, even when they're idle. Tests were done with Opensuse 64bit 12.3, 13.1 and 13.2 with Kernel from 3.11 to 3.18, all with the same slow performance. The setup was always a clean installation with only MFC42 installed with winetricks, as this was needed by the app. No differences were found when switching between native and builtin MSVCRT dlls. I wonder how I can narrow down the cause of this poor performance. -- 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 10

[Bug 30182] New: SuperPower 2 demo installation aborted
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

http://bugs.winehq.org/show_bug.cgi?id=30182 Bug #: 30182 Summary: SuperPower 2 demo installation aborted Product: Wine Version: 1.4 Platform: x86 URL: http://www.gamefront.com/files/3631719/SuperPower_2_De mo OS/Version: Linux Status: NEW Keywords: download, Installer, regression Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com CC: hans(a)meelstraat.net Classification: Unclassified Regression SHA1: fa2420d6960df77d6073e3666d375936c5999fe7 Created attachment 39392 --> http://bugs.winehq.org/attachment.cgi?id=39392 terminal output Near at the end of the install process I get the following error message: "Feature transfer error - Error: -1603 Fatal error during installation." Afterwards the installer reverts all changes. Installation works with Wine-1.4 but not with wine-1.4-284-gc5faf15. fa2420d6960df77d6073e3666d375936c5999fe7 is the first bad commit commit fa2420d6960df77d6073e3666d375936c5999fe7 Author: Hans Leidekker <hans(a)codeweavers.com> Date: Mon Mar 12 12:26:34 2012 +0100 msi: Perform a case insensitive match on filenames from cabinets. :040000 040000 6b7210c4e9372efd6a5d2ad5b1d9d99eecf57a45 55e5b3a84d2e1c72443ba9bbe2cf295098f8c5b2 M dlls The reverted patch fixed the problem. -- 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 5

[Bug 19350] New: right click context menu requires multiple left clicks, and multiple selections (control-or-shift) selecting is buggy
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

http://bugs.winehq.org/show_bug.cgi?id=19350 Summary: right click context menu requires multiple left clicks, and multiple selections (control-or-shift) selecting is buggy Product: Wine Version: 1.1.25 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: wine(a)tehk.org When using flashfxp, connecting to a remote ftp site and then a list of the files/folders on the remote site will appear. At first, when an attampt is made to select multiple files (while holding control or shift to select them) several clicks on a single file must be made first in order to then complete this action. secondly, when right clicking and bringing up a context menu, it requires 2 left clicks on any item in the menu to select that action versus the standard one click. -- 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 23

[Bug 18787] New: Implement interlocked.c for Solaris/x86 using Sun C
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

http://bugs.winehq.org/show_bug.cgi?id=18787 Summary: Implement interlocked.c for Solaris/x86 using Sun C Product: Wine Version: 1.1.22 Platform: PC OS/Version: Solaris Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: baggett.patrick(a)gmail.com When compiling Wine from source tarball on Solaris 10 5/09 with Sun Studio 12 cc I get the following message: "You must implement the interlocked* functions for your compiler" Sun C uses the same inline assembly language format as GCC, so simply changing line 27 at top of libs/port/interlocked.c to read: #if defined(__GNUC__) || defined(__SUNPRO_C) causes it to successfully compile using the inline assembly. Given the trivial nature of this, is there any way this can be merged? -- 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 12

[Bug 12553] New: Toolbars misplaced, hidden
by wine-bugs＠winehq.org Aug. 17, 2018

Aug. 17, 2018

http://bugs.winehq.org/show_bug.cgi?id=12553 Summary: Toolbars misplaced, hidden Product: Wine Version: 0.9.59. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tarasov.igor(a)gmail.com Created an attachment (id=12122) --> (http://bugs.winehq.org/attachment.cgi?id=12122) WINEDEBUG=+toolbar,+listview,+themingcombo wine 0.9.59 log Here are two screenshots: Wine being run with MS comctl32.dll, the same thing you see in Windows: http://polosatus.ru/wine/toolbar_reference.png And wine running with it's own version of comctl32: http://polosatus.ru/wine/toolbar_bug.png First of all, disappeared toolbar at the middle of screenshot. Also, notice misplaced right toolbar. It is misplaced to left a bit. I suppose both bugs are related. Seems that developers have used some undocumented features, as log has this: warn:toolbar:TOOLBAR_SetBitmapSize 5 buttons, undoc increase to bitmap size : 16-15 -> 20-20 and this: warn:toolbar:TOOLBAR_SetBitmapSize 6 buttons, undoc increase to bitmap size : 20-20 -> 16-16 several times. I've supposed that WINEDEBUG=+toolbar,+listview,+themingcombo should be enough for initial log :) -- 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 42

[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 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