- wine-devel - winehq.org

Re: mshtml: Added IHTMLImgElement::isMap property implementation. (try 2)
by Jacek Caban 14 Aug '14

14 Aug '14

Hi Zhenbo, On 08/11/14 08:46, Zhenbo Li wrote: > --- a/dlls/mshtml/htmlimg.c > +++ b/dlls/mshtml/htmlimg.c > @@ -102,15 +102,37 @@ static HRESULT WINAPI HTMLImgElement_Invoke(IHTMLImgElement *iface, DISPID dispI > static HRESULT WINAPI HTMLImgElement_put_isMap(IHTMLImgElement *iface, VARIANT_BOOL v) > { > HTMLImgElement *This = impl_from_IHTMLImgElement(iface); > - FIXME("(%p)->(%x)\n", This, v); > - return E_NOTIMPL; > + nsresult nsres; > + > + TRACE("(%p)->(%x)\n", This, v); > + > + nsres = nsIDOMHTMLImageElement_SetIsMap(This->nsimg, v ? TRUE : FALSE); Please avoid v?TRUE:FALSE style expressions. Cheers, Jacek

1 0

Re: [3/5] wined3d: replace vendor specific callbacks with generic code that uses vendor specific arrays (resend)
by Henri Verbeet 13 Aug '14

13 Aug '14

On 12 August 2014 02:17, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > @@ -2172,45 +2173,43 @@ intel_gl_vendor_table[] = > {GL_VENDOR_MESA, "Mesa Intel driver", cards_intel, > ARRAY_SIZE(cards_intel)}, Your mailer wrapped the patch, so it won't apply. I recommend using git send-email for sending patches. > +C_ASSERT(NUMELMS(card_fallback_nvidia) == WINED3D_D3D_LEVEL_COUNT); > +C_ASSERT(NUMELMS(card_fallback_amd) == WINED3D_D3D_LEVEL_COUNT); > +C_ASSERT(NUMELMS(card_fallback_intel) == WINED3D_D3D_LEVEL_COUNT); ... > + enum wined3d_pci_device *card_fallback; /* An array with D3D_LEVEL_COUNT > elements */ I also strongly suspect that even if the patch did apply, it would either generate warnings or just fail to compile.

1 0

Re: [4/4] ntdll/tests: Add tests for FILE_PIPE_INFORMATION.
by Marvin 12 Aug '14

12 Aug '14

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=8473 Your paranoid android. === w8 (32 bit pipe) === pipe.c:540: Test failed: can't open pipe, GetLastError: e7 pipe.c:616: Test failed: can't open pipe, GetLastError: e7

1 0

Re: (resend)[2/5]dwrite: Initial implementation of CreateCustomFontFileReference
by Marvin 12 Aug '14

12 Aug '14

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=8468 Your paranoid android. === build (build) === Patch failed to apply

1 0

RE. [1/5]dwrite: Implement Font File Loader registration
by Aric Stewart 12 Aug '14

12 Aug '14

Sorry, I missed this e-mail... I got a bit sloppy with some of my tests. I will clean those up. >> +static HRESULT WINAPI fontfileloader_CreateStreamFromKey(IDWriteFontFileLoader *iface, const void *fontFileReferenceKey, UINT32 fontFileReferenceKeySize, IDWriteFontFileStream **fontFileStream) >> +{ >> + return 0x8faecafe; > > I'm sure this works, but it's cleaner to return E_FAIL/E_NOTIMPL imho. The point of that part of the test is to show that the error code returned from CreateStreamFromKey is passed down to CreateFontFace. -aric

1 0

Re: dmscript/tests: Initialize test variable (valgrind)
by Bruno Jesus 12 Aug '14

12 Aug '14

On Sat, Aug 9, 2014 at 8:40 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=36809 I see the patch is in pending state but I don't know what is expected. Can anyone help me? http://source.winehq.org/patches/data/105943 Best regards, Bruno

2 1

Re: wined3d: add support for AMD Radeon HD7750
by Henri Verbeet 11 Aug '14

11 Aug '14

On 11 August 2014 02:23, Austin English <austinenglish(a)gmail.com> wrote: > + {HW_VENDOR_AMD, CARD_AMD_RADEON_HD7750, "AMD Radeon HD 7750 Series", DRIVER_AMD_R600, 1024}, This is suspicious, all recent discrete Radeon's have had descriptions of the form "AMD Radeon HD 7700 Series". Is this based on what the Windows driver actually returns? > + {"HD 7750", CARD_AMD_RADEON_HD7750}, Similarly, I'd expect fglrx to call this card "AMD Radeon HD 7700 Series". Is this based on actual fglrx glxinfo output? > + {"CAPE VERDE PRO", CARD_AMD_RADEON_HD7750}, This is just wrong. The radeonsi driver doesn't return "CAPE VERDE PRO" for any card.

1 0

Re: mshtml: Added IHTMLStyle::lineStylePosition property implementation.
by Marvin 10 Aug '14

10 Aug '14

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=8406 Your paranoid android. === w2000pro (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === wxppro (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === wvistau64 (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === w2008s64 (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === w7u (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === w8 (32 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === wvistau64 (64 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null) === w2008s64 (64 bit style) === style.c:2127: Test failed: Expects E_INVALIDARG, got 00000000 style.c:2132: Test failed: listStyleType = (null)

1 0

Re: mshtml: Added IHTMLStyle::lineStylePosition property implementation.
by Zhenbo Li 10 Aug '14

10 Aug '14

Sorry, this is a bad patch. Please just ignore it, thanks. 2014-08-10 20:11 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > --- > dlls/mshtml/htmlstyle.c | 15 +++++++++++---- > dlls/mshtml/htmlstyle.h | 1 + > dlls/mshtml/tests/style.c | 14 +++++++++++--- > 3 files changed, 23 insertions(+), 7 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: [PATCH 2/2] vbscript: Implemented Time
by Marvin 10 Aug '14

10 Aug '14

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=8405 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/2] vbscript: Implemented Date
by Marvin 10 Aug '14

10 Aug '14

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=8404 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/2] ddraw: Return empty D3D hardware flags for RGB device enumeration (try 2).
by Stefan Dösinger 09 Aug '14

09 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-08 17:45, schrieb Erich E. Hoover: > Per Henri's request this now also tests the Ramp and MMX devices. > I also tried to test for Ref devices, but the testbot and the > machine available to me didn't have a Ref device. To get the REF device for d3d7 and earlier you have to install the DirectX 7 sdk. This installs a system control applet that allows you to enable REF device enumeration. I don't think it's worth bothering. I don't even know if the REF device still works on a modern Windows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT5mncAAoJEN0/YqbEcdMwaEQP/A0/Y5o15v0WOOUk+k+ocDRh Vuf1FH6aKxPbKOF0HgEJsjKQyO+QUl3J1KZsqQeXtWaFTDa2Npki3LfoiAxBr4Gc l9EoRF7prVW/L+gAlqUvpQzpSEO0pjDvl1IFrMH/HNL4IMDeo7e8H+JRXUO5mVfJ bGO8WXJucNPwkzcQzMzgt8ycVP30uBCTS7vkCwG3J++HmTiChby0W7XPI5Q6n2T1 Gi00Z1RhLDb6HcTCPzwdIi/v7BpEOOMv0/U+CaoSZGQhxHWDTxtLVXehHwzHhX3p 86lUe906qjPmdTWsTpuiRcCWzRfbi/GQyXx04rDxKdb6/LfT5kDMhViLYeoGo0VZ YIQVe1eFHJ/LhpGZCMrZ/sv3DMIUfINZuzo/eYOLsA+ehdz7CPjLul2gqwL+8EKT kSwX2ptw8KlaOnLrcRxShU9OrUvbUeM4Ui6k+kAeZJyBRLbZbKCgq0EiNgtVN+IZ ul+Us3sR6jCo7qdrF2k1Ia39LxGLlOcP2TeyloJ14zKv8/zCkqlPwu3xGWGyl2EX qtnrDbhztL8Y12IDkCIkNULdqQ0Oxj/rOmVACDKgptLOlpfiq8fC98o7QgDdmYcc vLxu0q+7At5qQHLGPtaqNEa/GqkJ/OEM2abXGMMLVnPHx6tOwk+BnapZTbKKxKql WaQCwW4eBNX9BWqhAxTw =od4v -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] ddraw/tests: Remove broken tests of D3DTRANSFORM_UNCLIPPED.
by Stefan Dösinger 09 Aug '14

09 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-08 17:45, schrieb Erich E. Hoover: > - for(i = 0; i < sizeof(outH); i++) { > - if(((unsigned char *) outH)[i] != 0xcc) { > - ok(FALSE, "Homogeneous output was generated despite UNCLIPPED flag\n"); > - break; > - } > - } There is some more code you can remove. At least the outH memset is not needed. I'd say you can also remove the second call to TransFormVertices. The difference between the first and second call is pretty minor now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT5me/AAoJEN0/YqbEcdMwzn0P/RXdxutD01EhhYD2J0sUnjPZ uiAI+xj64mjMLF8WYByNSZc5e6HSRVR6cOvX8ZBQM2WSHgpcdiL0/GfnsRS21nTq pQDf9qqNMoUczVrJkt/RjvkINKESINuOWOmTK1eweS1RXB+Yto0PjdMXFJ8gnZc0 vq1Hqobv+zkwaGJ0jw8T3WFNJ2U7hY9eKmM61MetliqtA8rgkhilkZIcneXovW93 gxFQFIh90FgZzwudgUAIYk6s1aAf0EzaI1IPUGb9jr7GOrnH8Z2jOtK0ird+dLtb mbaTxjhUTzD37EYfOO+bvUOjxRDrboxSq4p/sRuXg0ZHCYP/tuSSP4HHzajOaHkc 1Z148lL7aG4PCRswLyQufJgqbVAr99axoSIivAOkObDXNVoaypCt63He6ctjq8e3 fwnmPhRfofZTL2a2arvP1Prvf3vcvvhF1zgLudNE5dlZr5VqiNJ64yf6zJfmN3Gf ad8qXyaq15f/BjfRamqlhyk5hXomfnTv3dQcUDa37FwYz01XR+24E031R207vqqc kiNxppo1s5+ri66VoEormjWBxhHwHfO2cYsjT3plsY9kVIy8B1cWDXBQLkZKaPhU kZlHD3gG01i8QrZ0c1YbZAwWdTLZUCqykH3RJGhUKKz68ELxOHZfT49BuByVRz8a gMPX2hwrcAQPQGMx/K6u =SA6e -----END PGP SIGNATURE-----

1 0

Re: [PATCH 7/7] vbscript: Implemented Atn
by Marvin 09 Aug '14

09 Aug '14

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=8386 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] vbscript: Implemented Sqr
by Marvin 09 Aug '14

09 Aug '14

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=8385 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/7] vbscript: Implemented Log
by Marvin 09 Aug '14

09 Aug '14

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=8384 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/7] vbscript: Implemented Exp
by Marvin 09 Aug '14

09 Aug '14

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=8383 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/7] vbscript: Implemented Tan
by Marvin 09 Aug '14

09 Aug '14

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=8382 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/7] vbscript: Implemented Sin
by Marvin 09 Aug '14

09 Aug '14

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=8381 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] vbscript: Implemented Cos
by Marvin 09 Aug '14

09 Aug '14

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=8380 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/4] vbscript: Implemented ScriptEngineMinorVersion(try 2)
by Marvin 08 Aug '14

