wine-devel August 2016

wine-devel@winehq.org

55 participants
282 discussions

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

03 Aug '16

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

2 2

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

03 Aug '16

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

1 0

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

03 Aug '16

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

2 2

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

02 Aug '16

1 0

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

02 Aug '16

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

1 0

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

02 Aug '16

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

1 0

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

02 Aug '16

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

1 0

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

02 Aug '16

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

1 0

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

02 Aug '16

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

1 0

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

02 Aug '16

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

1 0

Jump to page:

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 August 2016