- wine-devel - winehq.org

Re: [PATCH] ddraw/tests: Skip A4R4G4B4 ckey tests on Nvidia (v3)
by Marvin 10 Jul '16

10 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=24144 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [v3 1/3] dinput: Print location ID in debugstr_device on the Mac
by Ken Thomases 10 Jul '16

10 Jul '16

Hi, Sorry for the late review. See in-line comments: On Jun 30, 2016, at 7:02 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static void get_device_property_long(IOHIDDeviceRef in_device, CFStringRef in_key, long * out_value) As Dmitry suggested, you could make this simply return the property value rather than provide it through the indirect output parameter. > +{ > + Boolean result = FALSE; This variable isn't really used. It's assigned, but never read. > + CFTypeRef type; This variable isn't holding a type, it's holding a value or, if you prefer, an object reference. (The fact that its type is "CFTypeRef" doesn't imply it holds a type. Frankly, "CFTypeRef" is also a lousy name, but that's on Apple.) > + > + if (in_device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(in_device)); > + > + type = IOHIDDeviceGetProperty(in_device, in_key); > + > + if (type) > + { > + if (CFNumberGetTypeID() == CFGetTypeID(type)) You could combine these two "if" statements using &&. -Ken

1 0

Re: [v2 01/10] webservices: Add support for writing double values.
by Sebastian Lackner 10 Jul '16

10 Jul '16

On 08.07.2016 10:20, Hans Leidekker wrote: > v2: Fix build failure. > > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/webservices/reader.c | 8 +-- > dlls/webservices/tests/writer.c | 113 +++++++++++++++++++++++++++++++++ > dlls/webservices/webservices_private.h | 2 + > dlls/webservices/writer.c | 100 +++++++++++++++++++++++++++++ > include/webservices.h | 5 ++ > 5 files changed, 224 insertions(+), 4 deletions(-) > Unfortunately your patch does not work as expected here (gcc 5.3): ../../../tools/runtest -q -P wine -T ../../.. -M webservices.dll -p webservices_test.exe.so writer && touch writer.ok writer.c:358: Test failed: 1941: got 11 expected 10 writer.c:360: Test failed: 1941: got <t>:E-3</t>>000000004</t> expected <t>1E-2</t> writer.c:358: Test failed: 1941: got 12 expected 11 writer.c:360: Test failed: 1941: got <t>-:E-3</t>000000004</t> expected <t>-1E-2</t> Makefile:346: die Regel für Ziel „writer.ok“ scheiterte If you need any details to investigate this issue please let me know. Regards, Sebastian

2 2

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

10 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-10 um 17:41 schrieb Aaryaman Vasishta: > static HRESULT WINAPI d3drm_device1_AddDestroyCallback(IDirect3DRMDevice *iface, > D3DRMOBJECTCALLBACK cb, void *ctx) > { > - FIXME("iface %p, cb %p, ctx %p stub!\n", iface, cb, ctx); > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, cb %p, ctx %p.\n", iface, cb, ctx); > + > + return d3drm_device3_AddDestroyCallback(&device->IDirect3DRMDevice3_iface, cb, ctx); > } It doesn't fit in this patch, but at some point we should test which interface is passed to the destroy callback: Is it the interface on which AddDestroyCallback was called, or is it the interface returned by iface->QueryInterface(&IID_IDirect3DRMObject)? Please correct me if we already have tests for that and I missed them :- ) . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgpstAAoJEN0/YqbEcdMwWkcP/j25Gk+jAQlDrb0l0YV5Tz0k V0D/PZW7lHMcGCeAW4Y8GyzzKAFVD+d8YL9RRHcxyWbUnl5f6nR/yjAe3da6FFpD AF+vDvKGlV1POG1QhC8d/34SxVYXsngKNq2tvxYVQOhldvKh9d9Ti255dLFicqG3 aBBzPF1OvY9ZaxQJQAyJdU9944YtaH3CUd6cxjOH95jR1hAiz55akKWDRQHm7Uc+ S77/XRaaUmGTX5gpma/EeY7Rb/eG3cEDF8UBoCI6rfu+kjIEa+KTJVZKzeSA5+RU xPETE28jUX94XZnRz8lqLJbSRboBXSa2MWDdb2KvBUqSTLPS1cTm55cLYRngWDAD czF8Wfo+UOfGeG9oGhorUE2GkOleDd/WtXQtAfJeAvxfBxd4aA5v66Z7IwhcVeEV sSEhsqxFfc31VBB/f4Ii3F/5nFyMN+LfcDUIHI4tmOMjwj+VMlIES//71BvYQpqm iJNo9DPSVUyqApIgPSNsYL7vORUl2AKsklJKk4fxka1j1010TLJdpFIyv4leLfL8 mBUY13S+wzaEObhztQJiMJ5usWu9BoClm38x4Oj5JzMZ2Pg2If0WAcVRLOLkb9Br GIyfN5K89SUmiJp6GoMtKG99QXypMsg1fanYe6imBTL8Cj5tGuVAoJlPDMpc8i07 JxITcNBrsu5/WwP8tGeq =Zf/v -----END PGP SIGNATURE-----

1 0

Re: [PATCH] kernel32/tests/fiber: Add tests for fiber-local storage.
by André Hentschel 10 Jul '16

10 Jul '16

Hi, comments inline Am 08.07.2016 um 00:16 schrieb John Sheu: > +static void test_FiberLocalStorageCallback(PFLS_CALLBACK_FUNCTION cbfunc) { > + 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 ); > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + 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 ); > + ret = pFlsFree( fls ); > + ok(ret, "FlsFree failed with error %u\n", GetLastError() ); > + todo_wine > + { > + ok( cbCount == 1, "Wrong callback count: %d\n", cbCount ); > + } Please make those one-liners, like todo_wine ok(...); and the patch should be fine then > + > + /* Test that callback is not executed if value is NULL */ > + SetLastError( 0xdeadbeef ); > + cbCount = 0; > + fls = pFlsAlloc( cbfunc ); > + ok( fls != FLS_OUT_OF_INDEXES, "FlsAlloc failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + ret = pFlsSetValue( fls, NULL ); > + ok( ret, "FlsSetValue failed with error %u\n", GetLastError() ); > + > + SetLastError( 0xdeadbeef ); > + pFlsFree( fls ); > + ok( ret, "FlsFree failed with error %u\n", GetLastError() ); > + ok( cbCount == 0, "Wrong callback count: %d\n", cbCount ); > +}

3 3

Re: [PATCH 07/12] d3drm: Implement IDirect3DRMViewport*::Init. (v4)
by Stefan Dösinger 10 Jul '16

10 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-07 um 14:52 schrieb Aaryaman Vasishta: > - {&CLSID_CDirect3DRMTexture, d3drm_create_texture_object}, > - {&CLSID_CDirect3DRMDevice, d3drm_create_device_object}, > + { &CLSID_CDirect3DRMTexture, d3drm_create_texture_object }, > + { &CLSID_CDirect3DRMDevice, d3drm_create_device_object }, > + { &CLSID_CDirect3DRMViewport, d3drm_create_viewport_object }, I guess Visual Studio or xcode re-added the spaces between { and &. Henri removed them in the slightly modified version of "d3drm: Use a table in d3drm3_CreateObject() to create objects in a generic manner." > + if (FAILED(hr = IDirect3DRMFrame3_QueryInterface(camera, &IID_IDirect3DRMFrame, (void **)&viewport->camera))) > + goto cleanup; Aren't you more likely to need the implementation structure of the camera in the future? > + > + 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)); > + > + if (FAILED(hr = IDirect3DMaterial_SetMaterial(material, &mat))) > + goto cleanup; > + > + if (FAILED(hr = IDirect3DMaterial_GetHandle(material, d3d_device, &hmat))) > + goto cleanup; > + > + hr = IDirect3DViewport_SetBackground(viewport->d3d_viewport, hmat); > + > +cleanup: > + > + if (material) > + IDirect3DMaterial_Release(material); In the success case this will destroy the material you just created. Our IDirect3DViewport::SetBackground implementation does not AddRef the material. I don't think we have any tests for this, but because SetBackground accepts a handle instead of a COM object I don't expect it to AddRef. Overall it seems questionable to call camera->GetSceneBackground and apply the color here. I'd expect that the camera background can be changed after creating the viewport. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgnMdAAoJEN0/YqbEcdMwk+IP/2DZH4tPgtCN/PHoB/ZdsVwJ oodz6Sax5LZUaumbXZme4CPgPZKSKr44ue3qho/5cQicRISuJ3G6I6vFmkiiHol6 nFmY9cTJiNeXzd6NcJq5KK6IUmgrzO5YjGgXIbzgzEiTycbws/lo5fVwF74LSYn7 RMPg+U4qMaHVT/w/rb7dWWqPugSbm8cIGfp8Zjz2VrO+JX+S1Qs3ymCZViyMfCRz A1VtyJh/u72GlfCoRoUiT6DDsMjw1BCMogR4asDkQmoTdkc7XFRU3MYQwUN7cFY2 bxos78d6xozUwvDRoezrtRLh4gQis9gudaNYv4Dt4fZjNOSvCtA8fMbl35gXuJog ooROiaXSoW5oBrzv++Fvp38cixS0j9MMECNDgs1yCCKt0a/B4/IFEQMvyGt5LzRG zeJ2XzDEZI3ntsbeVdKPRuH6m7ROlQLfp+Q0ac+MrhJSQtnAd88mXVfU5U8330b4 DNyeSmyPhBpaRp62WZxMCeOct7psy1p4LYkbbE5QZ3eFS2QhHlnPC6PzNtcUbDqI RG4J+ZhquDnT57ViyjX1vKt6tXPlDOkwJf0AApwQ84OGs7ATNci/7Z1WuyULx9sR xPrpNYUPbFIxcadmvaa7jO+aaOXoNWFQQz7rJdCVBxUY1T4Bz8+FyzQ0O8Ld/xNj b7LndQJz3AbU//fQ1gdO =8gsI -----END PGP SIGNATURE-----

2 2

Re: [PATCH 1/2] d3d9/tests/visual: Add Vertexbuffer locking tests
by Stefan Dösinger 10 Jul '16

10 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Patrick, I ran your tests on one of my Nvidia machines, see below. Thanks for looking into this. I had problems with a few games (3DMark2001, Call of Duty Modern Warfare) doing stupid buffer / texture mapping calls that forced my command stream code to wait. Your findings may have some answers to why they work better on Windows. Please port this test to ddraw, d3d8, d3d10 and d3d11 as well. I know it's a lot of work, but the APIs might have different behavior for compatibility reasons, and I know at least one ddraw game that requires that we ignore redundant D3DLOCK_DISCARD locks (see commit d3520ef4, bug 32485). Am 2016-07-08 um 17:15 schrieb Patrick Rudolph: > + { > + "D3DLOCK_NOOVERWRITE", > + D3DLOCK_NOOVERWRITE, > + FALSE, > + TRUE, > + TRUE > + }, > + { It seems that this is not true on my Nvidia card: > visual.c:21966: Driver string: "nvd3dum.dll" > visual.c:21967: Description string: "NVIDIA GeForce GT 650M" > visual.c:21970: Device name string: "\\.\DISPLAY1" > visual.c:21972: Driver version 10.18.13.5900 > ... > visual.c:5503: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE. Dynamic = 0. > visual.c:5503: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. If AMD GPUs accept D3DLOCK_NOOVERWRITE on non-dynamic buffers we can pick any behavior in Wine because games can't rely on it on Windows. I'll run the test on AMD GPUs later, currently all my machines with AMD GPUs are in a rather bad shape :-\ . > + hr = IDirect3DDevice9_SetRenderState(device, D3DRS_FOGENABLE, FALSE); > + ok(SUCCEEDED(hr), "Failed to disable fog, hr %#x.\n", hr); This is redundant. > + /* sanity check */ > + hr = IDirect3DDevice9_CreateVertexBuffer(device, sizeof(quad_strip1), 0, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + ok(SUCCEEDED(hr), "Failed to create vertex buffer, hr %#x.\n", hr); Is there any place where this would fail, but the other tests succeed? My sense is that if something as basic as a vertex buffer draw is broken we'd have mass test failures anyway. > + /* Increase triangle draw count for faster GPUs. > + Limit size to 0x40000 as bigger values causes the Nvidia driver to crash. */ As mentioned I'll test this on other machines as well, it might make sense to use a pixel shader that calculates square roots in a loop to slow down the GPU if the current setup is unreliable. > + if (tests[i].dynamic) > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, D3DUSAGE_DYNAMIC, 0, D3DPOOL_DEFAULT, &buffer, NULL); > + else > + hr = IDirect3DDevice9_CreateVertexBuffer(device, size, 0, 0, D3DPOOL_DEFAULT, &buffer, NULL); You could store a DWORD of flags in the tests structure and set it either to 0 or D3DUSAGE_DYNAMIC. That way you can avoid the branch and it makes the tests array easier to read IMO. > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, size, (void **)&quad_strip_array, 0); > + ok(SUCCEEDED(hr), "Failed to lock vertex buffer, hr %#x.\n", hr); > + if (!SUCCEEDED(hr) || !quad_strip_array) > + { > + IDirect3DVertexBuffer9_Release(buffer); > + continue; > + } You don't really need the if branch. If the call fails the ok() call will already mean that the test fails, and we don't really care about error handling after that. I.e., if you have a test failure it's no problem if you segfault afterwards. (It would matter if you ok is marked todo_wine or has a broken() clause because it fails in some cases on Windows.) > + ok(hr == D3D_OK, "Failed to set stream source, hr %#x.\n", hr); Please consistently use SUCCEEDED(hr). Yeah, I know the existing code isn't perfect regarding this :-( . > + hr = IDirect3DVertexBuffer9_Lock(buffer, (quads - 1) * sizeof(quad_strip1), sizeof(quad_strip1), (void **)&quad_strip_array, D3DLOCK_READONLY); What is the purpose of the readonly lock here? I think it would be interesting to test how D3DLOCK_READONLY behaves regarding synchronization too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgk0zAAoJEN0/YqbEcdMwDDMP/3lJ/4Uu4hHSy9KWeLz5wDxH mq9cmVCon/34BlPOTAzIvYJ1tEoFnNGrXur5iuYgOuCq/4m8TZA7W10pCYEJ7yYE xS90d2udHsxYBEBoPDXzUff5GFdkRv53AX6IdYc2BmuPN+jA9+j51TxN9qWqYMHK XNV76BDZC8EZ+mQyTov82CsSsn0K3TvhBa/1njDlbUvuNuvuaDm7qzBMqooZycgv AejEiI/dwHPyu0dmAJxHjpEJl5FozdOELJwoRtXFCp2LANnWqCAugKkjD9O1kQsb u0/iKowANpHkP+VS1PkG5dZeIEJjM2lHlopUigwjeBY/SQ/Pdlh2wfJT3HWGKnEo mnACOI4xHGp5XyNX6iit1W5mjRtv0ZiMNaTawjvptTfMM54XopsuMw+hAK+6itLo 7fgccAGUhZo+Uun2p5ceZSr+2+J7q3TUtWlh633m8yW1jz/82jer2soyDoiFw+ap uo3+w8iQ2RUTrmD2kJ7dh0ZSaHeqSh522yi3fExbyyyFQiGd5S1CBaUgrHdnt56Z ciQWEb/hhJyAhLhlbjqJuaYaaozBwXrWCkpX2uRluOoMZFN3H7mi76jtNLys8mOO eQRQrw1j9vuN/vxEz1yg5NQMvV9PImrc1p56HYn2NXMqVptABjhcnyRpNwnB2ar+ PH/xwUDQRY9CTGRkt4dR =d9bG -----END PGP SIGNATURE-----

1 0

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

09 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=24129 Your paranoid android. === w7pro64 (64 bit nstc) === nstc.c:1953: Test failed: Got event 17, count 1

2 1

Re: explorerframe/tests: Use EqualRect() instead of open coding it.
by Marvin 09 Jul '16

09 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=24131 Your paranoid android. === w7pro64 (32 bit nstc) === nstc.c:1941: Test failed: Got event 17, count 1 === w7pro64 (64 bit nstc) === nstc.c:1951: Test failed: Got event 17, count 1

1 0

Re: explorerframe/tests: The width is between the RECT left and right fields
by Marvin 09 Jul '16

09 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=24130 Your paranoid android. === w7pro64 (64 bit nstc) === nstc.c:1946: Test failed: Got event 17, count 1

1 0

Re: [PATCH 2/2] wined3d/resource: Performance improvements
by Marvin 08 Jul '16

08 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=24126 Your paranoid android. === w8 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (32 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (64 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (64 bit visual) === visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4578: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1.

1 0

Re: [PATCH 1/2] d3d9/tests/visual: Add Vertexbuffer locking tests
by Marvin 08 Jul '16

08 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=24125 Your paranoid android. === w8 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (32 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w864 (64 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1. === w1064 (64 bit visual) === visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 0. visual.c:4573: Test failed: Expected buffer mapped unsyncronized. Flags = D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD. Dynamic = 1.

1 0

Re: [PATCH] xmllite/writer: Support trivial case of WriteAttributeString()
by Marvin 08 Jul '16

08 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=24119 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/2] wscript: Added WScript.Quit tests.
by Marvin 08 Jul '16

08 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=24118 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/5] d3d11/tests: Add test for immediate constant buffer.
by Marvin 08 Jul '16

08 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=24114 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/5] d3d10core/tests: Add test for vertex formats.
by Marvin 08 Jul '16

08 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=24113 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] d3d11/tests: Add test for vertex formats.
by Marvin 08 Jul '16

08 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=24112 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/3] wininet/tests: Add a test for recently introduced regression related to InternetCrackUrl.
by Marvin 08 Jul '16

08 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=24111 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/3] wininet/tests: Avoid unnecessary initialization of variables.
by Marvin 08 Jul '16

08 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=24110 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/3] wininet: Correctly set lpszUrlPath in InternetCrackUrlW for urls without path component.
by Marvin 08 Jul '16

08 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=24109 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: gdi32: Remove unused function.
by Sebastian Lackner 08 Jul '16

08 Jul '16

On 08.07.2016 12:25, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/gdi32/region.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/dlls/gdi32/region.c b/dlls/gdi32/region.c > index 0b0ff47..1e10221 100644 > --- a/dlls/gdi32/region.c > +++ b/dlls/gdi32/region.c > @@ -149,11 +149,6 @@ static inline void empty_region( WINEREGION *reg ) > reg->extents.left = reg->extents.top = reg->extents.right = reg->extents.bottom = 0; > } > > -static inline BOOL is_in_rect( const RECT *rect, int x, int y ) > -{ > - return (rect->right > x && rect->left <= x && rect->bottom > y && rect->top <= y); > -} > - > /* > * number of points to buffer before sending them off > * to scanlines() : Must be an even number > I assume it was intentional to remove the is_in_rect() check from PtInRegion, but is it really such a good idea? For points outside of the extents rectangle it increased runtime from O(1) to O(log N), which could still matter in practice.

2 1

Re: gdi32: Optionally return the type from GDI_GetObjPtr().
by Dmitry Timoshkov 08 Jul '16

08 Jul '16

Huw Davies <huw(a)codeweavers.com> wrote: > This enables get_dc_obj() to check the type without calling GetObjectType() > and thus it saves additional calls to Enter/LeaveCriticalSection(). > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > This reduces the runtime of the dib tests by about 8% and achieves a similar > increase in performance with the drawing phase of a (gdi heavy) app I'm > looking at. ... > - bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP ); > + bmp = GDI_GetObjPtr( hbitmap, OBJ_BITMAP, NULL ); Did you consider introducing GDI_GetObjPtrEx() with additional pointer to type, and making a shortcut by defining/calling it by a not Ex version? That would simplify the patch and avoid penalizing/changing the callers that don't need the type. -- Dmitry.

3 3

Re: [v3] riched20: Add support for ECO_NOHIDESEL flag
by Huw Davies 08 Jul '16

08 Jul '16

On Fri, Jul 08, 2016 at 12:32:55PM +0200, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/riched20/editor.c | 9 +++++++-- > dlls/riched20/paint.c | 6 ++++-- > 2 files changed, 11 insertions(+), 4 deletions(-) > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 13a2857..cb6fe3d 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -3453,14 +3453,15 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > ME_RewrapRepaint(editor); > } > > + if ((changedSettings & settings & ECO_NOHIDESEL) && !editor->bHaveFocus) > + ME_InvalidateSelection( editor ); > + Actually on reflection, I think comparing with ES_NOHIDESEL is slightly less confusing, so let's go with v2. Huw.

1 0

Re: riched20: Add support for ECO_NOHIDESEL flag
by Huw Davies 08 Jul '16

08 Jul '16

On Fri, Jul 08, 2016 at 11:34:11AM +0200, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > > This patch also fixes control behavior when ECO_NOHIDESEL is not specified > and the control looses focus (for bug 40915). > --- > dlls/riched20/editor.c | 9 +++++++-- > dlls/riched20/paint.c | 6 ++++-- > 2 files changed, 11 insertions(+), 4 deletions(-) > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 13a2857..b7864eb 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -3453,14 +3453,15 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > ME_RewrapRepaint(editor); > } > > + if ((changedSettings & settings & ECO_NOHIDESEL) && !editor->bHaveFocus) > + ME_InvalidateSelection( editor ); > + > if (changedSettings & settings & ECO_VERTICAL) > FIXME("ECO_VERTICAL not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOHSCROLL) > FIXME("ECO_AUTOHSCROLL not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOVSCROLL) > FIXME("ECO_AUTOVSCROLL not implemented yet!\n"); > - if (changedSettings & settings & ECO_NOHIDESEL) > - FIXME("ECO_NOHIDESEL not implemented yet!\n"); > if (changedSettings & settings & ECO_WANTRETURN) > FIXME("ECO_WANTRETURN not implemented yet!\n"); > if (changedSettings & settings & ECO_AUTOWORDSELECTION) > @@ -4257,6 +4258,8 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > editor->bHaveFocus = TRUE; > ME_ShowCaret(editor); > ME_SendOldNotify(editor, EN_SETFOCUS); > + if (!editor->bHideSelection && !(editor->styleFlags & ECO_NOHIDESEL)) I think this, and all subsequent ECO_NOHIDESELs, would be better as ES_NOHIDESEL. The first one is fine as ECO_NOHIDESEL, since that's the setting one. Huw.

2 3

Re: [PATCH 02/12] d3drm: Move d3drm_device struct to d3drm_private.h.
by Aaryaman Vasishta 08 Jul '16

08 Jul '16

> > +struct d3drm_device > +{ > + IDirect3DRMDevice IDirect3DRMDevice_iface; > + IDirect3DRMDevice2 IDirect3DRMDevice2_iface; > + IDirect3DRMDevice3 IDirect3DRMDevice3_iface; > + IDirect3DRMWinDevice IDirect3DRMWinDevice_iface; > + IDirect3DRM *d3drm; > + IDirectDraw *ddraw; > + IDirectDrawSurface *primary_surface, *render_target; > + IDirectDrawClipper *clipper; > + IDirect3DDevice *device; > + LONG ref; > + BOOL dither; > + D3DRMRENDERQUALITY quality; > + DWORD rendermode; > + DWORD height; > + DWORD width; > +}; > + > > I should remove the current forward declaration now that this patch moves the definition here.

1 0

Re: [PATCH 04/12] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback.
by Aaryaman Vasishta 08 Jul '16

08 Jul '16

On Thu, Jul 7, 2016 at 7:22 PM, Aaryaman Vasishta <jem456.vasishta(a)gmail.com > wrote: > > @@ -65,6 +65,7 @@ void d3drm_device_destroy(struct d3drm_device *device) > IDirectDraw_Release(device->ddraw); > IDirect3DRM_Release(device->d3drm); > } > + d3drm_object_cleanup((IDirect3DRMObject > *)&device->IDirect3DRMDevice_iface, &device->obj); > HeapFree(GetProcessHeap(), 0, device); > } > I should've probably put d3drm_object_cleanup at the beginning.

1 0

Re: [PATCH v2 3/3] winex11.drv: fix NULL pointer dereference (clang)
by Alexandre Julliard 08 Jul '16

08 Jul '16

Kirill Smirnov <kirill.k.smirnov(a)gmail.com> writes: > @@ -1679,6 +1679,11 @@ static void xrender_put_image( Pixmap src_pixmap, Picture src_pict, Picture mask > } > else > { > + if (!physdev) > + { > + ERR("physdev is NULL\n"); > + return; > + } This should never happen. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.
by flan 08 Jul '16

08 Jul '16

What is wrong with the patch? Right now the most glaring formatting issue I can find is inconsistent spacing in a variable declaration, but I'm asking just in case there are more problems I haven't noticed.

3 7

[PATCH] server: Move the \BaseNamedObjects symlink from \Sessions\0 to \Sessions\1\BaseNamedObjects.
by flan 07 Jul '16

07 Jul '16

What is wrong with the patch? Right now the most glaring formatting issue I can find is inconsistent spacing in a variable declaration, but I'm asking just in case there are more problems I haven't noticed.

1 0

Re: [PATCH 01/12] d3drm: Store reference to IDirect3DRM in struct d3drm_device.
by Aaryaman Vasishta 07 Jul '16

07 Jul '16

The end of the subject should have "d3drm_device_create" instead of "struct d3drm_device". On Thu, Jul 7, 2016 at 8:18 PM, Marvin <testbot(a)winehq.org> wrote: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

1 0

Re: [PATCH] wininet: fix the bug can not save proxy bypass server into regedit by ie internet options dialog
by Alex Henrie 07 Jul '16

07 Jul '16

Hi huangxuewei, Thanks for your interest in contributing to Wine! The Wine project requires you to use your real name (with capitalization and spaces) when submitting patches. It would also help to link to a bug report in the patch email, and to add tests to demonstrate that the behavior you want is the correct behavior. -Alex

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4)
by Marvin 07 Jul '16

07 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=24060 Your paranoid android. === wvistau64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). sock: unhandled exception c0000005 at 00000000 === w7u (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w8 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (32 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === wvistau64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (64 bit sock) === sock.c:6149: Test failed: IPV6_V6ONLY is enabled after bind. sock.c:6158: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well).

1 0

Re: [PATCH 3/3] mshtml: Export IElementSelector for all elements in compatibility mode >= IE8.
by Marvin 07 Jul '16

07 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=24059 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: [10/10] webservices: Implement WsWriteBody.
by Marvin 07 Jul '16

07 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=24055 Your paranoid android. === build (build) === Make failed

1 0

Re: [09/10] webservices: Implement WsWriteEnvelopeEnd.
by Marvin 07 Jul '16

07 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=24054 Your paranoid android. === build (build) === Make failed

1 0

Re: [08/10] webservices: Implement WsWriteEnvelopeStart.
by Marvin 07 Jul '16

07 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=24053 Your paranoid android. === build (build) === Make failed

1 0

Re: [07/10] webservices: Implement WsAddressMessage.
by Marvin 07 Jul '16

07 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=24052 Your paranoid android. === build (build) === Make failed

1 0

Re: [06/10] webservices: Implement WsInitializeMessage.
by Marvin 07 Jul '16

07 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=24051 Your paranoid android. === build (build) === Make failed

1 0

Re: [05/10] webservices: Implement WsCreateMessageForChannel.
by Marvin 07 Jul '16

07 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=24050 Your paranoid android. === build (build) === Make failed

1 0

Re: [03/10] webservices: Allow integer values to be passed by pointer in WsWriteType.
by Marvin 07 Jul '16

07 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=24049 Your paranoid android. === build (build) === Make failed

1 0

Re: [02/10] webservices: Inherit the prefix only if parent and child namespaces match.
by Marvin 07 Jul '16

07 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=24048 Your paranoid android. === build (build) === Make failed

1 0

Re: [01/10] webservices: Add support for writing double values.
by Marvin 07 Jul '16

07 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=24047 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH v3 6/6] shell32: Set output interfaces to NULL in FolderItems functions.
by Michael Stefaniuc 07 Jul '16

07 Jul '16

On 07/06/2016 06:55 AM, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shelldispatch.c | 9 ++++++++- > dlls/shell32/tests/shelldispatch.c | 3 --- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index 6d7973e..2705389 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -1063,12 +1063,16 @@ static HRESULT WINAPI FolderItemsImpl_get_Application(FolderItems3 *iface, IDisp > if (!ppid) > return E_INVALIDARG; > > + *ppid = NULL; > return E_NOTIMPL; > } > > static HRESULT WINAPI FolderItemsImpl_get_Parent(FolderItems3 *iface, IDispatch **ppid) > { > - FIXME("(%p,%p)\n", iface, ppid); > + TRACE("(%p,%p)\n", iface, ppid); > + > + if (ppid) > + *ppid = NULL; This two if's look odd: one for ppid and then for !ppid. Why don't you just unconditionally do the NULL assignment after the check below? > if (!ppid) > return E_INVALIDARG; bye michael

2 2

Re: [2/2] kernel32/tests: Add a test for sorting of InMemoryOrderModuleList.
by Marvin 07 Jul '16

07 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=24042 Your paranoid android. === w7u (32 bit loader) === loader.c:2308: Test failed: WaitForSingleObject failed: 102 loader.c:2310: Test failed: expected exit code 199, got 259 loader.c:2329: Test failed: expected 198, got 199 === w1064 (32 bit loader) === loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2742: Test failed: Test 3: Wrong callback count: 0 loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2742: Test failed: Test 4: Wrong callback count: 0 loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w864 (64 bit loader) === loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195 === w1064 (64 bit loader) === loader.c:2733: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 0: expected 00007FFC76DA5510, got 0000000000000000 loader.c:2733: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 1: expected 00007FFC6EFE1B00, got 0000000000000000 loader.c:2733: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2734: Test failed: Test 2: expected 00007FFC76DA2390, got 0000000000000000 loader.c:2741: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2742: Test failed: Test 3: Wrong callback count: 0 loader.c:2741: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2742: Test failed: Test 4: Wrong callback count: 0 loader.c:1820: Test failed: expected STILL_ACTIVE, got 195 loader.c:1855: Test failed: expected STILL_ACTIVE, got 195

2 1

Re: [PATCH 1/3] kernel32/tests/fiber: Add tests for fiber-local storage.
by André Hentschel 06 Jul '16

06 Jul '16

Am 02.07.2016 um 04:41 schrieb John Sheu: > Signed-off-by: John Sheu <sheu(a)google.com> Hi and welcome to Wine development! May I ask if you could name an application which will benefit from your fixes? Your tests currently fail on our testbot as you can see here: https://source.winehq.org/patches/ Some inline comments: > 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" ); > + } > + else > + { > + PVOID pret; > + BOOL bret; > + > + pret = FlsGetValue(fls_index_to_set); > + ok(pret == NULL, "FlsGetValue returned %p, expected NULL\n", pret); > + > + /* Set the FLS value */ > + SetLastError( 0xdeadbeef ); > + 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 = FlsGetValue(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]); > } You are mixing tabs and spaces in FiberMainProc, spaces are preferred. Further you can avoid some line brakes in ok() calls, only wrap at around 100 > +static void test_FiberLocalStorageWithFibers(PFLS_CALLBACK_FUNCTION cbfunc) { > + PVOID val1 = (PVOID) 0x314; > + PVOID val2 = (PVOID) 0x152; > + BOOL ret; > + > + if (!pConvertThreadToFiber || !pSwitchToFiber || !pDeleteFiber) > + { > + 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()); > + > + fiberCount = 0; > + cbCount = 0; > + fibers[0] = pConvertThreadToFiber(&testparam); Why do you convert the current thread into a fiber? It seems to me that is causing the crash on w2k3. You could try to run that test in a seperate thread > + 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()); > + 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); > + } You can make that a one liner: todo_wine ok(); Hope that helps Have fun!

2 1

Re: [PATCH 3/3] wininet: Added semi-stub INTERNET_OPTION_END_BROWSER_SESSION implementation.
by Marvin 06 Jul '16

06 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=24024 Your paranoid android. === w7u (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w8 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14

1 0

Re: [PATCH 2/3] wininet: Always set returned size in InternetGetCookieExA.
by Marvin 06 Jul '16

06 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=24023 Your paranoid android. === w7u (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w8 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (32 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w7pro64 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14 === w864 (64 bit internet) === internet.c:366: Test failed: InternetGetCookie should have failed with FALSE and error 14

1 0

Re: [PATCH 1/6] wined3d: Implement d3d11_immediate_context_Begin().
by Józef Kucia 06 Jul '16

06 Jul '16

On Wed, Jul 6, 2016 at 12:02 PM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d11/async.c | 5 +++++ > dlls/d3d11/d3d11_private.h | 1 + > dlls/d3d11/device.c | 10 +++++++++- > 3 files changed, 15 insertions(+), 1 deletion(-) The subject prefix should be "d3d11".

1 0

Re: [PATCH] explorer: add registry support to disable Virtual Desktop systray
by Alexandre Julliard 06 Jul '16

06 Jul '16

Rob Walker <bob.mt.wya(a)gmail.com> writes: > Workaround for https://bugs.winehq.org/show_bug.cgi?id=40828 A better approach would be to detect the fullscreen window and automatically hide the taskbar. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 1/3] comdlg32: Init clipboard format only once in filedlg.
by Alexandre Julliard 06 Jul '16

06 Jul '16

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > @@ -3798,6 +3789,25 @@ static void COMCTL32_ReleaseStgMedium (STGMEDIUM medium) > } > > /*********************************************************************** > + * GetFormatEtc > + * > + * Get the FORMATETC used in the shell id list > + */ > +static FORMATETC* GetFormatEtc(void) > +{ > + static FORMATETC formatetc; > + if (!formatetc.cfFormat) > + { > + formatetc.cfFormat = RegisterClipboardFormatA(CFSTR_SHELLIDLISTA); > + formatetc.ptd = 0; > + formatetc.dwAspect = DVASPECT_CONTENT; > + formatetc.lindex = -1; > + formatetc.tymed = TYMED_HGLOBAL; > + } > + return &formatetc; > +} This looks a little risky, since the structure is passed to the application. Caching only the clipboard format should be enough. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] explorer: add registry support to disable Virtual Desktop systray
by Alex Henrie 06 Jul '16

06 Jul '16

+ if (using_root) + { + enable_shell = FALSE; + initialize_systray( graphics_driver, using_root, enable_shell ); + } + else + { + enable_systray=get_default_systray_state(); + initialize_systray( graphics_driver, !enable_systray, enable_shell ); + } I think you should put the same whitespace around the equals sign in both cases. -Alex

1 0

Re: [1/3] imm32, user32: Create and destroy the default IME window implicitly. (try 8)
by Alexandre Julliard 06 Jul '16

06 Jul '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 8: > - Fix user32 test failures. To achieve this, we create the default IME window > as message-only window for now. This doesn't match Windows behavior, as the tests show: ../../../tools/runtest -q -P wine -T ../../.. -M imm32.dll -p imm32_test.exe.so imm32 && touch imm32.ok imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x30066 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:994: Test failed: Expected IME window existence imm32.c:996: Test failed: Expected (nil), got 0x50066 imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x60066 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:994: Test failed: Expected IME window existence imm32.c:996: Test failed: Expected (nil), got 0x80066 imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0xb005e imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence imm32.c:946: Test failed: Expected IME window existence imm32.c:948: Test failed: Expected (nil), got 0x20040 imm32.c:195: Test failed: expected IME window existence imm32.c:209: Test failed: expected IME window existence imm32.c:221: Test failed: expected IME window existence imm32.c:956: Test failed: Expected IME window existence make: *** [imm32.ok] Error 40 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] advapi32: Add some tests for StartTrace().
by Marvin 06 Jul '16