08 Aug '14

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=8363 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 3/4] vbscript: Implemented ScriptEngineMajorVersion(try 2)
by Marvin 08 Aug '14

08 Aug '14

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=8362 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/4] vbscript: Inplemented ScriptEngineBuildVersion(try 2)
by Marvin 08 Aug '14

08 Aug '14

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=8361 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/4] vbscript: Implemented ScriptEngine(try 2)
by Marvin 08 Aug '14

08 Aug '14

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=8360 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [1/5]dwrite: Implement Font File Loader registration
by Nikolay Sivov 08 Aug '14

08 Aug '14

> +static HRESULT WINAPI fontfileloader_QueryInterface(IDWriteFontFileLoader *iface, REFIID riid, void **obj) > +{ > + *obj = iface; > + return S_OK; > +} This should follow normal QI behavior, with test failure on unexpected riids. > +static HRESULT WINAPI fontfileloader_CreateStreamFromKey(IDWriteFontFileLoader *iface, const void *fontFileReferenceKey, UINT32 fontFileReferenceKeySize, IDWriteFontFileStream **fontFileStream) > +{ > + return 0x8faecafe; I'm sure this works, but it's cleaner to return E_FAIL/E_NOTIMPL imho. > + hr = IDWriteFactory_RegisterFontFileLoader(factory, &floader); > + ok(hr == S_OK, "got 0x%08x\n", hr); Probably it makes sense to test NULL argument as well, but that's certainly optional (and dwrite tends to crash in such cases).

1 0

Re: mshtml/tests: Better output when an exception is caught.
by Marvin 07 Aug '14

07 Aug '14

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=8326 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 4/4] vbscript: Implemented ScriptEngineMinorVersion(try 2)
by Jacek Caban 06 Aug '14

