September 2014 - Wine-Devel

Re: [PATCH] vbscript: Implemented RGB(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://testbot.winehq.org/JobDetails.pl?Key=8993 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

Sept. 20, 2014

Re: [PATCH] vbscript: Implemented RGB

by Nikolay Sivov

On Fri, Sep 19, 2014 at 4:02 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > On 09/19/2014 02:14 PM, Shuai Meng wrote: > > + total = color[0] + 256 * color[1] + 256 * 256 * color[2]; >>> >> >> RGB() macro does the same thing. >> >> I don't quite understand this line..will you explain it in detail > please? > > See http://source.winehq.org/source/include/wingdi.h#0434 > So total = color[0] + 256 * color[1] + 256*256*color[2] is the same as > total = RGB(color[0], color[1], color[2]) > > > > Right, it's also better to rename color component variables imho.

Sept. 19, 2014

Re: Question about implementing a test for BCryptGetFipsAlgorithmMode

by Kai Blaschke

> If you need to do something that requires admin privileges, you should > try to do it and check for an access denied error. If it fails with > access denied, you should skip the test. (Ideally, you should try > running your test with a limited account on Windows.) Non-admin users lack the proper access rights to change anything in HKLM, so at least on modern systems with active UAC the test won't work. > I would be more worried about the fact that it's changing a global > user preference. Maybe you should just read the key and verify that > the API matches the value there. It's worse, to fully test both OS variants, the test would have to delete and create subkeys, since Microsoft put the value under a subkey of the name of the former value since Vista. That's nothing I'd like to do on some unsuspecting user's machine. > This is probably more depth than you should be putting into > investigating native's behavior. If it's supposed to be a boolean, and > the expected values are 1 and 0, you can assume it's one of those and > not worry about what happens if it's 256 (unless you know a real > application that sets that value). Yeah, that's what the documentation states, too. I tested this just out of curiosity. I'll leave it with my current code for both the implemenation and the test, and submit the patch for reviewing.

Sept. 19, 2014

Re: wined3d: Correctly display fog for right-handed projection matrix (try 2)

by Joachim Priesner

Thanks for your response. > For example, it doesn't currently distinguish between using the > absolute fog coordinate in the vertex shader or doing the same in the > fragment shader. Is it enough to extend the test to include both FOGVERTEXMODE and FOGTABLEMODE? Or what else would I (roughly) have to do? Joachim Am Freitag, 19. September 2014 schrieb Henri Verbeet: > On 18 September 2014 21:57, Joachim Priesner <joachim.priesner(a)web.de> wrote: > > When using a right-handed projection matrix, z coordinates of vertices may be negative. This is not considered in the code generating the GLSL fog shader. The patch fixes that and adds a test. > > > The patch is likely correct, but the test has room for improvement. > For example, it doesn't currently distinguish between using the > absolute fog coordinate in the vertex shader or doing the same in the > fragment shader. Also, please don't forget about ddraw and d3d8.

Sept. 19, 2014

Re: [3/3] gdiplus: Add a more optimized loop for composing onto PARGB.

by Vincent Povirk

>> + else if ((fg & 0xff000000) == 0xff) > > This will never be true. Thanks, I will fix that and resend.

Sept. 19, 2014

Re: [3/3] gdiplus: Add a more optimized loop for composing onto PARGB.

by Andrew Eikum

On Fri, Sep 19, 2014 at 11:28:13AM -0500, Vincent Povirk wrote: > + else if ((fg & 0xff000000) == 0xff) This will never be true. Andrew

Sept. 19, 2014

Re: Question about implementing a test for BCryptGetFipsAlgorithmMode

by Vincent Povirk

> To properly test the function, I'd have to write to a registry key in > HKLM\System\CurrentControlSet\Control\Lsa. Is it safe to assume that the > test has write access to this key? If you need to do something that requires admin privileges, you should try to do it and check for an access denied error. If it fails with access denied, you should skip the test. (Ideally, you should try running your test with a limited account on Windows.) I would be more worried about the fact that it's changing a global user preference. Maybe you should just read the key and verify that the API matches the value there. > Additionally, I noticed I put a small bug in the code, returning false for > all registry values which are multiples of 256, which is a result of simply > casting a registry DWORD value to a BOOLEAN. To my surprise, the original > function - tested with WinXP and Win7 - has the same bug, so I wouldn't fix > my implementation before sending in the patch if no one votes against it. This is probably more depth than you should be putting into investigating native's behavior. If it's supposed to be a boolean, and the expected values are 1 and 0, you can assume it's one of those and not worry about what happens if it's 256 (unless you know a real application that sets that value).

Sept. 19, 2014

Question about implementing a test for BCryptGetFipsAlgorithmMode

by Kai Blaschke

Hi, I had a small patch lying around here for some while which properly implements the BCryptGetFipsAlgorithmMode function, behaving identically to the original implementation. Just one question is bugging me, regarding the test. To properly test the function, I'd have to write to a registry key in HKLM\System\CurrentControlSet\Control\Lsa. Is it safe to assume that the test has write access to this key? Additionally, I noticed I put a small bug in the code, returning false for all registry values which are multiples of 256, which is a result of simply casting a registry DWORD value to a BOOLEAN. To my surprise, the original function - tested with WinXP and Win7 - has the same bug, so I wouldn't fix my implementation before sending in the patch if no one votes against it. Regards Kai

Sept. 19, 2014

Re: [PATCH] vbscript: Implemented RGB

by Shuai Meng

2014-09-19 21:02 GMT+08:00 GOUJON Alexandre <ale.goujon(a)gmail.com>: > On 09/19/2014 02:14 PM, Shuai Meng wrote: > > + total = color[0] + 256 * color[1] + 256 * 256 * color[2]; >>> >> >> RGB() macro does the same thing. >> >> I don't quite understand this line..will you explain it in detail > please? > > See http://source.winehq.org/source/include/wingdi.h#0434 > So total = color[0] + 256 * color[1] + 256*256*color[2] is the same as > total = RGB(color[0], color[1], color[2]) > Thank you, I have found that.

Sept. 19, 2014

Re: [PATCH 1/2] riched20: Stub for ITextFont interface and implement ITextRange::GetFont. (try 3)

by Huw Davies

On Fri, Sep 19, 2014 at 08:58:51PM +0800, Jactry Zeng wrote: > dlls/riched20/richole.c | 786 > +++++++++++++++++++++++++++++++++++++++++- > dlls/riched20/tests/richole.c | 47 +++ > 2 files changed, 831 insertions(+), 2 deletions(-) These two look good to me. Huw.

Sept. 19, 2014