June 2015 - Wine-devel - list.winehq.org

Re: [PATCH] mshtml: add NULL check to get_frame_by_name
by Jacek Caban 01 Jun '15

01 Jun '15

On 05/29/15 15:51, Indrek Altpere wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34982 > --- > dlls/mshtml/htmlwindow.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index 618648e..c53ea16 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -406,6 +406,11 @@ HRESULT get_frame_by_name(HTMLOuterWindow *This, const WCHAR *name, BOOL deep, H > > nsIDOMWindow_Release(nswindow); > > + if(!window_iter) { > + WARN("nsIDOMWindow without HTMLOuterWindow: %p\n", nswindow); > + continue; > + } > + The real question is why there is no HTMLOuterWindow created for given window, but I'm fine with the patch. Thanks, Jacek

1 0

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.
by Nikolay Sivov 01 Jun '15

01 Jun '15

On 01.06.2015 12:52, Qian Hong wrote: > +/* Query object type name information */ > +(a)REQ(get_object_typename) > + obj_handle_t handle; /* handle to the object */ > +(a)REPLY > + data_size_t total; /* needed size for type name */ > + VARARG(typename,unicode_str); /* type name */ > +(a)END > + Also, do we really need to transfer a string? It seems to be that you can use an index and a static array at ntdll side.

1 0

Re: [PATCH] Do not run update-desktop-database on make install/uninstall
by Damjan Jovanovic 01 Jun '15

01 Jun '15

Not all of us install Wine through a package manager, and update-desktop-database is useful in that case. What that Makefile should probably be doing instead, is calling update-desktop-database only on the desktop directory where wine.desktop was just installed, where it will succeed without root privileges, ie.: -$(UPDATE_DESKTOP_DATABASE) $(DESTDIR)$(datadir)/applications Thank you Damjan On Sun, May 31, 2015 at 8:12 AM, Jerome Leclanche <jerome(a)leclan.ch> wrote: > This causes root invocations of "make install" in a chroot to error > It is the maintainer's or the package manager's job to run it, instead. > > Fixes bug #35191 > > J. Leclanche > > >

2 1

Re: [PATCH] wined3d: fix color in range comparison
by Nikolay Sivov 31 May '15

31 May '15

On 27.05.2015 20:12, Sergey Isakov wrote: > I think the patch must be accepted because original codes are more wrong. > > Tests will be created when WINED3D_CKEY_COLORSPACE will be implemented. Tests are needed to prove that your patch is correct. > > The game affected is in bug 38581. > > Meanwhile, the policy to reject any patches is not constructive. > If one developer propose not perfect codes then next developer can > correct them and obtain a result. > If you rejected the first developer then you will not have a result. That's not how it works. > > Best wishes! > > > On 27 мая 2015 г., at 10:39, Stefan Dösinger <stefandoesinger(a)gmail.com > <mailto:stefandoesinger(a)gmail.com>> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2015-05-26 um 14:41 schrieb Sergey Isakov: >>> +#define RED_KEY(x) (x & 0xff0000) >>> +#define GREEN_KEY(x) (x & 0x00ff00) >>> +#define BLUE_KEY(x) (x & 0x0000ff) >>> + return ((RED_KEY(color) >= >>> RED_KEY(color_key->color_space_low_value)) && >>> + (RED_KEY(color) <= >>> RED_KEY(color_key->color_space_high_value)) && >>> + (GREEN_KEY(color) >= >>> GREEN_KEY(color_key->color_space_low_value)) && >>> + (GREEN_KEY(color) <= >>> GREEN_KEY(color_key->color_space_high_value)) && >>> + (BLUE_KEY(color) >= >>> BLUE_KEY(color_key->color_space_low_value)) && >>> + (BLUE_KEY(color) <= >>> BLUE_KEY(color_key->color_space_high_value))); >>> +#undef RED_KEY >>> +#undef GREEN_KEY >>> +#undef BLUE_KEY >> The basic idea is most likely right, but it needs tests. Do you have a >> game that needs this behavior? >> >> The way you're extracting individual colors from the key is wrong. The >> bitmasks depend on the texture format. >> >> The code you're modifying is unused on any modern GPU. On GPUs that >> support ARB_fragment_program or GLSL we do the color key comparison in >> the fragment shader nowadays. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBAgAGBQJVZXSWAAoJEN0/YqbEcdMwbEUP/RM4QUsbdSzhSLyIz5j00Epb >> AW1ZcNOg61yrfymjHdhJkqfdNmEiKQFsRshD+ZQAxVHqMsZLTxXtRFfBB14WtmNI >> Ng5jwwiAzDqlmpjftlZ4CmkR1w7DMxH6Nt4e9OQBlDKShSIoGngL6RremV+2Wq+f >> nNC6HfdmUiAIReVvI2aMm5B9C5L624SKLvoAZNI8QW+HJeZeESSGmT9bx4IRVQwl >> QX+aKojT43CJwq6UpZRu7ZkniotrmO9aDC+6S3S0od0ZJWSP5Q9upCNWNcN+iPG7 >> 9kCPwZMsEAxNUjvh/wQx8xE1+wiR7Ugjl/X6yTN8HFesFHChrqC2UeHUAkUKU++L >> WC4kwijfbktKSZnIiSvrTAzWvLOeCZMifFQqm8aqmlOqyvbNwyOJjh6yM/nqZi+c >> 2aEdEIMY5aaoswDIlyGRRN57zeWtqjZVmg7UzVxmZqfiocmUVxgdmdRv8BvFi0RF >> R4A6YTDP5EYb33SvH3qQE5kIrtDdtL8qtanmBsuHnhhwd1rdgeeq/9N0tqSjH1GQ >> s8vsXVmd3qU+mQMzyaxN9Cc9RGxGNgd+g1LkkoPqe+aVUw/JDzvAdMDGpy63zjhM >> QUlfS771f+Zt43wku/20XP1engXXti4m+KfnSOS3nCdKO1xRKOGHAMlUZzd8+jhU >> 2rWKuh42D3mSMDk1OhLR >> =IdO/ >> -----END PGP SIGNATURE----- > > > >

1 0

Re: [PATCH 2/2] d3d9/test: implemented tests for UpdateTexture method
by Marvin 31 May '15

31 May '15

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=13726 Your paranoid android. === w8 (32 bit visual) === visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 0, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 1, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 2, 8.

1 0