06 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=23920 Your paranoid android. === wxppro (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1185: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7pro64 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w864 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w1064 (32 bit eventlog) === eventlog.c:1172: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1194: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:1255: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:1272: Test failed: Expected success eventlog.c:1280: Test failed: Expected ERROR_ALREADY_EXISTS, got 87

3 3

Re: [PATCH 3/3] regedit: Process the next file, if any, on error (v2)
by Sebastian Lackner 06 Jul '16

06 Jul '16

On 05.07.2016 11:13, Hugh McMaster wrote: > Changes since v1: > * Do not leak memory when moving to the next file. > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regedit.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/programs/regedit/regedit.c b/programs/regedit/regedit.c > index 04dd317..8a6a975 100644 > --- a/programs/regedit/regedit.c > +++ b/programs/regedit/regedit.c > @@ -88,7 +88,7 @@ typedef enum { > ACTION_ADD, ACTION_EXPORT, ACTION_DELETE > } REGEDIT_ACTION; > > -static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > +static void PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > { > switch (action) { > case ACTION_ADD: { > @@ -113,7 +113,9 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > if (size == 0) > { > output_message(STRING_FILE_NOT_FOUND, filename); > - exit(1); > + if (realname) > + HeapFree(GetProcessHeap(), 0, realname); I haven't reviewed the whole series, but passing a NULL pointer to HeapFree() is perfectly fine, and its better to avoid such checks. > + return; > } > reg_file = _wfopen(realname, rb_mode); > if (reg_file == NULL) > @@ -121,7 +123,9 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > WCHAR regedit[] = {'r','e','g','e','d','i','t',0}; > _wperror(regedit); > output_message(STRING_CANNOT_OPEN_FILE, filename); > - exit(1); > + if (realname) > + HeapFree(GetProcessHeap(), 0, realname); Same here. > + return; > } > import_registry_file(reg_file); > if (realname) > @@ -150,7 +154,6 @@ static BOOL PerformRegAction(REGEDIT_ACTION action, WCHAR **argv, int *i) > exit(1); > break; > } > - return TRUE; > } > > BOOL ProcessCmdLine(WCHAR *cmdline) >

2 1

Re: [v2] secur32 : add and fix some algids
by Jacek Caban 06 Jul '16

06 Jul '16

Hi Max, On 03.07.2016 23:41, Max Qian wrote: > diff --git a/include/wincrypt.h b/include/wincrypt.h > index 55c9509..19af6ca 100644 > --- a/include/wincrypt.h > +++ b/include/wincrypt.h > @@ -1583,6 +1583,7 @@ typedef const CERT_CRL_CONTEXT_PAIR *PCCERT_CRL_CONTEXT_PAIR; > #define ALG_SID_AGREED_KEY_ANY 3 > #define ALG_SID_KEA 4 > #define ALG_SID_ECDH 5 > +#define ALG_SID_ECDH_EPHEM 6 > /* RC2 SIDs */ > #define ALG_SID_RC4 1 > #define ALG_SID_RC2 2 > @@ -1639,6 +1640,7 @@ typedef const CERT_CRL_CONTEXT_PAIR *PCCERT_CRL_CONTEXT_PAIR; > #define CALG_KEA_KEYX (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_KEA) > #define CALG_HUGHES_MD5 (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_ANY | ALG_SID_MD5) > #define CALG_ECDH (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_ECDH) > +#define CALG_ECDH_EPHEM (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_DH | ALG_SID_ECDH_EPHEM) > #define CALG_RSA_KEYX (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_RSA | ALG_SID_RSA_ANY) > #define CALG_ECMQV (ALG_CLASS_KEY_EXCHANGE | ALG_TYPE_ANY | ALG_SID_ECMQV) > #define CALG_DES (ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_DES) Do you have a version of PSDK that has this definition? I can't see it here. If those are not in MS headers, we shouldn't have them unless we have a strong reason. When I asked you about adding a comment, I was hoping for something like /* MSDN mentions CALG_ECDH_EPHEM, but it's not available in headers. */ case ....: return CALG_ECDH; Thanks, Jacek

2 1

Re: [PATCH 02/15] mshtml: Rewrite navigation tests using new HTTP emulation framework.
by Marvin 05 Jul '16

05 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=24000 Your paranoid android. === build (build) === Make failed

2 1

Re: [PATCH 14/15] mshtml: Reimplement IHTMLDocument5::get_compatMode based on document mode.
by Marvin 05 Jul '16

05 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=24002 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 13/15] mshtml: Added document.documentMode tests.
by Marvin 05 Jul '16

05 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=24001 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)
by Bruno Jesus 05 Jul '16

05 Jul '16

On Tue, Jul 5, 2016 at 10:33 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. It still looks like there is a formatting problem with the patch, please attach it in a new attempt or use git send-email, also see the comments below. > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++------------- > dlls/ws2_32/tests/sock.c | 51 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 59 insertions(+), 14 deletions(-) > > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY ((LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } If the ok() is supposed to always fail use ok(0, ...). But according to msdn this option is not present in 2003/XP, so you would end up with an error. Better to use win_skip then to avoid this problem. The testbot will test against many different Windows versions so we need to ensure it works everywhere, before resending it would be useful to do a manual run at https://testbot.winehq.org/ to check the patch. > + ok(enabled == 1, "IPV6_V6ONLY is not enabled by default.\n"); > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } This should never fail as the previous test already took care of checking for IPV6_V6ONLY support, so drop the if and goto. > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } Again I think getsockopt must always work at this point. > + ok(!enabled, "IPV6_V6ONLY is enabled after bind.\n"); > + v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); > + if (v4 == INVALID_SOCKET) { > + skip("Could not create IPv4 socket (LastError: %d).\n", > + WSAGetLastError()); > + goto end; > + } > + WSASetLastError(0xdeadbeef); > + ret = bind(v4, (struct sockaddr*)&sin4, sizeof(sin4)); Please also test ok(ret,...); Best wishes, Bruno

1 0

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.
by Nikolay Sivov 05 Jul '16

05 Jul '16

On 05.07.2016 8:47, Alex Henrie wrote: > + if (0) /* crashes on all versions of Windows */ > + { > + r = FolderItems_get_Count(items, NULL); > +todo_wine > + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); > + } Why do you want to handle this case if it crashes consistently on Windows? And todo_wine is not going to do anything in commented block obviously.

2 6

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
by Henri Verbeet 05 Jul '16

05 Jul '16

On 27 June 2016 at 23:54, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > static HRESULT WINAPI d3drm_viewport1_Init(IDirect3DRMViewport *iface, IDirect3DRMDevice *device, > IDirect3DRMFrame *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", > - iface, device, camera, x, y, width, height); > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport(iface); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(camera); Using impl_from_IDirect3DRMFrame() here is unusual. > + if (!device || !camera) > + return D3DRMERR_BADOBJECT; And note that this only works because of the d3drm_frame structure layout. You'll want to use unsafe_impl_from_IDirect3DRMFrame() if "camera" can be NULL.

1 0

Re: ntdll: Add RtlRestoreContext implementation
by Sebastian Lackner 05 Jul '16

05 Jul '16

On 04.07.2016 10:55, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/kernel32/kernel32.spec | 2 +- > dlls/ntdll/ntdll.spec | 1 + > dlls/ntdll/signal_x86_64.c | 73 +++++++++++++++++++++++++-------------------- > 3 files changed, 42 insertions(+), 34 deletions(-) > Your patch also changes unwinding behavior in case of MSVCRT_JUMP_BUFFER. Previously the instruction pointer stored in the jump buffer was ignored, now it will overwrite the value passed as target_ip. Is that intentional?

2 1

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)
by Marvin 05 Jul '16

05 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=23992 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: krnl386.exe16: Fix a typo in comment.
by Huw Davies 05 Jul '16

05 Jul '16

On Tue, Jul 05, 2016 at 03:36:30PM +0300, Andrey Gusev wrote: > diff --git a/dlls/krnl386.exe16/file.c b/dlls/krnl386.exe16/file.c > index 4e7f7c4..44b1e75 100644 > --- a/dlls/krnl386.exe16/file.c > +++ b/dlls/krnl386.exe16/file.c > @@ -549,7 +549,7 @@ INT16 WINAPI GetPrivateProfileString16( LPCSTR section, LPCSTR entry, > if (!entry) > { > /* We have to return the list of keys in the section but without the values > - * so we need to massage the results of GetPrivateProfileSectionA. > + * so we need to message the results of GetPrivateProfileSectionA. > */ > UINT ret, oldlen = len, size = min( len, 1024 ); > LPSTR data, src; No, again the original is correct. Huw.

1 0

Re: gdi32/dibdrv: Fix a typo in comment.
by Huw Davies 05 Jul '16

05 Jul '16

On Tue, Jul 05, 2016 at 03:33:39PM +0300, Andrey Gusev wrote: > diff --git a/dlls/gdi32/dibdrv/graphics.c b/dlls/gdi32/dibdrv/graphics.c > index bfb3451..ca357b2 100644 > --- a/dlls/gdi32/dibdrv/graphics.c > +++ b/dlls/gdi32/dibdrv/graphics.c > @@ -1567,7 +1567,7 @@ COLORREF dibdrv_SetPixel( PHYSDEV dev, INT x, INT y, COLORREF color ) > rect.bottom = rect.top + 1; > add_clipped_bounds( pdev, &rect, pdev->clip ); > > - /* SetPixel doesn't do the 1bpp massaging like other fg colors */ > + /* SetPixel doesn't do the 1bpp messaging like other fg colors */ > pixel = get_pixel_color( dev->hdc, &pdev->dib, color, FALSE ); > color = pdev->dib.funcs->pixel_to_colorref( &pdev->dib, pixel ); No, the original is correct. Huw.

1 0

Re: [PATCH 2/5] shell32: Stub out FolderItems.
by Sebastian Lackner 05 Jul '16

05 Jul '16

On 04.07.2016 07:25, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. Actually the patch looks very similar, but this is probably caused by the fact that you both wrote it based on existing code. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > Some of the variable names (for example ppTInfo, rgszNames, rgDispId) sound a bit odd. Usually variable names without ugly prefix are preferred for new code (except we want to keep it for compatibility with old code here?). > +static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > +{ > + FIXME("(%p,%p)\n", iface, ppid); You forgot to trace the index parameter here. > + > + return E_NOTIMPL; > +} [...] > @@ -1093,8 +1297,7 @@ static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) > { > FIXME("(%p,%p)\n", iface, ppid); You forgot to change the FIXME to a TRACE. > > - *ppid = NULL; > - return E_NOTIMPL; > + return FolderItems_Constructor(ppid); > } > > static HRESULT WINAPI FolderImpl_ParseName(Folder3 *iface, BSTR name, FolderItem **item) >

3 3

Re: [PATCH v2 2/5] shell32: Stub out FolderItems.
by Nikolay Sivov 05 Jul '16

05 Jul '16

On 05.07.2016 8:47, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index 492f79f..64a26bb 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -234,6 +234,7 @@ enum tid_t { > IShellDispatch6_tid, > IShellFolderViewDual3_tid, > Folder3_tid, > + FolderItems3_tid, > FolderItem2_tid, > FolderItemVerb_tid, > FolderItemVerbs_tid, That's not going to work, you have to update tid_ids[] too. Also please keep it sorted. > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index 6dece6d..3661430 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -65,6 +65,11 @@ typedef struct { > } FolderImpl; > > typedef struct { > + FolderItems3 FolderItems3_iface; > + LONG ref; > +} FolderItemsImpl; > + > +typedef struct { > FolderItem2 FolderItem2_iface; > LONG ref; > VARIANT dir; > @@ -97,6 +102,11 @@ static inline FolderImpl *impl_from_Folder(Folder3 *iface) > return CONTAINING_RECORD(iface, FolderImpl, Folder3_iface); > } > > +static inline FolderItemsImpl *impl_from_FolderItems(FolderItems3 *iface) > +{ > + return CONTAINING_RECORD(iface, FolderItemsImpl, FolderItems3_iface); > +} > + > static inline FolderItemImpl *impl_from_FolderItem(FolderItem2 *iface) > { > return CONTAINING_RECORD(iface, FolderItemImpl, FolderItem2_iface); > @@ -939,6 +949,200 @@ static HRESULT FolderItem_Constructor(VARIANT *dir, FolderItem **ppfi) > return ret; > } > > +static HRESULT WINAPI FolderItemsImpl_QueryInterface(FolderItems3 *iface, > + REFIID riid, LPVOID *ppv) > +{ > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + > + TRACE("(%p,%p,%p)\n", iface, riid, ppv); Usually we trace riid. > + > + if (!ppv) return E_INVALIDARG; This is unusual, do we have a test for that?

1 0

Re: PATCH] ws2_32: Allow user to enable IP dual stack.
by Bruno Jesus 04 Jul '16

04 Jul '16

On Mon, Jul 4, 2016 at 6:35 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. Hi, thanks for the updated version. I believe the patch failed to apply because you added text after it and also an attachment which is inlined while the email is being parsed. The result you can see at [1]. The subject should show how many attempts the patch was sent to, so next subject should be: [PATCH] ws2_32: Allow user to enable IP dual stack (v3) Please see some nitpicks below. [1] http://source.winehq.org/patches/data/123921 > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++-------------- > dlls/ws2_32/tests/sock.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 48 insertions(+), 14 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index b0af3d7..c29bd2b 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3240,20 +3240,6 @@ int WINAPI WS_bind(SOCKET s, const struct > WS_sockaddr* name, int namelen) > } > else > { > -#ifdef IPV6_V6ONLY > - const struct sockaddr_in6 *in6 = (const struct > sockaddr_in6*) &uaddr; > - if (name->sa_family == WS_AF_INET6 && > - !memcmp(&in6->sin6_addr, &in6addr_any, sizeof(struct > in6_addr))) > - { > - int enable = 1; > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, > sizeof(enable)) == -1) > - { > - release_sock_fd( s, fd ); > - SetLastError(WSAEAFNOSUPPORT); > - return SOCKET_ERROR; > - } > - } > -#endif > if (name->sa_family == WS_AF_INET) > { > struct sockaddr_in *in4 = (struct sockaddr_in*) &uaddr; > @@ -7163,6 +7149,14 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + /* Winsock documentation stipulates that IPV6_V6ONLY is enabled > by default*/ The documentation is not always useful (and sometimes wrong) and now we should have a test to back this up, I believe a better comment to be: /* AF_INET6 sockets have IPV6_V6ONLY enabled by default. */ Watch out for missing space between the last comment word and the */ > + int enable = 1; > + WS_setsockopt(ret, WS_IPPROTO_IPV6, WS_IPV6_V6ONLY, &enable, > sizeof(enable)); > + } > +#endif > return ret; > } > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 6853279..7c8d834 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -6114,6 +6114,46 @@ static void test_ipv6only(void) > ok(!ret, "Could not bind IPv4 address (LastError: %d; %d expected if > IPv6 binds to IPv4 as well).\n", > WSAGetLastError(), WSAEADDRINUSE); > > + if (v4 != INVALID_SOCKET) > + closesocket(v4); > + if (v6 != INVALID_SOCKET) > + closesocket(v6); > + > + /* Test again, this time disabling V6ONLY*/ > + v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); > + if (v6 == INVALID_SOCKET) { > + skip("Could not create IPv6 socket (LastError: %d; %d expected if > IPv6 not available).\n", > + WSAGetLastError(), WSAEAFNOSUPPORT); > + goto end; > + } Do a getsockopt at this point to check what is the default enabled value. Set enabled to the opposite of what you expected before the call and test its value after. > + DWORD enabled = 0; > + int len = sizeof(enabled); You cannot declare variables like this in C89 (?) so do it in the function beginning. > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } I understand that you are trying to skip when IPV6_V6ONLY is not present. It will be better if you catch the explicit error case and bail out, something like: WSASetLastError(0xdeadbeef); ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); error = WSAGetLastError(); if (ret) { ok(error == EXPECTED_ERROR, "Failed to disable IPV6_V6ONLY (LastError %d, %d expected).\n", error, EXPECTED_ERROR); goto end; } > ... Best wishes, Bruno

1 0

Re: [PATCH v2 05/11] d3d11/tests: Add test for creating unordered access views.
by Henri Verbeet 04 Jul '16

04 Jul '16

On 4 July 2016 at 12:26, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static void test_create_unordered_access_view(void) > +{ > + static const D3D_FEATURE_LEVEL feature_level = D3D_FEATURE_LEVEL_11_0; > + D3D11_UNORDERED_ACCESS_VIEW_DESC uav_desc; > + D3D11_TEXTURE3D_DESC texture3d_desc; > + D3D11_TEXTURE2D_DESC texture2d_desc; > + ULONG refcount, expected_refcount; > + D3D11_SUBRESOURCE_DATA data = {0}; > + ID3D11UnorderedAccessView *uav; > + struct device_desc device_desc; > + D3D11_BUFFER_DESC buffer_desc; > + ID3D11Device *device, *tmp; > + ID3D11Texture3D *texture3d; > + ID3D11Texture2D *texture2d; > + ID3D11Resource *texture; > + ID3D11Buffer *buffer; > + IUnknown *iface; This is unused.

1 0

Re: PATCH] ws2_32: Allow user to enable IP dual stack.
by Marvin 04 Jul '16

04 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=23959 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/2] msvcr120: Add fegetenv implementation
by Marvin 04 Jul '16

04 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=23946 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 0 === w2008s64 (64 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 10

1 0

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)
by Marvin 04 Jul '16

04 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=23944 Your paranoid android. === wxppro (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2003std (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === wvistau64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2008s64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7u (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7pro64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w8 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w864 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w1064 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161

1 0

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)
by Austin English 04 Jul '16

04 Jul '16

On Jul 4, 2016 1:25 AM, "Zebediah Figura" <z.figura12(a)gmail.com> wrote: > > --- > dlls/advapi32/tests/eventlog.c | 139 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 139 insertions(+) > > diff --git a/dlls/advapi32/tests/eventlog.c b/dlls/advapi32/tests/eventlog.c > index 3ca59c3..5163537 100644 > --- a/dlls/advapi32/tests/eventlog.c > +++ b/dlls/advapi32/tests/eventlog.c > @@ -20,12 +20,15 @@ > > #include <stdarg.h> > > +#include "initguid.h" > #include "windef.h" > #include "winbase.h" > #include "winerror.h" > #include "winnt.h" > #include "winreg.h" > #include "sddl.h" > +#include "wmistr.h" > +#include "evntrace.h" > > #include "wine/test.h" > > @@ -1142,6 +1145,141 @@ static void cleanup_eventlog(void) > ok(bret, "Expected MoveFileEx to succeed: %d\n", GetLastError()); > } > > +static void test_trace(void) > +{ > + const char sessionname[] = "Wine"; > + const char filepath[] = "wine.etl"; > + const LONG lnoffset = ((sizeof(EVENT_TRACE_PROPERTIES) >> 3) + 1) << 3; //pad to 8 bytes > + const LONG lfnoffset = (((lnoffset + sizeof(sessionname)) >> 3) + 1) << 3; //pad to 8 bytes Please avoid C++ style comments, use /* this instead */

1 0

Re: [PATCH signed-off] secur32 : add and fix some algids
by Jacek Caban 03 Jul '16

03 Jul '16

Hi Max, On 27.06.2016 05:29, Max Qian wrote: > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/secur32/schannel_gnutls.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index bcadd47..9d6af60 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -316,10 +316,11 @@ static ALG_ID schannel_get_mac_algid(gnutls_mac_algorithm_t mac) > case GNUTLS_MAC_UNKNOWN: > case GNUTLS_MAC_NULL: return 0; > case GNUTLS_MAC_MD5: return CALG_MD5; > - case GNUTLS_MAC_SHA1: > - case GNUTLS_MAC_SHA256: > - case GNUTLS_MAC_SHA384: > - case GNUTLS_MAC_SHA512: return CALG_SHA; > + case GNUTLS_MAC_SHA1: return CALG_SHA1; > + case GNUTLS_MAC_MD2: return CALG_MD2; > + case GNUTLS_MAC_SHA256: return CALG_SHA_256; > + case GNUTLS_MAC_SHA384: return CALG_SHA_384; > + case GNUTLS_MAC_SHA512: return CALG_SHA_512; > default: > FIXME("unknown algorithm %d\n", mac); > return 0; > @@ -331,8 +332,12 @@ static ALG_ID schannel_get_kx_algid(gnutls_kx_algorithm_t kx) > switch (kx) > { > case GNUTLS_KX_RSA: return CALG_RSA_KEYX; > + case GNUTLS_KX_DHE_PSK: > case GNUTLS_KX_DHE_DSS: > case GNUTLS_KX_DHE_RSA: return CALG_DH_EPHEM; > + case GNUTLS_KX_ECDHE_RSA: > + case GNUTLS_KX_ECDHE_PSK: return CALG_ECDH; MSDN mentions CALG_ECDH_EPHEM, which would fit better, but it seems to be missing in headers. Returning CALG_ECDH is fine with me, but please add a comment about CALG_ECDH_EPHEM. > + case GNUTLS_KX_ECDHE_ECDSA: return CALG_ECDSA; You're mixing tabs and spaces. Please avoid using tabs. Thanks, Jacek

3 2

Re: [PATCH] wined3d/resource: Performance improvement
by Patrick Rudolph 03 Jul '16

03 Jul '16

On 2016-07-03 11:55 AM, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-03 um 10:04 schrieb Henri Verbeet: >> Finally, there the possibility that Windows filters invalid flag >> combinations like Wine currently does, and picking either DISCARD >> or NOOVERWRITE will break an application that depends on that. > When I originally added support for dynamic buffers in 2010 or so I > just forwarded the flags to the driver. That did break some > applications. I'll try to find out which one it was, I believe I put > some details in the patch description. > > It's also possible that there are some differences between textures > and buffers. In d3d <= 9, D3DLOCK_NOOVERWRITE is not supported on > textures. So it might be filtered out, and DISCARD prevails. But my > understanding is that Unigine uses the questionable combination on > buffers, not textures. > It uses both flags on buffers in d3d9 mode. I'm going to add tests for it. Regards, Patrick > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXeOEWAAoJEN0/YqbEcdMwBRQP/jsjUZXuKbUeoh3iaorwY02B > qZXhtc2IbQlZt2989jAGIjuZoCtE2sP8oRkmtbGI3nfIthOxFKrwcPKnqYiz40aF > JqCqYiwMNSpcqDKEhC92w8ad4F8AMBIG/4IUVBtU/uL0W2fBKNJ0rKE4v2sNefo1 > OTa0ZCtUSCbvErO9xgen43KparIRNK1juxlkE7CVHkWwK3oBl8GO+IzJ6ZKSN54A > ftz48C7if3y0ul2Xs/HVC/J3UqnksgL1sRnxUeDrFC6MRsNQZaf0D3Gn9vUdqukt > t+hxArnt6DEgMiPlbh3Zhoso4lNzoJJxPpldmWYAgEiU5l6BqVnvSuDUzZZGjLqz > 8dg0QEzjDbta5rLwMi6NnZxTYinx8F61YMOUSfMIkKofz4Xc7v2TnEsgMRI9XuoV > f9KZVssvpYoBuQHI0qEpK4eEBqlU/ZtFh39O+j13980Z6wNtnCQVYUtMcY8hU8Nv > kf5iN/eOuMVrMV6EKqZswJe1CHfAfhVhLfD9kOMRREb5MjrAVyreigbHR/RXG3BH > K9bWwCnnaVfQDtJzUw9ab+e+uSbkkiymjrkWY8JKI3E0d8YBnupxS8GcwJTT0y0t > x5K/Fzp/a2U+x4FV8MZewIhT4azA+DEsgHi/6dviRi6/8ct6J4TTZZqCRKtgWFBy > O8waYy1TvNoBQETnhMaC > =7Pmz > -----END PGP SIGNATURE-----

1 0

Re: Re: [PATCH] wined3d/resource: Performance improvement
by Patrick Rudolph 03 Jul '16

03 Jul '16

> It makes logical sense to me that mapping a buffer with both DISCARD and > NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at > least some engines will map a part of a buffer with NOOVERWRITE and draw > with that part, map the next part of the buffer with NOOVERWRITE and > draw with that part, etc, then after the last part of the buffer it maps > with DISCARD to get new memory and keep going while the previous buffer > memory is handled asynchronously by the driver or card. > > I notice that wined3d has some parts where it ignores/removes DISCARD, > so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. > In such a case, the driver will get NOOVERWRITE for a part of the buffer > that's still in use. It would probably be better to remove NOOVERWRITE > when both DISCARD and NOOVERWRITE are set. Both flags are independent of each other and provide useful information to the OpenGL driver. The driver knows best how to map the resource. By passing NOOVERWRITE and DISCARD it's likely going to use NOOVERWRITE, as it's even less overhead than DISCARD. I don't think that WINE should drop flags, except there's a driver bug that can't be fixed (in the near future). Regards, Patrick

3 2

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

02 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=23919 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 2/3] kernel32/tests/loader: Add tests for fiber-local storage.
by Marvin 02 Jul '16

02 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=23918 Your paranoid android. === w2003std (32 bit loader) === loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 1, expected 2 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 0, expected 1 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 2, expected 3 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 === w864 (32 bit loader) === loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195 === w1064 (32 bit loader) === loader.c:2830: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2830: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2830: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2838: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2839: Test failed: Test 3: Wrong callback count: 0 loader.c:2838: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2839: Test failed: Test 4: Wrong callback count: 0 loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195 === w1064 (64 bit loader) === loader.c:2830: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 0: expected 00007FFC76DA5510, got 0000000000000000 loader.c:2830: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 1: expected 00007FFC6EFE1B00, got 0000000000000000 loader.c:2830: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 2: expected 00007FFC76DA2390, got 0000000000000000 loader.c:2838: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2839: Test failed: Test 3: Wrong callback count: 0 loader.c:2838: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2839: Test failed: Test 4: Wrong callback count: 0 loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195

1 0

Re: [PATCH 1/3] kernel32/tests/fiber: Add tests for fiber-local storage.
by Marvin 02 Jul '16

02 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=23917 Your paranoid android. === w2003std (32 bit fiber) === fiber: unhandled exception c0000005 at 77E61897

1 0

Re: mmdevapi/tests: Fix typos in a few ok() messages.
by Marvin 02 Jul '16

02 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=23913 Your paranoid android. === w8 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:263: Test failed: Position 2167 expected 1463 capture.c:325: Test failed: Position 3255 gap 1344 capture.c:349: Test failed: Position 4343 expected 3703 capture.c:374: Test failed: Position 4791 expected 4151 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:263: Test failed: Position 2167 expected 1463 capture.c:325: Test failed: Position 3255 gap 1344 capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:349: Test failed: Position 4343 expected 3703 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 4791 expected 4151 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:181: Test failed: Position 119 expected 0 capture.c:231: Test failed: Position 2167 expected 567 capture.c:263: Test failed: Position 2167 expected 567 capture.c:325: Test failed: Position 3191 gap 2176 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 12992 vs. BufferSize 21996 capture.c:349: Test failed: Position 5303 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5751 expected 5047

1 0

Re: [PATCH] winspool.drv: Support cups 2.2 header update
by Bruno Jesus 01 Jul '16

01 Jul '16

On Fri, Jul 1, 2016 at 6:32 PM, Michael Cronenworth <mike(a)cchtml.com> wrote: > Signed-off-by: Michael Cronenworth <mike(a)cchtml.com> > --- > dlls/winspool.drv/info.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c > index 3ba94cd..5468066 100644 > --- a/dlls/winspool.drv/info.c > +++ b/dlls/winspool.drv/info.c > @@ -43,6 +43,9 @@ > #include <signal.h> > #ifdef HAVE_CUPS_CUPS_H > # include <cups/cups.h> > +# if CUPS_VERSION_MAJOR > 2 || (CUPS_VERSION_MAJOR == 2 && CUPS_VERSION_MINOR > 1) > +# include <cups/ppd.h> > +# endif > #endif Hi, AFAICS this other patch from Ken Thomases in the queue will do the same: http://source.winehq.org/patches/data/123755 Best wishes, Bruno

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack.
by Bruno Jesus 01 Jul '16

01 Jul '16

On Thu, Jun 30, 2016 at 5:57 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. Hi, can you explain more about what is the problem? Is there any application affected? > @@ -7163,6 +7149,14 @@ SOCKET WINAPI WSASocketW(int af, int type, int protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > +#ifdef IPV6_V6ONLY > + if (af == WS_AF_INET6) > + { > + // dual stack (v4+v6) should be disabled by default > + int enable = 1; > + WS_setsockopt(ret, WS_IPPROTO_IPV6, WS_IPV6_V6ONLY, &enable, sizeof(enable)); > + } > +#endif > return ret; > } // comments are not allowed, use /* */. Please use unixaf == AF_INET6 as the code uses that as the af var was already parsed by this point in the code. And please write tests to prove this behavior, create the AF_INET6 socket and getsockopt(IPV6_V6ONLY) in order to determine the default on Windows and then bind and read again to prove it does not change automagically (like Wine is doind). Since in Wine the operation is only done when binding to anyaddr it should be useful to also try a specific address bind and check too. Best wishes, Bruno

1 0

Re: [PATCH] xaudio2: Always set current OpenAL context before making AL calls
by Chris Robinson 30 Jun '16

30 Jun '16

On 06/30/2016 12:07 PM, Andrew Eikum wrote: > if(!alcIsExtensionPresent(NULL, "ALC_SOFT_loopback") || > !(palcLoopbackOpenDeviceSOFT = alcGetProcAddress(NULL, "alcLoopbackOpenDeviceSOFT")) || > - !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT"))){ > + !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT")) || > + !(palcSetThreadContext = alcGetProcAddress(NULL, "alcSetThreadContext"))){ > ERR("XAudio2 requires the ALC_SOFT_loopback extension (OpenAL-Soft >= 1.14)\n"); > return FALSE; > } alcSetThreadContext isn't part of the ALC_SOFT_loopback extension, you should check for ALC_EXT_thread_local_context instead. > +static void context_lock(ALCcontext *ctx) > +{ > + EnterCriticalSection(&al_lock); > + alcMakeContextCurrent(ctx); > +} > + > +static void context_unlock(void) > +{ > + LeaveCriticalSection(&al_lock); > +} Since you're relying on ALC_EXT_thread_local_context anyway, it would probably be better to use alcSetThreadContext in context_lock, which would allow you to get rid of the global lock for normal calls (another thread can't change the current thread context on you, and unlike OpenGL, the same context can be current on multiple threads at the same time).

2 1

Re: [PATCH] wined3d/resource: Performance improvement
by Chris Robinson 30 Jun '16

30 Jun '16

On 06/30/2016 10:20 AM, Patrick Rudolph wrote: > Tests on Windows showed that mapping a buffer with flags WINED3D_MAP_DISCARD > and WINED3D_MAP_NOOVERWRITE is valid combination. Writing reliable tests > is difficult as the driver is free to choose when using discard. > > 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. It makes logical sense to me that mapping a buffer with both DISCARD and NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at least some engines will map a part of a buffer with NOOVERWRITE and draw with that part, map the next part of the buffer with NOOVERWRITE and draw with that part, etc, then after the last part of the buffer it maps with DISCARD to get new memory and keep going while the previous buffer memory is handled asynchronously by the driver or card. I notice that wined3d has some parts where it ignores/removes DISCARD, so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. In such a case, the driver will get NOOVERWRITE for a part of the buffer that's still in use. It would probably be better to remove NOOVERWRITE when both DISCARD and NOOVERWRITE are set.

1 0

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
by Aaryaman Vasishta 30 Jun '16

30 Jun '16

On Tue, Jun 28, 2016 at 3:24 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > + if (viewport->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + IDirect3DRM_AddRef(viewport->d3drm); > + > FWIW, I didn't put the intentional d3drm, camera leaks here because it seems that the device controls the leaked references via some sort of destroy callback on the device. (See the todo_wine tests in this patch). > + todo_wine ok(ref4 > frame_ref2, "Expected ref4 > frame_ref2, got > frame_ref2 = %u, ref4 = %u.\n", frame_ref2, ref4); > + > + IDirect3DRMDevice3_Release(device3); > + IDirect3DRMDevice_Release(device1); > I tried to release d3drm explicitly myself, like how I did with the texture tests. But the tests would then crash here, at IDirect3DRMDevice_Release, where the device gets destroyed. Which probably indicates that the device stores a list of leaked references and releases them on getting destroyed. For now I've decided to avoid the leak, thus avoiding the use of a destroy callback, and implementing this as a separate later on if an application demands it, unless it's safer to get this done on priority. Cheers, Aaryaman

1 0

Re: [PATCH 5/7] d3drm: Fix device not assigning width and height after creation.
by Henri Verbeet 30 Jun '16

30 Jun '16

On 24 June 2016 at 23:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > HRESULT d3drm_device_set_ddraw_device_d3d(struct d3drm_device *device, IDirect3DRM *d3drm, IDirect3D *d3d, IDirect3DDevice *d3d_device) > { > + IDirectDrawSurface *surface; > + IDirect3DDevice2 *d3d_device2; > + DDSURFACEDESC desc; > + HRESULT hr; > + > device->d3drm = d3drm; > IDirect3DRM_AddRef(d3drm); > device->device = d3d_device; > IDirect3DDevice_AddRef(d3d_device); > > + /* Fetch render target and get width/height from there */ > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirectDrawSurface, (void **)&surface))) > + { > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirect3DDevice2, (void **)&d3d_device2))) > + return hr; > + hr = IDirect3DDevice2_GetRenderTarget(d3d_device2, &surface); > + IDirect3DDevice2_Release(d3d_device2); > + if (FAILED(hr)) > + return hr; > + } > + > + desc.dwSize = sizeof(desc); > + if (FAILED(hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc))) > + { > + IDirectDrawSurface_Release(surface); > + return hr; > + } > + > + device->width = desc.dwWidth; > + device->height = desc.dwHeight; > + IDirectDrawSurface_Release(surface); > + > return IDirect3D_QueryInterface(d3d, &IID_IDirectDraw, (void **)&device->ddraw); > } > This leaks some references (IDirect3DRM, IDirect3DDevice) on error paths, are those on purpose?

2 5

Re: [PATCH 4/5] inetcomm: Support LPSTR to LPWSTR conversion in GetProp
by Nikolay Sivov 30 Jun '16

30 Jun '16

Is it possible to use PropVariantChangeType() for such conversion?

1 0

Re: [PATCH 1/5] inetcomm: Implement IMimeBody DeleteProp
by Nikolay Sivov 30 Jun '16

30 Jun '16

On 06/30/2016 11:58 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/inetcomm/mimeole.c | 23 +++++++++++++++++-- > dlls/inetcomm/tests/mimeole.c | 53 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 74 insertions(+), 2 deletions(-) > > diff --git a/dlls/inetcomm/mimeole.c b/dlls/inetcomm/mimeole.c > index 766503d..cff95a1 100644 > --- a/dlls/inetcomm/mimeole.c > +++ b/dlls/inetcomm/mimeole.c > @@ -898,8 +898,27 @@ static HRESULT WINAPI MimeBody_DeleteProp( > LPCSTR pszName) > { > MimeBody *This = impl_from_IMimeBody(iface); > - FIXME("(%p)->(%s) stub\n", This, debugstr_a(pszName)); > - return E_NOTIMPL; > + header_t *cursor, *cursor2; > + BOOL found = FALSE; You don't need to initialize 'found'. > + > + TRACE("(%p)->(%s) stub\n", This, debugstr_a(pszName)); 'stub' should be removed, unless it's still too stubby. > + > + LIST_FOR_EACH_ENTRY_SAFE(cursor, cursor2, &This->headers, header_t, entry) > + { > + if(ISPIDSTR(pszName)) > + found = STRTOPID(pszName) == cursor->prop->id; > + else > + found = !lstrcmpiA(pszName, cursor->prop->name); > + > + if(found) > + { > + list_remove(&cursor->entry); > + HeapFree(GetProcessHeap(), 0, cursor); > + return S_OK; > + } > + } > + > + return MIME_E_NOT_FOUND; > } The way you use it, there's no need for _SAFE() list iteration. > static HRESULT WINAPI MimeBody_CopyProps( > diff --git a/dlls/inetcomm/tests/mimeole.c b/dlls/inetcomm/tests/mimeole.c > index 8063b86..46fd1d5 100644 > --- a/dlls/inetcomm/tests/mimeole.c > +++ b/dlls/inetcomm/tests/mimeole.c > @@ -604,6 +604,58 @@ static void test_BindToObject(void) > IMimeMessage_Release(msg); > } > > +static void test_BodyDeleteProp(void) > +{ > + static const char topic[] = "wine topic"; > + HRESULT hr; > + IMimeMessage *msg; > + IMimeBody *body; > + PROPVARIANT prop; > + > + hr = MimeOleCreateMessage(NULL, &msg); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + PropVariantInit(&prop); > + > + hr = IMimeMessage_BindToObject(msg, HBODY_ROOT, &IID_IMimeBody, (void**)&body); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, "Subject", 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, "Subject", 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + IMimeBody_Release(body); > + IMimeMessage_Release(msg); > +} > + > static void test_MimeOleGetPropertySchema(void) > { > HRESULT hr; > @@ -627,6 +679,7 @@ START_TEST(mimeole) > test_MessageGetPropInfo(); > test_MessageOptions(); > test_BindToObject(); > + test_BodyDeleteProp(); > test_MimeOleGetPropertySchema(); > OleUninitialize(); > }

1 0

Re: [v2 1/3] dinput: Print location ID in debugstr_device on the Mac
by Dmitry Timoshkov 30 Jun '16

30 Jun '16

David Lawrie <david.dljunk(a)gmail.com> wrote: > +static Boolean get_device_property_long(IOHIDDeviceRef in_device, CFStringRef in_key, long * out_value) > +{ > + Boolean result = FALSE; > + CFTypeRef type; > + > + if (in_device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(in_device)); > + > + type = IOHIDDeviceGetProperty(in_device, in_key); > + > + if (type) > + { > + if (CFNumberGetTypeID() == CFGetTypeID(type)) > + result = CFNumberGetValue((CFNumberRef)type, kCFNumberLongType, out_value); > + } > + } > + return result; > +} > + > +long get_device_location_ID(IOHIDDeviceRef device) > +{ > + long result = 0; > + get_device_property_long(device, CFSTR(kIOHIDLocationIDKey), &result); > + return result; > +} The helper should be 'static'. Also, probably you should return value from the helper directly since you don't check for the boolean result anyway. Same comment applies for a similar winejoystick.drv patch. -- Dmitry.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP (v2).
by Marvin 29 Jun '16

29 Jun '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=23888 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH] d3dx9: Avoid overflowing debug channel buffer when tracing ASCII effect errors.
by Alistair Leslie-Hughes 29 Jun '16

29 Jun '16

Hi Matteo, On 29/06/16 03:06, Matteo Bruni wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > Inspired by a patch by Alistair Leslie-Hughes. > > dlls/d3dx9_36/effect.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(53,7): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(55,9): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "StaticMesh.fx(484,39): warning X3206: implicit truncation of vector type" Hers is the output from your patch. The first too lines are warnings are split across trace statement. Should we use a larger number to attempt to have each error/warning on one line. Best Regards Alistair Leslie-Hughes

2 1

Re: [v1 2/2] dinput/joystick_osx.c: sorts devices by location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for dinput joysticks > > Note: if multiple virtual joysticks have the same location ID, they will > still be unordered > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) Similar comments as for the corresponding winejoystick.drv patch, of which this is a subset. -Ken

2 1

Re: [v1 2/2] winejoystick.drv/joystick_osx.c: sorts devices by location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for winmm joysticks This should probably be a note and go below the "---" line, below. Also, please adjust the subjects of these patches. Take a look at how Alexandre changed the subjects of your previous commits. Try to save him the effort. The prefix should generally be just the DLL name without the name of the specific file (although changes to tests can have "/tests"). The first word after the colon should be capitalized. The verb should be in the imperative mood ("Sort" vs. "Sorts"). If you want to include the information that this patch is for the Mac which is lost by removing the file name, add that to the subject (e.g. "Sort devices by location ID on the Mac"). > @@ -321,6 +321,34 @@ static CFIndex find_top_level(IOHIDDeviceRef hid_device, CFMutableArrayRef main_ > /************************************************************************** > * find_osx_devices > */ You've separated the function header comment above from the function it goes with. > + > +/* > + * Helper to sort array by location ID since they are consistent across boots & launches > + */ Use the function header comment format used elsewhere in the file. > +static CFComparisonResult CFDeviceArrayComparatorFunction(const void *val1, const void *val2, void *context) As with the previous patches, don't start your function names with "CF" which is for Core Foundation functions. There's no reason to include "Function" in the name of a function. Use lowercase-and-underscores. Also, it should mention what it's comparing by or for. For example, "device_location_comparator" similar to button_usage_comparator() elsewhere in this file. > +{ > +#pragma unused(context) Don't bother with that. > + CFComparisonResult result = kCFCompareEqualTo; > + > + long loc1 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val1); > + long loc2 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val2); There's no need to cast void pointers to other pointer types. > + if (loc1 < loc2) { > + result = kCFCompareLessThan; > + } else if (loc1 > loc2) { > + result = kCFCompareGreaterThan; > + } If you're going to use braces around these blocks (which isn't necessary), put the braces on separate lines. > +/* > + * Helper to copy the CFSet to a CFArray > + */ > +static void CFSetApplierFunctionCopyToCFArray(const void *value, void *context) I know this name was copied from dinput, but it's still terrible. ;) > +{ > + CFArrayAppendValue((CFMutableArrayRef)context, value); Unneeded cast. > @@ -363,20 +391,16 @@ static int find_osx_devices(void) > if (devset) > { > CFIndex num_devices, num_main_elements; > - const void** refs; > - CFArrayRef devices; > + CFMutableArrayRef devices; > > num_devices = CFSetGetCount(devset); > - refs = HeapAlloc(GetProcessHeap(), 0, num_devices * sizeof(*refs)); > - if (!refs) > - { > - CFRelease(devset); > - goto fail; > - } > > - CFSetGetValues(devset, refs); > - devices = CFArrayCreate(NULL, refs, num_devices, &kCFTypeArrayCallBacks); > - HeapFree(GetProcessHeap(), 0, refs); > + devices = CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); As a minor optimization, you can specify a capacity to the above call. > + /* copy devices from (unordered) set to array */ > + CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, (void *)devices); Unneeded cast. > + /* now sort the array by location ID's */ Again, these comments don't add much and better names for the functions would make the code more self-explanatory. It might be worthwhile to put a comment here or in the function header about _why_ you're sorting by location ID (i.e. to provide a stable order across runs). That's a good general rule: comments shouldn't narrate what the code is doing, they should explain why it's doing it, or why it's doing it in a particular way, if that's non-obvious. > + CFArraySortValues(devices, CFRangeMake(0, num_devices), CFDeviceArrayComparatorFunction, NULL); > + -Ken

1 0

Re: [v1 1/2] winejoystick.drv/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 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 | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) Same issues as the corresponding dinput patch. -Ken

1 0

Re: [v1 1/2] dinput/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static Boolean IOHIDDevice_GetLongProperty(IOHIDDeviceRef inIOHIDDeviceRef, CFStringRef inKey, long * outValue) Don't name your functions as though they were Apple's. Apple "owns" the namespace of identifiers starting with "IOHIDDevice". In general, just use simple lowercase-and-underscores names unless there's a strong reason not to. Something like "get_device_property_long". Same goes for the parameters: "key" and "out_value" or the like. > +{ > + Boolean result = FALSE; > + CFTypeRef tCFTypeRef; Don't use this naming convention either (is that Hungarian notation?). Why is the type repeated in the variable name? What does the "t" prefix signify. Just call this "value" or something. > + > + if (inIOHIDDeviceRef) { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(inIOHIDDeviceRef)); > + > + tCFTypeRef = IOHIDDeviceGetProperty(inIOHIDDeviceRef, inKey); > + > + if ( tCFTypeRef ) { > + /* if this is a number */ > + if (CFNumberGetTypeID() == CFGetTypeID(tCFTypeRef)) { > + /* get it's value */ What do these comments add? > + result = CFNumberGetValue((CFNumberRef)tCFTypeRef, kCFNumberSInt32Type, outValue); "long" and "SInt32" don't match reliably. Why not kCFNumberLongType? > +long IOHIDDevice_GetLocationID(IOHIDDeviceRef inIOHIDDeviceRef) Naming conventions here, too. > +{ > + long result = 0; > + (void)IOHIDDevice_GetLongProperty(inIOHIDDeviceRef, CFSTR(kIOHIDLocationIDKey), &result); I don't think we generally use the cast-to-void thing for unused return values in Wine. -Ken

1 0

Re: shell32/tests: Avoid casts from a COM object to an iface.
by Marvin 29 Jun '16

29 Jun '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=23879 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

2 1

Re: [PATCH] winex11: fix destroying of top-level windows
by Alexandre Julliard 28 Jun '16

28 Jun '16

Miklós Máté <mtmkls(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=40767 > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/winex11.drv/opengl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index d89a193..27ddd79 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -1314,6 +1314,9 @@ static void free_gl_drawable( struct gl_drawable *gl ) > { > switch (gl->type) > { > + case DC_GL_WINDOW: > + pglXDestroyWindow( gdi_display, gl->drawable ); > + break; Actually this one has some issues too: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2250: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:6312: Tests skipped: This GPU supports SM3, skipping unsupported shader test. device.c:6724: Tests skipped: D3DFMT_A32B32G32R32F supports filtering, skipping tests. device.c:7747: Tests skipped: Failed to create cube texture for format R8G8B8 (hr 0x8876086c), skipping tests. device.c:8450: Tests skipped: Dynamic D3DFMT_YUY2 textures not supported, skipping mipmap test. device.c:8450: Tests skipped: Dynamic D3DFMT_UYVY textures not supported, skipping mipmap test. X Error of failed request: GLXBadWindow Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 32 (X_GLXDestroyWindow) Serial number of failed request: 8900 Current serial number in output stream: 8901 Makefile:208: recipe for target 'device.ok' failed -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: d3dx10: Implement D3DX10CompileFromMemory.
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-27 21:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > + TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > + "sflags %#x, eflage %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", "eflage" typo. > diff --git a/dlls/d3dx10_43/d3dx10_43_main.c b/dlls/d3dx10_43/d3dx10_43_main.c > index 0c1ff80..fe56ee0 100644 > --- a/dlls/d3dx10_43/d3dx10_43_main.c > +++ b/dlls/d3dx10_43/d3dx10_43_main.c > @@ -37,6 +37,8 @@ > #include "d3dx10core.h" > #include "d3dx10tex.h" > > +#include "wine/debug.h" That is already included a few lines above. Looks good otherwise.

1 0

Re: [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-23 1:45 GMT+02:00 Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection > > This add missing fields to the d3dcompiler_shader_reflection based on > http://timjones.tw/blog/archive/2015/09/02/parsing-direct3d-shader-bytecode > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476590(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb694550(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb172432(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476209(v=vs.85).… Thank you for the links, that saved me some time to have to look them up. > + UINT sample_frequency_shader; As far as I understand, that would be better served by a BOOL. > UINT dcl_count; > + UINT def_count; Nitpick but def_count is right before dcl_count in both D3D11_SHADER_DESC and in the shader bytecode, it would be nice to have the same order everywhere. We have tests for this in d3dcompiler_43/tests/reflection.c. Can you please add some tests for those new fields too? Notice that you don't necessarily need n separate new tests for each of the n new features. The patch subject should be something like "d3dcompiler: Add d3d11 fields to struct d3dcompiler_shader_reflection." i.e. no square brackets for the dll prefix and put a colon after it. Also, while not strictly required, it's encouraged to use git send-email, it will inline the patch without wrapping and generally take care of most of the formatting details, assuming git is configured correctly.

1 0

Re: [v2 PATCH] d3dx9_36: Stop crash when displaying effect errors
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-22 13:10 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > if (temp_errors) > - TRACE("%s\n", (char *)ID3D10Blob_GetBufferPointer(temp_errors)); > + { > + const char *p = ID3D10Blob_GetBufferPointer(temp_errors); > + SIZE_T size = ID3D10Blob_GetBufferSize(temp_errors); > + const char *end = p + size; > + const char *line = p; > + > + while (p != end) > + { > + if (*p == '\n') > + { > + UINT len = p - line; > + if (len && *(p - 1) == '\r') --len; > + TRACE("%s\n", debugstr_an(line, len)); > + line = ++p; > + } > + else ++p; > + } > + if (line != p) > + TRACE("%s\n", debugstr_an(line, p - line)); > + } This only breaks at '\n', which might still be too much if the lines are particularly long. I also wrote a patch for this a few days ago. I'm going to send it to wine-patches in a bit, I'd appreciate if you can test if it works for you or point out any issue with it.

1 0

Re: include: Add missing interface declaration.
by Nikolay Sivov 28 Jun '16

28 Jun '16

> interface IWbemContext; > interface IWbemServices; > +interface IWbemLocator; > interface IWbemStatusCodeText; > interface IWbemCallResult; > interface IWbemObjectSink; Why do you need this? IWbemLocator is fully defined later in this file.

1 0

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init.
by Stefan Dösinger 27 Jun '16

27 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-24 um 22:49 schrieb Aaryaman Vasishta: > + 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); > + > + return d3drm_viewport2_Init(&viewport->IDirect3DRMViewport2_iface, device3, camera3, x, y, width, height); This has the same problem as the first version of your frame thunks: You get "device3", but then you release "device", to which you don't hold a reference. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcFfoAAoJEN0/YqbEcdMweH8P/RBg+lEvXxGES0C1Uo5aN6Ht E0TOftji/AaGrVcaoHLWMsl30/GUpmh+iRdM19ZHwL0vey3yKKdTmFlt4tMrG5aP LLHLlxRqcJt1h+MREvMYb7JJjCAMcR/2Bn63nxWZpZ+PncQo1H90ZsBHCrd4Y707 JukrA3QfPm9cyXiX/ER8cj7QgpnNsk5y8ZXgbdtDDGOzShf2OSoslU5ivQQsmZ4W 2fiJWOeWdpi3P9Fh6EUTDOwUf5Rnj7mBYb3KFASc9o0VZXHuI/f35LGG9AdNkSxs lf6RbPDcXxPQqUxlz0VnmS/31/oGb0pDczESx+alDU9n29tWPANY+yBGUmDStyJ0 /RHl2qpZJMs/lQpk9UQ/RpvuVdZfLVxgftqyZuoWT4EfW5iseOlCytmsJEG1AVpd BKAMFRbueGhPYfUcuLAH1GL4keRg7P3QUd36MlR0wWVdYGtMWrbQL+6SrHT6r75C QmXU9mTJMTleA/Yzskenm71Tz9/wbwavYjUMaEQp3+7OKrG0Zqnt4foh2GpNUT+6 M7jxfSSng4+irWvxf3ZKdpjfGNHRn1ZhRKrEpxKQptiGlFvYSMDy7tHtyybK2MbB h8CO19YAzcVjfFHj5sRSYtZIHdVm5aG5FJLfVm9UPBA7xT2l9b6EgqXEhLTVLYC6 /TSyEFgT5j+DkKf6DCm+ =0tcs -----END PGP SIGNATURE-----

2 3

OSSCOM 2016 Conference - Dec, 2016 (Call for Papers)
by 2nd International Conference on Open Source Software Computing (OSSCOM 2016) 27 Jun '16

27 Jun '16

OSSCOM 2016 Call for Proposals/ Papers OSSCOM 2016 The 2nd International Conference on Open Source Software Computing 1st - 3rd December 2016 Lebanese University, Beirut - Lebanon http://mailer.tagorg.com/lists/lt.php?id=bB0DBlQZUAJSTlQNAFIEAA Partially funded by EC - Tempus and technically sponsored by IEEE Objectives To promote opportunities for cooperation towards enabling OSS key technologies, building cross-cutting sciences, and driving disruptive innovations; to disseminate research on technology and applications of open source software computing; and to expand the framework of effective participation of universities in developing OSS industry through incubators and business accelerators. Structure - Keynotes - Panel and roundtable discussions - Presentation sessions - Industry and technology discussions - Consultation meetings, focus groups, and roundtables - Best practice showcases and practical demonstration - Workshops Submission Deadline 1st September, 2016 (Manuscripts) 1st October, 2016 (Proposals) Topics of Interest Track 1: Systems Software - Operating systems: Linux Kernel, Server and Desktop Linux: RedHat, Debian, Slackware, Caldera, SuSe, Fedora - Distributed Operating systems: Open source platforms and software for the cloud platform as a service (PaaS), software as a service (SaaS), and infrastructure as a service (IaaS). Open stack, Open-source software in scientific computing including clouds, grids and HPCs - Embedded and Realtime Operating systems - Ubiquitous mobile computing and technologies: middleware, operating system (e.g. Android), new I/O and user interfaces, mobile protocols Track 2: Applications and Services - Open-source software services and applications in energy, environment, education, health, climate, water, agriculture, biology, economy, medicine and other pressing global issues and problems - Open-source software for e-Services, including e-Government, e-Libraries, e-Learning and any e-* - Open-source software for Smart Education, Smart Cities, Smart Power Grids, Smart Transportation - Open Source applications for mobile and tablets Track 3: Networking and Security - Open source network simulation/emulations tools - Open source platforms for network security deployment, testing and verification - Network and security open source management software Track 4: Open Source Development and Support - Perspectives on open-source software development and services, including challenges, operation, sustainability, funding, governance, business models, and security - National, regional and international organizations and their role in funding and supporting open-source software applications in research and education - Collaborative projects and initiatives in research and education at national, regional and global levels - Research and education challenges and open access paradigm - Business models for open-source software development and services Track 5: Software Engineering This track will bring together researchers, students and industry experts from diverse areas associated with software engineering who are utilizing, developing or even improving open source software systems during their research and experiments. Software Engineering influences all aspects of computer science research and touches every software researchers and practitioners. There are diverse Free and open-source software that could be utilized in many fields under the umbrella of Software Engineering such as but not limited to: - Software Process Models - Software Process Improvement - Software Architecture - Component-Based Software Engineering - Software Verification and Validation - Model Checking - Software Impact Analysis - Design Patterns and Frameworks - Model Driven Architecture - Modeling with UML - Reusable Software and Metrics - Reverse Engineering, Re-engineering - Adaptive Software - Software Define Network - Data Mining and Machine Learning - Safety and Security in Critical Software Conference Venue Lebanese University, Beirut - Lebanon Submit a Participation <http://mailer.tagorg.com/lists/lt.php?id=bB0DB1EZUAJSTlQNAFIEAA> Language English Registration Fees OSSCOM members 50 Euro OSSCOM non-members 100 Euro Authors and Speakers 50 Euro Students Free All papers will be peer-reviewed and selected papers will be published in the conference proceedings and submitted to IEEE Explore. Partners and Organisers - Hochschule Bonn-Rhein-Sieg University of Applied Sciences, Germany - German Jordanian University, Jordan - Lebanese University, Lebanon - Brunel University, United Kingdom - Yarmouk University, Jordan - Notre Dame University, Lebanon - University of Castilla-La Mancha, Spain - Tarent AG, Germany - Talal Abu-Ghazaleh Information Technology International, Jordan - Information Management Ltd, Lebanon - Le Cnam Liban Important Dates 1st Sept, 2016 Manuscript Submission Deadline 1st Oct, 2016 Acceptance Notification 15th Nov 2016 Registration Deadline 1st – 3rd Dec 2016 OSSCOM 2016 Conference For more information and paper submission, please contact Paper Submission: - Please submit your manuscript or proposal at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBVQZUAJSTlQNAFIEAA Registration: - Please register for OSSCOM 2016 conference at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBlYZUAJSTlQNAFIEAA Publicity: - Dr. Yaser Jararweh, yijararweh(a)just.edu.jo <mailto:yijararweh@just.edu.jo> - Dr. Muhannad Quwaider, mqquwaider(a)just.edu.jo <mailto:mqquwaider@just.edu.jo> More Information: - Please contact us through our email: office(a)osscom.org <mailto:office@osscom.org> All information is available at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBlcZUAJSTlQNAFIEAA -- This message was sent to wine-devel(a)winehq.org by Office(a)osscom.org To forward this message, please do not use the forward button of your email application, because this message was made specifically for you only. Instead use the forward page <http://mailer.tagorg.com/lists/lt.php?id=bB0DBVcZUAJSTlQNAFIEAA> in our newsletter system. To change your details and to choose which lists to be subscribed to, visit your personal preferences page <http://mailer.tagorg.com/lists/lt.php?id=bB0DS1dUUE9WClYGBlc> Or you can opt-out completely <http://mailer.tagorg.com/lists/lt.php?id=bB0CS1dUUE9WClYGBlc> from all future mailings. -- powered by phpList, www.phplist.com --

1 0

Host_Quit implementation in wscript
by Thiago Barbato 27 Jun '16

27 Jun '16

I tried running a .js with a WScript.Quit() call and noticed it isn't implemented yet in programs/wscript/host.c. Would a simple ExitProcess( ExitCode ) do the job or are there cases where this would be the wrong thing to do?

2 1

Re: [PATCH 4/4] rpcrt4: Added RpcServerRegisterAuthInfoW failure test.
by Marvin 27 Jun '16

27 Jun '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=23875 Your paranoid android. === w864 (32 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {6eb1cf99-3c79-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {f4f8b15d-3c7a-11e6-be78-e71666c2e04a}

1 0

Re: wordpad: Avoid buffer overrun in registry_set_filelist.
by Huw Davies 27 Jun '16

27 Jun '16

On Sun, Jun 26, 2016 at 11:42:31AM +0200, Thomas Faber wrote: > From e80a75cfe223a82eea4c55874975e54de4981282 Mon Sep 17 00:00:00 2001 > From: Thomas Faber <thomas.faber(a)reactos.org> > Date: Sun, 26 Jun 2016 10:59:08 +0200 > Subject: wordpad: Avoid buffer overrun in registry_set_filelist. > > Signed-off-by: Thomas Faber <thomas.faber(a)reactos.org> > --- > programs/wordpad/registry.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/wordpad/registry.c b/programs/wordpad/registry.c > index bf2af5b..e047f37 100644 > --- a/programs/wordpad/registry.c > +++ b/programs/wordpad/registry.c > @@ -298,7 +298,7 @@ void registry_set_filelist(LPCWSTR newFile, HWND hMainWnd) > if(!lstrcmpiW(pFiles[i], newFile)) > { > int j; > - for(j = 0; pFiles[j] && j < i; j++) > + for(j = 0; j < i && pFiles[j]; j++) > { > pFiles[i-j] = pFiles[i-j-1]; > } This looks odd to me. I don't see how this could avoid an overflow; pFiles[i] is valid at this point and so pFiles[j] will be ok if j == i. More confusingly though, is why pFiles[j] is in the test at all. Huw.

2 1

Re: d3d9/tests: Use SetRect() instead of open coding it.
by Marvin 27 Jun '16

27 Jun '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=23872 Your paranoid android. === w1064 (64 bit device) === device.c:4348: Test failed: cw is 0xf60, expected 0x7f. device.c:4357: Test failed: Callback cw is 0xf60, expected 0x7f.

2 1

Re: [PATCH 7/7] d3drm: Implement IDirect3DRM*::CreateViewport.
by Stefan Dösinger 27 Jun '16

27 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-24 um 22:49 schrieb Aaryaman Vasishta: > + hr = IDirect3DRM3_CreateViewport(d3drm3, device3, frame3, rc.left, rc.top, rc.right, rc.bottom + 1, &viewport2); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + if (FAILED(hr)) > + { > + hr = IDirect3DRM3_CreateViewport(d3drm3, device3, frame3, rc.left, rc.top, rc.right, rc.bottom, NULL); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + } Afaics the if (FAILED(hr)) isn't necessary here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcFm2AAoJEN0/YqbEcdMwbewP/11c9oFcbQjek33cW30miUka fO/BIk3qk6xpsz/CMF/DRmwQvqPObSnG5zsAXn4j1hsJM2y3EBRjLeZx1/CqyR9s uQ9JyN85zB2rEDkSpLFNaOIW0hnX7bFFnOmZlIlZPYRH1cqQSJcg5gcAq8EnLeIl ioWW0qK3ZREeRDZXEe0YxuwGqWE+HouUNzS/En9OrlZ9b76zfuRcH2rrGSw+2BPo Az8PzllV8v3Df/HxqYyeG9JxgjWElk2aQGfHP5BPUE/JF5+Ky2xEb6RvHVGJQ64P G/HKJGlKZT/VgQGCbJx6s5bNazBiJSyD4a6dj5IbEbWmnySJIbwW2DNXrcxKT9MO oz0NNyjMQAVkJx45QVvtxm+5QsJIbO6V/38h+zsPW0F6dGrYoqBXXSFbsbp4ge2G S2EC+bJVHsUwc2en52BaqJCRDYLSgxNaD2kL8ovZjLYBVi3jlfTP/OcIXYjam2I7 67b8VEeV7xBILU2uvhFxwpwLIgtVJ1b2QUyH3TjrKfClGu5lbe/VbASsrDjBaJV1 ZZMqcmn1JU/P24wQVWb2gfqN12ktvhEnnYznwz8zw7OKdpOUoKlOXr/06tlrMmei YfuGMZmJyxMJQSsfIVtoFH1HmqlZuk5QUjnjyShYDDf4TlKWZAtn4o4JJbt4n1J0 bOobnKLPsEGKSNhoZbnm =xbZw -----END PGP SIGNATURE-----

2 1

Vacation
by Alexandre Julliard 25 Jun '16

25 Jun '16

Folks, I'll be out on vacation next week, so there won't be any commits. Feel free to keep sending patches, I'll try to catch up when I get back, and make the next release on schedule two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] comdlg32: Optimize FILEDLG95_FILENAME_FillFromSelection.
by Henri Verbeet 25 Jun '16

25 Jun '16

On 23 June 2016 at 13:29, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > This trades some memory for speed, but since currently selecting > 1000 files takes over a minute but the required memory for those > 1000 filenames is only 262 kB (worst case), this seems a reasonable > trade-off. > That's probably fine, but is there any reason this can't use the standard approach of just doubling the buffer size when you run out of space? If this is performance critical code, the multiple copies of the string related to GetName() probably don't help either.

2 1

Re: [PATCH 7/9] d3d11: Implement ID3D11UnorderedAccessView interface.
by Henri Verbeet 24 Jun '16

24 Jun '16

On 24 June 2016 at 11:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + switch (desc->ViewDimension) > + { > + case D3D11_UAV_DIMENSION_TEXTURE1DARRAY: > + if (desc->u.Texture1DArray.ArraySize == -1 && desc->u.Texture1DArray.FirstArraySlice < layer_count) I noticed too late for the other normalisation functions, but "ArraySize" is unsigned.

2 2

Re: [PATCH 3/9] d3d11: Implement d3d11_immediate_context_OMGetBlendState().
by Henri Verbeet 24 Jun '16

24 Jun '16

On 24 June 2016 at 11:45, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -4044,16 +4053,17 @@ static void STDMETHODCALLTYPE d3d10_device_OMGetBlendState(ID3D10Device1 *iface, > ID3D10BlendState **blend_state, FLOAT blend_factor[4], UINT *sample_mask) > { > struct d3d_device *device = impl_from_ID3D10Device(iface); > + ID3D11BlendState *d3d11_blend_state; > + struct d3d_blend_state *object; > > TRACE("iface %p, blend_state %p, blend_factor %p, sample_mask %p.\n", > iface, blend_state, blend_factor, sample_mask); > > - if ((*blend_state = device->blend_state ? (ID3D10BlendState *)&device->blend_state->ID3D10BlendState1_iface : NULL)) > - ID3D10BlendState_AddRef(*blend_state); > - wined3d_mutex_lock(); > - memcpy(blend_factor, device->blend_factor, 4 * sizeof(*blend_factor)); > - *sample_mask = wined3d_device_get_render_state(device->wined3d_device, WINED3D_RS_MULTISAMPLEMASK); > - wined3d_mutex_unlock(); > + d3d11_immediate_context_OMGetBlendState(&device->immediate_context.ID3D11DeviceContext_iface, > + &d3d11_blend_state, blend_factor, sample_mask); > + > + object = unsafe_impl_from_ID3D11BlendState(d3d11_blend_state); Why not just impl_from_ID3D11BlendState() here?

2 4

Re: Andrey Gusev : msvcp120/tests: Fix a typo in ok() message.
by Ken Thomases 23 Jun '16

23 Jun '16

On Jun 23, 2016, at 11:15 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > diff --git a/dlls/msvcp120/tests/msvcp120.c b/dlls/msvcp120/tests/msvcp120.c > index 7c94906..354b2d3 100644 > --- a/dlls/msvcp120/tests/msvcp120.c > +++ b/dlls/msvcp120/tests/msvcp120.c > @@ -592,7 +592,7 @@ static void test_xtime_get(void) > diff = p__Xtime_diff_to_millis2(&after, &before); > > ok(diff >= tests[i], > - "xtime_get() not functioning correctly, test: %d, expect: ge %d, got: %d\n", > + "xtime_get() not functioning correctly, test: %d, expect: %d, got: %d\n", > i, tests[i], diff); > } Too late on this one, but I think the "ge" was supposed to mean "greater than or equal to", given the actual test being performed. Probably best to replace it with ">=". -Ken

1 0

Re: kernel32/tests: Fix a typo in skip() message.
by Marvin 23 Jun '16

23 Jun '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=23833 Your paranoid android. === w1064 (32 bit locale) === locale.c:2370: Test failed: LCMapStringEx should fail with bad locale name locale.c:2371: Test failed: unexpected error code -559038737 locale.c:2462: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4192: Test failed: IsValidLocaleName should have failed locale.c:4194: Test failed: IsValidLocaleName should have failed locale.c:4577: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4579: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2370: Test failed: LCMapStringEx should fail with bad locale name locale.c:2371: Test failed: unexpected error code -559038737 locale.c:2462: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4192: Test failed: IsValidLocaleName should have failed locale.c:4194: Test failed: IsValidLocaleName should have failed locale.c:4577: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4579: Test failed: For id 7, Expected IVC, got ''

1 0

Re: mshtml/tests: Fix a typo in ok() message.
by Michael Stefaniuc 23 Jun '16

23 Jun '16

On 06/23/2016 11:56 AM, Andrey Gusev wrote: > > mshtml-tests-Fix-a-typo-in-ok-message.txt > > > From d30dec56bc2f7f716ab786516ee6080c9cdea67f Mon Sep 17 00:00:00 2001 > Message-Id: <d30dec56bc2f7f716ab786516ee6080c9cdea67f.1466675739.git.andrey.goosev(a)gmail.com> > From: Andrey Gusev <andrey.goosev(a)gmail.com> > Date: Thu, 23 Jun 2016 12:55:21 +0300 > Subject: [PATCH] mshtml/tests: Fix a typo in ok() message. > > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > --- > dlls/mshtml/tests/dom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c > index dce65d5..5c4261e 100644 > --- a/dlls/mshtml/tests/dom.c > +++ b/dlls/mshtml/tests/dom.c > @@ -7497,7 +7497,7 @@ static void test_table_elem(IHTMLElement *elem) > VariantClear(&v); > hres = IHTMLTable_get_width(table, &v); > ok(hres == S_OK, "get_width = %08x\n", hres); > - ok(!strcmp_wa(V_BSTR(&v), "40.2%"), "Expected 40.2%%, got %s\n", wine_dbgstr_w(V_BSTR(&v))); > + ok(!strcmp_wa(V_BSTR(&v), "40.2%"), "Expected 40.2%, got %s\n", wine_dbgstr_w(V_BSTR(&v))); That is not a typo, one of this commands would have told you that: - man 3 printf - make bye michael

1 0

Re: mshtml/tests: Allow ParseUrl to clear buffer on Win10
by Marvin 22 Jun '16

22 Jun '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=23818 Your paranoid android. === w1064 (32 bit protocol) === protocol.c:723: Test failed: buf changed === w1064 (64 bit protocol) === protocol.c:723: Test failed: buf changed

1 0

Re: [2/2] advapi32/tests: Allow Win8+ flags for Admins ACE
by Marvin 22 Jun '16

22 Jun '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=23817 Your paranoid android. === w1064 (32 bit security) === security.c:4011: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4015: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4024: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4011: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4015: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4024: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: [1/2] advapi32/tests: Allow MACHINE\Software to be owned by local system
by Marvin 22 Jun '16

22 Jun '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=23816 Your paranoid android. === w864 (32 bit security) === security.c:4024: Test failed: Builtin Admins ACE has unexpected flags (0xa != 0x0) === w1064 (32 bit security) === security.c:4011: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4015: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4024: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4011: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4015: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4024: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: kernel32/tests: Fix a typo
by Marvin 22 Jun '16

22 Jun '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=23815 Your paranoid android. === w1064 (32 bit locale) === locale.c:2370: Test failed: LCMapStringEx should fail with bad locale name locale.c:2371: Test failed: unexpected error code -559038737 locale.c:2462: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4192: Test failed: IsValidLocaleName should have failed locale.c:4194: Test failed: IsValidLocaleName should have failed locale.c:4577: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4579: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2370: Test failed: LCMapStringEx should fail with bad locale name locale.c:2371: Test failed: unexpected error code -559038737 locale.c:2462: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4192: Test failed: IsValidLocaleName should have failed locale.c:4194: Test failed: IsValidLocaleName should have failed locale.c:4577: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4579: Test failed: For id 7, Expected IVC, got ''

1 0

Re: apphelp: add SdbGetAppPatchDir stub (try 2)
by Sebastian Lackner 22 Jun '16

22 Jun '16

On 22.06.2016 09:23, Austin English wrote: > Using WCHAR * > > Previous try dropped without comment. Fixes > https://bugs.winehq.org/show_bug.cgi?id=35892 > > -- -Austin GPG: 14FB D7EA A041 937B > > > 0001-apphelp-add-SdbGetAppPatchDir-stub.patch > > > From 12b43f471b437309d80bf8625cdc4d518a225c72 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Wed, 22 Jun 2016 02:17:19 -0500 > Subject: [PATCH] apphelp: add SdbGetAppPatchDir stub > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/apphelp/apphelp.c | 5 +++++ > dlls/apphelp/apphelp.spec | 2 +- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/dlls/apphelp/apphelp.c b/dlls/apphelp/apphelp.c > index 64dcd87..122642c 100644 > --- a/dlls/apphelp/apphelp.c > +++ b/dlls/apphelp/apphelp.c > @@ -111,3 +111,8 @@ void WINAPI SdbCloseDatabase(PDB pdb) > { > FIXME("stub: %p\n", pdb); > } > + > +void WINAPI SdbGetAppPatchDir(HSDB hsdb, WCHAR *path, DWORD size) > +{ > + FIXME("stub: %p %s %d\n", hsdb, debugstr_w(path), size); Path is an output buffer, it does not make sense to use debugstr_w here. Also, MSDN says "If the function fails, this parameter is set to the empty string ("").". It would probably make sense to implement that, too. > +} > diff --git a/dlls/apphelp/apphelp.spec b/dlls/apphelp/apphelp.spec > index a658e5c..0119a48 100644 > --- a/dlls/apphelp/apphelp.spec > +++ b/dlls/apphelp/apphelp.spec > @@ -49,7 +49,7 @@ > @ stub SdbFreeFileInfo > @ stub SdbFreeFlagInfo > @ stub SdbGetAppCompatDataSize > -@ stub SdbGetAppPatchDir > +@ stdcall SdbGetAppPatchDir(ptr wstr long) HSDB is a handle, so "long" is more appropriate. > @ stub SdbGetBinaryTagData > @ stub SdbGetDatabaseID > @ stub SdbGetDatabaseInformation > -- 2.8.1 > > >

1 0

Re: [PATCH 1/2] include: add wmium.h (try 2) (resend)
by Sebastian Lackner 22 Jun '16

22 Jun '16

On 22.06.2016 00:18, Austin English wrote: On the first sight, your patch still contains the same errors I pointed out in my earlier review: https://www.winehq.org/pipermail/wine-devel/2016-June/113414.html Is this really the latest version? Regards, Sebastian

1 0

Re: [v2 PATCH] inetcomm: Implement IMimeBody GetPropInfo
by Alexandre Julliard 22 Jun '16

22 Jun '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + memset(&info, 0, sizeof(info)); > + hr = IMimeBody_GetPropInfo(body, "Subject", &info); > + ok(hr == S_OK, "ret %08x\n", hr); > + if(hr == S_OK) > + { > + ok(info.dwMask == 0, "Invalid mask 0x%08x\n", info.dwFlags); > + ok(info.dwFlags == 0, "Invalid flags 0x%08x\n", info.dwFlags); > + ok(info.ietEncoding == 0, "Invalid encoding %d\n", info.ietEncoding); > + ok(info.dwPropId == 0, "Invalid propid %d\n", info.dwPropId); > + } > + > + memset(&info, 0, sizeof(info)); > + info.dwPropId = 1024; > + info.ietEncoding = 99; > + hr = IMimeBody_GetPropInfo(body, "Subject", &info); > + ok(hr == S_OK, "ret %08x\n", hr); > + if(hr == S_OK) > + { > + ok(info.dwMask == 0, "Invalid mask 0x%08x\n", info.dwFlags); > + ok(info.dwFlags == 0, "Invalid flags 0x%08x\n", info.dwFlags); > + ok(info.ietEncoding == 99, "Invalid encoding %d\n", info.ietEncoding); > + ok(info.dwPropId == 1024, "Invalid propid %d\n", info.dwPropId); > + } I still think it would be better to memset with a non-zero value so you can reliably see what has been set. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 4/7] msvcirt: Implement ostream::operator<< for floats
by Piotr Caban 22 Jun '16

22 Jun '16

On 06/22/16 11:53, Iván Matellanes wrote: > + str_length += _scprintf(sprintf_fmt, prec, d); /* number representation */ > + if (str_length > 24) { > + /* too long to output */ > + ostream_writepad(ostr, "", ""); Could you please add a test for it? Also a comment saying that this is expected behavior would be useful. > + float param_float[] = {1.0f, 0.0f, 4.25f, 3.999f, 12.0005f, 15.33582f, 15.0f, 15.22f, 21.123f, 0.1f, > + 13.14159f, 0.00013f, 0.000013f, 1.0f / 0.0f, -1.0f / 0.0f, 0.0f / 0.0f}; Please do something similar as in dlls/msvcrt/tests/misc.c to define INFINITY/NAN in tests. Thanks, Piotr

2 2

Re: user32/tests: Avoid using CopyRect().
by Marvin 22 Jun '16

22 Jun '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=23786 Your paranoid android. === w864 (64 bit win) === win.c:8733: Test failed: msg.message = 320

2 1

Re: [v2 1/7] msvcirt: Implement ostream::operator<< for characters
by Piotr Caban 22 Jun '16

22 Jun '16

On 06/22/16 11:53, Iván Matellanes wrote: > + enum { CHAR } type; It's better to avoid using enum values identical as Windows types. It will make it impossible to use CHAR type. Thanks, Piotr

1 0

Re: [v2 3/7] msvcirt: Implement ostream::operator<< for integers
by Piotr Caban 22 Jun '16

22 Jun '16

On 06/22/16 11:53, Iván Matellanes wrote: > int param_int[] = {0, 7, 10, 24 ,55, 1024, 1023, 65536, 2147483647, 2147483648, 4294967295, -20}; It causes compilation warning: ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:3023:5: warning: this decimal constant is unsigned only in ISO C90 int param_int[] = {0, 7, 10, 24 ,55, 1024, 1023, 65536, 2147483647, 2147483648, 4294967295, -20}; ^ ../../../../wine_src/dlls/msvcirt/tests/msvcirt.c:3023:5: warning: this decimal constant is unsigned only in ISO C90 Thanks, Piotr

1 0

Re: [PATCH 5/5] wined3d: Send query destruction through the command stream.
by Henri Verbeet 22 Jun '16

22 Jun '16

On 22 June 2016 at 10:39, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/palette.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > The subject should of course read "wined3d: Send palette destruction through the command stream."

1 0

Re: include: Add an inline version of CopyRect() too.
by Alexandre Julliard 21 Jun '16

21 Jun '16

Michael Stefaniuc <mstefani(a)redhat.de> writes: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > Around 95 use cases. > No, I do *not* want to do change RECT struct assignments to CopyRect(). Good, but how about changing CopyRect to assignments? ;-) -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcrt: Implement _wperror (v2)
by Piotr Caban 21 Jun '16

21 Jun '16

On 06/21/16 14:42, Hugh McMaster wrote: > + size = MSVCRT_wcstombs(NULL, str, 0) + 1; > + buffer = MSVCRT_malloc(size); > + if (!buffer) return; > + MSVCRT_wcstombs(buffer, str, size); Please handle MSVCRT_wcstombs failure. Thanks, Piotr

2 2

Re: [2/8] msvcirt: Implement ostream::operator<< for characters
by Piotr Caban 21 Jun '16

21 Jun '16

On 06/21/16 11:54, Iván Matellanes wrote: > @@ -2608,8 +2615,7 @@ ostream* __thiscall ostream_print_char(ostream *this, char c) > DEFINE_THISCALL_WRAPPER(ostream_print_unsigned_char, 8) > ostream* __thiscall ostream_print_unsigned_char(ostream *this, unsigned char c) > { > - FIXME("(%p %c) stub\n", this, c); > - return this; > + return ostream_print_char(this, (char) c); > } The cast here is not needed. > + pssb = (strstreambuf*) call_func1(p_strstreambuf_ctor, &ssb); > + ok(pssb == &ssb, "wrong return, expected %p got %p\n", &ssb, pssb); > + pos = (ostream*) call_func3(p_ostream_sb_ctor, &os, (streambuf*) &ssb, TRUE); As well as this ones. Such casts can potentially hide problems otherwise visible during 64-bit compilation. > + pos = (ostream*) call_func2(p_ostream_print_char, &os, (int) tests[i].param.c); break; The cast here is also not needed. Thanks, Piotr

1 0

Re: [7/8] msvcirt: Implement ostream::operator<< for streambuf
by Marvin 21 Jun '16

21 Jun '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=23764 Your paranoid android. === wxppro (32 bit msvcirt) === Found no trace of the test summary line or of a crash === w2003std (32 bit msvcirt) === Found no trace of the test summary line or of a crash

1 0

Re: [6/8] msvcirt: Implement ostream::operator<< for pointers
by Marvin 21 Jun '16

21 Jun '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=23763 Your paranoid android. === wxppro (32 bit msvcirt) === Found no trace of the test summary line or of a crash === w2003std (32 bit msvcirt) === Found no trace of the test summary line or of a crash

1 0

Re: [2/8] msvcirt: Implement ostream::operator<< for characters
by Piotr Caban 21 Jun '16

21 Jun '16

On 06/21/16 11:54, Iván Matellanes wrote: > + struct ostream_print_test { > + enum { CHAR } type; > + union { > + char c; > + } param; > + ios_io_state state; > + ios_flags flags; > + int precision; > + int fill; > + int width; > + const char *expected_text; > + ios_io_state expected_flags; > + } tests[] = { > + /* char */ > + {CHAR, {.c = 'a'}, IOSTATE_badbit, 0, 6, ' ', 0, "", IOSTATE_badbit|IOSTATE_failbit}, > + {CHAR, {.c = 'a'}, IOSTATE_eofbit, 0, 6, ' ', 0, "", IOSTATE_eofbit|IOSTATE_failbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, 0, 6, ' ', 0, "a", IOSTATE_goodbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, 0, 6, ' ', 4, " a", IOSTATE_goodbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, 0, 6, 'x', 3, "xxa", IOSTATE_goodbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, FLAGS_left, 6, ' ', 4, "a ", IOSTATE_goodbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, FLAGS_left|FLAGS_internal, 6, ' ', 4, " a", IOSTATE_goodbit}, > + {CHAR, {.c = 'a'}, IOSTATE_goodbit, FLAGS_internal|FLAGS_hex|FLAGS_showbase, 6, ' ', 4, " a", IOSTATE_goodbit}, > + {CHAR, {.c = '9'}, IOSTATE_goodbit, FLAGS_oct|FLAGS_showbase|FLAGS_uppercase, 6, 'i', 2, "i9", IOSTATE_goodbit}, > + {CHAR, {.c = '9'}, IOSTATE_goodbit, FLAGS_showpos|FLAGS_scientific, 0, 'i', 2, "i9", IOSTATE_goodbit}, > + {CHAR, {.c = 'e'}, IOSTATE_goodbit, FLAGS_left|FLAGS_right|FLAGS_uppercase, 0, '*', 8, "e*******", IOSTATE_goodbit} > + }; This is not portable (the {.c = 'a'} part). Thanks, Piotr

1 0

Re: [5/8] msvcirt: Implement ostream::operator<< for floats
by Marvin 21 Jun '16

21 Jun '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=23762 Your paranoid android. === wxppro (32 bit msvcirt) === Found no trace of the test summary line or of a crash === w2003std (32 bit msvcirt) === Found no trace of the test summary line or of a crash

1 0

Re: msvcrt: Implement _wperror
by Piotr Caban 21 Jun '16

21 Jun '16

On 06/21/16 10:09, Hugh McMaster wrote: > dlls/msvcrt/msvcrt.spec | 2 +- > 2 files changed, 36 insertions(+), 1 deletion(-) Please also update other msvc*/ucrtbase spec files as well. > /********************************************************************* > + * _wperror (MSVCRT.@) > + */ > +void CDECL MSVCRT__wperror(const MSVCRT_wchar_t* str) > +{ > + int err, size, len; > + static const WCHAR colon_spaceW[] = {':',' ',0}; > + static const WCHAR newlineW[] = {'\n',0}; > + MSVCRT_wchar_t *buffer = NULL; > + > + err = *MSVCRT__errno(); > + if (err < 0 || err > MSVCRT__sys_nerr) err = MSVCRT__sys_nerr; > + > + size = MultiByteToWideChar(CP_ACP, 0, MSVCRT__sys_errlist[err], -1, NULL, 0) + 1 /* add \n */; > + > + if (str && *str) > + size += lstrlenW(str) + 2; /* add str length, colon and space */ > + > + buffer = MSVCRT_malloc(size * sizeof(MSVCRT_wchar_t)); > + if (!buffer) return; > + > + if (str && *str) > + { > + lstrcpyW(buffer, str); > + lstrcatW(buffer, colon_spaceW); > + } > + else buffer[0] = 0; > + > + len = lstrlenW(buffer); > + MultiByteToWideChar(CP_ACP, 0, MSVCRT__sys_errlist[err], -1, buffer + len, size - len); > + lstrcatW(buffer, newlineW); > + MSVCRT__write(2, buffer, lstrlenW(buffer) * sizeof(MSVCRT_wchar_t)); > + MSVCRT_free(buffer); > +} This is not how the function works. It shouldn't print wchar_t string to stderr. Probably the simplest implementation is to convert input parameter and call _perror (CP_ACP is not the correct encoding, you can use MSVCRT_wcstombs). Thanks, Piotr

2 3

Re: Fix overflow when left-shifting
by Dmitry Timoshkov 21 Jun '16

21 Jun '16

Jarkko Korpi <jarkko_korpi(a)hotmail.com> wrote: > Subject: [PATCH] widi: Fix overflow when left-shifting The tool name is 'widl'. -- Dmitry.

1 0

Re: [PATCH v2] jscript: Properly handle arguments in Object constructor.
by Marvin 20 Jun '16

20 Jun '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=23756 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: jscript: Properly handle arguments in Object constructor.
by Marvin 20 Jun '16

20 Jun '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=23747 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 1/2] winex11: fix gl drawable type
by Alexandre Julliard 20 Jun '16

20 Jun '16

Miklós Máté <mtmkls(a)gmail.com> writes: > @@ -1344,7 +1344,7 @@ static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl ) > > if (data) > { > - gl->type = DC_GL_WINDOW; > + gl->type = DC_GL_CHILD_WIN; This can't possibly work, top-level windows and child windows have to be treated differently. -- Alexandre Julliard julliard(a)winehq.org

2 2

Images in MyHeritage Family Tree Builder
by Stephen Davies 20 Jun '16

20 Jun '16

I am running WINE 1.9.11 (Staging) under Fedora 22. I have been running the MyHeritage Family Tree Builder V7 product on this box for several years without issue but recently (last month perhaps), FTB is no longer able to display JPEG photographs. The JPEG files exist in the relevant directory but they all display as blank images. FTB has not changed but there have been numerous updates to F22 and to WINE suggesting that this may be the cause. Can anybody throw any light on what may have happened? Cheers and thanks, Stephen

3 4

Re: comctl32/tests: Use EqualRect() instead of memcmp() to compare RECTs.
by Marvin 20 Jun '16

20 Jun '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=23734 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: d3d8/tests: Use wine_dbgstr_rect() to print RECTs.
by Marvin 20 Jun '16

20 Jun '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=23732 Your paranoid android. === w8 (32 bit device) === device.c:1372: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1417: Test failed: Reset failed, hr 0x88760868. device.c:1419: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1423: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1430: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1431: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1432: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1433: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1434: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1435: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1440: Test failed: Screen width is 640, expected 800. device.c:1441: Test failed: Screen height is 480, expected 600. device.c:1447: Test failed: Back buffer width is 640, expected 800. device.c:1449: Test failed: Back buffer height is 480, expected 600. device.c:1479: Test failed: Screen width is 640, expected 1024. device.c:1480: Test failed: Screen height is 480, expected 768. device.c:2725: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2730: Test failed: The focus window is active. device.c:2738: Test failed: Got unexpected hr 0x88760869. device.c:2742: Test failed: Got unexpect screen size 800x600. device.c:2757: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2766: Test failed: Got unexpect screen size 800x600. device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2787: Test failed: Got unexpect width 640. device.c:2788: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:7573: Test failed: Got unexpected hr 0. device.c:7575: Test failed: Got unexpected hr 0. === w1064 (32 bit device) === device.c:2725: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2730: Test failed: The focus window is active. device.c:2738: Test failed: Got unexpected hr 0x88760869. device.c:2742: Test failed: Got unexpect screen size 800x600. device.c:2757: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2766: Test failed: Got unexpect screen size 800x600. device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2787: Test failed: Got unexpect width 640. device.c:2788: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 2/5] d3drm: Add stubs for IDirect3DRMFrame interface. (v5)
by Henri Verbeet 20 Jun '16

20 Jun '16

On 19 June 2016 at 00:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > +static HRESULT WINAPI d3drm_frame1_AddChild(IDirect3DRMFrame *iface, IDirect3DRMFrame *child) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + struct d3drm_frame *child_frame = unsafe_impl_from_IDirect3DRMFrame(child); > + > + TRACE("iface %p, child %p.\n", iface, child); > + > + if (!child_frame) > + return D3DRMERR_BADOBJECT; That's redundant, d3drm_frame3_AddChild() already takes care of that.

2 6

Re: [PATCH] msi: allocate correct buffer size (Coverity)
by Hans Leidekker 20 Jun '16

20 Jun '16

On Sat, 2016-06-18 at 10:02 +0200, Marcus Meissner wrote: > 713180 Out-of-bounds access > 713179 Out-of-bounds access > > We pass in a size of 1 character more to MBtoWC than we allocated earlier. No, Coverity doesn't see that MsiEnumComponentsExW and MsiEnumProductsExW return size excluding the terminating null.

1 0

Re: ws2_32: Ensure default route IP addresses are returned first in gethostbyname
by Marvin 19 Jun '16

19 Jun '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=23725 Your paranoid android. === w7pro64 (64 bit sock) === sock.c:7738: Test failed: bytesReturned isn't supposed to be 1 sock.c:7784: Test failed: Waiting for timeout failed with 0 + errno 997

1 0

Re: [PATCH 5/5] d3drm/tests: Modify all QI tests to compare vtables. (resend)
by Henri Verbeet 19 Jun '16

19 Jun '16

On 19 June 2016 at 00:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + { &IID_IUnknown, &IID_IUnknown, NULL, S_OK }, Is the NULL "vtable_iid" here intentional?

2 2

WineConf 2016
by Michael Stefaniuc 19 Jun '16

19 Jun '16

Hello guys, it's that time of the year again where we start thinking about the next WineConf. Last year would already have been the turn for North America so the next WineConf will happen definitely there. Jeremy White / CodeWeavers, as always, was very generous and offered to host it in Minneapolis (or was it St. Paul? ;). But if you're in US / Canada and really hoped to host the next WineConf now is your time to speak up! The Twin Cities are beautiful at -30 C but we wouldn't mind seeing other places too. bye michael

4 4

Re: [PATCH 4/5] d3drm: Fix viewport object creation. (resend)
by Henri Verbeet 19 Jun '16

19 Jun '16

On 19 June 2016 at 00:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -861,10 +863,19 @@ static HRESULT WINAPI d3drm2_CreateShadow(IDirect3DRM2 *iface, IDirect3DRMVisual > FIXME("iface %p, device %p, camera %p, x %u, y %u, width %u, height %u, viewport %p partial stub!\n", > - iface, device, camera, x, y, width, height, viewport); > + iface, device, camera, x, y, width, height, viewport); I thought that was fine the way it was. > -HRESULT Direct3DRMViewport_create(REFIID riid, IUnknown **out) > +HRESULT d3drm_viewport_create(struct d3drm_viewport **viewport, IDirect3DRM *d3drm) > { > struct d3drm_viewport *object; > > - TRACE("riid %s, out %p.\n", debugstr_guid(riid), out); > + TRACE("out %p, d3drm %p.\n", viewport, d3drm); "viewport"

1 0

Re: [PATCH 3/5] d3drm: Fix frame object creation method. (v3 resend)
by Henri Verbeet 19 Jun '16

19 Jun '16

On 19 June 2016 at 00:29, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/d3drm_private.h b/dlls/d3drm/d3drm_private.h > index 817accf..1f4094b 100644 > --- a/dlls/d3drm/d3drm_private.h > +++ b/dlls/d3drm/d3drm_private.h > @@ -44,6 +44,27 @@ struct d3drm_texture > D3DRMIMAGE *image; > }; > > +struct d3drm_frame > +{ > + IDirect3DRMFrame IDirect3DRMFrame_iface; > + IDirect3DRMFrame2 IDirect3DRMFrame2_iface; > + IDirect3DRMFrame3 IDirect3DRMFrame3_iface; > + IDirect3DRM *d3drm; > + LONG ref; > + struct d3drm_frame *parent; > + ULONG nb_children; > + ULONG children_capacity; > + IDirect3DRMFrame3** children; > + ULONG nb_visuals; > + ULONG visuals_capacity; > + IDirect3DRMVisual** visuals; > + ULONG nb_lights; > + ULONG lights_capacity; > + IDirect3DRMLight** lights; > + D3DRMMATRIX4D transform; > + D3DCOLOR scenebackground; > +}; "IDirect3DRMFrame3 **children", "IDirect3DRMVisual **visuals" and "IDirect3DRMLight **lights". > @@ -51,11 +72,11 @@ void d3drm_object_cleanup(IDirect3DRMObject *iface, struct d3drm_object *object) > > HRESULT d3drm_device_create(struct d3drm_device **out) DECLSPEC_HIDDEN; > HRESULT d3drm_texture_create(struct d3drm_texture **texture, IDirect3DRM *d3drm) DECLSPEC_HIDDEN; > +HRESULT d3drm_frame_create(struct d3drm_frame **frame, IUnknown* parent_frame, IDirect3DRM *d3drm) DECLSPEC_HIDDEN; "IUnknown *parent_frame". > -HRESULT Direct3DRMFrame_create(REFIID riid, IUnknown *parent, IUnknown **out) > +HRESULT d3drm_frame_create(struct d3drm_frame **frame, IUnknown* parent_frame, IDirect3DRM *d3drm) Like above. > { > struct d3drm_frame *object; > - HRESULT hr; > + HRESULT hr = D3DRM_OK; > > - TRACE("riid %s, parent %p, out %p.\n", debugstr_guid(riid), parent, out); > + TRACE("out %p, parent_frame %p, d3drm %p.\n", frame, parent_frame, d3drm); "frame" instead of "out". > + if (parent_frame) > { > IDirect3DRMFrame3 *p; > > - hr = IDirect3DRMFrame_QueryInterface(parent, &IID_IDirect3DRMFrame3, (void**)&p); > + hr = IDirect3DRMFrame_QueryInterface(parent_frame, &IID_IDirect3DRMFrame3, (void**)&p); > if (hr != S_OK) "if (FAILED(hr = ...))" and "(void **)".

1 0

Re: [PATCH 1/4] d3drm: Add stubs for IDirect3DRMFrame interface. (v4)
by Henri Verbeet 17 Jun '16

17 Jun '16

On 17 June 2016 at 09:38, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > v4: Replaced GetVisuals, GetParent and GetTransform with thunks to version 2. > > v3: Added version 1->3 thunks for only those frame1 methods that have tests (see test_Frame). The rest will be stubs returning E_NOTIMPL. Also avoid the use of QI in Add/DeleteChild. > Doesn't that potentially break currently working applications? And while having tests is great, I'm not sure I agree with the premise that it's better to return E_NOTIMPL than to forward to an implementation that may have subtle differences but probably doesn't in most cases. > +static HRESULT WINAPI d3drm_frame1_QueryInterface(IDirect3DRMFrame *iface, REFIID riid, void **out) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + return IDirect3DRMFrame3_QueryInterface(&frame->IDirect3DRMFrame3_iface, riid, out); > +} This may have come up before, but any reason you can't call d3drm_frame3_QueryInterface() directly here?

3 5

Re: [PATCH] msscript: Implement FindConnectionPoint()
by Jacek Caban 17 Jun '16

17 Jun '16

Hi Nikolay, On 06/16/2016 09:20 PM, Nikolay Sivov wrote: > +struct ConnectionPoint { > + IConnectionPoint IConnectionPoint_iface; > + ScriptControl *control; > + IConnectionPointContainer *container; Do you need to store IConnectionPointContainer here if you also store ScriptControl? Other than that the patch looks good to me. Thanks, Jacek

1 0

Re: [PATCH 3/5] d3drm/tests: Add refcount tests for IDirect3DRMFrame*. (v2)
by Stefan Dösinger 17 Jun '16

17 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-16 um 00:23 schrieb Aaryaman Vasishta: > This might be a stupid question, but by the full blown QI + > refcounting tests, did you mean what test_frame_qi does? Because > those tests are already present upstream. Yeah, this test is perfectly fine for testing frame refcount links. You can just drop patch 3/5. (I've re-CCed wine-devel) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYxntAAoJEN0/YqbEcdMw9HMP/0kwOc2M6z3bchxsxYJQAF77 ao8uYZvOjkz2Kzp3XGaRMuja2H55qpvNFe0JGmi3pHnGaNQ5SY2s4nqmYFjgUB3u +PNXAXGspalI/1Hx2dFuFYpjZ0FxUA3kaqQeyloBn3zjycb+XtRohQbyv0LOnrDb hRck+jyPpszjDbQruHBRh7Q1VnFMPQXjayfbrY6VhQnxvVKt2aY7mA/fmqRltfwF 9XKOMekT5zoNufjb1ll6+558Nl/+cek37sDr2d09WOO/hlfeovEKKqnYJfucV/bS ZNKN31JFx94KAFaG/JsIiLwS+lJq2bU92ZHWpkQc6CbcRcm8nOFMtZQ9EPh3iRqW ou2i00/UMBXwhoNMOq6yAI6FG6CvUyf7HKqEKhWyJHtaiJ85/ZPgtT+xqOvNSld8 9O54r1JbaDJ5SIQaDiIGc/XmyMot0hLjGMu5l9r/bIF+XTfsP8Bjge+hHe28yaL+ h7qwKWMes52DWxW1BHv6NTFRm1GAuSFaTz5QCyp1zNWegOqS05tmEWjISQ79871g urJg0XcEiKvftx7irWDUOM8gPAOKgSfxfFsVc0zMTJcFRUm6h5tFXld6nDYG7oMy KXU7guPKOdaW2KBM2mqYBUy6yXmAZ5fJXRRvl0Ai/fatvqoH+6RdNwVhEe1DL+BH 4zWH/+UP6vfFOXvAVHpk =hG2j -----END PGP SIGNATURE-----

2 1

IMM / IME work
by Aric Stewart 16 Jun '16

16 Jun '16

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: [PATCH 5/5] mshtml: Added IHTMLButtonElement::form property implementation.
by Marvin 16 Jun '16

16 Jun '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=23683 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/5] mshtml: Added IHTMLButtonElement::value property implementation.
by Marvin 16 Jun '16

16 Jun '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=23682 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/5] mshtml: Added IHTMLButtonElement::get_type implementation.
by Marvin 16 Jun '16

16 Jun '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=23681 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] mshtml: Added IElementSelector::querySelectorAll implementation.
by Marvin 16 Jun '16

16 Jun '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=23680 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: user32/tests: Use wine_dbgstr_rect() to print RECTs.
by Marvin 16 Jun '16

16 Jun '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=23661 Your paranoid android. === 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 === 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 === w1064 (32 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2 === w1064 (64 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2

2 1

Re: [PATCH] configure: Check for GnuTLS block size function
by Alexandre Julliard 16 Jun '16

16 Jun '16

Michael Cronenworth <mike(a)cchtml.com> writes: > diff --git a/configure.ac b/configure.ac > index 7f234b2..6ae8dde 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1268,6 +1268,9 @@ then > WINE_CHECK_LIB_FUNCS(gnutls_hash,[$GNUTLS_LIBS],, > [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no bcrypt hash support.])])])], > [GNUTLS_CFLAGS=""])]) > + WINE_PACKAGE_FLAGS(GNUTLS,[gnutls],,,, > + [WINE_CHECK_LIB_FUNCS(gnutls_cipher_get_block_size,[$GNUTLS_LIBS],, > + [WINE_NOTICE([libgnutls ${notice_platform}development files too old, no block size support.])])]) This won't have any effect, since you don't check the resulting define. In any case I don't think this needs a configure check, since we already have a fallback. You can simply declare the function pointer without using the MAKE_FUNCPTR macro. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] tools: Use type BOOL where appropriate.
by Alexandre Julliard 16 Jun '16

16 Jun '16

Hadrien Boizard <h.boizard(a)gmail.com> writes: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > tools/wrc/parser.y | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) In general, tools don't use the Windows API, so BOOL is not necessarily appropriate either. Technically it's not wrong, but IMO it's not worth changing the code for it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Include system headers before winsock2.h in http.c.
by Alexandre Julliard 16 Jun '16

16 Jun '16

Jacek Caban <jacek(a)codeweavers.com> writes: > Fixes compilation on NetBSD, where zlib.h doesn't include stdlib.h. > > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/wininet/http.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) This breaks the mingw build: In file included from ../../../wine/include/winsock2.h:47:0, from ../../../wine/dlls/wininet/http.c:42: ../../../wine/include/winsock.h:445:19: error: redefinition of ‘struct timeval’ ../../../wine/include/winsock.h:136:19: note: in definition of macro ‘WS’ In file included from /usr/share/mingw-w64/include/time.h:246:0, from ../../../wine/dlls/wininet/http.c:39: /usr/share/mingw-w64/include/_timeval.h:10:8: note: originally defined here Makefile:296: recipe for target 'http.o' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 04/10] d3dx9_30: Share the source with d3dx9_36
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > @@ -75,3 +75,21 @@ D3DX_CPU_OPTIMIZATION WINAPI D3DXCpuOptimizations(BOOL enable) > FIXME("%i - stub\n", enable); > return D3DX_NOT_OPTIMIZED; > } It's probably better to move the D3DXCpuOptimizations() implementation to d3dx9_36 in this patch so you can then drop the forwards from <= d3dx9_29.dll in the following patches.

1 0

Re: [PATCH 01/10] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 8:35 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > -@ stdcall D3DXComputeNormalMap(ptr ptr ptr long long long) d3dx9_36.D3DXComputeNormalMap ... > +@ stub D3DXComputeNormalMap(ptr ptr ptr long long float) Nicely spotted (also for D3DXFrameFind), that should probably be applied to all the DLLs and separately from this patch though. I'm sending a patch for it. > +@ stdcall D3DXGetShaderConstantTableEx(ptr long ptr) This function shouldn't be exported by d3dx9_33.dll. WRT D3DXDebugMute() and D3DXGetDriverLevel(), I would move the implementation to util.c or some other file and avoid duplicating the code in every d3dx9_xx_main.c.

1 0

Re: [PATCH 3/5] d3drm/tests: Add refcount tests for IDirect3DRMFrame*. (v2)
by Stefan Dösinger 15 Jun '16

15 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > + ok(ref1 == ref2, "Expected ref1 == ref2, got ref1 = %u, ref2 = %u.\n", ref1, ref2); > + ok(ref2 == ref3, "Expected ref2 == ref3, got ref2 = %u, ref3 = %u.\n", ref2, ref3); > + ok(ref1 == ref3, "Expected ref1 == ref3, got ref1 = %u, ref3 = %u.\n", ref1, ref3); I think you can assume basic logic still applies to d3drm :-) . There's no need to test ref1 == ref3 after you made sure (ref1 == ref2 && ref2 == ref3) . More importantly though, patch 5 somewhat suggests that you're planning to have a full-blown QI and refcounting test for frames too. If that's the case there's no need to add this patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcYrAAoJEN0/YqbEcdMwudEP/1BMGtCEhuN9i8BbphtECIuF otKTT8qBR1LFP0QocHWntJtCteJ69vq70dfxp764++wqt7UWuGrZhPdKG+6Qjb1u 9kBU6PppQNX4V0tybDgCMIEOv4HcY00FuCN4ahPu5bfBFOskXwOhzs2ne3bYHX1v iDR2NIATu2wwTkA/s/ttj5ZYuKflSl5EUC8wELFwy6IjonaICfuubvgZCVEDBc+R POeJbGbbvn/7v9Q+mfTLNDFvTdDANgTCFkIFmBxrPu2b4erFtRJQV47DVhaLGmZg BwOxV8AYnq7yEltiOkpWKgUtIC4q6U1pf7tW2uUm/4kPMM3+RviiFbX2fNKTFP6f 5rW/5xIP68ymv+Z4su24BbbMcYJPBXkHNkyk1bdARmXtTtzRQbSchdVCLCaOs81k Vmwbl7A4ZqqshTqv40DTRAQq5NWYFcvTbXdUkWZav9EtO9a0hs8PMO9GqG+RBgOu lGk9GrW/jvoWXx/knMtSuoHpkLnpPy4RuJefzVyw1NaawBfakTuUElD0/nnC2f+j 528Ft8FKM9wmJLf3v8fl4IB0vsnExkjOrbKRdWJAuvpxuZJp0rkSdXE0JrEEum44 BlgKzwWvFDl46BX/OC0pzvGlZ6417c/5JgaaPCXus9nGBPBaJx44d2QJWD/UELMS jN9KRUNfGyfcNYS4yVH1 =2nxr -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3drm: Add stubs for IDirect3DRMFrame interface. (v3)
by Stefan Dösinger 15 Jun '16

15 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-15 um 10:35 schrieb Aaryaman Vasishta: > +static HRESULT WINAPI d3drm_frame1_GetVisuals(IDirect3DRMFrame *iface, IDirect3DRMVisualArray **visuals) > +{ > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > + struct d3drm_visual_array *array; > + > + TRACE("iface %p, visuals %p.\n", iface, visuals); > + > + if (!visuals) > + return D3DRMERR_BADVALUE; > + > + if (!(array = d3drm_visual_array_create(frame->nb_visuals, frame->visuals))) > + return E_OUTOFMEMORY; > + > + *visuals = &array->IDirect3DRMVisualArray_iface; > + > + return D3DRM_OK; > +} This is a reimplementation instead of a thunk. Intentional? The same applies to d3drm_frame1_GetTransform. > +static HRESULT WINAPI d3drm_frame1_GetSceneBackgroundDepth(IDirect3DRMFrame *iface, > + IDirectDrawSurface **surface) The indentation here is different. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXYcT1AAoJEN0/YqbEcdMwUHcQAIAfKv2BAfasnwRACZsGBcK9 VAftr2zuIgmlMKtQaplsZuv2ZqcyUnydOgzuXQusFfBldeKeD1ukycLx/sONpuZI ggt7AbXcslw9T0wlprTnfl+1Pna/CSbRQWhVAjeB9dCCWblBslipsj9SLr3hTOwH ppQYvk+BtoXb7A+tvVI2ch/Q8HhwWh/Q9SvVg6tUV7gQLrPG0sj4NEjG50I7VN0c PjLgZHlT7JzVDxlGoefhTPXZdL+1muSIIuxVXho+oNx6qFqiyC0+7xxlJEVR2Eyo VBzdczdYd0UcLRb0GOqyJpRcGTpYE06zahKeDyODIXeorFB0NlYFqSTD2H32RVNU M2a+xKgFLqm4zu+cabfRIvFk9wGkIRykwfm8KUY4LyZCZmlQZ21nPCAIsuolRqV6 DrmQAParbMg/fAb6L9/uB0rb/CBPGIhm3mtv00TewBG8VG16uV4vLbvtoiIJJtD4 Z6iY6x948K+jjVVkhGDRfdEJn+nQRDTKIkgsRKic9S5x/nOEyfreVutjq4vULnGk l5hRAzyzOxjP/JTMHhvYtHYbLtqjgXPi3pwhjrfGMWLKAmeRPk3A2FdsUl9A1I3I INR8LmGAo3P7a1GZ21loc5A2iftn29vcAB0mDzcotczOEsinfx7Sc4oF5fIUDZla miBufY1gPaDENTTiRcz5 =hvk0 -----END PGP SIGNATURE-----