06 Aug '14

Hi Shuai, On 28/07/14 04:49, Shuai Meng wrote: > static HRESULT Global_ScriptEngineMinorVersion(vbdisp_t *This, VARIANT *arg, unsigned args_cnt, VARIANT *res) > { > - FIXME("\n"); > - return E_NOTIMPL; > + int minorversion = 8; Please use something like VBSCRIPT_MINOR_VERSION in a header file instead of hardcoding it here. This will allow sharing the value with resources strings in the future. Jacek

1 0

Bad coding style of kernel32/pipe tests
by Sebastian Lackner 05 Aug '14

05 Aug '14

Hi, I would like to submit some new tests for kernel32/pipe, but I don't really know how to deal with the existing ones. To show what I mean a few examples should be sufficient: --- snip --- [...] if (readden != sizeof(obuf)) /* Linux only returns the first message */ ok(readden == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes\n", readden); else todo_wine ok(readden == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes\n", readden); [...] if (avail != sizeof(obuf)) /* older Linux kernels only return the first write here */ ok(avail == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes available\n", avail); [...] --- /snip --- There are several such tests, which basically always succeed. I can understand that all these if(...)s were added to avoid test failures ... but I don't think its really useful - especially not when the ifs depend on the actual test result, and not the platform which causes the issues. :/ Before I start submitting additional tests I would like to know how to deal with all these problems. Should my new tests also contain if(...) blocks around every test, which could fail on old/new kernels, on MacOS, on FreeBSD, ...? Hopefully you'll all agree that we have to find a better solution for that ... some possible ideas: * Write the tests in such a way, that there are no test failures on Alexandre's main Linux development machine. Accept test failures for all other Linux/MacOS/FreeBSD/... platforms. * Add additional todo_mac, todo_linux, ... macros, and define WINETEST_PLATFORM to something a bit more specific than just "wine". todo_wine would mean that it is a todo on all platforms supported by Wine. This doesn't solve the problems with old/new kernels though. * Try to detect MacOS somehow else directly in the test (what would be the recommended way?) and use if(...)s based on that condition, instead of the test result. This also provides no solution for old/new kernels ... I'm also open for additional suggestions if someone has a good idea. I would especially like to hear, that the solution is _not_ that every Wine developer always has to check all possible platforms before submitting tests, which can easily get very complicated... Regards, Sebastian BTW: For those that are interested in the details where I'm working on, just take a look at: http://bugs.winehq.org/show_bug.cgi?id=17195#c154 ;)

1 0

Re: [PATCH 2/2] vbscript: Implemented Int
by Marvin 05 Aug '14

05 Aug '14

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=8295 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Implemented Fix
by Marvin 05 Aug '14

05 Aug '14

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=8294 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [1/2] imagehlp/tests: Add test for BindImageEx (try 12)
by Alexandre Julliard 04 Aug '14

04 Aug '14

Bernhard Reiter <ockham(a)raz.or.at> writes: > @@ -31,6 +31,8 @@ > static HMODULE hImageHlp; > > static BOOL (WINAPI *pImageGetDigestStream)(HANDLE, DWORD, DIGEST_FUNCTION, DIGEST_HANDLE); > +static BOOL (WINAPI *pBindImageEx)(DWORD Flags, const char *ImageName, const char *DllPath, > + const char *SymbolPath, void *StatusRoutine); That's not the correct prototype. > +static BOOL WINAPI testing_status_routine(IMAGEHLP_STATUS_REASON reason, char *ImageName, > + char *DllName, ULONG_PTR Va, ULONG_PTR Parameter) > +{ > + char kernel32_path[MAX_PATH]; > + > + status_routine_called[reason]++; This will have nasty results if you get an unexpected code. > + default: > + ok(0, "expected reason to be one of BindImportModule, BindImportProcedure, or " > + "BindForwarderNOT, got %d\n", reason); Please simplify your error messages. In particular, this one would need to be changed every time the test is expanded, that's not a good idea. > +static void test_bind_image_ex(void) > +{ > + BOOL ret; > + HANDLE file; > + char temp_file[MAX_PATH] = "nonexistant.dll"; There's no reason to use a variable for this. > + /* Under 64 bit images of Vista Ultimate, 2008 Server, and 7 Pro, StatusRoutine is called with > + * reason BindForwarderNOT instead of BindImportProcedure. */ > + todo_wine ok((status_routine_called[BindImportProcedure] == 1) || > + (status_routine_called[BindForwarderNOT] == 1), > + "Expected StatusRoutine to be called once with reason BindImportProcedure or " > + "BindForwarderNOT, but it was called %d and %d times, respectively\n", > + status_routine_called[BindImportProcedure], status_routine_called[BindForwarderNOT]); You'd most likely want the test to depend on 32/64-bit instead of always accepting both. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/5] wined3d: Make d3d_level_from_gl_info return an enum instead of a plain int
by Henri Verbeet 04 Aug '14

04 Aug '14

On 1 August 2014 20:25, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > -static UINT d3d_level_from_gl_info(const struct wined3d_gl_info *gl_info) > +static enum wined3d_d3d_level d3d_level_from_gl_info(const struct wined3d_gl_info *gl_info) > { > - UINT level = 0; > + enum wined3d_d3d_level level = WINED3D_D3D_LEVEL_5; > > if (gl_info->supported[ARB_MULTITEXTURE]) > - level = 6; > + level = WINED3D_D3D_LEVEL_6; > if (gl_info->supported[ARB_TEXTURE_COMPRESSION] > && gl_info->supported[ARB_TEXTURE_CUBE_MAP] > && gl_info->supported[ARB_TEXTURE_ENV_DOT3]) > - level = 7; > - if (level == 7 && gl_info->supported[ARB_MULTISAMPLE] > + level = WINED3D_D3D_LEVEL_7; > + if (level == WINED3D_D3D_LEVEL_7 && gl_info->supported[ARB_MULTISAMPLE] > && gl_info->supported[ARB_TEXTURE_BORDER_CLAMP]) > - level = 8; > - if (level == 8 && gl_info->supported[ARB_FRAGMENT_PROGRAM] > + level = WINED3D_D3D_LEVEL_8; > + if (level == WINED3D_D3D_LEVEL_8 && gl_info->supported[ARB_FRAGMENT_PROGRAM] > && gl_info->supported[ARB_VERTEX_SHADER]) > - level = 9; > - if (level == 9 && (gl_info->supported[EXT_GPU_SHADER4] > + level = WINED3D_D3D_LEVEL_9_SM2; > + if (level == WINED3D_D3D_LEVEL_9_SM2 && (gl_info->supported[EXT_GPU_SHADER4] > || gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30))) > - level = 10; > + level = WINED3D_D3D_LEVEL_10; > > return level; > } ... > - if (d3d_level >= 9 && gl_info->supported[NV_VERTEX_PROGRAM3]) > + if (d3d_level >= WINED3D_D3D_LEVEL_9_SM3) You never return WINED3D_D3D_LEVEL_9_SM3 from d3d_level_from_gl_info(). I'd recommend to just introduce WINED3D_D3D_LEVEL_9 in this patch, and split it up in _SM2 and _SM3 in a separate patch.

2 2

Re: [PATCH 5/5] wined3d: Move the "draw_binding" field from struct wined3d_surface to struct wined3d_resource.
by Stefan Dösinger 04 Aug '14

04 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-04 12:17, schrieb Henri Verbeet: > @@ -2029,6 +2029,7 @@ struct wined3d_resource > DWORD usage; > enum wined3d_pool pool; > DWORD access_flags; > + DWORD draw_binding; Will this stay in wined3d_resource, or do you plan to move this to wined3d_(render_target_)view later on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT35NhAAoJEN0/YqbEcdMwKKIP/32Zs+FGhMdt06llhXpNY34v /HnQyeTpQOlyHH4Q6xZT/2gg3I5v9L75Vrtryfgh/K5TBCIhMxP1inbPs9mooumz 67+A8X6cUZ0eSONlj/KT8qrk8sloy06nRfhh1IdZSdhPV0VUUFqC3HV01+BwaDdU Nz8lr/p2DGpUQkW5SjCjNNCHUEIRorvsoioZStIHAKNaEvlVwM+V0E6+u2lPKntz qhuT+D8kLq85E36TRc/zBkqYeFI0v9mnPymczG/gdU7bXQcz/KapqRvLoINCtZgF UM8o//uMkMkcepP4Zl6nPi5eYcJ7e/gOFioI6NkHQ87E1LNmmF9PljU/YyyGNcFP Y8xRQ+toSqZlNQ2lsP68r1jIGnH2ueW9LuawP6r6HxiWEXM0HzMs45F4X1VeBRa9 uZDADSaGbgmUJ73ceLAY1tNMMpuv8cBB6SJf7tW9rIRZNcSeV0U2O7O5Qb2t9DYh gLU5BqsTtVa+WiakO4HVKejsT8J2y/qqrdAg2bS8TbsrKjJIr8K7warUtekkIPIc t8hzrwhSqrdPdV3Xozya6tsA6qL2hgYS0vTYllJJ2TlCqmG71dWXIg9DXQ3CnAp6 RiwdAmpZiplwoLqBJn/k433xQmh5T8lHr74Jiw0V56f+aOktzp2udWzR2d4X9TI8 cH5SReslhRG86g2cTPbv =F1T9 -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/2] ddraw/tests: Ignore broken behavior of D3DTRANSFORM_UNCLIPPED.
by Henri Verbeet 04 Aug '14

04 Aug '14

On 31 July 2014 00:56, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > On new versions of Windows this test no longer behaves as expected > (clearly somebody at MS introduced a bug). Spotted while working on > Patch 2. > The test seems to be of somewhat questionable usefulness to begin with. Stefan, since you wrote this, is there any application that actually depends on this? Any value in keeping the test?

2 1

Re: [PATCH 2/5] d3d10core: Implement d3d10_device_CopyResource().
by Stefan Dösinger 04 Aug '14

04 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-08-04 12:17, schrieb Henri Verbeet: > + if (dst_resource->type != WINED3D_RTYPE_TEXTURE) > + { > + FIXME("Not implemented for %s resources.\n", debug_d3dresourcetype(dst_resource->type)); > + return; > + } What's the point of implementing this based on textures and blits? It seems to me that a major restructuring will be needed to make this work on buffers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT35GOAAoJEN0/YqbEcdMwljwQAI2wEkyQHnUbwVIc6wV1bkm6 25ySqo8ZC27L72eHHPpA6nBNDObcbN19MpnTGh57cK1xzt6aC/KBWwCotXkbgKzK almnHatukw7Nkms1jMGn7C0ROQRcdBC4VHKpeINKcCdTxfosm81NOpj9eofy0hB1 BGqWzAhS9oOKGmQZznIHeWJJNuRe5skvsOVvSg4bbaHGi1528BgKLLxRtlFfbXbO LNT3SnGvAI9jJC2lJEJ1SH62NkPXJmh8gIm5ptGS2JNzkT7EjNQyxqBJ1uTjlsAH jyIX1+XZx+H950ucH1RktOyccowPzi1TY2qe6nBDDr4G5u/mgfzXcGbHcUd1G51K DPP09g4NdaPExjfi40c0CgD0xRNgu7JInhzqLiBeEU2LBiXiSNC+wR8oXSlOroMj rC93/J2CqJ+7emZ1SQSq+zQECdaqscQ11iPPQGfKkwxlm8XwF+knMh99hnyknaQs wTbRh9Fp0OzM7cs81E3GL/KxJ+pmqctLBZSVAn6VHAXs06d3BQ+moX5D7sZaopQ/ y2U83wECb3DwSHp1ihbhoM6en9CWxdkLn+JqA8VRLiS803el7e7QvpmRzR7t8+VA O4jvo6v7TWszpsL2HbuyCJeOnWsVXAjIxlB2Eok8CI+FfYc0S20QCBMaFw1ixVIr BiyVPU9VwG/qicUSK53R =5T4j -----END PGP SIGNATURE-----

2 2

Re: [PATCH 2/2] ddraw: Return empty D3D hardware flags for HEL device enumeration.
by Henri Verbeet 04 Aug '14

04 Aug '14

On 31 July 2014 00:57, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > @@ -537,12 +537,16 @@ static HRESULT WINAPI enumDevicesCallback(GUID *Guid, char *DeviceDescription, > > ok(hal->dcmColorModel == 0, "RGB Device %u hal caps has colormodel %u\n", ver, hal->dcmColorModel); > ok(hel->dcmColorModel == D3DCOLOR_RGB, "RGB Device %u hel caps has colormodel %u\n", ver, hel->dcmColorModel); > + > + ok(hal->dwFlags == 0, "RGB Device %u has hardware flags %x\n", ver, hal->dwFlags); > } > else if(IsEqualGUID(&IID_IDirect3DHALDevice, Guid)) > { > trace("HAL Device %d\n", ver); > ok(hal->dcmColorModel == D3DCOLOR_RGB, "HAL Device %u hal caps has colormodel %u\n", ver, hel->dcmColorModel); > ok(hel->dcmColorModel == 0, "HAL Device %u hel caps has colormodel %u\n", ver, hel->dcmColorModel); > + > + ok(hal->dwFlags != 0, "HAL Device %u has hardware flags %x\n", ver, hal->dwFlags); > } In principle this patch looks plausible enough. What about hel->dwFlags though, and what about other device types like Ref, MMX, etc.?

1 0

Re: [2/2]dwrite: basic implementation for FontCollectionLoader registration
by Nikolay Sivov 04 Aug '14

04 Aug '14

> + IDWriteFontCollectionLoader **CollectionLoaders; > + LONG CollectionLoaderCount; I'd really like a better naming for those, something like 'loaders' and 'loaders_count'. > + if (i == This->CollectionLoaderCount) > + { > + This->CollectionLoaderCount++; > + if (This->CollectionLoaders) > + This->CollectionLoaders = heap_realloc(This->CollectionLoaders, This->CollectionLoaderCount * sizeof(IDWriteFontCollectionLoader*)); > + else > + This->CollectionLoaders = heap_alloc(This->CollectionLoaderCount * sizeof(IDWriteFontCollectionLoader*)); > + if (!This->CollectionLoaders) > + return E_OUTOFMEMORY; > + } > + IDWriteFontCollectionLoader_AddRef(loader); > + This->CollectionLoaders[i] = loader; This should grow more efficiently in my opinion. Also it probably makes sense to have small number of slots allocated on initial factory creation or even use a list (you don't need index access). Another question is do we want to register a default local loader on factory creation or not.

2 3

Re: [2/2]dwrite: basic implementation for FontCollectionLoader registration
by Piotr Caban 04 Aug '14

04 Aug '14

On 8/1/14 12:01 PM, Aric Stewart wrote: > + if (i == This->CollectionLoaderCount) > + { > + This->CollectionLoaderCount++; > + if (This->CollectionLoaders) > + This->CollectionLoaders = heap_realloc(This->CollectionLoaders, This->CollectionLoaderCount * sizeof(IDWriteFontCollectionLoader*)); > + else > + This->CollectionLoaders = heap_alloc(This->CollectionLoaderCount * sizeof(IDWriteFontCollectionLoader*)); > + if (!This->CollectionLoaders) > + return E_OUTOFMEMORY; > + } There's a leak in out of memory case. Isn't it better to grow the buffer exponentially?

3 2

What happened to the Fedora packages?
by Neal Gompa 02 Aug '14

02 Aug '14

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

Re: [3/3] dwrite/tests: Some tests for drawing sequence for a layout
by Marvin 31 Jul '14

31 Jul '14

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=8225 Your paranoid android. === w8 (32 bit layout) === layout.c:191: Test failed: unexpected QI {d3e0e934-22a0-427e-aae4-7d9574b59db1}

2 1

Re: [PATCH 5/6] quartz: Fix race condition on EndFlush between csRenderLock and filter.csFilter.
by Michael Stefaniuc 31 Jul '14

31 Jul '14

On 07/31/2014 03:48 AM, Erich E. Hoover wrote: > From b67543fba9b2af87654533831aee2c4dae43571a Mon Sep 17 00:00:00 2001 > From: "Erich E. Hoover" <erich.e.hoover(a)gmail.com> > Date: Thu, 17 Jul 2014 10:31:17 -0600 > Subject: quartz: Fix race condition on EndFlush between csRenderLock and > filter.csFilter. > > --- > dlls/quartz/videorenderer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/quartz/videorenderer.c b/dlls/quartz/videorenderer.c > index 4e8f359..5fe0aea 100644 > --- a/dlls/quartz/videorenderer.c > +++ b/dlls/quartz/videorenderer.c > @@ -377,8 +377,8 @@ static HRESULT WINAPI VideoRenderer_EndFlush(BaseRenderer* iface) > LeaveCriticalSection(&iface->csRenderLock); > LeaveCriticalSection(&iface->filter.csFilter); Eric, shouldn't you release the inner lock first? > WaitForSingleObject(This->hEvent, INFINITE); > - EnterCriticalSection(&iface->filter.csFilter); > EnterCriticalSection(&iface->csRenderLock); > + EnterCriticalSection(&iface->filter.csFilter); > EnterCriticalSection(iface->pInputPin->pin.pCritSec); > } > if (This->renderer.filter.state == State_Paused) { bye michael

2 1

mshtml: Added IHTMLImgElement::isMap property implementation.
by Zhenbo Li 31 Jul '14

31 Jul '14

--- dlls/mshtml/htmlimg.c | 27 +++++++++++++++++++++++---- dlls/mshtml/tests/dom.c | 18 ++++++++++++++++++ 2 files changed, 41 insertions(+), 4 deletions(-)

1 0

XInput over SDL
by akjsdfk sdkfnskd 31 Jul '14

31 Jul '14

Long story short, while I helped my friend with his "up to the neck in MS API" game, I wrote him complete drop in solution library for XInput over SDL. And since making patch for wine was easier than testing his half done game... well, it came to full featured XInput handling It supports: - hotplugging/unplugging (well, only if game didn't use DInput to scan new devices. if it is pure XInput, then it just works) - all controllers supported by SDL are XInput capable - haptic works And before cleaning it, I just wanted to ask if XInput over SDL is wanted or not. There is no point in working on regular patch if that is out of question. Just short points why SDL and not native (which I'm not interested in even remotely): - far better API than XInput - controller database is updated - completely cross platform - same source can be reused to port game ... but, don't treat this as I would try starting some holy war. If it doesn't fit in wine plans, no problem. I can still provide it as standalone patch for those that want it with regards wh1sper_123

5 7

[PATCH 3/3] iphlpapi: Add PfUnBindInterface function stub (try 2)
by Hao Peng 31 Jul '14

31 Jul '14

fix bug 36833 sorry for that I didn't follow the rules to send patches to wine dev channel. Hope I corrected everything this time.--- dlls/iphlpapi/iphlpapi.spec | 2 +- dlls/iphlpapi/iphlpapi_main.c | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-)

1 0

[PATCH 2/3] iphlpapi: Add PfDeleteInterface function stub (try 2)
by Hao Peng 31 Jul '14

31 Jul '14

fix bug 36833 sorry for that I didn't follow the rules to send patches to wine dev channel. Hope I corrected everything this time.--- dlls/iphlpapi/iphlpapi.spec | 2 +- dlls/iphlpapi/iphlpapi_main.c | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-)

1 0

[PATCH 1/3] iphlpapi: Add PfBindInterfaceToIPAddress function stub (try 2)
by Hao Peng 31 Jul '14

31 Jul '14

fix bug 36833 sorry for that I didn't follow the rules to send patches to wine dev channel. Hope I corrected everything this time. --- dlls/iphlpapi/iphlpapi.spec | 2 +- dlls/iphlpapi/iphlpapi_main.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-)

1 0

Re: [PATCH] riched20: Stub for ITextRange interface and implement ITextDocument::Range.
by Marvin 31 Jul '14

31 Jul '14

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=8174 Your paranoid android. === w2000pro (32 bit richole) === The test timed out

2 1

Re: shell32: Implement IEnumShellItems for IShellItemArray.
by Marvin 30 Jul '14

30 Jul '14

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=8193 Your paranoid android. === w7u (32 bit shlfolder) === shlfolder.c:3688: Test failed: Got 00000000 === w8 (32 bit shlfolder) === shlfolder.c:3688: Test failed: Got 00000000

1 0

Re: (Retry)[4/5] imm32: Restrict crossthread Association and destruction
by Marvin 30 Jul '14

30 Jul '14

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=8186 Your paranoid android. === wvistau64 (32 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === w2008s64 (32 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === wvistau64 (64 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed === w2008s64 (64 bit imm32) === imm32.c:629: Test failed: ImmGetCandidateWindow should succeed

1 0

Re: (Retry)[6/6]imm32: limit cross thread access to ImmSet* functions
by Aric Stewart 30 Jul '14

30 Jul '14

Sorry this patch is mislabeled as [6/6] it should be [5/5] -aric On 7/30/14, 3:32 PM, Aric Stewart wrote: > Resolves bug 35361 > --- > dlls/imm32/imm.c | 21 +++++++++++++++++++++ > dlls/imm32/tests/imm32.c | 28 ++++++++++++++-------------- > 2 files changed, 35 insertions(+), 14 deletions(-) > > > > >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel