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

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

by Christopher Thielen

I still haven't figured this bug out yet but Erich Hoover's help I've at least determined the missing cursor is not loaded from a resource in the .exe. I ported an Allegro-based fan tool somebody wrote in 2000 to Linux+SDL and have determined that the missing cursor is loaded from a resource file in the game's static/bitmap.flx file. Two questions: 1) Is there a way to add timestamps to the TRACE statements in Wine? 2) If I know which file is opened by the game, is there a way to debug from that point on, i.e. capture the fopen() and enable +cursor,+resource,+d3d TRACES for say, only 5 seconds after that point? Something along those lines? I can find the exact offset within the data file used to load the missing resource - but I'd need a way to know when a fread() was that far along. I figure if I can determine that I can determine if the cursor is loaded as a Windows cursor or as a D3D surface and go from there. Any ideas? - Christopher Thielen On 02/17/2014 12:27 PM, Christopher Thielen wrote: > I should clarify as per Stefan Dösinger's comments that I have only been > using the gog.com version (both under Wine and in my testing so far > under Windows XP) so the nGlide wrapper code paths should be the same. > The original, non-gog.com version is more or less garbage due to some > CD-ROM driver DRM-trickery. > > Erich Hoover suggested to look at WINEDEBUG=+cursor,+icon,+resource and > see if the game is merely using 'traditional' cursors. I do know this > game was in development for quite a while and originally started out as > a Glide game, so it makes some sense that the DirectX ShowCursor stuff > might not be used at all. I tried TRACE'ing d3d8_device,d3d9_device,and > dinput but found no calls related to cursors. > > The WINEDEBUG=+cursor,+icon,+resource trace does appear to be onto > something though. I attached the log to the bug but here are some snippets: > > trace:icon:ICO_LoadIcon 0x360000 0x360086 > trace:cursor:CreateIconFromResourceEx 0x37dc22 (1128 bytes), ver > 00030000, 32x32 icon > trace:cursor:ungrab_clipping_window no longer clipping > trace:icon:DrawIconEx > (hdc=0x2002d,pos=23.4,hicon=0x10044,extend=32.32,istep=0,br=(nil),flags=0x0000000b) > > trace:resource:LdrFindResource_U module 0x7e920000 type #0018 name #0002 > lang 0000 level 3 > trace:resource:find_entry_by_id root 0x7e93f3b4 dir 0x7e93f3b4 id 0018 > not found > trace:cursor:LoadCursorW (nil), #7f00 > trace:resource:LoadImageW ((nil),#7f00,2,0,0,0x00008040) > trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, > flags 0x8040 > > In particular, when the user presses 'Q', it should toggle the cursor > icon. Here is the log grepped for "cursor:LoadIconW": > > trace:cursor:LoadIconW (nil), #7f05 > trace:cursor:LoadIconW (nil), #7f05 > trace:cursor:LoadIconW 0x7edb0000, L"" > trace:cursor:LoadIconW (nil), L"" > trace:cursor:LoadIconW (nil), #7f05 > trace:cursor:LoadIconW 0x7edf0000, #0001 > trace:cursor:LoadIconW 0x7edb0000, #0001 > trace:cursor:LoadIconW (nil), #7f05 > trace:cursor:LoadIconW (nil), #7f00 > trace:cursor:LoadIconW (nil), #7f00 > > Am I wrong in reading this as the game toggling between two cursors? Is > there a way to dump the ICO resource from LoadIconW to the file system > to debug which icons it is trying and/or failing to load? > > Thanks again to everybody for all your help so far, > Christopher Thielen > > On 02/16/2014 11:55 AM, Stefan Dösinger wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-02-16 20:39, schrieb Christopher Thielen: >>> fixme:d3d:wined3d_debug_location Unrecognized location flag(s) >>> 0xfffffc00. >> These lines are harmless. That's pretty much code doing something like >> this >> >> TRACE("Removing flags %s.\n", >> wined3d_debug_location(~WINED3D_LOCATION_SYSMEM); >> >> which ends up passing a value like 0xfffffffe to wined3d_debug_location. >> >> wined3d_debug_location then does something like >> >> if (flags & (SYSMEM | BUFFER | ALL | DEFINED | FLAGS)) >> FIXME("Unrecognized location flag(s) %#x.\n", flags); >> >> What is missing here is a logical and that filters out unknown flags in >> places where a bitwise not is used, or maybe just the removal of the >> unknown flags fixme in wined3d_debug_location. >> >>> Unfortunately, there is no reference to "ddraw7_GetCaps" or >>> "GetCaps" anywhere in the 975 MB log. That confirms it isn't using >>> overlays, right? >> Pretty much, yeah. >> >>> fixme:d3d:debug_d3dusage Unrecognized usage flag(s) 0x10000000 >> That's WINED3DUSAGE_TEXTURE and needs to be added to the debug function. >> >>> This gog.com version uses nGlide to wrap the Glide API to DirectX >>> calls - DX9 I believe, based on the requirements of nGlide >>> (http://www.zeus-software.com/downloads/nglide) Not sure if this >>> information helps. >> This means the GOG version is using an entirely different codepath >> than what you're trying to run. It is quite possible that the codepath >> you're running is broken in some way. I recommend to test if the >> game's ddraw codepath is working properly on Windows before you bang >> your head against it. It can save you a lot of time :-) . >> >> If it turns out that the ddraw codepath is working just fine on >> Windows 7 there's certainly value in fixing it. If it is not, but it >> is working on e.g. Windows XP, it might still be worth a look. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJTARfAAAoJEN0/YqbEcdMwSC0P/1iZxKSLjIqEXeDmPsy7ARU9 >> vWm0Uqo0SYdCAEemGA2vD53IuojRUyMZ9E0ikfCZ7qlVK7uaFs54TtiY15C+p6ic >> gZhNezdyt/6idLootvCsJ9ZDoSaFdIDvoWga7JThwlZnfGVVZIGj6WeJeTV+rXon >> QHkQO/jghlHpgZIT6mdicvsltaWujg+Idwfuz1Z8i8+fKEhy7Uvp+QKCqsF8JdNf >> AuDceOPwF8aaH0YWVieyQfTiqzv4RHTnF5i+LGWPx61SRuRXi2YT+2hHlTbspua2 >> 6/FfQ+c2P6eoI39UiRysWL8+zB+T0o5V0JOF2PD5EJGqc+vP4066XkxZlA7Kdl6W >> h8RCzDbU+gxeq49cXHTG6AbvLUdkbDowo/dwW6x4wOmnlzZBW5CNxF0NbQ0Jf4sW >> mQLynduNdejnqgwZSFb5m8AoTqCZ+XbLkGq5uPAcAz6TIlsrKW7oQ41rTkeLxpU/ >> Z5nlLDmC5MIP8t8he2KuLu8eVrLhSsxYFEyeevhHY/SvNkmi1LxkXJMQHt8gDpdi >> 3ZW+LuW5nsOJ/9T7vH27ENorqRNtpFWnpdwPMyBgQJbPlNCYVp5ZTKE8WHpk+fk4 >> T+LzzbOlli8svOLHll4rmDhD89qYiQQUWNv7V7XjTHrgrxpZFY5aLXrprEGTc6Kc >> PCO4omr8MIkjrtJAHfKX >> =evKW >> -----END PGP SIGNATURE----- >> > >

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW (try 2)

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=4994 Your paranoid android. === wxppro (32 bit sock) === sock.c:613: Test failed: oob_server (b28): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB3F3A === wvistau64 (32 bit sock) === sock.c:613: Test failed: oob_server (190): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:603: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock.c:613: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit sock) === sock.c:613: Test failed: oob_server (63c): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:613: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:613: Test failed: oob_server (968): unexpectedly at the OOB mark: 0

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW

by Bruno Jesus

On Tue, Feb 18, 2014 at 1:06 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> wrote: > >> >> + else if(a->ai_canonname || b->ai_canonname) >> >> + ok(0, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); >> > >> > It would look more natural IMHO to use >> > ok(!a->ai_canonname && !b->ai_canonname, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); >> > instead of explicit ok(0) (here and in the not unicode variant). >> >> Indeed, much better. > > Please take into account my typos above (remove '!'s). If one of the strings are not present both must be null. So it's OK to have ok(!a->ai_canonname && !b->ai_canonname). Actually I changed the text to reflect that: if (a->ai_canonname && b->ai_canonname) { ok(!strcmp(a->ai_canonname, b->ai_canonname), "Wrong canonical name '%s' != '%s'\n", a->ai_canonname, b->ai_canonname); } else ok(!a->ai_canonname && !b->ai_canonname, "Expected both names absent (%p != %p)\n", a->ai_canonname, b->ai_canonname); I think that it's correct like this. > -- > Dmitry.

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW

by Dmitry Timoshkov

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > >> + else if(a->ai_canonname || b->ai_canonname) > >> + ok(0, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); > > > > It would look more natural IMHO to use > > ok(!a->ai_canonname && !b->ai_canonname, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); > > instead of explicit ok(0) (here and in the not unicode variant). > > Indeed, much better. Please take into account my typos above (remove '!'s). -- Dmitry.

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW

by Bruno Jesus

On Tue, Feb 18, 2014 at 12:11 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> wrote: > >> + if (a->ai_canonname && b->ai_canonname) >> + { >> + char bufa[128], bufb[128]; >> + WideCharToMultiByte(CP_ACP, 0, a->ai_canonname, -1, >> + bufa, sizeof(bufa), NULL, NULL); >> + WideCharToMultiByte(CP_ACP, 0, b->ai_canonname, -1, >> + bufb, sizeof(bufb), NULL, NULL); >> + ok(!strcmp(bufa, bufb), "Wrong canonical name '%s' != '%s'\n", bufa, bufb); >> + } > > I'd suggest to avoid using fixed size buffers and call lstrcmpW() for > comparison and wine_dbgstr_w() to print the values. For some stupid reason I was trying to use wine_debugstr_w instead of wine_dbgstr_w, so I looked for an alternative way... >> + else if(a->ai_canonname || b->ai_canonname) >> + ok(0, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); > > It would look more natural IMHO to use > ok(!a->ai_canonname && !b->ai_canonname, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); > instead of explicit ok(0) (here and in the not unicode variant). Indeed, much better. >> + if (a || b) >> + ok(0, "Expected both addresses null (%p != %p)\n", a, b); > > Same here. Yep. > -- > Dmitry. Thanks, Dmitry. Bruno

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW

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=4992 Your paranoid android. === wxppro (32 bit sock) === sock.c:617: Test failed: oob_server (b28): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:607: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 sock.c:617: Test failed: oob_server (654): unexpectedly at the OOB mark: 0 === wvistau64 (64 bit sock) === sock.c:617: Test failed: oob_server (b5c): unexpectedly at the OOB mark: 0 No test summary line found === w2008s64 (64 bit sock) === sock.c:617: Test failed: oob_server (744): unexpectedly at the OOB mark: 0

Feb. 18, 2014

Re: ws2_32: Fix conversion of address in GetAddrInfoW

by Dmitry Timoshkov

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > + if (a->ai_canonname && b->ai_canonname) > + { > + char bufa[128], bufb[128]; > + WideCharToMultiByte(CP_ACP, 0, a->ai_canonname, -1, > + bufa, sizeof(bufa), NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, b->ai_canonname, -1, > + bufb, sizeof(bufb), NULL, NULL); > + ok(!strcmp(bufa, bufb), "Wrong canonical name '%s' != '%s'\n", bufa, bufb); > + } I'd suggest to avoid using fixed size buffers and call lstrcmpW() for comparison and wine_dbgstr_w() to print the values. > + else if(a->ai_canonname || b->ai_canonname) > + ok(0, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); It would look more natural IMHO to use ok(!a->ai_canonname && !b->ai_canonname, "Expected both canonical names present (%p != %p)\n", a->ai_canonname, b->ai_canonname); instead of explicit ok(0) (here and in the not unicode variant). > + if (a || b) > + ok(0, "Expected both addresses null (%p != %p)\n", a, b); Same here. -- Dmitry.

Feb. 18, 2014

Re: [PATCH] kernel32: FindExInfoBasic added

by Zhenbo Li

2014-02-17 4:49 GMT+08:00 Marcus Meissner <marcus(a)jet.franken.de>: > > > > Lightroom calls it with FindExInfoBasic ... MSDN says its basically same as Standard, but without the short filename returned. > > As untangling the short filename handling is kind of large, lets just ignore > it. Hello, Marcus I have a question. As MSDN said[1] , "The FindFirstFileEx function does not query the short file name, improving overall enumeration speed." Then I can't get the *exact* difference between them. Could you please make a brief explanation? Or a few test-cases may be helpful? BTW, I found an old patch[2], which focus on the same issue. Maybe it would offer a reference? [1]: http://msdn.microsoft.com/en-us/library/aa364415%28v=vs.85%29.aspx [2]: http://www.winehq.org/pipermail/wine-patches/2013-May/124116.html -- Have a nice day! Zhenbo Li

Feb. 18, 2014

Re: [PATCH] kernel32: FindExInfoBasic added

by Zhenbo Li

2014-02-17 4:49 GMT+08:00 Marcus Meissner <marcus(a)jet.franken.de>: > > > > Lightroom calls it with FindExInfoBasic ... MSDN says its basically same as Standard, but without the short filename returned. > > As untangling the short filename handling is kind of large, lets just ignore > it. Hello, Marcus I have a question. As MSDN said[1] , "The FindFirstFileEx function does not query the short file name, improving overall enumeration speed." Then I can't get the *exact* difference between them. Could you please make a brief explanation? Or a few test-cases may be helpful? BTW, I found an old patch[2], which focus on the same issue. Maybe it would offer a reference? [1]: http://msdn.microsoft.com/en-us/library/aa364415%28v=vs.85%29.aspx [2]: http://www.winehq.org/pipermail/wine-patches/2013-May/124116.html -- Have a nice day! Zhenbo Li

Feb. 18, 2014

Re: [PATCH 4/4] ddraw/tests: Test that DirectDraw doesn't modify the pixel format of the window it targets. (try 2)

by Ken Thomases

On Feb 17, 2014, at 6:29 PM, Marvin wrote: > === w8 (32 bit ddraw2) === > ddraw2.c:5212: Test failed: Got unexpected refcount 3. > … > > === w8 (32 bit ddraw1) === > ddraw1.c:4115: Test failed: Got unexpected refcount 3. > … > > === w8 (32 bit ddraw7) === > ddraw7.c:4049: Test failed: Got unexpected hr 0x88760104 for format D3DFMT_YUY2, resource type videomemory overlay, size 1x1, expected 0. > … > > === w8 (32 bit ddraw4) === > ddraw4.c:4244: Test failed: Got unexpected hr 0x88760104 for format D3DFMT_YUY2, resource type videomemory overlay, size 1x1, expected 0. > … Not related to my patch. -Ken

Feb. 18, 2014