November 2009 - Wine-Devel - list.winehq.org

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
by chris ahrendt Nov. 25, 2009

Nov. 25, 2009

Roderick Colenbrander wrote: > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Ok going through and looking at the next failure in wine tests I found this one : >> >> >> If you look at the code its: >> >> >> 779 color = getPixelColor(device, 160, 120); >> 780 red = (color & 0x00ff0000) >> 16; >> 781 green = (color & 0x0000ff00) >> 8; >> 782 blue = (color & 0x000000ff); >> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >> >> >> but in MSDN it says : >> >> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >> >> Format of the rgb color is : >> >> 0x00bbggrr >> >> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >> the third byte contains a value for blue. >> >> The high-order byte must be zero. >> >> The maximum value for a single byte is 0xFF. >> >> so shouldn't it be something like this: >> >> red = color & 0x000000FF; >> green = ( color & 0x0000FF00 ) >> 8; >> blue = ( color & 0x00FF0000 ) >> 16; >> >> not the what is in the test? because of the following C action >> >> expression1 >> shift_value >> >> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >> shift_value. If expression1 is signed, then the result is implementation specific. >> >> so the test seems to be assigning the wrong values to the RGB.... Correct? >> >> chris >> > We are creating the framebuffer in the ARGB format (see init_d3d9). > D3D supports a variety of formats and we don't use the gdi RGB macro. > > Roderick > > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it to come back in the ARGB format??? Is that setup in the init_d3d9? chris

2 1

Next release
by Alexandre Julliard Nov. 24, 2009

Nov. 24, 2009

Folks, I'll be out for the rest of the week, so there won't be a release this Friday. 1.1.34 will be released on December 4. And with the new patch tracker you can watch the patches pile up while I'm away ;-) -- Alexandre Julliard julliard(a)winehq.org

4 3

mapistub: add stubbed dll mapistub.dll
by Louis Lenders Nov. 24, 2009

Nov. 24, 2009

I guess we can forward those functions to mapi32 later on. While running the app, no functions were called at all, it was even enough to copy a random dll into system32 , and call it mapistub.dll. That was enough to get the app going

1 0

Re: ole32: Fix circular reference count in default handler objects.
by Rob Shearman Nov. 24, 2009

Nov. 24, 2009

2009/11/24 Rob Shearman <robertshearman(a)gmail.com>: > This is caused by caching a pointer and reference to the data cache's > IPersistStorage interface without managing reference counts > appropriately. > --- > dlls/ole32/defaulthandler.c | 22 ++++++++++++++++++++++ > 1 files changed, 22 insertions(+), 0 deletions(-) > > Fixes memory leaks in defaulthandler tests. May also fix bugs 12419 & 14863. I should also note that the rules for aggregating objects implemented by this patch are listed here: http://msdn.microsoft.com/en-us/library/ms686558(VS.85).aspx -- Rob Shearman

1 0

Re: wineserver: Mark registry hives clean after being loaded initially from file
by Alexandre Julliard Nov. 24, 2009

Nov. 24, 2009

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -1393,6 +1393,7 @@ > fprintf( stderr, "%s is not a valid registry file\n", filename ); > return; > } > + make_clean( key ); It would be better to create them with the correct flags in the first place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: opengl32: fix wglCreateContextAttribsARB on nvidia
by Dmitry Timoshkov Nov. 24, 2009

Nov. 24, 2009

"Roderick Colenbrander" <thunderbird2k(a)gmail.com> wrote: > +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code */ > +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x40000000) Using MAKE_HRESULT() with appropriate severity and facility would be cleaner IMO. -- Dmitry.

2 1

RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
by chris ahrendt Nov. 24, 2009

Nov. 24, 2009

Ok going through and looking at the next failure in wine tests I found this one : If you look at the code its: 779 color = getPixelColor(device, 160, 120); 780 red = (color & 0x00ff0000) >> 16; 781 green = (color & 0x0000ff00) >> 8; 782 blue = (color & 0x000000ff); 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); but in MSDN it says : This value is a 32-bit value used to specify an RGB color or CLR_INVALID Format of the rgb color is : 0x00bbggrr The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF. so shouldn't it be something like this: red = color & 0x000000FF; green = ( color & 0x0000FF00 ) >> 8; blue = ( color & 0x00FF0000 ) >> 16; not the what is in the test? because of the following C action expression1 >> shift_value Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of shift_value. If expression1 is signed, then the result is implementation specific. so the test seems to be assigning the wrong values to the RGB.... Correct? chris

2 1

Re: mapistub: add stubbed dll mapistub.dll
by Rob Shearman Nov. 24, 2009

Nov. 24, 2009

2009/11/23 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk>: > This fixes http://bugs.winehq.org/show_bug.cgi?id=20050 > > The dll is present on my XP system This DLL is already partially implemented in a DLL called mapi32, so there should be no need to add this completely stubbed out. -- Rob Shearman

1 0

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.
by Paul Vriens Nov. 24, 2009

Nov. 24, 2009

On 11/19/2009 01:23 PM, Austin Lund wrote: > - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& > - pFileStructA->uFileTime == pFileStructW->uTime2, > - "Last write time should match last access time!\n"); > - Hi Austin, Is there no other way to get around this? I think it's a bit of a shame having tests removed for that odd system that has a FAT filesystem on a NT4+ box. -- Cheers, Paul.

2 6

Re: [2/3] msi/tests: Test for SELECT table.column FROM table
by Nikolay Sivov Nov. 23, 2009

Nov. 23, 2009

On Tue, Nov 24, 2009 at 11:14 AM, Nathan Gallaher <ngallaher(a)deepthought.org> wrote: > Make sure that mixing table columns returns the expected > data. eg: SELECT t1.action, t2.action FROM t1, t2 > should return distinct data. > > > + // Test that selection based on prefixing the column with the table + // actually selects the right data Cpp style isn't allowed, please resend it with plain C comments. Thanks.

1 0