1 0

Re: ddraw/tests: A spelling fix for a d3d ok() message.
by Francois Gouget 15 Jun '16

15 Jun '16

Anything wrong with this patch? On Sun, 29 May 2016, Francois Gouget wrote: > Signed-off-by: Francois Gouget <fgouget(a)free.fr> > --- > dlls/ddraw/tests/d3d.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index d877020..0e9a43b 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -1155,7 +1155,7 @@ static void Direct3D1Test(void) > /* Interface consistency check. */ > hr = IDirect3DDevice_GetDirect3D(Direct3DDevice1, &Direct3D_alt); > ok(hr == D3D_OK, "IDirect3DDevice_GetDirect3D failed: %08x\n", hr); > - ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer missmatch: %p != %p\n", Direct3D_alt, Direct3D1); > + ok(Direct3D_alt == Direct3D1, "Direct3D1 struct pointer mismatch: %p != %p\n", Direct3D_alt, Direct3D1); > IDirect3D_Release(Direct3D_alt); > > memset(&desc, 0, sizeof(desc)); > -- > 2.8.1 > > > > -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

3 4

Re: [PATCH 5/5] d3dx9: Turn an ERR into a WARN.
by Matteo Bruni 15 Jun '16

15 Jun '16

2016-06-15 9:51 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Hello Matteo, > > I am afraid that if application passes effect data broken an > arbitrary way then probably almost every ERR and FIXME should be changed > to WARN (at least in my code, but probably in the rest of effect > framework either). E. g., we have FIXME on not yet supported relative > addressing, but it can also happen if the application passes broken > effect code. Or do you see any difference for this case with parameter > name? I do not yet, as actually preshader and effect are compiled > together, and it is no way to get such a situation (at least if there is > some feature in fxc compiler which I am not aware of) other than > modifying effect bytecode. > > Regards, > Paul. The general idea is that FIXME refers to something that isn't (completely / correctly) implemented in Wine, so e.g. FIXME is the right choice for relative addressing. ERR is the correct choice for "internal errors" in Wine (i.e. something that shouldn't happen unless there is a bug in Wine - the ERR("Unexpected register set %u.\n", ...) is a good example of that) and WARN should be used when the application can trigger the problematic condition by misusing the API or similar. Specifically WRT this patch I just happened to notice that ERR while looking through the code and it seems to me that WARN fits better. It's not a big deal either way.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Józef Kucia 15 Jun '16

15 Jun '16

This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 5

Re: [PATCH] wined3d: Properly handle immediate NaN and Inf in GLSL backend.
by Józef Kucia 15 Jun '16

15 Jun '16

In my opinion, we do not want to solve the issue with immediate constant buffers this way. However, this patch might still be useful. Some games (Magicka 2) use shaders which contain NaN values in immediate constants. This patch represents a one way to solve the issue with NaN values in immediate constants. If we decide that we want to apply this change we should be more careful though. We probably want to use this for SM4+ shaders only, or use it only when GL_ARB_shader_bit_encoding is available. On a side note, "uintBitsToFloat" cannot be used as a constant expression (at least in GLSL 1.30), so to make this work with the immediate constant buffers patch you would have to drop "const". On Mon, Jun 13, 2016 at 9:30 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 36 +++++++++++++++++++++++++----------- > 1 file changed, 25 insertions(+), 11 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index def224c..fde4c5e 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -34,6 +34,8 @@ > > #include <limits.h> > #include <stdio.h> > +#include <stdint.h> > +#include <inttypes.h> We avoid C99 in Wine. unsigned int and %#xu should be good enough. > #ifdef HAVE_FLOAT_H > # include <float.h> > #endif > @@ -321,14 +323,26 @@ static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info > return "#version 120"; > } > > +/* Allow raw NaN and Inf in GLSL code. */ > +void wined3d_glsl_ftoa(float value, char *s) The function should be static. > +{ > + if (!isfinite(value)) > + { > + /* We need a buffer of at least 28 characters. */ > + snprintf(s, 28, "uintBitsToFloat(%"PRIu32"u)", *(uint32_t *)&value); It seems that 29 bytes are needed at least (including the null character). > + } > + else > + wined3d_ftoa(value, s); > +} In wined3d, generally, if one block in if-else statement needs curly braces we use curly braces for all blocks in this statement. else { wined3d_ftoa(value, s); } > + > static void shader_glsl_append_imm_vec4(struct wined3d_string_buffer *buffer, const float *values) > { > - char str[4][17]; > + char str[4][28]; > > - wined3d_ftoa(values[0], str[0]); > - wined3d_ftoa(values[1], str[1]); > - wined3d_ftoa(values[2], str[2]); > - wined3d_ftoa(values[3], str[3]); > + wined3d_glsl_ftoa(values[0], str[0]); > + wined3d_glsl_ftoa(values[1], str[1]); > + wined3d_glsl_ftoa(values[2], str[2]); > + wined3d_glsl_ftoa(values[3], str[3]); > shader_addline(buffer, "vec4(%s, %s, %s, %s)", str[0], str[1], str[2], str[3]); > } > > @@ -2299,7 +2313,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > const struct wined3d_gl_info *gl_info = ins->ctx->gl_info; > const char *prefix = shader_glsl_get_prefix(version->type); > struct glsl_src_param rel_param0, rel_param1; > - char imm_str[4][17]; > + char imm_str[4][28]; > > if (reg->idx[0].offset != ~0U && reg->idx[0].rel_addr) > shader_glsl_add_src_param(ins, reg->idx[0].rel_addr, WINED3DSP_WRITEMASK_0, &rel_param0); > @@ -2513,7 +2527,7 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)reg->immconst_data, register_name); > + wined3d_glsl_ftoa(*(const float *)reg->immconst_data, register_name); > break; > case WINED3D_DATA_INT: > sprintf(register_name, "%#x", reg->immconst_data[0]); > @@ -2533,10 +2547,10 @@ static void shader_glsl_get_register_name(const struct wined3d_shader_register * > switch (reg->data_type) > { > case WINED3D_DATA_FLOAT: > - wined3d_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > - wined3d_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[0], imm_str[0]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[1], imm_str[1]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[2], imm_str[2]); > + wined3d_glsl_ftoa(*(const float *)&reg->immconst_data[3], imm_str[3]); > sprintf(register_name, "vec4(%s, %s, %s, %s)", > imm_str[0], imm_str[1], imm_str[2], imm_str[3]); It looks like shader_glsl_append_imm_vec4() could be called there instead.

4 8

Re: [PATCH] wined3d: Correct memory size for Geforece 9600 GT (resend)
by Henri Verbeet 15 Jun '16

15 Jun '16

On 15 June 2016 at 09:48, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/wined3d/directx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > This isn't necessarily wrong, but why is this needed/more correct?

2 2

Fwd: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by DavidL 15 Jun '16

15 Jun '16

Sorry, keep hitting reply instead of reply-all to make sure the list-serve has a copy. ---------- Forwarded message ---------- From: DavidL <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 12:05 AM Subject: Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping To: Ken Thomases <ken(a)codeweavers.com> As far as I can tell, both. It both arbitrarily picks which is first for any given run (so yes I can definitely confirm that bug report's description) and the game seems to read input from both inputs regardless of which is first - although which is first does still affect the game. I created virtual joystick in Controllermate which I mapped my physical joystick to but mapping X to Y and Y to X, so that when I pulled back on the yoke it would give both an X reading and a Y reading at the same time if it were reading input from both the virtual and physical joystick. In game, that's what happened, even when the trace logs said it was only recording information from one joystick (and in one case, Red Baron, it was explicitly reading from both in the trace log). Which joystick was found first would affect behavior somewhat (hard to describe, basically how out of whack the motions became!), but regardless I could get it sometimes explicitly, sometimes implicitly to read multiple inputs. Maybe this is an anomaly with virtual joysticks. Not sure, shouldn't be. On Mon, Jun 13, 2016 at 11:41 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Jun 14, 2016, at 1:23 AM, DavidL <david.dljunk(a)gmail.com> wrote: > > > On Mon, Jun 13, 2016 at 2:46 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Is there reason to expect that these elements (sliders, dials, wheels) >> will be listed after the "proper" axes (x, y, z, etc.) in the children >> array? Since the proper axes are specific and these elements should only >> be mapped to unused axes, I think they should be enumerated in a separate >> pass after everything else has had a shot. Note that >> collect_joystick_elements() is recursive, so it's not right to do it in a >> separate loop within collect_joystick_elements(). Probably, you'll want to >> call it twice from open_joystick(), with a flag to indicate which mode it >> should operate in. > > > This where the Microsoft source documentation get *really* fuzzy. There > are all sorts of possible mappings in the rare case where there is both a > HID/Dinput Z-axis and a slider/dial/wheel. Microsoft gave 4-5 different > variations of how it could go and in some of these mappings, the slider > would take precedence over the reported HID Z-axis when mapping to the > Winmm Z-axis such that slider -> WinmmZ is correct and the HID Z-axis is > then ignored. So I decided to follow the Linux Winmm version and simply > have whichever element is listed by the joystick first, wins. If it is the > axis, it's the axis, if it is the slider, it's the slider. This actually is > one of the ways Microsoft says to decide proper HID mappings to Winmm (and > it seems like that for the elements within a joystick, the elements are > always reported in the same order such that a user shouldn't experience the > axes mappings changing each time they start up Wine/reconnect a device*). > There is no 1 correct mapping for all cases. I guess ideally we would have > a way of allowing the user to remap the joystick axes in the registry > (maybe that would work even now? I don't know - I've seen some emails on > that already in the wine-devel list serve but I don't know what the status > of that kind of capability is) but even Microsoft states on of their pages > that this is a pretty rare corner case. > > > OK, fine by me. > > > *Note: in my testing this is *not* the same for OS X (I guess macOS now) > reporting back devices - which human interface device is reported first > seems to be random in my testing when I had both a virtual and physical > joystick setup. Historically Winmm games would only take input from the > first reported device - under Mac-Wine, I've noticed the games seem to be > taking input from both my physical and virtual joysticks (sometimes > regardless of what the game was saying it was doing!). This has both good > and bad potential and is not necessarily behavior we should spend effort > trying to get rid of. Not sure how the Linux version behaves in this > situation in terms of joystick order and input from multiple sources. > > > It was taking input from both joysticks in the same run? At the same > time? If so, can you figure out how that's happening? It really > shouldn't, as near as I can see. > > Or was it just arbitrarily picking which was first and therefore active > for any given run? If this, then it's < > https://bugs.winehq.org/show_bug.cgi?id=38997>, more or less. > > -Ken > >

2 4

Re: [v2 02/10] msvcirt: Implement ostream constructors/destructors
by Piotr Caban 15 Jun '16

15 Jun '16

On 06/14/16 19:01, Iván Matellanes wrote: > On 14/06/16 16:20, Piotr Caban wrote: >> On 06/14/16 16:40, Iván Matellanes wrote: >>> /* ??_Dostream@@QAEXXZ */ >>> @@ -2287,23 +2341,48 @@ ostream* __thiscall ostream_assign(ostream >>> *this, const ostream *rhs) >>> DEFINE_THISCALL_WRAPPER(ostream_vbase_dtor, 4) >>> void __thiscall ostream_vbase_dtor(ostream *this) >>> { >>> - FIXME("(%p) stub\n", this); >>> + ios *base = ostream_to_ios(this); >>> + >>> + TRACE("(%p)\n", this); >>> + >>> + ostream_dtor(base); >>> + ios_dtor(base); >>> } >> The base should be computed using ostream_get_ios while calling ios_dtor: >> TRACE("(%p)\n", this); >> ostream_dtor(ostream_to_ios(this)); >> ios_dtor(ostream_get_ios(this)); > Do you mind explaining why is that required? I can't see the reason ostream_vbase_dtor can be used to destroy object that has virtual base in any position pointer by vbtable. ostream_get_ios computes it using object's vbtable. You can easily see it by overwriting ostream->vbtable with garbage, the application will crash then on Windows. On the other hand ostream_dtor is a virtual function that assumes "this" is at fixed offset from "base" that is passed to it. It's done this way because it has no access to vbtable. It's why you need to use ostream_to_ios in this case. There's no real need to call ostream_dtor here because it's an empty function (I don't know if it should be called here or if ostream_vbase_dtor should only destroy the vbase). Thanks, Piotr

2 2

Re: [PATCH] riched20: Remove duplicated condition and duplicated test
by Huw Davies 15 Jun '16

15 Jun '16

On Tue, Jun 14, 2016 at 08:56:41PM +0300, Nikolay Sivov wrote: > diff --git a/dlls/riched20/richole.c b/dlls/riched20/richole.c > index 1013e67..a2f23c9 100644 > --- a/dlls/riched20/richole.c > +++ b/dlls/riched20/richole.c > @@ -1976,7 +1976,7 @@ static HRESULT range_Collapse(LONG bStart, LONG *start, LONG *end) > if (*end == *start) > return S_FALSE; > > - if (bStart == tomEnd || bStart == tomFalse) > + if (bStart == tomEnd) > *start = *end; > else > *end = *start; > > diff --git a/dlls/riched20/tests/richole.c b/dlls/riched20/tests/richole.c > index 6da3ce3..33043fd 100644 > --- a/dlls/riched20/tests/richole.c > +++ b/dlls/riched20/tests/richole.c > @@ -1361,18 +1361,6 @@ static void test_ITextRange_Collapse(void) > first = 4, lim = 8; > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomTrue); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 4, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 4, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomStart); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); > @@ -1385,18 +1373,6 @@ static void test_ITextRange_Collapse(void) > > hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > ok(hres == S_OK, "got 0x%08x\n", hres); > - hres = ITextRange_Collapse(txtRge, tomFalse); > - ok(hres == S_OK, "ITextRange_Collapse\n"); > - hres = ITextRange_GetStart(txtRge, &start); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(start == 8, "got wrong start value: %d\n", start); > - hres = ITextRange_GetEnd(txtRge, &end); > - ok(hres == S_OK, "got 0x%08x\n", hres); > - ok(end == 8, "got wrong end value: %d\n", end); > - ITextRange_Release(txtRge); > - > - hres = ITextDocument_Range(txtDoc, first, lim, &txtRge); > - ok(hres == S_OK, "got 0x%08x\n", hres); > hres = ITextRange_Collapse(txtRge, tomEnd); > ok(hres == S_OK, "ITextRange_Collapse\n"); > hres = ITextRange_GetStart(txtRge, &start); I don't think we should remove the extra tests, especially as tomTrue != tomStart and it's documentented to work with either. Leaving the tomFalse tests in is fine too. Huw.

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Sebastian Lackner 15 Jun '16

15 Jun '16

