January 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] dnsapi: DnsQueryEx partial implementation (ver.3)
by Hans Leidekker Jan. 15, 2016

Jan. 15, 2016

On Fri, 2016-01-15 at 11:35 +0300, Donat Enikeev wrote: >+ TRACE("DNS address to use %hhu.%hhu.%hhu.%hhu (%u) \n", >+ p_sockaddr->sin_addr.WS_s_impno, p_sockaddr->sin_addr.WS_s_lh, >+ p_sockaddr->sin_addr.WS_s_host, p_sockaddr->sin_addr.WS_s_net, p_sockaddr->sin_addr.WS_s_addr); %hhu is not needed here (and would not be allowed in Wine because it's a C99 feature). You can use %u.

1 0

Re: [PATCH v3] ole32: OleGetClipboard(): zero output interface pointer on error ole32/tests: OleGetClipboard fails on locked
by Marvin Jan. 15, 2016

Jan. 15, 2016

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

1 0

Re: [PATCH] ole32/tests: OleGetClipboard natively succeeds when COM/OLE is not inited
by Huw Davies Jan. 15, 2016

Jan. 15, 2016

On Thu, Jan 14, 2016 at 01:49:39PM +0300, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/tests/clipboard.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c > index 83994f3..48ca891 100644 > --- a/dlls/ole32/tests/clipboard.c > +++ b/dlls/ole32/tests/clipboard.c > @@ -455,6 +455,17 @@ static HRESULT DataObjectImpl_CreateComplex(LPDATAOBJECT *lplpdataobj) > return S_OK; > } > > +static void test_get_clipboard_unitialized() You're missing a 'void'. clipboard.c:1574:13: warning: function declaration isn’t a prototype > +{ > + HRESULT hr; > + IDataObject *pDObj; > + > + pDObj = (IDataObject *)0xdeadbeef; > + hr = OleGetClipboard(&pDObj); > + todo_wine ok(hr == S_OK, "OleGetClipboard() got 0x%08x instead of 0x%08x\n", hr, S_OK); > + if (pDObj && pDObj != (IDataObject *)0xdeadbeef) IUnknown_Release((IUnknown*)pDObj); > +} > + > static void test_get_clipboard(void) > { > HRESULT hr; > @@ -1592,6 +1603,7 @@ static void test_get_clipboard_locked() > > START_TEST(clipboard) > { > + test_get_clipboard_unitialized(); > test_set_clipboard(); > test_consumer_refs(); > test_flushed_getdata(); > -- > 2.5.0 > > >

1 0

Re: [PATCH v2] ole32: better match native behaviour in OLE init/uninit ole32/tests: check COM/OLE init state after mixed COM/OLE init/uninit
by Huw Davies Jan. 15, 2016

Jan. 15, 2016

