December 2019 - Wine-Bugs - list.winehq.org

[Bug 48248] New: safsdgfdghfgh
by WineHQ Bugzilla Dec. 12, 2019

Dec. 12, 2019

https://bugs.winehq.org/show_bug.cgi?id=48248 Bug ID: 48248 Summary: safsdgfdghfgh Product: Wine Version: 4.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: activeds Assignee: wine-bugs(a)winehq.org Reporter: randymitchel795(a)gmail.com Distribution: --- <a href="https://www.google.com/">google</a> [url=https://www.google.com]google[/url] https://www.google.com/ support number -- 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 35689] New: iMesh 7.x crashes on exit
by wine-bugs＠winehq.org Dec. 12, 2019

Dec. 12, 2019

https://bugs.winehq.org/show_bug.cgi?id=35689 Bug ID: 35689 Summary: iMesh 7.x crashes on exit Product: Wine Version: 1.7.13 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, as the summary says. Trace log doesn't reveal much: --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/iMesh Applications/iMesh $ WINEDEBUG=+tid,+seh,+relay,+wmp wine ./iMesh.exe >>log.txt 2>&1 ... 0025:Call KERNEL32.GetProcAddress(7eb20000,00b041b4 "WinHelpW") ret=008a28ab 0025:Ret KERNEL32.GetProcAddress() retval=7eb2bd50 ret=008a28ab 0025:Call user32.WinHelpW(0001009a,00000000,00000002,00000000) ret=0094b72c 0025:Ret user32.WinHelpW() retval=00000001 ret=0094b72c 0025:Call user32.CallWindowProcW(ffff002f,0001009a,00000002,00000000,00000000) ret=009405c5 0025:Call window proc 0x126035c (hwnd=0x1009a,msg=WM_DESTROY,wp=00000000,lp=00000000) 0025:Call user32.CallWindowProcA(ffff002e,0001009a,00000002,00000000,00000000) ret=00353f4a 0025:Call window proc 0x90f0bd (hwnd=0x1009a,msg=WM_DESTROY,wp=00000000,lp=00000000) 0025:Call KERNEL32.GetProcAddress(7eb20000,00b03c34 "DefWindowProcW") ret=008a28ab 0025:Ret KERNEL32.GetProcAddress() retval=7eb28b70 ret=008a28ab 0025:Call user32.DefWindowProcW(0001009a,00000002,00000000,00000000) ret=7ebd3d72 0025:Ret user32.DefWindowProcW() retval=00000000 ret=7ebd3d72 0025:Ret window proc 0x90f0bd (hwnd=0x1009a,msg=WM_DESTROY,wp=00000000,lp=00000000) retval=00000000 0025:Ret user32.CallWindowProcA() retval=00000000 ret=00353f4a 0025:Ret window proc 0x126035c (hwnd=0x1009a,msg=WM_DESTROY,wp=00000000,lp=00000000) retval=00000000 0025:Ret user32.CallWindowProcW() retval=00000000 ret=009405c5 0025:trace:seh:raise_exception code=c0000005 flags=0 addr=0x608915 ip=00608915 tid=0025 0025:trace:seh:raise_exception info[0]=00000000 0025:trace:seh:raise_exception info[1]=00000000 0025:trace:seh:raise_exception eax=00000000 ebx=00ed0040 ecx=03131afc edx=030e09c4 esi=03131afc edi=00de0a14 0025:trace:seh:raise_exception ebp=0033f43c esp=0033f410 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 0025:trace:seh:call_stack_handlers calling handler at 0x972775 code=c0000005 flags=0 0025:trace:seh:call_stack_handlers handler at 0x972775 returned 1 0025:trace:seh:call_stack_handlers calling handler at 0x98f5d7 code=c0000005 flags=0 0025:trace:seh:call_stack_handlers handler at 0x98f5d7 returned 1 0025:trace:seh:call_stack_handlers calling handler at 0x999b5c code=c0000005 flags=0 0025:trace:seh:call_stack_handlers handler at 0x999b5c returned 1 0025:trace:seh:call_stack_handlers calling handler at 0x999ae3 code=c0000005 flags=0 ... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00608915). ... Backtrace: =>0 0x00608915 in imesh (+0x208915) (0x0033f43c) 1 0x006e0d36 in imesh (+0x2e0d35) (0x0033f498) 2 0x009438ed in imesh (+0x5438ec) (0x0033f520) 3 0x00940829 in imesh (+0x540828) (0x0033f540) 4 0x006e1495 in imesh (+0x2e1494) (0x0033f568) 5 0x009425a8 in imesh (+0x5425a7) (0x0033f5c8) 6 0x00942638 in imesh (+0x542637) (0x0033f5e8) 7 0x7ebd3d72 WINPROC_wrapper+0x19() in user32 (0x0033f618) ... Modules: Module Address Debug info Name (173 modules) PE 350000- 3c7000 Deferred actskn45 PE 400000- bdf000 Export imesh PE 18b0000- 18d7000 Deferred nssdbm3 PE 3230000- 3273000 Deferred portablemediadevicewrapper PE 3390000- 33c6000 Deferred nspr4 PE 33d0000- 33f7000 Deferred smime3 PE 10000000-1005c000 Deferred resourcesloc ... Threads: process tid prio (all id:s are in hex) ... 00000024 (D) C:\Program Files\iMesh Applications\iMesh\iMesh.exe 0000004e 0 0000004d 0 0000004c 0 0000004b 0 00000049 0 00000048 0 00000029 0 0000002a 0 0000000d 0 0000000b 0 00000046 0 00000045 0 00000044 0 00000043 -15 00000042 0 00000041 0 00000040 -1 0000003f 0 0000003e 0 0000003d -1 0000003c 0 0000003b 0 0000003a 0 00000039 0 00000038 0 00000037 0 00000036 0 00000028 -1 00000027 0 00000026 0 00000025 1 <== --- snip --- 'winetricks wmp10' works around. >From what I've gathered through debugging it seems the NULL pointer access is related to IWMPControls::stop(). The pointer accessed could be IWMPControls* returned by IWMPCore::get_controls(). Unfortunately I didn't find any FIXME reference to IWMPCore::get_controls() in trace log (stub right now). It's probably triggered by some code not in place yet because WMP is work-in-progress and various parts are incomplete. $ sha1sum iMeshV7.exe 0e4aa7ae0da88b7f69a7daa1bca36f3f2f6c497b iMeshV7.exe $ du -sh iMeshV7.exe 8.4M iMeshV7.exe $ wine --version wine-1.7.13-100-gfcae016 Regards -- 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 46466] New: Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism
by wine-bugs＠winehq.org Dec. 12, 2019