On 14.06.2016 09:09, Marcus Meissner wrote: > From: Austin English <austinenglish(a)gmail.com> > > https://bugs.winehq.org/show_bug.cgi?id=18745 > > Report 2MB minimum page size on x86 32bit and 64bit on Linux. > > This assumes that all x86 processors and the 64/32bit emulation mode > have hugetable support and it is always enabled. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > Signed-off-by: Austin English <austinenglish(a)gmail.com> As pointed out on IRC, the order of the sign-offs is wrong here. Your own signoff should always be the last because you have to take responsibility when you send a patch. > --- > dlls/kernel32/cpu.c | 15 +++++++++++++++ > dlls/kernel32/kernel32.spec | 2 +- > dlls/kernel32/tests/process.c | 16 ++++++++++++++++ > 3 files changed, 32 insertions(+), 1 deletion(-) > > diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c > index f48fcf0..f8b2c3d 100644 > --- a/dlls/kernel32/cpu.c > +++ b/dlls/kernel32/cpu.c > @@ -291,3 +291,18 @@ err: > } > return TRUE; > } > + > +/*********************************************************************** > + * GetLargePageMinimum (KERNEL32.@) > + */ > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux I do not see any need for that #ifdef linux. Its more architecture specific than linux specific. Dmitry already mentioned the same concern on the mailing list. > +#if defined(__i386___) || defined(__x86_64__) > + /* Linux x86 hugepages are minimum 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index ec7155b6e..0fc4dcb 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -696,7 +696,7 @@ > @ stdcall GetHandleInformation(long ptr) > @ stub -i386 GetLSCallbackTarget > @ stub -i386 GetLSCallbackTemplate > -# @ stub GetLargePageMinimum > +@ stdcall GetLargePageMinimum() > @ stdcall GetLargestConsoleWindowSize(long) > @ stdcall GetLastError() > @ stub GetLinguistLangSize > diff --git a/dlls/kernel32/tests/process.c b/dlls/kernel32/tests/process.c > index 61dcdc2..e9acfd3 100644 > --- a/dlls/kernel32/tests/process.c > +++ b/dlls/kernel32/tests/process.c > @@ -88,6 +88,7 @@ static BOOL (WINAPI *pProcess32Next)(HANDLE, PROCESSENTRY32*); > static BOOL (WINAPI *pThread32First)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pThread32Next)(HANDLE, THREADENTRY32*); > static BOOL (WINAPI *pGetLogicalProcessorInformationEx)(LOGICAL_PROCESSOR_RELATIONSHIP,SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX*,DWORD*); > +static SIZE_T (WINAPI *pGetLargePageMinimum)(void); > > /* ############################### */ > static char base[MAX_PATH]; > @@ -252,6 +253,7 @@ static BOOL init(void) > pThread32First = (void *)GetProcAddress(hkernel32, "Thread32First"); > pThread32Next = (void *)GetProcAddress(hkernel32, "Thread32Next"); > pGetLogicalProcessorInformationEx = (void *)GetProcAddress(hkernel32, "GetLogicalProcessorInformationEx"); > + pGetLargePageMinimum = (void *)GetProcAddress(hkernel32, "GetLargePageMinimum"); > > return TRUE; > } > @@ -3138,6 +3140,19 @@ static void test_GetLogicalProcessorInformationEx(void) > HeapFree(GetProcessHeap(), 0, info); > } > > +static void test_largepages(void) > +{ > + SIZE_T size; > + > + if (!pGetLargePageMinimum) { > + skip("No GetLargePageMinimum support.\n"); > + return; > + } > + size = pGetLargePageMinimum(); > + > + ok((size == 0) || (size == 2*1024*1024) || (size == 4*1024*1024), "GetLargePageMinimum reports %ld size\n", size); > +} > + > START_TEST(process) > { > HANDLE job; > @@ -3210,6 +3225,7 @@ START_TEST(process) > test_GetNumaProcessorNode(); > test_session_info(); > test_GetLogicalProcessorInformationEx(); > + test_largepages(); > > /* things that can be tested: > * lookup: check the way program to be executed is searched >

3 3

Re: [v4 4/4] winejoystick.drv/joystick_osx.c: adds sim page element controls
by Ken Thomases 15 Jun '16

15 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Adds support for input features defined by HID Simulation page: Rudder > (Rz), Throttle (Z), Steering (X), Accelerator (Y), Brake (Rz). > +static int axis_for_usage_Sim(int usage) > +{ > + switch (usage) > + { > + case kHIDUsage_Sim_Rudder: return AXIS_RZ; > + case kHIDUsage_Sim_Throttle: return AXIS_Z; > + case kHIDUsage_Sim_Steering: return AXIS_X; > + case kHIDUsage_Sim_Accelerator: return AXIS_Y; > + case kHIDUsage_Sim_Brake: return AXIS_RZ; > + } Is it intentional that Rudder and Brake both map to the same axis? Later, when enumerating elements, which comes first and thus "wins" the collision (if they ever appear on the same device) is arbitrary based on enumeration order. That OK? > @@ -404,66 +418,100 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kIOHIDElementTypeInput_Axis: > - { > - TRACE("kIOHIDElementTypeInput_Axis; ignoring\n"); > - break; > - } > case kIOHIDElementTypeInput_Misc: It seems that treating kIOHIDElementTypeInput_Axis the same as kIOHIDElementTypeInput_Misc is a separate issue from adding support for the Sim page inputs. Or is there an interrelationship that I'm not aware of? Is it the case that both Axis and Misc elements can be present with either GD or Sim usage pages? Some of the debug logging statements have been changed to say "kIOHIDElementTypeInput_Axis/Misc" while others have been left as "kIOHIDElementTypeInput_Misc". Is that indicative of something or just an oversight? > @@ -614,7 +662,7 @@ LRESULT driver_joyGetDevCaps(DWORD_PTR device_id, JOYCAPSW* caps, DWORD size) > { > int i; > > - /* complete 95 structure */ > + /* complete Win95 structure */ This is an unrelated change. -Ken

2 3

Fwd: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements
by DavidL 15 Jun '16

15 Jun '16

I made the changes to the patches we talked about and added the patch below. All it does is ignore "feature"-type elements which aren't meant for end user consumption, suppressing the FIXME message in Trace logs for those elements. Since these element types are un-handled by Winmm, I don't think a FIXME message is necessary for them. However, if you feel we should keep the fixme messages in place, I'm fine with that too. Cheers, David ---------- Forwarded message ---------- From: David Lawrie <david.dljunk(a)gmail.com> Date: Tue, Jun 14, 2016 at 8:33 PM Subject: [v5 5/5] winejoystick.drv/joystick_osx.c: ignore feature elements To: wine-patches <wine-patches(a)winehq.org> Cc: David Lawrie <david.dljunk(a)gmail.com> "Describes input and output elements not intended for consumption by the end user." Ignore, as otherwise, comes up as a FIXME in Trace logs. Source: https://developer.apple.com/library/mac/documentation/IOKit/Reference/ IOHIDKeys_iokit_header_reference/#//apple_ref/c/tdef/IOHIDElementType Tested on OS X 10.10.5. Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> --- dlls/winejoystick.drv/joystick_osx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c index ad82dd7..12ccff7 100644 --- a/dlls/winejoystick.drv/joystick_osx.c +++ b/dlls/winejoystick.drv/joystick_osx.c @@ -514,6 +514,9 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll } break; } + case kIOHIDElementTypeFeature: + /* Describes input and output elements not intended for consumption by the end user. Ignoring. */ + break; default: FIXME("Unhandled type %i\n",type); break; -- 1.7.12.4 (Apple Git-37)

1 0

Re: [v4 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
by Ken Thomases 15 Jun '16

15 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Ry now maps to U, Rx now maps to V. Windows defines Winmm U as Dinput Ry > and V as Dinput Rx. Original joystick_osx.c mapping was other way > around. This is also a bug in the Linux Winmm joystick version (not > fixed with this patch). > > Sources: > https://msdn.microsoft.com/en-us/library/windows/hardware/ff538340(v=vs.85)… > https://msdn.microsoft.com/en-us/library/windows/hardware/ff543445(v=vs.85)… > > Tested on OS X 10.10.5. > > Tested on Red Baron 3D, X-wing vs Tie Fighter, X-wing Alliance, > Independence War deluxe w/ Logitech Extreme 3D pro and ControllerMate > virtual joystick with 5/6 axes. I originally wrote this code, but I think I was largely basing it on the Linux code without having a strong handle on the behavior of the R* axes. Your testing is probably the most thorough that's been done for the Mac code, although I would expect the Linux code to have been tested pretty well. Maybe the Linux code is correct and it's only the comments about what the joystick device is providing that are wrong. So, the code changes appear to properly implement the logic you've described above, but I don't know if that's correct. The cited MSDN pages are not terribly clear. That said, I would prefer if you kept the order of the axes enum the same (consistently x, y, z order) and changed the order of the axis_map table in driver_joyGetPosEx(), instead. -Ken

2 3

Re: d3dx10_43: Add D3DX10FilterTexture stub
by Matteo Bruni 14 Jun '16

14 Jun '16

2016-06-13 17:02 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: Can you please also add the D3DX10_FILTER_FLAG type declaration to d3dx10tex.h? > + FIXME("texture %p, src_level %u, filter %u stub!\n", texture, src_level, filter); filter is a flags bitmask, please trace it with %#x or similar.

1 0

Re: [PATCH] d3dx9_33: Share the source with d3dx9_36
by Matteo Bruni 14 Jun '16

14 Jun '16

2016-06-10 10:33 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=21817 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx9_33/Makefile.in | 22 +- > dlls/d3dx9_33/d3dx9_33.spec | 667 +++++++++++++++++++++--------------------- > dlls/d3dx9_33/d3dx9_33_main.c | 19 ++ > tools/make_specfiles | 1 - > 4 files changed, 373 insertions(+), 336 deletions(-) > > diff --git a/dlls/d3dx9_33/Makefile.in b/dlls/d3dx9_33/Makefile.in > index 0934eab..1106d11 100644 > --- a/dlls/d3dx9_33/Makefile.in > +++ b/dlls/d3dx9_33/Makefile.in > @@ -1,7 +1,25 @@ > MODULE = d3dx9_33.dll > -IMPORTS = d3d9 > +IMPORTS = d3d9 d3dcompiler dxguid d3dxof ole32 gdi32 user32 wined3d You don't want to import wined3d here. It looks good otherwise, at a quick glance. Do you mind also writing similar patches for the other d3dx9_xx and d3dcompiler_xx DLLs?

1 0

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Nikolay Sivov 14 Jun '16

14 Jun '16

On 14.06.2016 21:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > index 18ca9d4..85b2b83 100644 > --- a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec > @@ -7,7 +7,7 @@ > @ cdecl _aligned_realloc(ptr long long) ucrtbase._aligned_realloc > @ stub _aligned_recalloc > @ cdecl _callnewh(long) ucrtbase._callnewh > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) ucrtbase._calloc_base > @ cdecl _expand(ptr long) ucrtbase._expand > @ stub _free_base > @ cdecl _get_heap_handle() ucrtbase._get_heap_handle > diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec > index 690072b..365674b 100644 > --- a/dlls/ucrtbase/ucrtbase.spec > +++ b/dlls/ucrtbase/ucrtbase.spec > @@ -211,7 +211,7 @@ > @ cdecl _c_exit() MSVCRT__c_exit > @ cdecl _cabs(long) MSVCRT__cabs > @ cdecl _callnewh(long) > -@ stub _calloc_base > +@ cdecl _calloc_base(long long) MSVCRT_calloc > @ cdecl _cexit() MSVCRT__cexit > @ cdecl _cgets(ptr) > @ stub _cgets_s > Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.

3 3

Re: [PATCH 2/4] ucrtbase: Forward _calloc_base to MSVCRT_calloc.
by Sebastian Lackner 14 Jun '16

14 Jun '16

On 14.06.2016 20:28, Alex Henrie wrote: > Cc: Piotr Caban <piotr(a)codeweavers.com> > > For https://bugs.winehq.org/show_bug.cgi?id=40796 > > The Windows 10 SDK helpfully explains that calloc simply wraps > _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not > defined. Since Wine will not be implementing _calloc_dbg because it is > only available in debug builds of the C runtime library, we can make > _calloc_base wrap calloc instead. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- > dlls/ucrtbase/ucrtbase.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Martin Storsjo tried the same approach already, and it was rejected. If I remember correctly separate wrapper functions were preferred in this case.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Henri Verbeet 14 Jun '16

14 Jun '16

On 12 June 2016 at 22:21, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > +static HRESULT WINAPI is_warp_cb(GUID *guid, char *description, char *name, > + D3DDEVICEDESC *hal_desc, D3DDEVICEDESC *hel_desc, void *ctx) > +{ > + BOOL *is_warp = ctx; > + if (IsEqualGUID(guid, &IID_IDirect3DHALDevice)) > + { > + *is_warp = !!(hal_desc->dwDevCaps & D3DDEVCAPS_TEXTURESYSTEMMEMORY); > + return DDENUMRET_CANCEL; > + } > + return DDENUMRET_OK; > +} > + > static void test_p8_blit(void) > { > IDirectDrawSurface *src, *dst, *dst_p8; > DDSURFACEDESC surface_desc; > IDirectDraw *ddraw; > + IDirect3D *d3d; > IDirectDrawPalette *palette, *palette2; > ULONG refcount; > HWND window; > @@ -5305,6 +5318,7 @@ static void test_p8_blit(void) > PALETTEENTRY palette_entries[256]; > unsigned int x; > DDBLTFX fx; > + BOOL is_warp = FALSE; > static const BYTE src_data[] = {0x10, 0x1, 0x2, 0x3, 0x4, 0x5, 0xff, 0x80}; > static const BYTE src_data2[] = {0x10, 0x5, 0x4, 0x3, 0x2, 0x1, 0xff, 0x80}; > static const BYTE expected_p8[] = {0x10, 0x1, 0x4, 0x3, 0x4, 0x5, 0xff, 0x80}; > @@ -5322,6 +5336,16 @@ static void test_p8_blit(void) > hr = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > > + /* Locking a P8 surface crashes on WARP if a d3d device has been created. So we > + * need to find the caps via enumeration. */ > + hr = IDirectDraw_QueryInterface(ddraw, &IID_IDirect3D, (void **)&d3d); > + if (SUCCEEDED(hr)) > + { > + hr = IDirect3D_EnumDevices(d3d, is_warp_cb, &is_warp); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + IDirect3D_Release(d3d); > + } Can't you just use ddraw4/7's GetDeviceIdentifier()?

2 1

Re: [PATCH] msvcrt/tests: Add tests for mbstowcs and wcstombs with a negative count.
by Piotr Caban 14 Jun '16

14 Jun '16

Hi Alex, On 06/12/16 22:07, Alex Henrie wrote: > + ret = mbstowcs(wOut, mSimple, -1); > +todo_wine > + ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); This will cause compilation warning: ../../../../wine_src/dlls/msvcrt/tests/string.c:1863:5: warning: format '%i' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=] ok(ret == -1 || broken(ret == 4) /* xp */, "mbstowcs returned %i instead of -1\n", ret); I'm also not sure if Windows XP behavior should be marked as broken. For me newer systems behavior is broken (doesn't handle strings longer then INT_MAX). Do you have an application that depends on it? Thanks, Piotr

2 4

Re: [v2 02/10] msvcirt: Implement ostream constructors/destructors
by Piotr Caban 14 Jun '16

14 Jun '16

On 06/14/16 16:40, Iván Matellanes wrote: > /* ??_Dostream@@QAEXXZ */ > @@ -2287,23 +2341,48 @@ ostream* __thiscall ostream_assign(ostream *this, const ostream *rhs) > DEFINE_THISCALL_WRAPPER(ostream_vbase_dtor, 4) > void __thiscall ostream_vbase_dtor(ostream *this) > { > - FIXME("(%p) stub\n", this); > + ios *base = ostream_to_ios(this); > + > + TRACE("(%p)\n", this); > + > + ostream_dtor(base); > + ios_dtor(base); > } The base should be computed using ostream_get_ios while calling ios_dtor: TRACE("(%p)\n", this); ostream_dtor(ostream_to_ios(this)); ios_dtor(ostream_get_ios(this)); Thanks, Piotr

1 0

Re: secur32/tests: Don't load crypt32.dll function dynamically.
by Marvin 14 Jun '16

14 Jun '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=23615 Your paranoid android. === w1064 (32 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308. === w1064 (64 bit schannel) === schannel.c:837: Test failed: Got unexpected status 0x80090308. schannel.c:845: Test failed: Got unexpected status 0x80090308.

1 0

Re: [PATCH] wined3d: Implement icb dcl support in GLSL.
by Guillaume Charifi 14 Jun '16

14 Jun '16

Hello, thank you for your feedback :) I just sent a patch that fixes the NaN issue in all places it can happen (at least in the GLSL backend). Well, stupid drivers... It seems to work really well with Mesa, but I just saw some 1 fps benchmarks, so I guess it's a *nope*. I'll do a test to make you happy, and try to fix the other things. :) <div>-------- Message d'origine --------</div><div>De : Józef Kucia <joseph.kucia(a)gmail.com> </div><div>Date :13/06/2016 20:32 (GMT+01:00) </div><div>À : wine-devel <wine-devel(a)winehq.org> </div><div>Cc : Guillaume Charifi <guillaume.charifi(a)sfr.fr> </div><div>Objet : Re: [PATCH] wined3d: Implement icb dcl support in GLSL. </div><div> </div>This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable. Also, a test would be nice. On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 55affc1..def224c 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont > if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) > shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool); > > + if (reg_maps->icb) > + { > + shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n", > + prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4); > + for (i = 0; i < reg_maps->icb->element_count / 4; i++) { > + shader_glsl_append_imm_vec4(buffer, (float *)&reg_maps->icb->data[4 * i]); > + if (i != reg_maps->icb->element_count / 4 - 1) > + shader_addline(buffer, ","); > + shader_addline(buffer, "\n"); > + } > + shader_addline(buffer, ");\n"); > + } I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer. > + > for (i = 0; i < WINED3D_MAX_CBS; ++i) > { > if (reg_maps->cb_sizes[i]) > @@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB > /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, > /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, > /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL, > - /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL, > + /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, > /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, > /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop, > -- > 2.7.4 > > >

2 1

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Marvin 14 Jun '16

14 Jun '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=23604 Your paranoid android. === w864 (32 bit process) === process.c:2859: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH] kernel32: implement GetLargePageMinimum
by Alexandre Julliard 14 Jun '16

14 Jun '16

Marcus Meissner <marcus(a)jet.franken.de> writes: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > + FILE *f; > + unsigned long hugepagesize = 0; > + > + f = fopen( "/proc/meminfo", "r" ); > + if (f) > + { > + char buffer[256]; > + > + while (fgets( buffer, sizeof(buffer), f )) > + { > + if (sscanf( buffer, "Hugepagesize: %lu", &hugepagesize )) > + break; > + } > + fclose( f ); > + } > + return (SIZE_T)hugepagesize*1024; > +#else > + FIXME("stub: not implemented on your platform.\n"); > + return 0; > +#endif This could probably be simply hard-coded based on the CPU architecture. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [v4 2/4] winejoystick.drv/joystick_osx.c: fixes Slider mapping
by Ken Thomases 14 Jun '16

14 Jun '16

On Jun 13, 2016, at 12:11 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Sliders, Dials, and Wheels now map to Z, U (Ry), or V (Rx) depending on > availability. Thus, also adds support for up to 3 such HID elements. > dlls/winejoystick.drv/joystick_osx.c | 20 +++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/dlls/winejoystick.drv/joystick_osx.c b/dlls/winejoystick.drv/joystick_osx.c > index 77dbef8..4e59ca3 100644 > --- a/dlls/winejoystick.drv/joystick_osx.c > +++ b/dlls/winejoystick.drv/joystick_osx.c > @@ -442,8 +442,26 @@ static void collect_joystick_elements(joystick_t* joystick, IOHIDElementRef coll > break; > } > case kHIDUsage_GD_Slider: > - TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_Slider; ignoring\n"); > + case kHIDUsage_GD_Dial: > + case kHIDUsage_GD_Wheel: > + { > + //if one axis is taken, fall to the next until axes are filled Line comments (//) are not allowed in most of Wine. > + int possible_axes[3] = {AXIS_Z,AXIS_RY,AXIS_RX}; > + int axis = 0; > + TRACE("kIOHIDElementTypeInput_Misc / kHIDUsage_GD_<axis> (%d)", usage); > + while(axis < 3 && joystick->axes[possible_axes[axis]].element) > + axis++; > + if (axis == 3) > + TRACE(" ignoring\n"); > + else > + { > + TRACE(" axis %d\n", possible_axes[axis]); Rather than breaking the trace line across multiple TRACEs, you should just move the TRACE to after the selection of an axis. Note that in the existing code, the "ignoring" TRACEs are on a separate line, which is why they are indented. It doesn't make sense to have that extra space if that isn't on a separate line. Alternatively, you could put a newline on the first TRACE and indent the axis trace as a subordinate line. > + joystick->axes[possible_axes[axis]].element = (IOHIDElementRef)CFRetain(child); > + joystick->axes[possible_axes[axis]].min_value = IOHIDElementGetLogicalMin(child); > + joystick->axes[possible_axes[axis]].max_value = IOHIDElementGetLogicalMax(child); > + } > break; > + } Is there reason to expect that these elements (sliders, dials, wheels) will be listed after the "proper" axes (x, y, z, etc.) in the children array? Since the proper axes are specific and these elements should only be mapped to unused axes, I think they should be enumerated in a separate pass after everything else has had a shot. Note that collect_joystick_elements() is recursive, so it's not right to do it in a separate loop within collect_joystick_elements(). Probably, you'll want to call it twice from open_joystick(), with a flag to indicate which mode it should operate in. -Ken

2 3

Re: [MASSMAIL][PATCH] kernel32: implement GetLargePageMinimum
by Dmitry Timoshkov 14 Jun '16

14 Jun '16

Marcus Meissner <marcus(a)jet.franken.de> wrote: > +SIZE_T WINAPI GetLargePageMinimum(void) > +{ > +#ifdef linux > +#ifdef __i386__ > + /* Linux x86 hugepages are 2 MB */ > + return 2*1024*1024; > +#endif > +#endif > + FIXME("stub: not implemented on your platform/architecture.\n"); > + return 0; > +} What's the reason of making it linux only and excluding x86_64? -- Dmitry.

1 0

Differences between named pipes in Windows and Wine
by Ryan Prichard 14 Jun '16

14 Jun '16

Hi, I noticed a handful of differences in the "lifecycle" of named pipes between Windows and Wine, and I figured I'd post about them here. I wrote a standalone one-file C++ program that demonstrates the differences I found. (In that test, the pipe handles are always overlapped and PIPE_WAIT.) I tested using wine-1.9.12. The differences were: 1. With Windows, there can be multiple concurrent ConnectNamedPipe operations on a pipe. With Wine, the second ConnectNamedPipe call fails with ERROR_INVALID_HANDLE. 2. With Windows, DisconnectNamedPipe aborts ConnectNamedPipe operations with the error ERROR_PIPE_NOT_CONNECTED. The DisconnectNamedPipe call succeeds, and the pipe is no longer listening. With Wine, the DisconnectNamedPipe call itself fails with ERROR_PIPE_LISTENING, and the pipe is still listening. 3. With Windows, if the server breaks the pipe by closing its handle, the client can finish reading the remaining data in the pipe. Once the data is gone, reading from a broken pipe fails with ERROR_BROKEN_PIPE. Writing to a broken pipe fails with ERROR_NO_DATA. With Wine, once the server breaks the pipe, the client cannot read the remaining data, and I/O on a broken pipe fails with ERROR_PIPE_NOT_CONNECTED. (Exception: ReadFile on a server pipe still returns ERROR_BROKEN_PIPE.) 4. Calling ConnectNamedPipe on a broken server pipe fails with ERROR_NO_DATA on Windows, but ERROR_NO_DATA_DETECTED on Wine. My test program is at: https://gist.github.com/rprichard/8dd8ca134b39534b7da2733994aa07ba. It passes on XP, Vista, Win7, and Win10, with the exception of testChangeMaxInstancesAfterClosingLastServerHandle, which passes on Vista and up. A couple of the more interesting tests are testDisconnectAtStartup and testReadFromBrokenClientPipe: testDisconnectAtStartup: // Calling DisconnectNamedPipe on a new pipe successfully transitions it to a // "Not Connected" state. The second DisconnectNamedPipe call fails, and the // client can't connect. void testDisconnectAtStartup() { const HANDLE server = assertValid(openServer(name(0))); CHECK_SUCCESS(DisconnectNamedPipe(server)); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_FAILURE(DisconnectNamedPipe(server), ERROR_PIPE_NOT_CONNECTED); CHECK(createFile(name(0)) == INVALID_HANDLE_VALUE); CHECK_SUCCESS(CloseHandle(server)); } // If a client pipe is broken, rather than disconnected, the remaining data can // still be read. void testReadFromBrokenClientPipe() { DWORD actual = 0; Over over; char buf[2] = {}; const HANDLE server = assertValid(openServer(name(0))); const HANDLE client = assertValid(createFile(name(0))); CHECK_SUCCESS(WriteFile(server, buf, 1, &actual, &over)); CHECK_SUCCESS(CloseHandle(server)); CHECK_SUCCESS(ReadFile(client, buf, 2, &actual, &over)); CHECK(actual == 1); CHECK_FAILURE(ReadFile(client, buf, 2, &actual, &over), ERROR_BROKEN_PIPE); CHECK_SUCCESS(CloseHandle(client)); } I know that item #3 above breaks my winpty project (in principle), where a pipe server signals EOF by closing a pipe without disconnecting it. The winpty client can read all the output before hitting the broken pipe. I suspect winpty may not run on Wine anyway, though. -Ryan

2 1

wine-1.8.3-rc2 Available
by Michael Stefaniuc 13 Jun '16

13 Jun '16

Hello guys, wine-1.8.3-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ There is just a small change compared to rc1 but that required a rebase and thus you'll see a forced upgrade. Changes to rc1: --------------- The two ole32 patches were deferred to a future 1.8.x version. They need more testing in the wild to make them less risky for Stable: - ole32: Implement StgOpenPropStg. - ole32: Implement StgCreatePropStg. This should be the final rc for 1.8.3 (famous last words...) bye michael

1 0

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP.
by Marvin 13 Jun '16

13 Jun '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=23562 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw1) === ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw1.c:5445: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw7) === ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw7.c:7940: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw2) === ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw2.c:6502: Test failed: Got unexpected P8 color key blit result. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w864 (64 bit ddraw4) === ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result. === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). ddraw4.c:8029: Test failed: Got unexpected P8 color key blit result.

2 1

Re: [PATCH 3/3] msscript: Implement Timeout property
by Jacek Caban 13 Jun '16

13 Jun '16

Hi Nikolay, On 06/11/2016 12:02 PM, Nikolay Sivov wrote: > static HRESULT WINAPI ScriptControl_put_Timeout(IScriptControl *iface, LONG milliseconds) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%d)\n", This, milliseconds); > - return E_NOTIMPL; > + > + TRACE("(%p)->(%d)\n", This, milliseconds); > + > + if (milliseconds < -1) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + This->timeout = milliseconds; > + return S_OK; > } Getter/setter implementation seems fine, but it's not full implementation and I'm pretty sure that at least first versions that will be able to execute script code won't support that (builtin jscript nor vbscript supports that, so there is very little point in implementing it here), so FIXME or WARN here would be more appropriate here. Thanks, Jacek

2 2

Re: [PATCH 2/3] msscript: Added basic script hosting stub support
by Jacek Caban 13 Jun '16

13 Jun '16

Hi Nikolay, On 06/11/2016 12:02 PM, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > This deprecates patch 123111. > > dlls/msscript.ocx/msscript.c | 237 ++++++++++++++++- > dlls/msscript.ocx/tests/Makefile.in | 2 +- > dlls/msscript.ocx/tests/msscript.c | 488 ++++++++++++++++++++++++++++++++++++ > include/activscp.idl | 16 ++ > 4 files changed, 737 insertions(+), 6 deletions(-) > > diff --git a/dlls/msscript.ocx/msscript.c b/dlls/msscript.ocx/msscript.c > index 5a03f0c..b6764f4 100644 > --- a/dlls/msscript.ocx/msscript.c > +++ b/dlls/msscript.ocx/msscript.c > @@ -22,6 +22,7 @@ > #include "initguid.h" > #include "ole2.h" > #include "olectl.h" > +#include "activscp.h" > #include "rpcproxy.h" > #include "msscript.h" > > @@ -29,14 +30,21 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(msscript); > > +static const WCHAR vbscriptW[] = {'V','B','S','c','r','i','p','t',0}; > +static const WCHAR jscriptW[] = {'J','S','c','r','i','p','t',0}; > + > struct ScriptControl { > IScriptControl IScriptControl_iface; > IPersistStreamInit IPersistStreamInit_iface; > IOleObject IOleObject_iface; > IOleControl IOleControl_iface; > + IActiveScriptSite IActiveScriptSite_iface; > LONG ref; > IOleClientSite *site; > SIZEL extent; > + BSTR lang; > + IActiveScript *script; > + SCRIPTSTATE script_state; > }; It's a good moment to think a bit about the design here. I don't think you want to reuse IActiveScriptSite for all script engines you load. A separated object would allow better ref counting, would be cleaner and safer in my opinion. A quick test on Windows suggests that native does that. > static HINSTANCE msscript_instance; > @@ -120,6 +128,29 @@ static void release_typelib(void) > ITypeLib_Release(typelib); > } > > +static void release_script_engine(ScriptControl *sc) > +{ > + if (!sc->script) > + return; > + > + switch (sc->script_state) { > + case SCRIPTSTATE_CONNECTED: > + IActiveScript_SetScriptState(sc->script, SCRIPTSTATE_DISCONNECTED); > + > + case SCRIPTSTATE_STARTED: > + case SCRIPTSTATE_DISCONNECTED: > + case SCRIPTSTATE_INITIALIZED: > + IActiveScript_Close(sc->script); > + > + default: > + ; > + } Some "fall through" comments to avoid static analyser fixes follow ups would be nice. > -static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR language) > +static HRESULT WINAPI ScriptControl_put_Language(IScriptControl *iface, BSTR lang) > { > ScriptControl *This = impl_from_IScriptControl(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_w(language)); > - return E_NOTIMPL; > + HRESULT hr; > + GUID guid; > + > + TRACE("(%p)->(%s)\n", This, debugstr_w(lang)); > + > + if (!lang) { > + release_script_engine(This); > + set_script_name(This, NULL); > + return S_OK; > + } > + > + hr = CLSIDFromProgID(lang, &guid); > + if (FAILED(hr)) > + return CTL_E_INVALIDPROPERTYVALUE; > + > + hr = CoCreateInstance(&guid, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IActiveScript, (void**)&This->script); > + if (FAILED(hr)) > + return CTL_E_INVALIDPROPERTYVALUE; > + else if (!init_script_engine(This)) { > + release_script_engine(This); > + return CTL_E_INVALIDPROPERTYVALUE; > + } > + > + /* store engine name */ > + if (!lstrcmpiW(lang, vbscriptW)) > + This->lang = SysAllocString(vbscriptW); > + else if (!lstrcmpiW(lang, jscriptW)) > + This->lang = SysAllocString(jscriptW); > + else Why do you need those? My guess is that returned script may have different upper/lower cases, but if that the case, then we should probably use ProgIDFromCLSID in getter and just store CLSID. > + This->lang = SysAllocString(lang); > + > + return S_OK; > } > > static HRESULT WINAPI ScriptControl_get_State(IScriptControl *iface, ScriptControlStates *p) > @@ -873,8 +1096,12 @@ static HRESULT WINAPI ScriptControl_CreateInstance(IClassFactory *iface, IUnknow > script_control->IPersistStreamInit_iface.lpVtbl = &PersistStreamInitVtbl; > script_control->IOleObject_iface.lpVtbl = &OleObjectVtbl; > script_control->IOleControl_iface.lpVtbl = &OleControlVtbl; > + script_control->IActiveScriptSite_iface.lpVtbl = &ActiveScriptSiteVtbl; > script_control->ref = 1; > script_control->site = NULL; > + script_control->lang = NULL; > + script_control->script_state = SCRIPTSTATE_UNINITIALIZED; > + script_control->script = NULL; > > hdc = GetDC(0); > dpi_x = GetDeviceCaps(hdc, LOGPIXELSX); > diff --git a/dlls/msscript.ocx/tests/Makefile.in b/dlls/msscript.ocx/tests/Makefile.in > index 8d769d3..cc62590 100644 > --- a/dlls/msscript.ocx/tests/Makefile.in > +++ b/dlls/msscript.ocx/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = msscript.ocx > -IMPORTS = user32 gdi32 ole32 > +IMPORTS = user32 gdi32 ole32 oleaut32 advapi32 > > C_SRCS = \ > msscript.c > diff --git a/dlls/msscript.ocx/tests/msscript.c b/dlls/msscript.ocx/tests/msscript.c > index 12f7003..d1d553b 100644 > --- a/dlls/msscript.ocx/tests/msscript.c > +++ b/dlls/msscript.ocx/tests/msscript.c > @@ -22,10 +22,411 @@ > #include <initguid.h> > #include <ole2.h> > #include <olectl.h> > +#include "dispex.h" > +#include "activscp.h" > +#include "activdbg.h" > +#include "objsafe.h" > > #include "msscript.h" > #include "wine/test.h" > > +#define TESTSCRIPT_CLSID "{178fc164-f585-4e24-9c13-4bb7faf80746}" > +static const GUID CLSID_TestScript = > + {0x178fc164,0xf585,0x4e24,{0x9c,0x13,0x4b,0xb7,0xfa,0xf8,0x07,0x46}}; > + > +#ifdef _WIN64 > + > +#define CTXARG_T DWORDLONG > +#define IActiveScriptParseVtbl IActiveScriptParse64Vtbl > +#define IActiveScriptSiteDebug_Release IActiveScriptSiteDebug64_Release > + > +#else > + > +#define CTXARG_T DWORD > +#define IActiveScriptParseVtbl IActiveScriptParse32Vtbl > +#define IActiveScriptSiteDebug_Release IActiveScriptSiteDebug32_Release > + > +#endif > + > +static IActiveScriptSite *site; > +static SCRIPTSTATE state; > + > +static HRESULT WINAPI ActiveScriptParse_QueryInterface(IActiveScriptParse *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + ok(0, "unexpected call\n"); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ActiveScriptParse_AddRef(IActiveScriptParse *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ActiveScriptParse_Release(IActiveScriptParse *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ActiveScriptParse_InitNew(IActiveScriptParse *iface) > +{ > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScriptParse_AddScriptlet(IActiveScriptParse *iface, > + LPCOLESTR pstrDefaultName, LPCOLESTR pstrCode, LPCOLESTR pstrItemName, > + LPCOLESTR pstrSubItemName, LPCOLESTR pstrEventName, LPCOLESTR pstrDelimiter, > + CTXARG_T dwSourceContextCookie, ULONG ulStartingLineNumber, DWORD dwFlags, > + BSTR *pbstrName, EXCEPINFO *pexcepinfo) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScriptParse_ParseScriptText(IActiveScriptParse *iface, > + LPCOLESTR pstrCode, LPCOLESTR pstrItemName, IUnknown *punkContext, > + LPCOLESTR pstrDelimiter, CTXARG_T dwSourceContextCookie, ULONG ulStartingLine, > + DWORD dwFlags, VARIANT *pvarResult, EXCEPINFO *pexcepinfo) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static const IActiveScriptParseVtbl ActiveScriptParseVtbl = { > + ActiveScriptParse_QueryInterface, > + ActiveScriptParse_AddRef, > + ActiveScriptParse_Release, > + ActiveScriptParse_InitNew, > + ActiveScriptParse_AddScriptlet, > + ActiveScriptParse_ParseScriptText > +}; > + > +static IActiveScriptParse ActiveScriptParse = { &ActiveScriptParseVtbl }; > + > +static HRESULT WINAPI ObjectSafety_QueryInterface(IObjectSafety *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + ok(0, "unexpected call %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ObjectSafety_AddRef(IObjectSafety *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ObjectSafety_Release(IObjectSafety *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ObjectSafety_GetInterfaceSafetyOptions(IObjectSafety *iface, REFIID riid, > + DWORD *pdwSupportedOptions, DWORD *pdwEnabledOptions) > +{ > + ok(IsEqualGUID(&IID_IActiveScriptParse, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + ok(pdwSupportedOptions != NULL, "pdwSupportedOptions == NULL\n"); > + ok(pdwEnabledOptions != NULL, "pdwEnabledOptions == NULL\n"); > + > + *pdwSupportedOptions = INTERFACESAFE_FOR_UNTRUSTED_DATA|INTERFACE_USES_DISPEX|INTERFACE_USES_SECURITY_MANAGER; > + *pdwEnabledOptions = INTERFACE_USES_DISPEX; > + > + return S_OK; > +} > + > +static HRESULT WINAPI ObjectSafety_SetInterfaceSafetyOptions(IObjectSafety *iface, REFIID riid, > + DWORD mask, DWORD options) > +{ > + ok(IsEqualGUID(&IID_IActiveScriptParse, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + > + ok(mask == INTERFACESAFE_FOR_UNTRUSTED_DATA, "option mask = %x\n", mask); > + ok(options == 0, "options = %x\n", options); > + > + return S_OK; > +} > + > +static const IObjectSafetyVtbl ObjectSafetyVtbl = { > + ObjectSafety_QueryInterface, > + ObjectSafety_AddRef, > + ObjectSafety_Release, > + ObjectSafety_GetInterfaceSafetyOptions, > + ObjectSafety_SetInterfaceSafetyOptions > +}; > + > +static IObjectSafety ObjectSafety = { &ObjectSafetyVtbl }; > + > +static HRESULT WINAPI ActiveScript_QueryInterface(IActiveScript *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + > + if(IsEqualGUID(&IID_IUnknown, riid) || IsEqualGUID(&IID_IActiveScript, riid)) { > + *ppv = iface; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IObjectSafety, riid)) { > + *ppv = &ObjectSafety; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IActiveScriptParse, riid)) { > + *ppv = &ActiveScriptParse; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IActiveScriptGarbageCollector, riid)) { > + return E_NOINTERFACE; > + } > + > + ok(0, "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ActiveScript_AddRef(IActiveScript *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ActiveScript_Release(IActiveScript *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ActiveScript_SetScriptSite(IActiveScript *iface, IActiveScriptSite *pass) > +{ > + IActiveScriptSiteInterruptPoll *poll; > + IActiveScriptSiteDebug *debug; > + IServiceProvider *service; > + ICanHandleException *canexpection; > + LCID lcid; > + HRESULT hres; > + > + ok(pass != NULL, "pass == NULL\n"); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IActiveScriptSiteInterruptPoll, (void**)&poll); > + ok(hres == E_NOINTERFACE, "Could not get IActiveScriptSiteInterruptPoll interface: %08x\n", hres); > + > + hres = IActiveScriptSite_GetLCID(pass, &lcid); > + ok(hres == S_OK, "GetLCID failed: %08x\n", hres); > + > + hres = IActiveScriptSite_OnStateChange(pass, (state = SCRIPTSTATE_INITIALIZED)); > +todo_wine > + ok(hres == E_NOTIMPL, "OnStateChange failed: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IActiveScriptSiteDebug, (void**)&debug); > + ok(hres == E_NOINTERFACE, "Could not get IActiveScriptSiteDebug interface: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_ICanHandleException, (void**)&canexpection); > + ok(hres == E_NOINTERFACE, "Could not get IID_ICanHandleException interface: %08x\n", hres); > + > + hres = IActiveScriptSite_QueryInterface(pass, &IID_IServiceProvider, (void**)&service); > +todo_wine > + ok(hres == S_OK, "Could not get IServiceProvider interface: %08x\n", hres); > + if(SUCCEEDED(hres)) > + IServiceProvider_Release(service); > + > + site = pass; > + IActiveScriptSite_AddRef(site); > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptSite(IActiveScript *iface, REFIID riid, > + void **ppvObject) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_SetScriptState(IActiveScript *iface, SCRIPTSTATE ss) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptState(IActiveScript *iface, SCRIPTSTATE *pssState) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_Close(IActiveScript *iface) > +{ > + return S_OK; > +} > + > +static HRESULT WINAPI ActiveScript_AddNamedItem(IActiveScript *iface, > + LPCOLESTR pstrName, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_AddTypeLib(IActiveScript *iface, REFGUID rguidTypeLib, > + DWORD dwMajor, DWORD dwMinor, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptDispatch(IActiveScript *iface, LPCOLESTR pstrItemName, > + IDispatch **ppdisp) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetCurrentScriptThreadID(IActiveScript *iface, > + SCRIPTTHREADID *pstridThread) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptThreadID(IActiveScript *iface, > + DWORD dwWin32ThreadId, SCRIPTTHREADID *pstidThread) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_GetScriptThreadState(IActiveScript *iface, > + SCRIPTTHREADID stidThread, SCRIPTTHREADSTATE *pstsState) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_InterruptScriptThread(IActiveScript *iface, > + SCRIPTTHREADID stidThread, const EXCEPINFO *pexcepinfo, DWORD dwFlags) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI ActiveScript_Clone(IActiveScript *iface, IActiveScript **ppscript) > +{ > + ok(0, "unexpected call\n"); > + return E_NOTIMPL; > +} > + > +static const IActiveScriptVtbl ActiveScriptVtbl = { > + ActiveScript_QueryInterface, > + ActiveScript_AddRef, > + ActiveScript_Release, > + ActiveScript_SetScriptSite, > + ActiveScript_GetScriptSite, > + ActiveScript_SetScriptState, > + ActiveScript_GetScriptState, > + ActiveScript_Close, > + ActiveScript_AddNamedItem, > + ActiveScript_AddTypeLib, > + ActiveScript_GetScriptDispatch, > + ActiveScript_GetCurrentScriptThreadID, > + ActiveScript_GetScriptThreadID, > + ActiveScript_GetScriptThreadState, > + ActiveScript_InterruptScriptThread, > + ActiveScript_Clone > +}; > + > +static IActiveScript ActiveScript = { &ActiveScriptVtbl }; > + > +static HRESULT WINAPI ClassFactory_QueryInterface(IClassFactory *iface, REFIID riid, void **ppv) > +{ > + *ppv = NULL; > + > + if(IsEqualGUID(&IID_IUnknown, riid) || IsEqualGUID(&IID_IClassFactory, riid)) { > + *ppv = iface; > + return S_OK; > + } > + > + if(IsEqualGUID(&IID_IMarshal, riid)) > + return E_NOINTERFACE; > + > + ok(0, "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI ClassFactory_AddRef(IClassFactory *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI ClassFactory_Release(IClassFactory *iface) > +{ > + return 1; > +} > + > +static HRESULT WINAPI ClassFactory_CreateInstance(IClassFactory *iface, IUnknown *outer, REFIID riid, void **ppv) > +{ > + ok(!outer, "outer = %p\n", outer); > + ok(IsEqualGUID(&IID_IActiveScript, riid), "unexpected riid %s\n", wine_dbgstr_guid(riid)); > + *ppv = &ActiveScript; > + return S_OK; > +} > + > +static HRESULT WINAPI ClassFactory_LockServer(IClassFactory *iface, BOOL dolock) > +{ > + ok(0, "unexpected call\n"); > + return S_OK; > +} > + > +static const IClassFactoryVtbl ClassFactoryVtbl = { > + ClassFactory_QueryInterface, > + ClassFactory_AddRef, > + ClassFactory_Release, > + ClassFactory_CreateInstance, > + ClassFactory_LockServer > +}; > + > +static IClassFactory script_cf = { &ClassFactoryVtbl }; > + > +static BOOL init_key(const char *key_name, const char *def_value, BOOL init) > +{ > + HKEY hkey; > + DWORD res; > + > + if(!init) { > + RegDeleteKeyA(HKEY_CLASSES_ROOT, key_name); > + return TRUE; > + } > + > + res = RegCreateKeyA(HKEY_CLASSES_ROOT, key_name, &hkey); > + if(res != ERROR_SUCCESS) > + return FALSE; > + > + if(def_value) > + res = RegSetValueA(hkey, NULL, REG_SZ, def_value, strlen(def_value)); > + > + RegCloseKey(hkey); > + > + return res == ERROR_SUCCESS; > +} > + > +static BOOL init_registry(BOOL init) > +{ > + return init_key("TestScript\\CLSID", TESTSCRIPT_CLSID, init) > + && init_key("CLSID\\"TESTSCRIPT_CLSID"\\Implemented Categories\\{F0B7A1A1-9847-11CF-8F20-00805F2CD064}", > + NULL, init) > + && init_key("CLSID\\"TESTSCRIPT_CLSID"\\Implemented Categories\\{F0B7A1A2-9847-11CF-8F20-00805F2CD064}", > + NULL, init); > +} > + > +static BOOL register_script_engine(void) > +{ > + DWORD regid; > + HRESULT hres; > + > + if(!init_registry(TRUE)) { > + init_registry(FALSE); > + return FALSE; > + } > + > + hres = CoRegisterClassObject(&CLSID_TestScript, (IUnknown *)&script_cf, > + CLSCTX_INPROC_SERVER, REGCLS_MULTIPLEUSE, &regid); > + ok(hres == S_OK, "Could not register script engine: %08x\n", hres); > + > + return TRUE; > +} > + > static HRESULT WINAPI OleClientSite_QueryInterface(IOleClientSite *iface, REFIID riid, void **obj) > { > if (IsEqualIID(riid, &IID_IOleClientSite) || IsEqualIID(riid, &IID_IUnknown)) > @@ -213,6 +614,92 @@ static void test_olecontrol(void) > IOleControl_Release(olecontrol); > } > > +static void test_Language(void) > +{ > + static const WCHAR vbW[] = {'V','B','S','c','r','i','p','t',0}; > + static const WCHAR jsW[] = {'J','S','c','r','i','p','t',0}; > + static const WCHAR vb2W[] = {'v','B','s','c','r','i','p','t',0}; > + static const WCHAR dummyW[] = {'d','u','m','m','y',0}; > + IScriptControl *sc; > + HRESULT hr; > + BSTR str; > + > + hr = CoCreateInstance(&CLSID_ScriptControl, NULL, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > + &IID_IScriptControl, (void**)&sc); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + hr = IScriptControl_get_Language(sc, NULL); > + ok(hr == E_POINTER, "got 0x%08x\n", hr); > + > + str = (BSTR)0xdeadbeef; > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(str == NULL, "got %s\n", wine_dbgstr_w(str)); > + > + str = SysAllocString(vbW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + str = SysAllocString(vb2W); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, vbW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + str = SysAllocString(dummyW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == CTL_E_INVALIDPROPERTYVALUE, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, vbW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + str = SysAllocString(jsW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(str, jsW), "got %s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + hr = IScriptControl_put_Language(sc, NULL); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(str == NULL, "got %s\n", wine_dbgstr_w(str)); > + > + /* custom script engine */ > + if (register_script_engine()) { > + static const WCHAR testscriptW[] = {'t','e','s','t','s','c','r','i','p','t',0}; > + > + str = SysAllocString(testscriptW); > + hr = IScriptControl_put_Language(sc, str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + SysFreeString(str); It's nice to have tests with emulated script engine, but please also add test of called callbacks. Please add something like CHECK_EXPECT()/CHECK_CALLED() macros or alike. Otherwise important informations that your tests already gather are hidden and not tested. > + > + hr = IScriptControl_get_Language(sc, &str); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(!lstrcmpW(testscriptW, str), "%s\n", wine_dbgstr_w(str)); > + SysFreeString(str); > + > + init_registry(FALSE); > + } > + else > + skip("Could not register TestScript engine\n"); > + > + IScriptControl_Release(sc); > +} > + > START_TEST(msscript) > { > IUnknown *unk; > @@ -231,6 +718,7 @@ START_TEST(msscript) > test_oleobject(); > test_persiststreaminit(); > test_olecontrol(); > + test_Language(); > > CoUninitialize(); > } > diff --git a/include/activscp.idl b/include/activscp.idl > index 8a3d75d..e539b04 100644 > --- a/include/activscp.idl > +++ b/include/activscp.idl > @@ -71,6 +71,11 @@ typedef enum tagSCRIPTUICHANDLING { > SCRIPTUICHANDLING_NOUIDEFAULT = 2 > } SCRIPTUICHANDLING; > > +typedef enum tagSCRIPTGCTYPE { > + SCRIPTGCTYPE_NORMAL = 0, > + SCRIPTGCTYPE_EXHAUSTIVE = 1 > +} SCRIPTGCTYPE; > + > typedef DWORD SCRIPTTHREADID; > cpp_quote("#define SCRIPTTHREADID_CURRENT ((SCRIPTTHREADID)-1)") > cpp_quote("#define SCRIPTTHREADID_BASE ((SCRIPTTHREADID)-2)") > @@ -551,3 +556,14 @@ interface IActiveScriptProperty : IUnknown > [in] VARIANT *pvarIndex, > [in] VARIANT *pvarValue); > } > + > +[ > + object, > + uuid(6aa2c4a0-2b53-11d4-a2a0-00104bd35090), > + pointer_default(unique) > +] > +interface IActiveScriptGarbageCollector : IUnknown > +{ > + HRESULT CollectGarbage( > + [in] SCRIPTGCTYPE gctype); > +} It's not too important, but technically it deserves a separated patch. Thanks, Jacek

2 2

Re: [PATCH] inetcomm: Implement IMimeBody GetPropInfo
by Alexandre Julliard 13 Jun '16

13 Jun '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if(pInfo->dwMask | PIM_CHARSET) > + pInfo->hCharset = 0; > + if(pInfo->dwMask | PIM_FLAGS) > + pInfo->dwFlags = 0x00000000; > + if(pInfo->dwMask | PIM_ROWNUMBER) > + pInfo->dwRowNumber = 0; > + if(pInfo->dwMask | PIM_ENCODINGTYPE) > + pInfo->ietEncoding = 0; > + if(pInfo->dwMask | PIM_VALUES) > + pInfo->cValues = 0; > + if(pInfo->dwMask | PIM_PROPID) > + pInfo->dwPropId = header->prop->id; > + if(pInfo->dwMask | PIM_VTDEFAULT) > + pInfo->vtDefault = header->prop->default_vt; > + if(pInfo->dwMask | PIM_VTCURRENT) > + pInfo->vtCurrent = 0; This doesn't do what you want. You should initialize to some garbage value instead of 0 in your tests, that would have caught it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32/tests: Use wine_dbgstr_rect() in the win tests.
by Marvin 13 Jun '16

13 Jun '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=23566 Your paranoid android. === w2008s64 (32 bit win) === win.c:8861: Test failed: GetActiveWindow() = 00000000 win.c:8861: Test failed: GetFocus() = 00000000 win.c:8863: Test failed: Expected foreground window 00080124, got 000200E4 win.c:8866: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:8873: Test failed: Expected foreground window 00080124, got 00000000 win.c:8875: Test failed: GetActiveWindow() = 00000000 win.c:8875: Test failed: GetFocus() = 00000000 win.c:8883: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.

2 1

Wine for Android
by Jimmy Tamayo 13 Jun '16

13 Jun '16

Hi I use wine in wifislax which is a Linux based os and is awesome but maybe the developers can make wine for Android lollipop and marshmallow that would be great so we the users can execute Exe applications in our smartphones Thanks in advance for your attention Greetings

2 1

Re: [1/3] imm32, user32: Create and destroy the default IME window implicitly. (try 7)
by Alexandre Julliard 13 Jun '16

13 Jun '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 7: > - Remove the refcount argument from internal API. > - Introduce WIN_HAS_IME_WIN flag to remember IME window reference. > - To avoid test failures on wine, always create IME window (affects non-CJK locales). > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 97 +++++++++++++++++++++++++++++++++++----------- > dlls/imm32/imm32.spec | 1 + > dlls/imm32/tests/imm32.c | 12 +++--- > dlls/user32/misc.c | 4 +- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 26 +++++++++++++ > dlls/user32/win.h | 1 + > 7 files changed, 112 insertions(+), 30 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so msg && touch msg.ok msg.c:14206: Test failed: 0: got 0x80050 msg.c:14206: Test failed: 4: got 0x80050 msg.c:14206: Test failed: 5: got 0x80050 msg.c:12921: Tests skipped: Skipping DBCS WM_CHAR test in SBCS codepage 'ANSI Latin 1' msg.c:13237: Tests skipped: Unable to load Greek keyboard layout make: *** [msg.ok] Error 3 Implementing ImmDisableIME first would probably fix it, but the test succeeds for me on Windows even without calling ImmDisableIME, so there may be something else going on here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 1/4] winejoystick.drv/joystick_osx.c: fixes Ry/Rx -> U/V axes mapping
by Alex Henrie 13 Jun '16

13 Jun '16

> Signed-off-by: David Lawrie david.dljunk(a)gmail.com This line is incorrectly formatted. Please use the format with angle brackets generated by `git commit -s`. See https://wiki.winehq.org/Submitting_Patches#The_commit_message for an example. -Alex

2 1

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