March 2014 - Wine-Devel - list.winehq.org

Re: [3/3] rpcrt4/tests: Add a couple of tests for marshalling an array of strings. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/rpcrt4/tests/server.c | 55 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/rpcrt4/tests/server.idl | 5 ++++ > 2 files changed, 60 insertions(+) It doesn't work on 64-bit: ../../../../wine/tools/runtest -q -P wine -T ../../.. -M rpcrt4.dll -p rpcrt4_test.exe.so server && touch server.ok server.c:1240: Test failed: expected Hello, got H server.c:1241: Test failed: expected World!, got W server.c:1250: Test failed: expected Hello, got L"H\0003" server.c:1251: Test failed: expected World!, got L"W\0001" server: 4 failures in child process server.c:1240: Test failed: expected Hello, got H server.c:1241: Test failed: expected World!, got W server.c:1250: Test failed: expected Hello, got L"H\0003" server.c:1251: Test failed: expected World!, got L"W\0001" server: 4 failures in child process server.c:1240: Test failed: expected Hello, got H server.c:1241: Test failed: expected World!, got W server.c:1250: Test failed: expected Hello, got L"H\0003" server.c:1251: Test failed: expected World!, got L"W\0001" server: 4 failures in child process make[1]: *** [server.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

March 24, 2014

Re: user32: Workaround SetForegroundWindow failure due to foreground lock timeout

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5923 Your paranoid android. === w8 (32 bit win) === win.c:6403: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6425: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6403: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6403: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6403: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6403: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6403: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6425: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6403: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6425: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 win.c:6186: Test failed: wrong error 31

March 24, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

I was able to find the frame and exact call which draws the cursor under the Windows XP code paths: it's drawn toward the end of the frame in two DrawPrimitiveUP calls. I ran into trouble tracing the Wine codepaths for the same: I first tried running the Win32 version of apitrace under Wine. It runs successfully but never generates a .trace file, even when I specify --output. If I ask it to run a program which doesn't load d3d9.dll, it emits a warning saying as much, so I know it's running. Anyone have success running the Win32 version of apitrace under Wine and getting a .trace file? I then tried cross-compiling Wine from Linux using MinGW. I copied over the resulting d3d9.dll and wined3d.dll to the game's directory on Windows XP but it then won't run, complaining: "The procedure entry point __wine_get_wgl_driver could not be located in the dynamic link library gdi32.dll." So I tried copying over Wine's cross-compiled gdi32.dll but the message doesn't change. My guess is you cannot locally override gdi32? Should __wine_get_wgl_driver be in gdi32? Any idea how I can get the game to launch using Wine's DLLs? I also have the Wine codepath OpenGL trace (from the Linux version of apitrace, tracing Wine) in which I've identified the frame but not the calls yet, so I cannot say if the texture is loaded correctly under Wine's codepaths or not yet. On 3/21/2014 9:10 AM, Matteo Bruni wrote: > 2014-03-21 10:14 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-03-21 03:24, schrieb Christopher Thielen: >>> apitrace is really neat, thanks for pointing it out. I ran it on >>> Windows XP with the Ultima IX (GOG edition) and generated a trace - >>> which shows the missing mouse cursor - then rebooted into Linux and >>> ran the Windows version of apitrace's GUI using the same .trace >>> file and it _did_ also show the mouse cursor, running under Wine. >> It means one thing for sure: The cursor is not a user32 cursor. >> Otherwise it would not show up in the captures. >> >> I have two theories: Either the game looks at the d3d capabilities >> (CheckDeviceFormat, GetDeviceCaps, mostly IDirect3D9 methods) and >> concludes that something is missing, enters a bad codepath and does >> not draw the pointer. >> >> Or some function unrelated to d3d does not work and the game fails to >> read the pointer from its resources. >> >> Since this is a glide application running through a glide wrapper the >> second case is much more likely. (Unless my memory is completely broken) >> >> You can compile wined3d for Windows. The basic idea is to set >> CFLAGS=-DUSE_WIN32_OPENGL and compile it with mingw on Windows, or >> Cross-Compile it from Linux. I also have a hacky Visual Studio 2013 >> based build setup, but you'll have a hard time generating a binary >> that works on Windows XP with that. With a Win32 build of wined3d.dll >> and our d3d9.dll you can run the game on Windows with our d3d code. If >> the pointer shows up in that case this demonstrates that it is not a >> d3d issue. If it does not, it shows that the issue is a capability >> flag problem. >> >>> Also, I don't know apitrace that well, but is the per-frame >>> 'texture' tab only showing textures utilized in that frame, not >>> counting anything already in the framebuffer? I couldn't find the >>> cursor texture after looking at about two dozen frames, but then >>> again, I didn't find most textures using that method. >> No idea :-( >> > I never used apitrace on D3D traces, I assume it works in the same > fashion as on GL ones. > The 'texture' tab shows the textures bound to the texture units at > that point in time, each one of them might or might not be used by the > draw call you're examining. You should check the shaders (or the state > of the fixed function pipeline, if no shaders are bound) to know which > of those textures are actually used by the draw you're looking into. > > What you can do at this point is to go through the draw calls of a > frame, looking for the one which draws the cursor (I would do that > just by looking at the framebuffer contents). Then run the game in > Wine + apitrace and see if you can find the same draw in the GL trace. > Either the draw is there, in which case you can look into why it > doesn't draw anything, or the call is totally missing, which would > support the hypothesis of the bad caps / wrong game codepath. >

March 24, 2014

Re: [PATCH 2/2] wininet: Fixed tests on some old Windows versions.

by Jacek Caban

On 03/24/14 16:48, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=5909 > > Your paranoid android. > > > === w8 (32 bit http) === > http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) > http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) > http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) > http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) > http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) > http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) > http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) > http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) > http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) > http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) > http.c:4292: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800000, expected 800000 > http.c:4292: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800000, expected 800000 > http.c:4295: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800080, expected 800080 > http.c:4295: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800080, expected 800080 > http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) > http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) > http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) > http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) > http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) > http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) > http.c:957: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 2 times, received 1 times > http.c:958: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 2 times, received 1 times > http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) > http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) > http.c:4620: Test failed: expected ERROR_HTTP_HEADER_NOT_FOUND, got 0 Those are unrelated: https://testbot.winehq.org/JobDetails.pl?Key=5906 Cheers, Jacek

March 24, 2014

Re: [PATCH 2/2] wininet: Fixed tests on some old Windows versions.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5909 Your paranoid android. === w8 (32 bit http) === http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:4292: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800000, expected 800000 http.c:4292: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800000, expected 800000 http.c:4295: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800080, expected 800080 http.c:4295: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800080, expected 800080 http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:957: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 2 times, received 1 times http.c:958: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 2 times, received 1 times http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:4620: Test failed: expected ERROR_HTTP_HEADER_NOT_FOUND, got 0

March 24, 2014

Re: [PATCH 1/2] wininet: Merge GetLastError() test into other request tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5908 Your paranoid android. === w2000pro (32 bit http) === http.c:3058: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 1 times, received 0 times http.c:3059: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 0 times === w8 (32 bit http) === http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:4284: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800000, expected 800000 http.c:4284: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800000, expected 800000 http.c:4287: Test failed: INTERNET_OPTION_SECURITY_FLAGS flags = 1800080, expected 800080 http.c:4287: Test failed: INTERNET_OPTION_SECURITY_FLAGS(98) flags = 1800080, expected 800080 http.c:318: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:318: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:318: Test failed: unexpected status 20 (INTERNET_STATUS_CONNECTING_TO_SERVER) http.c:318: Test failed: unexpected status 21 (INTERNET_STATUS_CONNECTED_TO_SERVER) http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:957: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 2 times, received 1 times http.c:958: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 2 times, received 1 times http.c:318: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:318: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:4612: Test failed: expected ERROR_HTTP_HEADER_NOT_FOUND, got 0

March 24, 2014

Re: dxdiagn: Added properties for hardware acceleration capabilities

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-24 02:24, schrieb Markus Weiland: > Is this implementation ok? Looks good to me. I guess there's a difference between those 3 flags and I guess at least bDDAccelerationEnabled should be queried from ddraw, but I think your patch is a reasonable first step. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTMCGxAAoJEN0/YqbEcdMw+FoP/Ags1yIt7IQgX77r6wFsS+vM n9LRuK2ZojOSCKrU/XeWy2X1txHSGXAA5ccqaqqr+EtFLOdOIYGM7qs8jpWBQFex 8nLSjYCMh6e0uG5qFZQUEH7WIcNgLd5SZmkbeqnCGdNem67YiSVrPGM8+9ujc9BY xBPG4s5iittmj2Q0sOBSyCzgRNIJeA6WivtGqxPEGhiiG2+GgcJgMrPv271jpZgy bCdF4M7f19TUofNEwLnyWbL7QJ9CvLPXJ3s6m0gQmz+N/GI9xG/hmhZHRo2yTWH7 jYirMqOZ5Q1/ycxdnE75y6bD9gF0tsWL0SELw8haluKAZXM1sapjT/rrQ8DtxhxQ dn7xjtynIpQ4GQb4O5eLnC0rqSec5vNPt1HKaGonr+aJx39XNcpmGeTM13qn5zTA 2mFNOB4jYbjEhlYEkYWLQuFhsUFOeqxj9h3ruYYib/eM1BMfUQqN4pmTWc0+ttNi hGtY0exJ2AAwDqWXxtt89zfSTAtx1hKJNJVSiU85Dj9NLDG9K/s4VKexntZh639c Wc+XZKvsai1Ul/h6vAt59p5UId/50+b0bQb8kdU3izr4awjfXi86ESqt3hONvrm1 FCCW7j42Y3XvctL9HSfmOMIfVcpbREvYOLhFN6USD76NZWPTRpT/cN4tVTnzUhix wlC4Z8CxRcTVaY2Wd+qG =Vzxn -----END PGP SIGNATURE-----

March 24, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

(Resending with attachments compressed since my previous message doesn't seem to have made it through. Apologies if anybody receives this twice.) I have an implementation of WGL_WINE_surface for the Mac driver and modified wined3d to use it. I still have to implement it for the X11 driver. I'm sending it along here to let folks see where it's going and review/critique my approach. I also need to update my description from my original proposal, since things didn't quite work how I planned. See below. The attached patches apply on top of the patches I just sent to wine-patches (patches 103407 through 103414). On Jan 28, 2014, at 6:47 PM, Ken Thomases wrote: > WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. … > > * The DC pixel format. … > * The current GL context for the thread. … > * The DC for the current GL context. … I realized that another piece of WGL state is the swap interval. That is set on the window of the current context, not on the context as such. So, when the context is targeting a surface, the swap interval will instead be set on that surface rather than the window. > Extension WGL_WINE_surface: > > HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); This no longer takes a pixel format argument. Wined3d doesn't have a pixel format chosen at the point where a surface should be created. Instead, one just calls SetPixelFormat() or wglSetPixelFormatWINE() on a surface DC as is currently done for window DCs. Similarly, GetPixelFormat() works on a surface DC. (It shouldn't end up that wglSetPixelFormatWINE() is ever actually called on a surface DC since we won't need to change it after it's first set, but it works.) Also, instead of using the generic HANDLE type, the extension defines the HSURFACEWINE type. > Destroying a surface while it still has extant surface DCs results in undefined behavior. This was untenable given the constraints that wined3d operates under. The surface is destroyed when the swapchain's window is changed, but there may still be contexts targeting the surface DC. Those may be current on another thread, so there's no way to clear them and release the DC synchronously. So, I've made the internal object underlying a surface handle reference counted. The handle itself holds one reference, which is released when the handle is destroyed. Each DC obtained by wglGetSurfaceDCWINE() holds an additional reference, which is released during wglReleaseSurfaceDCWINE(). -Ken

March 24, 2014

Re: Fixing conflicts between WineD3D and WGL

by Ken Thomases

I have an implementation of WGL_WINE_surface for the Mac driver and modified wined3d to use it. I still have to implement it for the X11 driver. I'm sending it along here to let folks see where it's going and review/critique my approach. I also need to update my description from my original proposal, since things didn't quite work how I planned. See below. The attached patches apply on top of the patches I just sent to wine-patches (patches 103407 through 103414). On Jan 28, 2014, at 6:47 PM, Ken Thomases wrote: > WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. … > > * The DC pixel format. … > * The current GL context for the thread. … > * The DC for the current GL context. … I realized that another piece of WGL state is the swap interval. That is set on the window of the current context, not on the context as such. So, when the context is targeting a surface, the swap interval will instead be set on that surface rather than the window. > Extension WGL_WINE_surface: > > HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); This no longer takes a pixel format argument. Wined3d doesn't have a pixel format chosen at the point where a surface should be created. Instead, one just calls SetPixelFormat() or wglSetPixelFormatWINE() on a surface DC as is currently done for window DCs. Similarly, GetPixelFormat() works on a surface DC. (It shouldn't end up that wglSetPixelFormatWINE() is ever actually called on a surface DC since we won't need to change it after it's first set, but it works.) Also, instead of using the generic HANDLE type, the extension defines the HSURFACEWINE type. > Destroying a surface while it still has extant surface DCs results in undefined behavior. This was untenable given the constraints that wined3d operates under. The surface is destroyed when the swapchain's window is changed, but there may still be contexts targeting the surface DC. Those may be current on another thread, so there's no way to clear them and release the DC synchronously. So, I've made the internal object underlying a surface handle reference counted. The handle itself holds one reference, which is released when the handle is destroyed. Each DC obtained by wglGetSurfaceDCWINE() holds an additional reference, which is released during wglReleaseSurfaceDCWINE(). -Ken

March 24, 2014

Re: dxdiagn: Added properties for hardware acceleration capabilities

by Dmitry Timoshkov

Markus Weiland <mw(a)graph-ix.net> wrote: > + BOOL hardware_accel; Shouldn't this be VARIANT_BOOL and take appropriate value? Also, patches should be sent to wine-patches. -- Dmitry.

March 24, 2014