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

Re: dplayx: Fix some crashes and wine_todo's ( try 2)
by Nikolay Sivov Oct. 29, 2014

Oct. 29, 2014

On 10/29/2014 08:13 AM, Alistair Leslie-Hughes wrote: > +#if 0 > + /* Crashes under Win7 */ > hr = IDirectPlayX_GetSessionDesc( pDP[0], lpData[0], NULL ); > checkHR( DPERR_INVALIDPARAM, hr ); > dwDataSize=-1; > hr = IDirectPlayX_GetSessionDesc( pDP[0], lpData[0], &dwDataSize ); > checkHR( DPERR_INVALIDPARAMS, hr ); > check( -1, dwDataSize ); > +#endif That's the same. Wine test use if (0) {} block to disable code. Also you don't need checkHR() at all in such cases.

2 1

Re: dplayx: Fix some crashes and wine_todo's ( try 2)
by Sebastian Lackner Oct. 29, 2014

Oct. 29, 2014

On 29.10.2014 06:13, Alistair Leslie-Hughes wrote: > Hi, > use #if 0 > Using "#if"s is no good idea, since this doesn't ensure that the code still compiles in the future. Better use "if (0)" instead.

1 0

Re: dplayx: Fix some crashes and wine_todo's
by Nikolay Sivov Oct. 28, 2014

Oct. 28, 2014

> - hr = IDirectPlayX_GetSessionDesc( pDP[0], lpData[0], NULL ); > +/* hr = IDirectPlayX_GetSessionDesc( pDP[0], lpData[0], NULL ); > checkHR( DPERR_INVALIDPARAM, hr ); > dwDataSize=-1; > hr = IDirectPlayX_GetSessionDesc( pDP[0], lpData[0], &dwDataSize ); > checkHR( DPERR_INVALIDPARAMS, hr ); > - check( -1, dwDataSize ); > + check( -1, dwDataSize );*/ You can't just comment out parts, if those crash on Windows put them in compilable block inside if (0) and add appropriate comment.

1 0

Re: gdiplus: Fix error when drawing from a rectangle outside bitmap bounds.
by Vincent Povirk Oct. 28, 2014

Oct. 28, 2014

Don't commit this. Right and bottom are included and I incorrectly treated them as excluded. I will send a fixed version.

1 0

Re: [2/2] wined3d: wined3d: Take abs() of vertex z coordinate as FFP fog coordinate
by Stefan Dösinger Oct. 28, 2014

Oct. 28, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-28 00:44, schrieb Joachim Priesner: > + {0, D3DFOG_NONE, D3DFOG_LINEAR, C_UNFOGGED, C_HALF_FOGGED, C_HALF_FOGGED, C_FOGGED}, > + {0, D3DFOG_LINEAR, D3DFOG_LINEAR, C_UNFOGGED, C_HALF_FOGGED, C_HALF_FOGGED, C_FOGGED}, > ... > + /* We are using an affine projection matrix, so pixel fog assumes fog start and end > + * to be in device space coordinates. Pixel fog will therefore be calculated from > + * z=-1 to z=1, whereas vertex fog will be calculated from z=0 to z=1. */ > + start.f = 0.0f; > + end.f = 1.0f; I think this comment is wrong. In d3d normalized Z coordiantes go from 0.0 to 1.0. In GL (sans GL_ARB_clip_control) they go from -1.0 to 1.0. The fog results above agree with this - otherwise you'd get C_UNFOGGED for table fog in the middle of the quad with the given projection matrix and fogstart and end. Strictly speaking you don't have to set start = 0, end = 1, those are the default values. A comment stating that is enough. > + {0, D3DFOG_NONE, D3DFOG_LINEAR, C_UNFOGGED, C_HALF_FOGGED, C_HALF_FOGGED, C_FOGGED}, > + {0, D3DFOG_LINEAR, D3DFOG_LINEAR, C_UNFOGGED, C_HALF_FOGGED, C_HALF_FOGGED, C_FOGGED}, > + {0, D3DFOG_LINEAR, D3DFOG_NONE, C_FOGGED, C_UNFOGGED, C_FOGGED, C_FOGGED}, > + {0, D3DFOG_NONE, D3DFOG_NONE, C_FOGGED, C_FOGGED, C_FOGGED, C_FOGGED}, There's a space missing in line 3. Otherwise this patch looks good to me. It also passes on my Radeon X1600 GPU. I didn't retest the HD 5770, I assume it passes there as well. I also tested it on Vista with my GeForce 7400, it works as expected. The Radeon 9000 GPU crashes on the vs1 ("non-foggy") + table fog tests. The other non-foggy shader tests run, but don't pass. I have attached the output in case you're interested, but otherwise don't bother about this. If I have time some day I'll try to find out where the driver's limitations are. I guess it's generally broken when fog is on and the shader does not write a fog coordinate. This is not the only fog-related problem on this card on Windows. Thanks again for your hard work. I hope I didn't miss anything this time :-) Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUT4SlAAoJEN0/YqbEcdMwYKoP/0UgSvtbxdM2sTto3Fmtl5dB fHvudTRqxQJs/7ymaxcoknGOwgY8iyu4UB0lQ1vWgIG0kJAI3QK351AujXTEG2bm Rbke87C//kTyb8DRMRYvpA05BnF1eMMtzZXD/+d1CDp8xqnUEwpdsCUz+5ZMymrk z07+zmGyq6t7XKVT4yvVA58dkIB5FuJQ/XS7mkiJ+267A+ZN+odnFGrMP/rT/jnE x/ySDcOatBsZ94LpsYqSLQH33COki+ngD2H0qAQG33Y1UAQnRb7l5g/fFwrs8vqS o5P8Hq5zEKjyjfP9Gr/BdVUjLgNurTLrpgs7T06XwMGeVJvQV2HyEIffXjrKUsqg T2H4fJaa9DHyehm+zB7YRdk+QKr0ibODA8/AG+m85nmcUFK7TZY0n+OMEHdwR8xk g6pr01zw4mJg7bJZE+uVdLwNuWA/BhTsxCrjphI9GAUf7VVr/VdaZC30m2p7lTsn rtH7vjh/UEBZg8vGwVgkpHNwaop8Cr1sfXH+uy4K6F1O/j+oLH0qpP15PCRkPqq4 HF39Lnj0/JYuI6Ak7M70K8Qw6ExP6KDs9KL9rn2znsomtPYRfkRyLe2uUCjeBHNz OfCWB8zQUrYfV9VCmK77rNgqui7+/Nyb7+MODwbnkkgBIOF/dao7WNYz501Cubee Ab85oRdj1ReT91QW2Awt =k/GT -----END PGP SIGNATURE-----

