- wine-devel - winehq.org

Re: [PATCH] ntdll: Catch page fault in RtlWow64EnableFsRedirectionEx
by Nikolay Sivov 06 Aug '16

06 Aug '16

On 04.08.2016 20:05, Matt Robinson wrote: > Previously, RtlWow64EnableFsRedirectionEx only returned > STATUS_NOT_IMPLEMENTED if the old_value pointer started with 0x0000, and > would cause an unhandled page fault if an invalid handle not starting > with 0x00 was passed. However, Windows seems to catch page faults when > accessing old_value and returns STATUS_ACCESS_VIOLATION. > > This adds a test to confirm the behaviour and then wraps the access to > old_value in an exception handler. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41066 > > Signed-off-by: Matt Robinson <git(a)nerdoftheherd.com> > --- > dlls/ntdll/directory.c | 12 +++++++++++- > dlls/ntdll/tests/directory.c | 2 ++ > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c > index 4a34475..13df0d1 100644 > --- a/dlls/ntdll/directory.c > +++ b/dlls/ntdll/directory.c > @@ -106,6 +106,7 @@ > #include "wine/list.h" > #include "wine/library.h" > #include "wine/debug.h" > +#include "wine/exception.h" > > WINE_DEFAULT_DEBUG_CHANNEL(file); > > @@ -2998,7 +2999,16 @@ NTSTATUS WINAPI RtlWow64EnableFsRedirectionEx( ULONG disable, ULONG *old_value ) > if (!is_wow64) return STATUS_NOT_IMPLEMENTED; > if (((ULONG_PTR)old_value >> 16) == 0) return STATUS_ACCESS_VIOLATION; Looks like you can remove this old pointer check now. > > - *old_value = !ntdll_get_thread_data()->wow64_redir; > + __TRY > + { > + *old_value = !ntdll_get_thread_data()->wow64_redir; > + } > + __EXCEPT_PAGE_FAULT > + { > + return STATUS_ACCESS_VIOLATION; > + } > + __ENDTRY > + > ntdll_get_thread_data()->wow64_redir = !disable; > return STATUS_SUCCESS; > }

1 0

Re: kernel32/tests: Convert fiber back to thread even when IsThreadAFiber is not available.
by Nikolay Sivov 06 Aug '16

06 Aug '16

On 06.08.2016 15:40, Bernhard Übelacker wrote: > Testbot shows the fiber test failing for Windows 2003 recently. > https://test.winehq.org/data/tests/kernel32:fiber.html > > This is probably related to the last change in > http://source.winehq.org/git/wine.git/commit/556fef3dd184e71e1f0345bd8f3725… > > As Windows 2003 seems to have no IsThreadAFiber the test never > calls test_ConvertFiberToThread. > This leads probably sometimes to the crash now visible. > > By calling test_ConvertFiberToThread before return the crash disappears > on Windows 2003. > > Signed-off-by: Bernhard Übelacker <bernhardu(a)mailbox.org> > --- > dlls/kernel32/tests/fiber.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/kernel32/tests/fiber.c b/dlls/kernel32/tests/fiber.c > index 9ff9366..0c989af 100644 > --- a/dlls/kernel32/tests/fiber.c > +++ b/dlls/kernel32/tests/fiber.c > @@ -158,6 +158,7 @@ static void test_FiberHandling(void) > if (!pCreateFiberEx) > { > win_skip( "CreateFiberEx not present\n" ); > + test_ConvertFiberToThread(); > return; > } > > @@ -171,6 +172,7 @@ static void test_FiberHandling(void) > if (!pIsThreadAFiber) > { > win_skip( "IsThreadAFiber not present\n" ); > + test_ConvertFiberToThread(); > return; > } > > It's better to have a helper for such cleanup, and not to call one test from another.

2 1

Re: [v2 4/8] msvcirt: Add a partial implementation of class istream_withassign.
by Piotr Caban 06 Aug '16

06 Aug '16

On 08/05/16 18:56, Iván Matellanes wrote: > +/* ??0istream_withassign@@QAE@XZ */ > +/* ??0istream_withassign@@QEAA@XZ */ > +DEFINE_THISCALL_WRAPPER(istream_withassign_ctor, 12) > +istream* __thiscall istream_withassign_ctor(istream *this, BOOL virt_init) There should be 8 instead of 12. Thanks, Piotr

1 0

Re: [PATCH] ntdll: Call __finally blocks in __C_specific_handler (try2)
by Piotr Caban 06 Aug '16

06 Aug '16

On 08/06/16 01:39, Daniel Lehman wrote: > + if (rec->ExceptionFlags & EH_TARGET_UNWIND && > + dispatch->TargetIp < dispatch->ImageBase + table->ScopeRecord[i].EndAddress) > + { > + break; > + } Here's a test that shows that you also need to check BeginAddress: BOOL first = TRUE; __try { begin: if(!first) { printf("here\n"); return 0; } first = FALSE; __try { __try { goto begin; } __finally { printf("finally 1\n"); } } __finally { printf("finally 2\n"); } } __finally { printf("finally 3\n"); }

1 0

Re: [PATCH 1/5] d3dx11: Use debugstr_a() to trace a user-supplied string.
by Henri Verbeet 05 Aug '16

05 Aug '16

On 5 August 2016 at 20:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -32,7 +32,7 @@ HRESULT WINAPI D3DX11CompileFromMemory(const char *data, SIZE_T data_size, const > { > TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > "sflags %#x, eflags %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", > - debugstr_a(data), data_size, debugstr_a(filename), defines, include, entry_point, > + debugstr_a(data), data_size, debugstr_a(filename), defines, include, debugstr_a(entry_point), Somewhat related, this seems to assume "data" is a zero-terminated string.

2 1

Re: Simple D3D/WGL demos for wine
by Matteo Bruni 05 Aug '16

05 Aug '16

2016-08-05 22:00 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >>> Hello all. I'd like to implement a set of simple demos which would be >>> something like glxgears for Wine — a simple way to check that WGL, >>> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >>> to look for a real app to test. I suppose it's not very interesting to >>> have just flat untextured gears, so I'd instead draw a textured cube >>> (similarly to what the tests in dxdiag do). >> >> Do you plan to include these demos in Wine or maintain them >> separately? I'd be in favor of including them in Wine proper (others >> might disagree though) but that introduces a few additional >> constraints, like no C++ code allowed. > I intended them to eventually get into Wine source, after I bring them > to more or less final form. It seems Wine does provide some macros to > call Direct3D virtual functions from C code — like > IDirect3D9_CreateDevice. Actually those macros are also in the original MS headers. Except when they aren't, like for a bunch of d3dx9 interfaces. In those cases we shouldn't have them either. If there is no macro for a method you need you can just manually call the function pointer through the vtable; see the relevant test sources for examples of that if it turns out to be the case. >> BTW, actually we do have a (VERY sketchy) dxdiag implementation in >> Wine, under programs/dxdiag/. You could integrate those demos into it >> in principle. > Good to know it exists, will look into integration of the demos there. > Do you think the WGL demo still fits there? I'd like to have a demo > for WGL since it's the simplest 3D interface for Wine, it's used by > wined3d, and if even it's not working then the users would be better > directed to where their problems might be (i.e. graphics > configuration, not wined3d code). I think it would be fine and nice to have, yes. >>> I have some prototype code for this (standalone and written in C++ for >>> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >>> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >>> ming32. But when I try to compile for D3D8 with wineg++, there's a >>> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >>> >>> Is it undesirable for Wine to have d3dx8 (I remember some commits >>> removing the library and headers related to it several years ago)? >> >> You remember correctly. It turns out d3dx8 in practice was always >> statically compiled into the game executables. IIRC the DX8 SDK had no >> d3dx8.dll at all, just a d3dx8.lib with the full library. There was >> also a d3dx8_d.dll with a debug version of the library but that wasn't >> installed by the usual DirectX redistributable so applications can't >> depend on its presence either. In any case, we've had 0 applications >> using our d3dx8.dll, which means our implementation wasn't actually >> used or tested and there was no point in keeping it. >> >>> Should I just drop usage of D3DXCreateTextureFromFile and use plain >>> IDirect3DDeviceX::CreateTexture? >> >> You could use some other API to load the image files. I imagine that >> mixing d3dx9.h with d3d8 won't be a great experience. There are other >> options though, depending on the texture file format you want to use; >> WIC (windowscodecs) might be a good choice generally speaking. >> Another possibility is to create the textures you need procedurally, >> without needing to load them from a file or a resource. > For WGL version I used GdiPlus (flat) API, so I guess this is the way > to go for D3D versions. > The texture I thought of using was something like the following: > http://6g6.eu/sih0-winehq-logo-glass.png > I don't think it'd be easy to generate procedurally, although if > there's a good idea on what image to use instead, I'd favor the > procedural version due to its better reliability (i.e. no dependency > on external file being readable, residing in the expected location > etc.). The procedural generation thing was just an idea, loading from file or, probably better, from resource is okay too. >>> Also I use some matrix functions, which are identical between d3dx8 >>> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >>> d3d9 and d3d8 versions of it? Or should I just reimplement all the >>> needed functions? >> >> As I mentioned above, I suspect you would get issues when trying to >> include d3dx9.h together with d3d8.h, although you can probably >> workaround that in this case by carefully dividing your code over >> multiple .c files. >> Depending on what you exactly need, just copying or reimplementing the >> relevant functions might be simpler. > Yeah there were some issues with including d3dx9.h directly, I worked > around them by manually declaring the necessary functions and types > and still linking to d3dx9 DLL. I guess that works too. It doesn't seem critical for the time being and it will probably be easier to give more sensible suggestions during an actual patch review. Looking forward to your patches :)

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v4)
by Marvin 05 Aug '16

05 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24770 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Fwd: Simple D3D/WGL demos for wine
by Ruslan Kabatsayev 05 Aug '16

05 Aug '16

Sorry, forgot to include the mailing list to recipients. ---------- Forwarded message ---------- From: Ruslan Kabatsayev <b7.10110111(a)gmail.com> Date: Fri, Aug 5, 2016 at 11:00 PM Subject: Re: Simple D3D/WGL demos for wine To: Matteo Bruni <matteo.mystral(a)gmail.com> On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >> Hello all. I'd like to implement a set of simple demos which would be >> something like glxgears for Wine — a simple way to check that WGL, >> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >> to look for a real app to test. I suppose it's not very interesting to >> have just flat untextured gears, so I'd instead draw a textured cube >> (similarly to what the tests in dxdiag do). > > Do you plan to include these demos in Wine or maintain them > separately? I'd be in favor of including them in Wine proper (others > might disagree though) but that introduces a few additional > constraints, like no C++ code allowed. I intended them to eventually get into Wine source, after I bring them to more or less final form. It seems Wine does provide some macros to call Direct3D virtual functions from C code — like IDirect3D9_CreateDevice. > BTW, actually we do have a (VERY sketchy) dxdiag implementation in > Wine, under programs/dxdiag/. You could integrate those demos into it > in principle. Good to know it exists, will look into integration of the demos there. Do you think the WGL demo still fits there? I'd like to have a demo for WGL since it's the simplest 3D interface for Wine, it's used by wined3d, and if even it's not working then the users would be better directed to where their problems might be (i.e. graphics configuration, not wined3d code). > >> I have some prototype code for this (standalone and written in C++ for >> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >> ming32. But when I try to compile for D3D8 with wineg++, there's a >> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >> >> Is it undesirable for Wine to have d3dx8 (I remember some commits >> removing the library and headers related to it several years ago)? > > You remember correctly. It turns out d3dx8 in practice was always > statically compiled into the game executables. IIRC the DX8 SDK had no > d3dx8.dll at all, just a d3dx8.lib with the full library. There was > also a d3dx8_d.dll with a debug version of the library but that wasn't > installed by the usual DirectX redistributable so applications can't > depend on its presence either. In any case, we've had 0 applications > using our d3dx8.dll, which means our implementation wasn't actually > used or tested and there was no point in keeping it. > >> Should I just drop usage of D3DXCreateTextureFromFile and use plain >> IDirect3DDeviceX::CreateTexture? > > You could use some other API to load the image files. I imagine that > mixing d3dx9.h with d3d8 won't be a great experience. There are other > options though, depending on the texture file format you want to use; > WIC (windowscodecs) might be a good choice generally speaking. > Another possibility is to create the textures you need procedurally, > without needing to load them from a file or a resource. For WGL version I used GdiPlus (flat) API, so I guess this is the way to go for D3D versions. The texture I thought of using was something like the following: http://6g6.eu/sih0-winehq-logo-glass.png I don't think it'd be easy to generate procedurally, although if there's a good idea on what image to use instead, I'd favor the procedural version due to its better reliability (i.e. no dependency on external file being readable, residing in the expected location etc.). > >> Also I use some matrix functions, which are identical between d3dx8 >> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >> d3d9 and d3d8 versions of it? Or should I just reimplement all the >> needed functions? > > As I mentioned above, I suspect you would get issues when trying to > include d3dx9.h together with d3d8.h, although you can probably > workaround that in this case by carefully dividing your code over > multiple .c files. > Depending on what you exactly need, just copying or reimplementing the > relevant functions might be simpler. Yeah there were some issues with including d3dx9.h directly, I worked around them by manually declaring the necessary functions and types and still linking to d3dx9 DLL. > > As an aside, one possible objection to these demos could be "but we > have tests already!" IMO these cover a somewhat separate use case and > having simple d3d* demos that common users could easily run, similarly > to the "Test sound" button in winecfg, could be valuable.

1 0

Wineconf 2016 location and dates are set - book your travel now!
by Jeremy White 05 Aug '16

05 Aug '16

Hi folks, WineConf 2016 will be held on November 12th and 13th in St. Paul, MN. I've put up all of the details here: https://wiki.winehq.org/WineConf2016 Everyone is welcome at WineConf, please feel free to come. If you need help with travel expenses, please write to ask to ask for help; we are generally able to help, particularly for contributors to Wine (directions are in the Wiki). If you're interested in WineConf, you should sign up for the wineconf mailing list: https://www.winehq.org/mailman/listinfo/wineconf I've put the only two agenda items that matter to me on the Wiki: the keynote and fixing the tests. Feel free to suggest other topics or agenda items using the wineconf mailing list. I look forward to seeing you all there! Cheers, Jeremy

1 0

Re: [PATCH] d3dx9: Remove dead assignment (Coverity)
by Nikolay Sivov 05 Aug '16

05 Aug '16

On 05.08.2016 21:57, Matteo Bruni wrote: > 2016-08-04 8:17 GMT+02:00 Nikolay Sivov <nsivov(a)codeweavers.com>: >> Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> >> --- >> >> It's overwritten right after if block. >> >> dlls/d3dx9_36/mesh.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c >> index 3204ea7..c26aa72 100644 >> --- a/dlls/d3dx9_36/mesh.c >> +++ b/dlls/d3dx9_36/mesh.c >> @@ -5662,7 +5662,6 @@ static HRESULT create_outline(struct glyphinfo *glyph, void *raw_outline, int da >> pt->corner = POINTTYPE_CURVE_END; >> } >> outline->count--; >> - lastpt = &outline->items[outline->count - 1]; >> } else { >> /* outline closed with a line from end to start point */ >> attempt_line_merge(outline, outline->count - 1, &pt->pos, FALSE, cos_table); >> -- >> 2.8.1 > > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > > BTW, there is exactly the same issue in the tests in tests/mesh.c line 3737. > > Ok, will try to remember to remove it too.

1 0

Simple D3D/WGL demos for wine
by Ruslan Kabatsayev 05 Aug '16

05 Aug '16

Hello all. I'd like to implement a set of simple demos which would be something like glxgears for Wine — a simple way to check that WGL, D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need to look for a real app to test. I suppose it's not very interesting to have just flat untextured gears, so I'd instead draw a textured cube (similarly to what the tests in dxdiag do). I have some prototype code for this (standalone and written in C++ for now), and it uses D3DXCreateTextureFromFile. This is all OK when I compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with ming32. But when I try to compile for D3D8 with wineg++, there's a problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. Is it undesirable for Wine to have d3dx8 (I remember some commits removing the library and headers related to it several years ago)? Should I just drop usage of D3DXCreateTextureFromFile and use plain IDirect3DDeviceX::CreateTexture? Also I use some matrix functions, which are identical between d3dx8 and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for d3d9 and d3d8 versions of it? Or should I just reimplement all the needed functions? Regards, Ruslan

2 1

Re: d3dx10: Add D3DX10CreateEffectPoolFromFileA/W stubs.
by Matteo Bruni 05 Aug '16

05 Aug '16

2016-08-04 11:25 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > For https://bugs.winehq.org/show_bug.cgi?id=39506 You should probably put the stubs in async.c. Looks good to me otherwise.

1 1

Re: [1/6] msvcirt: Add a partial implementation of class ostream_withassign.
by Piotr Caban 05 Aug '16

05 Aug '16

Hi Iván, On 08/05/16 13:12, Iván Matellanes wrote: > typedef struct _ostream { > const int *vbtable; > int unknown; > -} ostream; > +} ostream, ostream_withassign; I don't think you need ostream_withassign type. You can just use ostream since the structures are identical. > /* ??0ostream@@QAE@PAVstreambuf@@@Z */ > /* ??0ostream@@QEAA@PEAVstreambuf@@@Z */ > +/* ??0ostream_withassign@@QAE@PAVstreambuf@@@Z */ > +/* ??0ostream_withassign@@QEAA@PEAVstreambuf@@@Z */ > DEFINE_THISCALL_WRAPPER(ostream_sb_ctor, 12) Calling ostream equivalents is OK in most cases. In case of constructors ostream_withassing_vtable should be used. Thanks, Piotr

2 3

Re: [PATCH 3/3] jscript: Added more tests.
by Marvin 05 Aug '16

05 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24755 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: wininet: Return data available in current chunk in chunked_get_avail_data.
by Sebastian Lackner 05 Aug '16

05 Aug '16

On 02.08.2016 15:33, Jacek Caban wrote: > > Based on patch by Hans Leidekker. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/wininet/http.c | 26 ++++++++++++++++++++------ > 1 file changed, 20 insertions(+), 6 deletions(-) > It seems like this patch introduced test failures here: ../../../tools/runtest -q -P wine -T ../../.. -M wininet.dll -p wininet_test.exe.so http && touch http.ok http.c:815: Test failed: length = 12960, expected <= 8192

2 1

Re: [PATCH] dsound: Fix its vs it's typos
by Andrew Eikum 05 Aug '16

05 Aug '16

Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> On Thu, Aug 04, 2016 at 10:57:43AM +0300, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/dsound/sound3d.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > index 840ab93..b416cdc 100644 > --- a/dlls/dsound/sound3d.c > +++ b/dlls/dsound/sound3d.c > @@ -294,12 +294,12 @@ if(0) > dsb->ds3db_ds3db.vVelocity.z == dsb->device->ds3dl.vVelocity.z)) > { > /* calculate length of ds3db_ds3db.vVelocity component which causes Doppler Effect > - NOTE: if buffer moves TOWARDS the listener, it's velocity component is NEGATIVE > - if buffer moves AWAY from listener, it's velocity component is POSITIVE */ > + NOTE: if buffer moves TOWARDS the listener, its velocity component is NEGATIVE > + if buffer moves AWAY from listener, its velocity component is POSITIVE */ > flBufferVel = ProjectVector(&dsb->ds3db_ds3db.vVelocity, &vDistance); > /* calculate length of ds3dl.vVelocity component which causes Doppler Effect > - NOTE: if listener moves TOWARDS the buffer, it's velocity component is POSITIVE > - if listener moves AWAY from buffer, it's velocity component is NEGATIVE */ > + NOTE: if listener moves TOWARDS the buffer, its velocity component is POSITIVE > + if listener moves AWAY from buffer, its velocity component is NEGATIVE */ > flListenerVel = ProjectVector(&dsb->device->ds3dl.vVelocity, &vDistance); > /* formula taken from Gianicoli D.: Physics, 4th edition: */ > /* FIXME: replace dsb->freq with appropriate frequency ! */ > -- > 2.8.1 > > >

1 0

Re: [PATCH 1/2] msvcp140: Take _Mtx_t and _Cnd_t directly
by Piotr Caban 05 Aug '16

05 Aug '16

On 08/05/16 00:33, Daniel Lehman wrote: > +#if _MSVCP_VER >= 140 > +typedef _Mtx_t _Mtx_arg_t; > +#define D(m) (m) > +#define R(m) (m) > +#else > +typedef _Mtx_t *_Mtx_arg_t; > +#define D(m) (*(m)) > +#define R(m) (&(m)) > +#endif How about changing the defines names to something more meaningful, like e.g.: #define MTX_T_FROM_ARG(m) ... #define MTX_T_TO_ARG(m) ... ? Thanks, Piotr

1 0

Re: [PATCH 1/2] concrt140: Add concrt140 stub
by Piotr Caban 05 Aug '16

05 Aug '16

On 08/05/16 00:33, Daniel Lehman wrote: > +MODULE = concrt140.dll > + > + > +C_SRCS = \ > + concrt140_main.c Do you need the concrt140_main.c file? I think the file may be added later (when needed). Thanks, Piotr

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v3)
by Huw Davies 05 Aug '16

05 Aug '16

On Fri, Aug 05, 2016 at 12:50:10AM +0200, Bernhard Übelacker wrote: > diff --git a/dlls/usp10/tests/usp10.c b/dlls/usp10/tests/usp10.c > index 6b2152f..971e275 100644 > --- a/dlls/usp10/tests/usp10.c > +++ b/dlls/usp10/tests/usp10.c > @@ -2900,7 +2900,7 @@ static void test_ScriptString(HDC hdc) > DWORD Flags = SSA_GLYPHS; > int ReqWidth = 100; > const int Dx[5] = {10, 10, 10, 10, 10}; > - const BYTE InClass = 0; > + static const BYTE InClass[8]; /* Array size needs to be at least equal to String_len */ And yet len == 10 in this case ;-) How about: static const BYTE InClass[ (sizeof(teststr) / sizeof(WCHAR)) - 1 ]; Of course now I've noticed Dx[5], that's clearly wrong. The sdk has it marked as _In_reads_opt_(cString), so I suggest marking this the same length too. Huw.

1 0

Re: [PATCH] ntdll: Call __finally blocks in __C_specific_handler
by Piotr Caban 05 Aug '16

05 Aug '16

Hi, I was also trying to implement support for finally blocks. My implementation differs a little from yours. On 08/05/16 02:53, Daniel Lehman wrote: > + if (rec->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND)) > + { > + for (i = 0; i < table->Count; i++) > + { > + if (context->Rip >= dispatch->ImageBase + table->ScopeRecord[i].BeginAddress && > + context->Rip < dispatch->ImageBase + table->ScopeRecord[i].EndAddress) > + { > + if (table->ScopeRecord[i].JumpTarget) continue; > + > + if (rec->ExceptionFlags & EH_TARGET_UNWIND && > + dispatch->TargetIp < dispatch->ImageBase + table->ScopeRecord[i].EndAddress) I was also checking if: dispatch->TargetIp >= dispatch->ImageBase + table->ScopeRecord[i].BeginAddress I'm not sure if this is needed. > + { > + break; > + } > + > + handler = (PC_LANGUAGE_EXCEPTION_HANDLER)(dispatch->ImageBase + table->ScopeRecord[i].HandlerAddress); Termination handlers have different signature. I was using following definition: typedef void (WINAPI *TERMINATION_HANDLER)( ULONG flags, ULONG64 frame ); I don't really know what is passed in first argument. I guess that it might be BYTE is_abnormal. On Windows flags were set to 0x1101 or 0x1201 in my test applications (I think that probably only least significant BYTE matters). Thanks, Piotr

1 0

Re: [PATCH 2/4] ucrtbase: Add __std_type_info_name implementation
by Sebastian Lackner 05 Aug '16

05 Aug '16

On 04.08.2016 16:28, Piotr Caban wrote: > +static void CDECL type_info_entry_free(void *ptr) > +{ > + ptr = (char*)ptr - FIELD_OFFSET(type_info_entry, name); > + MSVCRT_free(ptr); > +} [...] > + else > + { > + type_info_entry *entry = (type_info_entry*)(name-FIELD_OFFSET(type_info_entry, name)); > + InterlockedPushEntrySList(header, &entry->entry); > + } Its up to you of course, but why not CONTAINING_RECORD in those two cases?

2 1

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v3)
by Marvin 04 Aug '16

04 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24733 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: urlmon/tests: Make use of todo_wine_if().
by Marvin 04 Aug '16

04 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24731 Your paranoid android. === w7u (32 bit url) === url.c:3414: Test failed: bctx should be destroyed here

1 0

Re: mmdevapi/tests: Make use of todo_wine_if().
by Marvin 04 Aug '16

04 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24728 Your paranoid android. === w7u (32 bit capture) === capture.c:327: Test failed: GCP 11200 vs. BufferSize 21996 === w8 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:261: Test failed: Position 2167 expected 1463 capture.c:323: Test failed: Position 3191 gap 1280 capture.c:327: Test failed: GCP 13440 vs. BufferSize 21996 capture.c:347: Test failed: Position 4279 expected 3639 capture.c:372: Test failed: Position 4727 expected 4087 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:323: Test failed: Position 3191 gap 1216 capture.c:327: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:347: Test failed: Position 4279 expected 3639 capture.c:348: Test failed: flags 1 capture.c:372: Test failed: Position 5303 expected 4087 capture.c:373: Test failed: flags 1 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:323: Test failed: Position 4215 gap 2240 capture.c:327: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:347: Test failed: Position 5303 expected 4663 capture.c:348: Test failed: flags 1 capture.c:372: Test failed: Position 6391 expected 5111 capture.c:373: Test failed: flags 1 === w864 (64 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:261: Test failed: Position 2167 expected 1463 capture.c:323: Test failed: Position 3191 gap 1280 capture.c:327: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:347: Test failed: Position 4343 expected 3639 capture.c:348: Test failed: flags 1 capture.c:372: Test failed: Position 4791 expected 4087 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1143 expected 0 capture.c:231: Test failed: Position 2167 expected 1591 capture.c:261: Test failed: Position 2167 expected 1591 capture.c:323: Test failed: Position 4215 gap 2176 capture.c:327: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:347: Test failed: Position 5303 expected 4663 capture.c:348: Test failed: flags 1 capture.c:372: Test failed: Position 6391 expected 5111 capture.c:373: Test failed: flags 1

2 1

Re: user32/tests: Make use of todo_wine_if().
by Marvin 04 Aug '16

04 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24730 Your paranoid android. === w864 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different === w1064 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different === w864 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:10053: Test failed: SendMessageTimeout succeeded msg.c:10054: Test failed: WmEmptySeq: 0: the msg sequence is not complete: expected 0000 - actual 0400 === w1064 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7437: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH v4] ntoskrnl.exe: Implement ObReferenceObjectByName for created drivers
by Sebastian Lackner 04 Aug '16

04 Aug '16

On 04.08.2016 18:24, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > v3: eliminate duplicated driver_name > v4: use the rb_tree > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) > > > > 0001-ntoskrnl.exe-Implement-ObReferenceObjectByName-but-onl.txt > > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index 25187d3..883e845 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -2107,8 +2107,34 @@ NTSTATUS WINAPI ObReferenceObjectByName( UNICODE_STRING *ObjectName, > void *ParseContext, > void **Object) > { > - FIXME("stub\n"); > - return STATUS_NOT_IMPLEMENTED; > + struct wine_driver *driver; > + struct wine_rb_entry *entry; > + > + TRACE("mostly-stub:%s %i %p %i %p %i %p %p\n", debugstr_us(ObjectName), > + Attributes, AccessState, DesiredAccess, ObjectType, AccessMode, > + ParseContext, Object); > + > + if (AccessState) FIXME("Unhandled AccessState\n"); > + if (DesiredAccess) FIXME("Unhandled DesiredAccess\n"); > + if (ParseContext) FIXME("Unhandled ParseContext\n"); > + if (ObjectType) FIXME("Unhandled ObjectType\n"); > + > + if (AccessMode != KernelMode) > + { > + FIXME("UserMode access not implemented\n"); > + return STATUS_NOT_IMPLEMENTED; > + } > + > + entry = wine_rb_get(&wine_drivers, ObjectName); You will have to lock the CS before accessing the tree structure. > + if (!entry) > + { > + FIXME("Object not found, may not be tracked.\n"); For debugging purposes it would make sense to dump the name here. > + return STATUS_NOT_IMPLEMENTED; > + } > + > + driver = WINE_RB_ENTRY_VALUE(entry, struct wine_driver, entry); > + *Object = &driver->driver_obj; > + return STATUS_SUCCESS; > } > > > > >

1 0

Re: RFC: dinput8/tests: Add valid wide string termination to actionName member.
by Huw Davies 04 Aug '16

04 Aug '16

On Tue, Aug 02, 2016 at 11:34:10PM +0200, Bernhard Übelacker wrote: > https://bugs.winehq.org/show_bug.cgi?id=40384 > https://www.winehq.org/pipermail/wine-devel/2016-July/114054.html > > DirectX SDK offers the possibility to increase debug > output via "DirectX Control Panel". > This prints this error: > DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string > > It looks like ansi version of EnumDevicesBySemantics forwards the string to > the wide variant without conversation. > So the assumption is that with the old compiler version we got > enough valid wide string termination between the ansi string actionName > member and the next invalid memory page. > This is the added test trying to prove by putting the string right before > a memory page with PAGE_NOACCESS. This seems pretty convincing, thanks for tracking this down. We don't actually want to test for this Windows bug, so please resend the patch without the PAGE_NOACCESS stuff - just add a comment explaining the double nul-termination. Huw.

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v2)
by Huw Davies 04 Aug '16

04 Aug '16

On Thu, Aug 04, 2016 at 12:44:58AM +0200, Bernhard Übelacker wrote: > https://bugs.winehq.org/show_bug.cgi?id=40385 > > ScriptStringAnalyse crashes if InClass is just one byte in size > followed by memory marked as PAGE_NOACCESS. > By testing the size it seems it should have the same size as characters > in teststr are given to the function. Hi, Thanks for getting to the bottom of this. I don't think we want to test with the PAGE_NOACCESS stuff; it's pretty clear that MSDN is incorrect and class should indeed be an array. Just fix the bug and perhaps add a comment somewhere. Huw.

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v2)
by Marvin 04 Aug '16

04 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24709 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH 2/2] winex11: track glx windows per thread
by Miklós Máté 03 Aug '16

03 Aug '16

On 07/22/2016 03:11 AM, Alexandre Julliard wrote: > Miklós Máté<mtmkls(a)gmail.com> writes: > >> Hmm, you are right. Mesa does set an XCloseDisplay callback to clean >> things up for the display connections it encounters. If I use >> data->display instead of gdi_display for pglXCreateWindow in line 1358 >> of opengl.c, the tests pass, and no zombie glx windows remain. I don't >> know if I should dare to take responsibility for this change, though, >> as I know almost nothing about GDI. > If it works then it's the right thing to do. I did some further testing, and it doesn't work. Mesa glx maintains its state per-display, and creating a drawable with one display connection but makecurrent with an other one can lead to bad things. Unfortunately, wine-csmt likes to do those from separate threads, so the thread-specific display connections cannot be used instead of the global gdi_display. MM

2 2

Re: [PATCH v3 ] programs/winedevice.exe: Use IoCreateDriver and IoDeleteDriver
by Sebastian Lackner 03 Aug '16

03 Aug '16

On 29.07.2016 21:02, Aric Stewart wrote: > v2: Pass a proper driver name to IoCreateDriver and use generated keyname > v3: Remove global driver_name > > The two patches are not longer a set as each is independent of the other > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > programs/winedevice/device.c | 179 +++++++++++++++++++++++-------------------- > 1 file changed, 94 insertions(+), 85 deletions(-) > > > > 0002-programs-winedevice.exe-Use-IoCreateDriver-and-IoDelet.txt > > > diff --git a/programs/winedevice/device.c b/programs/winedevice/device.c > index 94132ed..df0fac3 100644 > --- a/programs/winedevice/device.c > +++ b/programs/winedevice/device.c > @@ -40,11 +40,10 @@ WINE_DECLARE_DEBUG_CHANNEL(relay); > > extern NTSTATUS CDECL wine_ntoskrnl_main_loop( HANDLE stop_event ); > > -static WCHAR *driver_name; > static SERVICE_STATUS_HANDLE service_handle; > static HANDLE stop_event; > -static DRIVER_OBJECT driver_obj; > -static DRIVER_EXTENSION driver_extension; > +static DRIVER_OBJECT *driver_obj; > +static HMODULE driver_module; How do you plan to adjust this when multiple drivers are loaded? Its still not clear to me, unfortunately. The static variables have to go away sooner or later. ;) > > /* find the LDR_MODULE corresponding to the driver module */ > static LDR_MODULE *find_ldr_module( HMODULE module ) > @@ -132,92 +131,25 @@ error: > return NULL; > } > > -/* call the driver init entry point */ > -static NTSTATUS init_driver( HMODULE module, UNICODE_STRING *keyname ) > -{ > - unsigned int i; > - NTSTATUS status; > - const IMAGE_NT_HEADERS *nt = RtlImageNtHeader( module ); > - > - if (!nt->OptionalHeader.AddressOfEntryPoint) return STATUS_SUCCESS; > - > - driver_obj.Size = sizeof(driver_obj); > - driver_obj.DriverSection = find_ldr_module( module ); > - driver_obj.DriverInit = (PDRIVER_INITIALIZE)((char *)module + nt->OptionalHeader.AddressOfEntryPoint); > - driver_obj.DriverExtension = &driver_extension; > - > - driver_extension.DriverObject = &driver_obj; > - driver_extension.ServiceKeyName = *keyname; > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Call driver init %p (obj=%p,str=%s)\n", GetCurrentThreadId(), > - driver_obj.DriverInit, &driver_obj, wine_dbgstr_w(keyname->Buffer) ); > - > - status = driver_obj.DriverInit( &driver_obj, keyname ); > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Ret driver init %p (obj=%p,str=%s) retval=%08x\n", GetCurrentThreadId(), > - driver_obj.DriverInit, &driver_obj, wine_dbgstr_w(keyname->Buffer), status ); > - > - WINE_TRACE( "init done for %s obj %p\n", wine_dbgstr_w(driver_name), &driver_obj ); > - WINE_TRACE( "- DriverInit = %p\n", driver_obj.DriverInit ); > - WINE_TRACE( "- DriverStartIo = %p\n", driver_obj.DriverStartIo ); > - WINE_TRACE( "- DriverUnload = %p\n", driver_obj.DriverUnload ); > - for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) > - WINE_TRACE( "- MajorFunction[%d] = %p\n", i, driver_obj.MajorFunction[i] ); > - > - return status; > -} > - > -/* call the driver unload function */ > -static void unload_driver( HMODULE module, DRIVER_OBJECT *driver_obj ) > -{ > - if (driver_obj->DriverUnload) > - { > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Call driver unload %p (obj=%p)\n", GetCurrentThreadId(), > - driver_obj->DriverUnload, driver_obj ); > - > - driver_obj->DriverUnload( driver_obj ); > - > - if (WINE_TRACE_ON(relay)) > - WINE_DPRINTF( "%04x:Ret driver unload %p (obj=%p)\n", GetCurrentThreadId(), > - driver_obj->DriverUnload, driver_obj ); > - } > - FreeLibrary( module ); > -} > - > /* load the .sys module for a device driver */ > -static HMODULE load_driver(void) > +static HMODULE load_driver(const WCHAR *driver_name, UNICODE_STRING * keyname) > { > static const WCHAR driversW[] = {'\\','d','r','i','v','e','r','s','\\',0}; > static const WCHAR systemrootW[] = {'\\','S','y','s','t','e','m','R','o','o','t','\\',0}; > static const WCHAR postfixW[] = {'.','s','y','s',0}; > static const WCHAR ntprefixW[] = {'\\','?','?','\\',0}; > static const WCHAR ImagePathW[] = {'I','m','a','g','e','P','a','t','h',0}; > - static const WCHAR servicesW[] = {'\\','R','e','g','i','s','t','r','y', > - '\\','M','a','c','h','i','n','e', > - '\\','S','y','s','t','e','m', > - '\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t', > - '\\','S','e','r','v','i','c','e','s','\\',0}; > > - UNICODE_STRING keypath; > HKEY driver_hkey; > HMODULE module; > LPWSTR path = NULL, str; > DWORD type, size; > > - str = HeapAlloc( GetProcessHeap(), 0, sizeof(servicesW) + strlenW(driver_name)*sizeof(WCHAR) ); > - lstrcpyW( str, servicesW ); > - lstrcatW( str, driver_name ); > - > - if (RegOpenKeyW( HKEY_LOCAL_MACHINE, str + 18 /* skip \registry\machine */, &driver_hkey )) > + if (RegOpenKeyW( HKEY_LOCAL_MACHINE, keyname->Buffer + 18 /* skip \registry\machine */, &driver_hkey )) Currently its hardcoded in ntoskrnl, but it would be better to check the prefix first. > { > - WINE_ERR( "cannot open key %s, err=%u\n", wine_dbgstr_w(str), GetLastError() ); > - HeapFree( GetProcessHeap(), 0, str); > + WINE_ERR( "cannot open key %s, err=%u\n", wine_dbgstr_w(keyname->Buffer), GetLastError() ); > return NULL; > } > - RtlInitUnicodeString( &keypath, str ); > > /* read the executable path from memory */ > size = 0; > @@ -233,7 +165,6 @@ static HMODULE load_driver(void) > HeapFree( GetProcessHeap(), 0, str ); > if (!path) > { > - RtlFreeUnicodeString( &keypath ); > RegCloseKey( driver_hkey ); > return NULL; > } > @@ -276,19 +207,98 @@ static HMODULE load_driver(void) > > module = load_driver_module( str ); > HeapFree( GetProcessHeap(), 0, path ); > - if (!module) > + return module; > +} > + > +/* call the driver init entry point */ > +static NTSTATUS WINAPI init_driver( DRIVER_OBJECT *driver_object, UNICODE_STRING *keyname ) > +{ > + unsigned int i; > + NTSTATUS status; > + const IMAGE_NT_HEADERS *nt; > + const WCHAR *driver_name; > + > + /* Retrieve driver name from the keyname */ > + driver_name = strrchrW(keyname->Buffer, '\\'); It would be better to test that this actually worked. > + driver_name++; > + > + driver_module = load_driver( driver_name, keyname ); > + if (!driver_module) > { > - RtlFreeUnicodeString( &keypath ); > - return NULL; > + WINE_ERR("Failed to load device\n"); > + return STATUS_DLL_INIT_FAILED; > } > > - init_driver( module, &keypath ); > - return module; > + nt = RtlImageNtHeader( driver_module ); > + > + if (!nt->OptionalHeader.AddressOfEntryPoint) return STATUS_SUCCESS; > + > + driver_obj = driver_object; driver_obj will remain uninitialized when the module has no entry point. You will still need it during the unload step. > + > + driver_object->DriverSection = find_ldr_module( driver_module ); > + driver_object->DriverInit = (PDRIVER_INITIALIZE)((char *)driver_module + nt->OptionalHeader.AddressOfEntryPoint); > + > + if (WINE_TRACE_ON(relay)) > + WINE_DPRINTF( "%04x:Call driver init %p (obj=%p,str=%s)\n", GetCurrentThreadId(), > + driver_object->DriverInit, driver_object, wine_dbgstr_w(keyname->Buffer) ); > + > + status = driver_object->DriverInit( driver_object, keyname ); > + > + if (WINE_TRACE_ON(relay)) > + WINE_DPRINTF( "%04x:Ret driver init %p (obj=%p,str=%s) retval=%08x\n", GetCurrentThreadId(), > + driver_object->DriverInit, driver_object, wine_dbgstr_w(keyname->Buffer), status ); > + > + WINE_TRACE( "init done for %s obj %p\n", wine_dbgstr_w(driver_name), driver_object ); > + WINE_TRACE( "- DriverInit = %p\n", driver_object->DriverInit ); > + WINE_TRACE( "- DriverStartIo = %p\n", driver_object->DriverStartIo ); > + WINE_TRACE( "- DriverUnload = %p\n", driver_object->DriverUnload ); > + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) > + WINE_TRACE( "- MajorFunction[%d] = %p\n", i, driver_object->MajorFunction[i] ); > + > + return status; > +} > + > +/* call the driver unload function */ > +static void unload_driver( HMODULE module, DRIVER_OBJECT *driver_obj ) > +{ > + if (driver_obj->DriverUnload) > + { > + if (WINE_TRACE_ON(relay)) > + WINE_DPRINTF( "%04x:Call driver unload %p (obj=%p)\n", GetCurrentThreadId(), > + driver_obj->DriverUnload, driver_obj ); > + > + driver_obj->DriverUnload( driver_obj ); > + > + if (WINE_TRACE_ON(relay)) > + WINE_DPRINTF( "%04x:Ret driver unload %p (obj=%p)\n", GetCurrentThreadId(), > + driver_obj->DriverUnload, driver_obj ); > + } > + FreeLibrary( module ); > + IoDeleteDriver( driver_obj ); > +} > + > +static HRESULT create_driver(const WCHAR *driver_name) > +{ This should be a NTSTATUS return value. > + static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > + UNICODE_STRING drv_name; > + HRESULT status; > + WCHAR *str; > + > + str = HeapAlloc( GetProcessHeap(), 0, sizeof(driverW) + strlenW(driver_name)*sizeof(WCHAR) ); > + lstrcpyW( str, driverW); > + lstrcatW( str, driver_name ); > + RtlInitUnicodeString( &drv_name, str ); > + > + status = IoCreateDriver( &drv_name, init_driver ); > + > + RtlFreeUnicodeString( &drv_name); > + return status; > } > > static DWORD WINAPI service_handler( DWORD ctrl, DWORD event_type, LPVOID event_data, LPVOID context ) > { > SERVICE_STATUS status; > + WCHAR* driver_name = (WCHAR*)context; > > status.dwServiceType = SERVICE_WIN32; > status.dwControlsAccepted = SERVICE_ACCEPT_STOP; > @@ -318,13 +328,13 @@ static DWORD WINAPI service_handler( DWORD ctrl, DWORD event_type, LPVOID event_ > static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv ) > { > SERVICE_STATUS status; > - HMODULE driver_module; > + const WCHAR* driver_name = argv[0]; > > WINE_TRACE( "starting service %s\n", wine_dbgstr_w(driver_name) ); > > stop_event = CreateEventW( NULL, TRUE, FALSE, NULL ); > > - service_handle = RegisterServiceCtrlHandlerExW( driver_name, service_handler, NULL ); > + service_handle = RegisterServiceCtrlHandlerExW( driver_name, service_handler, (VOID*)driver_name); Usually "void *" is preferred in Wine source. > if (!service_handle) > return; > > @@ -337,15 +347,14 @@ static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv ) > status.dwWaitHint = 10000; > SetServiceStatus( service_handle, &status ); > > - driver_module = load_driver(); > - if (driver_module) > + if (SUCCEEDED(create_driver(driver_name))) After changing the HRESULT -> NTSTATUS return value, this also needs to be adjusted. > { > status.dwCurrentState = SERVICE_RUNNING; > status.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN; > SetServiceStatus( service_handle, &status ); > > wine_ntoskrnl_main_loop( stop_event ); > - unload_driver( driver_module, &driver_obj ); > + unload_driver( driver_module, driver_obj ); > } > else WINE_ERR( "driver %s failed to load\n", wine_dbgstr_w(driver_name) ); > > @@ -359,7 +368,7 @@ int wmain( int argc, WCHAR *argv[] ) > { > SERVICE_TABLE_ENTRYW service_table[2]; > > - if (!(driver_name = argv[1])) > + if (!(argv[1])) You can also remove the brackets. ;) > { > WINE_ERR( "missing device name, winedevice isn't supposed to be run manually\n" ); > return 1; > > >

2 2

Re: [PATCH 5/5] jscript: More arguments object tests.
by Marvin 03 Aug '16

03 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24706 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH resend 07/10] dxgi/tests: Add tests for IDXGISwapChain_GetFullscreenState() to test_create_swapchain().
by Henri Verbeet 03 Aug '16

03 Aug '16

On 3 August 2016 at 09:41, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + /* When numerator is non-zero and denominator is zero, the windowed mode is used. > + * Additionally, some versions of WARP seem to always fail to change fullscreen state. */ > + if (result_desc.Windowed != creation_desc.Windowed) > + trace("Test %u: Failed to change fullscreen state.\n", i); For what it's worth, I seem to consistently get "device.c:616: Test 1: Failed to change fullscreen state." from this as well on Windows.

1 0

Re: [PATCH] wined3d: Check pointer before use
by Henri Verbeet 03 Aug '16

03 Aug '16

On 3 August 2016 at 04:29, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > - if (tq->context->tid != GetCurrentThreadId()) > + if (!tq->context || tq->context->tid != GetCurrentThreadId()) How can the context be NULL?

2 2

Re: RFC: usp10/tests: Reserve for InClass a byte for every character in teststr.
by Nikolay Sivov 03 Aug '16

03 Aug '16

On 03.08.2016 0:33, Bernhard Übelacker wrote: > https://bugs.winehq.org/show_bug.cgi?id=40385 > > ScriptStringAnalyse crashes if InClass is just one byte in size > followed by memory marked as PAGE_NOACCESS. > By testing the size it seems it should have the same size as characters > in teststr are given to the function. > --- > dlls/usp10/tests/usp10.c | 103 +++++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 95 insertions(+), 8 deletions(-) > > diff --git a/dlls/usp10/tests/usp10.c b/dlls/usp10/tests/usp10.c > index 6b2152f..7eb0592 100644 > --- a/dlls/usp10/tests/usp10.c > +++ b/dlls/usp10/tests/usp10.c > @@ -2900,7 +2900,7 @@ static void test_ScriptString(HDC hdc) > DWORD Flags = SSA_GLYPHS; > int ReqWidth = 100; > const int Dx[5] = {10, 10, 10, 10, 10}; > - const BYTE InClass = 0; > + const BYTE InClass[len]; > SCRIPT_STRING_ANALYSIS ssa = NULL; > > int X = 10; > @@ -2916,29 +2916,30 @@ static void test_ScriptString(HDC hdc) > > > Charset = -1; /* this flag indicates unicode input */ > + memset((void*)InClass, 0, sizeof(InClass)); Instead of using len, it should be either use a constant, or be allocated dynamically, otherwise you'll get compiler warning with default flags we're building with. I think it would be easier to make it 'static const BYTE InClass[32];' (or whatever length is appropriate). Otherwise it looks reasonable, thanks for working on this.

1 0

Enabling/Disabling Joysticks from registry for the Mac
by DavidL 03 Aug '16

03 Aug '16

Hi Ken, I was looking into how the Linux-dinput code and joy.cpl work and comparing that to the macOS-dinput code. I have some questions about how best to proceed: joy.cpl uses joy->instance.tszInstanceName to name the joysticks in the control panel. In Linux-dinput code, they pass the joystick_devices[id].name to both tszInstanceName and tszProductName In the macOS-dinput code, they pass the name "Joystick #" where # is the index in the joystick array to the instance name and the joystick's actual name to the product name. When looking at the Microsoft guidelines for dinput, it does indeed say that the instance name *can* be joystick + position in the array, but doesn't specify that it *has* to be ( https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_…). Also, I've confirmed that in the Windows 10 joystick control panel the joysticks are listed by their name, not by joystick number (and in my memory of earlier Windows OSes it's the same). So, should I change the macOS-dinput code to set both tszInstanceName and tszProductName to the product name (as in Linux) or should I change joy.cpl to use tszProductName instead of tszInstanceName? This will also make it easier in the registry to know which joystick is being enabled/disabled. Further, while joy.cpl correctly is a dinput control panel, enabling/disabling joystick should be for both dinput and winmm games - e.g. X-wing vs Tie Fighter even has the joystick control panel in the game's loader window*, but, once in the game, joystick control is handled by winmm. I believe the joystick registry entry is under dinput, but the winmm wine joystick driver should read that as well. Is it acceptable for wine joystick driver to read the dinput registry? Or should two registry entries be created? or should a single general joystick registry entry not under dinput or winmm control both? I may have more questions, but we'll start off with these. :) Cheers, David *Interestingly, the game's sequel X-wing: Alliance says I need to install DirectX to access joystick options in the loader window. I'm not sure why the older title brings up the joystick control panel just fine, but the later one does not.

2 2

Re: [PATCH 2/2] kernel32/tests/thread: Add tests for fiber-local storage.
by Marvin 02 Aug '16

02 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24688 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH 1/2 v2] kernel32/tests/loader: Add tests for fiber-local storage.
by Marvin 02 Aug '16

02 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24687 Your paranoid android. === w1064 (32 bit loader) === loader.c:2980: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2980: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2980: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2981: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2988: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2989: Test failed: Test 3: Wrong callback count: 0 loader.c:2988: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2989: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784

1 0

Re: [PATCH] d3dx10: Implement D3DX10CreateDeviceAndSwapChain
by Matteo Bruni 02 Aug '16

02 Aug '16

2016-08-02 9:48 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > + TRACE("adapter %p, driver_type %d, swrast %p, flags %#x, desc %p, swapchain %p, device %p\n", > + adapter, driver_type, swrast, flags, desc, swapchain, device); Missing period at the end of the trace message. > + if (SUCCEEDED(hr = D3D10CreateDeviceAndSwapChain1(adapter, driver_type, swrast, flags, D3D10_FEATURE_LEVEL_10_1, > + D3D10_1_SDK_VERSION, desc, swapchain, (ID3D10Device1 **)device))) > + return hr; > + > + if (SUCCEEDED(hr = D3D10CreateDeviceAndSwapChain1(adapter, driver_type, swrast, flags, D3D10_FEATURE_LEVEL_10_0, > + D3D10_1_SDK_VERSION, desc, swapchain, (ID3D10Device1 **)device))) > + return hr; > + > + return hr; > +} The second if is redundant, you're going to "return hr;" either way.

1 0

Re: RFC: usp10/tests: Reserve for InClass a byte for every character in teststr.
by Marvin 02 Aug '16

02 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24683 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH 1/2] kernel32/tests/loader: Add tests for fiber-local storage.
by Alexandre Julliard 02 Aug '16

02 Aug '16

John Sheu <sheu(a)google.com> writes: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/loader.c | 125 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 123 insertions(+), 2 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so loader && touch loader.ok loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 loader.c:1880: Test failed: FlsGetValue failed with error 87 make[1]: *** [loader.ok] Error 14 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] msxml3/test: Add XMLParser Tests
by Nikolay Sivov 02 Aug '16

02 Aug '16

On 02.08.2016 11:02, Alistair Leslie-Hughes wrote: > With Signed-off. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/msxml3/tests/xmlparser.c | 196 ++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 188 insertions(+), 8 deletions(-) > > diff --git a/dlls/msxml3/tests/xmlparser.c b/dlls/msxml3/tests/xmlparser.c > index 32514e3..bf896e4 100644 > --- a/dlls/msxml3/tests/xmlparser.c > +++ b/dlls/msxml3/tests/xmlparser.c > @@ -26,8 +26,45 @@ > #include "windows.h" > #include "ole2.h" > #include "xmlparser.h" > +#include "rpcproxy.h" > #include "wine/test.h" Why do you need this? > + > +static HRESULT hresult_NotifyEvent = S_OK; Please move this global variable to factory instance. > > static HRESULT WINAPI nodefact_QueryInterface(IXMLNodeFactory *iface, > REFIID riid, void **ppvObject) > @@ -54,34 +91,67 @@ static ULONG WINAPI nodefact_Release(IXMLNodeFactory *iface) > } > > static HRESULT WINAPI nodefact_NotifyEvent(IXMLNodeFactory *iface, > - IXMLNodeSource *pSource, XML_NODEFACTORY_EVENT iEvt) > + IXMLNodeSource *source, XML_NODEFACTORY_EVENT event) > { > - return E_NOTIMPL; > + switch(event) > + { > + case XMLNF_STARTDOCUMENT: > + CHECK_EXPECT(NotifyStartDocument); > + trace("NotifyEvent: XMLNF_STARTDOCUMENT\n"); > + break; > + case XMLNF_ENDPROLOG: > + CHECK_EXPECT(NotifyEndProlog); > + trace("NotifyEvent: XMLNF_ENDPROLOG\n"); > + break; > + case XMLNF_ENDDOCUMENT: > + CHECK_EXPECT(NotifyEndDocument); > + trace("NotifyEvent: XMLNF_ENDDOCUMENT\n"); > + break; > + case XMLNF_DATAAVAILABLE: > + CHECK_EXPECT(NotifyDataAvailable); > + trace("NotifyEvent: XMLNF_DATAAVAILABLE\n"); > + break; > + default: > + ok(0, "Unsupported NotifyEvent %p %d\n", source, event); > + return E_FAIL; > + } > + > + return hresult_NotifyEvent; > } Arguably trace()'s are not really useful in this context, and will appear on every parsing test. > > static HRESULT WINAPI nodefact_BeginChildren(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, XML_NODE_INFO *pNodeInfo) > { > - return E_NOTIMPL; > + trace("nodefact_BeginChildren %p %p %d\n", pSource, pNodeInfo, > + pNodeInfo ? pNodeInfo->dwType : 0); > + return S_OK; > } > > static HRESULT WINAPI nodefact_EndChildren(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, BOOL fEmpty, XML_NODE_INFO *pNodeInfo) > { > - return E_NOTIMPL; > + trace("nodefact_EndChildren %p %d %p %d\n", pSource, fEmpty, pNodeInfo, > + pNodeInfo ? pNodeInfo->dwType : 0); > + return S_OK; > } > > static HRESULT WINAPI nodefact_Error(IXMLNodeFactory *iface, > IXMLNodeSource *pSource, HRESULT hrErrorCode, USHORT cNumRecs, > XML_NODE_INFO **ppNodeInfo) > { > - return E_NOTIMPL; > + CHECK_EXPECT(FactoryError); > + trace("nodefact_Error %p %08x %d %p\n", pSource, hrErrorCode, cNumRecs, ppNodeInfo); > + return S_OK; > } > > -static HRESULT WINAPI nodefact_CreateNode(IXMLNodeFactory *iface, IXMLNodeSource *pSource, > - PVOID pNodeParent, USHORT cNumRecs, XML_NODE_INFO **ppNodeInfo) > +static HRESULT WINAPI nodefact_CreateNode(IXMLNodeFactory *iface, IXMLNodeSource *source, > + void *parent, USHORT recs, XML_NODE_INFO **nodeinfo) > { > - return E_NOTIMPL; > + trace("nodefact_CreateNode %p %p %d %p\n", source, parent, recs, nodeinfo); > + > + *nodeinfo = NULL; > + > + return S_OK; > } > > static const IXMLNodeFactoryVtbl nodefactoryVtbl = > @@ -150,6 +220,114 @@ static void create_test(void) > IXMLParser_Release(parser); > } > > +static void parse_documnet(void) > +{ > + HRESULT hr; > + IXMLParser *parser; > + IStream* stream = NULL; > + HGLOBAL hMem; > + LPBYTE bytes; > + > + hr = CoCreateInstance(&CLSID_XMLParser30, NULL, CLSCTX_INPROC_SERVER, &IID_IXMLParser, (void**)&parser); > + if (FAILED(hr)) > + { > + win_skip("IXMLParser is not available (0x%08x)\n", hr); > + return; > + } > + > + hMem = GlobalAlloc(GMEM_MOVEABLE, strlen(empty_document)); > + bytes = GlobalLock(hMem); > + memcpy(bytes, empty_document, strlen(empty_document)); > + GlobalUnlock(hMem); > + > + CreateStreamOnHGlobal(hMem, TRUE, &stream); > + > + hr = IXMLParser_SetFactory(parser, &thenodefactory); > + ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + > + hr = IXMLParser_SetInput(parser, (IUnknown *)stream); > + ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + > + hr = IXMLParser_GetParserState(parser); > + ok(hr == XMLPARSER_IDLE, "got 0x%08x\n", hr); > + > + SET_EXPECT(NotifyStartDocument); > + SET_EXPECT(NotifyEndDocument); > + SET_EXPECT(NotifyEndProlog); > + SET_EXPECT(NotifyDataAvailable); > + hr = IXMLParser_Run(parser, -1); > + todo_wine ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > + todo_wine CHECK_CALLED(NotifyStartDocument); > + todo_wine CHECK_CALLED(NotifyEndDocument); > + todo_wine CHECK_CALLED(NotifyEndProlog); > + todo_wine CHECK_CALLED(NotifyDataAvailable); Main problem is that this does not test actual callback order - actual ordering is - start document; - create node; - end children; - end prolog; - data available; - end document; Please use test sequences facility saxreader.c is using - add_call(), ok_sequence(), etc. > START_TEST(xmlparser) > { > HRESULT hr; > @@ -160,6 +338,8 @@ START_TEST(xmlparser) > return; > > create_test(); > + parse_documnet(); > + parse_documnet_error(); I guess it was meant to be 'document'. > > CoUninitialize(); > } >

1 0

Re: [PATCH 10/11] dxgi: Add multi-monitor test for IDXGISwapChain_GetContainingOutput().
by Matteo Bruni 02 Aug '16

02 Aug '16

2016-08-01 22:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > + refcount = IDXGIOutput_Release(output); > + ok(!refcount, "IDXGIOuput has %u references left.\n", refcount); > refcount = IDXGIOutput_Release(output2); > ok(!refcount, "IDXGIOuput has %u references left.\n", refcount); There are a number of those "Ouput" typos through the patch, probably copypasted from this preexisting ok() message. Certainly not worth a resend by itself, but since you're going to anyway...

1 0

Re: [PATCH 02/11] wined3d: Add WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH flag.
by Matteo Bruni 02 Aug '16

02 Aug '16

2016-08-01 22:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > - FIXME("Ignoring SwapEffect and Flags\n"); > + FIXME("Ignoring SwapEffect %#x.\n", desc->SwapEffect); Yes please. I ended up making a similar change for debugging at least twice in separate occasions (even though in neither case the swap effect had anything to do with the issue at hand) but I didn't feel like sending just the trace change and I never completed a patch actually passing the swap effect to wined3d. I still might at some point, but in the meantime I'd love to see the actual swap effect traced.

1 0

wine-1.8.4-rc1
by Michael Stefaniuc 02 Aug '16

02 Aug '16

Hello guys, I have pushed wine-1.8.4-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Getting nearer to the goal of "around 50" commits for a stable release as this one contains only 66 commits. Nothing fancy though: - Stubs - More GPUs added - One wined3d fix backported (thanks again to Henri) - One original patch aka not cherry-picked, see below. Should somebody look at the release commit he'll notice that 7 of the bugs were already included in wine-1.8.3. That was a mistake as I had deferred those for a later release. So I've modified tools/make_announce to avoid that mistake in the future. For the release I would follow the same process: one week for feedback followed by another rc if needed with the final release 3-4 days later. Lets see how this works out as I'm on vacation travelling and Alexandre will travel too. And last but not least an excerpt from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes. - A few more cards added to the GPU description table. ---------------------------------------------------------------- Bugs fixed in 1.8.4 (total 49): 18745 64-bit Mortal Kombat X crashes on unimplemented function KERNEL32.dll.GetLargePageMinimum 20977 Bad hlp table rendering 22819 Some applications like Heroes of Might and Magic 2 display loopback. 25396 Safrosoft RoX freezes at start. 26268 Multiple applications need ntdll.ZwSetLdtEntries stub (kwiksupport.me, Ragnarok Online patcher) 26965 Dragon Age 2 demo - sound in cutscenes is muffled 27680 Multiple 64-bit applications crash on startup (violation of the Windows 64-bit ABI, stack pointer (RSP) must be 16-byte aligned when making a call to Win64 API) 28082 OCCT Perestroïka needs hal.dll.READ_PORT_ULONG 34052 The Witcher: Character models are sometimes invisible 36556 valgrind shows a definite leak in comctl32/tests/syslink.c 36838 TOCA Touring Car Championship: installer copies one file from CD and then shows an error 37063 NTLM EncryptMessage/DecryptMessage failure 37090 Multiple applications crash with built-in amstream (Shogun: Total War, Medieval: Total War) 37271 Applications get IP address of 127.12.34.56 when lo0 is up on OSX 38102 Process Hacker 2.x needs winsta.dll.WinStationEnumerateW 38137 WBaduk: "Could not obtain OLE control window handle" regression 38811 Java JRE 8 installer 'jre-8uXX-windows-i586.exe' crashes on startup (GetThreadPreferredUILanguages is a stub) 38962 expr.c:234 and 235 attempted computation of 1 << 31 should be 1u << 31 39543 Multiple games and applications crash on unimplemented function KERNEL32.dll.FreeUserPhysicalPages (Microsoft Office 2007 diagnosis service, Eden Eternal) 39579 iNode 3.6 client needs ndis.sys.NdisAllocateMemoryWithTag 39842 Skype for windows doesn't work (needs ndis.sys.NdisSystemProcessorCount) 39911 dxd9 PresentationInterval not propagated on device Reset 39933 iNode 3.6 client needs ndis.sys.NdisAllocateSpinLock 40048 Camtasia Studio 8 : crashes on unimplemented function dwmapi.dll.DwmSetPresentParameters 40301 wxDatePickerCtrl (wxWidgets) generates an assert on DTM_GETRANGE message result 40380 Wine should take dosbox's configuration instead of creating a new one 40389 cmd.exe (native): Unimplemented function KERNEL32.dll.GetConsoleAliasExesLengthW 40487 3dmark Vantage Benchmark: unimplemented functions hal.dll.READ and WRITE PORT 40497 "Trainz: A New Era" needs msvcr120.dll.?__ExceptionPtrToBool@@YA_NPEBX@Z 40511 Application that copies files from one place to another stoped working in wine versions greater then 1.6.2 40532 Microsoft Word Viewer 11.8 does not show text on file properties dialog until the text is selected 40557 KSP Trajectory Optimization Tool (MATLAB Runtime (MCR)) crashes at launch 40562 AkelPad: [ToolBar plugin] tooltips for toolbar buttons have some extra text 40581 Regression: dsound input recording from microphone lags with 2 seconds delay 40614 Cisco Jabber 11.6 crashes due to missing dbghelp.dll.EnumerateLoadedModulesExW 40618 Autodesk 123D Design needs msvcr100.dll.mbsrtowcs_s 40659 Window with CS_OWNDC style cause DC leak when GetDC/ReleaseDC is used. 40691 DVDFab 9.2.4.4 pre-check FabCheck.exe executable fails, needs setupapi.dll.CM_Get_DevNode_Status 40745 Python 3.5.1 interpreter crashes, needs _set_thread_local_invalid_parameter_handler 40747 Microsoft Expression Web 4 crashes on startup, needs gdiplus.dll.GdipGetImageAttributesAdjustedPalette 40754 GOG Galaxy crashes with unimplemented function api-ms-win-crt-locale-l1-1-0.dll._lock_locales 40755 GOG Galaxy crashes with unimplemented function ucrtbase.dll._lock_locales 40756 GOG Galaxy crashes with unimplemented function api-ms-win-crt-heap-l1-1-0.dll._calloc_base 40770 Nvidia GeForce GT 730 not recognized properly 40796 Python 3.5.1 interpreter crashes when importing pyqtSlot 40830 Conflict between kVK_RightCommand and macOS 10.12 Sierra in carbon framework 40833 Batman: Arkham Origins Blackgate no sound during gameplay (except cutscenes) 40851 macOS 10.12 Build Failure in winspool.drv with cupsGetPPD 40923 Alone in the Dark (2008) crashes on launch with msvcrt assertion ---------------------------------------------------------------- Changes since 1.8.3: Alex Henrie (6): msvcrt: Stub out _(get|set)_thread_local_invalid_parameter_handler. ucrtbase: Implement _(un)lock_locales. ucrtbase: Implement _calloc_base. ucrtbase: Implement _malloc_base. ucrtbase: Implement _free_base. riched20: Don't call UpdateWindow after setting the background color. Alexandre Julliard (1): user32: Completely free owned DCEs when the corresponding window/class is destroyed. Alistair Leslie-Hughes (2): wininet: Free socket when connection is freed. wined3d: Correct memory size for Geforce 9600 GT. Andrew Eikum (3): dsound: Support downmixing 5.1 to stereo. dsound: Capture all available data on each period callback. xaudio2: Always set current OpenAL context before making AL calls. André Hentschel (1): ndis.sys: Implement NdisSystemProcessorCount. Austin English (12): hal: Add READ_PORT_ULONG stub. hal: Add READ_PORT_UCHAR stub. hal: Add WRITE_PORT_ULONG stub. kernel32: Add FreeUserPhysicalPages stub. winsta: Add a stub for WinStationEnumerateW. dwmapi: Add DwmSetPresentParameters stub. kernel32: Add GetConsoleAliasExesLengthA/W stubs. ntdll: Add NtSetLdtEntries/ZwSetLdtEntries stub. dbghelp: Add forwards for EnumerateLoadedModulesEx/EnumerateLoadedModulesExW. kernel32: Implement GetLargePageMinimum. ndis.sys: Add NdisAllocateMemoryWithTag stub. ndis.sys: Add NdisAllocateSpinLock stub. Benjamin Hodgetts (1): wined3d: Add Intel Iris chips to identification list. Bruno Jesus (1): ws2_32: Ensure default route IP addresses are returned first in gethostbyname. Béla Gyebrószki (2): wined3d: Add Nvidia GeForce GTS 250. wined3d: Add Nvidia GeForce GT 730 (GK208). David Woodhouse (1): secur32: Fix handling of ANSI NTLM credentials. Fabian Maurer (1): msacm32: Added converter for ADPCM to PCM 8 bit mono. Grazvydas Ignotas (3): wined3d: Use Intel data returned by Windows driver. wined3d: Add some more Intel GPUs. wined3d: Add a fallback for Skylake. Hans Leidekker (1): kernel32: Improve the stub for GetThreadPreferredUILanguages. Henri Verbeet (1): wined3d: Also update the swap interval when not recreating the context in wined3d_device_reset(). Jarkko Korpi (1): widl: Fix overflow when left-shifting. Jean-Christophe Cardot (6): winhlp32: Replace magic numbers by symbols. winhlp32: Add some trace calls. winhlp32: Add a warning trace. winhlp32: Prepare winhlp32 for more font types. winhlp32: Rework and rename HLPFILE_HalfPointsToTwips. winhlp32: Fix table formatting. Justas Lavišius (1): include: Force stack alignment on x86_64. Ken Thomases (2): winspool.drv: Include <cups/ppd.h> to fix building against the macOS 10.12 SDK. winemac: Don't define kVK_RightCommand when building against the macOS 10.12 SDK. Luis Sahagun (1): winevdm: Tell dosbox to read the current user's config. Matteo Bruni (1): wined3d: Add a setting to check relative addressing indices when accessing uniforms. Michael Müller (1): amstream: Implement IDirectDrawMediaStream::GetMultiMediaStream. Michael Stefaniuc (1): tools: Get the bug list for ANNOUNCE from the stable-notes git notes. Nikolay Sivov (2): comctl32/datetime: Use MCM_GETRANGE result directly in DTM_GETRANGE. comctl32/tooltips: Cut tooltip text at first tab char unless TTS_NOPREFIX is used. Olivier F. R. Dierick (1): shell32: Set last error explicitly in SHFileOperation(). Piotr Caban (6): msvcrt: Add mbsrtowcs_s implementation. msvcp110: Fix num_put<char> structure layout. msvcrt: Fix mbtowc behavior for buffers containing more than one character. ieframe: Restore closed IOleClientSite in DoVerb. msvcr120: Add __ExceptionPtrToBool implementation. msvcrt: Return error when previously parsed type is accessed while demangling simple data type. Rob Walker (1): setupapi: Add stub for setupapi.dll.CM_Get_DevNode_Status. Sebastian Lackner (3): comctl32/syslink: Fix a blocks leak (Valgrind). amstream/tests: Add tests for GetMultiMediaStream methods. server: Fix assignment of primary_group in token_duplicate. Stefan Leichter (3): kernel32: Add stub for GetSystemPreferredUILanguages. kernel32/tests: Add tests for GetSystemPreferredUILanguages. kernel32: Return a dummy value in GetSystemPreferredUILanguages. Vincent Povirk (1): gdiplus: Implement GdipGetImageAttributesAdjustedPalette. bye michael -- Michael Stefaniuc mstefani(a)winehq.org

3 3

Re: [v2 4/6] msvcirt: Implement istream::operator>> for integers.
by Piotr Caban 02 Aug '16

02 Aug '16

On 08/02/16 13:37, Iván Matellanes wrote: > +static istream* istream_internal_read_unsigned_integer(istream *this, void *p, int size) > +{ > + /* size: 0 => short, 1 => int, 2 => long */ > + ios *base = istream_get_ios(this); > + char buffer[16]; > + int num_base; > + LONG min_value[3] = {SHRT_MIN, INT_MIN, LONG_MIN}; > + ULONG umax_value[3] = {USHRT_MAX, UINT_MAX, ULONG_MAX}, tmp; Shouldn't min_value be equal to 0? How about changing the helper functions to have following prototypes: static LONG istream_internal_read_integer(istream *this, LONG min_value, LONG max_value); and static ULONG istream_internal_read_unsigned_integer(istream *this, ULONG max_value); I think the code will be nicer this way. Thanks, Piotr

2 1

Re: [v2 5/6] msvcirt: Implement istream::operator>> for floats.
by Piotr Caban 02 Aug '16

02 Aug '16

On 08/02/16 13:37, Iván Matellanes wrote: > +static istream* istream_internal_read_float(istream *this, void *p, int size) > +{ > + /* size: 0 => float, 1 => double, 2 => long double */ > + const int max_chars[3] = {20, 28, 32}; /* character count is limited on Windows */ > + char buffer[32]; > + double d; > + > + TRACE("(%p %p %d)\n", this, p, size); > + > + if (istream_ipfx(this, 0)) { > + if (istream_getdouble(this, buffer, max_chars[size]) > 0) { > + d = strtod(buffer, NULL); > + if (size == 0) { > + /* check whether the value fits in the output var */ > + if (d > FLT_MAX) > + d = FLT_MAX; > + else if (d < -FLT_MAX) > + d = -FLT_MAX; > + else if (d > 0 && d < FLT_MIN) > + d = FLT_MIN; > + else if (d < 0 && d > -FLT_MIN) > + d = -FLT_MIN; > + *((float*) p) = d; I think that this helper will be nicer if it has following prototype: static double istream_internal_read_float(istream *this, int max_chars); where max_chars is set to 20, 28 or 32 depending if float, double or LDOUBLE needs to be read. With FLT_MIN/FLT_MAX checks moved to operator>>(float) implementation. Thanks, Piotr

1 0

Re: [v2 3/6] msvcirt: Implement istream::operator>> for strings.
by Piotr Caban 02 Aug '16

02 Aug '16

On 08/02/16 13:37, Iván Matellanes wrote: > @@ -3514,7 +3514,28 @@ istream* __thiscall istream_read_char(istream *this, char *ch) > DEFINE_THISCALL_WRAPPER(istream_read_str, 8) > istream* __thiscall istream_read_str(istream *this, char *str) > { > - FIXME("(%p %p) stub\n", this, str); > + ios *base = istream_get_ios(this); > + int ch, count = 0; > + > + TRACE("(%p %p)\n", this, str); > + > + if (istream_ipfx(this, 0)) { > + for (ch = streambuf_sgetc(base->sb); > + str && count < (unsigned int) base->width - 1 && !isspace(ch); > + ch = streambuf_snextc(base->sb)) { streambuf_sgetc shouldn't be called if str == NULL. Thanks, Piotr

1 0

Re: [PATCH 2/5] mpr: Implement provider selection given remote name.
by Nikolay Sivov 02 Aug '16

02 Aug '16

On 02.08.2016 14:31, Pierre Schweitzer wrote: > + len = WideCharToMultiByte(CP_ACP, 0, provider->lpProvider, -1, NULL, 0, NULL, NULL); > + provider_name = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (provider_name) > + memcpy(provider_name, provider->lpProvider, len * sizeof(WCHAR)); > + > + HeapFree(GetProcessHeap(), 0, provider); > + > + return provider_name; This is confusing. WNetGetResourceInformationW return W string, you convert it to A, and use A length to allocate another W buffer? What's going on?

2 2

Re: [PATCH 4/5] mpr: Implement WNetCancelConnectionA(), WNetCancelConnectionW(), WNetCancelConnection2A().
by Nikolay Sivov 02 Aug '16

02 Aug '16

This looks okay to me.

1 0

Re: [PATCH 1/5] mpr: Implement local name automatic redirection for disks. (try 3)
by Nikolay Sivov 02 Aug '16

02 Aug '16

On 02.08.2016 14:31, Pierre Schweitzer wrote: > + FIXME("Locale device selection is not implemented for printers.\n"); > + return WN_NO_NETWORK; This should be 'local', and not 'locale'.

1 0

Re: [PATCH 1/5] mpr: Implement local name automatic redirection for disks. (try 3)
by Nikolay Sivov 02 Aug '16

02 Aug '16

On 02.08.2016 14:31, Pierre Schweitzer wrote: > This fixes a bug seen during review for ReactOS commit: in case of local > redirection, the name wasn't properly converted back to ANSI for A callers. > > > -static void use_connection_set_accessnameW(struct use_connection_context *ctxt) > +static void use_connection_set_accessnameW(struct use_connection_context *ctxt, WCHAR *local_name) > { > WCHAR *accessname = ctxt->accessname; > - if (ctxt->resource->lpLocalName) > - strcpyW(accessname, ctxt->resource->lpLocalName); > + if (local_name) > + strcpyW(accessname, local_name); > else > strcpyW(accessname, ctxt->resource->lpRemoteName); > } You already have lpLocalName here, why another argument?

2 1

Re: [PATCH 3/5] mpr: Implement WNetCancelConnection2W().
by Nikolay Sivov 02 Aug '16

02 Aug '16

On 02.08.2016 14:31, Pierre Schweitzer wrote: > Resending just for offsets > > + if(providerTable->table[index].getCaps(WNNC_CONNECTION) & > + WNNC_CON_GETCONNECTIONS) > + { > + if (providerTable->table[index].cancelConnection) > + ret = providerTable->table[index].cancelConnection((LPWSTR)lpName, fForce); > + else > + ret = WN_NO_NETWORK; > + if (ret == WN_SUCCESS || ret == WN_OPEN_FILES) > + break; > + } I already asked about this before. Why is this using WNNC_CON_GETCONNECTIONS and not WNNC_CON_CANCELCONNECTION?

1 0

Re: [PATCH 02/11] wined3d: Add WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH flag.
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (mode) > + ERR("Ignoring mode.\n"); I think it's unclear what this means. "Ignoring mode" seems to suggest we're ignoring the mode, but shouldn't, in which case this should be a FIXME instead of an ERR. It could also mean the user of the API supplied a mode, but it has no effect because WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH is not set on the swapchain, in which case this should be a WARN instead of an ERR. > -#define WINED3DPRESENTFLAG_LOCKABLE_BACKBUFFER 0x00000001 > -#define WINED3DPRESENTFLAG_DISCARD_DEPTHSTENCIL 0x00000002 > -#define WINED3DPRESENTFLAG_DEVICECLIP 0x00000004 > -#define WINED3DPRESENTFLAG_VIDEO 0x00000010 > -#define WINED3DPRESENTFLAG_NOAUTOROTATE 0x00000020 > -#define WINED3DPRESENTFLAG_UNPRUNEDMODE 0x00000040 > +#define WINED3DSWAPCHAIN_LOCKABLE_BACKBUFFER 0x00000001 > +#define WINED3DSWAPCHAIN_DISCARD_DEPTHSTENCIL 0x00000002 > +#define WINED3DSWAPCHAIN_DEVICECLIP 0x00000004 > +#define WINED3DSWAPCHAIN_VIDEO 0x00000010 > +#define WINED3DSWAPCHAIN_NOAUTOROTATE 0x00000020 > +#define WINED3DSWAPCHAIN_UNPRUNEDMODE 0x00000040 > +#define WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH 0x00001000 Since you're renaming things, I think I'd prefer these as "WINED3D_SWAPCHAIN_". We'll probably want flags/masks to be unsigned, although it usually doesn't make a difference in practice.

2 1

Re: [PATCH 06/11] dxgi: Switch display mode when creating fullscreen swapchains.
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain->fullscreen) > + { > + if (FAILED(hr = wined3d_swapchain_set_fullscreen(swapchain->wined3d_swapchain, > + desc, NULL))) > + { > + WARN("Failed to set fullscreen state, hr %#x.\n", hr); > + wined3d_swapchain_decref(swapchain->wined3d_swapchain); > + goto cleanup; > + } > + > + if (FAILED(hr = IDXGISwapChain_GetContainingOutput(&swapchain->IDXGISwapChain_iface, > + &swapchain->target))) > + { > + struct wined3d_swapchain_desc wined3d_desc = *desc; > + WARN("Failed to get target output for fullscreen swapchain, hr %#x.\n", hr); > + wined3d_desc.windowed = FALSE; > + if (FAILED(hr = wined3d_swapchain_set_fullscreen(swapchain->wined3d_swapchain, > + &wined3d_desc, NULL))) Is this needed, or should swapchain destruction take care of this?

2 1

Re: [PATCH 10/11] dxgi: Add multi-monitor test for IDXGISwapChain_GetContainingOutput().
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/dxgi/tests/device.c | 159 ++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 135 insertions(+), 24 deletions(-) > "dxgi/tests: ", right?

1 0

Re: [PATCH 05/11] dxgi: Implement dxgi_swapchain_SetFullscreenState().
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (fullscreen) > + { > + if (target) > + { > + IDXGIOutput_AddRef(target); > + } > + else if (!target && FAILED(hr = IDXGISwapChain_GetContainingOutput(iface, &target))) The "!target" is redundant.

1 0

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL (try 3)
by Piotr Caban 02 Aug '16

02 Aug '16

On 08/02/16 01:40, Daniel Lehman wrote: > Try 3: > - use commented out externs for vtables > Try 2: > - add -arch to stubs > - use #define in _scprintf Here's the list of stubs that still needs to be changed: ?_Init_cnt@_UShinit@std@@0HA :- private: static int std::_UShinit::_Init_cnt ?id@?$codecvt@DDU_Mbstatet@@@std@@2V0locale@2@A :- public: static class std::locale::id std::codecvt<char,char,struct _Mbstatet>::id ?id@?$codecvt@GDU_Mbstatet@@@std@@2V0locale@2@A :- public: static class std::locale::id std::codecvt<unsigned short,char,struct _Mbstatet>::id ?id@?$codecvt@_WDU_Mbstatet@@@std@@2V0locale@2@A :- public: static class std::locale::id std::codecvt<wchar_t,char,struct _Mbstatet>::id ?id@?$messages@D@std@@2V0locale@2@A :- public: static class std::locale::id std::messages<char>::id ?id@?$messages@G@std@@2V0locale@2@A :- public: static class std::locale::id std::messages<unsigned short>::id ?id@?$messages@_W@std@@2V0locale@2@A :- public: static class std::locale::id std::messages<wchar_t>::id ?id@?$money_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_get<char,class std::istreambuf_iterator<char,struct std::char_traits<char> > >::id ?id@?$money_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_get<unsigned short,class std::istreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$money_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_get<wchar_t,class std::istreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?id@?$money_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_put<char,class std::ostreambuf_iterator<char,struct std::char_traits<char> > >::id ?id@?$money_put@GV?$ostreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_put<unsigned short,class std::ostreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$money_put@_WV?$ostreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::money_put<wchar_t,class std::ostreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?id@?$moneypunct@D$00@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<char,1>::id ?id@?$moneypunct@D$0A@@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<char,0>::id ?id@?$moneypunct@G$00@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<unsigned short,1>::id ?id@?$moneypunct@G$0A@@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<unsigned short,0>::id ?id@?$moneypunct@_W$00@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<wchar_t,1>::id ?id@?$moneypunct@_W$0A@@std@@2V0locale@2@A :- public: static class std::locale::id std::moneypunct<wchar_t,0>::id ?id@?$time_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::time_get<unsigned short,class std::istreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$time_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@2V0locale@2@A :- public: static class std::locale::id std::time_get<wchar_t,class std::istreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?intl@?$moneypunct@D$00@std@@2_NB :- public: static bool const std::moneypunct<char,1>::intl ?intl@?$moneypunct@D$0A@@std@@2_NB :- public: static bool const std::moneypunct<char,0>::intl ?intl@?$moneypunct@G$00@std@@2_NB :- public: static bool const std::moneypunct<unsigned short,1>::intl ?intl@?$moneypunct@G$0A@@std@@2_NB :- public: static bool const std::moneypunct<unsigned short,0>::intl ?intl@?$moneypunct@_W$00@std@@2_NB :- public: static bool const std::moneypunct<wchar_t,1>::intl ?intl@?$moneypunct@_W$0A@@std@@2_NB :- public: static bool const std::moneypunct<wchar_t,0>::intl Thanks, Piotr

1 0

Re: [PATCH] ddraw: Fix its vs it's typos
by Marvin 01 Aug '16

01 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24668 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 2/2] kernel32/tests/thread: Add tests for fiber-local storage.
by Marvin 01 Aug '16

01 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24663 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH 1/2] kernel32/tests/loader: Add tests for fiber-local storage.
by Marvin 01 Aug '16

01 Aug '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24662 Your paranoid android. === w1064 (32 bit loader) === loader.c:2979: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2979: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2979: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2987: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 3: Wrong callback count: 0 loader.c:2987: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784

1 0

Wine's forked version of fontforge
by Jens Reyer 01 Aug '16

01 Aug '16

Hi, in Debian we're currently moving to enable the maintainer mode to e.g. rebuild Wine's TrueType fonts. AJ already warned us that this is risky: On 04/01/2016 04:54 AM, wine-bugs(a)winehq.org wrote: > https://bugs.winehq.org/show_bug.cgi?id=40391 > > --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- > There is definitely a risk too, particularly for fonts. They are supposed to be > built with our forked version of fontforge > (https://source.winehq.org/git/fontforge.git), that contains a couple of fixes > compared to the upstream version. I really appreciate that warning, thanks again! See a "short" explanation at the end of the mail, why we want to do this anyway. I'd like to figure out how to improve the resulting situation by getting the Wine changes to fontforge applied upstream (and/or in Debian). With "upstream" I mean github.com/fontforge. I will contact them in a later step. Wine and Debian are both using the quite old fontforge version 20120731-b, the patches apply cleanly in Debian. But upstream is actively developing and in Debian someone is working on packaging a recent version (not sure with what outcome, e.g. afaik there is at least one upstream regression blocking an update). Are there any plans in Wine to update to a newer version? Wine's fontforge has 4 changes. I recreated them based on AJ's merge for 20120731-b and by myself for 20160404 to get a *rough* picture of their current state (not tested and I'm absolutely no expert in this): 1. Various hacks to avoid putting timestamps in generated files (AJ). No relevant changes upstream, but there is some work going to allow one to specify the timestamp in order to get the build deterministic/reproducible. Would this make this patch obsolete? I don't know why upstream wants timestamps at all, nor what problems these cause for Wine. Is this Wine specific, or would it make sense to drop timestamping upstream, too? 2. - Avoid outputting trailing spaces in sfd files (AJ). About a third seems to be applied in 20160404. I assume the rest would still be relevant if Wine updated its fontforge version. Is this patch only relevant for creating fonts/glyphs, but not for building the TrueType fonts? Looks like a good candidate for forwarding to upstream. 3. Enable the width of individual bitmap strikes to be altered (Huw Davies). Since the import of upstream version 20120731-b this patch only has a third of its original size. Are the remaining Wine changes still necessary, or are they cruft? If still needed, I guess they should be pushed upstream. In 20160404 not much seems to have changed, but the containing file bitmapview.c was moved ("splitting ui code from fontforge/ to fontforgeexe/"). Same as above: is this only needed when creating fonts? Looks like a candidate for upstream. 4. Don't save the selected state. (Huw Davies) I found no relevant changes upstream. No idea about this. Why are we doing this? ---------------------- The Debian Free Software Guidelines [DFSG] (which are the fundamental basis for the Debian project) mandate that binaries must be accompanied by their source (which is usually ensured by building from source), and that you must be able to modify and redistribute the package with only the software available in Debian. The reasons for these are e.g. philosophical (empowering the user), QA (rebuilding if there was an issue in the build tools), reproducibility (recreate byte-by-byte-identically, e.g. to rule out attacks at a build machine or do QA) or security (a build from correct source code may be manipulated by specific compilers). The TrueType fonts are pre-built with a forked fontforge, which isn't (and very unlikely will ever be) in Debian. To package the pre-built fonts imo we would have to remove Wine from official Debian (main), and move it to the non/semi-official contrib section. For the same reason (AFAIK, I'm not the author of these changes) we're also regenerating opengl files, request code and unicode. This problem was ignored/missed in the past for the Debian Wine packages, yet this is no argument against fixing them now. We definitely don't want Wine removed from Debian, instead keep it in and get it there as good as possible. btw, we're also adding a patch (based on wine staging) to append '(Debian)' to the version string now. btw2, can you recommend some alternative free fonts to install (either as partial replacement or as extension to the Wine fonts)? Greets, and thanks in advance jre [DFSG] https://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg, see also the following chapter "The main archive area".

2 3

Re: [2/3] wininet: Start the first chunk as soon as we have some data.
by Jacek Caban 01 Aug '16

01 Aug '16

Hi Hans, On 19.07.2016 11:27, Hans Leidekker wrote: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/wininet/http.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 2c62d97..c4cf66b 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -2921,6 +2921,7 @@ static DWORD set_content_length(http_request_t *request) > !strcmpiW(encoding, szChunked)) > { > chunked_stream_t *chunked_stream; > + DWORD res; > > chunked_stream = heap_alloc(sizeof(*chunked_stream)); > if(!chunked_stream) > @@ -2935,6 +2936,12 @@ static DWORD set_content_length(http_request_t *request) > memcpy(chunked_stream->buf, request->read_buf+request->read_pos, request->read_size); > chunked_stream->buf_size = request->read_size; > request->read_size = request->read_pos = 0; > + > + res = start_next_chunk(chunked_stream, request); > + if (res != ERROR_SUCCESS) { > + heap_free(chunked_stream); > + return res; > + } It seems to me that you're fixing a problem is a wrong place. start_next_chunk should be called by HTTP_ReceiveRequestData via refill_read_buffer anyway. I'd suggest to investigate why it doesn't work in your case. Also, see the attached test. We shouldn't need any chunk to complete requests. It's an existing problem in current Wine, which may be unrelated to your problem, but having such blocking calls here is not a step in the right direction. Thanks, Jacek

2 2

Re: [4/6] msvcirt: Implement istream::operator>> for integers.
by Piotr Caban 01 Aug '16

01 Aug '16

Hi, On 08/01/16 12:40, Iván Matellanes wrote: > Signed-off-by: Iván Matellanes <matellanes.ivan(a)gmail.com> > --- > dlls/msvcirt/msvcirt.c | 90 ++++++++++++++++++++++++++---- > dlls/msvcirt/tests/msvcirt.c | 128 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 205 insertions(+), 13 deletions(-) It causes following compilation warnings: ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:4891:5: warning: this decimal constant is unsigned only in ISO C90 int n, int_out[] = {123456789, 0, 1, -500, 0x8000, 2147483646, 2147483647, -2147483647, -2147483648, -1}; ^ ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:4893:5: warning: this decimal constant is unsigned only in ISO C90 LONG l, long_out[] = {2147483647l, -2147483648l};

1 0

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL (try 2)
by Alexandre Julliard 01 Aug '16

01 Aug '16

Daniel Lehman <dlehman(a)esri.com> writes: > +@ extern ??_7?$num_put@_WV?$ostreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@6B@ MSVCP_num_put_wchar_vtable > +@ extern ??_7?$time_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@6B@ MSVCP_time_get_char_vtable > +@ stub ??_7?$time_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@6B@ > +@ stub ??_7?$time_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@6B@ These should be extern, not stub. There are several more similar cases. Please check other msvcp versions to see where we are using commented out extern declarations. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Fix some its vs it's typos
by Marvin 31 Jul '16

31 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24626 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: comctl32/tests: Avoid using memset() on RECTs.
by Nikolay Sivov 30 Jul '16

30 Jul '16

On 30.07.2016 22:55, Michael Stefaniuc wrote: > - memset(&r1, 0, sizeof r1); > - r1.left = LVIR_ICON; > + SetRect(&r1, LVIR_ICON, 0, 0, 0); I don't like this, I think it's better to use SetRect() when actual coordinates are used, and LVIR_* has special meaning.

2 2

Re: [PATCH 1/4] mpr: Implement local name automatic redirection for disks.
by Alexandre Julliard 29 Jul '16

29 Jul '16

Pierre Schweitzer <pierre(a)reactos.org> writes: > +done: > + if (redirect) > + ctxt->resource->lpLocalName = NULL; It looks quite suspicious to modify that input parameter and restore it at the end. You should probably use a copy instead. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 08/10] gdi32: Where possible directly access the DC instead of using GetCurrentObject().
by Alexandre Julliard 29 Jul '16

29 Jul '16

Huw Davies <huw(a)codeweavers.com> writes: > @@ -1039,7 +1039,7 @@ INT WINAPI SetGraphicsMode( HDC hdc, INT mode ) > } > release_dc_ptr( dc ); > /* font metrics depend on the graphics mode */ > - if (ret) SelectObject(dc->hSelf, GetCurrentObject(dc->hSelf, OBJ_FONT)); > + if (ret) SelectObject(dc->hSelf, dc->hFont); The bug was already present, but we shouldn't be accessing the dc after release. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32: Avoid using memset on RECTs.
by Nikolay Sivov 29 Jul '16

29 Jul '16

On 29.07.2016 13:24, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/comctl32/status.c | 4 ++-- > dlls/comctl32/tab.c | 7 ++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/dlls/comctl32/status.c b/dlls/comctl32/status.c > index 738c33b..08ca158 100644 > --- a/dlls/comctl32/status.c > +++ b/dlls/comctl32/status.c > @@ -127,8 +127,8 @@ STATUSBAR_ComputeHeight(STATUS_INFO *infoPtr) > * textHeight pixels large */ > HDC hdc = GetDC(infoPtr->Self); > RECT r; > - memset (&r, 0, sizeof (r)); > - r.bottom = max(infoPtr->minHeight, tm.tmHeight); > + > + SetRect(&r, 0, 0, 0, max(infoPtr->minHeight, tm.tmHeight)); > if (SUCCEEDED(GetThemeBackgroundExtent(theme, hdc, SP_PANE, 0, &r, &r))) > { > height = r.bottom - r.top; > diff --git a/dlls/comctl32/tab.c b/dlls/comctl32/tab.c > index 0ed9152..62e34f9 100644 > --- a/dlls/comctl32/tab.c > +++ b/dlls/comctl32/tab.c > @@ -373,12 +373,9 @@ static BOOL TAB_InternalGetItemRect( > TRACE("Not Visible\n"); > /* need to initialize these to empty rects */ > if (itemRect) > - { > - memset(itemRect,0,sizeof(RECT)); > - itemRect->bottom = infoPtr->tabHeight; > - } > + SetRect(itemRect, 0, 0, 0, infoPtr->tabHeight); > if (selectedRect) > - memset(selectedRect,0,sizeof(RECT)); > + SetRectEmpty(selectedRect); > return FALSE; > } > > You probably can remove null rect checks as well.

2 1

Re: [PATCH] msxml3: Implement IXMLParser GetParserState
by Nikolay Sivov 29 Jul '16

29 Jul '16

On 29.07.2016 12:43, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/msxml3/tests/xmlparser.c | 3 +++ > dlls/msxml3/xmlparser.c | 6 ++++-- > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/dlls/msxml3/tests/xmlparser.c b/dlls/msxml3/tests/xmlparser.c > index 51f2a27..32514e3 100644 > --- a/dlls/msxml3/tests/xmlparser.c > +++ b/dlls/msxml3/tests/xmlparser.c > @@ -144,6 +144,9 @@ static void create_test(void) > hr = IXMLParser_SetFlags(parser, 0); > ok(hr == S_OK, "Expected S_OK got 0x%08x\n", hr); > > + hr = IXMLParser_GetParserState(parser); > + ok(hr == XMLPARSER_IDLE, "got 0x%08x\n", hr); > + > IXMLParser_Release(parser); > } > > diff --git a/dlls/msxml3/xmlparser.c b/dlls/msxml3/xmlparser.c > index ca40b22..6fcdb82 100644 > --- a/dlls/msxml3/xmlparser.c > +++ b/dlls/msxml3/xmlparser.c > @@ -51,6 +51,7 @@ typedef struct _xmlparser > LONG ref; > > int flags; > + XML_PARSER_STATE state; > } xmlparser; > > static inline xmlparser *impl_from_IXMLParser( IXMLParser *iface ) > @@ -345,9 +346,9 @@ static HRESULT WINAPI xmlparser_GetParserState(IXMLParser *iface) > { > xmlparser *This = impl_from_IXMLParser( iface ); > > - FIXME("(%p)\n", This); > + TRACE("(%p)\n", This); > > - return E_NOTIMPL; > + return This->state; > } > > static HRESULT WINAPI xmlparser_Suspend(IXMLParser *iface) > @@ -447,6 +448,7 @@ HRESULT XMLParser_create(void **ppObj) > This->nodefactory = NULL; > This->input = NULL; > This->flags = 0; > + This->state = XMLPARSER_IDLE; > This->ref = 1; > > *ppObj = &This->IXMLParser_iface; > Do you have SDK headers for that interface? Having HRESULT for a state looks a bit weird.

2 1

Re: [PATCH 2/6] d3d9/tests: Add visual tests for locking vertexbuffers
by Patrick Rudolph 29 Jul '16

29 Jul '16

Am Thu, 28 Jul 2016 14:04:56 +0200 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > > + static const struct > > + { > > + const char *flags_s; > > + unsigned int flags; > > + DWORD usage; > > + BOOL unsyncronized; > > + BOOL todo; > > + BOOL broken; > > + } > > + /* Nvidia ignores D3DLOCK_NOOVERWRITE on non dynamic buffers, > > + * while AMD always accepts D3DLOCK_NOOVERWRITE on all > > buffers. */ > > + tests[] = > > + { > > + {"0", 0, 0, FALSE, FALSE, FALSE}, > > + {"0", 0, D3DUSAGE_DYNAMIC, FALSE, FALSE, FALSE}, > > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, 0, FALSE, > > FALSE, TRUE}, > > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, > > D3DUSAGE_DYNAMIC, TRUE, FALSE, FALSE}, > > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, 0, FALSE, FALSE, > > FALSE}, > > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, D3DUSAGE_DYNAMIC, > > FALSE, FALSE, FALSE}, > > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, 0, FALSE, > > FALSE, TRUE}, > > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, > > D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, 0, FALSE, > > FALSE, TRUE}, > > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, > > D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > > + }; > [...] > > + todo_wine_if (tests[i].todo) > > + { > > + ok(tests[i].unsyncronized == unsyncronized || > > broken(tests[i].broken), > > + "Expected buffer mapped %s. Flags = %s. Usage > > = %#x.\n", > > + tests[i].unsyncronized ? "unsyncronized" : > > "syncronized", tests[i].flags_s, tests[i].usage); > > + } > I assume the broken() is for the testbot, but the way this is written, > half the cases aren't really tested on Windows. Also, what makes these > fail on the testbot? > I can replace some of the broken test results with another flag for AMD behaviour. AMD allows D3DLOCK_NOOVERWRITE for non dynamic buffers on d3d9, too. I guess the WARP driver filters D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD calls. > > + timestamp1 = GetTickCount(); > > + > > + hr = IDirect3DDevice9_BeginScene(device); > > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > > + hr = IDirect3DDevice9_DrawPrimitive(device, > > D3DPT_TRIANGLESTRIP, 0, tri); > > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > > + hr = IDirect3DDevice9_EndScene(device); > > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > > + > > + /* dummy read to wait for GPU being done */ > > + color = getPixelColor(device, 160, 360); > > + > > + timestamp2 = GetTickCount(); > > + > > + /* Adjust buffer size for 1 second draw call duration */ > > + size = (size * 1000UL) / (timestamp2 - timestamp1 + 1); > Does this work reliably? GetTickCount() has very limited resolution, I > think there's a real chance that the draw will take only a fraction of > GetTickCount()'s resolution. Yes it does. I first thought about using timestamp queries, but those aren't supported on ddraw and d3d8 and are broken on my AMD test system, so I'm using GetTickCount instead. It allows to test to pass on fast systems (Intel Core i5 + HD6870) and slow systems (Intel Atom + Nvidia ION). The buffersize can't be hardcoded as the Windows driver nukes the display driver whenever a draw call takes more than a few seconds, which is the case when using huge buffers to make them pass on fast systems. Regards, Patrick

2 1

Re: wined3d: Add Nvidia GT 740M to the GPU list
by Henri Verbeet 29 Jul '16

29 Jul '16

On 28 July 2016 at 22:42, Jeremy Audiger <audiger(a)live.fr> wrote: > @@ -2158,6 +2160,7 @@ cards_nvidia_mesa[] = > {"NVF0", CARD_NVIDIA_GEFORCE_GTX780}, > {"NVE6", CARD_NVIDIA_GEFORCE_GTX770M}, > {"NVE4", CARD_NVIDIA_GEFORCE_GTX680}, > + {"NV108", CARD_NVIDIA_GEFORCE_GT740M}, > /* Fermi */ > {"NVD9", CARD_NVIDIA_GEFORCE_GT520}, > {"NVD7", CARD_NVIDIA_GEFORCE_820M}, The patch seems fine, but could you please add "NV108" above "NVF1" instead of below "NVE4"?

1 0

Re: [PATCH 2/2] DInput : Use vendor and product ids to generate product GUID like it's done on Windows
by Bruno Jesus 28 Jul '16

28 Jul '16

On Sat, Jul 23, 2016 at 8:01 AM, Corentin Rossignon <corossig(a)gmail.com> wrote: > Signed-off-by: Corentin Rossignon <corossig(a)gmail.com> > --- > dlls/dinput/joystick_linux.c | 34 +++++++++++++++++++++++++++++++--- > dlls/dinput/joystick_linuxinput.c | 27 +++++++++++++++++++++++++-- > 2 files changed, 56 insertions(+), 5 deletions(-) Formatting problem: bruno@Note:~/programs/wine$ git apply dinput2 dinput2:31: trailing whitespace. /* dinput2:35: trailing whitespace. * Data4 seems to be a constant. dinput2:104: trailing whitespace. /* dinput2:108: trailing whitespace. * Data4 seems to be a constant. warning: 4 lines add whitespace errors. > diff --git a/dlls/dinput/joystick_linux.c b/dlls/dinput/joystick_linux.c > index 90b7280..f8499ca 100644 > --- a/dlls/dinput/joystick_linux.c > +++ b/dlls/dinput/joystick_linux.c > @@ -77,6 +77,7 @@ struct JoyDev > { > char device[MAX_PATH]; > char name[MAX_PATH]; > + GUID guid_product; > > BYTE axis_count; > BYTE button_count; > @@ -122,6 +123,21 @@ static const GUID DInput_Wine_Joystick_GUID = { /* 9e573ed9-7734-11d2-8d4a-23903 > {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} > }; > > + > +/* > + * Construct the GUID in the same way of Windows doing this. > + * Data1 is concatenation of productid and vendorid. > + * Data2 and Data3 are NULL. > + * Data4 seems to be a constant. > + */ > +static const GUID DInput_Wine_Joystick_Constant_Part_GUID = { > + 0x000000000, > + 0x0000, > + 0x0000, > + {0x00, 0x00, 0x50, 0x49, 0x44, 0x56, 0x49, 0x44} > +}; > + > + Please remove all double blank lines in your changes in order to be more compatible with the surrounding code style.

3 4

Re: [PATCH 1/6] wined3d/resource: Add flag WINED3D_MAP_WRITEONLY
by Patrick Rudolph 28 Jul '16

28 Jul '16

Am Thu, 28 Jul 2016 14:04:48 +0200 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > > #define WINED3D_MAP_READONLY > > 0x0010 +#define > > WINED3D_MAP_WRITEONLY 0x0020 > But now the API is weird. What happens when both READONLY and > WRITEONLY are set? I think the d3d11 model makes more sense. Yes you are right. The patch is required to fix some of the d3d11 TODOs introduced in my tests, but you can ignore it for now. I'll add additional tests for it.

1 0

Re: wine-devel Digest, Vol 132, Issue 55
by Anton Baskanov 28 Jul '16

28 Jul '16

On Wed, Jul 27, 2016 at 11:07 PM, <wine-devel-request(a)winehq.org> wrote: > ---------- Forwarded message ---------- > From: Nikolay Sivov <bunglehead(a)gmail.com> > To: wine-devel(a)winehq.org > Cc: > Date: Wed, 27 Jul 2016 17:39:26 +0300 > Subject: Re: [PATCH 1/6] amstream: Fix AMAudioData::QueryInterface. > On 27.07.2016 15:51, Anton Baskanov wrote: > > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > > --- > > dlls/amstream/audiodata.c | 1 - > > dlls/amstream/tests/Makefile.in | 3 +- > > dlls/amstream/tests/audiodata.c | 67 > +++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 69 insertions(+), 2 deletions(-) > > create mode 100755 dlls/amstream/tests/audiodata.c > > Hi, Anton. > > Please keep tests in existing amstream.c file. > > + > > +static void test_query_interface(void) > > +{ > > + IUnknown *unknown = create_audio_data(); > > + IMemoryData *memory_data = NULL; > > + IAudioData *audio_data = NULL; > > + > > + HRESULT result = S_OK; > > result initialization is not needed; > > > + > > + result = IUnknown_QueryInterface(unknown, &IID_IMemoryData, (void > **)&memory_data); > > + ok(E_NOINTERFACE == result, "got 0x%08x\n", result); > > + if (S_OK == result) > > + { > > + IMemoryData_Release(memory_data); > > + } > > If it always fails, there's no reason add conditional Release. > > > + > > + result = IUnknown_QueryInterface(unknown, &IID_IAudioData, (void > **)&audio_data); > > + ok(S_OK == result, "got 0x%08x\n", result); > > + if (S_OK == result) > > + { > > + IAudioData_Release(audio_data); > > + } > > + > > + IUnknown_Release(unknown); > > +} > > Could you check if you can query IMemoryData from IAudioData? It seems > really weird if parent interface is not supported at all. > Hi, Nikolay. Thanks for the review! I've checked QueryInterface from IAudioData, and it also fails with IID_IMemoryData. I've fixed the issues and sent the updated patches.

1 0

Re: [PATCH 2/2 v4] ucrtbase: Add _get_narrow_winmain_command_line tests
by Dmitry Timoshkov 28 Jul '16

28 Jul '16

Piotr Caban <piotr(a)codeweavers.com> wrote: > + sprintf(cmd, "\"\"%c\"\"\"%s\" \t \"misc\" cmd", name[0], name+1); > + memset(&startup, 0, sizeof(startup)); > + startup.cb = sizeof(startup); > + CreateProcessA(path, cmd, NULL, NULL, TRUE, > + CREATE_DEFAULT_ERROR_MODE|NORMAL_PRIORITY_CLASS, > + NULL, NULL, &startup, &proc); > + winetest_wait_child_process(proc.hProcess); Thanks for adding the tests. It shouldn't be too hard to also test other white space characters, at least testing '\r' and '\n' would be nice to have. -- Dmitry.

2 10

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL
by Piotr Caban 28 Jul '16

28 Jul '16

On 07/27/16 21:49, Daniel Lehman wrote: > +@ stub ??$_Getvals@_W@?$time_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@IAAX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@IAEX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@DV?$istreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@IEAAX_WAEBV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@IAAX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@IAEX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@GV?$istreambuf_iterator@GU?$char_traits@G@std@@@std@@@std@@IEAAX_WAEBV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@IAAX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@IAEX_WABV_Locinfo@1@@Z > +@ stub ??$_Getvals@_W@?$time_get@_WV?$istreambuf_iterator@_WU?$char_traits@_W@std@@@std@@@std@@IEAAX_WAEBV_Locinfo@1@@Z Could you please add -arch specifiers to stub entries? Thanks, Piotr

1 0

Re: avifil32: Use debugstr_a() and debugstr_w() in TRACE() messages.
by Nikolay Sivov 28 Jul '16

28 Jul '16

I see it's Rejected on the patch list, it's indeed wrong, because you're tracing output parameters.

2 1

Re: [PATCH 2/6] d3d9/tests: Add visual tests for locking vertexbuffers
by Henri Verbeet 28 Jul '16

28 Jul '16

On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > + static const struct > + { > + const char *flags_s; > + unsigned int flags; > + DWORD usage; > + BOOL unsyncronized; > + BOOL todo; > + BOOL broken; > + } > + /* Nvidia ignores D3DLOCK_NOOVERWRITE on non dynamic buffers, > + * while AMD always accepts D3DLOCK_NOOVERWRITE on all buffers. */ > + tests[] = > + { > + {"0", 0, 0, FALSE, FALSE, FALSE}, > + {"0", 0, D3DUSAGE_DYNAMIC, FALSE, FALSE, FALSE}, > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE", D3DLOCK_NOOVERWRITE, D3DUSAGE_DYNAMIC, TRUE, FALSE, FALSE}, > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, 0, FALSE, FALSE, FALSE}, > + {"D3DLOCK_DISCARD", D3DLOCK_DISCARD, D3DUSAGE_DYNAMIC, FALSE, FALSE, FALSE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD", > + D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD, D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, 0, FALSE, FALSE, TRUE}, > + {"D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY", > + D3DLOCK_NOOVERWRITE | D3DLOCK_READONLY, D3DUSAGE_DYNAMIC, TRUE, TRUE, TRUE}, > + }; [...] > + todo_wine_if (tests[i].todo) > + { > + ok(tests[i].unsyncronized == unsyncronized || broken(tests[i].broken), > + "Expected buffer mapped %s. Flags = %s. Usage = %#x.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } I assume the broken() is for the testbot, but the way this is written, half the cases aren't really tested on Windows. Also, what makes these fail on the testbot? > + timestamp1 = GetTickCount(); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitive(device, D3DPT_TRIANGLESTRIP, 0, tri); > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > + > + /* dummy read to wait for GPU being done */ > + color = getPixelColor(device, 160, 360); > + > + timestamp2 = GetTickCount(); > + > + /* Adjust buffer size for 1 second draw call duration */ > + size = (size * 1000UL) / (timestamp2 - timestamp1 + 1); Does this work reliably? GetTickCount() has very limited resolution, I think there's a real chance that the draw will take only a fraction of GetTickCount()'s resolution.

1 0

Re: [PATCH 1/6] wined3d/resource: Add flag WINED3D_MAP_WRITEONLY
by Henri Verbeet 28 Jul '16

28 Jul '16

On 26 July 2016 at 19:09, Patrick Rudolph <siro(a)das-labor.org> wrote: > #define WINED3D_MAP_READONLY 0x0010 > +#define WINED3D_MAP_WRITEONLY 0x0020 But now the API is weird. What happens when both READONLY and WRITEONLY are set? I think the d3d11 model makes more sense.

1 0

Re: [PATCH 3/4] mpr: Implement WNetCancelConnection2W().
by Nikolay Sivov 28 Jul '16

28 Jul '16

On 27.07.2016 16:16, Pierre Schweitzer wrote: > > DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) > { > - FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); I think it's better to keep this as TRACE, also maybe change lpName -> name, dwFlags -> flags, fForce -> force. Flags are unused, so maybe some fixme message for them is appropriate. > + DWORD ret = WN_NO_NETWORK; > + DWORD index; > > - return WN_SUCCESS; > + if (providerTable != NULL) > + { > + for (index = 0; index < providerTable->numProviders; index++) > + { > + if(providerTable->table[index].getCaps(WNNC_CONNECTION) & > + WNNC_CON_GETCONNECTIONS) Shouldn't this be WNNC_CON_CANCELCONNECTION? > + { > + if (providerTable->table[index].cancelConnection) > + ret = providerTable->table[index].cancelConnection((LPWSTR)lpName, fForce); > + else > + ret = WN_NO_NETWORK; > + if (ret == WN_SUCCESS || ret == WN_OPEN_FILES) > + break; > + } According to docs, WN_OPEN_FILES happens when force == FALSE, does it make sense to handle it only in this case? Of course we have no easy way to test any of that. > + } > + } > + return ret; > }

1 0

Re: [PATCH 2/2] msvcp140: add sprintf
by Nikolay Sivov 28 Jul '16

28 Jul '16

> +#if _MSVCP_VER >= 140 > +int __cdecl sprintf(char *buf, const char *fmt, ...) > +{ > + int ret; > + __ms_va_list valist; > + __ms_va_start(valist, fmt); > + ret = __stdio_common_vsprintf(2, buf, -1, fmt, NULL, valist); > + __ms_va_end(valist); > + return ret; > +} > +#endif Are we missing patch 1/2 that adds msvcp140? Also won't it work the same if you forward it to MSVCRT_sprintf? If _common_ functions should actually be used, options should use existing private defines.

1 0

Re: [PATCH 3/3] ntdll: For Mac 64-bit, poke NtCurrentTeb()->ThreadLocalStoragePointer to the corresponding offset from %gs.
by Sebastian Lackner 28 Jul '16

28 Jul '16

On 27.07.2016 17:42, Ken Thomases wrote: > 64-bit Windows apps have hard-coded accesses to %gs:0x58 baked into them. They > need to find the ThreadLocalStoragePointer there. > > Technically, the gsbase register and the memory it points to belong to the > pthread implementation on macOS. It's used for the pthread TLS implementation. > Slot 11 (offset 0x58) is currently used for the implementation of the ttyname() > system library function. We do not anticipate that Wine or any of the system > libraries or frameworks it uses will call ttyname(). Furthermore, Apple has > made it so that future releases of macOS will no longer use that slot. So, we > hijack it for our purposes. > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > --- > dlls/ntdll/loader.c | 11 +++++++- > dlls/ntdll/signal_x86_64.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 72 insertions(+), 1 deletion(-) I'm not sure if I correctly understand the purpose of this patch. If you have to set %gs:0x58 to some specific value, why not just use an assembly instruction for that?

3 7

Re: [PATCH 2/6] d3drm: Implement IDirect3DRM*::CreateViewport. (v2 resend)
by Stefan Dösinger 27 Jul '16

27 Jul '16

On 2016-07-19 19:08, Aaryaman Vasishta wrote: > + if (FAILED(hr = IDirect3DRMDevice_QueryInterface(device, &IID_IDirect3DRMDevice3, (void **)&device3))) > + return hr; > + > + if (FAILED(hr = IDirect3DRMFrame_QueryInterface(camera, &IID_IDirect3DRMFrame3, (void **)&camera3))) > + { > + IDirect3DRMDevice3_Release(device3); > + return hr; > + } > + IDirect3DRMDevice_Release(device); > + IDirect3DRMFrame_Release(camera); This releases references you don't own. Same in the V2 -> V3 thunk. > + if (!device || !camera) > + return D3DRMERR_BADOBJECT; > + if (!viewport) > + return D3DRMERR_BADVALUE; These checks are redundant, Init() does that as well. > + ok(ref4 == frame_ref, "Expected ref4 == frame_ref, got frame_ref = %u, ref4 = %u.\n", frame_ref, ref4); > + > + device_ref = get_refcount((IUnknown *)device1); > + frame_ref = get_refcount((IUnknown *)frame); The get_refcount here seems redundant because you've just shown that it is back to where it used to be.

2 2

Re: [PATCH 1/6] d3drm: Implement IDirect3DRMViewport*::Init. (v7)
by Stefan Dösinger 27 Jul '16

27 Jul '16

On 2016-07-19 19:08, Aaryaman Vasishta wrote: > + memset(&mat, 0, sizeof(mat)); > + mat.dwSize = sizeof(mat); > + mat.diffuse.r = RGBA_GETRED(color) / 255.0f; > + mat.diffuse.g = RGBA_GETGREEN(color) / 255.0f; > + mat.diffuse.b = RGBA_GETBLUE(color) / 255.0f; > + mat.diffuse.a = RGBA_GETALPHA(color) / 255.0f; Doing this here seems questionable. What happens if the camera's background is changed after the viewport is created? You'll probably want to update the material property in viewport::clear(), or maybe in camera::SetSceneBackground. > + if (material) > + IDirect3DMaterial_Release(material); This will destroy the material, viewport::SetBackground doesn't addref it. > + hr = IDirect3DRMViewport_Init(viewport, device1, frame, rc.left, rc.top, rc.right + 1, rc.bottom + 1); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + hr = IDirect3DRMViewport_Init(viewport, device1, frame, rc.left, rc.top, rc.right + 1, rc.bottom); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + hr = IDirect3DRMViewport_Init(viewport, device1, frame, rc.left, rc.top, rc.right + 1, rc.bottom + 1); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); The first and third test are identical. > + IDirect3DRMDevice3_Release(device3); > + IDirect3DRMDevice_Release(device1); > + ref4 = get_refcount((IUnknown *)d3drm1); > + todo_wine ok(ref4 > initial_ref1, "Expected ref4 > initial_ref1, got initial_ref1 = %u, ref4 = %u.\n", initial_ref1, ref4); The ref4 > inital_ref1 check isn't all too surprising because frame3 still holds a reference to its d3drm parent. Though it seems the leaked reference added by the second Viewport::Init call gets released somewhere. The test doesn't exactly show where. It is possible that releasing the device frees it, or releasing the frame does it.

3 3

Re: [PATCH 3/6] d3drm: Implement IDirect3DRMViewport::GetDirect3DViewport. (resend)
by Stefan Dösinger 27 Jul '16

27 Jul '16

You have some lines > 120 characters in here. Otherwise looks good to me. On 2016-07-19 19:08, Aaryaman Vasishta wrote: > Signed-off-by: Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > --- > dlls/d3drm/tests/d3drm.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++- > dlls/d3drm/viewport.c | 18 ++++++++++--- > 2 files changed, 80 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 17cf2dd..fc0b6b4 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1474,12 +1474,13 @@ static void test_Viewport(void) > IDirect3DRMFrame3 *frame3; > IDirect3DRMViewport *viewport; > IDirect3DRMViewport2 *viewport2; > + IDirect3DViewport *d3d_viewport; > IDirect3DRMObject *obj, *obj2; > GUID driver; > HWND window; > RECT rc; > DWORD size, data, ref1, ref2, ref3, ref4; > - DWORD initial_ref1, initial_ref2, initial_ref3, device_ref, frame_ref, frame_ref2; > + DWORD initial_ref1, initial_ref2, initial_ref3, device_ref, frame_ref, frame_ref2, viewport_ref; > CHAR cname[64] = {0}; > > window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, 0, 0, 0, 0); > @@ -1641,13 +1642,47 @@ static void test_Viewport(void) > > hr = IDirect3DRM2_CreateViewport(d3drm2, device1, frame, rc.left, rc.top, rc.right, rc.bottom, &viewport); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRMViewport interface (hr = %x)\n", hr); > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + viewport_ref = get_refcount((IUnknown *)d3d_viewport); > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 > viewport_ref, "Expected ref4 > viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 == viewport_ref, "Expected ref4 == viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > IDirect3DRMViewport_Release(viewport); > + > hr = IDirect3DRM3_CreateViewport(d3drm3, device3, frame3, rc.left, rc.top, rc.right, rc.bottom, &viewport2); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRMViewport2 interface (hr = %x)\n", hr); > + hr = IDirect3DRMViewport2_GetDirect3DViewport(viewport2, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + viewport_ref = get_refcount((IUnknown *)d3d_viewport); > + hr = IDirect3DRMViewport2_GetDirect3DViewport(viewport2, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 > viewport_ref, "Expected ref4 > viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 == viewport_ref, "Expected ref4 == viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > IDirect3DRMViewport2_Release(viewport2); > > hr = IDirect3DRM_CreateViewport(d3drm1, device1, frame, rc.left, rc.top, rc.right, rc.bottom, &viewport); > ok(hr == D3DRM_OK, "Cannot get IDirect3DRMViewport interface (hr = %x)\n", hr); > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + viewport_ref = get_refcount((IUnknown *)d3d_viewport); > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 > viewport_ref, "Expected ref4 > viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 == viewport_ref, "Expected ref4 == viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > > hr = IDirect3DRMViewport_QueryInterface(viewport, &IID_IDirect3DRMObject, (void**)&obj); > ok(hr == D3DRM_OK, "expected D3DRM_OK (hr = %x)\n", hr); > @@ -1713,6 +1748,9 @@ static void test_Viewport(void) > ref4 = get_refcount((IUnknown *)d3drm3); > ok(ref4 == ref3, "Expected ref4 == ref3, got ref3 = %u, ref4 = %u.\n", ref3, ref4); > > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + > /* Test all failures together */ > hr = IDirect3DRMViewport_Init(viewport, NULL, frame, rc.left, rc.top, rc.right, rc.bottom); > ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > @@ -1740,6 +1778,18 @@ static void test_Viewport(void) > ref4 = get_refcount((IUnknown *)frame); > ok(ref4 > frame_ref, "Expected ref4 > frame_ref, got frame_ref = %u, ref4 = %u.\n", frame_ref, ref4); > > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + viewport_ref = get_refcount((IUnknown *)d3d_viewport); > + hr = IDirect3DRMViewport_GetDirect3DViewport(viewport, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 > viewport_ref, "Expected ref4 > viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 == viewport_ref, "Expected ref4 == viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + > hr = IDirect3DRMViewport_Init(viewport, device1, frame, rc.left, rc.top, rc.right, rc.bottom); > ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > > @@ -1768,6 +1818,9 @@ static void test_Viewport(void) > ref4 = get_refcount((IUnknown *)d3drm3); > ok(ref4 == ref3, "Expected ref4 == ref3, got ref3 = %u, ref4 = %u.\n", ref3, ref4); > > + hr = IDirect3DRMViewport2_GetDirect3DViewport(viewport2, &d3d_viewport); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + > hr = IDirect3DRMViewport2_Init(viewport2, NULL, frame3, rc.left, rc.top, rc.right, rc.bottom); > ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > hr = IDirect3DRMViewport2_Init(viewport2, device3, NULL, rc.left, rc.top, rc.right, rc.bottom); > @@ -1788,6 +1841,18 @@ static void test_Viewport(void) > ref4 = get_refcount((IUnknown *)frame3); > ok(ref4 > frame_ref2, "Expected ref4 > frame_ref2, got frame_ref2 = %u, ref4 = %u.\n", frame_ref2, ref4); > > + hr = IDirect3DRMViewport2_GetDirect3DViewport(viewport2, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + viewport_ref = get_refcount((IUnknown *)d3d_viewport); > + hr = IDirect3DRMViewport2_GetDirect3DViewport(viewport2, &d3d_viewport); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DViewport interface (hr = %#x).\n", hr); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 > viewport_ref, "Expected ref4 > viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + ref4 = get_refcount((IUnknown *)d3d_viewport); > + ok(ref4 == viewport_ref, "Expected ref4 == viewport_ref, got ref4 = %u, viewport_ref = %u.\n", ref4, viewport_ref); > + IDirect3DViewport_Release(d3d_viewport); > + > hr = IDirect3DRMViewport2_Init(viewport2, device3, frame3, rc.left, rc.top, rc.right, rc.bottom); > ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > > diff --git a/dlls/d3drm/viewport.c b/dlls/d3drm/viewport.c > index 730a1f5..09b0e83 100644 > --- a/dlls/d3drm/viewport.c > +++ b/dlls/d3drm/viewport.c > @@ -826,17 +826,27 @@ static D3DRMPROJECTIONTYPE WINAPI d3drm_viewport1_GetProjection(IDirect3DRMViewp > static HRESULT WINAPI d3drm_viewport2_GetDirect3DViewport(IDirect3DRMViewport2 *iface, > IDirect3DViewport **viewport) > { > - FIXME("iface %p, viewport %p stub!\n", iface, viewport); > + struct d3drm_viewport *viewport_object = impl_from_IDirect3DRMViewport2(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, viewport %p.\n", iface, viewport); > + > + if (!viewport_object->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + *viewport = viewport_object->d3d_viewport; > + IDirect3DViewport_AddRef(*viewport); > + > + return D3DRM_OK; > } > > static HRESULT WINAPI d3drm_viewport1_GetDirect3DViewport(IDirect3DRMViewport *iface, > IDirect3DViewport **viewport) > { > - FIXME("iface %p, viewport %p stub!\n", iface, viewport); > + struct d3drm_viewport *viewport_object = impl_from_IDirect3DRMViewport(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, viewport %p.\n", iface, viewport); > + > + return d3drm_viewport2_GetDirect3DViewport(&viewport_object->IDirect3DRMViewport2_iface, viewport); > } > > static HRESULT WINAPI d3drm_viewport2_TransformVectors(IDirect3DRMViewport2 *iface, >

1 1

Re: [PATCH 1/3] ntdll: For Mac 64-bit, poke the TEB address to %gs:0x30 and re-enable the inlining of NtCurrentTeb().
by Sebastian Lackner 27 Jul '16

27 Jul '16

On 27.07.2016 17:42, Ken Thomases wrote: > 64-bit Windows apps have hard-coded accesses to %gs:0x30 baked into them. They > need to find the TEB self pointer there. > > Technically, the gsbase register and the memory it points to belong to the > pthread implementation on macOS. It's used for the pthread TLS implementation. > However, study of the sources and experimentation reveal that TLS slot 6 > (offset 0x30) is not currently used. Furthermore, Apple has promised to not > use that slot in the future. So, we hijack it for our purposes. > > This removes the implementation of NtCurrentTeb() based on pthread_key_create() > and pthread_set/getspecific(). > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > --- > dlls/ntdll/ntdll.spec | 2 +- > dlls/ntdll/signal_x86_64.c | 34 +++------------------------------- > include/winnt.h | 2 +- > 3 files changed, 5 insertions(+), 33 deletions(-) Nice to hear that Apple agreed to keep that slot reserved. Would it make sense to keep the NtCurrentTeb export neverthless, for compatibility with libraries compiled against old Wine?

2 3

Re: [v2 PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line
by Dmitry Timoshkov 27 Jul '16

27 Jul '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +char* CDECL _get_narrow_winmain_command_line(void) > +{ > + static char *narrow_command_line; > + char *s; > + > + if (narrow_command_line) > + return narrow_command_line; > + > + s = GetCommandLineA(); > + if (*s == '"') > + { > + /* skip all leading quotes */ > + while (*++s == '"') > + ; > + /* skip everything up to next quote */ > + while (*s && *s++ != '"') > + ; > + } > + else > + { > + while (*s && *s != ' ' && *s != '\t') > + { > + /* allow embedded quoted blocks */ > + if (*s == '"') > + { > + s++; > + while (*s && *s++ != '"') > + ; > + } > + else > + s++; > + } > + } > + while (*s == ' ' || *s == '\t') > + s++; > + > + return narrow_command_line = s; > +} Once again: Where did you get an idea of such an implementation? Is this copied from some place or based on some other implementation? Why for instance simple 'return GetCommandLineA()' is not enough as an initial implementation? -- Dmitry.

2 4

Re: [PATCH 1/6] amstream: Fix AMAudioData::QueryInterface.
by Nikolay Sivov 27 Jul '16

27 Jul '16

On 27.07.2016 15:51, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > --- > dlls/amstream/audiodata.c | 1 - > dlls/amstream/tests/Makefile.in | 3 +- > dlls/amstream/tests/audiodata.c | 67 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 69 insertions(+), 2 deletions(-) > create mode 100755 dlls/amstream/tests/audiodata.c Hi, Anton. Please keep tests in existing amstream.c file. + > +static void test_query_interface(void) > +{ > + IUnknown *unknown = create_audio_data(); > + IMemoryData *memory_data = NULL; > + IAudioData *audio_data = NULL; > + > + HRESULT result = S_OK; result initialization is not needed; > + > + result = IUnknown_QueryInterface(unknown, &IID_IMemoryData, (void **)&memory_data); > + ok(E_NOINTERFACE == result, "got 0x%08x\n", result); > + if (S_OK == result) > + { > + IMemoryData_Release(memory_data); > + } If it always fails, there's no reason add conditional Release. > + > + result = IUnknown_QueryInterface(unknown, &IID_IAudioData, (void **)&audio_data); > + ok(S_OK == result, "got 0x%08x\n", result); > + if (S_OK == result) > + { > + IAudioData_Release(audio_data); > + } > + > + IUnknown_Release(unknown); > +} Could you check if you can query IMemoryData from IAudioData? It seems really weird if parent interface is not supported at all.

1 0

RE: MPR patches
by Hugh McMaster 27 Jul '16

27 Jul '16

On Wednesday, 27 July 2016, Pierre Schweitzer wrote: > Regarding 1. & 3. should I perform a resend with that changed, or should > I change it in the next patch I submit? > > For 2., this is done on purpose. Real implementation will come in a > later patch (already ready and tested here :-)). Personally, I'd submit your real implementation of WNetCancelConnection2W as patch 1 of 2. Then submit your implementation patch using the WCHAR * style as the second patch. But if you decide to keep to your original order, please change the style before sending. You should also rebase your patches on the latest git. Your current patch has an offset of -87 lines. As for your security certificate, although it doesn't prevent the patch from applying, it would be better removed, if possible. Le 27/07/2016 à 13:40, Hugh McMaster a écrit : > On Wednesday, 27 July 2016 6:40 AM, Pierre Schweitzer wrote: > >> Is there any reason why the MPR patches are left abandoned? There are >> others awaiting in my queue... > >> + PWSTR name = strdupAtoW(lpName); >> + if (!name) >> + return ERROR_NOT_CONNECTED; > > 1. New code should use the WCHAR * style. > > 2. All three functions call WNetCancelConnection2W, but that function is a stub: > > DWORD WINAPI WNetCancelConnection2W( LPCWSTR lpName, DWORD dwFlags, BOOL fForce ) > { > FIXME( "(%s, %08X, %d), stub\n", debugstr_w(lpName), dwFlags, fForce ); > > return WN_SUCCESS; > } > > 3. Your mail has a StartCom Secure Digital Certificate attached. This has been mangled, as can be seen at the bottom of your patch: http://source.winehq.org/patches/data/124723

2 1

MPR patches
by Pierre Schweitzer 27 Jul '16

27 Jul '16

Hi, Is there any reason why the MPR patches are left abandoned? There are others awaiting in my queue... Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 2

Re: [PATCH] ucrtbase: Expose the fabsf function on arm
by Piotr Caban 27 Jul '16

27 Jul '16

Hi Martin, On 07/26/16 12:19, Martin Storsjo wrote: > It isn't available in the x86 or x64 versions of ucrtbase.dll > or api-ms-win-crt-math-l1-1-0.dll, but exists (and gets used by > MSVC 2015) on arm. > --- > dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec | 1 + > dlls/ucrtbase/ucrtbase.spec | 1 + > 2 files changed, 2 insertions(+) you forgot to sign-off your patch. Except of that it looks good for me. Thanks, Piotr

1 0

Re: [PATCH 2/3 v2] kernel32/tests/loader: Add tests for fiber-local storage.
by Alexandre Julliard 27 Jul '16

27 Jul '16

John Sheu <sheu(a)google.com> writes: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/loader.c | 118 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 116 insertions(+), 2 deletions(-) Could you please rebase it against recent changes, and resend with a fixed sequence number so that it can run through the testbot? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 6/6] d3d11/tests: Add visual tests for locking vertexbuffers
by Marvin 26 Jul '16

26 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24541 Your paranoid android. === wvistau64 (32 bit d3d11) === d3d11: unhandled exception 0000087c at 75A2E743 === w2008s64 (32 bit d3d11) === d3d11: unhandled exception 0000087c at 7680E743 === w7u (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w7pro64 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w8 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w864 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === w1064 (32 bit d3d11) === d3d11: unhandled exception c0000005 at 004022D6 === wvistau64 (64 bit d3d11) === d3d11: unhandled exception 0000087c at 000000007765674D === w2008s64 (64 bit d3d11) === d3d11: unhandled exception 0000087c at 0000000076EA674D === w7pro64 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C === w864 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C === w1064 (64 bit d3d11) === d3d11: unhandled exception c0000005 at 000000000040217C

1 0

Re: [PATCH 5/6] d3d10core/tests: Add visual tests for locking vertexbuffers
by Marvin 26 Jul '16

26 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24540 Your paranoid android. === wvistau64 (32 bit device) === device: unhandled exception 00000879 at 75A2E743 === w2008s64 (32 bit device) === device: unhandled exception 00000879 at 7680E743 === w7u (32 bit device) === device: unhandled exception c0000005 at 00406895 === w7pro64 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w8 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w864 (32 bit device) === device: unhandled exception c0000005 at 00406895 === w1064 (32 bit device) === device: unhandled exception c0000005 at 00406895 === wvistau64 (64 bit device) === device: unhandled exception 00000879 at 000000007765674D === w2008s64 (64 bit device) === device: unhandled exception 00000879 at 0000000076EA674D === w7pro64 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40 === w864 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40 === w1064 (64 bit device) === device: unhandled exception c0000005 at 0000000000405C40

1 0

Re: [PATCH 4/6] ddraw/tests: Add visual tests for locking vertexbuffers
by Marvin 26 Jul '16

26 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24539 Your paranoid android. === w8 (32 bit visual) === visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000. === w864 (32 bit visual) === visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000. === w1064 (32 bit visual) === visual.c:307: Test failed: Clear rectangle 3(pos, neg) has color 0000ff00 visual.c:309: Test failed: Clear rectangle 1(pos, pos) has color 0000ff00 visual.c:311: Test failed: Clear rectangle 4(NULL) has color 0000ff00 visual.c:313: Test failed: Clear rectangle 4(neg, neg) has color 0000ff00 visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_DISCARDCONTENTS. dwCaps = 0x10000. visual.c:1688: Test failed: Expected buffer mapped unsyncronized. Flags = DDLOCK_NOOVERWRITE | DDLOCK_READONLY. dwCaps = 0x10000.

1 0

Re: [PATCH] msxml2: Share source with msxml3
by Alexandre Julliard 26 Jul '16

26 Jul '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/msxml2/Makefile.in | 49 ++++++++++++++++++++++++++++++++++++-- > dlls/msxml2/main.c | 63 ------------------------------------------------- > dlls/msxml2/msxml2.spec | 2 +- > 3 files changed, 48 insertions(+), 66 deletions(-) > delete mode 100644 dlls/msxml2/main.c Is there a real need for this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 3/8] wined3d: Implement SM5 deriv_rtx_coarse instruction.
by Matteo Bruni 26 Jul '16

26 Jul '16

2016-07-22 12:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>: > + if (!gl_info->supported[ARB_DERIVATIVE_CONTROL]) > + { > + FIXME("OpenGL implementation does not support ARB_derivative_control.\n"); > + return; > + } What about using the generic dFdx()/dFdy() builtins (maybe with a WARN) for the coarse and fine variants when ARB_derivative_control isn't supported? I don't know that it's particularly relevant in practice, it just seems something we don't need to strictly depend on.

2 1

Re: [PATCH 3/8] wined3d: Implement SM5 deriv_rtx_coarse instruction.
by Henri Verbeet 26 Jul '16

26 Jul '16

On 22 July 2016 at 12:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static void shader_glsl_derivative(const struct wined3d_shader_instruction *ins) > +{ > + const struct wined3d_gl_info *gl_info = ins->ctx->gl_info; > + struct wined3d_string_buffer *buffer = ins->ctx->buffer; > + struct glsl_src_param src_param; > + const char *instruction; > + DWORD write_mask; > + > + if (!gl_info->supported[ARB_DERIVATIVE_CONTROL]) > + { > + FIXME("OpenGL implementation does not support ARB_derivative_control.\n"); > + return; > + } > + > + switch (ins->handler_idx) > + { > + case WINED3DSIH_DSX_COARSE: instruction = "dFdxCoarse"; break; > + default: ERR("Unhandled opcode %#x.\n", ins->handler_idx); return; > + } > + > + write_mask = shader_glsl_append_dst(buffer, ins); > + shader_glsl_add_src_param(ins, &ins->src[0], write_mask, &src_param); > + shader_addline(buffer, "%s(%s));\n", instruction, src_param.param_str); > +} It doesn't matter that much, but is there any reason shader_glsl_map2gl() can't handle these?

2 1

Re: d3dx9_36: Fix a typo in TRACE() message.
by Matteo Bruni 25 Jul '16

25 Jul '16

2016-07-25 10:24 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > > + TRACE("pout %p, pv %p, pviewport %p, pprojection %p, pview %p, pworld %p\n", pout, pv, pviewport, pprojection, pview, pworld); While you're there, can you please clean up the function? Like dropping all the 'p' prefixes from the function arguments and using the current d3d style for the function body. Also the TRACE line seems a bit too long.

1 0

Re: include: Fix prototypes of D3DXFillXXXTextureTx for d3dx9.
by Matteo Bruni 25 Jul '16

25 Jul '16

2016-07-21 11:06 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > -HRESULT WINAPI D3DXFillTextureTX(struct IDirect3DTexture9 *texture, const DWORD *function, > - const D3DXVECTOR4 *constants, UINT numconstants); > -HRESULT WINAPI D3DXFillCubeTextureTX(struct IDirect3DCubeTexture9 *cube, const DWORD *function, > - const D3DXVECTOR4 *constants, UINT numconstants); > -HRESULT WINAPI D3DXFillVolumeTextureTX(struct IDirect3DVolumeTexture9 *volume, const DWORD *function, > - const D3DXVECTOR4 *constants, UINT numconstants); > +HRESULT WINAPI D3DXFillTextureTX(struct IDirect3DTexture9 *texture, ID3DXTextureShader *texture_shader); > +HRESULT WINAPI D3DXFillCubeTextureTX(struct IDirect3DCubeTexture9 *cube, ID3DXTextureShader *texture_shader); > +HRESULT WINAPI D3DXFillVolumeTextureTX(struct IDirect3DVolumeTexture9 *volume, ID3DXTextureShader *texture_shader); Do you know where the old prototypes came from? In all the versions of the header I have around (which go back to _30) I see the "new" prototype but it's possible that it changed even further back. It's also possible these have always been wrong, although that seems somewhat unlikely to me.

1 0

Re: [PATCH] d3dx9: Implement D3DXCreateTextureShader with stubbed ID3DXTextureShader interface.
by Matteo Bruni 25 Jul '16

25 Jul '16

2016-07-21 11:06 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > +HRESULT WINAPI D3DXCreateTextureShader(const DWORD *function, ID3DXTextureShader **texture_shader) > +{ > + struct d3dx9_texture_shader *object; > + > + TRACE("function %p, texture_shader %p.\n", function, texture_shader); > + > + if (!function || !texture_shader) > + return D3DERR_INVALIDCALL; > + > + object = HeapAlloc(GetProcessHeap(), 0, sizeof(*object)); > + if (!object) > + return E_OUTOFMEMORY; > + > + object->ID3DXTextureShader_iface.lpVtbl = &d3dx9_texture_shader_vtbl; > + object->ref = 1; > + > + *texture_shader = &object->ID3DXTextureShader_iface; > + > + return D3D_OK; > +} It would be nice to have a test for this.

1 0

Re: [PATCH] d3dx10: Add D3DXCpuOptimizations stub
by Alex Henrie 25 Jul '16

25 Jul '16

+ * Copyright (C) 2007 David Adam + * Copyright (C) 2007 Tony Wasserka Did these people actually contribute anything to this patch? +/* This guaud is the same as D3DX9 to prevent double-inclusion */ Did you mean "guard"? Also, D3DX_CPU_OPTIMIZATION was already defined in d3dx9_30_main.c. I would remove the old definition from d3dx9_30_main.c and make it include d3dx10math.h instead. -Alex

3 2

Re: [v3 PATCH] d3dx10: Add D3DXCpuOptimizations stub
by Matteo Bruni 25 Jul '16

25 Jul '16

2016-07-20 11:20 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: Hi Alistair, I'm afraid this is going to be a bit nitpicky. It also means the patch is mostly okay though. > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx10_43/d3dx10_43.spec | 2 +- > dlls/d3dx10_43/d3dx10_43_main.c | 11 +++++++-- > include/Makefile.in | 1 + > include/d3dx10.h | 1 + > include/d3dx10math.h | 49 +++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 61 insertions(+), 3 deletions(-) > create mode 100644 include/d3dx10math.h > > diff --git a/dlls/d3dx10_43/d3dx10_43.spec b/dlls/d3dx10_43/d3dx10_43.spec > index ab696e8..f410be8 100644 > --- a/dlls/d3dx10_43/d3dx10_43.spec > +++ b/dlls/d3dx10_43/d3dx10_43.spec > @@ -70,7 +70,7 @@ > @ stdcall D3DXColorAdjustSaturation(ptr ptr float) d3dx9_36.D3DXColorAdjustSaturation > @ stdcall D3DXComputeBoundingBox(ptr long long ptr ptr) d3dx9_36.D3DXComputeBoundingBox > @ stdcall D3DXComputeBoundingSphere(ptr long long ptr ptr) d3dx9_36.D3DXComputeBoundingSphere > -@ stub D3DXCpuOptimizations(long) > +@ stdcall D3DXCpuOptimizations(long) > @ stdcall D3DXCreateMatrixStack(long ptr) d3dx9_36.D3DXCreateMatrixStack > @ stdcall D3DXFloat16To32Array(ptr ptr long) d3dx9_36.D3DXFloat16To32Array > @ stdcall D3DXFloat32To16Array(ptr ptr long) d3dx9_36.D3DXFloat32To16Array > diff --git a/dlls/d3dx10_43/d3dx10_43_main.c b/dlls/d3dx10_43/d3dx10_43_main.c > index 0c1ff80..408cf22 100644 > --- a/dlls/d3dx10_43/d3dx10_43_main.c > +++ b/dlls/d3dx10_43/d3dx10_43_main.c > @@ -34,8 +34,8 @@ > #include "objbase.h" > > #include "d3d10_1.h" > -#include "d3dx10core.h" > -#include "d3dx10tex.h" > +#include "d3dx10.h" > + > > WINE_DEFAULT_DEBUG_CHANNEL(d3dx); No reason to add double whitespace lines here. > > @@ -210,3 +210,10 @@ HRESULT WINAPI D3DX10GetImageInfoFromMemory(const void *src_data, SIZE_T src_dat > > return E_NOTIMPL; > } > + > +D3DX_CPU_OPTIMIZATION WINAPI D3DXCpuOptimizations(BOOL enable) > +{ > + FIXME("enable %d stub.\n", enable); Can you please use %#x when tracing BOOL arguments? > +#include "d3dx10.h" > + > +/* This guard is the same as D3DX9 to prevent double-inclusion */ > +#ifndef __D3DX9MATH_H__ > +#define __D3DX9MATH_H__ > + > +#include <math.h> > + > + > +typedef enum _D3DX_CPU_OPTIMIZATION > +{ > + D3DX_NOT_OPTIMIZED = 0, > + D3DX_3DNOW_OPTIMIZED = 1, > + D3DX_SSE2_OPTIMIZED = 2, > + D3DX_SSE_OPTIMIZED = 3 > +} D3DX_CPU_OPTIMIZATION; I would go the other way and drop all the initializers instead. It's fine either way though. Also double whitespace again. > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +D3DX_CPU_OPTIMIZATION WINAPI D3DXCpuOptimizations(BOOL enable); > + > +#ifdef __cplusplus > +} > +#endif > + > + > +/*#include <d3dx10math.inl> */ I don't like this. Either introduce d3dx10math.inl and make this an actual include (preferred) or just remove the line for the time being.

1 0

Re: [PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line
by Piotr Caban 25 Jul '16

25 Jul '16

On 07/24/16 20:40, Nikolay Sivov wrote: > +/********************************************************************* > + * _get_narrow_winmain_command_line (UCRTBASE.@) > + */ > +char* CDECL _get_narrow_winmain_command_line(void) > +{ > + static char *narrow_command_line; > + char *s; > + > + if (narrow_command_line) > + return narrow_command_line; > + > + s = GetCommandLineA(); > + if (*s == '"') > + { > + s++; > + while (*s) > + if (*s++ == '"') > + break; > + } > + else > + { > + while (*s && *s != ' ' && *s != '\t') > + s++; > + } > + while (*s == ' ' || *s == '\t') > + s++; > + > + return narrow_command_line = s; > +} It will not work in following case (executable name "test ws.exe"): CMD> test" "ws.exe other args or CMD> """test ws.exe" other args Probably there's no real use case for that but it shouldn't be hard to handle this cases as well. Thanks, Piotr

2 1

Re: [v2] ntdll: Keep drive letter size in RtlGetFullPathName_U when full path is specified
by Alexandre Julliard 25 Jul '16

25 Jul '16

Piotr Caban <piotr(a)codeweavers.com> writes: > v2: > - fix cmd test failure Looks like there's another one I missed: ../../../tools/runtest -q -P wine -T ../../.. -M shell32.dll -p shell32_test.exe.so shelllink && touch shelllink.ok shelllink.c:251: Test failed: case doesn't match make: *** [shelllink.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] msxml2: Let msxml3 register Msxml2.DOMDocument
by Alexandre Julliard 25 Jul '16

25 Jul '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > When msxml3 is native, msxml2 forwards to msxml3 which then fails > to create an object. On Windows 8.1, Msxml2.DOMDocument > point to Msxml2.DOMDocument.3.0. That should be the case on Wine too. It sounds like there's something broken with your config. Note that mixing native and builtin is not a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 02/03 v4 ] ntoskrnl.exe: Track drivers created with IoCreateDriver
by Thomas Faber 25 Jul '16

25 Jul '16

> NTSTATUS WINAPI IoCreateDriver( UNICODE_STRING *name, PDRIVER_INITIALIZE init ) > { > - DRIVER_OBJECT *driver; > - DRIVER_EXTENSION *extension; > + struct wine_driver *driver; > NTSTATUS status; > > TRACE("(%s, %p)\n", debugstr_us(name), init); > > if (!(driver = RtlAllocateHeap( GetProcessHeap(), HEAP_ZERO_MEMORY, > - sizeof(*driver) + sizeof(*extension) ))) > + sizeof(*driver) ))) > return STATUS_NO_MEMORY; > > - if ((status = RtlDuplicateUnicodeString( 1, name, &driver->DriverName ))) > + if ((status = RtlDuplicateUnicodeString( 1, name, &driver->driver_obj.DriverName))) Missing space before the closing parenthesis here. ;p > { > RtlFreeHeap( GetProcessHeap(), 0, driver ); > return status; > } > @@ -892,13 +959,18 @@ NTSTATUS WINAPI IoCreateDriver( UNICODE_STRING *name, PDRIVER_INITIALIZE init ) > /*********************************************************************** > * IoDeleteDriver (NTOSKRNL.EXE.@) > */ > -void WINAPI IoDeleteDriver( DRIVER_OBJECT *driver ) > +void WINAPI IoDeleteDriver( DRIVER_OBJECT *driver_object ) > { > - TRACE("(%p)\n", driver); > + TRACE("(%p)\n", driver_object); > + > + EnterCriticalSection( &drivers_cs ); > + if (wine_drivers) > + wine_rb_remove( wine_drivers, &driver_object->DriverName ); > + LeaveCriticalSection( &drivers_cs ); > > - RtlFreeUnicodeString( &driver->DriverName ); > - RtlFreeUnicodeString( &driver->DriverExtension->ServiceKeyName ); > - RtlFreeHeap( GetProcessHeap(), 0, driver ); > + RtlFreeUnicodeString( &driver_object->DriverName ); > + RtlFreeUnicodeString( &driver_object->DriverExtension->ServiceKeyName ); > + RtlFreeHeap( GetProcessHeap(), 0, driver_object ); > } You need to free the wine_driver now rather than the DRIVER_OBJECT, i.e. use CONTAINING_RECORD. Thanks, Thomas

2 1

Re: [PATCH 1/4] dwrite: Implement newer SetLineSpacing/GetLineSpacing
by Marvin 25 Jul '16

25 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24498 Your paranoid android. === wvistau64 (32 bit layout) === The test timed out

2 1

Re: urlmon: Remove double riid parameter.
by Nikolay Sivov 25 Jul '16

25 Jul '16

> - hres = IServiceProvider_QueryService(This->serv_prov, riid, riid, &ret); > + hres = IServiceProvider_QueryService(This->serv_prov, riid, &ret); This won't build.

1 0

Re: [PATCH v2 2/3] shell32: Implement FolderItems_Item.
by Nikolay Sivov 25 Jul '16

25 Jul '16

On 22.07.2016 6:51, Alex Henrie wrote: > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 83 +++++++++++++++++++++++++++++++++++--- > dlls/shell32/tests/shelldispatch.c | 17 +++++--- > 2 files changed, 89 insertions(+), 11 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index ac79302..4b4c822 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -68,6 +68,8 @@ typedef struct { > typedef struct { > FolderItems3 FolderItems3_iface; > LONG ref; > + BSTR *item_paths; > + LONG item_count; > } FolderItemsImpl; > Is it possible we'll need special folder indices here as well? I didn't check thoroughly. > static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > { > - FIXME("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + VARIANT path; > + > + TRACE("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > > *ppid = NULL; > - return E_NOTIMPL; > + > + if (V_I4(&index) >= This->item_count) > + return S_FALSE; > + > + V_VT(&path) = VT_BSTR; > + V_BSTR(&path) = This->item_paths[V_I4(&index)]; > + > + return FolderItem_Constructor(&path, ppid); > } This is assuming you always have VT_I4 on input, but it's obviously possible to call it with any type. > > static HRESULT WINAPI FolderItemsImpl__NewEnum(FolderItems3 *iface, IUnknown **ppunk) > @@ -1139,9 +1157,17 @@ static const FolderItems3Vtbl FolderItemsImpl_Vtbl = { > FolderItemsImpl_get_Verbs > }; > > -static HRESULT FolderItems_Constructor(FolderItems **ppfi) > +static HRESULT FolderItems_Constructor(VARIANT *dir, FolderItems **ppfi) > { > + static const WCHAR backslash_star[] = {'\\','*',0}; > + static const WCHAR dot[] = {'.',0}; > + static const WCHAR dot_dot[] = {'.','.',0}; > FolderItemsImpl *This; > + WCHAR path[MAX_PATH]; > + HANDLE first_file; > + WIN32_FIND_DATAW file_info; > + BSTR *paths; > + HRESULT ret = S_OK; > > TRACE("\n"); > > @@ -1152,8 +1178,51 @@ static HRESULT FolderItems_Constructor(FolderItems **ppfi) > This->FolderItems3_iface.lpVtbl = &FolderItemsImpl_Vtbl; > This->ref = 1; > > + This->item_paths = HeapAlloc(GetProcessHeap(), 0, sizeof(BSTR)); > + if (!This->item_paths) > + { > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + This->item_count = 0; > + > + lstrcpyW(path, V_BSTR(dir)); > + lstrcatW(path, backslash_star); > + first_file = FindFirstFileW(path, &file_info); > + if (first_file != INVALID_HANDLE_VALUE) 'dir' is not necessary VT_BSTR.

2 1

Re: [PATCH] ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line
by Dmitry Timoshkov 25 Jul '16

25 Jul '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +char* CDECL _get_narrow_winmain_command_line(void) > +{ > + static char *narrow_command_line; > + char *s; > + > + if (narrow_command_line) > + return narrow_command_line; > + > + s = GetCommandLineA(); > + if (*s == '"') > + { > + s++; > + while (*s) > + if (*s++ == '"') > + break; > + } > + else > + { > + while (*s && *s != ' ' && *s != '\t') > + s++; > + } > + while (*s == ' ' || *s == '\t') > + s++; > + > + return narrow_command_line = s; > +} Where did you get an idea of sucn an implementation? -- Dmitry.

1 0

Re: [PATCH 1/2] DInput : Add vendor_id and product_id with Linux joystick API
by Bruno Jesus 23 Jul '16

23 Jul '16

On Sat, Jul 23, 2016 at 8:01 AM, Corentin Rossignon <corossig(a)gmail.com> wrote: > Signed-off-by: Corentin Rossignon <corossig(a)gmail.com> > --- > dlls/dinput/joystick_linux.c | 35 ++++++++++++++++++++++++++++++++++- > 1 file changed, 34 insertions(+), 1 deletion(-) Thanks for the patch, I just tested and they work with my gamepads. Since you will have to fix the problems below I suggest that you resend the 2 patches with subjects: [PATCH 1/2] dinput: Retrieve vendor ID and product ID in Linux joystick API [PATCH 2/2] dinput: Fix product GUID generation in Linux joystick and event API Formatting problem: bruno@Note:~/programs/wine$ git apply dinput1 dinput1:19: trailing whitespace. dinput1:68: trailing whitespace. } warning: 2 lines add whitespace errors. > + /* Find vendor_id and product_id in sysfs */ > + joydev.vendor_id = 0; > + joydev.product_id = 0; > + > + snprintf(sys_path, MAX_PATH, "/sys/class/input/js%d/device/id/vendor", i); > + sys_fd = open(sys_path, O_RDONLY); > + if (sys_path > 0) > + { Wrong variable in the condition. Best Regards, Bruno

1 0

[PATCH] dinput : use vendor and product ids to generate product GUID like it's done on Windows - second try
by Corentin Rossignon 23 Jul '16

23 Jul '16

Signed-off-by: Corentin Rossignon <corossig(a)gmail.com> --- dlls/dinput/joystick_linuxinput.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/dlls/dinput/joystick_linuxinput.c b/dlls/dinput/joystick_linuxinput.c index 86f12d0..3f9c241 100644 --- a/dlls/dinput/joystick_linuxinput.c +++ b/dlls/dinput/joystick_linuxinput.c @@ -96,6 +96,7 @@ struct JoyDev { char *device; char *name; GUID guid; + GUID guid_product; BOOL has_ff; int num_effects; @@ -293,11 +294,32 @@ static void find_joydevs(void) } if (ioctl(fd, EVIOCGID, &device_id) == -1) + { WARN("ioctl(EVIOCGID) failed: %d %s\n", errno, strerror(errno)); + joydev.guid_product = DInput_Wine_Joystick_Base_GUID; + } else { joydev.vendor_id = device_id.vendor; joydev.product_id = device_id.product; + + /* Construct the GUID in the same way of Windows doing this. + Data1 is concatenation of productid and vendorid. + Data2 and Data3 are NULL. + Data4 seems to be a constant. */ + joydev.guid_product.Data1 = (device_id.product << 16) + device_id.vendor; + + joydev.guid_product.Data2 = 0x0000; + joydev.guid_product.Data3 = 0x0000; + + joydev.guid_product.Data4[0] = 0x00; + joydev.guid_product.Data4[1] = 0x00; + joydev.guid_product.Data4[2] = 0x50; + joydev.guid_product.Data4[3] = 0x49; + joydev.guid_product.Data4[4] = 0x44; + joydev.guid_product.Data4[5] = 0x56; + joydev.guid_product.Data4[6] = 0x49; + joydev.guid_product.Data4[7] = 0x44; } if (!have_joydevs) @@ -327,7 +349,7 @@ static void fill_joystick_dideviceinstanceA(LPDIDEVICEINSTANCEA lpddi, DWORD ver lpddi->dwSize = dwSize; lpddi->guidInstance = joydevs[id].guid; - lpddi->guidProduct = DInput_Wine_Joystick_Base_GUID; + lpddi->guidProduct = joydevs[id].guid_product; lpddi->guidFFDriver = GUID_NULL; if (version >= 0x0800) @@ -348,7 +370,7 @@ static void fill_joystick_dideviceinstanceW(LPDIDEVICEINSTANCEW lpddi, DWORD ver lpddi->dwSize = dwSize; lpddi->guidInstance = joydevs[id].guid; - lpddi->guidProduct = DInput_Wine_Joystick_Base_GUID; + lpddi->guidProduct = joydevs[id].guid_product; lpddi->guidFFDriver = GUID_NULL; if (version >= 0x0800) -- 2.9.0

2 2

Re: joy.cpl: Display the correct number of button boxes during test
by DavidL 23 Jul '16

23 Jul '16

I noticed this as well - thanks! On Friday, July 22, 2016, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > After testing with an 8 button only joystick I noticed that currently > the program displays 9 buttons. Then I tested with an PS2 + usb > adapter controller and noticed that it is also off by one. I believe > nobody notices this because the gamepads have too many buttons > nowadays and you never test all of them. > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com <javascript:;>> >

1 0

Re: [PATCH] ws2_32: Implement InetNtopW
by Bruno Jesus 22 Jul '16

22 Jul '16

On Fri, Jul 22, 2016 at 5:16 PM, Philipp Hoppermann <plata(a)mailbox.org> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=40999 Thanks, I have written some tests to back your changes and will send soon, I also noticed a mistake in my review of your patch that I'll fix and send a new version.

1 0

Re: [PATCH 2/2] ws2_32: Fix implementation of InetNtopW.
by Bruno Jesus 22 Jul '16

22 Jul '16

On Fri, Jul 22, 2016 at 9:04 AM, Philipp Hoppermann <plata(a)mailbox.org> wrote: > Replaced call to inet_ntop by more elaborate solution. Looks much better, thanks. See the comments below. > Signed-off-by: Philipp Hoppermann <plata(a)mailbox.org> > --- > dlls/ws2_32/socket.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 4 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 0622060..2045163 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -7934,11 +7934,75 @@ INT WINAPI InetPtonW(INT family, PCWSTR addr, PVOID buffer) > } > > /*********************************************************************** > -* InetNtopW (WS2_32.@) > -*/ > -PCWSTR WINAPI InetNtopW(INT family, PVOID addr, PWSTR stringBuf, SIZE_T stringBufSize) > + * InetNtopW (WS2_32.@) > + * > + * Get string representation of IP address. > + * > + * PARAMS > + * family [I] AF_INET or AF_INET6 > + * addr [I] IP address in byte > + * buffer [O] IP address as string > + * buffer_len [O] length of the buffer in characters > + * > + * RETURNS > + * Success: IP address as string > + * Failure: NULL. Use GetLastError() to find the error cause. > + * > + * Error codes: > + * WSAEAFNOSUPPORT > + * - family is not AF_INET or AF_INET6 > + * ERROR_INVALID_PARAMETER > + * - buffer is NULL > + * - buffer_len is 0 > + * - buffer_len is too small > + * (i.e. < 16 for AF_INET or < 46 for AF_INET6) > + * > + */ Usually only overly complex functions need comments, which is not the case here so you can drop them. As you can see in the file most almost no other function has comments like this. > +PCWSTR WINAPI InetNtopW(INT family, PVOID addr, PWSTR buffer, SIZE_T buffer_len) > { > - return inet_ntop(family, addr, stringBuf, stringBufSize); > + char *bufferA; > + > + TRACE("family %d, addr %s, buffer (%p), buffer_len %lu\n", family, debugstr_w(addr), buffer, (unsigned long) buffer_len); WS_inet_ntop traces buffer_len without the cast using %ld, I guess it is better to follow its example and avoid the cast. > + // check family // comments are not allowed, please use /* */. But most of them are obvious like "check if buffer is NULL" so they can be dropped. > + if ((family != AF_INET) && (family != AF_INET6)) > + { > + SetLastError(WSAEAFNOSUPPORT); > + return NULL; > + } > + > + // check if buffer is NULL > + if (buffer == NULL) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return NULL; > + } > + > + // check buffer_len > + if ((family == AF_INET && buffer_len < 16) || (family == AF_INET6 && buffer_len < 46)) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return NULL; > + } WS_inet_ntop already does some error checking, there is no need to manually test again, also we trust the system inet_ntop call to deal with buffer_len check. > + // allocate memory for the string representation in char > + if (!(bufferA = HeapAlloc(GetProcessHeap(), 0, buffer_len*sizeof(WCHAR)))) > + { > + SetLastError(WSA_NOT_ENOUGH_MEMORY); > + return NULL; > + } You are doubling the required amount of memory, buffer_len should be already in characters, so no need to multiply. > + if (WS_inet_ntop(family, addr, bufferA, buffer_len*sizeof(WCHAR)) != NULL) Again no need to multiply. > + { > + // convert to wchar > + MultiByteToWideChar(CP_ACP, 0, bufferA, buffer_len*sizeof(WCHAR), buffer, buffer_len); Use: MultiByteToWideChar(CP_ACP, 0, bufferA, -1, buffer, buffer_len); > + > + HeapFree(GetProcessHeap(), 0, bufferA); > + return buffer; > + } else > + { > + return NULL; You are leaking bufferA in the else case, use a variable to store the results of WS_inet_ntop and return it instead so you can always HeapFree before the return and then there is no need for else. Best wishes, Bruno

1 0

Re: [PATCH 1/2] ws2_32: Implement InetNtopW.
by Bruno Jesus 22 Jul '16

22 Jul '16

On Fri, Jul 22, 2016 at 9:04 AM, Philipp Hoppermann <plata(a)mailbox.org> wrote: > Fixes "unimplemented function WS2_32.dll.InetNtopW" > > At the moment, this fix just calls inet_ntop It is not necessary to split the patch, specially because this patch is broken because of the char/WCHAR thing. Merge the spec changes in the 2/2 patch and see my other comments there.

1 0

Re: include: Improve include directive in d3dtypes.h.
by Henri Verbeet 22 Jul '16

22 Jul '16

On 22 July 2016 at 15:31, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > -#include <d3dvec.inl> > +#include "d3dvec.inl" Is that really an improvement? I'd argue these are system headers and angle brackets are correct. Of course in that case there are a couple of places where we'd want to change things in the other direction. Whether that's worth the trouble may be a different question.

1 0

Re: [v3 1/1] winejoystick.drv: Sort virtual joysticks by name on the Mac
by Ken Thomases 22 Jul '16

22 Jul '16

Hi, On Jul 20, 2016, at 2:15 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static CFStringRef copy_device_name(IOHIDDeviceRef device) > +{ > + CFTypeRef ref_name, ref_man; > + CFStringRef name; > + long prodID; I prefer variables to be declared at the narrowest scope in which they're used. > + > + if (device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(device)); > + > + ref_name = IOHIDDeviceGetProperty(device, CFSTR(kIOHIDProductKey)); > + > + if (ref_name && CFStringGetTypeID() == CFGetTypeID(ref_name)) > + name = CFStringCreateCopy(kCFAllocatorDefault,ref_name); > + else > + { > + ref_man = IOHIDDeviceGetProperty(device, CFSTR(kIOHIDManufacturerKey)); I think it's simpler to use kIOHIDVendorIDKey with get_device_property_long(). Judging by the HID Calibrator code, kIOHIDManufacturerKey is not reliably available, but kIOHIDVendorIDKey should be. It's also pretty fundamental to USB/HID. > + prodID = get_device_property_long(device, CFSTR(kIOHIDProductIDKey)); > + > + if(ref_man && CFStringGetTypeID() == CFGetTypeID(ref_man)) > + name = CFStringCreateWithFormat(kCFAllocatorDefault, NULL, CFSTR("%@ %lu"), ref_man, prodID); Better to format vendor and product IDs using "0x%04lx" since that's how they are usually represented (e.g. within HID Calibrator windows and System Profiler). (Yes, I realize that Copy_DeviceName() which I cited previously formats them as decimal.) Thanks for persevering in the face of my picky-ness. :) -Ken

2 1

Re: [3/6] msvcirt: Forward signed char exports to char functions directly
by Alexandre Julliard 22 Jul '16

22 Jul '16

"Iván Matellanes" <matellanesivan(a)gmail.com> writes: > signed char and char are equivalent in Visual C++, so specific functions for signed char are unnecessary. Note that you can't assume that 'char' is signed for the Unix compiler. If it makes a difference, you'd have to specify signed char explicitly. Otherwise, you could as well you the same functions for the unsigned case too. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v2 PATCH 4/4] hnetcfg: Add initial tests
by Marvin 22 Jul '16

22 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24452 Your paranoid android. === build (build) === Make failed

2 1

Re: [PATCH] dinput : use vendor and product ids to generate product GUID like it's done on Windows
by Bruno Jesus 22 Jul '16

22 Jul '16

On Thu, Jul 21, 2016 at 7:08 PM, Corentin Rossignon <corossig(a)gmail.com> wrote: > Signed-off-by: Corentin Rossignon <corossig(a)gmail.com> > --- > dlls/dinput/joystick_linuxinput.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/dinput/joystick_linuxinput.c b/dlls/dinput/joystick_linuxinput.c > index 86f12d0..e5172b6 100644 > --- a/dlls/dinput/joystick_linuxinput.c > +++ b/dlls/dinput/joystick_linuxinput.c > @@ -321,13 +321,19 @@ static void find_joydevs(void) > static void fill_joystick_dideviceinstanceA(LPDIDEVICEINSTANCEA lpddi, DWORD version, int id) > { > DWORD dwSize = lpddi->dwSize; > + // Data1 is concatenation of productid and vendorid, Data4 seems constant > + GUID product_guid = { ((joydevs[id].product_id)<<16)+joydevs[id].vendor_id, > + 0x0000, > + 0x0000, > + {0x00, 0x00, 0x50, 0x49, 0x44, 0x56, 0x49, 0x44} }; > + Hi, I'm not familiar with direct input code but I can say that // comments are not allowed, please use /* */ and send a try 2. Is there any easy way to test this patch? Like a simple app that displays such information so I can help testing in Windows and Wine?

2 2

Re: [v3 1/1] dinput: Sort virtual joysticks by name on the Mac
by Ken Thomases 22 Jul '16

22 Jul '16

On Jul 20, 2016, at 2:15 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 50 +++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 47 insertions(+), 3 deletions(-) Same comments as for the winejoystick version. -Ken

1 0

i need yor help
by achbarrr＠gmail.com 22 Jul '16

22 Jul '16

hello everyone i need your help i want wine for android why because i work in corel and photosop and msoffice but i want to do it on touchly os like android because my finger do best on it please send me an mail or email for that wine for android please

1 0

Re: [PATCH 2/2] winex11: track glx windows per thread
by Alexandre Julliard 21 Jul '16

21 Jul '16

Miklós Máté <mtmkls(a)gmail.com> writes: > XCloseDisplay in thread_detach() closes all X windows, but the GLX windows > remain, and become zombies. If a new X window is created with the same XID, > Mesa refuses to attach a GLX window to it because of the zombie. Observed > in the ddraw test. Is there a reason that creating the GLX window on the window thread wouldn't work? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] ws2_32: Implement InetNtopW.
by Bruno Jesus 21 Jul '16

21 Jul '16

On Thu, Jul 21, 2016 at 2:46 PM, Philipp Hoppermann <plata(a)mailbox.org> wrote: > Fixes "unimplemented function WS2_32.dll.InetNtopW" Hi, thanks for the patch. > At the moment, this fix just calls inet_ntop Unfortunately you can't do that. inet_ntop replies in char, not WCHAR. Please see how InetPtonW is implemented [1], by following its example you will be able to implement the function properly using WS_inet_ntop. http://source.winehq.org/git/wine.git/commitdiff/af8c79343ce9eb24e223607ec2… > Signed-off-by: Philipp Hoppermann <plata(a)mailbox.org> > --- > dlls/ws2_32/socket.c | 8 ++++++++ > dlls/ws2_32/ws2_32.spec | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index b0af3d7..0622060 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -7934,6 +7934,14 @@ INT WINAPI InetPtonW(INT family, PCWSTR addr, PVOID buffer) > } > > /*********************************************************************** > +* InetNtopW (WS2_32.@) > +*/ > +PCWSTR WINAPI InetNtopW(INT family, PVOID addr, PWSTR stringBuf, SIZE_T stringBufSize) Please change stringBuf to buffer and stringBufSize to buffer_len.

1 0

Re: ole32: Use debugstr_guid() in TRACE() messages.
by Michael Stefaniuc 21 Jul '16

21 Jul '16

Hello Andrey! On 07/21/2016 05:57 PM, Andrey Gusev wrote: > > ole32-Use-debugstr_guid-in-TRACE-messages.txt > > > From d360a701eee8b8cf715059d630163a7a21dc3222 Mon Sep 17 00:00:00 2001 > Message-Id: <d360a701eee8b8cf715059d630163a7a21dc3222.1469116606.git.andrey.goosev(a)gmail.com> > From: Andrey Gusev <andrey.goosev(a)gmail.com> > Date: Thu, 21 Jul 2016 18:56:32 +0300 > Subject: [PATCH] ole32: Use debugstr_guid() in TRACE() messages. > > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/ole32/classmoniker.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/ole32/classmoniker.c b/dlls/ole32/classmoniker.c > index 1bcf58f..00c2f42 100644 > --- a/dlls/ole32/classmoniker.c > +++ b/dlls/ole32/classmoniker.c > @@ -231,7 +231,7 @@ static HRESULT WINAPI ClassMoniker_BindToObject(IMoniker* iface, > IClassActivator *pActivator; > HRESULT hr; > > - TRACE("(%p,%p,%p,%p)\n", pbc, pmkToLeft, riid, ppvResult); > + TRACE("(%p,%p,%s,%p)\n", pbc, pmkToLeft, debugstr_guid(riid), ppvResult); > > bindopts.cbStruct = sizeof(bindopts); > IBindCtx_GetBindOptions(pbc, (BIND_OPTS *)&bindopts); > @@ -264,7 +264,7 @@ static HRESULT WINAPI ClassMoniker_BindToStorage(IMoniker* iface, > REFIID riid, > VOID** ppvResult) > { > - TRACE("(%p,%p,%p,%p)\n",pbc, pmkToLeft, riid, ppvResult); > + TRACE("(%p,%p,%s,%p)\n",pbc, pmkToLeft, debugstr_guid(riid), ppvResult); > return IMoniker_BindToObject(iface, pbc, pmkToLeft, riid, ppvResult); > } > > @@ -586,7 +586,7 @@ static HRESULT WINAPI ClassMonikerROTData_QueryInterface(IROTData *iface,REFIID > > ClassMoniker *This = impl_from_IROTData(iface); > > - TRACE("(%p,%p,%p)\n",iface,riid,ppvObject); > + TRACE("(%p,%s,%p)\n",iface,debugstr_guid(riid),ppvObject); While you work on this please fix also the whitespace issues in those lines: Space after ',' and line length should not exceed around 100 chars. > > return IMoniker_QueryInterface(&This->IMoniker_iface, riid, ppvObject); > } > -- 2.5.5 bye michael

1 0

Re: [PATCH 4/4] hnetcfg: Add stubbed INetFwPolicy2 interface
by Nikolay Sivov 21 Jul '16

21 Jul '16

On 21.07.2016 12:09, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/hnetcfg/apps.c | 1 + > dlls/hnetcfg/hnetcfg.c | 5 + > dlls/hnetcfg/hnetcfg_private.h | 2 + > dlls/hnetcfg/policy.c | 332 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 340 insertions(+) > > diff --git a/dlls/hnetcfg/apps.c b/dlls/hnetcfg/apps.c > index ea6d411..2b8d78c 100644 > --- a/dlls/hnetcfg/apps.c > +++ b/dlls/hnetcfg/apps.c > @@ -111,6 +111,7 @@ static REFIID tid_id[] = > &IID_INetFwOpenPort, > &IID_INetFwOpenPorts, > &IID_INetFwPolicy, > + &IID_INetFwPolicy2, > &IID_INetFwProfile > }; > > diff --git a/dlls/hnetcfg/hnetcfg.c b/dlls/hnetcfg/hnetcfg.c > index fadd367..e56dbab 100644 > --- a/dlls/hnetcfg/hnetcfg.c > +++ b/dlls/hnetcfg/hnetcfg.c > @@ -113,6 +113,7 @@ static const struct IClassFactoryVtbl hnetcfg_cf_vtbl = > static hnetcfg_cf fw_manager_cf = { { &hnetcfg_cf_vtbl }, NetFwMgr_create }; > static hnetcfg_cf fw_app_cf = { { &hnetcfg_cf_vtbl }, NetFwAuthorizedApplication_create }; > static hnetcfg_cf fw_openport_cf = { { &hnetcfg_cf_vtbl }, NetFwOpenPort_create }; > +static hnetcfg_cf fw_policy2_cf = { { &hnetcfg_cf_vtbl }, NetFwPolicy2_create }; > > BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID reserved) > { > @@ -151,6 +152,10 @@ HRESULT WINAPI DllGetClassObject( REFCLSID rclsid, REFIID iid, LPVOID *ppv ) > { > cf = &fw_openport_cf.IClassFactory_iface; > } > + else if (IsEqualGUID( rclsid, &CLSID_NetFwPolicy2 )) > + { > + cf = &fw_policy2_cf.IClassFactory_iface; > + } > > if (!cf) return CLASS_E_CLASSNOTAVAILABLE; > return IClassFactory_QueryInterface( cf, iid, ppv ); > diff --git a/dlls/hnetcfg/hnetcfg_private.h b/dlls/hnetcfg/hnetcfg_private.h > index bb3f3aa..812d970 100644 > --- a/dlls/hnetcfg/hnetcfg_private.h > +++ b/dlls/hnetcfg/hnetcfg_private.h > @@ -24,6 +24,7 @@ enum type_id > INetFwOpenPort_tid, > INetFwOpenPorts_tid, > INetFwPolicy_tid, > + INetFwPolicy2_tid, > INetFwProfile_tid, > last_tid > }; > @@ -33,6 +34,7 @@ void release_typelib(void) DECLSPEC_HIDDEN; > > HRESULT NetFwMgr_create(IUnknown *, LPVOID *) DECLSPEC_HIDDEN; > HRESULT NetFwPolicy_create(IUnknown *, LPVOID *) DECLSPEC_HIDDEN; > +HRESULT NetFwPolicy2_create(IUnknown *, void **) DECLSPEC_HIDDEN; It makes sense to test first if those two both support INetFwPolicy and INetFwPolicy2.

1 0

Re: [PATCH 3/4] hnetcfg: Register NetFwPolicy2 interface
by Nikolay Sivov 21 Jul '16

21 Jul '16

On 21.07.2016 12:09, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/hnetcfg/hnetcfg.idl | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/hnetcfg/hnetcfg.idl b/dlls/hnetcfg/hnetcfg.idl > index 9934f6a..763529a 100644 > --- a/dlls/hnetcfg/hnetcfg.idl > +++ b/dlls/hnetcfg/hnetcfg.idl > @@ -43,3 +43,11 @@ coclass NetFwAuthorizedApplication { interface INetFwAuthorizedApplications; } > uuid(0ca545c6-37ad-4a6c-bf92-9f7610067ef5) > ] > coclass NetFwOpenPort { interface INetFwOpenPort; } > + > +[ > + helpstring("HNetCfg.FwPolicy2"), > + progid("HNetCfg.FwPolicy2"), > + threading(both), > + uuid(e2b3c97f-6ae1-41ac-817a-f6f92166d7dd) > +] > +coclass NetFwPolicy2 { interface INetFwPolicy2; } > This doesn't have to be a separate patch.

1 0

Re: ntdll: Keep drive letter size in RtlGetFullPathName_U when full path is specified
by Alexandre Julliard 21 Jul '16

21 Jul '16

Piotr Caban <piotr(a)codeweavers.com> writes: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/ntdll/path.c | 2 +- > dlls/ntdll/tests/path.c | 9 +++++---- > 2 files changed, 6 insertions(+), 5 deletions(-) This is causing a test failure: ../../../tools/runtest -q -P wine -T ../../.. -M cmd.exe -p cmd.exe_test.exe.so batch && touch batch.ok batch.c:313: Test succeeded inside todo block: unexpected char 0x0 position -1 in line 983 (got 'c:\', wanted 'c:\') make[1]: *** [batch.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/6] msvcirt: Forward signed char exports to char functions directly
by Iván Matellanes 21 Jul '16

21 Jul '16

Oops, I messed up the numbering, this one should say [3/3]. On 21/07/16 10:56, Iván Matellanes wrote: > signed char and char are equivalent in Visual C++, so specific functions for signed char are unnecessary. > > Signed-off-by: Iván Matellanes <matellanes.ivan(a)gmail.com> > --- > dlls/msvcirt/msvcirt.c | 44 ++++++++++++++++---------------------------- > dlls/msvcirt/msvcirt.spec | 24 ++++++++++++------------ > 2 files changed, 28 insertions(+), 40 deletions(-)

1 0

Re: [PATCH 2/3] shell32: Implement FolderItems_Item.
by Nikolay Sivov 21 Jul '16

21 Jul '16

On 21.07.2016 7:45, Alex Henrie wrote: > static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > { > - FIXME("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + VARIANT path; > + struct list *node = list_head(&This->items); > + int i; > + > + TRACE("(%p,%s,%p)\n", iface, debugstr_variant(&index), ppid); > > *ppid = NULL; > - return E_NOTIMPL; > + > + if (!node) > + return S_FALSE; > + > + for (i = 0; i < V_I4(&index); i++) > + { > + node = list_next(&This->items, node); > + if (!node) > + return S_FALSE; > + } If it's only using indexed access, list is not a right data type.

1 0

Re: [PATCH 1/3] shell32/tests: Add more tests for FolderItems.
by Nikolay Sivov 21 Jul '16

21 Jul '16

On 21.07.2016 7:45, Alex Henrie wrote: > + for (i = 0; i < sizeof(file_defs)/sizeof(file_defs[0]); i++) > + { > + switch (file_defs[i].type) > + { > + case DIRECTORY: > + r = CreateDirectoryA(file_defs[i].name, NULL); > + ok(r, "file_defs[%d]: CreateDirectory failed: %08x\n", i, GetLastError()); > + break; > + > + case SHORTCUT: > + sl = NULL; > + r = CoCreateInstance(&CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, &IID_IShellLinkA, (void**)&sl); > + ok(SUCCEEDED(r), "file_defs[%d]: CoCreateInstance failed: %08x\n", i, r); > + ok(!!sl, "sl is null\n"); > + > + shortcut = NULL; > + r = IShellLinkA_QueryInterface(sl, &IID_IPersistFile, (void**)&shortcut); > + ok(r == S_OK, "file_defs[%d]: IShellLink::QueryInterface failed: %08x\n", i, r); > + ok(!!shortcut, "file_defs[%d]: shortcut is null\n", i); > + > + MultiByteToWideChar(CP_ACP, 0, file_defs[i].name, -1, wstr, sizeof(wstr)/sizeof(WCHAR)); > + r = IPersistFile_Save(shortcut, wstr, FALSE); > + ok(r == S_OK, "file_defs[%d]: IPersistFile::Save failed: %08x\n", i, r); > + > + IPersistFile_Release(shortcut); > + IShellLinkA_Release(sl); If you're only interested in IPersistFile you can request it directly when calling CoCreateInstance(). > + r = FolderItems_QueryInterface(items, &IID_FolderItems2, (void**)&items2); > + ok(r == S_OK || broken(E_NOINTERFACE) /* xp and later */, "FolderItems::QueryInterface failed: %08x\n", r); > + ok(!!items2 || broken(!items2) /* xp and later */, "items2 is null\n"); Second ok() is a bit meaningless, because it's expected to be consistent with previous return value test. I think it could be placed into if (r == S_OK), with broken() removed. > + > + bstr = NULL; > + r = FolderItem_get_Path(item, &bstr); > + ok(r == S_OK, "file_defs[%d]: FolderItem::get_Path failed: %08x\n", i, r); > + ok(!!bstr, "file_defs[%d]: bstr is null\n", i); > + > + bstr2 = NULL; > + r = FolderItem_get_Path(item, &bstr2); > + ok(r == S_OK, "file_defs[%d]: FolderItem::get_Path failed: %08x\n", i, r); > + ok(bstr2 != bstr, "file_defs[%d]: bstr and bstr2 are the same\n", i); > + SysFreeString(bstr2); This is a regular convention for [out] BSTR arguments. It only makes sense to explicitly test it if it differs from expected behavior. > + > + V_I4(&var) = sizeof(file_defs)/sizeof(file_defs[0]); > + item = NULL; > + r = FolderItems_Item(items, var, &item); > +todo_wine > + ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > + ok(!item, "item is not null\n"); > + > if (0) /* crashes on xp */ > { > r = FolderItems_get_Application(items, NULL); > @@ -422,12 +623,20 @@ todo_wine > ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); > } > > + verbs = (FolderItemVerbs*)0xdeadbeef; > r = FolderItems3_get_Verbs(items3, &verbs); > todo_wine > ok(r == S_FALSE, "expected S_FALSE, got %08x\n", r); > ok(!verbs, "verbs is not null\n"); > } > > + for (i = 0; i < sizeof(file_defs)/sizeof(file_defs[0]); i++) > + { > + if (file_defs[i].type == DIRECTORY) > + RemoveDirectoryA(file_defs[i].name); > + else > + DeleteFileA(file_defs[i].name); > + } Could this cleanup be merged with one of the loops you have earlier? >

1 0

Re: [PATCH 3/4] quartz: Try all surfaces when calling GetSurface
by Andrew Eikum 20 Jul '16

20 Jul '16

On Wed, Jul 20, 2016 at 02:37:11PM +1000, Jan Schmidt wrote: > If the surface we want is refused, cycle through all > possible ones. Some applications (Silver at least) > request 2 surfaces, but then refuse to return anything > other than the first one. > I'm not necessarily opposed to this, but it does seem unlikely that the application would request two surfaces be used, but only provide one. I noticed that we set num_surfaces to 2 in VMR9_maybe_init. Is this function calling IVMRSurfaceAllocatorEx9::InitializeDevice on the application-provided allocator, or on our default implementation? This seems like where the application should tell us it wants only one surface. If it is calling the application's allocator, then maybe they don't handle VMR9AllocationInfo::MinBuffers > 1 very well. Why do we set MinBuffers to 2 here, I wonder. Aric? Andrew > Signed-off-by: Jan Schmidt <jan(a)centricular.com> > --- > dlls/quartz/vmr9.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/vmr9.c b/dlls/quartz/vmr9.c > index d590a71..8455678 100644 > --- a/dlls/quartz/vmr9.c > +++ b/dlls/quartz/vmr9.c > @@ -292,6 +292,7 @@ static HRESULT WINAPI VMR9_DoRenderSample(BaseRenderer *iface, IMediaSample * pS > REFERENCE_TIME tStart, tStop; > VMR9PresentationInfo info; > HRESULT hr; > + int i; > > TRACE("%p %p\n", iface, pSample); > > @@ -338,10 +339,19 @@ static HRESULT WINAPI VMR9_DoRenderSample(BaseRenderer *iface, IMediaSample * pS > info.szAspectRatio.cx = This->bmiheader.biWidth; > info.szAspectRatio.cy = This->bmiheader.biHeight; > > - hr = IVMRSurfaceAllocatorEx9_GetSurface(This->allocator, This->cookie, (++This->cur_surface)%This->num_surfaces, 0, &info.lpSurf); > + /* Sometimes apps refuse to return the surface we request, > + * so try each and see if any are available if the first fails */ > + for (i = 0; i < This->num_surfaces; i++) { > + hr = IVMRSurfaceAllocatorEx9_GetSurface(This->allocator, This->cookie, > + (++This->cur_surface) % This->num_surfaces, 0, &info.lpSurf); > + if (SUCCEEDED (hr)) > + break; > + } > > - if (FAILED(hr)) > + if (FAILED(hr)) { > + ERR("Failed to get render surface (%x)\n", hr); > return hr; > + } > > VMR9_SendSampleData(This, &info, pbSrcStream, cbSrcStream); > IDirect3DSurface9_Release(info.lpSurf); > -- > 2.7.4 > > >

2 1

Re: [PATCH 1/5] wined3d: Fix immediate draws when ARB_vertex_array_bgra is not supported.
by Henri Verbeet 20 Jul '16

20 Jul '16

On 20 July 2016 at 00:33, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -5848,7 +5850,7 @@ static void wined3d_adapter_init_ffp_attrib_ops(struct wined3d_adapter *adapter) > ops->generic[WINED3D_FFP_EMIT_FLOAT2] = (wined3d_generic_attrib_func)gl_info->gl_ops.ext.p_glVertexAttrib2fv; > ops->generic[WINED3D_FFP_EMIT_FLOAT3] = (wined3d_generic_attrib_func)gl_info->gl_ops.ext.p_glVertexAttrib3fv; > ops->generic[WINED3D_FFP_EMIT_FLOAT4] = (wined3d_generic_attrib_func)gl_info->gl_ops.ext.p_glVertexAttrib4fv; > - if (gl_info->supported[ARB_VERTEX_ARRAY_BGRA]) > + if (!gl_info->supported[ARB_VERTEX_ARRAY_BGRA]) > ops->generic[WINED3D_FFP_EMIT_D3DCOLOR] = generic_d3dcolor; > else > ops->generic[WINED3D_FFP_EMIT_D3DCOLOR] = This looks wrong. When ARB_vertex_array_bgra is not supported, shaders swizzle the corresponding input registers (see also shader_glsl_swizzle_to_str() and shader_arb_get_swizzle()), so the attribute upload code shouldn't.

2 2

Re: [5/5] msvcirt: Implement istream::getdouble
by Marvin 20 Jul '16

20 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24393 Your paranoid android. === wxppro (32 bit msvcirt) === msvcirt.c:4839: Test failed: Test 48: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 49: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 50: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 51: wrong return, expected 4 got 5 msvcirt.c:4841: Test failed: Test 52: expected 2 got 0 msvcirt.c:4843: Test failed: Test 52: expected 003E601D got 003E601C msvcirt.c:4839: Test failed: Test 54: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 57: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 58: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 59: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 61: wrong return, expected 0 got 1 msvcirt.c:4839: Test failed: Test 62: wrong return, expected 1 got 2 === w2003std (32 bit msvcirt) === msvcirt.c:4839: Test failed: Test 48: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 49: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 50: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 51: wrong return, expected 4 got 5 msvcirt.c:4841: Test failed: Test 52: expected 2 got 0 msvcirt.c:4843: Test failed: Test 52: expected 003D60B5 got 003D60B4 msvcirt.c:4839: Test failed: Test 54: wrong return, expected 4 got 5 msvcirt.c:4839: Test failed: Test 57: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 58: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 59: wrong return, expected -1 got 0 msvcirt.c:4839: Test failed: Test 61: wrong return, expected 0 got 1 msvcirt.c:4839: Test failed: Test 62: wrong return, expected 1 got 2

1 0

Re: [PATCH 2/4] quartz: Images in Direct3D surfaces must be top-down
by Henri Verbeet 20 Jul '16

20 Jul '16

On 20 July 2016 at 06:37, Jan Schmidt <jan(a)centricular.com> wrote: > Invert images when copying to a Direct3D surface if > they are provided bottom-up. > Is that observable behaviour? I.e., could you write a test that verifies where the data ends up in the surface? If it isn't, it may be better to just flip the image when presenting it.

2 3

Re: [resend PATCH] msscript: Implement SetAdvise/GetAdvise
by Jacek Caban 20 Jul '16

20 Jul '16

Hi Nikolay, On 19.07.2016 20:42, Nikolay Sivov wrote: > -static HRESULT WINAPI ViewObject_SetAdvise(IViewObjectEx *iface, DWORD aspects, DWORD advf, IAdviseSink *sink) > +static HRESULT WINAPI ViewObject_SetAdvise(IViewObjectEx *iface, DWORD aspects, DWORD flags, IAdviseSink *sink) > { > ScriptControl *This = impl_from_IViewObjectEx(iface); > > - FIXME("(%p)->(%d %d %p)\n", This, aspects, advf, sink); > + TRACE("(%p)->(%d %#x %p)\n", This, aspects, flags, sink); > > - return E_NOTIMPL; > + if (aspects != DVASPECT_CONTENT) > + return DV_E_DVASPECT; Since only DVASPECT_CONTENT is supported and it's also a default value, is there a reason to bother storing it in the object? Thanks, Jacek

2 1

Re: [PATCH] kernel32: Implement SetConsoleFont
by Sebastian Lackner 20 Jul '16

20 Jul '16

On 19.07.2016 14:34, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/console.c | 27 ++++++++++++++++++++++++--- > dlls/kernel32/tests/console.c | 6 +++--- > 2 files changed, 27 insertions(+), 6 deletions(-) > It looks like your code requests the font size from the wineserver (GetConsoleFontSize) just to send it back immediately afterwards. Is that intentional? And wouldn't it make more sense to implement support for multiple font sizes first? Also, please note that the GetNumberOfConsoleFonts() check is unnecessary because GetConsoleFontSize() already takes care of that.

2 3

Re: hlink/tests: Use wine_dbgstr_guid() to print a REFIID.
by Marvin 20 Jul '16

20 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24381 Your paranoid android. === w1064 (32 bit hlink) === hlink.c:414: Test failed: url only: Saved data differs hlink.c:414: Test failed: url + friendly name: Saved data differs hlink.c:414: Test failed: url + friendly_name + location: Saved data differs hlink.c:414: Test failed: url + target frame name: Saved data differs === w1064 (64 bit hlink) === hlink.c:414: Test failed: url only: Saved data differs hlink.c:414: Test failed: url + friendly name: Saved data differs hlink.c:414: Test failed: url + friendly_name + location: Saved data differs hlink.c:414: Test failed: url + target frame name: Saved data differs

2 1

[v2 PATCH] d3dx10: Add D3DXCpuOptimizations stub
by Andrey Gusev 20 Jul '16

20 Jul '16

+#include <d3dx10.h> Please change to "d3dx10.h"

1 0

[v2 PATCH] d3dx10: Add D3DXCpuOptimizations stub
by Andrey Gusev 20 Jul '16

20 Jul '16

+#include <d3dx10.h> Please change to "d3dx10.h"

1 0

Re: [PATCH 02/11] mshtml: Use bind_to_tree callback to parse dynamically added scripts.
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24357 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH 01/11] mshtml/tests: Use relative URLs in navigation.js.
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24356 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH] msscript: Implement SetAdvise/GetAdvise
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24348 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: comctl32: Get rid of TOOLTIPS_SetMargin(), it is just a RECT assignment.
by Nikolay Sivov 19 Jul '16

19 Jul '16

On 19.07.2016 10:53, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/comctl32/tooltips.c | 15 ++------------- > 1 file changed, 2 insertions(+), 13 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index eed113e..a0c7ade 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1599,18 +1599,6 @@ TOOLTIPS_SetDelayTime (TOOLTIPS_INFO *infoPtr, DWORD duration, INT nTime) > } > > > -static LRESULT > -TOOLTIPS_SetMargin (TOOLTIPS_INFO *infoPtr, const RECT *lpRect) > -{ > - infoPtr->rcMargin.left = lpRect->left; > - infoPtr->rcMargin.right = lpRect->right; > - infoPtr->rcMargin.bottom = lpRect->bottom; > - infoPtr->rcMargin.top = lpRect->top; > - > - return 0; > -} > - > - > static inline LRESULT > TOOLTIPS_SetMaxTipWidth (TOOLTIPS_INFO *infoPtr, INT MaxWidth) > { > @@ -2261,7 +2249,8 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > return TOOLTIPS_SetDelayTime (infoPtr, (DWORD)wParam, (INT)LOWORD(lParam)); > > case TTM_SETMARGIN: > - return TOOLTIPS_SetMargin (infoPtr, (LPRECT)lParam); > + infoPtr->rcMargin = *(RECT*)lParam; > + return 0; > > case TTM_SETMAXTIPWIDTH: > return TOOLTIPS_SetMaxTipWidth (infoPtr, (INT)lParam); > I think this needs test to see if any rectangle is accepted, for example with negative values. If we need to validate it, it's easier to do in a helper to match the rest of code.

1 0

Re: [PATCH] kernel32: Implement SetConsoleFont
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24347 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2884226813 console.c:1445: Test failed: [15] Expected output count to be 0, got 2884226813 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2884226813 console.c:1689: Test failed: [13] Expected output count to be 0, got 2884226813 console.c:1689: Test failed: [15] Expected output count to be 0, got 2884226813 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2884226813 === w864 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 1106048744 console.c:1445: Test failed: [15] Expected output count to be 0, got 1106048744 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 1106048744 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 1106048744 console.c:1689: Test failed: [15] Expected output count to be 0, got 1106048744 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 1106048744 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 131584522 console.c:1445: Test failed: [15] Expected output count to be 0, got 131584522 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 131584522 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 131584522 console.c:1689: Test failed: [15] Expected output count to be 0, got 131584522 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 131584522 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w864 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

1 0

Re: [1/3] wininet: Don't return available data sizes larger than the read buffer.
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24338 Your paranoid android. === w864 (64 bit http) === http.c:5309: Test failed: HttpSendRequest failed: 8

2 1

Re: [v2 1/1] dinput: Sort virtual joysticks by name on the Mac
by Ken Thomases 19 Jul '16

19 Jul '16

On Jul 18, 2016, at 1:57 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > +static CFStringRef copy_device_name(IOHIDDeviceRef device) > +{ > + CFTypeRef ref; > + CFStringRef name = NULL; > + > + if(device) Maybe didn't notice this in the previous version, but put a space between "if" and the parenthesis. > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(device)); > + > + ref = IOHIDDeviceGetProperty(device, CFSTR(kIOHIDProductKey)); > + > + if (ref && CFStringGetTypeID() == CFGetTypeID(ref)) > + name = CFStringCreateCopy(kCFAllocatorDefault,ref); Please use a space after the comma in argument lists in function calls. > + else if (ref) > + name = CFCopyDescription(ref); > + else > + name = CFStringCreateCopy(kCFAllocatorDefault,CFSTR("(null)")); You don't want to fall back to a string based on the vendor and product ID? Also, the same spacing issue as above. > + } > + else > + ERR("Invalid Device requested %p\n",device); At this point, device is known to be NULL, so the log message can say that rather than the vague "invalid", and doesn't need to include its value. Or did you mean to be checking something else in the "if"? > + > + return name; > +} > + > static long get_device_location_ID(IOHIDDeviceRef device) > { > return get_device_property_long(device, CFSTR(kIOHIDLocationIDKey)); > @@ -203,7 +227,18 @@ static void copy_set_to_array(const void *value, void *context) > CFArrayAppendValue(context, value); > } > > -static CFComparisonResult device_location_comparator(const void *val1, const void *val2, void *context) > +static CFComparisonResult device_name_comparator(IOHIDDeviceRef device1, IOHIDDeviceRef device2) > +{ > + CFStringRef name1 = copy_device_name(device1), name2 = copy_device_name(device2); > + CFComparisonResult result = CFStringCompare(name1, name2, (kCFCompareForcedOrdering | kCFCompareNumerically)); > + if(name1) > + CFRelease(name1); > + if(name2) > + CFRelease(name2); If name1 or name2 might be NULL as these tests imply, then what does the preceding CFStringCompare() call do? Probably crashes. So, either assume/assure that copy_device_name() doesn't return NULL in normal operation or handle the possibility that it might more thoroughly. -Ken

2 2

Re: [PATCH 1/2] msctf: Don't crash on NULL input in EnumLanguageProfiles().
by Marvin 19 Jul '16

19 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24335 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:834: Test failed: Deactivation came unexpectedly

2 1

Re: shell32: add SHGetPropertyStoreForWindow stub (try 2)
by Nikolay Sivov 19 Jul '16

19 Jul '16

> +HRESULT WINAPI SHGetPropertyStoreForWindow(HWND hwnd, REFIID riid, void **ppv) > +{ > + FIXME("(%p %p %p) stub!\n", hwnd, riid, ppv); > + return E_NOTIMPL; > +} Not very important, but riid could be traced.

1 0

Re: [PATCH 7/7] d3d11/tests: Add test for bitwise shader instructions.
by Józef Kucia 19 Jul '16

19 Jul '16

On Mon, Jul 18, 2016 at 1:27 PM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + return uint4(~bits[0], ~(bits[0] & ~0u), ~bits[1], ~(bits[1] & ~0u)); This is a mistake. It should read "return uint4(~bits[0], ~(bits[0] ^ ~0u), ~bits[1], ~(bits[1] ^ ~0u));".

1 0

Re: [v2 1/1] winejoystick.drv: Sort virtual joysticks by name on the Mac
by Ken Thomases 19 Jul '16

19 Jul '16

On Jul 18, 2016, at 1:57 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 49 ++++++++++++++++++++++++++++++++---- > 1 file changed, 44 insertions(+), 5 deletions(-) Same comments as for the dinput version. -Ken

1 0

Re: [3/4] vcomp: Implement 8-bit atomic instructions.
by Alexandre Julliard 19 Jul '16

19 Jul '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/vcomp/main.c | 109 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/vcomp/vcomp.spec | 22 ++++---- > dlls/vcomp100/vcomp100.spec | 22 ++++---- > dlls/vcomp110/vcomp110.spec | 22 ++++---- > dlls/vcomp120/vcomp120.spec | 22 ++++---- > dlls/vcomp90/vcomp90.spec | 22 ++++---- > 6 files changed, 164 insertions(+), 55 deletions(-) It doesn't compile here (gcc 5.4.0): gcc -m32 -c -o main.o main.c -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror -g -O2 -fno-diagnostics-show-caret main.c: Assembler messages: main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%dil' main.c:246: Error: bad register name `%dil' main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%sil' main.c:246: Error: bad register name `%sil' Makefile:163: recipe for target 'main.o' failed make[1]: *** [main.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: add SHGetPropertyStoreForWindow stub
by Alex Henrie 18 Jul '16

18 Jul '16

@ stdcall SHGetPropertyStoreFromParsingName(wstr ptr long ptr ptr) +@ stdcall SHGetPropertyStoreForWindow(long ptr ptr) Switch these two lines to get alphabetical order. -Alex

1 0

Re: [PATCH] wined3d: Test and enable ARB_gpu_shader5 in shaders.
by Józef Kucia 18 Jul '16

18 Jul '16

As it was already mentioned the plan was to use GLSL 4.30 for shader model 5. However, it shouldn't be much of a burden to also support SM5 bitwise opcodes with ARB_gpu_shader5. Apart from that the other issue is that adding newer OpenGL extensions is generally blocked by bug 38648 [1]. The main reason is that it cannot be tested in the current version of Wine with drivers which do not support compatibility profiles. On Fri, Jul 15, 2016 at 2:25 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > + if (gl_info->supported[ARB_GPU_SHADER5]) > + shader_addline(buffer, "#extension GL_ARB_gpu_shader5 : enable\n"); > if (gl_info->supported[ARB_SHADER_BIT_ENCODING]) > shader_addline(buffer, "#extension GL_ARB_shader_bit_encoding : enable\n"); > if (gl_info->supported[ARB_SHADER_TEXTURE_LOD]) These should be sorted alphabetically. I guess the ARB_gpu_shader5 extension should also be added to the "core_extensions" table. [1] - https://bugs.winehq.org/show_bug.cgi?id=38648

3 5

Re: [PATCH] vcruntime140: Forward set_unexpected
by Piotr Caban 18 Jul '16

18 Jul '16

On 07/18/16 12:11, Alistair Leslie-Hughes wrote: > dlls/ucrtbase/ucrtbase.spec | 2 +- > dlls/vcruntime140/vcruntime140.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Please also update api-ms-win-crt-private-l1-1-0.spec file. Thanks, Piotr

1 0

Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.
by Józef Kucia 18 Jul '16

18 Jul '16

On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5e23920..376d110 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) > case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; > case WINED3DSIH_SQRT: instruction = "sqrt"; break; > case WINED3DSIH_UMAX: instruction = "max"; break; > + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; It looks like this should be in alphabetical order.

1 0

Re: [PATCH] wined3d: Implement SM5 f32tof16 opcode in glsl.
by Józef Kucia 18 Jul '16

18 Jul '16

A test would be nice to have. On Fri, Jul 15, 2016 at 1:37 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/arb_program_shader.c | 1 + > dlls/wined3d/glsl_shader.c | 38 ++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/shader_sm4.c | 2 ++ > dlls/wined3d/wined3d_private.h | 1 + > 4 files changed, 42 insertions(+) > > diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c > index 24c1194..9aa4252 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -5286,6 +5286,7 @@ static const SHADER_HANDLER shader_arb_instruction_handler_table[WINED3DSIH_TABL > /* WINED3DSIH_EQ */ NULL, > /* WINED3DSIH_EXP */ shader_hw_scalar_op, > /* WINED3DSIH_EXPP */ shader_hw_scalar_op, > + /* WINED3DSIH_F32TOF16 */ NULL, > /* WINED3DSIH_FRC */ shader_hw_map2gl, > /* WINED3DSIH_FTOI */ NULL, > /* WINED3DSIH_FTOU */ NULL, You need to add WINED3DSIH_F32TOF16 in other places as well, e.g. in shader.c. > + shader_addline(ins->ctx->buffer, "unpackHalf2x16(floatBitsToUint(%s)).x", src_param.param_str); You shouldn't need floatBitsToUint. shader_glsl_add_src_param() takes care about it when you set a proper type for the parameter. > + *dst_mask_ptr++ = dst_masks[i]; > + } else > + shader_addline(ins->ctx->buffer, "0"); > + > + if(i != NB_COMPS - 1) > + shader_addline(ins->ctx->buffer, ","); > + shader_addline(ins->ctx->buffer, "\n"); > + } > + > + *dst_mask_ptr++ = '\0'; You shouldn't need to construct dst_mask manually. > + shader_addline(ins->ctx->buffer, ")%s);\n", dst_mask); > +#undef NB_COMPS > +} > + > static void shader_glsl_else(const struct wined3d_shader_instruction *ins) > { > shader_addline(ins->ctx->buffer, "} else {\n"); > @@ -8704,6 +8741,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_EQ */ shader_glsl_relop, > /* WINED3DSIH_EXP */ shader_glsl_scalar_op, > /* WINED3DSIH_EXPP */ shader_glsl_expp, > + /* WINED3DSIH_F32TOF16 */ shader_glsl_f32tof16, > /* WINED3DSIH_FRC */ shader_glsl_map2gl, > /* WINED3DSIH_FTOI */ shader_glsl_to_int, > /* WINED3DSIH_FTOU */ shader_glsl_to_uint, > diff --git a/dlls/wined3d/shader_sm4.c b/dlls/wined3d/shader_sm4.c > index c8fdb32..6c15751 100644 > --- a/dlls/wined3d/shader_sm4.c > +++ b/dlls/wined3d/shader_sm4.c > @@ -215,6 +215,7 @@ enum wined3d_sm4_opcode > WINED3D_SM5_OP_DERIV_RTY_COARSE = 0x7c, > WINED3D_SM5_OP_DERIV_RTY_FINE = 0x7d, > WINED3D_SM5_OP_GATHER4_C = 0x7e, > + WINED3D_SM5_OP_F32TOF16 = 0x82, > WINED3D_SM5_OP_BFI = 0x8c, > WINED3D_SM5_OP_BFREV = 0x8d, > WINED3D_SM5_OP_SWAPC = 0x8e, > @@ -811,6 +812,7 @@ static const struct wined3d_sm4_opcode_info opcode_table[] = > {WINED3D_SM5_OP_DERIV_RTY_COARSE, WINED3DSIH_DSY_COARSE, "f", "f"}, > {WINED3D_SM5_OP_DERIV_RTY_FINE, WINED3DSIH_DSY_FINE, "f", "f"}, > {WINED3D_SM5_OP_GATHER4_C, WINED3DSIH_GATHER4_C, "f", "fRSf"}, > + {WINED3D_SM5_OP_F32TOF16, WINED3DSIH_F32TOF16, "f", "f"}, You should use "u" for the source parameters. Similar comments as to other patches also applies.

1 0

Re: [PATCH 1/2] wined3d: Implement SM5 bfi opcode in glsl.
by Józef Kucia 18 Jul '16

18 Jul '16

On Fri, Jul 15, 2016 at 1:53 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 72 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 71 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index d8edfdc..b0d3a91 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -4380,6 +4380,76 @@ static void shader_glsl_f32tof16(const struct wined3d_shader_instruction *ins) > #undef NB_COMPS > } This patch requires 124405 so it should be in the same series. > > + > +static void shader_glsl_bitfield_op(const struct wined3d_shader_instruction *ins) > +{ > +#define NB_COMPS 4 > + const DWORD write_masks[NB_COMPS] = { > + WINED3DSP_WRITEMASK_0, > + WINED3DSP_WRITEMASK_1, > + WINED3DSP_WRITEMASK_2, > + WINED3DSP_WRITEMASK_3, > + }; You shouldn't need this array. You can assume that WINED3DSP_WRITE_MASK_i = WINED3DSP_WRITE_MASK_0 << i. > + const char dst_masks[NB_COMPS] = { 'x', 'y', 'z', 'w' }; > + const char *prefix; > + const char *suffix; > + int nb_params; For consistency, this should be named "param_count" and should be unsigned int. > + struct glsl_src_param src_param; > + DWORD write_mask; > + char dst_mask[6]; > + char *dst_mask_ptr = dst_mask; > + > + switch(ins->handler_idx) > + { > + case WINED3DSIH_BFI: > + prefix = "bitfieldInsert("; > + suffix = ")"; > + nb_params = 4; > + break; > + > + default: > + prefix = "<unhandled opcode>"; > + suffix = ""; > + nb_params = 0; > + FIXME("Can't handle opcode %s.\n", debug_d3dshaderinstructionhandler(ins->handler_idx)); > + } > + > + write_mask = shader_glsl_append_dst(ins->ctx->buffer, ins); > + > + *dst_mask_ptr++ = '.'; > + shader_addline(ins->ctx->buffer, "uvec4(\n"); > + > + for (int i = 0; i < NB_COMPS; i++) This requires C99. > + { > + if (write_mask & write_masks[i]) > + { > + shader_addline(ins->ctx->buffer, "%s", prefix); > + for(int j = nb_params - 1; j >= 0; j--) > + { > + shader_glsl_add_src_param(ins, &ins->src[j], write_masks[i], &src_param); > + if(j <= 1) > + shader_addline(ins->ctx->buffer, "int(%s)", src_param.param_str); You shouldn't need this cast. It's better to adjust the parameter types and let shader_glsl_add_src_param() handle this. > + else > + shader_addline(ins->ctx->buffer, "%s", src_param.param_str); > + > + if(j) > + shader_addline(ins->ctx->buffer, ", "); > + } > + shader_addline(ins->ctx->buffer, "%s", suffix); > + *dst_mask_ptr++ = dst_masks[i]; > + } else > + shader_addline(ins->ctx->buffer, "0"); > + > + if(i != NB_COMPS - 1) > + shader_addline(ins->ctx->buffer, ","); > + shader_addline(ins->ctx->buffer, "\n"); > + } > + > + *dst_mask_ptr++ = '\0'; You shouldn't need to build dst_mask manually. > + shader_addline(ins->ctx->buffer, ")%s);\n", dst_mask); > +#undef NB_COMPS I don't like this duplicated enums. Generally, this implementation seems overly complicated. You should be able to do something similar to: for (i = 0; i < 4; ++i) { write_mask = WINED3DSP_WRITEMASK_0 << i; dst.write_mask = ins->dst[0].write_mask & write_mask; if (!(write_mask = shader_glsl_append_dst_ext(ins->ctx->buffer, ins, &dst, dst.reg.data_type))) continue; shader_glsl_add_src_param(ins, &ins->src[0], write_mask, &bits); shader_glsl_add_src_param(ins, &ins->src[1], write_mask, &offset); shader_glsl_add_src_param(ins, &ins->src[2], write_mask, &insert); shader_glsl_add_src_param(ins, &ins->src[3], write_mask, &base); shader_addline(ins->ctx->buffer, "bitfieldInsert(%s, %s, %s, %s));\n", base.param_str, insert.param_str, offset.param_str, bits.param_str); }

1 0

Re: [4/5] msvcirt: Implement istream::getline
by Piotr Caban 18 Jul '16

18 Jul '16

On 07/18/16 10:13, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(istream_getline, 16) > istream* __thiscall istream_getline(istream *this, char *str, int count, char delim) > { > - FIXME("(%p %p %d %c) stub\n", this, str, count, delim); > - return this; > + this->extract_delim++; > + return istream_get_str_delim(this, str, count, (unsigned char) delim); > } You probably need to call ios_lock before updating extract_delim. Thanks, Piotr

1 0

Re: [v1 1/1] dinput: Sort virtual joysticks by name on the Mac
by Ken Thomases 18 Jul '16

18 Jul '16

On Jul 16, 2016, at 3:15 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 35 ++++++++++++++++++++++++++++++++--- > 1 file changed, 32 insertions(+), 3 deletions(-) > > diff --git a/dlls/dinput/joystick_osx.c b/dlls/dinput/joystick_osx.c > index 637692b..22bdc4f 100644 > --- a/dlls/dinput/joystick_osx.c > +++ b/dlls/dinput/joystick_osx.c > @@ -193,6 +193,26 @@ static long get_device_property_long(IOHIDDeviceRef device, CFStringRef key) > return result; > } > > +static CFStringRef get_device_name(IOHIDDeviceRef device) > +{ > + CFTypeRef ref; > + CFStringRef name = CFSTR("Default Name"); You can probably do better for a fallback. For example, you can format the vendor ID and product ID into a string. For an extreme take on this, see the Copy_DeviceName() function in Apple's HID Calibrator sample code: https://developer.apple.com/library/mac/samplecode/HID_Calibrator/Listings/… > + > + if(device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(device)); > + > + ref = IOHIDDeviceGetProperty(device, CFSTR(kIOHIDProductKey)); > + > + if (ref && CFStringGetTypeID() == CFGetTypeID(ref)) > + name = ref; > + else if (ref) > + name = CFCopyDescription(ref); This introduces a memory-management problem, a.k.a. a leak. This copy is never released. If you follow my suggestion above for formatting a string as a fallback if the product name isn't available, you'd also have to release that. So, you would change this function's name to copy_device_name() and make sure all code paths return an owned reference to the caller, which the caller has to release. Basically, in the case where IOHIDDeviceGetProperty() gives you a string, you'd have to copy it to match the other code paths. Of course, you'd have to make sure the callers do, in fact, release the references. > + } > + > + return name; > +} > + > static long get_device_location_ID(IOHIDDeviceRef device) > { > return get_device_property_long(device, CFSTR(kIOHIDLocationIDKey)); > @@ -203,7 +223,15 @@ static void copy_set_to_array(const void *value, void *context) > CFArrayAppendValue(context, value); > } > > -static CFComparisonResult device_location_comparator(const void *val1, const void *val2, void *context) > +static CFComparisonResult device_name_comparator(IOHIDDeviceRef device1, IOHIDDeviceRef device2) > +{ > + CFStringRef name1 = get_device_name(device1), name2 = get_device_name(device2); > + CFStringCompareFlags compareOptions = kCFCompareForcedOrdering | kCFCompareNumerically; Any reason you've added this separate variable instead of just inlining the options in the call? > + > + return CFStringCompare(name1, name2, compareOptions); > +} -Ken

2 3

Re: [PATCH] winex11.drv: Use XRRSetScreenSize with XRRSetCrtcConfig
by Henri Verbeet 17 Jul '16

17 Jul '16

On 16 July 2016 at 00:48, Gabriel Corona <gabriel.corona(a)enst-bretagne.fr> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=33290 > > The nvidia driver is not so happy about using XRRSetCrtcConfig alone > and generates a panning configuration. We set the screen size > accordingly. Moreover we disable the CRT during the transition. > Updating the screen size isn't necessarily wrong, although avoiding panning is the wrong reason. If you don't want panning, make sure it doesn't get enabled in the first place. The main problem with this patch though, is that it's almost certainly wrong for multi-head configurations.

1 0

Re: [v1 1/1] winejoystick.drv: Sort virtual joysticks by name on the Mac
by Ken Thomases 17 Jul '16

17 Jul '16

On Jul 16, 2016, at 3:15 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 42 +++++++++++++++++++++++++++++++----- > 1 file changed, 37 insertions(+), 5 deletions(-) Same comments as for the dinput version. -Ken

1 0

Re: [PATCH] winegstreamer: Fixes for video flipping
by Andrew Eikum 16 Jul '16

16 Jul '16

Thanks very much for working on this, I'm glad to have more eyes looking at it. Comments in-line below. On Sat, Jul 16, 2016 at 02:51:10AM +1000, Jan Schmidt wrote: > The videoflip element doesn't handle all formats, > so some formats like Intel Indeo 3 will fail. > Add videoconvert to do format conversion when it's > needed. > Shouldn't the decodebin handle this during format negotiation when the videoflip is connected to it? > Fix some refcount issues too - add a new element > to a bin takes ownership of the floating reference, > so there's no need to keep pointers around to unref > later. > Good catch. Could you separate this out into a different, stand-alone patch from the other changes? > Fix state setting of new elements - always just > set them to PAUSED. gst_element_sync_state_with_parent() > can be problematic, and we only need these in paused > or playing anyway. > I'm not sure about this part. It makes sense to me for all members of a container to be in the same state. Why is it better for these to be PAUSED while others are PLAYING? If it's needed, this should be its own patch, too. > @@ -846,13 +855,16 @@ static void init_new_decoded_pad(GstElement *bin, GstPad *pad, GSTImpl *This) > > gst_util_set_object_arg(G_OBJECT(pin->flipfilter), "method", "vertical-flip"); > > - gst_bin_add(GST_BIN(This->container), pin->flipfilter); > - gst_element_sync_state_with_parent(pin->flipfilter); > + gst_element_set_state (vconv, GST_STATE_PAUSED); > + gst_bin_add(GST_BIN(This->container), vconv); /* bin takes ownership */ > + gst_element_set_state (pin->flipfilter, GST_STATE_PAUSED); > + gst_bin_add(GST_BIN(This->container), pin->flipfilter); /* bin takes ownership */ > > - pin->flip_sink = gst_element_get_static_pad(pin->flipfilter, "sink"); > + gst_element_link (vconv, pin->flipfilter); > + > + pin->flip_sink = gst_element_get_static_pad(vconv, "sink"); > if(!pin->flip_sink){ > WARN("Couldn't find sink on flip filter\n"); > - gst_object_unref(pin->flipfilter); I believe this leaves a dangling element in the container. Should these lines be replaced with calls to gst_bin_remove() instead? Andrew

2 2

Re: [PATCH 2/9] d3drm: Implement IDirect3DRMDevice*::InitFromD3D. (v2)
by Henri Verbeet 15 Jul '16

15 Jul '16

On 15 July 2016 at 12:32, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -3984,6 +3985,8 @@ static void test_create_device_from_d3d1(void) > ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u , ref2 = %u.\n", ref1, ref2); > device_ref2 = get_refcount((IUnknown *)d3ddevice1); > ok(device_ref2 > device_ref1, "Expected device_ref2 > device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); > + d3d_ref2 = get_refcount((IUnknown *)d3d1); > + ok(d3d_ref2 > d3d_ref1, "Expected d3d_ref2 > d3d_ref1, got d3d_ref1 = %u, d3d_ref2 = %u.\n", d3d_ref1, d3d_ref2); > ret_val = IDirect3DRMDevice_GetWidth(device1); > ok(ret_val == rc.right, "Expected device width = 300, got %u.\n", ret_val); > ret_val = IDirect3DRMDevice_GetHeight(device1); > @@ -4053,6 +4056,133 @@ static void test_create_device_from_d3d1(void) > device_ref2 = get_refcount((IUnknown *)d3ddevice1); > ok(device_ref2 == device_ref1, "Expected device_ref2 == device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); > > + /* InitFromD3D tests */ > + hr = IDirect3DRM_CreateObject(d3drm1, &CLSID_CDirect3DRMDevice, NULL, &IID_IDirect3DRMDevice, (void **)&device1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice interface (hr = %#x).\n", hr); > + > + hr = IDirect3DRMDevice_InitFromD3D(device1, NULL, d3ddevice1); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, NULL); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, d3ddevice1); > + ok(SUCCEEDED(hr), "Failed to initialise IDirect3DRMDevice interface (hr = %#x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u , ref2 = %u.\n", ref1, ref2); > + device_ref2 = get_refcount((IUnknown *)d3ddevice1); > + ok(device_ref2 > device_ref1, "Expected device_ref2 > device_ref1, got device_ref1 = %u, device_ref2 = %u.\n", device_ref1, device_ref2); I've just fixed some these up in the past, and let some others slide, but please watch your line length.

2 1

Fwd: Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.
by Guillaume Charifi 15 Jul '16

15 Jul '16

Right, I was sure to forget to git add something... Do I need to resend everything, or is it ok if I send a patch that only enables the required extension, and will need to be committed before the others? Le 15/07/2016 13:59, Józef Kucia a écrit : > On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi > <guillaume.charifi(a)sfr.fr> wrote: >> Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> >> --- >> dlls/wined3d/glsl_shader.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c >> index 5e23920..376d110 100644 >> --- a/dlls/wined3d/glsl_shader.c >> +++ b/dlls/wined3d/glsl_shader.c >> @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) >> case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; >> case WINED3DSIH_SQRT: instruction = "sqrt"; break; >> case WINED3DSIH_UMAX: instruction = "max"; break; >> + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; > I think this requires you to enable appriopriate extension in GLSL > (GL_ARB_gpu_shader5, in this case). I haven't looked closely at the > other patches but they seem to have the same issue.

1 0

Re: [PATCH] wined3d: Implement SM5 bfrev opcode in glsl.
by Józef Kucia 15 Jul '16

15 Jul '16

On Fri, Jul 15, 2016 at 1:25 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5e23920..376d110 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -3538,6 +3538,7 @@ static void shader_glsl_map2gl(const struct wined3d_shader_instruction *ins) > case WINED3DSIH_ROUND_Z: instruction = "trunc"; break; > case WINED3DSIH_SQRT: instruction = "sqrt"; break; > case WINED3DSIH_UMAX: instruction = "max"; break; > + case WINED3DSIH_BFREV: instruction = "bitfieldReverse"; break; I think this requires you to enable appriopriate extension in GLSL (GL_ARB_gpu_shader5, in this case). I haven't looked closely at the other patches but they seem to have the same issue.

2 1

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)
by Henri Verbeet 15 Jul '16

15 Jul '16

On 15 July 2016 at 12:32, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/viewport.c b/dlls/d3drm/viewport.c > index 9fd627d..743fb75 100644 > --- a/dlls/d3drm/viewport.c > +++ b/dlls/d3drm/viewport.c > @@ -270,19 +279,126 @@ static HRESULT WINAPI d3drm_viewport1_GetClassName(IDirect3DRMViewport *iface, D > static HRESULT WINAPI d3drm_viewport2_Init(IDirect3DRMViewport2 *iface, IDirect3DRMDevice3 *device, > IDirect3DRMFrame3 *camera, DWORD x, DWORD y, DWORD width, DWORD height) > { > - FIXME("iface %p, device %p, camera %p, x %u, y %u, width %u, height %u stub!\n", > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport2(iface); > + D3DVIEWPORT vp; > + D3DVALUE scale; > + IDirect3D *d3d1 = NULL; > + D3DCOLOR color; > + IDirect3DDevice *d3d_device = NULL; > + IDirect3DMaterial *material = NULL; > + D3DMATERIAL mat; > + D3DMATERIALHANDLE hmat; > + HRESULT hr = D3DRM_OK; > + ... > + color = IDirect3DRMFrame3_GetSceneBackground(camera); > + /* Create material (ambient/diffuse/emissive?), set material */ > + if (FAILED(hr = IDirect3D_CreateMaterial(d3d1, &material, NULL))) > + goto cleanup; > + > + memset(&mat, 0, sizeof(mat)); > + memcpy(&mat.diffuse, &color, sizeof(color)); That doesn't look right.

1 0

Re: [PATCH] msscript: Initial support for hosting script engines
by Jacek Caban 15 Jul '16

15 Jul '16

Hi Nikolay, On 14.07.2016 16:35, Nikolay Sivov wrote: > +static HRESULT init_script_host(const CLSID *clsid, ScriptHost **ret) > +{ > + IObjectSafety *objsafety; > + ScriptHost *host; > + HRESULT hr; > + > + *ret = NULL; > + > + host = heap_alloc(sizeof(*host)); > + if (!host) > + return E_OUTOFMEMORY; > + > + host->IActiveScriptSite_iface.lpVtbl = &ActiveScriptSiteVtbl; > + host->ref = 1; > + host->script = NULL; > + host->parse = NULL; > + host->clsid = *clsid; > + > + hr = CoCreateInstance(&host->clsid, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IActiveScript, (void**)&host->script); > + if (FAILED(hr)) { > + WARN("Failed to create an instance for %s, %#x\n", debugstr_guid(clsid), hr); > + goto failed; > + } > + > + hr = IActiveScript_QueryInterface(host->script, &IID_IObjectSafety, (void**)&objsafety); > + if (FAILED(hr)) { > + FIXME("Could not get IObjectSafety, %#x\n", hr); > + goto failed; > + } > + > + hr = IObjectSafety_SetInterfaceSafetyOptions(objsafety, &IID_IActiveScriptParse, INTERFACESAFE_FOR_UNTRUSTED_DATA, 0); > + if (FAILED(hr)) > + FIXME("SetInterfaceSafetyOptions failed, %#x\n", hr); This failure is important, please handle it well. > + IObjectSafety_Release(objsafety); > + > + hr = IActiveScript_SetScriptSite(host->script, &host->IActiveScriptSite_iface); > + if (FAILED(hr)) { > + WARN("SetScriptSite failed, %#x\n", hr); > + goto failed; > + } > + > + hr = IActiveScript_QueryInterface(host->script, &IID_IActiveScriptParse, (void**)&host->parse); > + if (FAILED(hr)) { > + WARN("Failed to get IActiveScriptParse, %#x\n", hr); > + goto failed; > + } This and... > + hr = IActiveScriptParse_InitNew(host->parse); > + if (FAILED(hr)) { > + WARN("InitNew failed, %#x\n", hr); > + goto failed; > + } ...this failure will cause ref leak. You have already set script site, so engine holds a reference to ScriptHost, but you only release one reference on failure. Using release_script_engine on failure should fix that. > + > + *ret = host; > + return S_OK; > + > +failed: > + IActiveScriptSite_Release(&host->IActiveScriptSite_iface); > + return hr; > +} > + > static HRESULT WINAPI ScriptControl_QueryInterface(IScriptControl *iface, REFIID riid, void **ppv) > { > ScriptControl *This = impl_from_IScriptControl(iface); > @@ -257,6 +498,10 @@ static ULONG WINAPI ScriptControl_Release(IScriptControl *iface) > if(!ref) { > if (This->site) > IOleClientSite_Release(This->site); > + if (This->host) { > + release_script_engine(This->host); > + IActiveScriptSite_Release(&This->host->IActiveScriptSite_iface); > + } > heap_free(This); > } > > @@ -321,15 +566,47 @@ static HRESULT WINAPI ScriptControl_Invoke(IScriptControl *iface, DISPID dispIdM > static HRESULT WINAPI ScriptControl_get_Language(IScriptControl *iface, BSTR *p) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + LPOLESTR progidW; > + HRESULT hr; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + if (!p) > + return E_POINTER; > + > + *p = NULL; > + > + if (!This->host) > + return S_OK; > + > + hr = ProgIDFromCLSID(&This->host->clsid, &progidW); > + if (FAILED(hr)) > + return hr; > + > + *p = SysAllocStringLen(progidW, lstrlenW(progidW)); How about SysAllocString instead? > + CoTaskMemFree(progidW); > + return *p ? S_OK : E_OUTOFMEMORY; > } > > static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR language) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(language)); > - return E_NOTIMPL; > + CLSID clsid; > + > + TRACE("(%p)->(%s)\n", This, debugstr_w(language)); > + > + if (language && FAILED(CLSIDFromProgID(language, &clsid))) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + if (This->host) { > + IActiveScriptSite_Release(&This->host->IActiveScriptSite_iface); > + This->host = NULL; > + } This will leave zombie script host and engine. You should probably use release_script_engine here as well. > + > + if (!language) > + return S_OK; > + > + return init_script_host(&clsid, &This->host); > } > > static HRESULT WINAPI ScriptControl_get_State(IScriptControl *iface, ScriptControlStates *p) > @@ -1379,6 +1656,7 @@ static HRESULT WINAPI ScriptControl_CreateInstance(IClassFactory *iface, IUnknow > script_control->ref = 1; > script_control->site = NULL; > script_control->cp_list = NULL; > + script_control->host = NULL; > > ConnectionPoint_Init(&script_control->cp_scsource, script_control, &DIID_DScriptControlSource); > ConnectionPoint_Init(&script_control->cp_propnotif, script_control, &IID_IPropertyNotifySink); > Thanks, Jacek

1 0

Re: [PATCH 4/9] d3drm: Implement IDirect3DRMViewport*::Init. (v5)
by Aaryaman Vasishta 15 Jul '16

15 Jul '16

On Fri, Jul 15, 2016 at 4:02 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > struct d3drm_viewport > { > struct d3drm_object obj; > + IDirect3DRMFrame *camera; > IDirect3DRMViewport IDirect3DRMViewport_iface; > IDirect3DRMViewport2 IDirect3DRMViewport2_iface; > + IDirect3DViewport *d3d_viewport; > + IDirect3DMaterial *material; > IDirect3DRM *d3drm; > D3DVALUE back; > D3DVALUE front; > I've decided to keep the interface instead of using the struct directly, since it'll be easier to use the interface functions for transformations and other paramaters. Referencing the interface via the object for every function call seems a bit redundant. Also I think refcounts should be handled seamlessly this way. A reference to the background material created internally is also kept here. As Stefan had pointed out, the material is not AddRef'd since its handle is used instead, so it's probably safer to keep the reference to ourselves and release it when the object is destroyed. Cheers, Aaryaman

2 2

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)
by Aaryaman Vasishta 14 Jul '16

14 Jul '16

CC'ing to wine-devel again. On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta < > jem456.vasishta(a)gmail.com> wrote: > >> >> >> On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger < >> stefandoesinger(a)gmail.com> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta: >>> > Anyways, the vtable qi tests tests written so far show that >>> > querying IDirect3DRMObject from a particular interface will return >>> > version 1 of that interface. So technically it all comes down to >>> > calling >>> > >>> IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, >>> > ...);. In our implementation of this method (see d3drm_main.c), we >>> > have passed version 1 of the relevant interface while calling the >>> > destroy callbacks within d3drm_object_destroy. The tests seem to >>> > agree with that implementation so far. >>> >> Also, I may have written the example incorrectly. You're right about the > fact that calling device3->AddDestroyCallback will pass device3 into this > function. But internally this interface will be QI'd to IDirect3DRMObject, > and then passed as the first parameter to the destroy callback itself. > >

2 2

Re: [PATCH 05/12] d3drm: Implement IDirect3DRMDevice*::InitFromD3D.
by Stefan Dösinger 14 Jul '16

14 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Patches 1-4 look good to me, once the fixes you mentioned and we talked about on IRC are implemented. Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > struct d3drm_frame > { > + struct d3drm_object obj; This seems unrelated. > + if (device->ddraw) > + hr = D3DRMERR_BADOBJECT; I guess you're not returning here right away because you want to addref d3drm later. Wouldn't it be better to move those AddRefs in front in this case? The QueryInterface / GetRenderTarget code below is unlikely to fail, if it does something is severely wrong (A d3d device without a render target???) and getting the reference leak right is the last of your worries. > device->width = desc.dwWidth; > device->height = desc.dwHeight; If I read the diff right this code will set width and height to 0 on an already initialized device. > static HRESULT WINAPI d3drm_device3_GetDirect3DDevice2(IDirect3DRMDevice3 *iface, IDirect3DDevice2 **d3d_device) > { > struct d3drm_device *device = impl_from_IDirect3DRMDevice3(iface); > + HRESULT hr; > > TRACE("iface %p, d3d_device %p.\n", iface, d3d_device); > > - IDirect3DDevice_QueryInterface(device->device, &IID_IDirect3DDevice2, (void**)d3d_device); > + if (FAILED(hr = IDirect3DDevice_QueryInterface(device->device, &IID_IDirect3DDevice2, (void**)d3d_device))) > + hr = D3DRMERR_BADOBJECT; > > - return D3DRM_OK; > + return hr; > } I think this change (like the device2_GetDirect3DDevice2 one) can be moved to a separate patch. > + hr = IDirect3DRMDevice_InitFromD3D(device1, d3d1, d3ddevice1); > + ok(hr == D3DRMERR_BADOBJECT, "Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", hr); > + ref3 = get_refcount((IUnknown *)d3ddevice1); > + ok(ref3 > device_ref2, "Expected ref3 > device_ref2, got ref3 = %u, device_ref2 = %u.\n", ref3, device_ref2); > + ref3 = get_refcount((IUnknown *)d3d1); > + ok(ref3 > d3d_ref2, "Expected ref3 > d3d_ref2, got ref3 = %u, d3d_ref2 = %u.\n", ref3, d3d_ref2); You forgot to test the reference of d3drm1. > + hr = IDirect3DRMDevice_QueryInterface(device1, &IID_IDirect3DRMDevice2, (void **)&device2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 Interface (hr = %x).\n", hr); > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + ok(SUCCEEDED(hr), "Expected hr == D3DRM_OK, got %#x.\n", hr); > + ok(d3ddevice2 == NULL, "Expected d3ddevice2 == NULL, got %p.\n", d3ddevice2); > + IDirect3DRMDevice2_Release(device2); You forgot d3ddevice2 = 0xdeadbeef here. > + hr = IDirect3DRM2_CreateObject(d3drm2, &CLSID_CDirect3DRMDevice, NULL, &IID_IDirect3DRMDevice2, (void **)&device2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMDevice2 interface (hr = %#x).\n", hr); > + > + hr = IDirectDraw_QueryInterface(ddraw1, &IID_IDirect3D, (void **)&d3d1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3D interface (hr = %x).\n", hr); > + if (SUCCEEDED(hr = IDirect3DDevice2_QueryInterface(d3ddevice2, &IID_IDirect3DDevice, (void **)&d3ddevice1))) > + { > + hr = IDirect3DRMDevice2_InitFromD3D(device2, d3d1, d3ddevice1); > + ok(hr == E_NOINTERFACE, "Expected hr == E_NOINTERFACE, got %#x.\n", hr); What happens if you QI IDirect3DRMDevice1 from IDirect3DRMDevice2 and call InitFromD3D on it? I would expect it to succeed because common decency suggests that CreateObject doesn't leave a history of which interface was requested and there's no CLSID_CDirect3DRMDevice2 or CLSID_CDirect3DRMDevice3. Still worth a check though I think. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgmxrAAoJEN0/YqbEcdMw9dQP/RbovFFjwIdo5ho2BcxWi1Sm 68U7n+sX+HAPmHPc2W/fOK1scbPaQz84e3cHj+dsFClCUKNLUpZ1eGdJDu1u9Fgh ZJVC9hgw8rzC+IDGr5vdmuzzOj65mI7KslJX9CfD9tnXigLtlvPf3me8jnhjL51b Eq8N1rStZTh805gDBEnmr/oqgQFkRoHKgs5lLIWq2inAfF3dq0BiThBGpC+eq19H YcihqOJWgSXrbXQYtTPjFtjp3jqqFa32+/ZQufCEAELcYUjM2gG23+O/rT5sa4d2 QuQOIhdUnTR9G6WnoZXgxKwxtJTvTu02GKlk5gaIkpWFJ2O+mPJuiBmylLoucQ6V BkYkhORuT2WYKainbTx3qNJaxBPSa5/y4HWTpQhzYH0LryFBLkL8MiVjO+pGk7QM 4wHTeL4ZXmjtyYOs6qfuxNIEJyfDs0hU5850lWdVD6MLaj3JwZYRLedCJ9TwV7Jb Qz3JQIK6YPOgTSqehIGTwzxgcbvjjiLP2zalEV4HOIqKeEkodcBxVS0QiXSDbuAj gLhbqwlRMshT5Dtt1Umi2KUoGljFjh1rbe42cyVxXcoa72D+g9LQUb4d0hUP/Ppt 6lNhfq+Vf2W+FmdB2Hv/WWof7vBV59r/TwjjExrN00yRGCLNLF3BaK8lzjeJprGO H6J9OAsscEyzMNpB+l0W =exYP -----END PGP SIGNATURE-----

2 3

Re: Testbot 3D tests broken
by Patrick Rudolph 14 Jul '16

14 Jul '16

On 2016-07-13 09:53 PM, Matteo Bruni wrote: > 2016-07-12 17:51 GMT+02:00 Patrick Rudolph <siro(a)das-labor.org>: >> Hi, >> can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. >> Other 3D tests might be affected, too. >> As you can see here it reports no test failures, but it skipped all >> tests: >> https://testbot.winehq.org/JobDetails.pl?Key=24151 >> https://testbot.winehq.org/JobDetails.pl?Key=24150 > > Not sure if you already got an answer on IRC or elsewhere. Anyway, the > tests are actually executed on OS versions with the WARP device > available, i.e. Win8 and newer. WARP device doesn't entirely match > "usual" hardware devices WRT test results and since we really only > care to match hardware behavior (but we still want the tests to pass > on the testbot) there are a number of hacks in the tests. > Should I don't care about pre Win8 test results ? Both, d3d8 and d3d9 games, are likely to be used with WinXp or Win7. Does it make sense to test them on Win8 or newer ? As likely every wine user is running wined3d on real hardware, shouldn't there be test systems that have real GPUs ? >> Regards, >> Patrick

2 1

Re: kernel32: Overhaul the handling of argv in set_process_name().
by Sebastian Lackner 14 Jul '16

14 Jul '16

On 12.07.2016 06:44, Ken Thomases wrote: > This fixes several problems with the code: > > * The code had been assuming that the argument strings pointed to by the argv > array are contiguous iff certain process-name-setting functions are available. > This doesn't seem reliable. Instead, test if it's true and shift the strings > if so. Thanks for working on this, looks indeed like a nice improvement. > > However, setproctitle() is specifically documented as a preferred alternative > to the technique of overwriting the arg strings, so don't shift the strings > if that's available. Wouldn't it make sense to remove the directory component also in this case, to be consistent? By moving the code to the bottom all functions would be called in the same way. > > * Use the last path component, recognizing backslash as a path separator, for > setprogname() in addition to prctl(). First, setprogname() is documented as > searching for the last component itself, but it doesn't understand Windows- > style paths, so we need to help it. Second, on some platforms (e.g. macOS), > setprogname(), like prctl(), has a fairly small internal length limit (e.g. > 32 characters). So, concentrate on the most meaningful part of the path. > > * Remove argv[0] from argv whether or not there are any process-name-setting > functions available. This is necessary for the proper functioning of Wine, > so it must be done on all platforms. This part of the logic was lost with > commit 5a4576ee0. > > * Call all available process-name-setting functions instead of treating them > as mutually exclusive alternatives. This is also logic that was lost with > commit 5a4576ee0. > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > --- > dlls/kernel32/process.c | 63 +++++++++++++++++++++++++++++-------------------- > 1 file changed, 37 insertions(+), 26 deletions(-) >

2 9

Re: [2/2] kernel32/tests: Add tests for GetThreadSelectorEntry.
by Marvin 14 Jul '16

14 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24204 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

2 1

Testbot 3D tests broken
by Patrick Rudolph 13 Jul '16

13 Jul '16

Hi, can you have a look at the testbot, it doesn't run d3d8 and d3d9 tests. Other 3D tests might be affected, too. As you can see here it reports no test failures, but it skipped all tests: https://testbot.winehq.org/JobDetails.pl?Key=24151 https://testbot.winehq.org/JobDetails.pl?Key=24150 Regards, Patrick

2 1

Re: [PATCH v2 2/3] winex11.drv: avoid passing NULL to memcpy (clang)
by Alexandre Julliard 13 Jul '16

13 Jul '16

Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > @@ -92,7 +92,8 @@ static void X11DRV_ImmSetInternalString(DWORD dwOffset, > ptr_new = CompositionString + byte_offset; > memmove(ptr_new + byte_length, ptr_new + byte_selection, > dwCompStringLength - byte_offset - byte_selection); > - memcpy(ptr_new, lpComp, byte_length); > + /* Do not pass NULL even if the length == 0 */ > + if (lpComp) memcpy(ptr_new, lpComp, byte_length); > dwCompStringLength += byte_expansion; Why would that be a problem? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 1/2] include: Fix include arguments.
by Matteo Bruni 13 Jul '16

13 Jul '16

This probably makes sense (although, WRT the patch title, this is probably more of a consistency improvement rather than a "fix"). Maybe split the d3dtypes.h change to a separate patch?

1 0

Re: include: Add d3dx10math.inl.
by Matteo Bruni 13 Jul '16

13 Jul '16

2016-07-04 19:26 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: +#ifndef __D3DX10MATH_INL__ +#define __D3DX10MATH_INL__ My copy of the file (from the latest DX SDK) uses __D3DXMATH_INL__ as header guard. I think we should do the same for compatibility. +/* constructors & operators */ Nitpicking but this comment doesn't seem particularly useful. +inline D3DXVECTOR2::D3DXVECTOR2(const FLOAT *pf) Just use plain float. + if(!pf) return; Space before '(', return on a separate line. +inline D3DXVECTOR2::operator FLOAT* () +{ + return (FLOAT*)&x; Please put a space between "float" and '*' in the cast. Probably do the same in the operator definition, although I don't really care in that regard. +inline D3DXMATRIX D3DXMATRIX::operator - () const +{ + return D3DXMATRIX(-_11, -_12, -_13, -_14, + -_21, -_22, -_23, -_24, + -_31, -_32, -_33, -_34, + -_41, -_42, -_43, -_44); +} This is almost identical to the MS's header. Please use 8 space indentation for line continuations. Probably drop the space between the "operator" keyword and the operator and between the operator and the opening parenthesis, in the operator declaration. +inline D3DXCOLOR::operator UINT () const +{ + UINT _r = r >= 1.0f ? 0xff : r <= 0.0f ? 0x00 : (UINT)(r * 255.0f + 0.5f); + UINT _g = g >= 1.0f ? 0xff : g <= 0.0f ? 0x00 : (UINT)(g * 255.0f + 0.5f); + UINT _b = b >= 1.0f ? 0xff : b <= 0.0f ? 0x00 : (UINT)(b * 255.0f + 0.5f); + UINT _a = a >= 1.0f ? 0xff : a <= 0.0f ? 0x00 : (UINT)(a * 255.0f + 0.5f); + + return (_a << 24) | (_r << 16) | (_g << 8) | (_b << 0); +} This one is also virtually identical. There seems to be room for writing a slightly different but equivalent implementation. FWIW identifiers starting with an underscore are supposed to be reserved, to some degree. It's generally better to avoid them. +inline D3DXFLOAT16::D3DXFLOAT16() +{ +} These default constructors are in (native) d3dx10math.h. I know that with d3dx9* headers we did put those in the .inl file but I think that was a bad idea. +inline BOOL D3DXFLOAT16::operator == (const D3DXFLOAT16 &f) const +{ This one is also almost identical, implementation-wise. Now maybe there isn't that much room for variations here but still, at the very least replace the "== 0" with a '!'. If you can find other reasonable ways to differentiate, that's even better. +inline D3DXCOLOR::D3DXCOLOR(UINT col) +{ + const FLOAT f = 1.0f / 255.0f; + r = f * (FLOAT)(unsigned char)(col >> 16); + g = f * (FLOAT)(unsigned char)(col >> 8); + b = f * (FLOAT)(unsigned char)(col >> 0); + a = f * (FLOAT)(unsigned char)(col >> 24); +} Another one essentially identical. I would write it as something like: inline D3DXCOLOR::D3DXCOLOR(UINT col) { float inv = 1.0f / 255.0f; a = ((col >> 24) & 0xff) * inv; r = ((col >> 16) & 0xff) * inv; g = ((col >> 8) & 0xff) * inv; b = (col & 0xff) * inv; } +static inline D3DXCOLOR* D3DXColorLerp(D3DXCOLOR *pout, const D3DXCOLOR *pc1, const D3DXCOLOR *pc2, FLOAT s) Don't use those prefixed argument names: out, c1 and c2 work just fine. Also you want a space between D3DXCOLOR and '*' and no space between '*' and the function name. +{ + if ( !pout || !pc1 || !pc2 ) return NULL; Please no spaces after the '(' and before the ')'. Return on a separate line. + pout->r = (1-s) * (pc1->r) + s *(pc2->r); You want spaces around the '-' operator and a space after the multiplication operator. No need for the parentheses around pc1->r and pc2->r. Regardless, MS's header uses the "optimized" linear interpolation formula, with just one multiplication. Your current implementation will generally give slightly different results (because of the limited precision of floats) so you should stick to the same formula instead. This isn't an exhaustive list of issues. Many of the above comments apply to multiple places over the patch.

1 0

Re: [PATCH 4/5] d3d11/tests: Add test for writing special floating-point values to render target.
by Henri Verbeet 13 Jul '16

13 Jul '16

On 13 July 2016 at 10:52, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +#ifndef NAN > +static inline float __port_nan(void) > +{ > + static const unsigned __nan_bytes = 0x7fc00000; > + return *(const float *)&__nan_bytes; > +} > +#define NAN __port_nan() > +#endif This looks unused. > + const struct vec4 *value = get_readback_vec4(&rb, x, y); > + ok(isnan(value->x) && value->y == INFINITY && value->z == -INFINITY && value->w == 1.0f, > + "Got unexpected value {%.8e, %.8e, %.8e, %.8e} at (%u, %u).\n", > + value->x, value->y, value->z, value->w, x, y); It would slightly change the meaning of the test, but you could also just read these back as uvec4's and compare the bit patterns. > @@ -9312,4 +9400,5 @@ START_TEST(d3d11) > test_check_feature_support(); > test_create_unordered_access_view(); > test_immediate_constant_buffer(); > + test_special_float_values(); For what it's worth, those are usually called "floating-point specials". (And hence fp_special_test() in the d3d9 tests.)

1 0

Re: ntdll/tests: Use inline implementation of NtCurrentTeb for exception tests.
by Marvin 13 Jul '16

13 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24168 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:489: Test failed: 42: Unexpected eip 0x3d0000/0x3d0001 exception: unhandled exception 80000004 at 003D0000 exception.c:489: Test failed: 42: Unexpected eip 0x77baed97/0x3d0001 === w7u (32 bit exception) === exception.c:489: Test failed: 42: Unexpected eip 0x280000/0x280001 exception: unhandled exception 80000004 at 00280000 exception.c:489: Test failed: 42: Unexpected eip 0x77cde34f/0x280001 === w1064 (32 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died) === w1064 (64 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died)

3 2

Re: [PATCH] wined3d: Fix the size parameter of glVertexAttrib*Pointer().
by Józef Kucia 13 Jul '16

13 Jul '16

On Wed, Jul 13, 2016 at 2:48 AM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > The mistake is obvious when looking at the GL 3.0 spec: > p29: > void VertexAttribPointer(uint index, int size, enum type, boolean normalized, sizei stride, const void *pointer); > void VertexAttribIPointer(uint index, int size, enum type, sizei stride, const void *pointer); > > p30: > Command Sizes > VertexAttribPointer 1, 2, 3, 4 > VertexAttribIPointer 1, 2, 3, 4 > > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/state.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This looks wrong to me. The "gl_vtx_format" field is equal to the "component_count" field. There's one exception though, the "gl_vtx_format" is set to GL_BGRA for WINED3DFMT_B8G8R8A8_UNORM. GL_BGRA was added as an accepted value by GL_ARB_vertex_array_bgra (core since OpenGL 3.2). What are you trying to fix?

2 2

Re: ncrypt: add some ncrypt stubs
by Alex Henrie 12 Jul '16

12 Jul '16

+ return NTE_INVALID_PARAMETER; I think NTE_NOT_SUPPORTED makes more sense for stub functions in this DLL. Other than that, the patch looks good. -Alex

2 1

Ubuntu considering dropping 32-bit libraries
by Josh DuBois 12 Jul '16

12 Jul '16

A Slashdot post yesterday pointed to a worrying thread on the Ubuntu mailing list archive about dropping 32-bit support from Ubuntu. The Ubuntu thread is here: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html It is not 100% clear to me what they are considering - they mention dropping 32-bit .isos and also ceasing to support users who want to run 32-bit apps (at least unless the app is packaged in a container alongside all of the necessary libraries). Their thought is to do this in a couple of years, with Ubuntu 18.10: 18.10+: * Stop providing i386 port * Run legacy i386 only application in snaps / containers / virtual machines Disturbingly, no one on the Ubuntu thread ever mentions Wine. Oddly there is discussion about IoT applications which might need 32-bit libraries and a proposal to continue building select libs for those things, but maybe minus the graphics stack :-(. In the Slashdot post someone at least mentions Wine, but the little discussion that prompted was seemingly in error until Francois came along to correct them. I think Wine should be aware of the issue and make some noise about it before distros grow attached to the idea of ceasing to build 32-bit libraries. I will probably post to the Ubuntu thread to at least mention Wine, unless someone here is involved in that community and thinks they can do a better job. The more distros hear from the Wine community about the value of 32-bit libraries, the better. It might be that they will conclude on their own that users need them to continue building 32-bit libraries, but I don't know that we can trust distros not to break things if we don't speak up.

1 1

Re: [PATCH 3/3] wined3d/resource: Performance improvements, try 2
by Henri Verbeet 12 Jul '16

12 Jul '16

This could do with a more descriptive subject line. On 11 July 2016 at 18:13, Patrick Rudolph <siro(a)das-labor.org> wrote: > Tests showed that D3DLOCK_NOOVERWRITE is prefered over D3DLOCK_DISCARD > and that D3DLOCK_NOOVERWRITE doesn't depend on dynamic buffers. "preferred", but you'll probably want to say "takes precedence over" instead. > Unigine Heavon maps a lot of buffers with both flags, but run on about > 85% GPU-load, as WINE removes both hints and the game has to wait for > the buffer to be mapped. "Unigine Heaven", "Wine" > OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.1.0-devel (git-60c68c5) It doesn't make much of a difference here, but note that unless you set the "MaxVersionGL" registry key, wined3d doesn't use core profiles. > --- > dlls/d3d9/tests/visual.c | 10 +++++----- > dlls/wined3d/resource.c | 33 ++++++++++++++++----------------- > 2 files changed, 21 insertions(+), 22 deletions(-) What about the d3d8 tests? > @@ -359,29 +359,28 @@ DWORD wined3d_resource_sanitize_map_flags(const struct wined3d_resource *resourc > { > /* Not all flags make sense together, but Windows never returns an error. > * Catch the cases that could cause issues. */ > - if (flags & WINED3D_MAP_READONLY) > + if ((flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) == > + (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > { > - if (flags & WINED3D_MAP_DISCARD) > - { > - WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_DISCARD, ignoring flags.\n"); > - return 0; > - } > - if (flags & WINED3D_MAP_NOOVERWRITE) > - { > - WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_NOOVERWRITE, ignoring flags.\n"); > - return 0; > - } > + WARN("WINED3D_MAP_DISCARD and WINED3D_MAP_NOOVERWRITE used together, using WINED3D_MAP_NOOVERWRITE.\n"); > + flags &= ~WINED3D_MAP_DISCARD; > + } > + if ((flags & (WINED3D_MAP_READONLY | WINED3D_MAP_NOOVERWRITE)) == > + (WINED3D_MAP_READONLY | WINED3D_MAP_NOOVERWRITE)) > + { > + WARN("WINED3D_MAP_READONLY and WINED3D_MAP_NOOVERWRITE used together, clearing WINED3D_MAP_READONLY.\n"); > + flags &= ~WINED3D_MAP_READONLY; > } > - else if ((flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > - == (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE)) > + > + if ((flags & (WINED3D_MAP_READONLY | WINED3D_MAP_DISCARD)) == > + (WINED3D_MAP_READONLY | WINED3D_MAP_DISCARD)) > { > - WARN("WINED3D_MAP_DISCARD and WINED3D_MAP_NOOVERWRITE used together, ignoring.\n"); > + WARN("WINED3D_MAP_READONLY combined with WINED3D_MAP_DISCARD, ignoring flags.\n"); > return 0; > } > - else if (flags & (WINED3D_MAP_DISCARD | WINED3D_MAP_NOOVERWRITE) > - && !(resource->usage & WINED3DUSAGE_DYNAMIC)) > + else if ((flags & WINED3D_MAP_DISCARD) && !(resource->usage & WINED3DUSAGE_DYNAMIC)) > { > - WARN("DISCARD or NOOVERWRITE map on non-dynamic buffer, ignoring.\n"); > + WARN("DISCARD on non dynamic buffer, ignoring.\n"); > return 0; > } This changes several things at once. One (logical) change per commit, please.

1 0

Re: [PATCH 1/3] d3d9/tests/visual: Add Vertexbuffer locking tests, try 2
by Henri Verbeet 12 Jul '16

12 Jul '16

On 11 July 2016 at 18:13, Patrick Rudolph <siro(a)das-labor.org> wrote: > +static void test_vb_lock_flags(void) > +{ > + IDirect3DVertexBuffer9 *buffer; > + IDirect3DDevice9 *device; > + IDirect3D9 *d3d9; > + DWORD i, j, tri, quads; > + HWND window; > + HRESULT hr; > + ULONG size; > + unsigned refcount; "ULONG refcount;", but that's minor. > + { > + "0", > + 0, > + 0, > + FALSE, > + FALSE > + }, This may have been inspired by other tests, but as long as it fits I'd prefer the more compact option of keeping this all on a single line. You may have to shorten the "flags_s" values a bit to do that. > + static struct > + { > + struct > + { > + struct vec3 position; > + DWORD diffuse; > + } strip[4]; > + } > + *quad_strip_array, quad_strip1 = > + { > + { > + {{-1.0f, -1.0f, 0.0f}, 0xffff0000}, > + {{-1.0f, 1.0f, 0.0f}, 0xff00ff00}, > + {{ 1.0f, -1.0f, 0.0f}, 0xff0000ff}, > + {{ 1.0f, 1.0f, 0.0f}, 0xffffffff}, > + } > + }, > + quad_strip2 = > + { > + { > + {{-1.0f, -1.0f, 0.0f}, 0xffffff00}, > + {{-1.0f, 1.0f, 0.0f}, 0xffffff00}, > + {{ 1.0f, -1.0f, 0.0f}, 0xffffff00}, > + {{ 1.0f, 1.0f, 0.0f}, 0xffffff00}, > + } > + }; These are triangle strips or quads, but I don't think "quad strips" makes sense here. "quad_strip1" and "quad_strip2" can be const, and "quad_strip_array" doesn't need to be static, right? > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, tests[i].usage, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + ok(SUCCEEDED(hr), "Failed to create vertex buffer, hr %#x.\n", hr); > + if (!SUCCEEDED(hr)) > + continue; The continue is pointless, the test would have already failed at that point. > + if (tests[i].unsyncronized == unsyncronized) > + break; This means the test will only try the smallest buffer size for cases that you expect to be synchronised, right? That seems problematic, since the reason you try the larger buffer sizes is that you can't necessarily reliably detect the unsynchronised cases with the smaller buffer sizes. > + if (tests[i].todo) > + { > + todo_wine ok(tests[i].unsyncronized == unsyncronized, "Expected buffer mapped %s. Flags = %s. Usage = %d.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } > + else > + { > + ok(tests[i].unsyncronized == unsyncronized, "Expected buffer mapped %s. Flags = %s. Usage = %d.\n", > + tests[i].unsyncronized ? "unsyncronized" : "syncronized", tests[i].flags_s, tests[i].usage); > + } I think "todo_wine_if" would be appropriate here. Please use %#x to print the usage. Note that ddraw has the mostly equivalent flags DDLOCK_NOOVERWRITE and DDLOCK_DISCARDCONTENTS as well. Direct3D 10 has D3D10_MAP_WRITE_DISCARD and D3D10_MAP_WRITE_NO_OVERWRITE, but you can't use them at the same time because they're not flags. Direct3D 11 is similar to Direct3D 10. You'll need to account for the testbot failures in some way. They may be specific to WARP, but it's suspicious that the "D3DLOCK_NOOVERWRITE" tests do seem to pass. Also, please follow the usual conventions for the subject line. (I.e., "d3d9/tests:", "d3d8/tests:", "wined3d:".)

1 0

Re: [PATCH] dxgi: Implement IDXGISwapChain GetFullscreenState
by Henri Verbeet 12 Jul '16

12 Jul '16

On 11 July 2016 at 12:08, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +static HRESULT STDMETHODCALLTYPE dxgi_swapchain_GetFullscreenState(IDXGISwapChain *iface, > + BOOL *fullscreen, IDXGIOutput **target) > +{ > + HRESULT hr = S_OK; > + > + TRACE("iface %p, fullscreen %p, target %p semi-stub.\n", iface, fullscreen, target); > + > + if (fullscreen) > + *fullscreen = TRUE; > + > + if (target) > + hr = dxgi_swapchain_GetContainingOutput(iface, target); > + > + return hr; > +} That's not a real implementation, of course. > @@ -496,6 +498,22 @@ static void test_create_swapchain(void) > refcount = IUnknown_Release(parent); > todo_wine ok(refcount == 4, "Got unexpected refcount %u.\n", refcount); > > + hr = IDXGISwapChain_GetFullscreenState(swapchain, NULL, NULL); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, &fullscreen, NULL); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, NULL, &target); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + if(target) > + IDXGIOutput_Release(target); > + > + hr = IDXGISwapChain_GetFullscreenState(swapchain, &fullscreen, &target); > + ok(hr == S_OK, "GetFullscreenState failed, hr %#x.\n", hr); > + if(target) > + IDXGIOutput_Release(target); > + And this doesn't test much beyond the function returning S_OK.

1 0

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.
by Theodore Dubois 12 Jul '16

12 Jul '16

This patch causes a segfault in the event that __wine_main_argv is not the argv that got passed to main. This happened in a program I wrote that acts as a custom wine loader. It creates an argv by using malloc, then passes that to wine_init. Why wouldn’t setprogname(argv[1]) be adequate? ~Theodore > On Feb 19, 2016, at 2:33 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> > --- > Try 2: > * Clean up the #ifdefs a bit. (I'm not happy about the duplicated code, though.) > * Don't copy the progname into a static array. There's no need; the argument vector lasts as long as the process itself. (I suppose I was being overly defensive with that.) > > configure.ac | 1 + > dlls/kernel32/process.c | 17 ++++++++++++++--- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/configure.ac b/configure.ac > index c9445e7..2ebbb10 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2026,6 +2026,7 @@ AC_CHECK_FUNCS(\ > sched_yield \ > select \ > setproctitle \ > + setprogname \ > setrlimit \ > settimeofday \ > sigaltstack \ > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index 86333be..4771108 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -1118,9 +1118,20 @@ static void set_process_name( int argc, char *argv[] ) > { > #ifdef HAVE_SETPROCTITLE > setproctitle("-%s", argv[1]); > -#endif > + /* remove argv[0] */ > + memmove( argv, argv + 1, argc * sizeof(argv[0]) ); > +#elif defined(HAVE_SETPROGNAME) > + int i, offset; > + char *end = argv[argc-1] + strlen(argv[argc-1]) + 1; > > -#ifdef HAVE_PRCTL > + offset = argv[1] - argv[0]; > + memmove( argv[1] - offset, argv[1], end - argv[1] ); > + memset( end - offset, 0, offset ); > + for (i = 1; i < argc; i++) argv[i-1] = argv[i] - offset; > + argv[i-1] = NULL; > + > + setprogname( argv[0] ); > +#elif defined(HAVE_PRCTL) > int i, offset; > char *p, *prctl_name = argv[1]; > char *end = argv[argc-1] + strlen(argv[argc-1]) + 1; > @@ -1141,11 +1152,11 @@ static void set_process_name( int argc, char *argv[] ) > argv[i-1] = NULL; > } > else > -#endif /* HAVE_PRCTL */ > { > /* remove argv[0] */ > memmove( argv, argv + 1, argc * sizeof(argv[0]) ); > } > +#endif /* HAVE_PRCTL */ > } > > > -- > 2.7.1 > > >

4 12

Re: ntoskrnl.exe: add IoAttachDevice stub
by Sebastian Lackner 12 Jul '16

12 Jul '16

On 12.07.2016 05:07, Austin English wrote: > + > +/*********************************************************************** > + * IoAttachDevice (NTOSKRNL.EXE.@) > + */ > +NTSTATUS IoAttachDevice(DEVICE_OBJECT *source, UNICODE_STRING *target, DEVICE_OBJECT *attached) You forgot to specify the calling convention (WINAPI) - this is probably also the reason why your stub is not sufficient yet. Otherwise the patch looks fine to me. > +{ > + FIXME("(%p, %s, %p): stub\n", source, debugstr_us(target), attached); > + return STATUS_NOT_IMPLEMENTED; > +}

1 0

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.
by Sebastian Lackner 11 Jul '16

11 Jul '16

On 08.07.2016 00:16, John Sheu wrote: > Signed-off-by: John Sheu <sheu(a)google.com> > --- > dlls/kernel32/tests/fiber.c | 291 +++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 258 insertions(+), 33 deletions(-) > > diff --git a/dlls/kernel32/tests/fiber.c b/dlls/kernel32/tests/fiber.c > index 1e4ca66..4f61f80 100644 > --- a/dlls/kernel32/tests/fiber.c > +++ b/dlls/kernel32/tests/fiber.c > @@ -33,9 +33,13 @@ static BOOL (WINAPI *pFlsFree)(DWORD); > static PVOID (WINAPI *pFlsGetValue)(DWORD); > static BOOL (WINAPI *pFlsSetValue)(DWORD,PVOID); > > -static LPVOID fibers[2]; > +static LPVOID fibers[3]; > static BYTE testparam = 185; > -static WORD cbCount; > +static DWORD fls_index_to_set = FLS_OUT_OF_INDEXES; > +static PVOID fls_value_to_set = NULL; > + > +static int fiberCount = 0; > +static int cbCount = 0; > > static VOID init_funcs(void) > { > @@ -59,15 +63,44 @@ static VOID init_funcs(void) > > static VOID WINAPI FiberLocalStorageProc(PVOID lpFlsData) > { > + ok(lpFlsData == fls_value_to_set, > + "FlsData expected not to be changed, value is %p, expected %p\n", > + lpFlsData, fls_value_to_set); > cbCount++; > - ok(lpFlsData == (PVOID) 1587, "FlsData expected not to be changed\n"); > } > > static VOID WINAPI FiberMainProc(LPVOID lpFiberParameter) > { > BYTE *tparam = (BYTE *)lpFiberParameter; > - cbCount++; > + fiberCount++; > ok(*tparam == 185, "Parameterdata expected not to be changed\n"); > + if (fls_index_to_set != FLS_OUT_OF_INDEXES) > + { > + if (!pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); You can get rid of this check, fls_index_to_set should not be set when Fiber Local Storage is not supported. > + } > + else > + { > + PVOID pret; Usually "void *" types and variable names without "p" prefix are preferred. > + BOOL bret; > + > + pret = pFlsGetValue(fls_index_to_set); > + ok(pret == NULL, "FlsGetValue returned %p, expected NULL\n", pret); > + > + /* Set the FLS value */ > + SetLastError( 0xdeadbeef ); You can remove this line when you are not testing the error value. > + bret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(bret, "FlsSetValue failed with error %u\n", GetLastError()); > + > + /* Verify that FlsGetValue retrieves the value set by FlsSetValue */ > + SetLastError( 0xdeadbeef ); > + pret = pFlsGetValue(fls_index_to_set); > + ok(pret == fls_value_to_set, > + "FlsGetValue returned %p, expected %p\n", pret, fls_value_to_set); > + ok(GetLastError() == ERROR_SUCCESS, "FlsGetValue error %u\n", GetLastError()); > + } > + } > pSwitchToFiber(fibers[0]); > } > > @@ -110,9 +143,23 @@ static void test_ConvertFiberToThread(void) > } > } > > +static void test_IsThreadAFiber(BOOL is_fiber) > +{ > + if (pIsThreadAFiber) > + { > + BOOL ret = pIsThreadAFiber(); > + ok(ret == is_fiber, "IsThreadAFiber reported %d, expected %d\n", ret, is_fiber); > + } > + else > + { > + win_skip( "IsThreadAFiber not present\n" ); > + return; return at the end of a function is unnecessary. Also, I'm not sure if it makes much sense to have this as a separate function. You could probably just inline it in this case. > + } > +} > + > static void test_FiberHandling(void) > { > - cbCount = 0; > + fiberCount = 0; > fibers[0] = pCreateFiber(0,FiberMainProc,&testparam); > ok(fibers[0] != 0, "CreateFiber failed with error %d\n", GetLastError()); > pDeleteFiber(fibers[0]); > @@ -124,12 +171,11 @@ static void test_FiberHandling(void) > else > test_ConvertThreadToFiber(); > > - > fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); > ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); > > pSwitchToFiber(fibers[1]); > - ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > pDeleteFiber(fibers[1]); > > if (!pCreateFiberEx) > @@ -143,46 +189,72 @@ static void test_FiberHandling(void) > ok(fibers[1] != 0, "CreateFiberEx failed with error %d\n", GetLastError()); > > pSwitchToFiber(fibers[1]); > - ok(cbCount == 2, "Wrong callback count: %d\n", cbCount); > + ok(fiberCount == 2, "Wrong fiber count: %d\n", fiberCount); > pDeleteFiber(fibers[1]); > > - if (!pIsThreadAFiber) > - { > - win_skip( "IsThreadAFiber not present\n" ); > - return; > - } > - > - ok(pIsThreadAFiber(), "IsThreadAFiber reported FALSE\n"); > + test_IsThreadAFiber(TRUE); > test_ConvertFiberToThread(); > - ok(!pIsThreadAFiber(), "IsThreadAFiber reported TRUE\n"); > + test_IsThreadAFiber(FALSE); > } > > -static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > +static void test_FiberLocalStorage(void) > { > - DWORD fls; > + DWORD fls, fls_2; > BOOL ret; > - PVOID val = (PVOID) 1587; > + PVOID val; "void *" would be preferred here. > > - if (!pFlsAlloc) > + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) > { > win_skip( "Fiber Local Storage not supported\n" ); > return; > } > - cbCount = 0; > > - fls = pFlsAlloc(cbfunc); > - ok(fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); > + /* Test an unallocated index > + * FlsFree should fail > + * FlsGetValue and FlsSetValue should succeed > + */ > + SetLastError( 0xdeadbeef ); > + ret = pFlsFree( 127 ); > + ok( !ret, "freeing fls index 127 (unallocated) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "freeing fls index 127 (unallocated) wrong error %u\n", GetLastError() ); > > - ret = pFlsSetValue(fls, val); > - ok(ret, "FlsSetValue failed\n"); > - ok(val == pFlsGetValue(fls), "FlsGetValue failed\n"); > + SetLastError( 0xdeadbeef ); This is unnecessary if you don't test the error. > + val = pFlsGetValue( 127 ); > + ok( val == NULL, > + "getting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsSetValue( 127, (PVOID) 0x217 ); "(void *)0x217" would be preferred here (and at a couple of places below). > + ok( ret, "setting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + val = pFlsGetValue( 127 ); > + ok( val == (PVOID) 0x217, "fls index 127 (unallocated) wrong value %p\n", val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index 127 (unallocated) failed with error %u\n", GetLastError() ); > + > + /* FlsFree, FlsGetValue, and FlsSetValue out of bounds should return > + * ERROR_INVALID_PARAMETER > + */ > + SetLastError( 0xdeadbeef ); > + ret = pFlsFree( 128 ); > + ok( !ret, "freeing fls index 128 (out of bounds) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "freeing fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); > > - ret = pFlsFree(fls); > - ok(ret, "FlsFree failed\n"); > - if (cbfunc) > - todo_wine ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + SetLastError( 0xdeadbeef ); > + ret = pFlsSetValue( 128, (PVOID) 0x217 ); > + ok( !ret, "setting fls index 128 (out of bounds) succeeded\n" ); > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "setting fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + val = pFlsGetValue( 128 ); It would make sense to test "val" aswell. > + ok( GetLastError() == ERROR_INVALID_PARAMETER, > + "setting fls index 128 (out of bounds) wrong error %u\n", GetLastError() ); The function above is no set function. > > - /* test index 0 */ > + /* Test index 0 */ > SetLastError( 0xdeadbeef ); > val = pFlsGetValue( 0 ); > ok( !val, "fls index 0 set to %p\n", val ); > @@ -196,6 +268,7 @@ static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > ok( !val, "fls index 0 wrong value %p\n", val ); > ok( GetLastError() == ERROR_INVALID_PARAMETER, "setting fls index wrong error %u\n", GetLastError() ); > > + /* Test creating an FLS index */ > fls = pFlsAlloc( NULL ); > ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed\n" ); > ok( fls != 0, "fls index 0 allocated\n" ); > @@ -205,11 +278,162 @@ static void test_FiberLocalStorage(PFLS_CALLBACK_FUNCTION cbfunc) > ok( ret, "setting fls index %u failed\n", fls ); > val = pFlsGetValue( fls ); > ok( val == (void *)0xdeadbeef, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls, GetLastError() ); > pFlsFree( fls ); > + > + /* Undefined behavior: verify the value is NULL after it the slot is freed */ > + val = pFlsGetValue( fls ); > + ok( val == NULL, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls, GetLastError() ); > + > + /* Undefined behavior: verify the value is settable after the slot is freed */ > ret = pFlsSetValue( fls, (void *)0xdeadbabe ); > ok( ret, "setting fls index %u failed\n", fls ); > val = pFlsGetValue( fls ); > ok( val == (void *)0xdeadbabe, "fls index %u wrong value %p\n", fls, val ); > + > + /* Try to create the same FLS index again, and verify that is initialized to NULL */ > + fls_2 = pFlsAlloc( NULL ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed\n" ); > + /* If this fails it is not an API error, but the test will be inconclusive */ > + ok( fls_2 == fls, "different FLS index allocated, was %u, now %u\n", fls, fls_2 ); > + val = pFlsGetValue( fls_2 ); > + ok( val == NULL, "fls index %u wrong value %p\n", fls, val ); > + ok( GetLastError() == ERROR_SUCCESS, > + "getting fls index %u failed with error %u\n", fls_2, GetLastError() ); A SetLastError() call is missing here, otherwise this test is not really convincing. > + pFlsFree( fls_2 ); > +} > + > +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { All the other functions have the "{" on the next line. > + DWORD fls; > + BOOL ret; > + PVOID val, val2; > + > + if (!pFlsAlloc || !pFlsSetValue || !pFlsGetValue || !pFlsFree) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + /* Test that the callback is executed */ > + SetLastError( 0xdeadbeef ); This is unnecessary. > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); This also. > + val = (PVOID) 0x1587; > + fls_value_to_set = val; > + ret = pFlsSetValue( fls, val ); > + ok(ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + val2 = pFlsGetValue( fls ); > + ok(val == val2, "FlsGetValue returned %p, expected %p\n", val2, val); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsFree( fls ); > + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); > + todo_wine > + { > + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); > + } > + > + /* Test that callback is not executed if value is NULL */ > + SetLastError( 0xdeadbeef ); Same here. > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + ret = pFlsSetValue( fls, NULL ); > + ok( ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); Same here. > + pFlsFree( fls ); > + ok( ret, "FlsFree failed with error %u\n", GetLastError() ); > + ok( cbCount == 0, "Wrong callback count: %d\n", cbCount ); > +} > + > +static void test_FiberLocalStorageWithFibers(PFLS_CALLBACK_FUNCTION cbfunc) { > + PVOID val1 = (PVOID) 0x314; > + PVOID val2 = (PVOID) 0x152; > + BOOL ret; > + > + if (!pConvertThreadToFiber || !pSwitchToFiber || !pDeleteFiber || !pConvertFiberToThread) > + { > + win_skip( "Fibers not supported\n" ); > + return; > + } > + if (!pFlsAlloc || !pFlsFree || !pFlsSetValue || !pFlsGetValue) > + { > + win_skip( "Fiber Local Storage not supported\n" ); > + return; > + } > + > + > + fls_index_to_set = pFlsAlloc(cbfunc); > + ok(fls_index_to_set != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %d\n", GetLastError()); Not really critical, but in the code above you used %u for GetLastError values. > + > + test_ConvertThreadToFiber(); > + > + fiberCount = 0; > + cbCount = 0; > + fibers[1] = pCreateFiber(0,FiberMainProc,&testparam); > + fibers[2] = pCreateFiber(0,FiberMainProc,&testparam); > + ok(fibers[1] != 0, "CreateFiber failed with error %d\n", GetLastError()); > + ok(fibers[2] != 0, "CreateFiber failed with error %d\n", GetLastError()); CreateFiber returns a pointer, so it would be better to compare against NULL. > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pSwitchToFiber(fibers[1]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val2; > + pSwitchToFiber(fibers[2]); > + ok(fiberCount == 1, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + fls_value_to_set = val2; > + ret = pFlsSetValue(fls_index_to_set, fls_value_to_set); > + ok(ret, "FlsSetValue failed\n"); > + ok(val2 == pFlsGetValue(fls_index_to_set), "FlsGetValue failed\n"); > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pDeleteFiber(fibers[1]); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + todo_wine > + { > + ok(cbCount == 1, "Wrong callback count: %d\n", cbCount); > + } > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val2; > + pFlsFree(fls_index_to_set); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + todo_wine > + { > + ok(cbCount == 2, "Wrong callback count: %d\n", cbCount); > + } > + > + fiberCount = 0; > + cbCount = 0; > + fls_value_to_set = val1; > + pDeleteFiber(fibers[2]); > + ok(fiberCount == 0, "Wrong fiber count: %d\n", fiberCount); > + ok(cbCount == 0, "Wrong callback count: %d\n", cbCount); > + > + test_ConvertFiberToThread(); > } > > START_TEST(fiber) > @@ -223,6 +447,7 @@ START_TEST(fiber) > } > > test_FiberHandling(); > - test_FiberLocalStorage(NULL); > - test_FiberLocalStorage(FiberLocalStorageProc); > + test_FiberLocalStorage(); > + test_FiberLocalStorageCallback(FiberLocalStorageProc); > + test_FiberLocalStorageWithFibers(FiberLocalStorageProc); > } >

2 2

Re: [PATCH 3/3] wined3d/resource: Performance improvements, try 2
by Marvin 11 Jul '16

11 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24152 Your paranoid android. === w8 (32 bit visual) === visual.c:8177: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:8345: Test failed: Got unexpected color 0x00ff0000 for no color attribute test. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (32 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (32 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (64 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (64 bit visual) === visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4529: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512.

1 0

Re: [PATCH 1/3] d3d9/tests/visual: Add Vertexbuffer locking tests, try 2
by Marvin 11 Jul '16

11 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24150 Your paranoid android. === w8 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (32 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w864 (64 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512. === w1064 (64 bit visual) === visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 0. visual.c:4524: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Usage = 512.

1 0

Re: [v3 1/2] winejoystick.drv: Print location ID in debugstr_device on the Mac
by Ken Thomases 11 Jul '16

11 Jul '16

On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 30 ++++++++++++++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) This has similar issues as the dinput version, the main one being the pointless "result" variable in get_device_property_long(). -Ken

2 3

Re: [v3 2/3] dinput: Sort devices by location ID on the Mac
by DavidL 11 Jul '16

11 Jul '16

This patch will be superseded in a later version. Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> On Sun, Jul 10, 2016 at 3:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Signed-off-by: Ken Thomases <ken(a)codeweavers.com> > > > >

1 0

Re: [v3 3/3] dinput: Alter function name and code style
by Ken Thomases 11 Jul '16

11 Jul '16

On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > @@ -490,10 +490,10 @@ static int find_osx_devices(void) > if (devset) > { > CFIndex num_devices, num_main_elements, idx; > - CFMutableArrayRef devices = CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); > - CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, devices); > - CFRelease( devset); > - num_devices = CFArrayGetCount(devices); > + num_devices = CFSetGetCount(devset); > + CFMutableArrayRef devices = CFArrayCreateMutable(kCFAllocatorDefault, num_devices, &kCFTypeArrayCallBacks); You've now interleaved statements and declarations. Wine's code standard requires that declarations all come before statements. So, you could change the assignment of num_devices to an initialization or split the declaration and initialization of devices to separate declaration and assignment. Wine should be using -Wdeclaration-after-statement for its compile commands. Therefore, this change would have added a new warning. I know that some of the Mac files have a lot of warnings, which makes it hard to see new ones, but you should strive to avoid adding more. -Ken

2 1

Re: usp10/tests: Use SetRect() instead of open coding it.
by Marvin 11 Jul '16

11 Jul '16

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=24145 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: [PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)
by Stefan Dösinger 11 Jul '16

11 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 21:49 schrieb Aaryaman Vasishta: > I believe the "obj == ctxt->obj" tests in destroy_callback and > destroy_callback1 should cover this. See test_destroy_callback. If I understand it correctly not quite, because you're only ever calling AddDestroyCallback via IDirect3DRMObject, never via IDirect3DRMSomethingElse. (Re-CCed wine-devel) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgsLBAAoJEN0/YqbEcdMwlsUP/2AIUfNl//T23Ik/gnL5FHVd 4axt1f/F5l1Hb5C3049Eh/se5SfF8jM6YYJte62al60f8nf0ERCW8S9JCzRueV2+ Q4ETvXbxhffKh9Ceb8W83ijxkwGf3GplypnXK7OQnqFUg88AR4YTGIL4I5pTPZVq Bw/MKgOfnDAHn+QsRDnzaQTtZcJPDNx+mrf26S/x15Wdi+PQjdVWb3uPbtgfkHN4 TWVwAgTQwPcnJQDaQ2wmWlEG+uxvxqpCF5BFCf1JwRV6oMdYYCQeHH+nvBrnPjEN /7Upv092RGbazucxMr6OWc9GJaCy4K9pfer8U2Ahdb47eAsF9UTO4AoW718GnIfU CJPvh8kMxukMw81U3U5Dr61v9cxd2xywz8ZMWMfKScrN4b6W7/hiE19B3+0w/XHi JHDf0NlPG8RDS+LR3N67X7dkaVqtEkRNCyVfAKdOozlz2EIlzs6lHmYNSxd17GO1 foIPVad9Ovo7nNQhB6FK+0zMZCKAz7be6ai9orlCk4ThhBhVwlaQXX16LBxgrYBi cU/3emOonGzto6sqzDrXyTNEqQTzvFMXnqitH/ITgvKuey0GBLHVSeOAHdECbrN3 bdGYdYPuXnxdksTey/zGORo4u0plUxS3gXiAGM0Ch0oCb6E9uzWMqKJpH6rIoR22 yAuKU7HOboWb3rlcAs0i =s5bk -----END PGP SIGNATURE-----

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel