Re: [3/4] kernel32/tests: Add 0-length read tests for a pipe.
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://newtestbot.winehq.org/JobDetails.pl?Key=2250 Your paranoid android. === wvista (32 bit pipe) === Failure running script in VM: network read error: Resource temporarily unavailable
Re: (resend)[3/4] imm32: use thread data from target HWND
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://newtestbot.winehq.org/JobDetails.pl?Key=2263 Your paranoid android. === build (build) === Patch failed to apply
Re: (resend)[3/4] imm32: use thread data from target HWND
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://newtestbot.winehq.org/JobDetails.pl?Key=2262 Your paranoid android. === build (build) === Patch failed to apply
Re: [3/4] imm32: use thread data from target HWND
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://newtestbot.winehq.org/JobDetails.pl?Key=2256 Your paranoid android. === build (build) === Patch failed to apply
Re: (resend)[3/4] imm32: use thread data from target HWND
Aric Stewart writes: > @@ -507,7 +524,7 @@ HIMC WINAPI ImmAssociateContext(HWND hWnd, HIMC hIMC) > LeaveCriticalSection(&threaddata_cs); > defaultContext = ImmCreateContext(); > ((InputContextData*)defaultContext)->threadDefault = TRUE; > -thread_data = IMM_GetThreadData(0); > +thread_data = IMM_GetThreadDataForWindow(hWnd); > thread_data->defaultContext = defaultContext; > } You have multiple race conditions here. -- Alexandre Julliard julli...@winehq.org
Re: [3/4] ws2_32: Filter invalid socket parameters and return the appropriate error
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://newtestbot.winehq.org/JobDetails.pl?Key=2237 Your paranoid android. === build (build) === Patch failed to apply
Re: [3/4] ws2_32: Filter invalid socket parameters and return the appropriate error
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://newtestbot.winehq.org/JobDetails.pl?Key=2228 Your paranoid android. === build (build) === Patch failed to apply
Re: [PATCH 3/4] d3dx9: Improve ID3DXConstantTable::Set*().
Rico Schüller writes:
> +static UINT set(struct ID3DXConstantTableImpl *table, IDirect3DDevice9
> *device, struct ctab_constant *constant,
> +const void **indata, D3DXPARAMETER_TYPE intype, UINT *size, UINT
> incol, D3DXPARAMETER_CLASS inclass, UINT index,
> +BOOL is_pointer)
> +{
> +DWORD (*get_index)(const void **indata, UINT index) = NULL;
> +D3DXCONSTANT_DESC *desc = &constant->desc;
> +UINT l, i, regcount = 1, regsize = 1, cin = 1, rin = 1, ret, last = 0;
> +DWORD tmp;
> +
> +if (is_pointer) get_index = &get_index_pointer;
> +else get_index = &get_index_array;
It would be cleaner and easier to follow to have a simple helper with a
is_pointer flag, rather than using function pointers with such trivial
functions.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-20 13:23, schrieb Henri Verbeet: >> Just to make sure I understand you correctly: You're saying that >> the test should still call SetRenderState(LIGHTING), check the >> initial value, and GetRenderState(LIGHTING) should return a >> hardcoded 0x? >> > I think it may be enough to only ever set it and test that it > doesn't affect rendering. Ok -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwuupAAoJEN0/YqbEcdMwzfAP/1efoDdVK1cUpx2z3w0dFVxS ftaHF4MW4vywyFOIr6bjsNBAly0movKiWLMSoZ0HhDPD5l7ooY6kXCdqtiiSsulu id9lPx9OxhWBBubYGvinOe/j/9gQnjnKk9UWDT3/CJbHASwezTlAt8kzdPhvOFs1 iYTwc55M1c3RanUn4IWz6AovBL0iTAYKfM9mq/Qj+m8XWc9SRNVA6pTycq7hrpLh vJuIvb4gRuRxufzwdisr5HbGqsOPW9X/HflmgAbYZ0Jm6DAgsrjV71Nzuqj8A6Ry lc2582BqAuctBGfsWvJfDd00w+0hPfHKpnrh2j5UyRTH7NWX5MZV21wr/sOYSZTp N8fblKoiULniDOy0+xMfFjMoDhCzy8WAAIuBuSehsz/1pkPAn0SiH1NVzOMpl4t/ p3NviOBHCcbvKH4aw9S71Pvmoft00kH2CzZt0CIfIz1RDEV+9w4OFBpCCAIYADcH Bkduwp5DzB3UBaJjm/kEblgPW5spajKPohGvyA3N7K3g2hwAKj36eqBcsU7S1iC9 m5ZjR7bO/7aOy+au/1M4+4ASB5RtHP4Jo5iXC6Bmtv/A33dz3aJFt2+sSvKdfWi3 /x4YvR6kNMqWYqixRe0H6K9psSqTceMYSwDvfpX9uh9mYNNeJZdqmqBL7U7osjQK WGwQ5nKCz0OCnneCek6N =5IQX -END PGP SIGNATURE-
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
On 20 June 2013 13:18, Stefan Dösinger wrote: > I don't know any application that depends on this. It just seemed like > an interesting thing to test to see how far the interaction between > the different APIs goes. > > Just to make sure I understand you correctly: You're saying that the > test should still call SetRenderState(LIGHTING), check the initial > value, and GetRenderState(LIGHTING) should return a hardcoded 0x? > I think it may be enough to only ever set it and test that it doesn't affect rendering.
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-20 13:02, schrieb Henri Verbeet: > On 20 June 2013 12:17, Stefan Dösinger > wrote: >> /* Light state */ DWORD material; +DWORD dummy_rs_lighting; >> > Considering the render state doesn't exist in early ddraw versions, > do we really care that its value is preserved? It seems unlikely > that anything except our tests would depend on it. I don't know any application that depends on this. It just seemed like an interesting thing to test to see how far the interaction between the different APIs goes. Just to make sure I understand you correctly: You're saying that the test should still call SetRenderState(LIGHTING), check the initial value, and GetRenderState(LIGHTING) should return a hardcoded 0x? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwuUDAAoJEN0/YqbEcdMwDCAQAJAGmdgE2CP6ZwMudC1x77eh SORFI6G/U8vO+6zv39KWAStA9S6KB9MOJuHGo8ytVxscn5UxXo7QR4+WqtKc4G6M 75Qry5gsHRvHEa9YeJIcJttjZq49+htZ0rWmt2HxI4+XC4aeIpsQWBNDoJLBE94P +M915aZPrBB7rurhGqgWBQ/lDt9o0ov2obH2NUJj8Ze7KKPYIT150rRVxbS1qqbp D0DpIKT+4rgUukx77zN6jQ7+gegUGTQodbhD1VKaD0HicCBEPJ4l8/dB3Q8bvfa+ Xe/E69/5YmslMO74rYD702grNOiGhHAcRQbetqxllcGivIOrO1CWCP88465uhfED pLD+7aIoVqcroj5ifgQkGtrZ4tcSN6GoJcvy5x+7d0OtiJmf8xHeHjw8SF7fqCQk Uy4/t5IRrAcOzR9v81lp+38hVUUpminc3cW9YK8nEQDCyHTxi9MWalOoU1xR0Zlm qtkpYPxjZoNl4aju2xC2t+AanjsX/9+VRsmiY5hj4j5QE2o0Wsp9c6Y75XsdCuGR SHMJkeq1DfthNhMJTpF4eMG4HdW00nxtrAT14WRUq+I6vlgRXjgUYrw4GgJRFFYW diqeqj+KJtDErTP/X3jlnLZhw6Dy2sLq0J/inoXjom6oZPvgCXfPDEq0nupQzE8y ef9JQ1JCpo5NJ4E8rZZU =oVUh -END PGP SIGNATURE-
Re: [PATCH 3/4] ddraw: Device2 and Device3 do not have a lighting render state
On 20 June 2013 12:17, Stefan Dösinger wrote: > /* Light state */ > DWORD material; > +DWORD dummy_rs_lighting; > Considering the render state doesn't exist in early ddraw versions, do we really care that its value is preserved? It seems unlikely that anything except our tests would depend on it.
Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
On 04/01/2013 08:16 AM, Henri Verbeet wrote: I think it's ok for the tests to be todo_wine, but we do want ddraw coverage for this in the tests. Fine by me. But that will take a few days since I'll have to familiarize myself with ddraw first. :) In the meantime, should I resend this patchset (with the reset_device() change included) so that it can be reviewed and committed while I'm busy with ddraw (and send the ddraw tests in a separate patch), or is this patchset unacceptable until I include the ddraw tests? Thanks, Sam
Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
On 1 April 2013 16:56, Sam Edwards wrote: > In the meantime, should I resend this patchset (with the reset_device() > change included) so that it can be reviewed and committed while I'm busy > with ddraw (and send the ddraw tests in a separate patch), or is this > patchset unacceptable until I include the ddraw tests? > I wouldn't go so far as to say it's unacceptable without the ddraw tests, but I do think it would be preferred to submit them in the same set. For what it's worth, I don't think the ddraw tests have to be particularly complicated, you'd essentially just add a SetCooperativeLevel(..., DDSCL_NORMAL); call and then test that the style flags are unchanged from their initial values.
Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
On 1 April 2013 02:40, Sam Edwards wrote: > I opted not to write ddraw tests. The existing ddraw window style tests > suggest that DirectDraw doesn't even set WS_VISIBLE when initializing a > (non-visible) window, which is very odd, so any new tests would have been > todo_wine anyway. Nonetheless, my changes to wined3d are minimal and > shouldn't affect ddraw's behavior. > I think it's ok for the tests to be todo_wine, but we do want ddraw coverage for this in the tests. > +ZeroMemory( &d3dpp, sizeof(d3dpp) ); > +d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; > +d3dpp.Windowed = TRUE; > +d3dpp.BackBufferWidth = screen_width / 2; > +d3dpp.BackBufferHeight = screen_height / 2; > +hr = IDirect3DDevice9_Reset(device, &d3dpp); > +ok(hr == D3D_OK, "IDirect3DDevice9_Reset failed with %08x\n", hr); I think you'll want to use reset_device() here. (Although I also just notice 766e732fb changed that to use screen_width x screen_height instead of 640x480, which is perhaps a bit of an unfortunate choice. It's fine to change reset_device() to use screen_width / 2 x screen_height / 2, if needed.)
Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
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 http://testbot.winehq.org/JobDetails.pl?Key=24396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] windowscodecs: Test conversions of the 24bpp PixelFormats
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 http://testbot.winehq.org/JobDetails.pl?Key=23739 Your paranoid android. === W2K8SE (32 bit converter) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
Vincent Povirk wrote: > I guess I prefer to keep interfaces as simple as possible even if it > means writing more code? I'd consider writing a helper function, but > none of the other methods would use it. Is there any hurry with CreateBitmapFromMemory implementation, or you somehow prefer your own one? I'm asking because I was planning to send my implementation (fixed to create a copy of the passed in buffer) after new year vacations, but it looks like you need it right now. -- Dmitry.
Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
On Wed, Jan 2, 2013 at 11:42 PM, Dmitry Timoshkov wrote: > It's better to actually check return value of IWICBitmapLock_GetDataPointer > before memecpy(), or if that's not supposed to fail drop 'hr' assignment. Whoops, good catch. (I don't think it can fail, but I didn't mean to make that assumption.) I guess I prefer to keep interfaces as simple as possible even if it means writing more code? I'd consider writing a helper function, but none of the other methods would use it.
Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
Vincent Povirk wrote:
> +hr = IWICBitmap_Lock(bitmap, NULL, WICBitmapLockWrite, &lock);
> +if (SUCCEEDED(hr))
> +{
> +UINT buffersize;
> +BYTE *buffer;
> +
> +hr = IWICBitmapLock_GetDataPointer(lock, &buffersize, &buffer);
> +
> +memcpy(buffer, pbBuffer, uiHeight * cbStride);
> +
> +IWICBitmapLock_Release(lock);
> +}
It's better to actually check return value of IWICBitmapLock_GetDataPointer
before memecpy(), or if that's not supposed to fail drop 'hr' assignment.
My approach to pass buffer directly to BitmapImpl_Create looks much simpler
than fiddling with IWICBitmap_Lock IMHO.
--
Dmitry.
Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
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 http://testbot.winehq.org/JobDetails.pl?Key=23710 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
[3/4] gdiplus: Always use AlphaBlend to draw to 32-bit DIB's.
From c785203469fe96df081c5b0812d64699ec8f4f2f Mon Sep 17 00:00:00 2001
From: Vincent Povirk
Date: Wed, 5 Dec 2012 13:15:25 -0600
Subject: [PATCH 3/4] gdiplus: Always use AlphaBlend to draw to 32-bit DIB's.
---
dlls/gdiplus/gdiplus_private.h |1 +
dlls/gdiplus/graphics.c| 19 ++-
dlls/gdiplus/tests/graphics.c |2 +-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h
index 4a8b10a..cb7330e 100644
--- a/dlls/gdiplus/gdiplus_private.h
+++ b/dlls/gdiplus/gdiplus_private.h
@@ -152,6 +152,7 @@ struct GpGraphics{
HDC hdc;
HWND hwnd;
BOOL owndc;
+BOOL alpha_hdc;
GpImage *image;
SmoothingMode smoothing;
CompositingQuality compqual;
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
index 247b17d..4474db6 100644
--- a/dlls/gdiplus/graphics.c
+++ b/dlls/gdiplus/graphics.c
@@ -2250,6 +2250,8 @@ GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics
**graphics)
GpStatus WINGDIPAPI GdipCreateFromHDC2(HDC hdc, HANDLE hDevice, GpGraphics
**graphics)
{
GpStatus retval;
+HBITMAP hbitmap;
+DIBSECTION dib;
TRACE("(%p, %p, %p)\n", hdc, hDevice, graphics);
@@ -2274,6 +2276,13 @@ GpStatus WINGDIPAPI GdipCreateFromHDC2(HDC hdc, HANDLE
hDevice, GpGraphics **gra
return retval;
}
+hbitmap = GetCurrentObject(hdc, OBJ_BITMAP);
+if (hbitmap && GetObjectW(hbitmap, sizeof(dib), &dib) == sizeof(dib) &&
+dib.dsBmih.biBitCount == 32 && dib.dsBmih.biCompression == BI_RGB)
+{
+(*graphics)->alpha_hdc = 1;
+}
+
(*graphics)->hdc = hdc;
(*graphics)->hwnd = WindowFromDC(hdc);
(*graphics)->owndc = FALSE;
@@ -3157,7 +3166,7 @@ GpStatus WINGDIPAPI GdipDrawImagePointsRect(GpGraphics
*graphics, GpImage *image
graphics->scale, image->xres, image->yres, bitmap->format,
imageAttributes ? imageAttributes->outside_color : 0);
-if (imageAttributes ||
+if (imageAttributes || graphics->alpha_hdc ||
(graphics->image && graphics->image->type == ImageTypeBitmap) ||
ptf[1].Y != ptf[0].Y || ptf[2].X != ptf[0].X ||
ptf[1].X - ptf[0].X != srcwidth || ptf[2].Y - ptf[0].Y !=
srcheight ||
@@ -4021,7 +4030,7 @@ GpStatus WINGDIPAPI GdipFillPath(GpGraphics *graphics,
GpBrush *brush, GpPath *p
if(graphics->busy)
return ObjectBusy;
-if (!graphics->image)
+if (!graphics->image && !graphics->alpha_hdc)
stat = GDI32_GdipFillPath(graphics, brush, path);
if (stat == NotImplemented)
@@ -4359,7 +4368,7 @@ GpStatus WINGDIPAPI GdipFillRegion(GpGraphics* graphics,
GpBrush* brush,
if(graphics->busy)
return ObjectBusy;
-if (!graphics->image)
+if (!graphics->image && !graphics->alpha_hdc)
stat = GDI32_GdipFillRegion(graphics, brush, region);
if (stat == NotImplemented)
@@ -5982,7 +5991,7 @@ GpStatus WINGDIPAPI GdipGetDC(GpGraphics *graphics, HDC
*hdc)
{
stat = METAFILE_GetDC((GpMetafile*)graphics->image, hdc);
}
-else if (!graphics->hdc ||
+else if (!graphics->hdc || graphics->alpha_hdc ||
(graphics->image && graphics->image->type == ImageTypeBitmap &&
((GpBitmap*)graphics->image)->format & PixelFormatAlpha))
{
/* Create a fake HDC and fill it with a constant color. */
@@ -6626,7 +6635,7 @@ static GpStatus draw_driver_string(GpGraphics *graphics,
GDIPCONST UINT16 *text,
if (length == -1)
length = strlenW(text);
-if (graphics->hdc &&
+if (graphics->hdc && !graphics->alpha_hdc &&
((flags & DriverStringOptionsRealizedAdvance) || length <= 1) &&
brush->bt == BrushTypeSolidColor &&
(((GpSolidFill*)brush)->color & 0xff00) == 0xff00)
diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
index 553e77f..f4e7ffa 100644
--- a/dlls/gdiplus/tests/graphics.c
+++ b/dlls/gdiplus/tests/graphics.c
@@ -4115,7 +4115,7 @@ static void test_alpha_hdc(void)
status = GdipGraphicsClear(graphics, 0xffaa);
expect(Ok, status);
-todo_wine expect(0xffaa, bits[0]);
+expect(0xffaa, bits[0]);
SelectObject(hdc, old_hbm);
--
1.7.10.4
Re: [PATCH 3/4] [cmd] Add support for NUL in copy
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 http://testbot.winehq.org/JobDetails.pl?Key=23016 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:312: Test failed: unexpected char 0x53 position 0 in line 419 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on a.a [7]') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 420 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on b.b [8]') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 421 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on a.a [7]') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 422 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on b.b [8]') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 423 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on a.a [7]') batch.c:312: Test failed: unexpected char 0x53 position 0 in line 424 (got 'Skipping file size check on NT4', wanted 'Passed: file size check on subdir\a.a [8]') batch.c:312: Test failed: unexpected char 0x68 position 0 in line 866 (got 'h=%h i=a j=b k=c l=e m= o=%o', wanted 'h=%h i=a j=b k=c l=e m=%m o=%o') batch.c:312: Test failed: unexpected char 0x68 position 0 in line 868 (got 'h=%h i=a j=b k=c l=d e f g m= n=%n o=%o', wanted 'h=%h i=a j=b k=c l=d e f g m=%m n=%n o=%o') batch.c:312: Test failed: unexpected char 0x68 position 0 in line 869 (got 'h=%h i=a j=c k= l= m= n=%n o=%o', wanted 'h=%h i=a j=c k= l= m=%m n=%n o=%o') batch.c:312: Test failed: unexpected char 0x68 position 0 in line 870 (got 'h=%h i=b j=c k= l= m= n=%n o=%o', wanted 'h=%h i=b j=c k= l= m=%m n=%n o=%o') batch.c:312: Test failed: unexpected char 0x68 position 0 in line 871 (got 'h=%h i=b j=c k= l= m= n=%n o=%o', wanted 'h=%h i=b j=c k= l= m=%m n=%n o=%o')
Re: [PATCH 3/4] msvcp90: in istream<>::tellg don't use sentry
On 10/30/12 10:16 PM, Daniel Lehman wrote: +tpos.pos = 0xdeadbeefdeadbeef; Long long constants are not supported in C89. You can use 0xdeadbeef here.
Re: [3/4] comctl32: fix notifications and return value when collapsing already collapsed node (rebased)
Hello, Nikolay. Thanks for reminder. Attached it now. 2012/10/15 Nikolay Sivov : > Hi, Daniel. > > You forgot a patch. >
Re: [3/4] comctl32: fix notifications and return value when collapsing already collapsed node (rebased)
Hi, Daniel. You forgot a patch.
Re: [3/4] shell32/tests: Simplify shlexec's test_argify() and test_lpFile_parsed() and avoid numeric literals.
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 http://testbot.winehq.org/JobDetails.pl?Key=22056 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] ole32: Move the propvariant serialization into a helper function.
Vincent Povirk writes: > From eb900b2807167f25ad8f4e97c558dec8b71b070c Mon Sep 17 00:00:00 2001 > From: Vincent Povirk > Date: Thu, 4 Oct 2012 16:58:48 -0500 > Subject: [PATCH 3/4] ole32: Move the propvariant serialization into a helper > function. It doesn't work here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so suminfo.c && touch suminfo.ok suminfo.c:441: Test succeeded inside todo block: value incorrect suminfo.c:450: Test failed: MsiSummaryInfoSetProperty failed 0 make: *** [suminfo.ok] Error 2 -- Alexandre Julliard julli...@winehq.org
Re: [3/4] dxgi: Avoid division by zero. Based on patch by Eduard - Gabriel Munteanu.
On 23 September 2012 22:40, Ričardas Barkauskas wrote: > +static UINT dxgi_rational_to_uint(DXGI_RATIONAL *rational) "rational" should be const.
Re: [3/4] windowscodecs: Implement Image Descriptor metadata reader.
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 http://testbot.winehq.org/JobDetails.pl?Key=21584 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] gdiplus: Destination points passed to GdipDrawImagePointsRect should be in device units.
Dmitry Timoshkov wrote: > +scale_x = units_scale(srcUnit, graphics->unit, graphics->xres); > +scale_y = units_scale(srcUnit, graphics->unit, graphics->yres); This depends on a not yet sent series which introduces units_scale(), please ignore for now, I'll resend it a bit later. -- Dmitry.
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.
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 http://winetestbot.dolphin/JobDetails.pl?Key=158 Your paranoid android. === debiantesting (build) === Patch failed to apply
Re: [PATCH 3/4] vbscript: Fixed function return crossing for loop
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 http://winetestbot.dolphin/JobDetails.pl?Key=154 Your paranoid android. === debiantesting (build) === Patch failed to apply
Re: [PATCH 3/4] d3dx9/tests: Add effect parameter value SetMatrixPointerArray() test.
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 http://winetestbot.dolphin/JobDetails.pl?Key=147 Your paranoid android. === debiantesting (build) === Patch failed to apply
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
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 http://winetestbot.dolphin/JobDetails.pl?Key=100 Your paranoid android. === debiantesting (build) === Patch failed to apply
Re: [PATCH 3/4] d3dx9/tests: Add effect parameter value GetMatrixPointerArray() test.
Am 09.07.2012 16:17, schrieb Matteo Bruni:
2012/7/8 Rico Schüller:
---
dlls/d3dx9_36/tests/effect.c | 90
++
1 files changed, 90 insertions(+), 0 deletions(-)
Hi Rico,
maybe it's just me misunderstanding this, but:
+FLOAT fvalue[EFFECT_PARAMETER_VALUE_ARRAY_SIZE];
+D3DXMATRIX *matrix_pointer_array[sizeof(fvalue)/sizeof(D3DXMATRIX)];
+UINT l, k, m, element;
+
+for (element = 0; element<= res_desc->Elements + 1; ++element)
+{
+memset(fvalue, 0xab, sizeof(fvalue));
+for (l = 0; l< element; ++l)
+{
+matrix_pointer_array[l] = (D3DXMATRIX *)&fvalue[l *
sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)];
+}
I don't quite understand what you're trying to achieve with
"sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)". As
far as I can see, that depends on the size of the pointer (32/64 bits)
and I'm not sure that the offset should change in that case. Maybe you
meant to use sizeof(float) as divisor?
Hi Matteo,
yes, the array increment has to be constantly 16. So sizeof(FLOAT) is
correct. Thanks for the hint, it needs to be corrected in some other
cases, too. I'll send some new patches to fix the issues.
Cheers
Rico
Re: [PATCH 3/4] ieframe: Added init_test helper
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 http://testbot.winehq.org/JobDetails.pl?Key=19864 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3476: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3325: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3441: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3419: Test failed: Could not get WebBrowserV1 instance: 80040154 webbrowser: unhandled exception c005 at 0040AF8E === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2627: Test failed: expected GetOverridesKeyPath webbrowser.c:2632: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2633: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3052: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402FCA
Re: [PATCH 3/4] d3dx9/tests: Add effect parameter value GetMatrixPointerArray() test.
2012/7/8 Rico Schüller :
> ---
> dlls/d3dx9_36/tests/effect.c | 90
> ++
> 1 files changed, 90 insertions(+), 0 deletions(-)
>
Hi Rico,
maybe it's just me misunderstanding this, but:
+FLOAT fvalue[EFFECT_PARAMETER_VALUE_ARRAY_SIZE];
+D3DXMATRIX *matrix_pointer_array[sizeof(fvalue)/sizeof(D3DXMATRIX)];
+UINT l, k, m, element;
+
+for (element = 0; element <= res_desc->Elements + 1; ++element)
+{
+memset(fvalue, 0xab, sizeof(fvalue));
+for (l = 0; l < element; ++l)
+{
+matrix_pointer_array[l] = (D3DXMATRIX *)&fvalue[l *
sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)];
+}
I don't quite understand what you're trying to achieve with
"sizeof(**matrix_pointer_array) / sizeof(*matrix_pointer_array)". As
far as I can see, that depends on the size of the pointer (32/64 bits)
and I'm not sure that the offset should change in that case. Maybe you
meant to use sizeof(float) as divisor?
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.
Marvin wrote: > === WINEBUILD (build) === > Patch failed to apply Either the testbot needs to reset its incoming queue once a day, or mail delivery problems for patch batches in winehq should be fixed. -- Dmitry.
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.
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 http://testbot.winehq.org/JobDetails.pl?Key=19764 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH 3/4] vbscript: Fixed function return crossing for loop
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 http://testbot.winehq.org/JobDetails.pl?Key=19753 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
Ben Peddell wrote: > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > > delivery problem in the mailing list software, and it is getting pretty > > annoying. > > > > The winehq.org mailserver only allows one SMTP connection per relaying > IP, so emails sent at the same time are likely to be received out of > order unless the relaying mailserver only transfers emails sequentially. It doesn't explain the lost of some e-mails. For instance patch tracker may see 2 of 5 patches while http://www.winehq.org/pipermail/wine-patches lists 3 of 5. -- Dmitry.
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
On 27/06/2012 7:35 PM, Dmitry Timoshkov wrote: > Marvin wrote: > >> === W7PROX64 (64 bit image) === >> image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 >> image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 >> image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 >> >> === TEST64_W7SP1 (64 bit image) === >> image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 >> image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 >> image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > delivery problem in the mailing list software, and it is getting pretty > annoying. > The winehq.org mailserver only allows one SMTP connection per relaying IP, so emails sent at the same time are likely to be received out of order unless the relaying mailserver only transfers emails sequentially. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
Dmitry Timoshkov wrote: > Marvin wrote: > > > === W7PROX64 (64 bit image) === > > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > > > === TEST64_W7SP1 (64 bit image) === > > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > delivery problem in the mailing list software, and it is getting pretty > annoying. Just in case sent precompiled version of the tests to testbot once again, and they passed: https://testbot.winehq.org/JobDetails.pl?Key=19596 -- Dmitry.
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
Marvin wrote: > === W7PROX64 (64 bit image) === > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > === TEST64_W7SP1 (64 bit image) === > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail delivery problem in the mailing list software, and it is getting pretty annoying. -- Dmitry.
Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.
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 http://testbot.winehq.org/JobDetails.pl?Key=19594 Your paranoid android. === W7PROX64 (64 bit image) === image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 === TEST64_W7SP1 (64 bit image) === image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 image.c:2811: Test failed: 3: expected property size 20 or 0, got 28
Re: [PATCH 3/4] qedit/tests: Add COM aggregation test for MediaDet.
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 http://testbot.winehq.org/JobDetails.pl?Key=19577 Your paranoid android. === WNT4WSSP6 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 === W2KPROSP4 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154
Re: [PATCH 3/4] qedit/tests: Add COM aggregation test for MediaDet.
Argh!
Please skip this patch, it is incomplete and just skips the rest of the
tests on Wine. I'll resubmit it when I implement COM aggregation for
MediaDet. Patch 4/4 can be still applied as it doesn't depends on this.
bye
michael
On 06/26/2012 11:53 PM, Michael Stefaniuc wrote:
> ---
> dlls/qedit/tests/mediadet.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/qedit/tests/mediadet.c b/dlls/qedit/tests/mediadet.c
> index 1d9a2f1..1d75680 100644
> --- a/dlls/qedit/tests/mediadet.c
> +++ b/dlls/qedit/tests/mediadet.c
> @@ -132,6 +132,7 @@ static BOOL init_tests(void)
> static void test_mediadet(void)
> {
> HRESULT hr;
> +struct unk_impl unk_obj = {{&unk_vtbl}, 19, NULL};
> IMediaDet *pM = NULL;
> BSTR filename = NULL;
> LONG nstrms = 0;
> @@ -141,6 +142,12 @@ static void test_mediadet(void)
> int flags;
> int i;
>
> +/* COM aggregation */
> +hr = CoCreateInstance(&CLSID_MediaDet, &unk_obj.IUnknown_iface,
> CLSCTX_INPROC_SERVER,
> +&IID_IUnknown, (void**)&unk_obj.inner_unk);
> +todo_wine ok(hr == S_OK, "CoCreateInstance failed: %08x\n", hr);
> +if (hr != S_OK) return;
> +
> /* test.avi has one video stream. */
> hr = CoCreateInstance(&CLSID_MediaDet, NULL, CLSCTX_INPROC_SERVER,
> &IID_IMediaDet, (LPVOID*)&pM);
Re: [PATCH 3/4] kernel32/tests: Add a IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) test
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 http://testbot.winehq.org/JobDetails.pl?Key=18926 Your paranoid android. === W2KPROSP4 (32 bit cdrom) === cdrom.c:84: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87
Re: [3/4] windowscodecs: Add test for IWICMetadataBlockReader interface.
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 http://testbot.winehq.org/JobDetails.pl?Key=18674 Your paranoid android. === WXPPROSP3 (32 bit metadata) === metadata: unhandled exception c005 at 4CCA826D === W2K8SE (32 bit metadata) === metadata: unhandled exception c005 at 72C28045
Re: [PATCH 3/4] shell32: Add IQueryInfo to more shellfolder
On 5/18/2012 14:06, Detlef Riekenberg wrote:
+} else if (IsEqualIID(riid,&IID_IQueryInfo)&& (cidl == 1)) {
+pidl = ILCombine (This->pidlRoot, apidl[0]);
+pObj = (IUnknown *) IQueryInfo_Constructor (pidl);
+SHFree (pidl);
+hr = S_OK;
} else {
Patch doesn't have a cast here, and looks really redundant. If you
really need that it's better to make IQueryInfo_Constructor look more
like class factory call - with HRESULT and void** parameter.
Also it looks like you always need to combine pidls and cleanup after
that, I think it's better to combine them in constructor and keep result
in QueryInfo impl. (instead of making a clone). So constructor could
look like "HRESULT constructor(root, pidl, pObj)".
Re: [PATCH 3/4] dmusic: COM cleanup of IReferenceClock.
2012/5/11 Nikolay Sivov
> On 5/11/2012 09:19, Christian Costa wrote:
>
>>
>> diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h
>> index 73a05d4..96334c9 100644
>> --- a/dlls/dmusic/dmusic_private.h
>> +++ b/dlls/dmusic/dmusic_private.h
>> @@ -167,13 +167,14 @@ extern HRESULT WINAPI DMUSIC_CreateDMSynthPort(**REFIID
>> riid, LPVOID *ppobj, LPUNK
>> * IReferenceClockImpl implementation structure
>> */
>> struct IReferenceClockImpl {
>> - /* IUnknown fields */
>> - const IReferenceClockVtbl *lpVtbl;
>> - LONG ref;
>> +/* IUnknown fields */
>> +IReferenceClock IReferenceClock_iface;
>>
>
> +const IReferenceClockVtbl *lpVtbl;
>>
> You forgot to remove that, right?
>
>>
>> Yes. Right ! :)
Re: [PATCH 3/4] dmusic: COM cleanup of IReferenceClock.
On 5/11/2012 09:19, Christian Costa wrote:
diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h
index 73a05d4..96334c9 100644
--- a/dlls/dmusic/dmusic_private.h
+++ b/dlls/dmusic/dmusic_private.h
@@ -167,13 +167,14 @@ extern HRESULT WINAPI DMUSIC_CreateDMSynthPort(REFIID
riid, LPVOID *ppobj, LPUNK
* IReferenceClockImpl implementation structure
*/
struct IReferenceClockImpl {
- /* IUnknown fields */
- const IReferenceClockVtbl *lpVtbl;
- LONG ref;
+/* IUnknown fields */
+IReferenceClock IReferenceClock_iface;
+const IReferenceClockVtbl *lpVtbl;
You forgot to remove that, right?
+LONG ref;
Re: [PATCH 3/4] amstream: Add stubbed implementation of DirectDrawStreamSample. (try 2) (resend)
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 http://testbot.winehq.org/JobDetails.pl?Key=18152 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH 3/4] ws2_32/tests: Test for AcceptEx IOCP behavior for a duplicated handle (try 2).
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 http://testbot.winehq.org/JobDetails.pl?Key=18137 Your paranoid android. === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: [PATCH 3/4] ws2_32/tests: Test for AcceptEx IOCP behavior for a duplicated handle.
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 http://testbot.winehq.org/JobDetails.pl?Key=18133 Your paranoid android. === WVISTAADM (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W2K8SE (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PRO (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: [PATCH 3/4] jscript: Added Number.toExpontential implementation
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 http://testbot.winehq.org/JobDetails.pl?Key=17956 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [3/4] server: Perform an access check for kernel objects without a security descriptor using access rights of the owner'
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 http://testbot.winehq.org/JobDetails.pl?Key=17911 Your paranoid android. === WVISTAADM (32 bit sync) === sync.c:923: Test failed: DeleteTimerQueueTimer
Re: [3/4] server: Perform an access check for kernel objects without a security descriptor using access rights of the owner'
Marvin wrote: > === WVISTAADM (32 bit sync) === > sync.c:923: Test failed: DeleteTimerQueueTimer This failure has nothing to do with that patch. -- Dmitry.
Re: [PATCH 3/4] d3drm: Implement IDirect3DRMFrameX_GetParent and update tests. (resend)
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 http://testbot.winehq.org/JobDetails.pl?Key=17839 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH 3/4] d3drm: Implement IDirect3DRMFrameX_GetParent and update tests. (resend)
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 http://testbot.winehq.org/JobDetails.pl?Key=17832 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH 3/4] winspool/tests: Add some tests for OpenPrinter with non-NULL defaults.
On Tue, Apr 03, 2012 at 12:50:18PM +0200, Marvin wrote: > === WINEBUILD (build) === > Can't determine base name A winspool vs winspool.drv thing perhaps? Huw.
Re: [PATCH 3/4] winspool/tests: Add some tests for OpenPrinter with non-NULL defaults.
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 http://testbot.winehq.org/JobDetails.pl?Key=17661 Your paranoid android. === WINEBUILD (build) === Can't determine base name
Re: [PATCH 3/4] mmdevapi/tests: Perform renderer padding & position tests.
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 http://testbot.winehq.org/JobDetails.pl?Key=16887 Your paranoid android. === WVISTAADM (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W2K8SE (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PRO (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 === W7PROX64 (32 bit render) === render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffer failed: 88890007 render.c:980: Test failed: ReleaseBuffer failed: 80070057 render.c:1003: Test failed: Position 0 vs. last 0 render.c:1066: Test failed: Reset failed: 8889000b render.c:1070: Test failed: Reset on a resetted stream returns 8889000b render.c:1079: Test failed: GetBuffer failed: 88890007 render.c:1084: Test failed: ReleaseBuffer failed: 80070057 render.c:1105: Test failed: Position 0 vs. last 0 render.c:1137: Test failed: Reset failed: 8889000b render.c:1144: Test failed: Reset on a resetted stream returns 8889000b render.c:1152: Test failed: GetBuffe
Re: [PATCH 3/4] ddraw/tests: Add an IDirect3DTexture2::Load color key test
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 http://testbot.winehq.org/JobDetails.pl?Key=16746 Your paranoid android. === W7PROX64 (64 bit ddraw4) === ddraw4.c:1247: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. ddraw4.c:1249: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. Timeout === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1247: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. ddraw4.c:1249: Test failed: Failed to get Direct3DTexture2 interface, hr 0x80004002. Timeout
Re: [3/4] ddraw: Set correct HEL and HAL color models
Am Samstag, 10. Dezember 2011, 22:26:34 schrieb Stefan Dösinger: > This looks strange. The system doesn't support hardware d3d, since the > CreateDevice calls for HAL and HW T&L HAL calls fail, but it still > enumerates them. I guess adding a broken() is the way to go. > > I'll send a patch next week. I just noticed that I never sent the promised patch. Can you file bugs for those issues next time and assign them to me? A bugtracker is a better way to keep track of things than my poorly organized inbox. signature.asc Description: This is a digitally signed message part.
Re: [3/4] ddraw: Set correct HEL and HAL color models
Am Samstag, 10. Dezember 2011, 18:44:32 schrieb Saulius Krasuckas: > Stefan, > > it looks like your patch > http://source.winehq.org/git/wine.git/commitdiff/9e0baa55cec232656048c972e94 > a9dc2a15ec30b > > has introduced 2 failures on one virtual w2k3-vmware machine: > http://test.winehq.org/data/e7bbb4ef1e95396b72a58f813b4346d9abccb699/2003_wt > b-w2k3r2sex64-32/ddraw:d3d.html This looks strange. The system doesn't support hardware d3d, since the CreateDevice calls for HAL and HW T&L HAL calls fail, but it still enumerates them. I guess adding a broken() is the way to go. I'll send a patch next week.
Re: [3/4] ddraw: Set correct HEL and HAL color models
Stefan, it looks like your patch http://source.winehq.org/git/wine.git/commitdiff/9e0baa55cec232656048c972e94a9dc2a15ec30b has introduced 2 failures on one virtual w2k3-vmware machine: http://test.winehq.org/data/e7bbb4ef1e95396b72a58f813b4346d9abccb699/2003_wtb-w2k3r2sex64-32/ddraw:d3d.html See earlier results: http://test.winehq.org/data/tests/ddraw:d3d.html Would you mind fixing this, please:)? S.
Re: [3/4] winemaker: Be less picky when detecting the target type (try 2)
Am 19.11.2011 20:18, schrieb Vitaliy Margolen:
> On 11/19/2011 11:42 AM, André Hentschel wrote:
>> this catches more than one 0 after the space and possible 0s after the x
>> +if (/[[:space:]]0+x0*101$/) {
> For more then one you should use "+" not "*". "*" means any number, including
> 0.
>
> Vitaliy
So i used:
+ before "x" to match at least one 0, but don't complain if it's more than one
like "00x0101"
* after "x" to match no 0 like in "00x101" or expect much more like in
"00x0101" or maybe something like "0x0099"
that's what i meant with "possible 0s"
--
Best Regards, André Hentschel
Re: [3/4] winemaker: Be less picky when detecting the target type (try 2)
On 11/19/2011 11:42 AM, André Hentschel wrote:
this catches more than one 0 after the space and possible 0s after the x
+if (/[[:space:]]0+x0*101$/) {
For more then one you should use "+" not "*". "*" means any number, including 0.
Vitaliy
Re: [3/4] ddraw: Add more tests and fixes for SetSurfaceDesc
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 http://testbot.winehq.org/JobDetails.pl?Key=15326 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/4/2011 20:21, Jacek Caban wrote:
On 11/04/11 17:11, Nikolay Sivov wrote:
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic
and typelib-based values, then you could simply return whatever
invoke returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
It really depends on how it's used in msxml3.
The only case I'm aware of so far is index based access of collection
elements, that's all. So I'll better go with DISP_E_UNKNOWNNAME for now
cause use of this thing is really limited in msxml.
The problem with this solution is that it means more code in every
object using custom dipids. If we can avoid it, even at cost of more
complicated code in dispex.c, that's probably better in terms of code
maintaining IMO.
Right, extra call is too much probably.
Jacek
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/04/11 17:11, Nikolay Sivov wrote:
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke
returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
It really depends on how it's used in msxml3. The problem with this
solution is that it means more code in every object using custom dipids.
If we can avoid it, even at cost of more complicated code in dispex.c,
that's probably better in terms of code maintaining IMO.
Jacek
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke
returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
Jacek
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid, wFlags, pdp,
pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke returns.
Jacek
Re: [3/4] d3d9/tests: Test partial block locks
On Monday 31 October 2011 21:10:41 Henri Verbeet wrote:
> On 31 October 2011 20:03, Stefan Dösinger wrote:
> > +case D3DPOOL_SCRATCH:
> > +case D3DPOOL_SYSTEMMEM:
> > +hr =
> > IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128,
> > formats[i].fmt, +D3DPOOL_SCRATCH, &surface,
> > 0);
>
> That doesn't really test D3DPOOL_SYSTEMMEM.
That was a pretty simple change, but when I re-ran the tests on Windows to be
sure they work the ATI2N test failed.
On Nvidia drivers ATI2N has 4x4 blocks, which makes sense, but if you violate
that the driver returns E_INVALIDARG instead of D3DERR_INVALIDCALL. Oh well.
On AMD, ATI2N has 2x2 blocks, which doesn't make sense to me. When I ran the
tests on Windows the last time the 1x1 "blocks" locked fine. I couldn't
reproduce that even with the last version of my patch.
I've changed the test and implementation according to those results, but
before I resubmit them I'll test a few more Windows machines(especially dx9
and xp based ones).
What's changed:
*) block_size removed, this was unused
*) Improved messages, print the pool
*) Use block_dimensions / 2 instead of block_dimensions - 1 to construct
invalid blocks.
*) Adjusted test to 2x2 / 4x4 ATI2N block sizes
From 98f5f0f70f09a501ea6d236047f70d777d0c2eae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20D=C3=B6singer?=
Date: Fri, 14 Oct 2011 12:54:37 +0200
Subject: [PATCH 03/13] d3d9/tests: Test partial block locks
---
dlls/d3d9/tests/surface.c | 171 +
1 files changed, 171 insertions(+), 0 deletions(-)
diff --git a/dlls/d3d9/tests/surface.c b/dlls/d3d9/tests/surface.c
index 361e8a3..70ae71a 100644
--- a/dlls/d3d9/tests/surface.c
+++ b/dlls/d3d9/tests/surface.c
@@ -633,6 +633,176 @@ static void test_surface_double_unlock(IDirect3DDevice9 *device)
}
}
+static void test_surface_lockrect_blocks(IDirect3DDevice9 *device)
+{
+IDirect3DTexture9 *texture;
+IDirect3DSurface9 *surface;
+IDirect3D9 *d3d;
+D3DLOCKED_RECT locked_rect;
+unsigned int i, j;
+HRESULT hr;
+RECT rect;
+BOOL surface_only;
+
+const struct
+{
+D3DFORMAT fmt;
+const char *name;
+unsigned int block_width;
+unsigned int block_height;
+BOOL broken;
+}
+formats[] =
+{
+{D3DFMT_DXT1, "D3DFMT_DXT1", 4, 4, FALSE},
+{D3DFMT_DXT2, "D3DFMT_DXT2", 4, 4, FALSE},
+{D3DFMT_DXT3, "D3DFMT_DXT3", 4, 4, FALSE},
+{D3DFMT_DXT4, "D3DFMT_DXT4", 4, 4, FALSE},
+{D3DFMT_DXT5, "D3DFMT_DXT5", 4, 4, FALSE},
+/* ATI2N has 2x2 blocks on AMD drivers, which doesn't make sense. */
+{MAKEFOURCC('A','T','I','2'), "ATI2N", 4, 4, TRUE},
+};
+static const struct
+{
+D3DPOOL pool;
+const char *name;
+/* Don't check the return value, Nvidia returns D3DERR_INVALIDCALL for some formats
+ * and E_INVALIDARG/DDERR_INVALIDPARAMS for others. */
+BOOL success;
+}
+pools[] =
+{
+{D3DPOOL_DEFAULT, "D3DPOOL_DEFAULT", FALSE},
+{D3DPOOL_SCRATCH, "D3DPOOL_SCRATCH", TRUE},
+{D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM",TRUE},
+{D3DPOOL_MANAGED, "D3DPOOL_MANAGED", TRUE},
+};
+
+hr = IDirect3DDevice9_GetDirect3D(device, &d3d);
+ok(SUCCEEDED(hr), "IDirect3DDevice9_GetDirect3D failed (%08x)\n", hr);
+
+for (i = 0; i < (sizeof(formats) / sizeof(*formats)); ++i) {
+surface_only = FALSE;
+hr = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, D3DUSAGE_DYNAMIC,
+D3DRTYPE_TEXTURE, formats[i].fmt);
+if (FAILED(hr))
+{
+hr = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0, D3DRTYPE_SURFACE, formats[i].fmt);
+if (FAILED(hr))
+{
+skip("Format %s not supported, skipping lockrect offset test\n", formats[i].name);
+continue;
+}
+surface_only = TRUE;
+}
+
+for (j = 0; j < (sizeof(pools) / sizeof(*pools)); j++)
+{
+switch (pools[j].pool)
+{
+case D3DPOOL_SYSTEMMEM:
+case D3DPOOL_MANAGED:
+if (surface_only) continue;
+/* Fall through */
+case D3DPOOL_DEFAULT:
+if (surface_only)
+{
+hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt,
+pools[j].pool, &surface, 0);
+ok(SUCCEEDED(hr), "IDirect3DDevice9_CreateOffscreenPlainSurface failed (%08x)\n", hr);
+}
+else
+{
+hr = IDirect3DD
Re: [3/4] d3d9/tests: Test partial block locks
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 http://testbot.winehq.org/JobDetails.pl?Key=15192 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] d3d9/tests: Test partial block locks
On 31 October 2011 20:03, Stefan Dösinger wrote: > +case D3DPOOL_SCRATCH: > +case D3DPOOL_SYSTEMMEM: > +hr = > IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > +D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.
Re: [3/4] wined3d: reject ffp blits if the destination is not fbo attachable
On 11 October 2011 22:30, Stefan Dösinger wrote:
> +if (wined3d_settings.offscreen_rendering_mode == ORM_FBO)
> +{
> +if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) ||
> (dst_usage & WINED3DUSAGE_RENDERTARGET)))
> +return FALSE;
> +}
> +else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET))
> +{
> +return FALSE;
> +}
Same consideration as for 2/4. Guess I should have caught this when
bccfd7cc introduced it.
Re: mshtml: Add IHTMLCurrentStyle2/3/4 support
Alistair Leslie-Hughes writes: > diff --git a/dlls/mshtml/Makefile.in b/dlls/mshtml/Makefile.in > index 3933645..62a2d6f 100644 > --- a/dlls/mshtml/Makefile.in > +++ b/dlls/mshtml/Makefile.in > @@ -14,6 +14,7 @@ C_SRCS = \ > htmlbody.c \ > htmlcomment.c \ > htmlcurstyle.c \ > + htmlcurstyle2.c \ Please add this to the existing file. There are already way too many source files in this dll. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
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 http://testbot.winehq.org/JobDetails.pl?Key=12805 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found
Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
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 http://testbot.winehq.org/JobDetails.pl?Key=12778 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 3/4] shell32: Add IKnownFolder::SetPath() implementation
Please, ignore this single patch. This function should be implemented in other way (using redirection feature, the thing I am working on but did not submit yet). W dniu 23.06.2011 18:50, Mariusz Pluciński pisze: --- dlls/shell32/shellpath.c | 32 ++-- dlls/shell32/tests/shellpath.c |3 +-- 2 files changed, 31 insertions(+), 4 deletions(-) -- Best regards Mariusz Pluciński
Re: [PATCH 3/4] d3dx9: Implement ID3DXBaseEffect::GetPixelShader().
2011/5/3 Rico Schüller : > +#define SAFE_ADDREF(x) if(x) IUnknown_AddRef(x) > +#define SAFE_RELEASE(x) if(x) IUnknown_Release(x) That's not so safe, actually. Consider e.g. what happens when "x" has side effects, or when you write something like "if (cond) SAFE_ADDREF(x); else return;". If you really want this an inline function should do just as well, but for the handful of uses I see in this series it just obfuscates the code.
Re: [PATCH 3/4] dsound: Implement capture buffer based on mmdevapi, try 2
It would be nice if you used more descriptive variable names. For example:
+struct IDirectSoundCaptureBufferImpl
+{
+DWORD buf_size;
+DWORD pos;
What units are these sizes and positions in? Frames? Bytes? Time? What
position is being represented here, read, write, or something else?
Using more descriptive names helps when understanding and verifying code
like this:
+pos1 = This->pos;
+if (This->playing)
+{
+pos2 = This->format->nSamplesPerSec / 100;
+pos2 *= This->format->nBlockAlign;
+pos2 += pos1;
+if (!This->looping && pos2 > This->buf_size)
+pos2 = 0;
+else
+pos2 %= This->buf_size;
+}
+else
+pos2 = pos1;
+pos2 %= This->buf_size;
Are all of these positions in Bytes? I hope so... (Remember this has
tripped things up in the past, see bbbf72ddcb). If everything is always
in bytes, maybe make a note of that near the variable declarations, and
then verify that it's true throughout the code. Also, why is pos1 a
separate variable here?
These patches are all missing quite a lot of error handling, which
really makes me hesitate. Especially on some important calls:
+IAudioCaptureClient_GetBuffer(buf->cap_dev, &data, &read,
&flags, &pos, 0);
+IAudioClient_GetDevicePeriod(This->dev, &default_period, &min_period);
+IAudioClient_Start(This->dev);
Knowing when these functions fail will help debugging if something goes
wrong. Much worse to suddenly crash four function calls later due to
invalid default_period value than to just error out appropriately when
the error occurs.
This doesn't matter a whole lot, but I think it would be more clear to
use a separate object here, instead of a separate refcount:
struct IDirectSoundCaptureBufferImpl
{
IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface;
-LONG ref;
+IDirectSoundNotify IDirectSoundNotify_iface;
+LONG ref, notify_ref;
If not, at least a comment explaining why two refcounts are needed.
Obviously a test would improve it even more, if one doesn't already exist.
Re: [PATCH 3/4] comdlg32: Add implementation of DllRegisterServer/DllUnregisterServer. (resend)
David Hedberg writes: > @@ -274,3 +277,82 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID > riid, void **ppv) > > return CLASS_E_CLASSNOTAVAILABLE; > } > + > +/*** > + * Register/Unregister DLL, based on shdocvw/factory.c > + */ You should use the new IRegistrar mechanism instead. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 3/4] mshtml: Added IHTMLPrivateWindow_GetAddressBarUrl implementation
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 http://testbot.winehq.org/JobDetails.pl?Key=9859 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === WVISTAADM (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PRO (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (64 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace"
Re: [PATCH 3/4] urlmon: Properly handle BINDSTATUS_BEGINDOWNLOADDATA.
On 2/15/11 5:13 PM, Marvin wrote: 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 http://testbot.winehq.org/JobDetails.pl?Key=9273 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 I don't believe it's related, it seems like a random failure. It passed clearly here: http://testbot.winehq.org/JobDetails.pl?Key=9269&log_226=1#k226 and sometimes fails in regular winetest run: http://test.winehq.org/data/a24e8c8f0bd3924cc72501007eaaee10349c6c93/win7_wtb-w7pro/urlmon:protocol.html Tried also on my Windows 7 Professional, but I couldn't reproduce those failures, even after multiple runs. E:\jhakonen\Downloads>urlmon_test64.exe protocol protocol.c:2544: Testing file protocol... protocol.c:2897: Testing http protocol (not from urlmon)... protocol.c:2901: Testing http protocol (from urlmon)... protocol.c:2905: Testing http protocol (to file)... protocol.c:2909: Testing http protocol (post data)... protocol.c:2915: Testing http protocol (post data stream)... protocol.c:2918: Testing http protocol (direct read)... protocol.c:2922: Testing http protocol (redirected)... protocol.c:2926: Testing http protocol abort... protocol.c:2939: Testing https protocol (from urlmon)... protocol.c:2959: Testing ftp protocol... protocol.c:3042: Testing gopher protocol... protocol.c:3084: Testing mk protocol... protocol.c:3158: Testing CreateBinding... protocol.c:3516: Testing file binding (mime verification, emulate prot)... protocol.c:3518: Testing http binding (mime verification, emulate prot)... protocol.c:3520: Testing its binding (mime verification, emulate prot)... protocol.c:3522: Testing http binding (mime verification, emulate prot, short read, direct read)... protocol.c:3524: Testing file binding (mime verification, emulate prot, mime filter)... protocol.c:3526: Testing http binding (mime verification, emulate prot, mime filter)... protocol.c:3528: Testing http binding (mime verification, emulate prot, direct read)... protocol.c:3530: Testing http binding (mime verification, emulate prot, abort)... protocol.c:3533: Testing file binding (use IUri, mime verification, emulate prot)... protocol.c:3535: Testing file binding (use IUri, impl StartEx, mime verification, emulate prot)... protocol.c:3537: Testing file binding (impl StartEx, mime verification, emulate prot)... protocol: 5135 tests executed (0 marked as todo, 0 failures), 0 skipped. Best Regards, Janne Hakonen
Re: [PATCH 3/4] urlmon: Properly handle BINDSTATUS_BEGINDOWNLOADDATA.
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 http://testbot.winehq.org/JobDetails.pl?Key=9273 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 protocol.c:278: Test failed: Expected ERRO
Re: [PATCH 3/4] urlmon: Properly handle BINDSTATUS_BEGINDOWNLOADDATA.
On 2/15/11 5:13 PM, Marvin wrote: 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 http://testbot.winehq.org/JobDetails.pl?Key=9273 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:278: Test failed: Expected ERROR_INTERNET_SEC_CERT_REV_FAILED got 12045 I don't believe it's related, it seems like a random failure. It passed clearly here: http://testbot.winehq.org/JobDetails.pl?Key=9269&log_226=1#k226 and sometimes fails in regular winetest run: http://test.winehq.org/data/a24e8c8f0bd3924cc72501007eaaee10349c6c93/win7_wtb-w7pro/urlmon:protocol.html Jacek
Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)
On Thu, Feb 3, 2011 at 20:19, Juan Lang wrote: > Hey Austin, > > ok(ret, "WintrustSetRegPolicyFlags failed: %d\n", GetLastError()); > size = sizeof(flags1); > r = RegQueryValueExA(key, State, NULL, NULL, (LPBYTE)&flags1, &size); > - ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); > + ok(!r || r == ERROR_FILE_NOT_FOUND, "RegQueryValueEx failed: %d\n", r); > + if (!r) > + ok(flags1 == flags3, "Got %08x flags instead of %08x\n", > flags1, flags3); > > It seems to me that the introduction of ERROR_FILE_NOT_FOUND weakens > the test. (Testing r should be done, thanks for fixing that.) I > assume that, since WintrustSetRegPolicyFlags should have succeeded, > the registry value should now exist. Is there a test failure you're > also trying to fix? No, good catch. Too little caffeine -> copy/paste error. Resending, thanks. -- -Austin
Re: wintrust/tests: make sure return values are used (LLVM/Clang) (3/4)
Hey Austin, ok(ret, "WintrustSetRegPolicyFlags failed: %d\n", GetLastError()); size = sizeof(flags1); r = RegQueryValueExA(key, State, NULL, NULL, (LPBYTE)&flags1, &size); -ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); +ok(!r || r == ERROR_FILE_NOT_FOUND, "RegQueryValueEx failed: %d\n", r); +if (!r) +ok(flags1 == flags3, "Got %08x flags instead of %08x\n", flags1, flags3); It seems to me that the introduction of ERROR_FILE_NOT_FOUND weakens the test. (Testing r should be done, thanks for fixing that.) I assume that, since WintrustSetRegPolicyFlags should have succeeded, the registry value should now exist. Is there a test failure you're also trying to fix? Thanks, --Juan
Re: [PATCH 3/4] shell32: Some events are sent twice in SHChangeNotify
Obviously this needs some work yet. 1, 2, and 4 should work fine without this patch. On 11/12/2010 11:29 PM, Marvin wrote: 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 http://testbot.winehq.org/JobDetails.pl?Key=7032 Your paranoid android.
Re: [PATCH 3/4] shell32: Some events are sent twice in SHChangeNotify
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 http://testbot.winehq.org/JobDetails.pl?Key=7032 Your paranoid android. === W98SE (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called === WNT4WSSP6 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W2KPROSP4 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === WVISTAADM (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W2K8SE (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PRO (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PROX64 (32 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called === W7PROX64 (64 bit shlfolder) === shlfolder.c:4339: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEITEM: Expected wndproc to be called shlfolder.c:4339: Test failed: RENAMEFOLDER: Expected wndproc to be called shlfolder.c:4350: Test failed: RENAMEFOLDER: Expected wndproc to be called
Re: [PATCH 3/4] shdocvw: Implement ControlSite::TranslateAccelerator.
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 http://testbot.winehq.org/JobDetails.pl?Key=7010 Your paranoid android. === WVISTAADM (32 bit webbrowser) === webbrowser.c:1301: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP === W7PRO (32 bit webbrowser) === webbrowser.c:1301: Test failed: unexpected call UpdateUI webbrowser.c:241: Test failed: unexpected call QueryStatus_STOP
Re: [PATCH 3/4] mshtml: Added IDispatchEx support to HTMLStyleSheetsCollection object.
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
http://testbot.winehq.org/JobDetails.pl?Key=6856
Your paranoid android.
=== W2K3R2SESP2 (32 bit dom) ===
dom.c:3607: Test failed: unexpected guid {3050F54A-98B5-11CF-BB82-00AA00BDCE0B}
=== W7PRO (32 bit dom) ===
dom.c:5854: Test failed: unexpected guid {3050F547-98B5-11CF-BB82-00AA00BDCE0B}
dom.c:3607: Test failed: unexpected guid {3050F54A-98B5-11CF-BB82-00AA00BDCE0B}
=== W7PROX64 (32 bit dom) ===
dom.c:5854: Test failed: unexpected guid {3050F547-98B5-11CF-BB82-00AA00BDCE0B}
dom.c:3607: Test failed: unexpected guid {3050F54A-98B5-11CF-BB82-00AA00BDCE0B}
=== W7PROX64 (64 bit dom) ===
dom.c:5854: Test failed: unexpected guid {3050F547-98B5-11CF-BB82-00AA00BDCE0B}
dom.c:3607: Test failed: unexpected guid {3050F54A-98B5-11CF-BB82-00AA00BDCE0B}
Re: [3/4] msxml3: Add error code defines (resend)
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 http://testbot.winehq.org/JobDetails.pl?Key=6690 Your paranoid android. === WINEBUILD (build) === Make of import library failed Make of import library failed
Re: (resend)[3/4]winegstreamer: add gstreamer mp3 transform filter
Aric Stewart writes: > --- > dlls/winegstreamer/gst_guids.h |1 + > dlls/winegstreamer/gst_private.h |1 + > dlls/winegstreamer/gsttffilter.c | 125 > ++ > dlls/winegstreamer/main.c| 35 +++ > 4 files changed, 162 insertions(+), 0 deletions(-) It doesn't work here: ../../../../wine/tools/runtest -q -P wine -M qedit.dll -T ../../.. -p qedit_test.exe.so ../../../../wine/dlls/qedit/tests/mediadet.c && touch mediadet.ok mediadet.c:151: Test failed: IMediaDet_put_Filename -> 80040207 mediadet.c:162: Test failed: IMediaDet_get_StreamMediaType mediadet.c:214: Test failed: IMediaDet_get_StreamMediaType mediadet.c:222: Test failed: IMediaDet_get_FrameRate mediadet.c:223: Test failed: IMediaDet_get_FrameRate mediadet.c:238: Test failed: IMediaDet_put_Filename -> 80040207 mediadet.c:243: Test failed: IMediaDet_get_OutputStreams mediadet.c:259: Test failed: IMediaDet_put_CurrentStream mediadet.c:264: Test failed: IMediaDet_get_CurrentStream mediadet.c:283: Test failed: IMediaDet_get_StreamMediaType mediadet.c:291: Test failed: IMediaDet_get_CurrentStream make: *** [mediadet.ok] Error 11 -- Alexandre Julliard julli...@winehq.org
Re: [3/4] ddraw: fix DDSCAPS_3DDEVICE surfaces always setting DDSCAPS_VISIBLE
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 http://testbot.winehq.org/JobDetails.pl?Key=6460 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found
Re: [3/4]strmbase: implement OLE registration in AMovieDllRegisterServer2
Aric Stewart writes:
> HRESULT WINAPI AMovieDllRegisterServer2(BOOL bRegister)
> {
> HRESULT hr;
> int i;
> IFilterMapper2 *pIFM2 = NULL;
> +HMODULE psapi;
> +fnGetModuleFileNameExW pFunc;
> +WCHAR szFileName[MAX_PATH];
> +
> +psapi = LoadLibraryA("psapi.dll");
> +if (psapi)
> +{
> +pFunc = (fnGetModuleFileNameExW)GetProcAddress(psapi,
> "GetModuleFileNameExW");
> +if (pFunc)
> +{
> +if (!pFunc(GetCurrentProcess(), g_hInst, szFileName, MAX_PATH))
> +{
> +ERR("Failed to get module file name for registration\n");
> +return E_FAIL;
> +}
> +}
> +else
> +{
> +ERR("Failed to get get function GetModuleFileNameExW\n");
> +return E_FAIL;
> +}
> +}
> +else
> +{
> +ERR("Failed to load psapi.dll\n");
> +return E_FAIL;
> +}
> +FreeLibrary(psapi);
There's no reason to use psapi for this.
--
Alexandre Julliard
julli...@winehq.org
