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

Wiki is being hammered by spammers
by Rosanne DiMesio Jan. 13, 2016

Jan. 13, 2016

In the past hour, I've restored the Front Page three times, and deleted over two dozen newly created spam pages. Earlier, Alexandre deleted many more spam pages. Something needs to be done now. -- Rosanne DiMesio dimesio(a)earthlink.net

9 10

Re: [PATCH] ole32: OleGetClipboard(): zero output interface pointer on error
by Nikolay Sivov Jan. 13, 2016

Jan. 13, 2016

On 13.01.2016 13:23, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/clipboard.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/ole32/clipboard.c b/dlls/ole32/clipboard.c > index ca9520f..b871bbc 100644 > --- a/dlls/ole32/clipboard.c > +++ b/dlls/ole32/clipboard.c > @@ -2201,6 +2201,7 @@ HRESULT WINAPI OleGetClipboard(IDataObject **obj) > TRACE("(%p)\n", obj); > > if(!obj) return E_INVALIDARG; > + *obj = NULL; > > if(FAILED(hr = get_ole_clipbrd(&clipbrd))) return hr; > Hi, Paul. This is to handle a case when OLE was not initialized, right? If so, it should be easy to add a test for it. It makes sense to zero it as a common convention for out interface pointers, but a test won't hurt.

2 4

Re: [2/4] gdi32: Fix the advance width in synthetic bold glyphs with scaling. (try 3)
by Marvin Jan. 13, 2016

Jan. 13, 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=19662 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: shell32/tests: Trace the effective ShellExecuteEx() flags.
by Marvin Jan. 13, 2016

Jan. 13, 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=19657 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:141: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec") WaitForSingleObject returned 258 shlexec.c:1570: Test failed: argvA3 expected 'Open', but key not found or empty shlexec.c:1578: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec', but key not found or empty shlexec.c:1570: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1578: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec' === w1064 (32 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2305: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde")]' shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: shell32/tests: Tweak some overly optimistic ok() messages.
by Marvin Jan. 13, 2016

Jan. 13, 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=19656 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2305: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde")]' shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: regsvr32/tests: Add initial tests
by Francois Gouget Jan. 13, 2016

Jan. 13, 2016

On Tue, 12 Jan 2016, Hugh McMaster wrote: [...] > diff --git a/programs/regsvr32/tests/Makefile.in b/programs/regsvr32/tests/Makefile.in > new file mode 100644 > index 0000000..61d25fe > --- /dev/null > +++ b/programs/regsvr32/tests/Makefile.in [...] > +ifneq (,$(filter crosstest mingw,$(MAKECMDGOALS) $(findstring mingw,$(CC)))) > + TARGET_DLLS = $(addsuffix .dll, $(DLL_BASENAMES)) I believe the syntax on these last two lines is specific to GNU make which is something that Wine has tried to avoid so far. Note that more generally getting a dll into this test will be pretty tricky. Would it be possible to do the tests using an existing dll? Alternatively would it work to add the test's dll to dlls/ and grab and include it as a resource in programs/regsvr32/tests? This may help avoid makefile shenanigans. > diff --git a/programs/regsvr32/tests/regsvr32.c b/programs/regsvr32/tests/regsvr32.c > new file mode 100644 > index 0000000..746c81f > --- /dev/null > +++ b/programs/regsvr32/tests/regsvr32.c [...] > +#define run_test(...) run_test_(output, &r, __VA_ARGS__) A macro with a variable argument list? That does not seem portable (or maybe is a > C99 feature). > +static BOOL __cdecl run_test_(char *output, DWORD *r, const char *fmt, ...) > +{ > + __ms_va_list va_args; Shouldn't this be using something like __winetest_va_list? To be checked... > +#define CMP(s) !strcmp(output, s) This macro is totally unnecessary. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 3

Re: [PATCH] comctl32/trackbar: Update thumb immediately on key press
by Marvin Jan. 13, 2016

Jan. 13, 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=19639 Your paranoid android. === wvistau64 (32 bit trackbar) === trackbar.c:682: Test failed: got 36, expected 36 === wvistau64 (64 bit trackbar) === trackbar.c:682: Test failed: got 36, expected 36

2 1

Re: [PATCH 1/2] dnsapi: migrating to res_nquery (try 2)
by Sebastian Lackner Jan. 13, 2016

Jan. 13, 2016