2 2

Re: [PATCH] d3d8/tests: The device restores the mode settings from the registry (v3).
by Marvin Oct. 28, 2014

Oct. 28, 2014

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://testbot.winehq.org/JobDetails.pl?Key=9818 Your paranoid android. === w8 (32 bit device) === device.c:2437: Test failed: Expected foreground window 000701B2, got 0002004C. device.c:3219: Test failed: Expected wndproc 0x412ba0, got 0x412ba0.

1 0

Re: gdiplus: Blend in the background colour.
by Vincent Povirk Oct. 28, 2014

Oct. 28, 2014

> + return ((b + ((BYTE)bkgnd * (255 - alpha) + 127) / 255) | What's the purpose of adding 127 here? > stat = GdipBitmapLockBits(bitmap, NULL, ImageLockModeRead|ImageLockModeUserInputBuf, > PixelFormat32bppPARGB, &lockeddata); > > + if (background & 0xffffff) > + { > + DWORD *ptr; > + UINT i; > + for (ptr = (DWORD*)bits, i = 0; i < width * height; ptr++, i++) > + { > + if ((*ptr & 0xff000000) == 0xff000000) continue; > + *ptr = blend_argb_no_bkgnd_alpha(*ptr, background); > + } > + } I guess it wouldn't hurt anything, but it doesn't make much sense to do this if LockBits fails.

2 1

Re: comctl32: Enable the appropriate wizard buttons before sending DM_SETDEFID.
by Marvin Oct. 28, 2014

Oct. 28, 2014

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://testbot.winehq.org/JobDetails.pl?Key=9817 Your paranoid android. === w2000pro (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! propsheet.c:785: Test failed: property sheet with custom window proc: the msg 0x001c was expected, but got msg 0x0047 instead === wxppro (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! === wvistau64 (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! === w2008s64 (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! === w7u (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! propsheet.c:785: Test failed: property sheet with custom window proc: the msg 0x001c was expected, but got msg 0x0047 instead === w8 (32 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! === wvistau64 (64 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed! === w2008s64 (64 bit propsheet) === propsheet.c:584: Test failed: The Add button has not been pressed!

1 0

Re: ws2_32: WS_get_local_ips: Fix sorting IP addresses by metric if two addresses have the same metric
by Ken Thomases Oct. 27, 2014

Oct. 27, 2014

Hi, On Oct 24, 2014, at 3:27 PM, Joachim Priesner <joachim.priesner(a)web.de> wrote: > The previous implementation required the metrics to be mutually inequal > (because of the "this_metric > last_metric" check). If the metrics were > not mutually inequal, it would write only one address per metric value to the list > and fill up the rest of the list with the magic loopback IP address 127.12.34.56. > > I take it that this is not the expected behavior, please correct me if I'm wrong! I was recently looking at this code and noticed the same problem. Thanks for working on this. I don't understand why the original code ever would have wanted to return the magic loopback address, other than to cover up the brokenness of the sort. So, why do you still have that logic in there? Each pass of the outer (i) loop can "consume" at most one entry in the list. So, the inner (j) loop should always find a remaining lowest-metric entry. lowest_metric_idx should never be -1 at the end of that loop and the magic address should never be used. More simply, this is just an attempt to sort the routes. None should be added and none should be removed (i.e. replaced with magic). Since it's a sort, I recommend that this loop simply be replaced with an invocation of qsort() with an appropriate comparison function. That's what's done in iphlpapi for similar situations. (This can be conditioned on numroutes >= 2 to avoid the overhead when it's not necessary.) After the routes are sorted, the addresses can be copied over to the h_addr_list with a much simpler loop. -Ken

1 0

Re: [PATCH 2/6] reg: Add path/key conversion functions
by Stefan Dösinger Oct. 27, 2014

Oct. 27, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-27 13:10, schrieb Jonathan Vollebregt: > +#define ARRAY_COUNT(A) (sizeof(A)/sizeof(*A)) Other places that use a macro like this call it ARRAY_SIZE. > +typedef struct { > + HKEY key; > + const WCHAR *short_name; > + const WCHAR *long_name; > +} hkey_rel; Style :-) > +static inline int path_rootname_cmp(const WCHAR *path, const WCHAR *name) > +{ > + DWORD length = strlenW(name); > + > + return (strncmpiW(path, name, length) == 0 && (path[length] == 0 || path[length] == '\\')); > +} I don't like the names "path" and "name". I wondered why you're relying on the length of name. A better name for "path" could be "input", but I can't think of anything for "name". > +static HKEY path_get_rootkey(const WCHAR *path) > +{ > + DWORD i; > + for (i = 0; i < ARRAY_COUNT(root_rels); i++) > + { > + if (path_rootname_cmp(path, root_rels[i].short_name) || > + path_rootname_cmp(path, root_rels[i].long_name)) > + return root_rels[i].key; > + } > + > + reg_message(STRING_INVALID_KEY); > + return NULL; > +} Is it a good idea to write an error message from deep inside a helper function? What happens when you just pass the NULL root to RegOpenKey? Can you tell the cases for STRING_INVALID_KEY and STRING_CANNOT_FIND apart base on the return value? You could also consider a function that returns an error string ID for each advapi32 Reg* error result. Then you can propagate the advapi32 return codes to main() and write the error string there. Depending on the possible failure modes this may or may not be possible. > + path = strchrW(path, '\\'); > + if (!path) > + return k; I see that this is why you need the trailing backslash elimination in the previous patch. But still, do you need this? What happens when you call e.g. RegOpenKey(HKEY_CURRENT_USER, "\\", &k)? If it returns HKEY_CURRENT_USER or a handle that points to HKEY_CURRENT_USER you're fine. Similarly for RegOpenKey(HKEY_CURRENT_USER, "", &k). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUTtS5AAoJEN0/YqbEcdMw+kEP/0DwI2fMgk2o6bKh1mCVwzeg AFH+EKh1pAwpHBmIRHX7XzyDBAusd0GVH0+B5WQFnl+Fr49ybYqp8CGfytqm0H/e lgqS0SCDZjaDTI5WO5zT/L5/VGhQ5tQHSQJiHS3UhXX3IBDXd7aYcbreSMHNcyJ8 ZPaFmVVCH8iRiR4qqMS8cJKXPxzx5tg5Ec9TpXfyYraI8YDPTNPOGlUipl9m5kwa lrqjD+TbGbCOczq1mx6WSJnVxKWboWhz3FnzYDM0C8PzpJlRyzODWlfUHVMSLSmQ xu9K/lXl2XJpmXbjFsCPZ5C4K3pRVH3poAtPNs+yOEeHkWTE2Pf3uyKNBwpW4ONU 3PFhn0beJM1scJY/LRjpCWLi74xA+FdBq6WDuxx2BpMoDvKCe/zV+LEY6zbymtxY OsXQXXQwpcVBAC3mWQK0EWce8g2/he4PoPi8/l4ZakkCEAF4dqtdfSEQAccf9KfV EeI8PJOAZRLoKAUQgKse2mYHG8V4EJEp8IQA0HcuWgR9zEMTpIUt08xdmU5cIWfu Ena2T9phlAWmDIjcgr9haIHEreZkMI8DZI07XOmVAlZL44rSdkVop816I/ItTE98 CTwU6N0pD/V4htZcwWN7ZVojPK4AA7UD9NW7sg326drl2KIpk5j0ZmYq0/WwSL2o uS2pHS9eKgBarX7GCXyd =k2ys -----END PGP SIGNATURE-----

1 0