On Wed, Jan 13, 2016 at 01:16:42PM +0300, Paul Gofman wrote: > Native OleUnitialize never uninits apartment inited by CoInitializeEx. > CoUnitialize after OleInitialize uninits apartment, but Ole is still considered > inited. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/compobj.c | 2 ++ > dlls/ole32/ole2.c | 7 +++++ > dlls/ole32/tests/compobj.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 79 insertions(+) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index 90b049a..78fc30d 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -1972,6 +1972,8 @@ void WINAPI DECLSPEC_HOTPATCH CoUninitialize(void) > > if (!--info->inits) > { > + if (info->ole_inits) > + ERR("uninitializing apartment while Ole is still initialized\n"); This should be a WARN since it's likely to be an application, not a Wine, error. > apartment_release(info->apt); > info->apt = NULL; > } > diff --git a/dlls/ole32/ole2.c b/dlls/ole32/ole2.c > index 7929d3d..f078fb6 100644 > --- a/dlls/ole32/ole2.c > +++ b/dlls/ole32/ole2.c > @@ -186,6 +186,8 @@ HRESULT WINAPI DECLSPEC_HOTPATCH OleInitialize(LPVOID reserved) > > if (!COM_CurrentInfo()->ole_inits) > hr = S_OK; > + else > + hr = S_FALSE; > > /* > * Then, it has to initialize the OLE specific modules. > @@ -229,6 +231,11 @@ void WINAPI DECLSPEC_HOTPATCH OleUninitialize(void) > { > TRACE("()\n"); > > + if (COM_CurrentInfo()->ole_inits == 0) > + { > + WARN("ole_inits is already 0\n"); > + return ; > + } > /* > * If we hit the bottom of the lock stack, free the libraries. > */ > diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c > index 5fe9876..3ee5470 100644 > --- a/dlls/ole32/tests/compobj.c > +++ b/dlls/ole32/tests/compobj.c > @@ -2181,6 +2181,75 @@ static void test_CoInitializeEx(void) > OleUninitialize(); > } > > +static void test_OleInitialize_InitCounting(void) > +{ > + HRESULT hr; > + HANDLE thread; > + IUnknown *pUnk; > + REFCLSID rclsid = &CLSID_InternetZoneManager; > + IDataObject *pDObj; compobj.c: In function ‘test_OleInitialize_InitCounting’: compobj.c:2190: warning: unused variable ‘pDObj’ compobj.c:2187: warning: unused variable ‘thread’

2 1

Re: [PATCH 2/2] ntdll: Make avail_mode always TRUE for serial ports.
by Alexandre Julliard Jan. 15, 2016

Jan. 15, 2016

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Cc: Eric Pouech <eric.pouech(a)orange.fr> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > avail_mode controls whether a read operation is considered a success as > long as at least one byte can be read, or whether the operation is > considered pending until the total number of requested bytes has been > received. For serial ports, avail_mode was TRUE if read operations > always finished immediately, and FALSE if read operations did not finish > until data was available or the request timed out.[1] However, whether > or not a zero-byte read is considered a success has nothing to do with > whether or not a one-byte read is considered a success. > > Since serial ports are essentially hardware-based pipes, it makes sense > that they behave the same as software pipes and sockets. Pipes and sockets don't have comm timeouts, it's not at all obvious that they should be identical. This will need tests; at the very least a test app, if using the testbot isn't possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/3] bcrypt: Add support for SHA hashes on Linux using GnuTLS.
by Francois Gouget Jan. 15, 2016

Jan. 15, 2016

FreeBSD 8.1 is getting old and it shows up in the form of this error: gcc -c -o bcrypt_main.o bcrypt_main.c -I. -I../../include -I/usr/local/include -D__WINESRC__ -D_REENTRANT \ -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes \ -Wwrite-strings -Wpointer-arith -gdwarf-2 -fno-omit-frame-pointer -I/usr/local/include -g -O2 ../../tools/wrc/wrc -o version.res --nostdinc -I. -I../../include -I/usr/local/include -D__WINESRC__ \ version.rc bcrypt_main.c:55: error: 'gnutls_hash' undeclared here (not in a function) bcrypt_main.c:55: warning: type defaults to 'int' in declaration of 'pgnutls_hash' bcrypt_main.c:56: error: 'gnutls_hash_deinit' undeclared here (not in a function) bcrypt_main.c:56: warning: type defaults to 'int' in declaration of 'pgnutls_hash_deinit' bcrypt_main.c:57: error: 'gnutls_hash_init' undeclared here (not in a function) bcrypt_main.c:57: warning: type defaults to 'int' in declaration of 'pgnutls_hash_init' bcrypt_main.c:346: error: expected specifier-qualifier-list before 'gnutls_hash_hd_t' bcrypt_main.c: In function 'hash_init': bcrypt_main.c:378: error: 'struct hash' has no member named 'handle' bcrypt_main.c:378: error: called object 'pgnutls_hash_init' is not a function bcrypt_main.c: In function 'hash_update': bcrypt_main.c:384: error: 'struct hash' has no member named 'handle' bcrypt_main.c:384: error: called object 'pgnutls_hash' is not a function bcrypt_main.c: In function 'hash_finish': bcrypt_main.c:390: error: 'struct hash' has no member named 'handle' bcrypt_main.c:390: error: called object 'pgnutls_hash_deinit' is not a function In other words its gnutls 2.8.6 library is missing the gnutls_hash_xxx() functions. So this should probably be checked in the autoconf script. This should probably be a separate check as secur32 still compiles fine with gnutls support. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.

1 0

Re: shell32/tests: Arrange for the shell_execute{_ex}() calls to set the test line.
by Marvin Jan. 15, 2016

Jan. 15, 2016

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=19703 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2306: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde")]' shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: d3dx9_36: Fix a typo
by Matteo Bruni Jan. 14, 2016

Jan. 14, 2016

2016-01-13 1:19 GMT+01:00 Andrey Gusev <andrey.goosev(a)gmail.com>: Hi Andrey, - TRACE("Created ID3DBuffer %p\n", *buffer); + TRACE("Created ID3DXBuffer %p\n", *buffer); While you're there, can you also add a period at the end of the message? Also please use the "d3dx9:" prefix in the commit title.

1 0

Re: [PATCH 3/3] d3dx9: Add D3DXCreateAnimationController tests (try 3)
by Nikolay Sivov Jan. 14, 2016

Jan. 14, 2016

On 12.01.2016 10:34, Alistair Leslie-Hughes wrote: > +if (0) /* Windows crashes when animation is Released */ > +{ > + hr = D3DXCreateAnimationController(0, 0, 0, 0, &animation); > + ok(hr == D3D_OK, "Got unexpected hr returned %#x.\n", hr); > + animation->lpVtbl->Release(animation); > +} Is 'animation' NULL at this point by any chance?

3 2

Re: [PATCH 2/5] wined3d: Recognize SM4 resinfo opcode.
by Henri Verbeet Jan. 14, 2016

Jan. 14, 2016

On 12 January 2016 at 23:51, Józef Kucia <jkucia(a)codeweavers.com> wrote: > The _uint and _rcpFloat modifiers seems to be specific to the resinfo > instruction. AFAIK, there is one other instruction, SM 4.1 sampleinfo, > which also has _uint modifier. I think it may be better to store those as instruction flags in "ins->flags", the way e.g. WINED3DSI_TEXLD_PROJECT and WINED3DSI_TEXLD_BIAS are.

1 0