On 12.01.2016 20:55, Donat Enikeev wrote: > @@ -597,7 +609,9 @@ static DNS_STATUS dns_do_query( PCSTR name, WORD type, DWORD options, PDNS_RECOR > > DNS_RRSET_INIT( rrset ); > > - len = res_query( name, ns_c_in, type, answer, sizeof(answer) ); > + TRACE("Performing res_nquery(%p, %s, %u, %u, %p)\n", rs, name, type, options, result); Please use debugstr_a() when tracing untrusted values of arbitrary size. > + > + len = res_nquery( rs, name, ns_c_in, type, answer, sizeof(answer) ); > if (len < 0) > { > ret = dns_map_h_errno( h_errno );

1 0

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

Jan. 13, 2016

On Tue, 2016-01-12 at 22:55 +0300, Donat Enikeev wrote: This produces a warning on Mac OS: gcc -m32 -c -o query.o query.c -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 query.c:701:17: warning: format specifies type 'unsigned short' but the argument has type 'UCHAR' (aka 'unsigned char') [-Wformat] p_sockaddr->sin_addr.WS_s_impno, p_sockaddr->sin_addr.WS_s_lh, ^

1 0

Re: [PATCH 1/4] oleaut32: Add tests for safearray unmarshaling into passed variant
by Dmitry Timoshkov Jan. 13, 2016

Jan. 13, 2016

Hi Piotr, Piotr Caban <piotr(a)codeweavers.com> wrote: > @@ -1316,11 +1316,19 @@ static void test_marshal_VARIANT(void) > ok(*wirev, "wv[6] %08x\n", *wirev); /* win2k: this is lpsa. winxp: this is (char*)lpsa + 1 */ > wirev++; > check_safearray(wirev, lpsa); > - VariantInit(&v2); > + mem = CoTaskMemAlloc(1024); > + lpsa_copy = lpsa2 = SafeArrayCreate(VT_I8, 1, &sab); > + CoTaskMemFree(mem); > + mem = lpsa2->pvData; > + V_VT(&v2) = VT_UI4 | VT_ARRAY | VT_BYREF; > + V_ARRAYREF(&v2) = &lpsa2; Looks like the result of CoTaskMemAlloc/CoTaskMemFree is not used. -- Dmitry.

2 3

why are WineWindows NSPanels
by Theodore Dubois Jan. 13, 2016

Jan. 13, 2016

Hi, Why are WineWindows NSPanels, not NSWindows? I can see a disadvantage of this, which is that NSPanels don’t show up in Mission Control, but I can’t see the advantage. ~Theodore

2 1

Re: [PATCH 2/4] oleaut32: Set safearray pointer to NULL in LPSAFEARRAY_UserFree
by Marvin Jan. 12, 2016

Jan. 12, 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=19628 Your paranoid android. === w1064 (64 bit usrmarshal) === The test timed out

1 0

Re: [PATCH 2/2] winegstreamer: Always run gstreamer callbacks on a Wine thread
by Michael Stefaniuc Jan. 12, 2016

Jan. 12, 2016

Hello Andrew, On 01/11/2016 09:13 PM, Andrew Eikum wrote: > This gets winegstreamer with gstreamer-0.10 working for me again, > fixing Bug 30557. However, gstreamer-0.10 is no longer developed and > some distros don't ship it anymore. which distros are those? gstreamer-0.10 is still available in Fedora 23. I intend to pull this patch (or a version of it) into Stable. But I'd rather stick with the old gstreamer-0.10 then go to the new API; it is the smaller change. > I have more patches on top of this one to move winegstreamer to the > gstreamer-1.0 API. See Bug 31836. In order to avoid dependency churn > for packagers, I think it makes sense to apply them both during the > same release, so I intend to send those patches after this one is > accepted. If you prefer to review them all, I can send them all at > once. bye michael

3 4

Re: dwrite: Remove "crashes on native" tests that were already if(0)-ed. if(0)-ed.
by Nikolay Sivov Jan. 12, 2016

Jan. 12, 2016

On 12.01.2016 14:44, Gerald Pfeifer wrote: > I noticed those via the new -Wmisleading-indentation warnings. All > of these are tests that are disabled (if (0)) since they crash native. > > Am I missing something, or can we just remove them as dead code? There are disabled from the very beginning, and serve documentation purpose. > > (If not, okay to add braces for those cases not having them yet?) We try to avoid workarounds for static analyzers, and this warning is very similar in nature. I personally don't see a need of extra braces just to please it, but if it's decided that it's important to handle this warning for all wine code and if this warning will be actually on by default in gcc release, then sure, braces it is, instead of removing such blocks. > > Gerald >

1 0

Re: [PATCH 1/2] dnsapi: migrating to res_nquery (split resend)
by Hans Leidekker Jan. 12, 2016

Jan. 12, 2016

On Mon, 2016-01-11 at 22:07 +0300, Donat Enikeev wrote: > -static void initialise_resolver( void ) > +static res_state initialise_resolver( void ) > { > - if ((_res.options & RES_INIT) == 0) > - res_init(); > + res_state dns_res_state = NULL; No need to initialize this variable. Why the dns_ prefix on local variables? > + if ( !(dns_res_state = heap_alloc_zero(sizeof(struct __res_state))) ) > + return NULL; > + > + res_ninit(dns_res_state); > + > + return dns_res_state; > } > @@ -706,6 +719,7 @@ DNS_STATUS WINAPI DnsQuery_UTF8( PCSTR name, WORD type, DWORD options, PVOID ser > { > DNS_STATUS ret = DNS_ERROR_RCODE_NOT_IMPLEMENTED; > #ifdef HAVE_RESOLV > + res_state dns_res_state; > > TRACE( "(%s,%s,0x%08x,%p,%p,%p)\n", debugstr_a(name), dns_type_to_str( type ), > options, servers, result, reserved ); > @@ -713,13 +727,15 @@ DNS_STATUS WINAPI DnsQuery_UTF8( PCSTR name, WORD type, DWORD options, PVOID ser > if (!name || !result) > return ERROR_INVALID_PARAMETER; > > - initialise_resolver(); > - _res.options |= dns_map_options( options ); > + dns_res_state = initialise_resolver(); > + if ( !dns_res_state ) return ERROR_NOT_ENOUGH_MEMORY; > > - if (servers && (ret = dns_set_serverlist( servers ))) > + dns_res_state->options |= dns_map_options( options ); > + > + if (servers && (ret = dns_set_serverlist( dns_res_state, servers ))) > return ret; You are leaking dns_res_state here. > @@ -824,8 +842,9 @@ DNS_STATUS WINAPI DnsQueryConfig( DNS_CONFIG_TYPE config, DWORD flag, PCWSTR ada > case DnsConfigDnsServerList: > { > #ifdef HAVE_RESOLV > - initialise_resolver(); > - ret = dns_get_serverlist( buffer, len ); > + res_state dns_res_state = initialise_resolver(); > + ret = dns_get_serverlist( dns_res_state, buffer, len ); > + heap_free(dns_res_state); You should check the return value of initialise_resolver() here too.

1 0

Re: regsvr32/tests: Add initial tests
by Marvin Jan. 12, 2016

Jan. 12, 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=19620 Your paranoid android. === wxppro (32 bit dll) === No test summary line found === w2003std (32 bit dll) === No test summary line found === wvistau64 (32 bit dll) === No test summary line found === w2008s64 (32 bit dll) === No test summary line found === w7u (32 bit dll) === No test summary line found === w7pro64 (32 bit dll) === No test summary line found === w8 (32 bit dll) === No test summary line found === w864 (32 bit dll) === No test summary line found === w1064 (32 bit dll) === No test summary line found === wvistau64 (64 bit dll) === No test summary line found === w2008s64 (64 bit dll) === No test summary line found === w7pro64 (64 bit dll) === No test summary line found === w864 (64 bit dll) === No test summary line found === w1064 (64 bit dll) === No test summary line found

2 1

Re: [PATCH 2/2] winegstreamer: Always run gstreamer callbacks on a Wine thread
by Matteo Bruni Jan. 11, 2016

Jan. 11, 2016

2016-01-11 21:13 GMT+01:00 Andrew Eikum <aeikum(a)codeweavers.com>: Just happened to notice this while skimming the patch: > +GstBusSyncReply watch_bus_wrapper(GstBus *bus, GstMessage *msg, gpointer user) > +{ > + struct cb_data cbdata = { WATCH_BUS, > + { .watch_bus_data = { bus, msg, user} } > + }; I think designators are a C99 feature :/

1 0

ole32: OleInitialize/OleUnitialize behaves differently in Wine and Windows
by Paul Gofman Jan. 11, 2016

Jan. 11, 2016

OleInitialize/OleUnitialize behave differently in Wine and Windows (at least WinXP) in the following special case. The application thread has a multithreaded apartment initialized. Then OleInitialize is called from the same thread, followed by OleUnitialize call later. According to MSDN spec OleInitialize should return RPC_E_CHANGED_MODE (which is the case both in Windows and Wine) and OleUnitilize call should not be performed after that. If OleUnitilize is actually called (which is the case in the application), it presumably should uninitialize the COM apartment completely just as in case CoUnitialize (this is what Wine does). But this seems to be not the case under Windows. I am attaching a patch which adds such a test to ole32/tests/compobj. The test does CoInitializeEx(NULL, COINIT_MULTITHREADED), then OleInitialize, OleUninitialize and then tries to create COM object. The test fails under Wine (apartment not initialized) but passes OK under my WinXP virtual machine. If to change OleInitialize/OleUninitialize to CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)/CoUnitialize the test will fail both under Wine and Windows. The application works under Windows but crashes under Wine. I can tweak the application to work under Wine by, for instance, incrementing init counter in CoInitializeEx in ole32/compobj.c despite of returning RPC_E_CHANGED_MODE. So, the questions are: 1. Should I submit this test to wine-patches? 2. Is there some obvious way how can this be correctly fixed? E. g. it could potentially be fixed by adding some extra field to COM current info which would be checked in OleUninitialize not to allow the decrement of init counter by OleUnitialize below the value that was before first OleInit call, but I am not sure for now what Windows actually does. Maybe there are some known good ways how to explore this refcounting behaviour under Windows? If no, I could try to guess native behaviour by doing multiple CoInit/CoUninit/OleInit/OleUninit in different combinations followed by CoCreateInstance. Regards, Paul.

1 0

Re: shell32/tests: create_test_association() should either succeed or fail due to insufficient permissions.
by Marvin Jan. 11, 2016

Jan. 11, 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=19589 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:141: Test failed: ShellExecute(verb="QuotedUpperL", file="C:\Users\winetest\AppData\Local\Temp\wtD538.tmp\test file.shlexec") WaitForSingleObject returned 258 shlexec.c:1567: Test failed: argvA3 expected 'QuotedUpperL', but key not found or empty shlexec.c:1575: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD538.tmp\test file.shlexec', but key not found or empty === w1064 (32 bit shlexec) === shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1306.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1306.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1306.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1306.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2301: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde")]' shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2289: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt72F2.tmp\test file.sde") failed: rc=29 err=2

2 1

Re: mshtml: Skip unused named args in Invoke calls.
by Marvin Jan. 11, 2016

Jan. 11, 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=19615 Your paranoid android. === w8 (32 bit script) === script.c:632: Test failed: L"extern_res_script_rs = loaded0,eval,complete1, expected eval,complete1," === w864 (32 bit script) === script.c:632: Test failed: L"extern_res_script_rs = loaded0,eval,complete1, expected eval,complete1,"

1 0

Backup of wiki.winehq.org?
by Michael Stefaniuc Jan. 11, 2016

Jan. 11, 2016

Hello Dimi, do you have a recent backup of wiki.winehq.org? The bloody spammers went nuts and even renamed the FrontPage to one of their spammer pages... I tried to move it back but MoinMoin didn't let me as it generated a new standard FrontPage. And it seems I have removed by mistake our real FrontPage before I could copy and paste its content over :( So could you please restore the FrontPage from the backup? While you are at it please block those 3 accounts used by the spammer(s). thanks bye michael

3 4

Re: [PATCH] d3dx9/test: magic isn't part of the dds structure
by Józef Kucia Jan. 11, 2016

Jan. 11, 2016

On Mon, Jan 11, 2016 at 10:46 AM, Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3dx9_36/tests/surface.c | 19 ++++++++++++------- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c > index 183086f..5a20658 100644 > --- a/dlls/d3dx9_36/tests/surface.c > +++ b/dlls/d3dx9_36/tests/surface.c > @@ -200,7 +200,6 @@ struct dds_pixel_format > > struct dds_header > { > - DWORD magic; > DWORD size; > DWORD flags; > DWORD height; > @@ -222,7 +221,6 @@ static void fill_dds_header(struct dds_header *header) > { > memset(header, 0, sizeof(*header)); > > - header->magic = MAKEFOURCC('D','D','S',' '); > header->size = sizeof(*header); > header->flags = DDS_CAPS | DDS_WIDTH | DDS_HEIGHT | DDS_PIXELFORMAT; > header->height = 4; > @@ -250,10 +248,12 @@ static void check_dds_pixel_format_(unsigned int > line, > D3DXIMAGE_INFO info; > struct > { > + DWORD magic; > struct dds_header header; > BYTE data[256]; > } dds; > > + dds.magic = MAKEFOURCC('D','D','S',' '); > fill_dds_header(&dds.header); > dds.header.pixel_format.flags = flags; > dds.header.pixel_format.fourcc = fourcc; > @@ -281,6 +281,7 @@ static void test_dds_header_handling(void) > D3DXIMAGE_INFO info; > struct > { > + DWORD magic; > struct dds_header header; > BYTE data[4096 * 1024]; > } *dds; > @@ -399,9 +400,10 @@ static void test_dds_header_handling(void) > > for (i = 0; i < sizeof(tests) / sizeof(tests[0]); i++) > { > - DWORD file_size = sizeof(dds->header) + tests[i].pixel_data_size; > + DWORD file_size = sizeof(dds->magic) + sizeof(dds->header) + > tests[i].pixel_data_size; > assert(file_size <= sizeof(*dds)); > > + dds->magic = MAKEFOURCC('D','D','S',' '); > fill_dds_header(&dds->header); > dds->header.flags |= tests[i].flags; > dds->header.width = tests[i].width; > @@ -1235,6 +1237,7 @@ static void > test_D3DXSaveSurfaceToFileInMemory(IDirect3DDevice9 *device) > ID3DXBuffer *buffer; > IDirect3DSurface9 *surface; > struct dds_header *header; > + BYTE *data; > > hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 4, 4, > D3DFMT_A8R8G8B8, D3DPOOL_SCRATCH, &surface, NULL); > if (FAILED(hr)) { > @@ -1257,9 +1260,10 @@ static void > test_D3DXSaveSurfaceToFileInMemory(IDirect3DDevice9 *device) > todo_wine ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr); > if (SUCCEEDED(hr)) > { > - header = ID3DXBuffer_GetBufferPointer(buffer); > + data = ID3DXBuffer_GetBufferPointer(buffer); > + header = (struct dds_header *)(data + sizeof(DWORD)); > > - ok(header->magic == MAKEFOURCC('D','D','S',' '), "Invalid DDS > signature.\n"); > + ok( *(DWORD*)data == MAKEFOURCC('D','D','S',' '), "Invalid DDS > signature.\n"); > ok(header->size == 124, "Invalid DDS size %u.\n", header->size); > ok(!header->height, "Got unexpected height %u.\n", > header->height); > ok(!header->width, "Got unexpected width %u.\n", header->width); > @@ -1274,9 +1278,10 @@ static void > test_D3DXSaveSurfaceToFileInMemory(IDirect3DDevice9 *device) > > hr = D3DXSaveSurfaceToFileInMemory(&buffer, D3DXIFF_DDS, surface, > NULL, NULL); > ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr); > - header = ID3DXBuffer_GetBufferPointer(buffer); > > - ok(header->magic == MAKEFOURCC('D','D','S',' '), "Invalid DDS > signature.\n"); > + data = ID3DXBuffer_GetBufferPointer(buffer); > + header = (struct dds_header *)(data + sizeof(DWORD)); > + ok( *(DWORD*)data == MAKEFOURCC('D','D','S',' '), "Invalid DDS > signature.\n"); > ok(header->size == 124, "Invalid DDS size %u.\n", header->size); > ok(header->height == 4, "Got unexpected height %u.\n", > header->height); > ok(header->width == 4, "Got unexpected width %u.\n", header->width); > -- > 2.6.4 > > > > What's the point of this change? It doesn't fix anything and doesn't make code more readable. If the file signature isn't included in the DDS header size it doesn't necessarily mean we have to move it out of struct dds_header.

2 1

Re: [PATCH 2/3] xaudio2_7: Move source to shared xaudio2 directory
by Alistair Leslie-Hughes Jan. 11, 2016

Jan. 11, 2016

Hi Andrew, On 09/01/16 04:03, Andrew Eikum wrote: > Currently, all of Wine's xaudio2 modules forward their implementations > to xaudio2_7. This fails when the user installs native xaudio2_7 and > tries to use a built-in xaudio DLL like xaudio2_8. Instead, we should > use the shared source mechanism to build each xaudio DLL independent > of the others. > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > > This is the first patch in a long series to move all 22 xaudio DLLs to > use shared source. These first two show the idea; the following > patches move all xaudio2_* DLLs, then xapofx1_*, then x3daudio1_*. > Next, there are a few cleanup patches to remove the run-time version > logic, since we can now do it at compile-time. > > dlls/{xaudio2_7 => xaudio2}/compat.c | 0 > dlls/{xaudio2_7 => xaudio2}/xapofx.c | 0 > dlls/{xaudio2_7 => xaudio2}/xaudio_classes.idl | 0 > dlls/{xaudio2_7 => xaudio2}/xaudio_dll.c | 0 > dlls/{xaudio2_7 => xaudio2}/xaudio_private.h | 0 > dlls/xaudio2_7/Makefile.in | 2 ++ > 6 files changed, 2 insertions(+) Whats the reason behind moving the source into a separate directory? It's not needed, have a look d3dcompiler_46 which uses the source in d3dcompiler_43. If you have main.c in each directory the build script is smart enough to compile the correct one, if that is your concern. Best Regards Alistair Leslie-Hughes

3 2

Re: shell32/tests: Check the hProcess field when ShellExecuteEx() fails.
by Marvin Jan. 11, 2016

Jan. 11, 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=19588 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt2A18.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt2A18.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt2A18.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt2A18.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2302: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde")]' shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2290: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtFF28.tmp\test file.sde") failed: rc=29 err=2

2 1

Re: [1/2] bcrypt: Add support for SHA hashes on Linux using Nettle.
by Damjan Jovanovic Jan. 11, 2016

Jan. 11, 2016

Hi I don't believe it's possible to use Nettle in Wine right now, due to its copyright license: "Nettle is dual licenced under the GNU General Public License version 2 or later, and the GNU Lesser General Public License version 3 or later. When using Nettle, you must comply fully with all conditions of at least one of these licenses." ( http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright) Wine is only LGPLv2+, which isn't compatible with either. Besides, why not GnuTLS or Mozilla's NSS? Regards Damjan On Mon, Jan 11, 2016 at 12:25 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > v2: Load Nettle dynamically. > > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > configure.ac | 13 +++ > dlls/bcrypt/Makefile.in | 1 + > dlls/bcrypt/bcrypt_main.c | 199 > ++++++++++++++++++++++++++++++++++++++++++++-- > 3 files changed, 208 insertions(+), 5 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 2b1dd81..32b09ad 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -60,6 +60,7 @@ AC_ARG_WITH(ldap, > AS_HELP_STRING([--without-ldap],[do not use LDAP]), > [if test "x$withval" = "xno"; then ac_cv_header_ldap_h=no; > ac_cv_header_lber_h=no; fi]) > AC_ARG_WITH(mpg123, AS_HELP_STRING([--without-mpg123],[do not use the > mpg123 library])) > AC_ARG_WITH(netapi, AS_HELP_STRING([--without-netapi],[do not use the > Samba NetAPI library])) > +AC_ARG_WITH(nettle, AS_HELP_STRING([--without-nettle],[do not use > Nettle])) > AC_ARG_WITH(openal, AS_HELP_STRING([--without-openal],[do not use > OpenAL]), > [if test "x$withval" = "xno"; then ac_cv_header_AL_al_h=no; > ac_cv_header_OpenAL_al_h=no; fi]) > AC_ARG_WITH(opencl, AS_HELP_STRING([--without-opencl],[do not use > OpenCL]), > @@ -1274,6 +1275,18 @@ fi > WINE_WARNING_WITH(gnutls,[test "x$ac_cv_lib_soname_gnutls" = "x"], > [libgnutls ${notice_platform}development files not > found, no schannel support.]) > > +dnl **** Check for libnettle *** > +if test "x$with_nettle" != "xno" > +then > + WINE_PACKAGE_FLAGS(NETTLE,[nettle],,,, > + [AC_CHECK_HEADER([nettle/sha2.h], > + > [WINE_CHECK_SONAME(nettle,nettle_sha512_init,,[NETTLE_CFLAGS=""],[$NETTLE_LIBS])], > + [NETTLE_CFLAGS=""])]) > +fi > +WINE_WARNING_WITH(nettle,[test "x$ac_cv_lib_soname_nettle" = "x" -a \ > + > "x$ac_cv_header_CommonCrypto_CommonDigest_h" != "xyes"], > + [libnettle ${notice_platform}development files not > found, no crypto support (bcrypt).]) > + > dnl **** Check which curses lib to use *** > CURSES_LIBS="" > if test "$ac_cv_header_ncurses_h" = "yes" > diff --git a/dlls/bcrypt/Makefile.in b/dlls/bcrypt/Makefile.in > index 87e1429..e83cbab 100644 > --- a/dlls/bcrypt/Makefile.in > +++ b/dlls/bcrypt/Makefile.in > @@ -1,5 +1,6 @@ > MODULE = bcrypt.dll > IMPORTS = advapi32 > +EXTRAINCL = $(NETTLE_CFLAGS) > > C_SRCS = \ > bcrypt_main.c > diff --git a/dlls/bcrypt/bcrypt_main.c b/dlls/bcrypt/bcrypt_main.c > index 9cc5227..e66a70f 100644 > --- a/dlls/bcrypt/bcrypt_main.c > +++ b/dlls/bcrypt/bcrypt_main.c > @@ -18,10 +18,14 @@ > */ > > #include "config.h" > +#include "wine/port.h" > > #include <stdarg.h> > #ifdef HAVE_COMMONCRYPTO_COMMONDIGEST_H > #include <CommonCrypto/CommonDigest.h> > +#elif defined(SONAME_LIBNETTLE) > +#include <nettle/sha1.h> > +#include <nettle/sha2.h> > #endif > > #include "ntstatus.h" > @@ -32,10 +36,73 @@ > #include "bcrypt.h" > > #include "wine/debug.h" > +#include "wine/library.h" > #include "wine/unicode.h" > > WINE_DEFAULT_DEBUG_CHANNEL(bcrypt); > > +static HINSTANCE instance; > + > +#if defined(SONAME_LIBNETTLE) && > !defined(HAVE_COMMONCRYPTO_COMMONDIGEST_H) > +WINE_DECLARE_DEBUG_CHANNEL(winediag); > + > +static void *libnettle_handle; > +#define MAKE_FUNCPTR(f) static typeof(f) * p##f > +MAKE_FUNCPTR(nettle_sha1_init); > +MAKE_FUNCPTR(nettle_sha256_init); > +MAKE_FUNCPTR(nettle_sha384_init); > +MAKE_FUNCPTR(nettle_sha512_init); > +MAKE_FUNCPTR(nettle_sha1_update); > +MAKE_FUNCPTR(nettle_sha256_update); > +MAKE_FUNCPTR(nettle_sha512_update); > +MAKE_FUNCPTR(nettle_sha1_digest); > +MAKE_FUNCPTR(nettle_sha256_digest); > +MAKE_FUNCPTR(nettle_sha384_digest); > +MAKE_FUNCPTR(nettle_sha512_digest); > +#undef MAKE_FUNCPTR > + > +static BOOL nettle_init(void) > +{ > + if (!(libnettle_handle = wine_dlopen( SONAME_LIBNETTLE, RTLD_NOW, > NULL, 0 ))) > + { > + ERR_(winediag)( "failed to load libnettle, no crypto support\n" ); > + return FALSE; > + } > + > +#define LOAD_FUNCPTR(f) \ > + if (!(p##f = wine_dlsym( libnettle_handle, #f, NULL, 0 ))) \ > + { \ > + ERR( "failed to load %s\n", #f ); \ > + goto fail; \ > + } > + > + LOAD_FUNCPTR(nettle_sha1_init) > + LOAD_FUNCPTR(nettle_sha256_init) > + LOAD_FUNCPTR(nettle_sha384_init) > + LOAD_FUNCPTR(nettle_sha512_init) > + LOAD_FUNCPTR(nettle_sha1_update) > + LOAD_FUNCPTR(nettle_sha256_update) > + LOAD_FUNCPTR(nettle_sha512_update) > + LOAD_FUNCPTR(nettle_sha1_digest) > + LOAD_FUNCPTR(nettle_sha256_digest) > + LOAD_FUNCPTR(nettle_sha384_digest) > + LOAD_FUNCPTR(nettle_sha512_digest) > +#undef LOAD_FUNCPTR > + return TRUE; > + > +fail: > + wine_dlclose( libnettle_handle, NULL, 0 ); > + libnettle_handle = NULL; > + return FALSE; > +} > + > +static void nettle_deinit(void) > +{ > + wine_dlclose( libnettle_handle, NULL, 0 ); > + libnettle_handle = NULL; > +} > +#endif /* SONAME_LIBNETTLE && !HAVE_COMMONCRYPTO_COMMONDIGEST_H */ > + > NTSTATUS WINAPI BCryptEnumAlgorithms(ULONG dwAlgOperations, ULONG > *pAlgCount, > BCRYPT_ALGORITHM_IDENTIFIER > **ppAlgList, ULONG dwFlags) > { > @@ -203,7 +270,7 @@ static NTSTATUS hash_init( struct hash *hash ) > return STATUS_SUCCESS; > } > > -static void hash_update( struct hash *hash, UCHAR *input, ULONG size ) > +static NTSTATUS hash_update( struct hash *hash, UCHAR *input, ULONG size ) > { > switch (hash->alg_id) > { > @@ -225,8 +292,9 @@ static void hash_update( struct hash *hash, UCHAR > *input, ULONG size ) > > default: > ERR( "unhandled id %u\n", hash->alg_id ); > - break; > + return STATUS_NOT_IMPLEMENTED; > } > + return STATUS_SUCCESS; > } > > static NTSTATUS hash_finish( struct hash *hash, UCHAR *output, ULONG size > ) > @@ -255,6 +323,105 @@ static NTSTATUS hash_finish( struct hash *hash, > UCHAR *output, ULONG size ) > } > return STATUS_SUCCESS; > } > +#elif defined(SONAME_LIBNETTLE) > +struct hash > +{ > + struct object hdr; > + enum alg_id alg_id; > + union > + { > + struct sha1_ctx sha1_ctx; > + struct sha256_ctx sha256_ctx; > + struct sha512_ctx sha512_ctx; > + } u; > +}; > + > +static NTSTATUS hash_init( struct hash *hash ) > +{ > + if (!libnettle_handle) return STATUS_NOT_IMPLEMENTED; > + > + switch (hash->alg_id) > + { > + case ALG_ID_SHA1: > + pnettle_sha1_init( &hash->u.sha1_ctx ); > + break; > + > + case ALG_ID_SHA256: > + pnettle_sha256_init( &hash->u.sha256_ctx ); > + break; > + > + case ALG_ID_SHA384: > + pnettle_sha384_init( &hash->u.sha512_ctx ); > + break; > + > + case ALG_ID_SHA512: > + pnettle_sha512_init( &hash->u.sha512_ctx ); > + break; > + > + default: > + ERR( "unhandled id %u\n", hash->alg_id ); > + return STATUS_NOT_IMPLEMENTED; > + } > + return STATUS_SUCCESS; > +} > + > +static NTSTATUS hash_update( struct hash *hash, UCHAR *input, ULONG size ) > +{ > + if (!libnettle_handle) return STATUS_NOT_IMPLEMENTED; > + > + switch (hash->alg_id) > + { > + case ALG_ID_SHA1: > + pnettle_sha1_update( &hash->u.sha1_ctx, size, input ); > + break; > + > + case ALG_ID_SHA256: > + pnettle_sha256_update( &hash->u.sha256_ctx, size, input ); > + break; > + > + case ALG_ID_SHA384: > + pnettle_sha512_update( &hash->u.sha512_ctx, size, input ); > + break; > + > + case ALG_ID_SHA512: > + pnettle_sha512_update( &hash->u.sha512_ctx, size, input ); > + break; > + > + default: > + ERR( "unhandled id %u\n", hash->alg_id ); > + return STATUS_NOT_IMPLEMENTED; > + } > + return STATUS_SUCCESS; > +} > + > +static NTSTATUS hash_finish( struct hash *hash, UCHAR *output, ULONG size > ) > +{ > + if (!libnettle_handle) return STATUS_NOT_IMPLEMENTED; > + > + switch (hash->alg_id) > + { > + case ALG_ID_SHA1: > + pnettle_sha1_digest( &hash->u.sha1_ctx, size, output ); > + break; > + > + case ALG_ID_SHA256: > + pnettle_sha256_digest( &hash->u.sha256_ctx, size, output ); > + break; > + > + case ALG_ID_SHA384: > + pnettle_sha384_digest( &hash->u.sha512_ctx, size, output ); > + break; > + > + case ALG_ID_SHA512: > + pnettle_sha512_digest( &hash->u.sha512_ctx, size, output ); > + break; > + > + default: > + ERR( "unhandled id %u\n", hash->alg_id ); > + return STATUS_NOT_IMPLEMENTED; > + } > + return STATUS_SUCCESS; > +} > #else > struct hash > { > @@ -268,9 +435,10 @@ static NTSTATUS hash_init( struct hash *hash ) > return STATUS_NOT_IMPLEMENTED; > } > > -static void hash_update( struct hash *hash, UCHAR *input, ULONG size ) > +static NTSTATUS hash_update( struct hash *hash, UCHAR *input, ULONG size ) > { > ERR( "support for hashes not available at build time\n" ); > + return STATUS_NOT_IMPLEMENTED; > } > > static NTSTATUS hash_finish( struct hash *hash, UCHAR *output, ULONG size > ) > @@ -484,8 +652,7 @@ NTSTATUS WINAPI BCryptHashData( BCRYPT_HASH_HANDLE > handle, UCHAR *input, ULONG s > if (!hash || hash->hdr.magic != MAGIC_HASH) return > STATUS_INVALID_HANDLE; > if (!input) return STATUS_INVALID_PARAMETER; > > - hash_update( hash, input, size ); > - return STATUS_SUCCESS; > + return hash_update( hash, input, size ); > } > > NTSTATUS WINAPI BCryptFinishHash( BCRYPT_HASH_HANDLE handle, UCHAR > *output, ULONG size, ULONG flags ) > @@ -499,3 +666,25 @@ NTSTATUS WINAPI BCryptFinishHash( BCRYPT_HASH_HANDLE > handle, UCHAR *output, ULON > > return hash_finish( hash, output, size ); > } > + > +BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID reserved ) > +{ > + switch (reason) > + { > + case DLL_PROCESS_ATTACH: > + instance = hinst; > + DisableThreadLibraryCalls( hinst ); > +#if defined(SONAME_LIBNETTLE) && > !defined(HAVE_COMMONCRYPTO_COMMONDIGEST_H) > + nettle_init(); > +#endif > + break; > + > + case DLL_PROCESS_DETACH: > + if (reserved) break; > +#if defined(SONAME_LIBNETTLE) && > !defined(HAVE_COMMONCRYPTO_COMMONDIGEST_H) > + nettle_deinit(); > +#endif > + break; > + } > + return TRUE; > +} > -- > 2.6.4 > > > >

3 2

Re: [PATCH 1/2] dnsapi: migrating to res_nquery and partial DnsQueryEx implementation
by Hans Leidekker Jan. 11, 2016

Jan. 11, 2016

On Sun, 2016-01-10 at 16:55 +0300, Donat Enikeev wrote: > There was a note about res_query bug in MacOSX 10.4: > /* call res_init() just once because of a bug in Mac OS X 10.4, call once per thread on systems that have per-thread _res */ > > I've removed it while migratign to res_nquery, let me please clarify reasons: > > 1. I found no proof that bug is fair for res_nquery for MacOSX 10.4 > 2. I believe that generally res_init was not designed to be reliable under several calls > Quote from manual: "res_init() and res_query() use some static (global) state stored in the _res structure, rendering these functions non-thread-safe" That information is outdated, _res is a per-thread variable on modern systems. In any case, you should put the implementation of DnsQueryEx in a separate patch.

1 0

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled (try 2)
by Qian Hong Jan. 11, 2016

Jan. 11, 2016

The patch looks good to me, Aric, would you mind sign off the patch? I'm glad to sign off, but I'm not qualified enough :) On Tue, Dec 29, 2015 at 11:19 AM, Changhui LIU <liuchanghui(a)linuxdeepin.com> wrote: > Superseded patch 117285. > > Try 2: Fixed IRP completion event will not be signaled if a driver is > misbehaving and is blocked or crashes while processing an IRP. > -- Regards, Qian Hong - http://www.winehq.org

5 7

Re: shell32/tests: Fix the shortcut vs. class interaction test.
by Marvin Jan. 11, 2016

Jan. 11, 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=19590 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt11FC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt11FC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt11FC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt11FC.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2300: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde")]' shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt7F55.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: shell32/tests: The expectedArgs parameter of the DDE tests is an argument count, not a boolean.
by Marvin Jan. 11, 2016

Jan. 11, 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=19587 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde")]' shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE3FF.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1846.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1846.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1846.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1846.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: [01/12] shell32/tests: The expectedArgs parameter of the DDE tests is an argument count, not a boolean.
by Marvin Jan. 11, 2016

Jan. 11, 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=19403 Your paranoid android. === wxppro (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w2003std (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === wvistau64 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w2008s64 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w7u (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w7pro64 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w8 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w864 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w1064 (32 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde")]' shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtE4CD.tmp\test file.sde") failed: rc=29 err=2 === wvistau64 (64 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w2008s64 (64 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w7pro64 (64 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w864 (64 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 === w1064 (64 bit shlexec) === shlexec.c:2294: Test failed: argcA expected 3, but got 4 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt91AC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt91AC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt91AC.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt91AC.tmp\test file.sde") failed: rc=29 err=2

3 3

Re: [PATCH] avifil32: Use typed pointers in sizeof() (Coverity)
by Bruno Jesus Jan. 10, 2016

Jan. 10, 2016

On Sun, Jan 10, 2016 at 10:35 PM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/avifil32/api.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/api.c b/dlls/avifil32/api.c > index c71efb4..a88e3bf 100644 > --- a/dlls/avifil32/api.c > +++ b/dlls/avifil32/api.c > @@ -2332,8 +2332,8 @@ HRESULT WINAPIV AVISaveW(LPCWSTR szFile, CLSID * pclsidHandler, AVISAVECALLBACK > > if (nStreams <= 0) return AVIERR_BADPARAM; > > - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *)); > - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *)); > + streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*streams)); > + options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*options)); Hi, Nikolay. What about AviSaveA? The structure of code is identical. Also in the loop I used void * to get the next arg from the list, could that be a problem? Best wishes, Bruno

2 1

Re: winhttp: Avoid -Wmisleading-indentation warning in test_IWinHttpRequest_Invoke.
by Nikolay Sivov Jan. 10, 2016

Jan. 10, 2016

On 10.01.2016 14:26, Gerald Pfeifer wrote: > This is a bit unusual formatting, though I understand where it's coming > from. Adding braces silences GCC 6's new -Wmisleading-indentation. > > Gerald > > Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> > --- > dlls/winhttp/tests/winhttp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index d676dd8..1408f35 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -3820,8 +3820,9 @@ static void test_IWinHttpRequest_Invoke(void) > ok(hr == DISP_E_UNKNOWNINTERFACE, "error %#x\n", hr); > > VariantInit(&ret); > -if (0) /* crashes */ > +if (0) /* crashes */ { > hr = IWinHttpRequest_Invoke(request, DISPID_HTTPREQUEST_OPTION, &IID_NULL, 0, DISPATCH_PROPERTYPUT, NULL, &ret, NULL, &err); > +} > > params.cArgs = 1; > hr = IWinHttpRequest_Invoke(request, DISPID_HTTPREQUEST_OPTION, &IID_NULL, 0, DISPATCH_PROPERTYPUT, &params, &ret, NULL, &err); > I think we have tons of those, I myself almost always use todo_wine this way, to reduce diff that remove todo_wine when implementation is fixed. Actually not sure if todo_wine will trigger this check, does it?

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 10).
by Stefan Dösinger Jan. 9, 2016

Jan. 9, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-04 um 18:51 schrieb Aaryaman Vasishta: > + file_header.bfSize = ((((w * bpp + 31) & ~31) >> 3) * h) + > file_header.bfOffBits; This suggests (if I understand it right) that the on-disk bmp is written with 4 byte aligned rows (i.e., similar to bytes_per_line being 4 byte aligned in some cases). The actual image you generate doesn't match that though, so you have some unused data at the end. It's possible that this size alignment is necessary though. Why are you using it instead of just using w * h * (bpp / 8)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWkEqmAAoJEN0/YqbEcdMwKhEP/2OjRx6dtXxfqOoLPFb6687p cOBr5nCzJYMHKvNL1yD1Wb1T3jNjQWduOpAuUZV9QfcEsOzwYpMAO0wprFslNEVo r/aPwMnAAjjW/xXQD30s4McXKIdRQdo7myXbVbtyv4n7+PG4ROaHrqxdAcIyEAHe 1APXsX3hXXVSBxxeSwFDxQlos+50T0AmGZOjJL3gK0dZt8yu/Wokk6iuVrSERuu2 x/D2mtOEbhpu2i4YXbgHMAEXayxYr/t+88PC8StAb6CicM4LmbNGNG8JAFrSW+q5 AoXreMs5aM4jjvOrCL/lDYADDzgN/M41eT5vYNAv6KWGA57upAhENg5ar+ukhi9l QiDsjPDL64LfZtTaRrxV76PCBMoP/BVMhumtY0TCu8QvvxuKCFcIQ+5LHExt+Q2l XmF5woFzCtgVI8P4KTCU3eWi+QT5+TSgGQqHd7VrK6qRI7Jc/fh6JpQxrOo0x+j7 wJPS3uk99IcCwh2w0Z8jA3oiCEOKpxfjb8EP4udyVN6BsPX2qKcyQ/lRJJRHOuQi rEkTV8Vy0MC1WC6rfNaOeWphyNvsbzP0lm8sNjgxDjSb8egr507aTkjJxE8AsrCP F+nUMg336lM5Ww/VCAYaw8jVaCRnKcsuoPDulaHPG3Te6pa0BFzM4+6eWFAK0xz+ sLFNfCkHNgGDKHoubKnL =SEdW -----END PGP SIGNATURE-----

2 1

Re: [PATCH] quartz: Handle NULL target format in FilterGraph::ConvertTimeFormat. (try 2)
by Nikolay Sivov Jan. 9, 2016

Jan. 9, 2016

Looks good, thanks.

1 0

Re: winedbg: Add disassembly_flavor option to use the intel disassembly style like gdb's disassembly-flavor option.
by Michael Müller Jan. 8, 2016

Jan. 8, 2016

Am 08.01.2016 um 04:28 schrieb Changhui LIU: > The disassembler source is cloned from https://github.com/vmt/udis86. > It is Simplified BSD License. I think your code has a much higher probability in getting accepted if you do not fork the source code but instead link dynamically or statically against this library, i.e. search for the library in configure.ac. I have to admit though that not many distros seem to ship the library as package. You should also put your implementation into #if defined(__i386__) || defined(__amd64__) blocks since Wine also supports other architectures like ARM which are not supported by udis86. The option should be unavailable on these platforms and it also does not make much sense to link against the library in this case. Regards, Michael

1 0

Re: [PATCH 1/3] d3dx9: Implement D3DXCreateAnimationController with a stubbed ID3DXAnimationController interface. (try 2)
by Matteo Bruni Jan. 8, 2016

Jan. 8, 2016

2016-01-06 3:52 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Correct QI to be like the IDevice11 one. > Changed DOUBLE to double in the interface. > Adjusted parameter names in D3DXCreateAnimationController > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > +static inline struct d3dx9_animation_controller *impl_from_ID3DXAnimationController(ID3DXAnimationController *iface) Not a big deal but I think it's better to avoid the "inline" here, it's unnecessary in this case since the function isn't in a .h file. > +static HRESULT WINAPI d3dx9_animation_controller_AdvanceTime(ID3DXAnimationController *iface, double time_delta, > + ID3DXAnimationCallbackHandler **callback_handler) I think callback_handler only wants one '*' here. > +static HRESULT WINAPI d3dx9_animation_controller_GetTrackPriority(ID3DXAnimationController *iface, > + UINT track, D3DXPRIORITY_TYPE *priority) This one should be called SetTrackPriority, at least according to the header from the June 2010 DirectX SDK. The header currently in Wine has the same GetTrackPriority prototype you used here (it's there since the header was first introduced by Dylan Smith in 5cccad1311745117628b9a5f10652b5211151b51). I guess this is simply a typo in our header and it "propagated" here but if anyone knows better please speak up ;) Quite reasonably, in a sense, the "priority" parameter for the SetTrackPriority method is not supposed to be a pointer. > +static HRESULT WINAPI d3dx9_animation_controller_SetTrackPosition(ID3DXAnimationController *iface, > + UINT track, double position) > +{ > + FIXME("iface %p, track %u, position %g stub.\n", iface, track, position); It doesn't seem a good choice to me to use %g instead of %f for double parameters. > +static HRESULT WINAPI d3dx9_animation_controller_SetTrackEnable(ID3DXAnimationController *iface, > + UINT track, BOOL enable) > +{ > + FIXME("iface %p, track %u, enable %u stub.\n", iface, track, enable); BOOL is defined as long i.e. signed. > +static D3DXEVENTHANDLE WINAPI d3dx9_animation_controller_GetUpcomingPriorityBlend(ID3DXAnimationController *iface, > + D3DXEVENTHANDLE handle) > +{ > + FIXME("iface %p, handle %u stub.\n", iface, handle); Not too important but you called all the other occurrences "event" instead of "handle". > +static HRESULT WINAPI d3dx9_animation_controller_CloneAnimationController(ID3DXAnimationController *iface, UINT max_num_anim_outputs, > + UINT max_num_anim_sets, UINT max_num_tracks, UINT max_num_events, ID3DXAnimationController **anim_controller) You can probably drop the "num_" part of those parameter names for brevity.

2 2

Re: [PATCH 1/4] include: Add declarations for D3DUSAGEs added with d3d9ex.
by Henri Verbeet Jan. 8, 2016

Jan. 8, 2016

On 7 January 2016 at 16:22, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +/* Parts added with d3d9ex */ > +#if !defined(D3D_DISABLE_9EX) > +#define D3DUSAGE_RESTRICTED_CONTENT __MSABI_LONG(0x00000800) > +#define D3DUSAGE_RESTRICT_SHARED_RESOURCE_DRIVER __MSABI_LONG(0x00001000) > +#define D3DUSAGE_RESTRICT_SHARED_RESOURCE __MSABI_LONG(0x00002000) > +#define D3DUSAGE_TEXTAPI __MSABI_LONG(0x10000000) That's a bit of a problem, D3DUSAGE_TEXTAPI conflicts with WINED3DUSAGE_TEXTURE. These would also get masked out by WINED3DUSAGE_MASK.

2 1

Re: [PATCH] comctl32: Update Thumb Rect when position changes
by Nikolay Sivov Jan. 8, 2016

Jan. 8, 2016

On 08.01.2016 10:33, Alistair Leslie-Hughes wrote: > --- > dlls/comctl32/trackbar.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/trackbar.c b/dlls/comctl32/trackbar.c > index 6d092a3..3a92794 100644 > --- a/dlls/comctl32/trackbar.c > +++ b/dlls/comctl32/trackbar.c > @@ -1225,13 +1225,17 @@ TRACKBAR_SetPos (TRACKBAR_INFO *infoPtr, BOOL fPosition, LONG lPosition) > infoPtr->lPos = lPosition; > > if (infoPtr->lPos < infoPtr->lRangeMin) > - infoPtr->lPos = infoPtr->lRangeMin; > + infoPtr->lPos = infoPtr->lRangeMin; > > if (infoPtr->lPos > infoPtr->lRangeMax) > - infoPtr->lPos = infoPtr->lRangeMax; > + infoPtr->lPos = infoPtr->lRangeMax; > infoPtr->flags |= TB_THUMBPOSCHANGED; > > - if (fPosition && oldPos != lPosition) TRACKBAR_InvalidateThumbMove(infoPtr, oldPos, lPosition); > + if (fPosition && oldPos != lPosition) > + { > + TRACKBAR_UpdateThumb(infoPtr); > + TRACKBAR_InvalidateThumbMove(infoPtr, oldPos, infoPtr->lPos); > + } > > return 0; > } > It's updated indirectly later I think. What does this fix? Visually SETPOS works as it is for me.

2 1

Re: ntdll: add RtlCreateUserProcess stub (try 2)
by Sebastian Lackner Jan. 8, 2016

Jan. 8, 2016

On 28.12.2015 00:58, Austin English wrote: > Using info from http://www.rohitab.com/discuss/topic/40191-ntcreateuserprocess/ > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38722 > > Try 2: fix prototypes > > -- -Austin > > > 0001-ntdll-add-RtlCreateUserProcess-stub-try-2.patch > > > From 27f4ac611c2d7c9b0d778519fc6eb9675dbd6b09 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Tue, 15 Dec 2015 01:51:05 -0600 > Subject: [PATCH] ntdll: add RtlCreateUserProcess stub (try 2) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/ntdll/ntdll.spec | 2 +- > dlls/ntdll/rtl.c | 13 +++++++++++++ > include/winternl.h | 10 ++++++++++ > 3 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index c3b6bf0..b8abc9c 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -505,7 +505,7 @@ > @ stdcall RtlCreateTimerQueue(ptr) > @ stdcall RtlCreateUnicodeString(ptr wstr) > @ stdcall RtlCreateUnicodeStringFromAsciiz(ptr str) > -@ stub RtlCreateUserProcess > +@ stdcall RtlCreateUserProcess(ptr long ptr ptr ptr long long long long ptr) > @ stub RtlCreateUserSecurityObject > @ stdcall RtlCreateUserThread(long ptr long ptr long long ptr ptr ptr ptr) > @ stub RtlCustomCPToUnicodeN > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 8eb3e9f..1c9b50d 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1595,3 +1595,16 @@ void WINAPI RtlGetCurrentProcessorNumberEx(PROCESSOR_NUMBER *processor) > processor->Number = NtGetCurrentProcessorNumber(); > processor->Reserved = 0; > } This needs rebasing, your RtlInsertElementGenericTableAvl() implementation conflicts here. > + > +/********************************************************************** > + * RtlCreateUserProcess [NTDLL.@] > + */ > +NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *path, ULONG attributes, RTL_USER_PROCESS_PARAMETERS *parameters, > + SECURITY_DESCRIPTOR *process_descriptor, SECURITY_DESCRIPTOR *thread_descriptor, > + HANDLE parent, BOOLEAN inherit, HANDLE debug, HANDLE exception, > + RTL_USER_PROCESS_INFORMATION *info) > +{ > + FIXME("(%p %u %p %p %p %p %d %p %p %p): stub\n", path, attributes, parameters, process_descriptor, thread_descriptor, > + parent, inherit, debug, exception, info); > + return STATUS_NOT_IMPLEMENTED; > +} > diff --git a/include/winternl.h b/include/winternl.h > index ecd5791..69b7b2d 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -1892,6 +1892,15 @@ typedef struct _LPC_MESSAGE { > UCHAR Data[ANYSIZE_ARRAY]; > } LPC_MESSAGE, *PLPC_MESSAGE; > > +typedef struct _RTL_USER_PROCESS_INFORMATION > +{ > + ULONG Length; Most definitions I have found call this field "Size", not "Length". Based on which header files is your patch? > + HANDLE Process; > + HANDLE Thread; > + CLIENT_ID ClientId; > + SECTION_IMAGE_INFORMATION ImageInformation; > +} RTL_USER_PROCESS_INFORMATION, *PRTL_USER_PROCESS_INFORMATION; > + > typedef enum _SHUTDOWN_ACTION { > ShutdownNoReboot, > ShutdownReboot, > @@ -2391,6 +2400,7 @@ NTSYSAPI NTSTATUS WINAPI RtlCreateTimerQueue(PHANDLE); > NTSYSAPI NTSTATUS WINAPI RtlCreateTimer(PHANDLE, HANDLE, RTL_WAITORTIMERCALLBACKFUNC, PVOID, DWORD, DWORD, ULONG); > NTSYSAPI BOOLEAN WINAPI RtlCreateUnicodeString(PUNICODE_STRING,LPCWSTR); > NTSYSAPI BOOLEAN WINAPI RtlCreateUnicodeStringFromAsciiz(PUNICODE_STRING,LPCSTR); > +NTSYSAPI NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *, ULONG, RTL_USER_PROCESS_PARAMETERS *, SECURITY_DESCRIPTOR *, SECURITY_DESCRIPTOR *, HANDLE, BOOLEAN, HANDLE, HANDLE, RTL_USER_PROCESS_INFORMATION *); > NTSYSAPI NTSTATUS WINAPI RtlCreateUserThread(HANDLE,const SECURITY_DESCRIPTOR*,BOOLEAN,PVOID,SIZE_T,SIZE_T,PRTL_THREAD_START_ROUTINE,void*,HANDLE*,CLIENT_ID*); > NTSYSAPI void WINAPI RtlDeactivateActivationContext(DWORD,ULONG_PTR); > NTSYSAPI PVOID WINAPI RtlDecodePointer(PVOID); > -- 2.6.4 >

2 2

[RFC] Removing 200XXXXX versions from Bugzilla
by Austin English Jan. 8, 2016

Jan. 8, 2016

Howdy all, I'd like to remove the old 200XXXXX from Bugzilla, and replace them with a pre-0.9 version instead. My reasoning is that it's obnoxious to have to find the latest release in the middle of the list (or type it in to find it), but if we removed all the 200XXXXX versions, it would be the second to last (next to -unknown). For that matter, I'd be okay with merging everything pre-1.0, but I'm mostly concerned about the 200XXXXX versions. Comments would be appreciated. -- -Austin

3 3