Dec. 12, 2019

https://bugs.winehq.org/show_bug.cgi?id=46466 Bug ID: 46466 Summary: Accessing 32-bit DLLs from 64-bit code through COM as an IPC mechanism Product: Wine Version: 4.0-rc6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: reinhold.hoffmann(a)hotmail.com Distribution: --- For more than 10 years a brilliant blog exists how to start a 32-bit DLL from an x64 application. This sound weird but in case a DLL cannot be converted to 64-bit for whatever reason such a solution is very helpful. In the blog there is a method described how to do this. The blog is very sophistcated. Please see https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ On Windows accessing a DLL through the COM IPC mechanism works like a charm. On Wine64 a 32-bit DLL can only be accessed and executed from a 32-bit app through a COM IPC mechanism (btw. works great). But accessing the 32-bit DLL through a COM IPC mechanism from the same x64 version of such an app fails. Of course, such a capability is beyond Wine-4.0. But it would be great if a fix could be addressed in the scope of Wine-5.0. I try to provide a sample which demonstrate the issue. May be somebody familiar with the COM IPC mechnism may help to address the right component. Thx. Reinhold -- 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 13

[Bug 9850] New: win16 test suite multiple failures
by wine-bugs＠winehq.org Dec. 11, 2019

Dec. 11, 2019

http://bugs.winehq.org/show_bug.cgi?id=9850 Summary: win16 test suite multiple failures Product: Wine Version: 0.9.46. Platform: Other URL: http://win16test.googlecode.com OS/Version: other Status: NEW Keywords: download, source Severity: enhancement Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Jennifer Lai put together a win16 test suite as her intern project this summer, with a little guidance from me. The code is a combination of win16 tests that had been posted in the past, and backports of 32 bit wine tests. Jennifer says the tests pass on Windows XP. The code can be downloaded from http://win16test.googlecode.com with svn, and is quite easy to run; see http://win16test.googlecode.com/svn/trunk/src/README for instructions. There are four or five crash failures and several lesser failures. She has proposed patches to fix most of these at http://win16test.googlecode.com/svn/trunk/src/patches/ I think there are mistakes in at least one of her patches, but they're still a good starting point We would have liked to commit the win16 tests as part of the wine source tree, but Alexandre didn't want us to, so we created a project at googlecode.com to host them. I'll gladly give committer status to any serious wine developer who wants to work on them. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 12

[Bug 48269] New: Tray icon (XEMBED) moves when (0,0) coordinate is outside of the drawing area
by WineHQ Bugzilla Dec. 11, 2019

Dec. 11, 2019

https://bugs.winehq.org/show_bug.cgi?id=48269 Bug ID: 48269 Summary: Tray icon (XEMBED) moves when (0,0) coordinate is outside of the drawing area Product: Wine Version: 4.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: materka(a)gmail.com Distribution: --- Created attachment 65934 --> https://bugs.winehq.org/attachment.cgi?id=65934 Monitor layouts For some uncommon monitor layouts wine tray icon is not working correctly. When XEMBED is used X11 window should never move, because it is managed by the system tray. KDE positions all tray icons in (0,0) position and renders them off-screen (XComposite + XDamage). When screens are configured in a way, that (0,0) is not is the first screen (?) area (attachment), wine icon tray window tries to move itself. This repeats, window is moved further and further with each event (not sure how it is triggered). For example, primary screen has size 1440x900, second screen 900x1600 (vertical position) and is positioned right of the primary screen, bottoms aligned. Check attached picture for reference (second "NOT OK" example). It this scenario (0,0) is 700 px above the primary screen (1600 - 900 = 700). Wine will move tray icon to the position (0, 700). This should not happen, because tray icon window is embedded, so it is managed by parent window. I *suspect* the move is performed "UpdateLayeredWindowIndirect" in dlls/user32/win.c. It calls set_window_pos which then moves the window using X11 functions. I'm not that familiar with X11 to trace it correctly. I tested mainly with wine-4.21 (Staging), but it also reproducible with old wine 3.6. Originally reported on KDE bug tracker: https://bugs.kde.org/show_bug.cgi?id=414667 -- 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 34859] New: Serious Sam Classic: the game's world is closed in a giant cube (Mac OS X only bug)
by wine-bugs＠winehq.org Dec. 11, 2019

