Re: [1/3] comctl32/tab: Add a test for TCM_SETITEMEXTRA
On 09/26/2010 05:08 PM, Nikolay Sivov wrote:
Add a test for TCM_SETITEMEXTRA
+static HWND parent_wnd;
-static void test_curfocus(HWND parent_wnd, INT nTabs)
+static void test_curfocus(void)
{
-hTab = createFilledTabControl(parent_wnd, TCS_FIXEDWIDTH,
TCIF_TEXT|TCIF_IMAGE, nTabs);
+hTab = createFilledTabControl(parent_wnd, TCS_FIXEDWIDTH,
TCIF_TEXT|TCIF_IMAGE, 5);
So how is the global better then function parameter? Or a magic number?
Vitaliy.
Re: hey, saw a job ad that mentions wine!
On 9/26/10 6:52 PM, Dan Kegel wrote: I do periodic searches in google blogsearch and twitter for references to wine, sometimes I find interesting tidbits that way. Tonight I also tried searching on indeed.com, and one job popped up: http://storagecraft.iapplicants.com/ViewJob-106203.html They're only looking for wine users, but still, it's nice to see. I'd have to move...Good company and location for someone with the requisite skill set and it does mention Wine as a PLUS. James McKenzie
hey, saw a job ad that mentions wine!
I do periodic searches in google blogsearch and twitter for references to wine, sometimes I find interesting tidbits that way. Tonight I also tried searching on indeed.com, and one job popped up: http://storagecraft.iapplicants.com/ViewJob-106203.html They're only looking for wine users, but still, it's nice to see.
Re: Wine test bot failure?
W dniu 26.09.2010 20:27, Greg Geldorp pisze: This is now fixed. The problem occurred when your patch contained a change to tests/Makefile.in. The config.status invocation to create an updated Makefile recently changed, TestBot now calls config.status with the correct arguments again. Greg. Hi Thanks for your efforts. Good to know that bot is working well again. -- Best regards Mariusz Pluciński
Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite
On Sun, Sep 26, 2010 at 12:41 PM, Stefan Dösinger wrote: > > Am 26.09.2010 um 19:51 schrieb Travis Athougies: > >> +data = compute_shader_fullscreen9(device, vshader_passthru, >> pshader, quad_geometry, >> +D3DFMT_A8R8G8B8, 1, 1); >> + >> +ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), >> +"swizzle_test: Got color %08x (should be 0x)\n", >> data[0]); > You leak the returned data here. > Ok woops. Can't believe I missed that > On the big picture of this, I don't like the void * blob returned from > compute_shader_fullscreen. As far as I can see the only position dependent > aspect of HLSL is vpos(or rather, the HLSL equivalent). For all others it > would be OK to return a ARGB color. > The reason why I don't return just one value here is (a) because the data might either be in DWORD or float format and (b) some tests use more than just 1 pixel, so they need access to all their pixels. >> +/* The Direct3D 9 docs state that we cannot lock a render target >> surface, >> + instead we must copy the render target onto this surface to lock it >> */ > I think you can, if you create it with D3DUSAGE_DYNAMIC | > D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need > some device creation flag whose name I forgot. There is the lockable boolean argument that I think might work. I will look into using this On Sun, Sep 26, 2010 at 12:41 PM, Stefan Dösinger wrote: > > Am 26.09.2010 um 19:51 schrieb Travis Athougies: > >> + data = compute_shader_fullscreen9(device, vshader_passthru, >> pshader, quad_geometry, >> + D3DFMT_A8R8G8B8, 1, 1); >> + >> + ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), >> + "swizzle_test: Got color %08x (should be 0x)\n", >> data[0]); > You leak the returned data here. > > On the big picture of this, I don't like the void * blob returned from > compute_shader_fullscreen. As far as I can see the only position dependent > aspect of HLSL is vpos(or rather, the HLSL equivalent). For all others it > would be OK to return a ARGB color. > >> + /* The Direct3D 9 docs state that we cannot lock a render target >> surface, >> + instead we must copy the render target onto this surface to lock it >> */ > I think you can, if you create it with D3DUSAGE_DYNAMIC | > D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need > some device creation flag whose name I forgot. > > > > -- Travis Athougies
Re: what's the proper way to define a COM interface that takes function pointers as arguments?
Never mind. Henri has pointed out that I am on crack and this totally works. On Sun, Sep 26, 2010 at 4:05 PM, Vincent Povirk wrote: > I am trying to define the ICLRRuntimeHost interface. > > It has this method: > http://msdn.microsoft.com/en-us/library/ms164410.aspx > > One of the arguments is a function pointer type: > http://msdn.microsoft.com/en-us/library/aa964757.aspx > > Widl fails when I try to define a function pointer type using C syntax. > > So, what's the proper way to do this? > > Does widl need to be fixed? >
what's the proper way to define a COM interface that takes function pointers as arguments?
I am trying to define the ICLRRuntimeHost interface. It has this method: http://msdn.microsoft.com/en-us/library/ms164410.aspx One of the arguments is a function pointer type: http://msdn.microsoft.com/en-us/library/aa964757.aspx Widl fails when I try to define a function pointer type using C syntax. So, what's the proper way to do this? Does widl need to be fixed?
Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite
Am 26.09.2010 um 19:51 schrieb Travis Athougies: > +data = compute_shader_fullscreen9(device, vshader_passthru, pshader, > quad_geometry, > +D3DFMT_A8R8G8B8, 1, 1); > + > +ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), > +"swizzle_test: Got color %08x (should be 0x)\n", > data[0]); You leak the returned data here. On the big picture of this, I don't like the void * blob returned from compute_shader_fullscreen. As far as I can see the only position dependent aspect of HLSL is vpos(or rather, the HLSL equivalent). For all others it would be OK to return a ARGB color. > +/* The Direct3D 9 docs state that we cannot lock a render target surface, > + instead we must copy the render target onto this surface to lock it */ I think you can, if you create it with D3DUSAGE_DYNAMIC | D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need some device creation flag whose name I forgot.
RE: Wine test bot failure?
> From: Mariusz Pluciński > > I also had this problem yesterday both with patches submitted manually > and my patches transferred from wine-patches. I can confirm that > sending executables instead worked for me, but this is possible only > when submitting own test, and not when it is loaded from wine-patches. > > It is also strange that as I see, only your and my patches causes this > error, there's some other which works properly. I hope Greg will look > at this, if he finds time. This is now fixed. The problem occurred when your patch contained a change to tests/Makefile.in. The config.status invocation to create an updated Makefile recently changed, TestBot now calls config.status with the correct arguments again. Greg.
Re: [PATCH 1/5] gameux: Add implementation of IGameStatistics::SetCategoryTitle
W dniu 26.09.2010 15:07, Nikolay Sivov pisze:
On 9/26/2010 16:59, Mariusz Pluciński wrote:
---
dlls/gameux/gamestatistics.c | 50 ++-
dlls/gameux/tests/gamestatistics.c | 14 +-
2 files changed, 55 insertions(+), 9 deletions(-)
@@ -177,8 +201,30 @@ static HRESULT WINAPI
GameStatisticsImpl_SetCategoryTitle(
WORD categoryIndex,
LPCWSTR title)
{
- FIXME("stub\n");
- return E_NOTIMPL;
+ HRESULT hr = S_OK;
+ DWORD dwLength;
+ GameStatisticsImpl *This = impl_from_IGameStatistics(iface);
+
+ TRACE("(%p, %d, %s)\n", This, categoryIndex, debugstr_w(title));
+
+ if(!title || categoryIndex>= MAX_CATEGORIES)
+ hr = E_INVALIDARG;
Just return here and be done with it, this will save you hr
initialization and unnecessary if (SUCCEEDED(hr)) after that.
You're right, I'll fix it.
+
+ if(SUCCEEDED(hr))
+ {
+ dwLength = lstrlenW(title);
+
+ if(dwLength> MAX_CATEGORY_LENGTH)
+ {
+ hr = S_FALSE;
+ dwLength = MAX_CATEGORY_LENGTH;
+ }
Does it really copy with hr == S_FALSE ?
Yes, this behavior is subject of one of tests.
--
Best regards
Mariusz Pluciński
Re: [PATCH 1/5] gameux: Add implementation of IGameStatistics::SetCategoryTitle
On 9/26/2010 16:59, Mariusz Pluciński wrote:
---
dlls/gameux/gamestatistics.c | 50
++-
dlls/gameux/tests/gamestatistics.c | 14 +-
2 files changed, 55 insertions(+), 9 deletions(-)
@@ -177,8 +201,30 @@ static HRESULT WINAPI GameStatisticsImpl_SetCategoryTitle(
WORD categoryIndex,
LPCWSTR title)
{
-FIXME("stub\n");
-return E_NOTIMPL;
+HRESULT hr = S_OK;
+DWORD dwLength;
+GameStatisticsImpl *This = impl_from_IGameStatistics(iface);
+
+TRACE("(%p, %d, %s)\n", This, categoryIndex, debugstr_w(title));
+
+if(!title || categoryIndex>= MAX_CATEGORIES)
+hr = E_INVALIDARG;
Just return here and be done with it, this will save you hr
initialization and unnecessary if (SUCCEEDED(hr)) after that.
+
+if(SUCCEEDED(hr))
+{
+dwLength = lstrlenW(title);
+
+if(dwLength> MAX_CATEGORY_LENGTH)
+{
+hr = S_FALSE;
+dwLength = MAX_CATEGORY_LENGTH;
+}
Does it really copy with hr == S_FALSE ?
+
+lstrcpynW(This->stats.categories[categoryIndex].sName,
+ title, dwLength+1);
+}
+
+return hr;
}
Re: RFC [PATCH] ddraw: Prevent refcount underflow
Am 26.09.2010 um 12:01 schrieb Vincent Pelletier: > Points on which I would like opinions: > - getting rid of the magic number ~0U or ~((unsigned long) 0) > - couldn't it actually hide a refcount problem in wine ? Very likely > - if not, then would it be good to extend to other refcounts aswell or include > in [a local wrapper for] InterlockedDecrement ? If the problem is indeed an underflow and not a hidden refcount issue(e.g. separated refcounts on surface versions, that's being worked on) it needs a testcase.
RFC [PATCH] ddraw: Prevent refcount underflow
Hi.
Attached patch fixes a problem with Beetle Crazy Cup's VideoSetup.exe, which
hangs at exit because some code tries to free ddraw surface on which a
refcount underflow happened earlier in the execution.
Executing it with winedbg shows that the first call causing the underflow is
triggered from game's binary:
Stopped on breakpoint 3 at 0x7ed494fc ddraw1_Release+0x2c
[/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw
476 ULONG ref = InterlockedDecrement(&ddraw->ref1);
Wine-dbg>print ddraw->ref1
0
Wine-dbg>bt
Backtrace:
=>0 0x7ed494fc ddraw1_Release+0x2c(iface=0x129e10)
[/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw (0x0033fd24)
1 0x00401d2c in videosetup (+0x1d2b) (0x0033fd5c)
2 0x0040342b in videosetup (+0x342a) (0x0033fd84)
3 0x004034f5 in videosetup (+0x34f4) (0x0033fda0)
4 0x00402f65 in videosetup (+0x2f64) (0x0033fe04)
5 0x00404a4e in videosetup (+0x4a4d) (0x0033fe90)
6 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fea8)
7 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fee8)
8 0x7b858a9b start_process+0x5a(peb=0x536430)
[/home/vincent/git/wine/dlls/kernel32/process.c:994] in kernel32 (0x0033fef8)
9 0x7bc715f0 call_thread_func+0xb() in ntdll (0x0033ffc8)
10 0x7bc717c0 call_thread_entry_point+0x6f(entry=0x7b858a40, arg=0x7ffdf000)
[/home/vincent/git/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0033ffe8)
11 0x7bc4cefa start_process+0x29(kernel_start=0x7b858a40)
[/home/vincent/git/wine/dlls/ntdll/loader.c:2610] in ntdll (0x)
Points on which I would like opinions:
- getting rid of the magic number
- need to check after InterlockedDecrement (in doubt I did, but the code is
much less readable this way)
- couldn't it actually hide a refcount problem in wine ?
- if not, then would it be good to extend to other refcounts aswell or include
in [a local wrapper for] InterlockedDecrement ?
Regards,
---
dlls/ddraw/ddraw.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index f3ebade..39738d5 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -475,7 +475,11 @@ static ULONG WINAPI ddraw1_Release(IDirectDraw *iface)
IDirectDrawImpl *ddraw = ddraw_from_ddraw1(iface);
ULONG ref = InterlockedDecrement(&ddraw->ref1);
-TRACE("%p decreasing refcount to %u.\n", ddraw, ref);
+if (ref == 4294967295U) {
+InterlockedIncrement(&ddraw->ref1);
+WARN("%p NOT decreasing refcount.\n", ddraw);
+} else
+TRACE("%p decreasing refcount to %u.\n", ddraw, ref);
if (!ref && !InterlockedDecrement(&ddraw->numIfaces))
ddraw_destroy(ddraw);
Re: comctl32/treeview: Erase background when painting over supplied hdc
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=5489 Your paranoid android. === W98SE (32 bit treeview) === treeview.c:1293: Test failed: got 0x0