Dec. 11, 2019

http://bugs.winehq.org/show_bug.cgi?id=34859 Bug #: 34859 Summary: Serious Sam Classic: the game's world is closed in a giant cube (Mac OS X only bug) Product: Wine Version: 1.7.5 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: winebugs140(a)gmail.com Classification: Unclassified Created attachment 46460 --> http://bugs.winehq.org/attachment.cgi?id=46460 Serious Sam Classic Log You can see this especially when looking at the sky, there are also some lines visible in the ground. I've attatched a screenshot. The bug seems to be GPU independent. On Ubuntu everything looks fine. The problem can be reproduced in the demo (check out the link). Tested with: Mac OS X 10.7 and 10.9, ATI HD 2600 Pro, ATI HD 6970M, Geforce 320M, Mac Driver/X11 -- 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.

2 7

[Bug 47596] New: Invision Studio installer don't work
by wine-bugs＠winehq.org Dec. 11, 2019

Dec. 11, 2019

https://bugs.winehq.org/show_bug.cgi?id=47596 Bug ID: 47596 Summary: Invision Studio installer don't work Product: Wine Version: 4.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ieframe Assignee: wine-bugs(a)winehq.org Reporter: wiiu3dsxl13127(a)gmail.com Distribution: --- Created attachment 65010 --> https://bugs.winehq.org/attachment.cgi?id=65010 Log The app launch but due to a bug in wine with the ieframe.dll and tzres.dll, the app make an error -- 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 9

[Bug 48262] New: DirectX 9 SDK "lightingvs.exe" fails
by WineHQ Bugzilla Dec. 10, 2019

Dec. 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=48262 Bug ID: 48262 Summary: DirectX 9 SDK "lightingvs.exe" fails Product: Wine Version: 4.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: yurikazakov9184(a)gmail.com Distribution: --- Created attachment 65928 --> https://bugs.winehq.org/attachment.cgi?id=65928 Screenshot When I try to run the LightingVS demo using WineD3D, I see a blue screen and a lot of errors in the terminal. Errors occur regardless of the driver used. Binary file placed in C++/Direct3D/Bin/LightingVS.exe Source placed in C++/Direct3D/LightingVS This is Samples folder from other DirectX9 SDK. This demo is not available in the DirectX 9.29 sdk; it is only available in older versions of the DirectX 9 SDK. -- 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 48243] New: Could not find any compatible 3D devices in RTPatch sample
by WineHQ Bugzilla Dec. 10, 2019

Dec. 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=48243 Bug ID: 48243 Summary: Could not find any compatible 3D devices in RTPatch sample Product: Wine Version: 4.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: yurikazakov9184(a)gmail.com Distribution: --- This sample works on Windows, but not working with WineD3D. Error "Could not find any compatible Direct3D devices. This sample will now exit.". Binary file placed in C++/Direct3D/Bin/RTPatch.exe Source placed in C++/Direct3D/RTPatch This is Samples folder from other DirectX9 SDK. https://archive.org/download/dx9sdk -- 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 48260] New: DrawText with len -1 returns a different height under WINE than in Windows
by WineHQ Bugzilla Dec. 10, 2019

Dec. 10, 2019

https://bugs.winehq.org/show_bug.cgi?id=48260 Bug ID: 48260 Summary: DrawText with len -1 returns a different height under WINE than in Windows Product: Wine Version: 3.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: ryampolsky(a)yahoo.com Distribution: --- The following 2 lines of code return different values for 'height' on WINE and Windows when p points to a null string, but the differences are different. height = DrawText(hDC, p, -1, &rc, dt_options|DT_WORDBREAK|DT_NOPREFIX); height = DrawText(hDC, p, strlen(p), &rc, dt_options|DT_WORDBREAK|DT_NOPREFIX); On Windows, the first case (length -1 : telling Windows to calculate the string length) returns a height of 1. On WINE it returns a height of 14 - i.e. the height of an actual row of text using the currently selected font. On both Windows and WINE, the second case (where I pass in the length of 0) returns a height of 0. I don't know why Windows doesn't return a 0 height for a null string when you pass in a -1 length, but both Windows and WINE do this. Except that WINE returns the height of a row of text, and Windows returns 1 pixel - which ends up producing no visible different in my code - where this issue shows up. I changed my code to pass in the length instead of counting on -1 to get Windows to do it, but I guess any difference between Windows and WINE is a 'bug', huh? -- 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