- wine-devel - winehq.org

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

13 Jan '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=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 13 Jan '16

13 Jan '16

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 13 Jan '16

13 Jan '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=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 13 Jan '16

13 Jan '16

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 13 Jan '16

13 Jan '16

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 13 Jan '16

13 Jan '16

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 13 Jan '16

13 Jan '16

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 12 Jan '16

12 Jan '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=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 12 Jan '16

12 Jan '16

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 12 Jan '16

12 Jan '16

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 12 Jan '16

12 Jan '16

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 12 Jan '16

12 Jan '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=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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '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=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 11 Jan '16

11 Jan '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=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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '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=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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '16

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 11 Jan '16

11 Jan '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=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 11 Jan '16

11 Jan '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=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 11 Jan '16

11 Jan '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=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 10 Jan '16

10 Jan '16

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 10 Jan '16

10 Jan '16

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 09 Jan '16

09 Jan '16

-----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 09 Jan '16

09 Jan '16

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 08 Jan '16

08 Jan '16

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 08 Jan '16

08 Jan '16

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 08 Jan '16

08 Jan '16

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 08 Jan '16

08 Jan '16

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 08 Jan '16

08 Jan '16

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 08 Jan '16

08 Jan '16

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

Re: [PATCH 2/2] d3dx9: Improve generated DDS file header. (try 5)
by Matteo Bruni 08 Jan '16

08 Jan '16

2015-12-22 8:26 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> It would be nice if you could write a few followup patches to fix struct dds_header properly, as Henri suggested in his review, and the remaining todo_wines.

1 0

Re: Mac OS X beta packages!
by James LeFevre 07 Jan '16

07 Jan '16

Can’t get wine to work. Here is what shows in the terminal window when I click on the Wine sysbol on the launch pad. Last login: Wed Jan 6 10:22:23 on ttys000 [parsont:~] jameslefevre% export PATH="/Applications/Wine Devel.app/Contents/Resources/wine/bin":$PATH; source "/Applications/Wine Devel.app/Contents/Resources/start-script.sh" export: Command not found. Illegal variable name. [parsont:~] jameslefevre% Running Mac OS X 10.11.2 Any ideas Jim

3 2

Re: [PATCH 4/4] d3d9/tests: Add missing space to trace() message.
by Marvin 07 Jan '16

07 Jan '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=19514 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2347: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2349: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2347: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2349: Test failed: Got unexpected hr 0, i=1.

1 0

Re: [PATCH 3/4] d3d9/tests: Add test for CreateDepthStencilSurfaceEx().
by Marvin 07 Jan '16

07 Jan '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=19513 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2347: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2349: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2347: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2349: Test failed: Got unexpected hr 0, i=1.

1 0

Re: [PATCH] xaudio2: Added missing break in a switch (Coverity)
by Andrew Eikum 07 Jan '16

07 Jan '16

On Wed, Jan 06, 2016 at 05:56:05PM +0300, Nikolay Sivov wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/xaudio2_7/xaudio_dll.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/xaudio2_7/xaudio_dll.c b/dlls/xaudio2_7/xaudio_dll.c > index e7176b2..1f5a91f 100644 > --- a/dlls/xaudio2_7/xaudio_dll.c > +++ b/dlls/xaudio2_7/xaudio_dll.c > @@ -449,6 +449,7 @@ static ALenum get_al_format(const WAVEFORMATEX *fmt) > case 8: > return AL_FORMAT_71CHN8; > } > + break; > case 16: Could you also add a break to the 16 case? Thanks, Andrew

2 2

Re: [PATCH 1/2] d3d10core/tests: Multisampled render targets are zeroed on creation (v2).
by Henri Verbeet 07 Jan '16

07 Jan '16

On 6 January 2016 at 23:56, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + hr = ID3D10Device_CreateTexture2D(device, &desc, NULL, &single); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + ID3D10Device_ResolveSubresource(device, (ID3D10Resource *)single, 0, > + (ID3D10Resource *)multi, 0, DXGI_FORMAT_R8G8B8A8_UNORM); > + > + get_texture_readback(single, &rb); > + for (y = 0; y < 480; ++y) > + { > + for (x = 0; x < 640; ++x) > + { > + color = get_readback_color(&rb, x, y); > + if (!compare_color(color, 0x00000000, 0)) > + { > + all_zero = FALSE; > + break; > + } > + } > + if (!all_zero) > + break; > + } > + release_texture_readback(&rb); > + ok(all_zero, "Got unexpected color 0x%08x, position %ux%u.\n", color, x, y); > + This probably works, but depends very much on ResolveSubresource() working as intended. I think it would be a little more robust to first clear "single" with a different color. Also, it's not strictly required, but if you use a swapchain surface to resolve to, it's easier to later debug the test visually by inserting a Present() call in the appropriate place.

1 0

Re: user32: Set correct caret state in the server in SetCaretPos. (try 5)
by Sebastian Lackner 07 Jan '16

07 Jan '16

On 31.12.2015 17:39, Sebastian Lackner wrote: > From: Anton Baskanov <baskanov(a)gmail.com> > > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Changes since v4: > > * Replace !!req->state with (req->state != CARET_STATE_OFF). > The first version still depends on CARET_STATE_OFF == 0, which > might change in the future. > > * Avoid nested ifs by reordering checks. > > dlls/user32/caret.c | 8 ++++---- > server/protocol.def | 6 +++++- > server/queue.c | 8 ++++++-- > 3 files changed, 15 insertions(+), 7 deletions(-) > Any remarks on this patch?

1 0

Re: [PATCH 1/2] ntdll: RtlIpv4|6 implementations
by Sebastian Lackner 07 Jan '16

07 Jan '16

Thanks for your contribution. I didn't do a full review yet, but there are a couple of things I would like to point out. Before you resend, please also wait if other people have additional comments. Sorry in advance, the Wine project can sometimes be a bit picky with patch acceptance. ;) Please note that especially for people new to the Wine project, it is highly recommended to send your patches splitted in small pieces. In this case for example, you could send one patch per function, with corresponding test patch inbetween, to make reviewing as easy as possible. On 07.01.2016 00:25, Donat Enikeev wrote: > Using inet_?to? if available, otherwise - behave like a stub. > > Tested on Windows8@VM and Ubutnu 15.04. > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > > --- > dlls/ntdll/ntdll.spec | 6 +-- > dlls/ntdll/rtl.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++ > include/in6addr.h | 4 ++ > 3 files changed, 136 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 8cabf95..d7c23fc 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -711,14 +711,14 @@ > @ stdcall RtlIpv4AddressToStringExA(ptr long ptr ptr) > @ stdcall RtlIpv4AddressToStringExW(ptr long ptr ptr) > @ stdcall RtlIpv4AddressToStringW(ptr ptr) > -# @ stub RtlIpv4StringToAddressA > +@ stdcall RtlIpv4StringToAddressA(ptr long ptr ptr) For strings (like the first argument), str should be used. > # @ stub RtlIpv4StringToAddressExA > @ stdcall RtlIpv4StringToAddressExW(ptr ptr wstr ptr) > # @ stub RtlIpv4StringToAddressW > -# @ stub RtlIpv6AddressToStringA > +@ stdcall RtlIpv6AddressToStringA(ptr ptr) > # @ stub RtlIpv6AddressToStringExA > # @ stub RtlIpv6AddressToStringExW > -# @ stub RtlIpv6AddressToStringW > +@ stdcall RtlIpv6AddressToStringW(ptr ptr) Usually *A functions are implemented on top of the corresponding *W function. This means you have to implement RtlIpv4StringToAddressW first, and then RtlIpv4StringToAddressA on top of it. > # @ stub RtlIpv6StringToAddressA > # @ stub RtlIpv6StringToAddressExA > # @ stub RtlIpv6StringToAddressExW > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 74ad35a..5c82d43 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -33,6 +33,9 @@ > #ifdef HAVE_NETINET_IN_H > #include <netinet/in.h> > #endif > +#ifdef HAVE_ARPA_INET_H > +#include <arpa/inet.h> > +#endif > #include "ntstatus.h" > #define NONAMELESSUNION > #define NONAMELESSSTRUCT > @@ -45,6 +48,7 @@ > #include "wine/unicode.h" > #include "ntdll_misc.h" > #include "inaddr.h" > +#include "in6addr.h" > #include "ddk/ntddk.h" > > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > @@ -891,6 +895,50 @@ NTSTATUS WINAPI RtlIpv4StringToAddressExW(PULONG IP, PULONG Port, > } > > /*********************************************************************** > + * RtlIpv4StringToAddressA [NTDLL.@] > + * > + * Convert the given ipv4 address to binary representation (network byte order) > + * > + * PARAMS > + * s [I] NULL terminated string with address to convert > + * strict [I] TRUE: restricts to usual 4-part ip-address with decimal parts; FALSE: other forms allowed > + * terminator [O] Pointer to the terminated charatcer of s > + * in_addr [IO] PTR to store converted ip address > + * > + * RETURNS > + * Success: STATUS_SUCCESS > + * Failure: STATUS_INVALID_PARAMETER > + * > + */ > +NTSTATUS WINAPI RtlIpv4StringToAddressA(LPCSTR s, BOOLEAN strict, LPCSTR *terminator, IN_ADDR *in_addr) As mentioned above, usually *A functions forward to the corresponding *W function. It might be preferred to avoid using inet_pton(), and use direct string operations instead. > +{ > + if (!s || !in_addr) > + return STATUS_INVALID_PARAMETER; > + > + if (strict == FALSE) > + FIXME("Support of non-decimal IP addresses is not implemented. semi-stub (%s)\n", s); > + /* ^ support of the option above could be easily implemented with `inet_atop`, not available by the moment in wine */ > + > + #ifdef HAVE_INET_PTON > + > + TRACE("('%s' @ %s, %d, %p, %p, %llu) \n", s, s, strict, terminator, in_addr, (long long unsigned)in_addr->S_un.S_addr); Use debugstr_a / debugstr_w() for tracing untrusted values. Why do you print s twice? > + > + if (!inet_pton(AF_INET, s, &in_addr->S_un.S_addr)) > + { > + TRACE("Conversion of ip address '%s' failed\n", s); > + return STATUS_INVALID_PARAMETER; > + } > + > + *terminator = s+(int)strlen(s); > + > + return STATUS_SUCCESS; > + #endif > + > + FIXME( "No inet_pton() available on the platform - stub\n" ); > + return STATUS_INVALID_PARAMETER; > +} > + > +/*********************************************************************** > * RtlIpv4AddressToStringExW [NTDLL.@] > * > * Convert the given ipv4 address and optional the port to a string > @@ -1004,6 +1052,87 @@ CHAR * WINAPI RtlIpv4AddressToStringA(const IN_ADDR *pin, LPSTR buffer) > } > > /*********************************************************************** > + * RtlIpv6AddressToStringA [NTDLL.@] > + * > + * Converts the given ipv6 address to a string > + * > + * PARAMS > + * pin [I] PTR to the ip address to convert (network byte order) > + * buffer [O] destination buffer for the result (at least 46 characters) > + * > + * RETURNS > + * PTR to the 0 character at the end of the converted string > + * > + */ > +CHAR * WINAPI RtlIpv6AddressToStringA(const IN6_ADDR *pin, LPSTR buffer) > +{ Please add TRACES or FIXMEs (for partial implementations) at the top of each function. > + if (!pin || !buffer) > + { > + WARN("Incorrect parameters passed: (%p, %p)", pin, buffer); Always add a linebreak at the end of messages. > + return NULL; > + } > + > + #ifdef HAVE_INET_NTOP > + > + if (!inet_ntop(AF_INET6, &(pin->u), buffer, INET6_ADDRSTRLEN)) > + ERR("Conversion of Ipv6Address failed\n"); > + > + TRACE("(%p, %p) Ipv6 Address %s\n", pin, buffer, buffer); > + > + return buffer+strlen(buffer); > + > + #else > + > + FIXME( "No inet_ntop() available - stub\n" ); > + return buffer; > + > + #endif > +} > + > +/*********************************************************************** > + * RtlIpv6AddressToStringW [NTDLL.@] > + * > + * Converts the given ipv6 address to a string > + * > + * PARAMS > + * pin [I] PTR to the ip address to convert (network byte order) > + * buffer [O] destination buffer for the result (at least 46 characters) > + * > + * RETURNS > + * PTR to the 0 character at the end of the converted string > + * > + */ > +WCHAR * WINAPI RtlIpv6AddressToStringW(const IN6_ADDR *pin, LPWSTR buffer) > +{ > + CHAR tmp_buffer[INET6_ADDRSTRLEN]; Here a TRACE/FIXME is also missing. > + > + if (!pin || !buffer) > + { > + WARN("Incorrect parameters passed: (%p, %p)", pin, buffer); > + return NULL; > + } > + > + if (RtlIpv6AddressToStringA(pin, (LPSTR)&tmp_buffer)) There are many places in your patch with unncessary casts. Those should be avoided. > + { > + int len = strlen(tmp_buffer); > + > + RtlZeroMemory(buffer, len*sizeof(WCHAR)); This doesn't work when your string contains multibyte characters. > + > + if (len > INET6_ADDRSTRLEN) > + WARN("Potential buffer overflow with %d length of %d maximum supposed", len, INET6_ADDRSTRLEN); Unless the same limitation exists on Windows, such code should be avoided. Also please note that INET6_ADDRSTRLEN is defined different on Linux/Windows. > + > + TRACE("Got Ipv6Address '%s' of length %d from RtlIpv6AddressToStringA\n", (char *)&tmp_buffer, len); > + > + ntdll_umbstowcs(0, (const char *)&tmp_buffer, len, buffer, len); > + > + return buffer+len; > + } > + > + FIXME("(%p, %p): semi-stub\n", pin, buffer); > + return buffer; > +} > + > +/*********************************************************************** > * get_pointer_obfuscator (internal) > */ > static DWORD_PTR get_pointer_obfuscator( void ) > diff --git a/include/in6addr.h b/include/in6addr.h > index a745bd2..7600407 100644 > --- a/include/in6addr.h > +++ b/include/in6addr.h > @@ -32,6 +32,10 @@ typedef struct WS(in6_addr) { > } u; > } IN6_ADDR, *PIN6_ADDR, *LPIN6_ADDR; > > +#ifndef INET6_ADDRSTRLEN > +#define INET6_ADDRSTRLEN 65 > +#endif > + > #define in_addr6 WS(in6_addr) > > #ifdef USE_WS_PREFIX >

2 1

Re: [PATCH 2/2] ntdll: RtlIpv4|6 tests
by Sebastian Lackner 07 Jan '16

07 Jan '16

For tests, the subject should start with "ntdll/tests:". Please note that Mark Jansen also has been working on the tests. Instead of starting again from scratch, you might want to take a look at: https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-Rt… It probably should be possible to get those patches upstream with no or just minor changes, I'll also take a look at them again. On 07.01.2016 00:26, Donat Enikeev wrote: > Tests for newly added implementations plus `test_RtlIpv4StringToAddress` rewritten as there was no such function before and therefore tests were never applied > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > --- > dlls/ntdll/tests/rtl.c | 444 +++++++++++++++++++++++++++++++------------------ > 1 file changed, 281 insertions(+), 163 deletions(-) > > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 94a22ac..8a77bcc 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -25,6 +25,8 @@ > > #include "ntdll_test.h" > #include "inaddr.h" > +#include "in6addr.h" > +#include "winnls.h" > > #ifndef __WINE_WINTERNL_H > > @@ -89,6 +91,8 @@ static IMAGE_BASE_RELOCATION *(WINAPI *pLdrProcessRelocationBlock)(void*,UINT,US > static CHAR * (WINAPI *pRtlIpv4AddressToStringA)(const IN_ADDR *, LPSTR); > static NTSTATUS (WINAPI *pRtlIpv4AddressToStringExA)(const IN_ADDR *, USHORT, LPSTR, PULONG); > static NTSTATUS (WINAPI *pRtlIpv4StringToAddressA)(PCSTR, BOOLEAN, PCSTR *, IN_ADDR *); > +static CHAR * (WINAPI *pRtlIpv6AddressToStringA)(const IN6_ADDR *, LPSTR); > +static WCHAR * (WINAPI *pRtlIpv6AddressToStringW)(const IN6_ADDR *, LPWSTR); > static NTSTATUS (WINAPI *pLdrAddRefDll)(ULONG, HMODULE); > static NTSTATUS (WINAPI *pLdrLockLoaderLock)(ULONG, ULONG*, ULONG_PTR*); > static NTSTATUS (WINAPI *pLdrUnlockLoaderLock)(ULONG, ULONG_PTR); > @@ -115,24 +119,24 @@ static void InitFunctionPtrs(void) > hntdll = LoadLibraryA("ntdll.dll"); > ok(hntdll != 0, "LoadLibrary failed\n"); > if (hntdll) { > - pRtlCompareMemory = (void *)GetProcAddress(hntdll, "RtlCompareMemory"); > - pRtlCompareMemoryUlong = (void *)GetProcAddress(hntdll, "RtlCompareMemoryUlong"); > + pRtlCompareMemory = (void *)GetProcAddress(hntdll, "RtlCompareMemory"); > + pRtlCompareMemoryUlong = (void *)GetProcAddress(hntdll, "RtlCompareMemoryUlong"); > pRtlDeleteTimer = (void *)GetProcAddress(hntdll, "RtlDeleteTimer"); > - pRtlMoveMemory = (void *)GetProcAddress(hntdll, "RtlMoveMemory"); > - pRtlFillMemory = (void *)GetProcAddress(hntdll, "RtlFillMemory"); > - pRtlFillMemoryUlong = (void *)GetProcAddress(hntdll, "RtlFillMemoryUlong"); > - pRtlZeroMemory = (void *)GetProcAddress(hntdll, "RtlZeroMemory"); > - pRtlUlonglongByteSwap = (void *)GetProcAddress(hntdll, "RtlUlonglongByteSwap"); > - pRtlUniform = (void *)GetProcAddress(hntdll, "RtlUniform"); > - pRtlRandom = (void *)GetProcAddress(hntdll, "RtlRandom"); > - pRtlAreAllAccessesGranted = (void *)GetProcAddress(hntdll, "RtlAreAllAccessesGranted"); > - pRtlAreAnyAccessesGranted = (void *)GetProcAddress(hntdll, "RtlAreAnyAccessesGranted"); > - pRtlComputeCrc32 = (void *)GetProcAddress(hntdll, "RtlComputeCrc32"); > - pRtlInitializeHandleTable = (void *)GetProcAddress(hntdll, "RtlInitializeHandleTable"); > - pRtlIsValidIndexHandle = (void *)GetProcAddress(hntdll, "RtlIsValidIndexHandle"); > - pRtlDestroyHandleTable = (void *)GetProcAddress(hntdll, "RtlDestroyHandleTable"); > - pRtlAllocateHandle = (void *)GetProcAddress(hntdll, "RtlAllocateHandle"); > - pRtlFreeHandle = (void *)GetProcAddress(hntdll, "RtlFreeHandle"); > + pRtlMoveMemory = (void *)GetProcAddress(hntdll, "RtlMoveMemory"); > + pRtlFillMemory = (void *)GetProcAddress(hntdll, "RtlFillMemory"); > + pRtlFillMemoryUlong = (void *)GetProcAddress(hntdll, "RtlFillMemoryUlong"); > + pRtlZeroMemory = (void *)GetProcAddress(hntdll, "RtlZeroMemory"); > + pRtlUlonglongByteSwap = (void *)GetProcAddress(hntdll, "RtlUlonglongByteSwap"); > + pRtlUniform = (void *)GetProcAddress(hntdll, "RtlUniform"); > + pRtlRandom = (void *)GetProcAddress(hntdll, "RtlRandom"); > + pRtlAreAllAccessesGranted = (void *)GetProcAddress(hntdll, "RtlAreAllAccessesGranted"); > + pRtlAreAnyAccessesGranted = (void *)GetProcAddress(hntdll, "RtlAreAnyAccessesGranted"); > + pRtlComputeCrc32 = (void *)GetProcAddress(hntdll, "RtlComputeCrc32"); > + pRtlInitializeHandleTable = (void *)GetProcAddress(hntdll, "RtlInitializeHandleTable"); > + pRtlIsValidIndexHandle = (void *)GetProcAddress(hntdll, "RtlIsValidIndexHandle"); > + pRtlDestroyHandleTable = (void *)GetProcAddress(hntdll, "RtlDestroyHandleTable"); > + pRtlAllocateHandle = (void *)GetProcAddress(hntdll, "RtlAllocateHandle"); > + pRtlFreeHandle = (void *)GetProcAddress(hntdll, "RtlFreeHandle"); To keep your patches as simple as possible, it might be easier to skip the formatting changes. Touching code which is unrelated to your patch is usually not a good idea. ;) > pRtlAllocateAndInitializeSid = (void *)GetProcAddress(hntdll, "RtlAllocateAndInitializeSid"); > pRtlFreeSid = (void *)GetProcAddress(hntdll, "RtlFreeSid"); > pNtCurrentTeb = (void *)GetProcAddress(hntdll, "NtCurrentTeb"); > @@ -141,6 +145,8 @@ static void InitFunctionPtrs(void) > pLdrProcessRelocationBlock = (void *)GetProcAddress(hntdll, "LdrProcessRelocationBlock"); > pRtlIpv4AddressToStringA = (void *)GetProcAddress(hntdll, "RtlIpv4AddressToStringA"); > pRtlIpv4AddressToStringExA = (void *)GetProcAddress(hntdll, "RtlIpv4AddressToStringExA"); > + pRtlIpv6AddressToStringA = (void *)GetProcAddress(hntdll, "RtlIpv6AddressToStringA"); > + pRtlIpv6AddressToStringW = (void *)GetProcAddress(hntdll, "RtlIpv6AddressToStringW"); > pRtlIpv4StringToAddressA = (void *)GetProcAddress(hntdll, "RtlIpv4StringToAddressA"); > pLdrAddRefDll = (void *)GetProcAddress(hntdll, "LdrAddRefDll"); > pLdrLockLoaderLock = (void *)GetProcAddress(hntdll, "LdrLockLoaderLock"); > @@ -1129,172 +1135,282 @@ static void test_RtlIpv4AddressToStringEx(void) > static void test_RtlIpv4StringToAddress(void) > { > NTSTATUS res; > - IN_ADDR ip, expected_ip; > - PCSTR terminator; > - CHAR dummy; > + IN_ADDR ip; > + LPCSTR terminator; If you want to improve existing tests, this should probably also go into a separate patch. Also, it wouldn't hurt to explain more detailed what exactly you improved. > struct > { > PCSTR address; > NTSTATUS res; > int terminator_offset; > - int ip[4]; > - BOOL strict_is_different; > - NTSTATUS res_strict; > - int terminator_offset_strict; > - int ip_strict[4]; > - } tests[] = > + ULONG ip_ulong; > + } tests[] = /** tests data for non-strict (strict below) */ > + { > + { "255.255.255.255:123", STATUS_SUCCESS, 15, 4294967295UL }, > + { "255.255.255.256", STATUS_INVALID_PARAMETER, 15, 1 }, > + { "255.255.255.42949672", STATUS_INVALID_PARAMETER, 22, 1 }, > + { "a", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "1.1.1.0xaA", STATUS_SUCCESS, 10, 2852192513UL }, > + { "1.1.1.0XaA", STATUS_SUCCESS, 10, 2852192513UL }, > + { "1.1.1.0x", STATUS_INVALID_PARAMETER, 8, 1 }, > + { "1.1.1.0xff", STATUS_SUCCESS, 10, 4278255873UL }, > + { "1.1.1.0x100", STATUS_INVALID_PARAMETER, 11, 1 }, > + { "1.1.1.0xffffffff", STATUS_INVALID_PARAMETER, 16, 1 }, > + { "1.1.1.0x100000000", STATUS_INVALID_PARAMETER, 16, 1 }, > + { "1.1.1.010", STATUS_SUCCESS, 9, 134283521UL }, > + { "1.1.1.00", STATUS_SUCCESS, 8, 65793 }, > + { "1.1.1.007", STATUS_SUCCESS, 9, 117506305UL }, > + { "1.1.1.08", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "1.1.1.008", STATUS_SUCCESS, 8, 65793 }, > + { "1.1.1.0a", STATUS_SUCCESS, 7, 65793 }, > + { "1.1.1.0o10", STATUS_SUCCESS, 7, 65793 }, > + { "1.1.1.0b10", STATUS_SUCCESS, 7, 65793 }, > + { "1.1.1.-2", STATUS_INVALID_PARAMETER, 6, 1 }, > + { "1", STATUS_SUCCESS, 1, 16777216 }, > + { "-1", STATUS_INVALID_PARAMETER, 0, 0 }, > + { "203569230", STATUS_SUCCESS, 9, 1312301580UL }, > + { "1.223756", STATUS_SUCCESS, 8, 208274177 }, > + { "3.4.756", STATUS_SUCCESS, 7, 4093772803UL }, > + { "3.4.756.1", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "3.4.65536", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "3.4.5.6.7", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "3.4.5.+6", STATUS_INVALID_PARAMETER, 6, 1 }, > + { " 3.4.5.6", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "\t3.4.5.6", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "3.4.5.6 ", STATUS_SUCCESS, 7, 100992003UL }, > + { "3. 4.5.6", STATUS_INVALID_PARAMETER, 2, 1 }, > + { ".", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "..", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "1.", STATUS_INVALID_PARAMETER, 2, 1 }, > + { "1..", STATUS_INVALID_PARAMETER, 3, 1 }, > + { ".1", STATUS_INVALID_PARAMETER, 1, 1 }, > + { ".1.", STATUS_INVALID_PARAMETER, 1, 1 }, > + { ".1.2.3", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "::1", STATUS_INVALID_PARAMETER, 0, 1 }, > + { ":1", STATUS_INVALID_PARAMETER, 0, 1 }, > + }, tests_strict[] = > { > - { "", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { " ", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "1.1.1.1", STATUS_SUCCESS, 7, { 1, 1, 1, 1 } }, > - { "0.0.0.0", STATUS_SUCCESS, 7, { 0, 0, 0, 0 } }, > - { "255.255.255.255", STATUS_SUCCESS, 15, { 255, 255, 255, 255 } }, > - { "255.255.255.255:123", > - STATUS_SUCCESS, 15, { 255, 255, 255, 255 } }, > - { "255.255.255.256", STATUS_INVALID_PARAMETER, 15, { -1 } }, > - { "255.255.255.4294967295", > - STATUS_INVALID_PARAMETER, 22, { -1 } }, > - { "255.255.255.4294967296", > - STATUS_INVALID_PARAMETER, 21, { -1 } }, > - { "255.255.255.4294967297", > - STATUS_INVALID_PARAMETER, 21, { -1 } }, > - { "a", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "1.1.1.0xaA", STATUS_SUCCESS, 10, { 1, 1, 1, 170 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0XaA", STATUS_SUCCESS, 10, { 1, 1, 1, 170 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0x", STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0xff", STATUS_SUCCESS, 10, { 1, 1, 1, 255 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0x100", STATUS_INVALID_PARAMETER, 11, { -1 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0xffffffff",STATUS_INVALID_PARAMETER, 16, { -1 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.0x100000000", > - STATUS_INVALID_PARAMETER, 16, { -1, 0, 0, 0 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "1.1.1.010", STATUS_SUCCESS, 9, { 1, 1, 1, 8 }, > - TRUE, STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "1.1.1.00", STATUS_SUCCESS, 8, { 1, 1, 1, 0 }, > - TRUE, STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "1.1.1.007", STATUS_SUCCESS, 9, { 1, 1, 1, 7 }, > - TRUE, STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "1.1.1.08", STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "1.1.1.008", STATUS_SUCCESS, 8, { 1, 1, 1, 0 }, > - TRUE, STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "1.1.1.0a", STATUS_SUCCESS, 7, { 1, 1, 1, 0 } }, > - { "1.1.1.0o10", STATUS_SUCCESS, 7, { 1, 1, 1, 0 } }, > - { "1.1.1.0b10", STATUS_SUCCESS, 7, { 1, 1, 1, 0 } }, > - { "1.1.1.-2", STATUS_INVALID_PARAMETER, 6, { -1 } }, > - { "1", STATUS_SUCCESS, 1, { 0, 0, 0, 1 }, > - TRUE, STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { "-1", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "203569230", STATUS_SUCCESS, 9, { 12, 34, 56, 78 }, > - TRUE, STATUS_INVALID_PARAMETER, 9, { -1 } }, > - { "1.223756", STATUS_SUCCESS, 8, { 1, 3, 106, 12 }, > - TRUE, STATUS_INVALID_PARAMETER, 8, { -1 } }, > - { "3.4.756", STATUS_SUCCESS, 7, { 3, 4, 2, 244 }, > - TRUE, STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "3.4.756.1", STATUS_INVALID_PARAMETER, 9, { -1 } }, > - { "3.4.65536", STATUS_INVALID_PARAMETER, 9, { -1 } }, > - { "3.4.5.6.7", STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "3.4.5.+6", STATUS_INVALID_PARAMETER, 6, { -1 } }, > - { " 3.4.5.6", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "\t3.4.5.6", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "3.4.5.6 ", STATUS_SUCCESS, 7, { 3, 4, 5, 6 } }, > - { "3. 4.5.6", STATUS_INVALID_PARAMETER, 2, { -1 } }, > - { ".", STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { "..", STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { "1.", STATUS_INVALID_PARAMETER, 2, { -1 } }, > - { "1..", STATUS_INVALID_PARAMETER, 3, { -1 } }, > - { ".1", STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { ".1.", STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { ".1.2.3", STATUS_INVALID_PARAMETER, 1, { -1 } }, > - { "0.1.2.3", STATUS_SUCCESS, 7, { 0, 1, 2, 3 } }, > - { "0.1.2.3.", STATUS_INVALID_PARAMETER, 7, { -1 } }, > - { "[0.1.2.3]", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { "::1", STATUS_INVALID_PARAMETER, 0, { -1 } }, > - { ":1", STATUS_INVALID_PARAMETER, 0, { -1 } }, > + { "", STATUS_INVALID_PARAMETER, 0, 0}, > + { " ", STATUS_INVALID_PARAMETER, 0, 0 }, > + { "1.1.1.1", STATUS_SUCCESS, 7, 16843009 }, > + { "0.0.0.0", STATUS_SUCCESS, 7, 0 }, > + { "255.255.255.255", STATUS_SUCCESS, 15, 4294967295UL }, > + { "255.255.255.256", STATUS_INVALID_PARAMETER, 15, 1 }, > + { "255.255.255.42949672", STATUS_INVALID_PARAMETER, 22, 1 }, > + { "1.1.1.010", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "1.1.1.00", STATUS_INVALID_PARAMETER, 8, 1 }, > + { "1.1.1.007", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "1.1.1.08", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "1.1.1.008", STATUS_INVALID_PARAMETER, 8, 1 }, > + { "1.1.1.-2", STATUS_INVALID_PARAMETER, 6, 1 }, > + { "1", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "-1", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "203569230", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "1.223756", STATUS_INVALID_PARAMETER, 8, 1 }, > + { "3.4.756", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "3.4.756.1", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "3.4.65536", STATUS_INVALID_PARAMETER, 9, 1 }, > + { "3.4.5.6.7", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "3.4.5.+6", STATUS_INVALID_PARAMETER, 6, 1 }, > + { " 3.4.5.6", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "\t3.4.5.6", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "3.4.5.6", STATUS_SUCCESS, 7, 100992003 }, > + { "3. 4.5.6", STATUS_INVALID_PARAMETER, 2, 1 }, > + { ".", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "..", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "1.", STATUS_INVALID_PARAMETER, 2, 1 }, > + { "1..", STATUS_INVALID_PARAMETER, 3, 1 }, > + { ".1", STATUS_INVALID_PARAMETER, 1, 1 }, > + { ".1.", STATUS_INVALID_PARAMETER, 1, 1 }, > + { ".1.2.3", STATUS_INVALID_PARAMETER, 1, 1 }, > + { "0.1.2.3", STATUS_SUCCESS, 7, 50462976 }, > + { "0.1.2.3.", STATUS_INVALID_PARAMETER, 7, 1 }, > + { "[0.1.2.3]", STATUS_INVALID_PARAMETER, 0, 1 }, > + { "::1", STATUS_INVALID_PARAMETER, 0, 1 }, > + { ":1", STATUS_INVALID_PARAMETER, 0, 1 }, > }; > const int testcount = sizeof(tests) / sizeof(tests[0]); > + const int testcount_strict = sizeof(tests_strict) / sizeof(tests_strict[0]); > int i; > > if (!pRtlIpv4StringToAddressA) > { > - skip("RtlIpv4StringToAddress not available\n"); > + skip("RtlIpv4StringToAddressA not available\n"); > return; > } > > - if (0) > - { > - /* leaving either parameter NULL crashes on Windows */ > - res = pRtlIpv4StringToAddressA(NULL, FALSE, &terminator, &ip); > - res = pRtlIpv4StringToAddressA("1.1.1.1", FALSE, NULL, &ip); > - res = pRtlIpv4StringToAddressA("1.1.1.1", FALSE, &terminator, NULL); > - /* same for the wide char version */ > - /* > - res = pRtlIpv4StringToAddressW(NULL, FALSE, &terminatorW, &ip); > - res = pRtlIpv4StringToAddressW(L"1.1.1.1", FALSE, NULL, &ip); > - res = pRtlIpv4StringToAddressW(L"1.1.1.1", FALSE, &terminatorW, NULL); > - */ > - } > - > + /* non-strict */ > for (i = 0; i < testcount; i++) > { > - /* non-strict */ > - terminator = &dummy; > - ip.S_un.S_addr = 0xabababab; > + memset(&ip, 0, sizeof(ip)); > + > res = pRtlIpv4StringToAddressA(tests[i].address, FALSE, &terminator, &ip); > - ok(res == tests[i].res, > - "[%s] res = 0x%08x, expected 0x%08x\n", > - tests[i].address, res, tests[i].res); > - ok(terminator == tests[i].address + tests[i].terminator_offset, > - "[%s] terminator = %p, expected %p\n", > - tests[i].address, terminator, tests[i].address + tests[i].terminator_offset); > - if (tests[i].ip[0] == -1) > - expected_ip.S_un.S_addr = 0xabababab; > - else > - { > - expected_ip.S_un.S_un_b.s_b1 = tests[i].ip[0]; > - expected_ip.S_un.S_un_b.s_b2 = tests[i].ip[1]; > - expected_ip.S_un.S_un_b.s_b3 = tests[i].ip[2]; > - expected_ip.S_un.S_un_b.s_b4 = tests[i].ip[3]; > - } > - ok(ip.S_un.S_addr == expected_ip.S_un.S_addr, > - "[%s] ip = %08x, expected %08x\n", > - tests[i].address, ip.S_un.S_addr, expected_ip.S_un.S_addr); > + todo_wine ok(res == tests[i].res, > + "#%d '%s' (Strict:FALSE) res = 0x%08x, expected 0x%08x\n", i, > + tests[i].address, res, tests[i].res); > + > + if (res == STATUS_SUCCESS) { > + todo_wine ok( terminator == tests[i].address + (size_t)tests[i].terminator_offset, > + "#%d '%s' (Strict:FALSE) terminator = %p, expected %p for ptr %p\n", i, > + tests[i].address, terminator, tests[i].address + (size_t)tests[i].terminator_offset, tests[i].address); > + > + todo_wine ok(ip.S_un.S_addr == tests[i].ip_ulong, > + "#%d '%s' (Strict:FALSE) ip = %llu, expected %llu\n", i, > + tests[i].address, (long long unsigned)ip.S_un.S_addr, (long long unsigned)tests[i].ip_ulong); > > - if (!tests[i].strict_is_different) > - { > - tests[i].res_strict = tests[i].res; > - tests[i].terminator_offset_strict = tests[i].terminator_offset; > - tests[i].ip_strict[0] = tests[i].ip[0]; > - tests[i].ip_strict[1] = tests[i].ip[1]; > - tests[i].ip_strict[2] = tests[i].ip[2]; > - tests[i].ip_strict[3] = tests[i].ip[3]; > } > - /* strict */ > - terminator = &dummy; > - ip.S_un.S_addr = 0xabababab; > - res = pRtlIpv4StringToAddressA(tests[i].address, TRUE, &terminator, &ip); > - ok(res == tests[i].res_strict, > - "[%s] res = 0x%08x, expected 0x%08x\n", > - tests[i].address, res, tests[i].res_strict); > - ok(terminator == tests[i].address + tests[i].terminator_offset_strict, > - "[%s] terminator = %p, expected %p\n", > - tests[i].address, terminator, tests[i].address + tests[i].terminator_offset_strict); > - if (tests[i].ip_strict[0] == -1) > - expected_ip.S_un.S_addr = 0xabababab; > - else > + } > + > + /* strict */ > + for (i=0; i<testcount_strict; i++) > + { > + memset(&ip, 0, sizeof(ip)); > + > + res = pRtlIpv4StringToAddressA(tests_strict[i].address, TRUE, &terminator, &ip); > + > + ok(res == tests_strict[i].res, > + "#%d '%s' (Strict:TRUE) res = 0x%08x, expected 0x%08x\n", i, > + tests_strict[i].address, res, tests_strict[i].res); > + > + if (res == STATUS_SUCCESS) > { > - expected_ip.S_un.S_un_b.s_b1 = tests[i].ip_strict[0]; > - expected_ip.S_un.S_un_b.s_b2 = tests[i].ip_strict[1]; > - expected_ip.S_un.S_un_b.s_b3 = tests[i].ip_strict[2]; > - expected_ip.S_un.S_un_b.s_b4 = tests[i].ip_strict[3]; > + ok(terminator == tests_strict[i].address + (size_t)tests_strict[i].terminator_offset, > + "#%d '%s' (Strict:TRUE) terminator = %p, expected %p for ptr %p\n", i, > + tests_strict[i].address, terminator, tests_strict[i].address + tests_strict[i].terminator_offset, tests_strict[i].address); > + > + ok(ip.S_un.S_addr == tests_strict[i].ip_ulong, > + "#%d '%s' (Strict:TRUE) ip = %llu, expected %llu\n", i, > + tests_strict[i].address, (long long unsigned)ip.S_un.S_addr, (long long unsigned)tests_strict[i].ip_ulong); > } > - ok(ip.S_un.S_addr == expected_ip.S_un.S_addr, > - "[%s] ip = %08x, expected %08x\n", > - tests[i].address, ip.S_un.S_addr, expected_ip.S_un.S_addr); > + > + } > +} > + > +struct ipv6_testing_data > +{ > + LPCSTR readable_addr; > + UCHAR expected_representation[16]; > + LPCSTR readable_compact_addr; /** could differ from readable **/ > +}; > + > +static struct ipv6_testing_data ipv6_samples[] = > +{ > + { "0::", { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, "::" }, > + { "::01", { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 }, "::1" }, > + { "1::2", { 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2 }, "1::2" }, > + { "2002:4559:1FE2::4559:1FE2", { 32, 2, 69, 89, 31, 226, 0, 0, 0, 0, 0, 0, 69, 89, 31, 226 }, "2002:4559:1fe2::4559:1fe2" }, > + { "2a02:6b8::3", { 42, 2, 6, 184, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3 }, "2a02:6b8::3" }, > + { "::192.168.001.1", { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 192, 168, 1, 1 }, "::192.168.1.1" }, > + { "fff::190.160.10.10", { 15, 255, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 190, 160, 10, 10 }, "FFf::bea0:a0a" }, > + { "2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d", { 32, 1, 13, 184, 17, 163, 9, 215,31, 52, 138, 46, 7, 160, 118, 93 }, "2001:db8:11a3:9d7:1f34:8a2e:7a0:765d" }, > + { "2001:0db8::", { 32, 1, 13, 184, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, "2001:db8::" }, > + { "ff00::", { 255, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, "ff00::" } The number of tests is most likely not sufficient. The special cases (empty string, invalid format, ...) might be more interesting. > +}; > + > + > +static void test_RtlIpv6AddressToStringA(void) > +{ > + const int testcount = sizeof(ipv6_samples) / sizeof(ipv6_samples[0]); > + int i; > + CHAR buffer[65]; > + CHAR * res; > + > + if ( !pRtlIpv6AddressToStringA ) > + { > + win_skip("Method not supported\n"); > + return; > + } > + > + res = pRtlIpv6AddressToStringA((IN6_ADDR*) &ipv6_samples[0].expected_representation, (LPSTR)&buffer); > + if ((void *)&buffer==(void *)res) { Please avoid unnecessary casts. buffer and res should both have the same type. The same also applies to a couple of other places. > + win_skip("No conversion expected with stub without inet_ntop\n"); > + return; > + } > + > + for (i=0; i<testcount; i++) > + { > + CHAR buffer[65]; Did you forget to replace with the constant maybe? > + CHAR * res; > + IN6_ADDR * in6; > + int expected_len, result_len; > + > + memset(buffer, 0, sizeof(buffer) - 1); > + > + in6 = (IN6_ADDR*) &ipv6_samples[i].expected_representation; > + > + res = pRtlIpv6AddressToStringA(in6, (LPSTR)&buffer); > + > + ok( 0 == (CHAR)(*res), > + "Pointer to 0 expected, got %c at %p\n", > + (CHAR)(*res), res); > + > + expected_len = strlen(ipv6_samples[i].readable_compact_addr); > + result_len = strlen(buffer); > + > + ok( expected_len == result_len, > + "Unexpected resulting strlen, waited for %d, got %d\n", > + expected_len, result_len); > + > + ok ( strcasecmp((const char *)ipv6_samples[i].readable_compact_addr, (const char *)&buffer) == 0, > + "Unexpected IPv6 address, waited '%s', got '%s'", > + ipv6_samples[i].readable_compact_addr, (const char *)&buffer); > + } > + > +} > + > +static void test_RtlIpv6AddressToStringW(void) > +{ > + const int testcount = sizeof(ipv6_samples) / sizeof(ipv6_samples[0]); > + int i; > + WCHAR buffer[INET6_ADDRSTRLEN]; > + WCHAR * res; > + > + if ( !pRtlIpv6AddressToStringW ) > + { > + win_skip("Method not supported\n"); > + return; > + } > + > + res = pRtlIpv6AddressToStringW((IN6_ADDR*) &ipv6_samples[0].expected_representation, (LPWSTR)&buffer); > + > + if ((void *)&buffer==(void *)res) > + { > + win_skip("No conversion expected with stub without inet_ntop\n"); > + return; > + } > + > + for (i=0; i<testcount; i++) > + { > + WCHAR buffer[INET6_ADDRSTRLEN]; > + WCHAR * res; > + WCHAR W_readable_addr[INET6_ADDRSTRLEN]; > + > + IN6_ADDR * in6; > + int expected_len, result_len; > + > + in6 = (IN6_ADDR*) &ipv6_samples[i].expected_representation; > + > + expected_len = strlen(ipv6_samples[i].readable_compact_addr); > + > + memset(&W_readable_addr,0, sizeof(W_readable_addr)); > + memset(&buffer,0, sizeof(W_readable_addr)); > + > + MultiByteToWideChar(CP_ACP,0,ipv6_samples[i].readable_compact_addr,expected_len,(LPWSTR)&W_readable_addr,expected_len); > + > + res = pRtlIpv6AddressToStringW(in6, (LPWSTR)&buffer); > + > + ok( '\0' == (WCHAR)(*res), > + "Pointer to 0 expected, got %s at %p+%p, full string '%s'\n", > + wine_dbgstr_wn(res, 1), buffer, res, wine_dbgstr_w((const WCHAR *)&buffer)); > + > + expected_len = lstrlenW((LPCWSTR)&W_readable_addr); > + result_len = lstrlenW((LPCWSTR)&buffer); > + > + ok( expected_len == result_len, > + "Unexpected resulting strlen, waited for %d, got %d\n", expected_len, result_len); > + > + ok( lstrcmpiW((LPCWSTR)&W_readable_addr, (LPCWSTR)&buffer) == 0, > + "IPv6 address strings are not equal, '%s' expected, got '%s'", > + wine_dbgstr_w((const WCHAR *)&W_readable_addr), wine_dbgstr_w((const WCHAR *)&buffer)); > } > } > > @@ -1779,8 +1895,8 @@ static void test_RtlDecompressBuffer(void) > /* regular tests for RtlDecompressBuffer */ > for (i = 0; i < sizeof(test_lznt) / sizeof(test_lznt[0]); i++) > { > - trace("Running test %d (compressed_size=%u, uncompressed_size=%u, status=0x%08x)\n", > - i, test_lznt[i].compressed_size, test_lznt[i].uncompressed_size, test_lznt[i].status); > + /* trace("Running test %d (compressed_size=%u, uncompressed_size=%u, status=0x%08x)\n", > + i, test_lznt[i].compressed_size, test_lznt[i].uncompressed_size, test_lznt[i].status); */ Any reason why you comment out traces in a completely unrelated test? ;) > > /* test with very big buffer */ > final_size = 0xdeadbeef; > @@ -2080,6 +2196,8 @@ START_TEST(rtl) > test_RtlIpv4AddressToString(); > test_RtlIpv4AddressToStringEx(); > test_RtlIpv4StringToAddress(); > + test_RtlIpv6AddressToStringA(); > + test_RtlIpv6AddressToStringW(); > test_LdrAddRefDll(); > test_LdrLockLoaderLock(); > test_RtlCompressBuffer(); >

1 0

Re: Hans Leidekker : bcrypt: Implement BCryptHashData.
by Bruno Jesus 06 Jan '16

06 Jan '16

On Thu, Jan 7, 2016 at 3:50 AM, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > + case ALG_ID_SHA384: > + CC_SHA384_Update( &hash->u.sha512_ctx, input, size ); > + break; > + > + case ALG_ID_SHA512: > + CC_SHA512_Update( &hash->u.sha512_ctx, input, size ); > + break; I missed this when I first saw the patches but in a second look and judging by the surrounding code I guess there is a copy&paste issue here. SHA384 should probably use &hash->u.sha384_ctx, no?

2 2

Re: msdrm: add stub dll
by Alex Henrie 06 Jan '16

06 Jan '16

diff --git a/configure.ac b/configure.ac index d47f7e9..69ab604 100644 --- a/configure.ac +++ b/configure.ac @@ -3009,6 +3009,7 @@ WINE_CONFIG_TEST(dlls/msctf/tests) WINE_CONFIG_DLL(msctfp,,[clean]) WINE_CONFIG_DLL(msdaps,,[clean]) WINE_CONFIG_DLL(msdelta) +WINE_CONFIG_DLL(msdrm) WINE_CONFIG_DLL(msdmo,,[implib]) WINE_CONFIG_TEST(dlls/msdmo/tests) WINE_CONFIG_DLL(msftedit) If you're going for alphabetical order, msdmo would come before msdrm. -Alex

1 0

Re: [PATCH] quartz: Handle NULL target format in FilterGraph::ConvertTimeFormat.
by Nikolay Sivov 06 Jan '16

06 Jan '16

On 05.01.2016 14:13, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > --- > dlls/quartz/filtergraph.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index 5b4b080..5cb670e 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -2530,6 +2530,9 @@ static HRESULT WINAPI MediaSeeking_ConvertTimeFormat(IMediaSeeking *iface, LONGL > if (!pSourceFormat) > pSourceFormat = &This->timeformatseek; > > + if (!pTargetFormat) > + pTargetFormat = &This->timeformatseek; > + > if (IsEqualGUID(pTargetFormat, pSourceFormat)) > *pTarget = Source; > else > Hi, Anton. According to msdn this looks correct to me. Could you add a simple test for that? Let's say one test with both formats as NULL; and a couple more with one format being NULL and another set to current format. Looks like it could be added easily to test_mediacontrol() as it has everything you'd need.

2 1

Wine Gecko 2.44-beta1
by Jacek Caban 06 Jan '16

06 Jan '16

Hi all, I prepared beta builds of the next Wine Gecko release. They are available via our new download site [1]. If you want to help testing, all that's needed is the attached patch (Wine will dowload the package for you). This build is based on Firefox 44 sources. It includes a few Wine-specific bug fixes. Also the way we hook IO in Gecko is redesigned. The new interface should be more stable and the code is cleaner. I think wine-staging may be a good way to have more testing before we do the final release. Please commit the patch to the tree. Thanks, Jacek [1] http://dl.winehq.org/wine/wine-gecko/2.44-beta1/

2 2

Re: [PATCH] mscoree: Set config path for default app domain
by Vincent Povirk 06 Jan '16

06 Jan '16

+ GetModuleFileNameA(NULL, base_dir, sizeof(base_dir)); + + slash = strrchr(base_dir, '\\'); + if (slash) + *slash = 0; + + TRACE("setting base_dir: %s, config_path: %s\n", base_dir, config_pathA); + mono_domain_set_config(This->default_domain, base_dir, config_pathA); Mono embedding api functions expect utf8-encoded paths. We need to use the W function and utf8-encode using WtoA.

1 0

Re: jscript: Added support for Function constructor called as a function.
by Marvin 06 Jan '16

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

1 0

Re: [PATCH 3/3] ddraw: Only allow DDSCAPS_MIPMAP on textures.
by Marvin 06 Jan '16

06 Jan '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=19462 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 2/3] ddraw/tests: Merge MipMapCreationTest() with test_mipmap_lock().
by Marvin 06 Jan '16

06 Jan '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=19461 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [7/8] bcrypt: Add support for SHA hashes on Linux using Nettle.
by Bruno Jesus 06 Jan '16

06 Jan '16

On Wed, Jan 6, 2016 at 8:19 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > configure.ac | 18 +++++++++ > dlls/bcrypt/Makefile.in | 1 + > dlls/bcrypt/bcrypt_main.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 114 insertions(+) Hi, Hans. Great job in the patch series, but Is this change really necessary? Can't we reuse the internal libraries from rsaenh? I think it was a copy of tomcrypt lib, I'm not able to check right now. By using rsaenh or moving the tomcrypt to a more generic place it could be reused without need for external dependencies, right? Unless I'm missing something obvious. Best wishes, Bruno

3 3

Re: [8/8] bcrypt/tests: Add tests for SHA hashes.
by Marvin 06 Jan '16

06 Jan '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=19459 Your paranoid android. === w864 (64 bit bcrypt) === bcrypt.c:259: Test failed: got c0000023 bcrypt.c:260: Test failed: hash not set bcrypt.c:263: Test failed: got c0000008 bcrypt.c:267: Test failed: got c0000008 bcrypt.c:268: Test failed: got 3735928559 bcrypt.c:269: Test failed: got 3735928559 bcrypt.c:273: Test failed: got c0000008 bcrypt.c:275: Test failed: got 0000000000000000000000000000000000000000000000000000000000000000 bcrypt.c:278: Test failed: got c000000d bcrypt.c:338: Test failed: got c0000023 bcrypt.c:339: Test failed: hash not set bcrypt.c:342: Test failed: got c0000008 bcrypt.c:346: Test failed: got c0000008 bcrypt.c:347: Test failed: got 3735928559 bcrypt.c:348: Test failed: got 3735928559 bcrypt.c:352: Test failed: got c0000008 bcrypt.c:354: Test failed: got 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 bcrypt.c:357: Test failed: got c000000d bcrypt.c:418: Test failed: got c0000023 bcrypt.c:419: Test failed: hash not set bcrypt.c:422: Test failed: got c0000008 bcrypt.c:426: Test failed: got c0000008 bcrypt.c:427: Test failed: got 3735928559 bcrypt.c:428: Test failed: got 3735928559 bcrypt.c:432: Test failed: got c0000008 bcrypt.c:434: Test failed: got 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 bcrypt.c:437: Test failed: got c000000d === w1064 (64 bit bcrypt) === bcrypt.c:180: Test failed: got c0000023 bcrypt.c:181: Test failed: hash not set bcrypt.c:184: Test failed: got c0000008 bcrypt.c:188: Test failed: got c0000008 bcrypt.c:189: Test failed: got 3735928559 bcrypt.c:190: Test failed: got 3735928559 bcrypt.c:194: Test failed: got c0000008 bcrypt.c:196: Test failed: got 0000000000000000000000000000000000000000 bcrypt.c:199: Test failed: got c000000d bcrypt.c:338: Test failed: got c0000023 bcrypt.c:339: Test failed: hash not set bcrypt.c:342: Test failed: got c0000008 bcrypt.c:346: Test failed: got c0000008 bcrypt.c:347: Test failed: got 3735928559 bcrypt.c:348: Test failed: got 3735928559 bcrypt.c:352: Test failed: got c0000008 bcrypt.c:354: Test failed: got 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 bcrypt.c:357: Test failed: got c000000d bcrypt.c:418: Test failed: got c0000023 bcrypt.c:419: Test failed: hash not set bcrypt.c:422: Test failed: got c0000008 bcrypt.c:426: Test failed: got c0000008 bcrypt.c:427: Test failed: got 3735928559 bcrypt.c:428: Test failed: got 3735928559 bcrypt.c:432: Test failed: got c0000008 bcrypt.c:434: Test failed: got 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 bcrypt.c:437: Test failed: got c000000d

1 0

Re: mshtml: Added IHTMLDocument4::hasFocus implementation.
by Marvin 06 Jan '16

06 Jan '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=19458 Your paranoid android. === wxppro (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w2003std (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === wvistau64 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w2008s64 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w7u (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w7pro64 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w8 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w864 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w1064 (32 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === wvistau64 (64 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w7pro64 (64 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff === w864 (64 bit dom) === dom.c:6263: Test failed: hasFocus returned 0, expected ffffffff

1 0

Re: [RFC] msvcp120: Change exported vbtable sizes.
by Piotr Caban 06 Jan '16

06 Jan '16

Hi, On 01/04/16 12:08, Bernhard Übelacker wrote: > The test contains 2 tests: > - Simply check the exports of the vbtable sizes for their values. This test needs some improvements before it can be accepted to wine. The structure sizes are different in 32-bit and 64-bit cases. > - Call constructor and destructor like it is done in Supertux. This test will need to be rewritten in order to get into wine. You should use vbtable while computing this pointer (you can tests values inside vbtable). The test should also be named differently (e.g. test_virtual_base_func_call). > I tried to add these 8 bytes as an unknown field to basic_istream_* > and basic_ostream_* structs. But then I cannot find a way to get the > sizes for basic_iostream_* right. I've tried to find what happens there. It looks like there's a bug in Visual Studio that is described here (sorry I couldn't find it on Microsoft pages): http://stackoverflow.com/questions/14487241/avoiding-an-inheritance-by-domi… I've tried looking on basic_istream_char class layout (32-bit): void* vbtable 4-byte padding int64 count 4-byte padding int vtordisp = 0 (as described https://msdn.microsoft.com/en-us/library/7sf3txa8%28v=vs.100%29.aspx) basic_ios_char I've also tried creating following classes and ended with a different layout: class vbase { public: int a; virtual ~vbase() {}; }; class c : virtual public vbase { public: int b; virtual ~c() {}; virtual _Add_vtordisp1() {}; }; c class has following layout (as expected): void *vtable; void *vbtable; int b; void *vtable; int a; if b is defined as offsetof the layout changes strangely (looks like there's another problem in compiler related to padding): void *vtable; 4-byte padding; void *vbtable; 4-byte padding int64 b void *vtable int a The difference shows that _Add_vtordisp1 and _Add_vtordisp2 are defined in basic_ios_char class. I don't understand yet why vtordisp is needed. It's kind of described here (https://msdn.microsoft.com/en-us/library/453x4xdd%28v=vs.100%29.aspx) but I don't understand it yet. Thanks, Piotr

2 3

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

06 Jan '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=19429 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\wtF7A6.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF7A6.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF7A6.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtF7A6.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtF7A6.tmp\test file.sde")]' shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF7A6.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF7A6.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\wt4B23.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt4B23.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt4B23.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2287: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt4B23.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: [PATCH] kernel32: Clamp maximum console window size to screen buffer size.
by Sebastian Lackner 06 Jan '16

06 Jan '16

On 06.01.2016 05:26, Hugh McMaster wrote: > From: Sebastian Lackner <sebastian(a)fds-team.de> > > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/console.c | 4 ++-- > dlls/kernel32/tests/console.c | 9 +++++++++ > 2 files changed, 11 insertions(+), 2 deletions(-) Thanks for adding your sign-off. Please note that there is no need to resend the patch itself, if you don't do any changes. A mail just with "Signed-off-by: ..." as reply to wine-patches(a)winehq.org is sufficient, and makes it easier to review.

2 2

kernel32: add GetConsoleScreenBufferInfoEx/SetConsoleScreenBufferInfoEx stubs (try 2)
by Hugh McMaster 06 Jan '16

06 Jan '16

On Tuesday, 5 Jan 2016 13:10:14 -0600, Austin English wrote: +BOOL WINAPI GetConsoleScreenBufferInfoEx(HANDLE output, CONSOLE_SCREEN_BUFFER_INFOEX *buffer) +{ + FIXME("(%p %p): stub!\n", output, buffer); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return FALSE; +} + +BOOL WINAPI SetConsoleScreenBufferInfoEx(HANDLE output, CONSOLE_SCREEN_BUFFER_INFOEX *buffer) +{ + FIXME("(%p %p): stub!\n", output, buffer); + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); + return FALSE; +} Would you mind resending this patch with HANDLE hConsole and CONSOLE_SCREEN_BUFFER_INFOEX *csbix?

1 0

Re: [PATCH] kernel32: Clamp maximum console window size to screen buffer size.
by Marvin 06 Jan '16

06 Jan '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=19422 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

1 0

RE: [PATCH 4/5] kernel32/tests: Refresh the console to clear the console font table
by Hugh McMaster 06 Jan '16

06 Jan '16

On Tuesday, 5 Jan 2016 16:21:51 +0100, Sebastian Lackner wrote: > > On 05.01.2016 08:59, Hugh McMaster wrote: > > The testScreenBuffer function unintentionally causes the console > > font table to increase from 14 entries to about 40. This patch restores the font table. > > > > Signed-off-by: Hugh McMaster > > --- > > dlls/kernel32/tests/console.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > Signed-off-by: Sebastian Lackner > > (It would look better if we could restore it in the corresponding test itself, but at least I'm fine with this solution.) I'm not sure it's possible to restore the console font table from the test, but I'll take a look.

2 1

Re: kernel32: Clamp maximum console window size to screen buffer size.
by Marvin 06 Jan '16

06 Jan '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=19420 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Re: [PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().
by Stefan Dösinger 05 Jan '16

05 Jan '16

> Am 04.01.2016 um 14:11 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>: > > This fixes commit b0d4502c29941c31108a53d6c23f9e23196fb7ec. I asked Riccardo about this init change in an earlier version, and afair he said creating cubemaps without a device crashes on some Windows drivers. I can't find the exchange in the archives, it was probably on IRC. Riccardo, do you remember why you made this change? > - if ((test_data[i].caps2 & DDSCAPS2_CUBEMAP) > - && !(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP)) > - { > - skip("Device does not support cubemaps.\n"); > - continue; > - } You're creating cubemaps without checking for support now.

3 3

Re: [PATCH 3/5] wined3d: Set WINED3D_BUFFER_DOUBLEBUFFER for managed buffers as well.
by Marvin 05 Jan '16

05 Jan '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=19408 Your paranoid android. === w1064 (32 bit device) === device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2618: Test failed: The focus window is active. device.c:2626: Test failed: Got unexpected hr 0x88760869. device.c:2632: Test failed: Got unexpect screen size 800x600. device.c:2647: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2656: Test failed: Got unexpect screen size 800x600. device.c:2669: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2677: Test failed: Got unexpect width 640. device.c:2678: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().
by Marvin 05 Jan '16

05 Jan '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=19406 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Testbot build VM is offline
by Hugh McMaster 05 Jan '16

05 Jan '16

The Build VM / vm4 is currently offline. Judging by the test queue, it has been offline since 3 January, 23:30 (UTC+1). Francois, I imagine this is for maintenance? -- Hugh McMaster

2 1

Re: [1/2] kernel32: add stub for GetSystemPreferredUILanguages
by Matteo Bruni 05 Jan '16

05 Jan '16

2015-12-30 10:21 GMT+01:00 Stefan Leichter <Stefan.Leichter(a)camline.com>: > The function is called from VSWinExpress.exe (Visual Studio 2013/12.0 > Express Edition) > > Signed-off-by: Stefan Leichter <Stefan.Leichter(a)camLine.com> > --- > .../api-ms-win-core-localization-l1-2-0.spec | 2 +- > .../api-ms-win-core-localization-l1-2-1.spec | 2 +- > dlls/kernel32/kernel32.spec | 2 +- > dlls/kernel32/locale.c | 26 > ++++++++++++++++++++++ > include/winnls.h | 1 + > 5 files changed, 30 insertions(+), 3 deletions(-) Just a drive-by comment: I think it would be nicer if the FIXME was at the start of the function i.e. before the early returns. I would also replace PULONG and PZZWSTR with ULONG * and WCHAR *, not sure what's the convention in kernel32 though.

2 1

Re: [PATCH 5/5] kernel32/tests: Add tests for GetLargestConsoleWindowSize
by Marvin 05 Jan '16

05 Jan '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=19405 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Re: [PATCH 4/5] kernel32/tests: Refresh the console to clear the console font table
by Marvin 05 Jan '16

05 Jan '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=19404 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Re: [PATCH 9/9] programs/plugplay.exe: Add Linux udev hidraw bus
by Damjan Jovanovic 05 Jan '16

05 Jan '16

Using poll() would be better than select() here, as select() not only has a limit on the number of fds that can be polled, but cannot even deal with a single fd whose number is above the same limit, which could happen if many files are already open by that process. That limit is as low as 1024, and needs patching and recompiling both the kernel and libc on Linux IIRC. We already went through a round of converting all Wine source from select() to poll(). udev is also Linux-only - the *BSDs are left out in the cold. Nice work otherwise, I expected it to take you much longer. Damjan On Mon, Jan 4, 2016 at 7:36 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > programs/plugplay/Makefile.in | 1 + > programs/plugplay/bus_hidraw.c | 264 > +++++++++++++++++++++++++++++++++++++++++ > programs/plugplay/main.c | 3 + > programs/plugplay/pnp.h | 1 + > 4 files changed, 269 insertions(+) > create mode 100644 programs/plugplay/bus_hidraw.c > > > > > >

1 0

[PATCH] ntdll/tests: Correct signaled / not signaled error messages.
by Alex Henrie 05 Jan '16

05 Jan '16

Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- dlls/ntdll/tests/file.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c index b8f1847..7bf2ffe 100644 --- a/dlls/ntdll/tests/file.c +++ b/dlls/ntdll/tests/file.c @@ -677,7 +677,7 @@ static void read_file_test(void) apc_count = 0; U(iosb).Status = 0xdeadbabe; iosb.Information = 0xdeadbeef; - ok( !is_signaled( read ), "read handle is not signaled\n" ); + ok( !is_signaled( read ), "read handle is signaled\n" ); status = pNtReadFile( read, 0, apc, &apc_count, &iosb, buffer, 1, NULL, NULL ); ok( status == STATUS_PENDING, "wrong status %x\n", status ); ok( !is_signaled( read ), "read handle is signaled\n" ); @@ -690,7 +690,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == 0, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 1, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( read ), "read handle is signaled\n" ); + ok( is_signaled( read ), "read handle is not signaled\n" ); ok( !apc_count, "apc was called\n" ); apc_count = 0; SleepEx( 1, FALSE ); /* non-alertable sleep */ @@ -731,7 +731,7 @@ static void read_file_test(void) ok(ret && written == 1, "WriteFile error %d\n", GetLastError()); /* partial read is good enough */ Sleep(1); /* FIXME: needed for wine to run the i/o apc */ - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( U(iosb).Status == 0, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 1, "wrong info %lu\n", iosb.Information ); ok( !apc_count, "apc was called\n" ); @@ -762,7 +762,7 @@ static void read_file_test(void) ok( status == STATUS_INVALID_HANDLE, "wrong status %x\n", status ); ok( U(iosb).Status == 0xdeadbabe, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0xdeadbeef, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); /* not reset on invalid handle */ + ok( is_signaled( event ), "event is not signaled\n" ); /* not reset on invalid handle */ ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( !apc_count, "apc was called\n" ); @@ -782,7 +782,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == STATUS_PIPE_BROKEN, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -807,7 +807,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == STATUS_CANCELLED, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -833,7 +833,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == STATUS_CANCELLED, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -859,7 +859,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == STATUS_CANCELLED, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -885,7 +885,7 @@ static void read_file_test(void) Sleep(1); /* FIXME: needed for wine to run the i/o apc */ ok( U(iosb).Status == STATUS_CANCELLED, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 2, "apc was not called\n" ); @@ -906,7 +906,7 @@ static void read_file_test(void) if (status == STATUS_PENDING) WaitForSingleObject( event, 1000 ); ok( U(iosb).Status == STATUS_SUCCESS, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == strlen(text), "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -923,7 +923,7 @@ static void read_file_test(void) if (status == STATUS_PENDING) WaitForSingleObject( event, 1000 ); ok( U(iosb).Status == STATUS_SUCCESS, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == strlen(text), "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -940,7 +940,7 @@ static void read_file_test(void) WaitForSingleObject( event, 1000 ); ok( U(iosb).Status == STATUS_END_OF_FILE, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == 0, "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -961,7 +961,7 @@ static void read_file_test(void) if (status == STATUS_PENDING) WaitForSingleObject( event, 1000 ); ok( U(iosb).Status == STATUS_SUCCESS, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == strlen(text), "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ ok( apc_count == 1, "apc was not called\n" ); @@ -975,7 +975,7 @@ static void read_file_test(void) ok( status == STATUS_SUCCESS, "wrong status %x\n", status ); ok( U(iosb).Status == STATUS_SUCCESS, "wrong status %x\n", U(iosb).Status ); ok( iosb.Information == strlen(text), "wrong info %lu\n", iosb.Information ); - ok( is_signaled( event ), "event is signaled\n" ); + ok( is_signaled( event ), "event is not signaled\n" ); ok( !apc_count, "apc was called\n" ); SleepEx( 1, TRUE ); /* alertable sleep */ todo_wine ok( !apc_count, "apc was called\n" ); -- 2.6.4

1 0

read_file_test doesn't look right
by Alex Henrie 05 Jan '16

05 Jan '16

Dear Mike and Alexandre, The function read_file_test in dlls/ntdll/tests/file.c [1] has a lot of lines like this: ok( is_signaled( event ), "event is not signaled\n" ); This makes sense to me. The first parameter is the condition we want (a signal), and the second parameter is the error message to display if we didn't get what we want (no signal). However, there are also a lot of lines like this: ok( is_signaled( event ), "event is signaled\n" ); Either this is a mistake or in some cases a zero return value does indicate that the event was signaled. What is going on here? I made a patch to make these messages look like I think they should. If you approve, I will send the patch on to wine-patches. -Alex [1] https://source.winehq.org/git/wine.git/blob/93d7356290bfe5bfd2104f985927908…

1 0

Re: [PATCH 3/5] winex11.drv: Only update drop effect if IDropTarget::DragOver returned S_OK
by Matteo Bruni 04 Jan '16

04 Jan '16

2015-12-21 11:21 GMT+01:00 Piotr Caban <piotr(a)codeweavers.com>: diff --git a/dlls/winex11.drv/xdnd.c b/dlls/winex11.drv/xdnd.c index d5881ad..841eaff 100644 --- a/dlls/winex11.drv/xdnd.c +++ b/dlls/winex11.drv/xdnd.c @@ -325,7 +325,7 @@ void X11DRV_XDND_PositionEvent( HWND hWnd, XClientMessageEvent *event ) if (dropTarget) { hr = IDropTarget_DragOver(dropTarget, MK_LBUTTON, pointl, &effect); - if (SUCCEEDED(hr)) + if (hr != S_OK) XDNDDropEffect = effect; else WARN("IDropTarget_DragOver failed, error 0x%08X\n", hr); Doesn't that do the opposite of what the patch title says?

1 0

Re: [PATCH 2/3] d3dx9_36: Store all values passed to the create and return them in the correct functions
by Matteo Bruni 04 Jan '16

04 Jan '16

2015-12-23 7:47 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > static ULONG WINAPI d3dx9_animation_controller_AddRef(ID3DXAnimationController *iface) > { > - struct d3dx9_animation_controller *animation = impl_from_ID3DXAnimationController(iface); > - ULONG refcount = InterlockedIncrement(&animation->ref); > + struct d3dx9_animation_controller *This = impl_from_ID3DXAnimationController(iface); > + ULONG refcount = InterlockedIncrement(&This->ref); > > - TRACE("%p increasing refcount to %u.\n", animation, refcount); > + TRACE("%p increasing refcount to %u.\n", This, refcount); These changes don't seem useful, especially considering that these lines were introduced in the previous patch. More of it below, same comment applies. FWIW I prefer "animation" to "This".

1 0

Re: [PATCH 1/3] d3dx9_36: Implement D3DXCreateAnimationController with a stubbed ID3DXAnimationController interface.
by Matteo Bruni 04 Jan '16

04 Jan '16

2015-12-23 7:47 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> Hi Alistair, some nitpicking... Please use the "d3dx9:" prefix for this and the other patches. > +static HRESULT WINAPI d3dx9_animation_controller_QueryInterface(ID3DXAnimationController *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_ID3DXAnimationController)) > + { > + IUnknown_AddRef(iface); > + *out = iface; I think this is usually done as "*out = &animation->ID3DXAnimationController_iface" or similar (where "animation" is the result of impl_from_ID3DXAnimationController(iface)). > + return D3D_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE\n", debugstr_guid(riid)); > + > + *out = NULL; > + return E_NOINTERFACE; > +} Similarly this is usually written in a slightly different way. Please follow the style of the other (recent) QueryInterface implementations, we are pretty consistent now and it would be nice to preserve that consistency. > +static DOUBLE WINAPI d3dx9_animation_controller_GetTime(ID3DXAnimationController *iface) Can this (and the other instances of it in the patch) simply use "double" instead? Apparently the only difference between the two is that DOUBLE sometimes forces alignment to 8 bytes. That should only matter for struct fields though, as far as we are concerned, so we should probably prefer plain double. > +/*********************************************************************** > + * D3DXCreateAnimationController (D3DX9_36.@) > + */ It doesn't really matter but this comment is unnecessary. > +HRESULT WINAPI D3DXCreateAnimationController(UINT MaxNumAnimationOutputs, UINT MaxNumAnimationSets, > + UINT MaxNumTracks, UINT MaxNumEvents, ID3DXAnimationController **AnimationController) Please use the usual "lowercase and underscores" style for the parameter names. Also check the '*' placement a couple of lines below.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 10).
by Aaryaman Vasishta 04 Jan '16

04 Jan '16

Now that I'm not using CreateDIBSection, I should probably remove the gdi32 dependency as well (Thanks to nsivov for pointing that out). I'll resend the patch after your review (if there's any more changes required) so that way I can get both done at the same time. Cheers, Aaryaman On Tue, Jan 5, 2016 at 12:21 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > try 10: Fix XP test failures. > Added bitmap generation function to generate bitmaps at runtime. > > Signed-off-by: Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > --- > dlls/d3drm/tests/Makefile.in | 2 +- > dlls/d3drm/tests/d3drm.c | 320 > +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 321 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3drm/tests/Makefile.in b/dlls/d3drm/tests/Makefile.in > index 4b39989..76613e2 100644 > --- a/dlls/d3drm/tests/Makefile.in > +++ b/dlls/d3drm/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = d3drm.dll > -IMPORTS = dxguid uuid d3drm ddraw user32 > +IMPORTS = dxguid uuid d3drm ddraw user32 gdi32 > > C_SRCS = \ > d3drm.c \ > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 06c2c54..9cabbe6 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -2,6 +2,7 @@ > * Copyright 2010, 2012 Christian Costa > * Copyright 2012 André Hentschel > * Copyright 2011-2014 Henri Verbeet for CodeWeavers > + * Copyright 2014-2015 Aaryaman Vasishta > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -3693,6 +3694,324 @@ static void test_create_device_from_d3d3(void) > DestroyWindow(window); > } > > +static char *create_bitmap(const char *filename, int w, int h, BOOL > palettized) > +{ > + static char path[MAX_PATH]; > + HANDLE file; > + BITMAPFILEHEADER file_header; > + BITMAPINFOHEADER info_header; > + BITMAPINFO *info = NULL; > + const int bpp = palettized ? 8 : 24; > + unsigned char *buffer = NULL; > + DWORD written, size; > + int i, j; > + > + /* Calculate size of the BITMAPINFO header */ > + /* Space for 256 color palette would need to be allocated if the > bitmap is 8bpp */ > + size = sizeof(BITMAPINFOHEADER); > + if (palettized) > + size += sizeof(RGBQUAD)* 256; > + > + memset(&file_header, 0, sizeof(BITMAPFILEHEADER)); > + file_header.bfType = 0x4d42; /* BM */ > + file_header.bfOffBits = sizeof(BITMAPFILEHEADER)+size; > + file_header.bfSize = ((((w * bpp + 31) & ~31) >> 3) * h) + > file_header.bfOffBits; > + memset(&info_header, 0, sizeof(BITMAPINFOHEADER)); > + info_header.biSize = sizeof(BITMAPINFOHEADER); > + info_header.biBitCount = bpp; > + info_header.biPlanes = 1; > + info_header.biWidth = w; > + info_header.biHeight = h; > + info_header.biCompression = BI_RGB; > + > + if (palettized) > + { > + info = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + /* Create a 256 color palette for 8bpp bitmap */ > + for (i = 0; i < 256; i++) > + { > + info->bmiColors[i].rgbBlue = i; > + info->bmiColors[i].rgbGreen = i; > + info->bmiColors[i].rgbRed = i; > + } > + } > + else > + info = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > sizeof(*info)); > + info->bmiHeader = info_header; > + > + /* Create the bitmap file */ > + GetTempPathA(sizeof(path) / sizeof(char), path); > + lstrcatA(path, filename); > + file = CreateFileA(path, GENERIC_READ | GENERIC_WRITE, 0, NULL, > CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation failed, at %s, error > %d\n", path, > + GetLastError()); > + > + /* Write the file header, followed by the BITMAPINFO header */ > + WriteFile(file, &file_header, sizeof(BITMAPFILEHEADER), &written, > NULL); > + ok(written == sizeof(BITMAPFILEHEADER), "Couldn't write bitmap file > header.\n"); > + WriteFile(file, info, size, &written, NULL); > + ok(written == size, "Couldn't write bitmap info header.\n"); > + > + size = file_header.bfSize; > + buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + > + /* Saving pixels by directly accessing bitmap buffer is faster than > using SetPixel */ > + for (i = 0, j = 0; i < size;) > + { > + if (palettized) > + { > + buffer[i++] = j++; > + j %= 256; > + } > + else > + { > + buffer[i++] = j % 251; > + buffer[i++] = j % 239; > + buffer[i++] = j++ % 247; > + } > + } > + > + /* Finally, write the bitmap pixels */ > + WriteFile(file, buffer, size, &written, NULL); > + ok(written == size, "Couldn't write bitmap pixels.\n"); > + > + CloseHandle(file); > + HeapFree(GetProcessHeap(), 0, buffer); > + > + return path; > +} > + > +static BOOL test_bitmap_data(const int test_num, const char *file, > D3DRMIMAGE *img, BOOL upside_down) > +{ > + const int w = img->width; > + const int h = img->height; > + int i, j, k = 0, offset, depth, expected; > + BOOL val1, val2, val3, ret = TRUE; > + BITMAPFILEHEADER *bmp_header = NULL; > + BITMAPINFO *bmp_info = NULL; > + BITMAPINFOHEADER info_header; > + HANDLE hfile = NULL, hmapping = NULL; > + DWORD size; > + BOOL check; > + unsigned char *buffer = NULL, *buffer1 = NULL, *buffer2 = NULL; > + > + buffer1 = (unsigned char *)img->buffer1; > + hfile = CreateFileA(file, GENERIC_READ, FILE_SHARE_READ, 0, > OPEN_EXISTING, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "Failed to open file at %s, error %d > (test %d)\n", file, > + GetLastError(), test_num); > + if (hfile == INVALID_HANDLE_VALUE) > + goto cleanup; > + > + size = GetFileSize(hfile, NULL); > + ok(size != INVALID_FILE_SIZE, "Failed to get file size, error %d > (test %d)\n", GetLastError(), test_num); > + > + hmapping = CreateFileMappingA(hfile, NULL, PAGE_READONLY, 0, 0, NULL); > + ok(hmapping != NULL, "Cannot create file mapping (error = %d, test > %d).\n", GetLastError(), test_num); > + if (hmapping == NULL) > + goto cleanup; > + > + buffer = MapViewOfFile(hmapping, FILE_MAP_READ, 0, 0, 0); > + ok(buffer != NULL, "Cannot create map view of file (error = %d, test > %d).\n", GetLastError(), test_num); > + if (buffer == NULL) > + goto cleanup; > + > + bmp_header = (BITMAPFILEHEADER *)buffer; > + bmp_info = (BITMAPINFO *)((unsigned char *)buffer + > sizeof(BITMAPFILEHEADER)); > + info_header = bmp_info->bmiHeader; > + ok(info_header.biWidth == w, "Expected texture width == %d, got %d > (test %d).\n", info_header.biWidth, w, test_num); > + ok(info_header.biHeight == h, "Expected texture height == %d, got %d > (test %d).\n", info_header.biHeight, h, test_num); > + depth = info_header.biBitCount; > + > + buffer2 = (unsigned char *)buffer + bmp_header->bfOffBits; > + > + if (img->palette) > + { > + ok(img->depth == 8, "Expected texture bpp == 8, got %d (test > %d).\n", img->depth, test_num); > + if (depth == 8) > + { > + /* bytes_per_line is not always aligned by d3drm depending on > the format */ > + expected = info_header.biWidth; > + ok(expected == img->bytes_per_line, "Expected bytes per line > == %d, got %d (test %d).\n", expected, img->bytes_per_line, test_num); > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (img->bytes_per_line * (h - i - > 1)) : (img->bytes_per_line * i); > + for (j = 0; j < w; j++) > + { > + if (buffer1[k++] != buffer2[offset++]) > + { > + ret = FALSE; > + goto cleanup; > + } > + } > + } > + } > + else > + { > + /* In this case, bytes_per_line is aligned to the nearest > multiple of 4 from width */ > + expected = (info_header.biWidth + 3) & ~3; > + ok(expected == img->bytes_per_line, "Expected bytes per line > == %d, got %d (test %d).\n", expected, img->bytes_per_line, test_num); > + /* The image is palettized if the total number of colors used > is <= 256. */ > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (w * (h - i - 1) * 3) : (w * i * > 3); > + for (j = 0; j < w; j++) > + { > + val1 = img->palette[buffer1[k + j]].blue == > buffer2[offset]; > + val2 = img->palette[buffer1[k + j]].green == > buffer2[offset + 1]; > + val3 = img->palette[buffer1[k + j]].red == > buffer2[offset + 2]; > + if (!(val1 && val2 && val3)) > + { > + ret = FALSE; > + goto cleanup; > + } > + offset += 3; > + } > + k += img->bytes_per_line; > + } > + } > + } > + else > + { > + /* d3drm aligns the 24bpp texture to 4 bytes in the buffer, with > one bype padding from 24bpp texture. */ > + ok(img->depth == 32, "Expected texture bpp == 32, got %d (test > %d).\n", img->depth, test_num); > + expected = info_header.biWidth * 4; > + ok(expected == img->bytes_per_line, "Expected bytes per line == > %d, got %d (test %d).\n", expected, img->bytes_per_line, test_num); > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (w * (h - i - 1) * 3) : (w * i * 3); > + for (j = 0; j < w; j++) > + { > + val1 = buffer1[k] == buffer2[offset]; > + val2 = buffer1[k + 1] == buffer2[offset + 1]; > + val3 = buffer1[k + 2] == buffer2[offset + 2]; > + if (!(val1 && val2 && val3)) > + { > + ret = FALSE; > + goto cleanup; > + } > + k += 4; > + offset += 3; > + } > + } > + } > + > +cleanup: > + UnmapViewOfFile(buffer); > + CloseHandle(hmapping); > + CloseHandle(hfile); > + check = DeleteFileA(file); > + ok(check, "Cannot delete image stored in %s (error = %d, test > %d).\n", file, GetLastError(), test_num); > + return ret; > +} > + > +static void test_load_texture(void) > +{ > + struct texture_test > + { > + int version; > + int w; > + int h; > + BOOL palettized; > + }; > + static const struct texture_test tests[] = > + { > + { 1, 100, 100, TRUE }, > + { 1, 99, 100, TRUE }, > + { 1, 100, 100, FALSE }, > + { 1, 99, 100, FALSE }, > + { 1, 3, 39, FALSE }, > + { 2, 100, 100, TRUE }, > + { 2, 99, 100, TRUE }, > + { 2, 100, 100, FALSE }, > + { 2, 99, 100, FALSE }, > + { 2, 3, 39, FALSE }, > + { 3, 100, 100, TRUE }, > + { 3, 99, 100, TRUE }, > + { 3, 100, 100, FALSE }, > + { 3, 99, 100, FALSE }, > + { 3, 3, 39, FALSE }, > + }; > + HRESULT hr; > + IDirect3DRM *d3drm1 = NULL; > + IDirect3DRM2 *d3drm2 = NULL; > + IDirect3DRM3 *d3drm3 = NULL; > + IDirect3DRMTexture *texture1 = NULL; > + IDirect3DRMTexture2 *texture2 = NULL; > + IDirect3DRMTexture3 *texture3 = NULL; > + D3DRMIMAGE *d3drm_img = NULL; > + BOOL check; > + char *file = NULL; > + const int num_tests = sizeof(tests) / sizeof(*tests); > + int i; > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", > hr); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void > **)&d3drm2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRM2 interface (hr = %x)\n", > hr); > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM3, (void > **)&d3drm3); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRM3 interface (hr = %x)\n", > hr); > + > + for (i = 0; i < num_tests; i++) > + { > + switch (tests[i].version) > + { > + case 1: > + file = create_bitmap("test.bmp", tests[i].w, tests[i].h, > tests[i].palettized); > + hr = IDirect3DRM_LoadTexture(d3drm1, file, &texture1); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", > hr); > + d3drm_img = IDirect3DRMTexture_GetImage(texture1); > + todo_wine ok(d3drm_img != NULL, "Could not get a > D3DRMIMAGE struct from texture.\n"); > + if (d3drm_img == NULL) > + { > + IDirect3DRMTexture_Release(texture1); > + goto cleanup; > + } > + check = test_bitmap_data(i, file, d3drm_img, FALSE); > + ok(check, "Buffer contents do not match that of bitmap > (test %d).\n", i); > + IDirect3DRMTexture_Release(texture1); > + break; > + case 2: > + file = create_bitmap("test.bmp", tests[i].w, tests[i].h, > tests[i].palettized); > + hr = IDirect3DRM2_LoadTexture(d3drm2, file, &texture2); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", > hr); > + d3drm_img = IDirect3DRMTexture2_GetImage(texture2); > + todo_wine ok(d3drm_img != NULL, "Could not get a > D3DRMIMAGE struct from texture.\n"); > + check = test_bitmap_data(i, file, d3drm_img, TRUE); > + ok(check, "Buffer contents do not match that of bitmap > (test %d).\n", i); > + IDirect3DRMTexture2_Release(texture2); > + break; > + case 3: > + file = create_bitmap("test.bmp", tests[i].w, tests[i].h, > tests[i].palettized); > + hr = IDirect3DRM3_LoadTexture(d3drm3, file, &texture3); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", > hr); > + d3drm_img = IDirect3DRMTexture3_GetImage(texture3); > + todo_wine ok(d3drm_img != NULL, "Could not get a > D3DRMIMAGE struct from texture.\n"); > + check = test_bitmap_data(i, file, d3drm_img, TRUE); > + ok(check, "Buffer contents do not match that of bitmap > (test %d).\n", i); > + IDirect3DRMTexture3_Release(texture3); > + break; > + } > + } > + > + /* Test whether querying a version 1 texture from version 3 causes a > change in the loading behavior */ > + file = create_bitmap("test.bmp", 3, 39, FALSE); > + hr = IDirect3DRM3_LoadTexture(d3drm3, file, &texture3); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", hr); > + hr = IDirect3DRMTexture3_QueryInterface(texture3, > &IID_IDirect3DRMTexture, (void **)&texture1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMTexture interface (hr = > %x)\n", hr); > + d3drm_img = IDirect3DRMTexture_GetImage(texture1); > + check = test_bitmap_data(num_tests + 1, file, d3drm_img, TRUE); > + ok(check, "Buffer contents do not match that of bitmap (test %d).\n", > num_tests + 1); > + IDirect3DRMTexture_Release(texture1); > + IDirect3DRMTexture3_Release(texture3); > + > +cleanup: > + IDirect3DRM3_Release(d3drm3); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM_Release(d3drm1); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -3720,4 +4039,5 @@ START_TEST(d3drm) > test_create_device_from_d3d1(); > test_create_device_from_d3d2(); > test_create_device_from_d3d3(); > + test_load_texture(); > } > -- > 2.3.2 (Apple Git-55) > >

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 9).
by Marvin 04 Jan '16

04 Jan '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=19398 Your paranoid android. === wxppro (32 bit d3drm) === d3drm.c:3777: Test failed: Couldn't write bitmap pixels. d3drm.c:3972: Test failed: Buffer contents do not match that of bitmap (test 4). d3drm.c:3777: Test failed: Couldn't write bitmap pixels. d3drm.c:3830: Test failed: Expected texture bpp == 8, got 4 (test 9). d3drm.c:3853: Test failed: Expected bytes per line == 4, got 2 (test 9). d3drm.c:3982: Test failed: Buffer contents do not match that of bitmap (test 9). d3drm.c:3777: Test failed: Couldn't write bitmap pixels. d3drm.c:3830: Test failed: Expected texture bpp == 8, got 4 (test 14). d3drm.c:3853: Test failed: Expected bytes per line == 4, got 2 (test 14). d3drm.c:3992: Test failed: Buffer contents do not match that of bitmap (test 14). d3drm.c:3777: Test failed: Couldn't write bitmap pixels. d3drm.c:3830: Test failed: Expected texture bpp == 8, got 4 (test 16). d3drm.c:3853: Test failed: Expected bytes per line == 4, got 2 (test 16). d3drm.c:4006: Test failed: Buffer contents do not match that of bitmap (test 16).

2 1

Re: [PATCH] usp10: rewrite ScriptXtoCP
by Marvin 04 Jan '16

04 Jan '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=19394 Your paranoid android. === wvistau64 (32 bit usp10) === No test summary line found Failure running script in VM: network read timed out (wait2:ListSize:0/4) === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: [PATCH 3/5] wined3d: Set WINED3D_BUFFER_DOUBLEBUFFER for managed buffers as well.
by Marvin 04 Jan '16

04 Jan '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=19397 Your paranoid android. === w1064 (32 bit device) === device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2618: Test failed: The focus window is active. device.c:2626: Test failed: Got unexpected hr 0x88760869. device.c:2632: Test failed: Got unexpect screen size 800x600. device.c:2647: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2656: Test failed: Got unexpect screen size 800x600. device.c:2669: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2677: Test failed: Got unexpect width 640. device.c:2678: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 2/5] ddraw/tests: Don't require a 3D device for test_resource_priority().
by Marvin 04 Jan '16

04 Jan '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=19395 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 8).
by Stefan Dösinger 04 Jan '16

04 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-02 um 22:57 schrieb Aaryaman Vasishta: > + for (i = 0, j = 0; i < size;) > + { > + if (palettized) > + { > + buffer[i++] = j; > + buffer[i++] = j; > + buffer[i++] = j++; > + j %= 256; > + } You're still initializing 3 pixels here. This will go wrong if size isn't a multiple of 3. > +struct texture_test > +{ > + int version; > + int w; > + int h; > + BOOL palettized; > + BOOL upside_down; > +}; upside_down is unused. You can make this an anonymous structure: static void test_load_texture(void) { static const struct { int version; ... } tests[] = { { 1, 100, 100, TRUE }, ... }; ... } No need to have a global struct declaration. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWiXP7AAoJEN0/YqbEcdMwuhgP/0hLiEmRWbxxxfpe7ndxtq1Z DdbBsB3Mzd2r062tVeFl5fM2zxTAfD0XIHBEnJiAXgbkvZYfJelc9oWzU+k6dbb3 SnpbxGQo0K9YQQMXMxQwAcd6e72dNysEEEF66wowLoyYuSej5uHm4CKr030s9qAN 14Dkr+3O5yXXHGLewKaFptOnePBEhRNPKo2xxV2QNJRlA4Vl+Cck+89O6yW2iGjS /ubaZ72wYlZaC14AiYGaUof0oYsyf2GjneyxKWbGxsy9oieB8JayCDaajtNjo7Pi WpunKlMzbi+mQgJ0lAloFcyuEKfZQBboMWCibkOIAJc4jyT4FMls77cPUme0wKBA AR7vSupCSTxVKucbppEuI0Wbaaa/t9UycAB+WnTsm0Vvj4/NC+eXDz6GFhk41Els C5wlSfKCFetPP/ItZKLwI/4nSNRHehfv51T0LwS0DcPe3BGSMaxYcYP6OnHvc/nk zZzUresWwyUXq4Sk6/XdTjcMQ+SUZeBRCDPDpQivuvY2I3ABz2AeuCgNk0viGJyp SROL+bpF2YGU+Fr3sD306fIE3nd4q0sUQ71BwAQ49Kj5ZuFfjv9/RvL8JL0Ao0YP OP3esHNFazQIVMNXwuEVK3YMPnQqN2smHcVPgBPYbC75BB2KciAkKqjCdnsJ2wua 3zutYgIYY7j/HkhfmCgX =3JVE -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/6] wined3d: Add support for buffers in wined3d_device_update_sub_resource().
by Henri Verbeet 04 Jan '16

04 Jan '16

On 1 January 2016 at 18:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3989,6 +3989,17 @@ void CDECL wined3d_device_update_sub_resource(struct wined3d_device *device, str > TRACE("device %p, resource %p, sub_resource_idx %u, box %p, data %p, row_pitch %u, depth_pitch %u.\n", > device, resource, sub_resource_idx, box, data, row_pitch, depth_pitch); > > + if (resource->type == WINED3D_RTYPE_BUFFER) > + { > + struct wined3d_buffer *buffer = buffer_from_resource(resource); > + HRESULT hr; > + > + if (FAILED(hr = wined3d_buffer_upload_data(buffer, box, data))) > + WARN("Failed to update buffer data, hr %#x.\n", hr); > + > + return; > + } Are the sub_resource_idx and row_pitch/depth_pitch parameters validated in any way for buffer resources?

2 1

Re: [RFC] msvcp120: Change exported vbtable sizes.
by Marvin 04 Jan '16

04 Jan '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=19384 Your paranoid android. === w2008s64 (32 bit msvcp120) === msvcp120: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit msvcp120) === msvcp120.c:1862: Test failed: vbtable[1] wrong, got 0x10 msvcp120.c:1863: Test failed: vbtable[1] wrong, got 0x10 msvcp120.c:1864: Test failed: vbtable[1] wrong, got 0x10

1 0

Re: [4/6] gdi32: Fix the advance width in synthetic bold glyphs with scaling.
by Huw Davies 04 Jan '16

04 Jan '16

On Thu, Dec 31, 2015 at 01:33:16PM +0900, Akihiro Sagawa wrote: > @@ -6955,14 +6972,18 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, > vec.x = metrics.horiAdvance; > vec.y = 0; > pFT_Vector_Transform(&vec, &transMat); > - gm.gmCellIncY = -((vec.y+63) >> 6); > + if (font->fake_bold) > + fake_bold_adv = normalize_vector(&vec); > + else > + fake_bold_adv.x = fake_bold_adv.y = 0; > + gm.gmCellIncY = -((vec.y+fake_bold_adv.y+63) >> 6); > if (!avgAdvance || vec.y) > - gm.gmCellIncX = (vec.x+63) >> 6; > + gm.gmCellIncX = (vec.x+fake_bold_adv.x+63) >> 6; > else { > vec.x = incoming_font->ntmAvgWidth; > vec.y = 0; > pFT_Vector_Transform(&vec, &transMat); > - gm.gmCellIncX = pFT_MulFix(vec.x, em_scale) * 2; > + gm.gmCellIncX = pFT_MulFix(vec.x, em_scale) * 2 + (fake_bold_adv.x >> 6); > } > > if (vertical_metrics) > @@ -6971,13 +6992,15 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, > vec.x = metrics.horiAdvance; > vec.y = 0; > pFT_Vector_Transform(&vec, &transMatUnrotated); > + if (font->fake_bold) > + fake_bold_adv = normalize_vector(&vec); > if (!avgAdvance || vec.y) > - adv = (vec.x+63) >> 6; > + adv = (vec.x+fake_bold_adv.x+63) >> 6; > else { > vec.x = incoming_font->ntmAvgWidth; > vec.y = 0; > pFT_Vector_Transform(&vec, &transMatUnrotated); > - adv = pFT_MulFix(vec.x, em_scale) * 2; > + adv = pFT_MulFix(vec.x, em_scale) * 2 + (fake_bold_adv.x >> 6); > } > Is it possible to merge these two blocks of very similar code into a helper or something? I realise that you didn't start this duplication, but it's become increasingly more complicated. Huw.

1 0

Re: [PATCH] msxml3/tests: Fix BSTR leak warning (Valgrind)
by Marvin 04 Jan '16

04 Jan '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=19359 Your paranoid android. === w1064 (32 bit httpreq) === httpreq.c:1627: Test failed: got 0x80070057, expected 0x00000000

1 0

Re: [resend v2 4/4] ddraw: Do refcounting only through wined3d_texture_{inc, dec}ref().
by Henri Verbeet 03 Jan '16

03 Jan '16

On 22 December 2015 at 22:43, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > @@ -1227,6 +1221,7 @@ static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 > struct wined3d_texture *texture; > IDirectDrawSurface7 *current; > struct wined3d_surface *tmp; > + unsigned int tmp_idx; You shouldn't need that. Flippable surfaces aren't supposed to be textures, and only textures should have mip-levels. It should be enough to validate the sub-resource index is 0 and print an ERR if it somehow isn't. I don't think we enforce that DDSCAPS_MIPMAP needs DDSCAPS_TEXTURE. That would be a bug and needs tests. > @@ -6286,8 +6287,10 @@ void ddraw_surface_init(struct ddraw_surface *surface, struct ddraw *ddraw, stru > } > desc->lpSurface = NULL; > > - wined3d_surface_incref(wined3d_surface); > + wined3d_texture_incref(wined3d_texture); > surface->wined3d_surface = wined3d_surface; > + surface->wined3d_texture = wined3d_texture; The reference counting here is odd. You'd normally increment the reference count right before or after storing the pointer. You also store wined3d_surface without increasing the reference count, although that's probably ok because it's protected by the one from the texture. Still, it would probably be nicer to just get rid of the wined3d_surface field first.

3 5

Re: [PATCH 1/5] wined3d: Regenerate FFP replacement VS on changes to the normal attribute in the vertex declaration.
by Henri Verbeet 03 Jan '16

03 Jan '16

On 15 December 2015 at 11:58, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > I signed of on this (117257) a while ago, but notice it's still marked as "Assigned".

1 0

Re: [PATCH 3/6] d3d11/tests: Add test for SM4 sample_l instruction.
by Henri Verbeet 03 Jan '16

03 Jan '16

There seems to be a good amount of overlap between this test and test_texture(). Would it make sense to merge them? Also, I assume you'll add a d3d10core version of the test as well? On 1 January 2016 at 18:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + float miplevel[4] = {0}; A struct vec4 would perhaps be more appropriate. IIRC MSVC gets a bit unhappy about initializing floating-point variables with anything other than floating-point constants, so it would perhaps be better to use 0.0f here. However, ... > + buffer_desc.ByteWidth = sizeof(miplevel); > + buffer_desc.BindFlags = D3D11_BIND_CONSTANT_BUFFER; > + > + resource_data[0].pSysMem = &miplevel; > + > + hr = ID3D11Device_CreateBuffer(device, &buffer_desc, resource_data, &cb); > + ok(SUCCEEDED(hr), "Failed to create constant buffer, hr %#x.\n", hr); ... > + *miplevel = test->miplevel; > + ID3D11DeviceContext_UpdateSubresource(context, (ID3D11Resource *)cb, 0, NULL, miplevel, 0, 0); ... I don't think you should need to pass in initial data in the first place.

1 0

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it
by Nikolay Sivov 03 Jan '16

03 Jan '16

Hello again. > +typedef struct > +{ > + MOUSEHOOKSTRUCT MOUSEHOOKSTRUCT; > + DWORD mouseData; > +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; Apparently that's not how Windows SDK defines it. For some obscure reason they didn't define EX struct simply as non-EX + extra field, but used cpp style, kind of. Older versions don't even have field name for MOUSEHOOKSTRUCT portion, only type, but this won't work, not with gcc at least. SDK 10 uses DUMMYSTRUCTNAME as a field name, which resolves to 's', if NONAMELESSSTRUCT is defined. I guess we have to follow version 10 definition.

3 4

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes (v2)
by Marvin 03 Jan '16

03 Jan '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=19336 Your paranoid android. === w7u (32 bit msg) === msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

2 1

Fedora source packages
by Jeffrey Smith 02 Jan '16

02 Jan '16

For the builddep commands in http://wiki.winehq.org/Fedora to work as intended, there needs to be a repository containing the source rpms. The binary rpms do NOT provide the _build_ dependency information needed for the builddep commands to do their job. Otherwise, the instructions need to be redone, as the builddep commands are not really doing anything useful as things stand. Jeff

4 4

Shared WoW64 on Mac OS X via Homebrew
by kaazoo 02 Jan '16

02 Jan '16

Hello, I modified the existing Homebrew formular for Wine in order to make shared WoW64 (32bit and 64bit Wine together) possible: https://github.com/kaazoo/homebrew/commit/cd0f1db42e0a8228740fce347604d1cfe… The changes are not yet upstream, so you'll need to overwrite /usr/local/Library/Formula/wine.rb with my version. The upcoming LLVM 3.8 release is a dependency for the 64bit build: brew install llvm --with-clang --with-clang-extra-tools --with-compiler-rt --with-libcxx --with-lld --with-rtti --HEAD After that Wine 1.9.0 can be installed via: brew install wine --with-win64 --without-x11 --devel Regards, kaazoo

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 7).
by Stefan Dösinger 02 Jan '16

02 Jan '16

> Am 02.01.2016 um 07:24 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + size = w * h * (bpp / 8); > + /* Saving pixels by directly accessing bitmap buffer is faster than using SetPixel */ > + for (i = 0, j = 0; i < size;) > + { > + if (palettized) > + { > + buffer[i++] = j; > + buffer[i++] = j; > + buffer[i++] = j++; > + j %= 256; > + } > + else > + { > + buffer[i] = i % 256; > + i++; > + buffer[i] = j % 256; > + i++; > + j = (j % w) + 1; > + } > + } This is different from earlier patch versions afair. Whats the reason for the change? I guess this gets the job done, but it feels a bit odd to initialize 2/3rds of a rgb pixel or 3 palletized pixels per iteration. It can also cause trouble with writing past the end if size isn't a multiple of 2 or 3 respectively. (with 24 bit rgb even a multiple of 2 isn't guaranteed) Also I think you can get rid of the DIB section and just use a HeapAlloced blob.

2 1

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).
by Stefan Dösinger 02 Jan '16

02 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-01 um 18:15 schrieb Aaryaman Vasishta: > + expected = (info_header.biWidth + 3) & ~3; > + ok(expected == img->bytes_per_line, "Expected bytes per line == %d, got %d.\n", expected, img->bytes_per_line); > + if (depth == 8) > + { > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (img->bytes_per_line * (h - i - 1)) : (img->bytes_per_line * i); > + for (j = 0; j < img->bytes_per_line; j++) > + { > + if (buffer1[k++] != buffer2[offset++]) > + return FALSE; > + } You want j < img->width here, otherwise you compare the padded bytes against the next line of the input image. (You'll then also compare the follow-up lines incorrectly and read past the input buffer). It works here because you pass an image with a width that's a multiple of 4 when this codepath is used. So iterate over width pixels, but advance the read offset / pointer by bytes_per_line bytes after processing one line. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWhs9jAAoJEN0/YqbEcdMwx6kP/RXJJdivWRU1ouvEP32VWNRA O/tOZxGNJnXw0Rz40QQz1rtckN3GGAe54pwilQbaPAqrZeIDAEWfk4gWMKIvHvUw Vdg3w7dfQv6fpKK16EWWb83gdaQU9X3Nc7bFzHx4XwvkjHgV/ztsk/t6cqkAOv2Y cWul6MpQcWvehGyEv+vk1siMxO5zFjLvBpT7jgFh+7Ehzbk8ziZWdBYGjV18PnAQ 4eT5MrsNbaA99wKj7ibhz9I4GsKLf8oQQAFFqcVTutCOLeQh7zvHkQ4Z4glXSEYu VvNRmLdMYNSYho+Z9lZEABNvaw9lkxJ6/r1OYd3tP2A0TZzKur732iUYwTo1RnFB Hlv6K/PKzTTMN1m9GZ8UiltnjsEq5G+05nkaywsh7pkr9bGU2pfSEihZ8BSX1/4a zG+vLJipg/rdHalQKfCflxWpKcHiIFjm5E/+Bdtgzb3sSksPh2bfmdVDW/bl3lvD OMXD2FgHB4BE+lexisBV7+qlQhlv8vEPgWryoJ8xomfyAc0ZHioOgTrq0XSMrTdC 19oNGDWZd/8P1guTTC3eRlBFA3jYt/yvjzINRYG1h9L5DbYISuMbp0oUSFx3412o YB7HTHjbyxcWhZFEXc9oDHoMzfIEyJI1QOa8fCNkisucCc/idN7Zrqz+3wYJhHCu PjleVblBVMqsSN/Qw2OE =ftwX -----END PGP SIGNATURE-----

2 1

Mac OS X beta packages!
by Michael Müller 02 Jan '16

02 Jan '16

Hi, we are happy to announce an initial version of our Mac OS X >= 10.8 builds. So far the packages have not yet received that much testing, so please give them a try, and report any issues you encounter. The packages are available at: https://dl.winehq.org/wine-builds/macosx (Some mirrors don't show all files yet, just append random arguments to the url like ?whereismypackage to trick the cache) For unexperienced users, it is recommended to install Wine using the *.pkg files. Just double-click on the package, and the usual Mac OS X installer wizard should open. As pointed out by Austin, I am not a registered Apple Developer and therefore the packages aren't signed. This will result in an error if you configured gate keeper to block unsigned packages. The installation itself should be self-explaining, so I will not go into too much detail here. It is possible to install the package either for all users (needs administrator privileges), or just for your current user. If you haven't installed XQuartz >= 2.7.7 yet (our package supports the x11drv as well as the macdrv), the installer will complain. Just install the missing dependency, and restart the installation, if this is the case. After the installation is finished, you should find an entry "Wine Staging" or "Wine Devel" in your Launchpad. By clicking on it, a new Terminal window opens with a short introduction into some important wine commands. You can now directly start wine/winecfg/... from the Terminal, as the PATH variable is set correctly. For user convenience, the package also associates itself with all *.exe files, which means you can run windows executables just by double-clicking on them. This might not work for all executables though, since OS X doesn't seem to pass the current working directory to the "Open With" handler. Some experienced users on the other hand might prefer a raw wine version without those gimmicks, so we also provide tarball archives. They basically contain the same files (except packaging related stuff), and can be unpacked in any directory. There is no need to set DYLD_* environment variables, all paths are relative, so it should work as long as the directory structure is preserved (you can skip the /usr prefix though using --strip-components 1). Also make sure to install XQuartz >= 2.7.7 in this case. For those who are wondering, here a couple more technical aspects: -------- Dependencies -------- The following dependencies are shipped as precompiled *.dylib-libraries directly with Wine: * libjpeg-turbo * liblcms2 * liblzma * libopenal-soft * libtiff * libxml2 * libxslt * [libtxc-dxtn-s2tc] This is the patent free implementation of dxtn as used by many linux distros. Only included in Wine Staging. -------- Scripts -------- You can find all scripts and build files at https://github.com/wine-compholio/wine-packaging/tree/master/macosx Those files allow you to build the packages on Debian Jessie as host system, starting from a patched clang compiler (to support ms_hook_prologue), tools necessary to create OS X packages, cross compilation of the Wine build dependencies and finally cross compiles Wine itself. You only have to provide MacOSX10.8.sdk.tar.xz and xquartz-2.7.7.tar.xz, everything else is built from source. However, the generated scripts are meant to be run inside our build VMs, so realistically speaking it requires some effort to setup such a system and is not suitable for an average user. ------------------------ There are also some features I am planning to implement in the future (depending on how much time I have): -------- Auto updater -------- There is no common system to provide automatic updates for packages besides the Store, so I think it would be good to come up with some solution for this problem. Especially if the user installed the package into his home directory, he could easily update it without entering a password. I don't have much knowledge about objective-c or cocoa, so if someone else wants to implement this, I am more then glad to add it as an optional feature to the installer. -------- Desktop integration -------- So far Wine does not create desktop entries that are shown in Launchpad, but instead creates useless entries at ~/.local/share/applications/. I think it shouldn't be too hard to dynamically create a proper entry at ~/Applications/ using a wrapper like I did for the main wine executable. -------- Package signing? -------- This is basically something I could fix in 5 minutes, but I don't feel like paying 99$/year if I basically don't use Mac OS X myself. ------------------------ Happy new year and happy testing! :) Best regards, Michael

3 5

Re: [PATCH] shell32/tests: Explicitly compare to HRESULT values
by Marvin 02 Jan '16

02 Jan '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=19335 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1578: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

2 1

Re: [3/3] ntdll/tests: Add tests for setting debug registers with NtSetContextThread.
by Marvin 02 Jan '16

02 Jan '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=19333 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 002D0000/002D0001 exception: unhandled exception 80000004 at 002D0000 exception.c:485: Test failed: 42: Wrong exception address 77BAED97/002D0001 === w7u (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/003D0001 === w1064 (32 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === w1064 (64 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

2 1

Re: [PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter. (try 2)
by Sebastian Lackner 02 Jan '16

02 Jan '16

On 01.01.2016 23:50, Christopher Thielen wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=13683 > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. > > Tested on Windows XP and Fedora Workstation 22. > > Re-submitting to simplify based on wine-devel feedback. > Re-submitting after 1.8 release. > > Signed-off-by: Christopher Thielen <cthielen(a)gmail.com> > Where are the tests you initially had in your patch? I assume you accidentially resent an old version. The tests are still useful to make sure, that noone will break this fix again. Also, please review all the occurances of WM_CAPTURECHANGED, and fix them accordingly. If the code doesn't look like it can handle the double notification, then just ignore them based on the condition lParam == hWnd. This could also be done in separate patches before. Regards, Sebastian

1 0

Re: [PATCH 3/3] ddraw/tests: Use a slop for test_shademode.
by Marvin 01 Jan '16

01 Jan '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=19330 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2337: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2186: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw4) === ddraw4.c:2522: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 5).
by Stefan Dösinger 01 Jan '16

01 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-12-27 um 10:23 schrieb Aaryaman Vasishta: > + if (info_header.biWidth % 4 != 0) > + expected = (info_header.biWidth & ~0x03) + 4; > + else > + expected = info_header.biWidth; This is more complicated than it needs to be: expected = (info_header.biWidth + 3) & ~3 should work as well. > + k++; > + /* Take into account padded bytes after every row for odd widths */ > + if ((w % 2 == 1) && (j == w - 1)) > + k = (k & ~0x03) + 4; Wouldn't this also apply for e.g. a width of 10 that is a multiple of 2, but not a multiple of 4? The canonical way is to advance bytes_per_line bytes every line, e.g. buffer1[i * bytes_per_line + j] Or do k += bytes_per_line in the outer loop and then just do buffer1[k + j] to avoid re-doing the multiplication every time. I'd expect the compiler to optimize it anyway though. Other than that the patch looks good :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWhnqDAAoJEN0/YqbEcdMwiLYP/1eERxdjpnqfm2CX3dPF4wmx 3BQjdvH8LLxlS9HNG9PcGXs6gnyhPtsXL3DTSJtsl6UnHn7Ws9EWrjNFrnLEkoDB K7JwHNCPBvuOGb4YHDo4+9NeIXn3Kg6r3yorPGEu0NvWO98FcbhTJWbfhPq4y0uD WvQSCUcqufusFRUFUlOAks5zUXEmEVimxtMgaAYMqul3rsD22pT9CIOPd7Pxp+tc 6AzROoxTA0OoyMpH33APRKCLSwXET6KsMsrV7V83DblE5T9GrIz1ufRYQ155yUpe 3sBG9cGtPJ9KgjEdwp2Gy4hSFOSNVZJauNG3NhYf55cpngnYGU2W7Om9hkGQ6lOF IkjlBDWdKTX6WpC3Yiitw8DfNtRy7S1syEfhkqscYEiDRKYKILHB/njrbdj8q3so SRGAO/g8WSltCfUzlPHU3Jjmb/QjHl6JUV7JkqmJkrmqtd5mrOqPO+YFlDVCwtKl 79DWf5gbF7MbDBQQ82pBy30dy7+a4W9/cmls8x6EeZVr9zBvojfnxbR9xgy7tAVp EWaSUvUJWIoTTxMh4KEbVrH2LxJcEKGocHdXL22h5pMvpk02oCoj8nx1hUtHqMTW mvfYJDGV/DKiaYoSxUjuLqiB1wtNzg4BQcDNCzojRWQD4xS/yHC22rV9/4jG/+b4 F11LmyZfBxp83t+SpGjk =BnPO -----END PGP SIGNATURE-----

2 1

Re: [PATCH] ieframe: Don't write icon file path and index to storage if not specified in shortcut (Valgrind)
by Dmitry Timoshkov 01 Jan '16

01 Jan '16

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > - U(pv[1]).iVal = iconIndex; > + U(pv[1]).lVal = iconIndex; This change is wrong and doesn't match the code below it in the patch. -- Dmitry.

2 1

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes
by Marvin 01 Jan '16

01 Jan '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=19318 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10877: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:10889: Test failed: msg.message = 275 instead of WM_USER msg.c:10891: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:10900: Test failed: msg.message = 1024 instead of WM_TIMER msg.c:10902: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:13824: Test failed: 0: WaitForSingleObject failed === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

2 1

Re: [PATCH 3/3] msxml3/tests: Fix a stream leak (Valgrind)
by Marvin 31 Dec '15

31 Dec '15

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=19305 Your paranoid android. === w1064 (32 bit httpreq) === httpreq.c:1627: Test failed: got 0x80070057, expected 0x00000000

2 1

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes
by Marvin 31 Dec '15

31 Dec '15

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=19315 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0

Re: [4/6] gdi32: Fix the advance width in synthetic bold glyphs with scaling.
by Marvin 31 Dec '15

31 Dec '15

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=19284 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: [2/6] gdi32/tests: Add font advance tests for synthetic bold face with scaling.
by Marvin 31 Dec '15

31 Dec '15

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

1 0

Re: [1/6] gdi32/tests: Refactor test_fake_bold_font() to avoid code duplications.
by Marvin 31 Dec '15

31 Dec '15

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=19282 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: [PATCH 1/4] ntdll: Use correct parameter types instead of casting.
by Sebastian Lackner 31 Dec '15

31 Dec '15

On 30.12.2015 06:37, Alex Henrie wrote: > Casting has not been necessary here ever since this code was converted > to use wineserver requests circa Wine 1.0. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ntdll/file.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 1027b54..6524f32 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -411,10 +411,8 @@ static struct async_fileio *alloc_fileio( DWORD size, HANDLE handle, PIO_APC_ROU > } > > /* callback for irp async I/O completion */ > -static NTSTATUS irp_completion( void *user, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > +static NTSTATUS irp_completion( struct async_irp *async, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > { It would no longer match the prototype in dlls/ntdll/server.c then: NTSTATUS (*func)(void *, IO_STATUS_BLOCK *, NTSTATUS, void **, void **) = wine_server_get_ptr( call->async_io.func );

2 1

Re: [PATCH 2/2] odbccp32: Implement SQLRemoveDriver/SQLRemoveDriverW
by Marvin 31 Dec '15

31 Dec '15

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=19279 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH 1/2] odbccp32: Implement SQLInstallDriverEx correctly
by Marvin 31 Dec '15

31 Dec '15

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=19278 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH v2] ole32: Properly implement OleRegGetUserType()
by Marvin 30 Dec '15

30 Dec '15

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=19269 Your paranoid android. === wvistau64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7u (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w8 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === wvistau64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null)

2 1

Plug and Play and Wine
by Aric Stewart 30 Dec '15

30 Dec '15

Hello All, Yay 1.8! So in discussions with Alexandre, he expressed that he would really like there to be a Plug and Play system in wine to support the HID work I have been doing. Others at WineConf also expressed a desire for a plug and play system. So I have been doing research, reading and work to try to design out how this system will work. I promised him that while I would do research and testing I would wait until after the release before initiating this conversation. We also discussed at WineConf that design processes like this should happen more out in the open so here is my proposed design, with my thinking, so that people who have interest and maybe more knowledge about parts of this than I can help improve the design. I have done some basic proof of concept coding on most of this so that I know it can work, but have flexibility. Long discussion below. The main thing I have learned is that this side of Plug and Play (The system side) is very complicated and pretty much completely undocumented. So this beginning design is going to be greatly simplified but hopefully in enough of a good framework state that it can be expanded as needed. A few definitions, these are borrowed terms but may not be specifically defined exactly the same as on windows: Bus driver : this is whatever lump of code that it talking to the underlying devices, this should be talking to platform native devices. For the purposes of our PnP the bus driver will be only really responsible for enumerating devices, detecting addition and removal of devices and being able to generate device IDs for these devices. This will all be wine code as far as I can determine. Device Driver: This is the code that is actually trying to do something with the device enumerated but the bus driver. This too will likely be wine code. Think a hid minidriver or usb.sys. Generally any supported native drivers will have to sit above this particular device driver level. But that could maybe change, we will see Plug and Play manager: This is the chunk of code that manages all the driver, devices and does the plug and play work. I have chosen to make the existing Programs/plugplay.exe be the plug and play manager. No INF processing or install: The most important part of this that is missing and that I am not addressing is anything about driver installation or inf files. Right now everything in this process is wine builtin code, so there is no need to have inf processing, and that is a seriously complicated part of this process. I have not fully figured out how we should manage the driver store and do the full driver on demand installation and such. But a basic framework can be put together without it. The Plug and Play process, (As I see it for wine) Ok, here is the meat of what is interesting. Starting at the bottom. Plug and Play bus drivers will be written for OS/X HID devices as well as udev hidraw devices. When I discussed this with Alexandre he did not feel like these need to be individual dlls, so they will be included in the plugplay.exe manager. However they will be designed in such a way that if a compelling reason why we need to pull them out becomes apparent it will not be difficult. These bus drivers will not be full device driver really, they just handle the Plug and play aspects of the bus, the device->DeviceExtension will be simply be a handle to the native device in question. The driver will only handle IRP_MJ_PNP ioctls. Having these be loaded into the plugplay.exe manager process space makes many things much easier. When the bus driver detects a new device it will call PNP_IoInvalidateDeviceRelations, and internal function inside of plugplay.exe that mirrors IoInvalidateDeviceRelations. Because the bus drivers are living inside of the plugplay manager there is no need to implement and deal with the ntoskrnl.exe version of IoInvalidateDeviceRelations. Again this will be coded to be able to be pulled out if needed. If we decide to handle any bus drivers that live outside of the plugplay.exe process space then we will need to have this functionality, probably via RPC like the service manager. Here is where the fun comes. Because we are not handling installing drivers (yet) we can just make use of the critical device store. These are drivers that, on windows, are automatically loaded on boot every time. This database is maintained in [CurrentControlSet/Control/CriticalDeviceDatabase] The keys in this registry key represent a HardwareID that will match a device. We query the IDs from the bus device’s BusQueryHardwareIDs and if we find a match (from most specific to most general) we look at that registry key. The CriticalDeviceDatabase entry will specify a [Service] value. All the first round builtin drivers will specify the [Service]. Further implementations when we start supporting inf files will also look at supporting the [ClassGUID] value where a driver inf can be specified. That Service will specify a key in [CurrentControlSet\Services]. These services will need to be [type] of 0x1 (device driver) and [start] of 0x3 (on demand), finally they will have an [ImagePath] that points to the .sys file for this driver. The plug and play manager will determine if it has loaded that driver or not, and if not then it will load the driver into its process space and call the drivers DriverEntry. Part of this will be done via the advapi service APIs to query the service and then I was planing to reuse code from winedevice.exe for the actual loading of the driver.sys into the plugplay.exe process space. With the loaded driver we then call the driver’s extension.AddDevice entry point with the new bus device. The drivers AddDevice function will be well behaved and call IoAttachDeviceToDeviceStack. The Plug and Play manager will look at the bus device after AddDevice and if there is an AttachedDevice then will proceed to call IRP_MN_START_DEVICE on the attached device. Then a IRP_MJ_POWER/IRP_MN_SET_POWER to PowerDeviceD0. It is an important point that having the bus drivers and function drivers all loaded into the same process space means that they have a common process stack for sharing memory and handles and such. Driver will expect this so if we end up having to change this we will have to deal with the complexities of the memory management. Device removal will be more simplistic. When the bus driver detects that a device has been removed then we again make a PNP_IoInvalidateDeviceRelations. Then the plug and play manager will send a IRP_MN_SURPRISE_REMOVAL followed by a IRP_MN_REMOVE_DEVICE ioctl to the AttachedDevice. That will represent the entirety of the process, as I see it on the first pass, for plug and play. Some of the many things this does not do, it does not make use of or maintain a driver store (I think maintained as keys under the [CurrentControlSet/Control/Class/<GUID>] keys). It does not do any of the complicated driver INF, install on demand work and it does not allow for new drivers to be installed via any of the installation processes. But it does not prevent this from being expanded on for next passes. Another big unanswered part of this is the integration with the Plug and Play configuration manager (cfgmgr32.dll) and all the CM_XXX functions. I am only working on the HID bus and drivers, however I feel like we could expand this pretty easily into USB or even mountmgr bus and driver architectures as we move forward. Comments? Thoughts? Anyone actually get to the end here? -aric

2 2

Re: configure: Detect MinGW-w64 Clang cross toolchain
by Alexandre Julliard 30 Dec '15

30 Dec '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -171,17 +171,19 @@ LIBS="$ac_wine_check_funcs_save_LIBS"]) > > dnl **** Check for a mingw program, trying the various mingw prefixes **** > dnl > -dnl Usage: WINE_CHECK_MINGW_PROG(variable,prog,[value-if-not-found],[path]) > +dnl Usage: WINE_CHECK_MINGW_PROG(variable,progs,[value-if-not-found],[path]) > dnl > AC_DEFUN([WINE_CHECK_MINGW_PROG], > [case "$host_cpu" in > i[[3456789]]86*) > ac_prefix_list="m4_foreach([ac_wine_prefix],[w64-mingw32, pc-mingw32, mingw32msvc, mingw32], > - m4_foreach([ac_wine_cpu],[i686,i586,i486,i386],[ac_wine_cpu-ac_wine_prefix-$2 ])) > + m4_foreach([ac_wine_cpu],[i686,i586,i486,i386], > + m4_foreach([ac_wine_prog],[$2],[ac_wine_cpu-ac_wine_prefix-ac_wine_prog ]))) > mingw32-$2" ;; Do we need to duplicate all the names? Or would it be sufficient to check only the w64-mingw one? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] kernel32: add tests for GetSystemPreferredUILanguages
by Marvin 30 Dec '15

30 Dec '15

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=19262 Your paranoid android. === w1064 (32 bit locale) === locale.c:2339: Test failed: LCMapStringEx should fail with bad locale name locale.c:2340: Test failed: unexpected error code -559038737 locale.c:2431: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4154: Test failed: IsValidLocaleName should have failed locale.c:4156: Test failed: IsValidLocaleName should have failed locale.c:4521: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4523: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message(). (resend)
by Marvin 30 Dec '15

30 Dec '15

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=19261 Your paranoid android. === w1064 (32 bit msg) === msg.c:6138: Test failed: Update region shouldn't be empty msg.c:6372: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6374: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message().
by Marvin 30 Dec '15

30 Dec '15

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=19260 Your paranoid android. === w1064 (32 bit msg) === msg.c:6138: Test failed: Update region shouldn't be empty msg.c:6372: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6374: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different

1 0

Re: [PATCH] ole32: Properly implement OleRegGetUserType()
by Dmitry Timoshkov 30 Dec '15

30 Dec '15

> dlls/ole32/ole2.c | 85 +++++++++++++++++++++++++++++-------------------------- > 1 file changed, 45 insertions(+), 40 deletions(-) It would be helpful to know why this implementaion is considered more "proper" than an existing one, especially taking into account lack of any tests or reference to a bug report. -- Dmitry.

2 2

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Jactry Zeng 30 Dec '15

30 Dec '15

Hi Changhui, I like this patch, too. '&Debug' and 'Show &Details' use a same shortcut key here. @@ -58,6 +50,7 @@ BEGIN IDC_STATIC_TXT2,"SysLink",0,27,60,224,100 DEFPUSHBUTTON "Close", IDOK, 205, 151, 60, 16, WS_TABSTOP PUSHBUTTON "Show &Details", ID_DETAILS, 140, 151, 60, 16, WS_TABSTOP + PUSHBUTTON "&Debug", ID_DEBUG, 75, 151, 60, 16, WS_TABSTOP END I think push this debug button in the left corner seems better? Maybe we also need some text in IDC_STATIC_TXT2 to let users know what it means. Thanks. 2015-12-28 17:21 GMT+08:00 Changhui LIU <liuchanghui(a)linuxdeepin.com>: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > > -- Regards, Jactry Zeng

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Alex Henrie 30 Dec '15

30 Dec '15

I'm pretty sure that the Debug button on the crash dialog is hidden so that people who don't know what they're doing don't try to use it. -Alex

2 1

Re: [PATCH 1/1] msvcr120: Enable MSVCRT__nextafterf when _MSVCR_VER>=120.
by Piotr Caban 29 Dec '15

29 Dec '15

Hi, On 12/28/15 08:19, YongHao Hu wrote: > dlls/msvcr120/msvcr120.spec | 6 +++--- > dlls/msvcr120_app/msvcr120_app.spec | 6 +++--- > dlls/msvcrt/math.c | 18 +++++++++--------- > 3 files changed, 15 insertions(+), 15 deletions(-) Please also update: ucrtbase/ucrtbase.spec api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec files. Thanks, Piotr

2 2

Re: [PATCH] ole32: Zero out pointer in CreateFileMoniker() on error
by Marvin 29 Dec '15

29 Dec '15

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=19236 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w1064 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w1064 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Francois Gouget 29 Dec '15

29 Dec '15

On Tue, 29 Dec 2015, Francois Gouget wrote: [...] > + > + if ((sei_tmp.lpVerb && *sei_tmp.lpVerb) || PathIsExeW(wszApplicationName)) Please don't apply. I think this test is wrong. It should probably be checking that no was specified, or maybe that no class was specified. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Bugzilla changes
by Austin English 29 Dec '15

29 Dec '15

Howdy all, As Alexandre mentioned [1], at WineConf we made several decisions to modify bugzilla in a few ways. I've now implemented those changes, which are outlined below: * New wine-staging product: This should be used for bugs caused by patches that are in wine-staging, but that do not occur in wine-development (i.e., wine-staging patch regressions) * New STAGED resolution: This is to differentiate bugs that are FIXED (in wine-development) from bugs that are not present in wine-staging because of one or more patches. The anticipated workflow is: UNCONFIRMED > bug confirmed, NEW > patch written and sent to wine-patches, if it's accepted, FIXED. If not, and the patch is integrated into wine-staging, then the bug is STAGED. When the patch is revised and eventually integrated into wine-development, the bug should move to FIXED. * New NEEDINFO resolution: There's a lot of confusion and different handling by triagers for what to do with bug reports that are incomplete (i.e., leaving it open versus closing invalid). To mitigate this, I've added a NEEDINFO resolution. If a bug report lacks needed information, set it to this status. Bug that have been open NEEDINFO for more than 1 year can be closed. * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other projects do, and eliminates confusion about the upstream/downstream distinction. Please let me know if there are any questions or ideas for further enhancements. [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html -- -Austin

6 11

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled.
by Aric Stewart 29 Dec '15

29 Dec '15

Sorry for the delayed review, I have been traveling. I understand the issue your trying to fix, but I worry that you could get yourself into a bad state where if a driver is misbehaving and is blocked or crashes while processing an IRP then the halt event will never get processed as we will be waiting INFINITE on an event that may never come. I dont know which is the more likely or problematic case. What I may suggest is keep the WaitForMultipleObjects(2, events, FALSE, INFINITE) and instead of relying on the return code you could do an additional WaitForSingleObject(ext->halt_event, 0) to determine if exit_now should be set. -aric

2 1

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message. (try 3)
by Marvin 29 Dec '15

29 Dec '15

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=19233 Your paranoid android. === w1064 (32 bit msg) === msg.c:6140: Test failed: Update region shouldn't be empty msg.c:6374: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6376: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6146: Test failed: Regions are different msg.c:6146: Test failed: Regions are different msg.c:6146: Test failed: Regions are different

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Marvin 29 Dec '15

29 Dec '15

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=19232 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:142: Test failed: ShellExecute(verb="QuotedUpperL", file="C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec") WaitForSingleObject returned 258 shlexec.c:1566: Test failed: argvA3 expected 'QuotedUpperL', but key not found or empty shlexec.c:1574: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec', but key not found or empty === w1064 (32 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2667: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2668: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', but key not found or empty shlexec.c:556: childTimeout called shlexec.c:2679: Test failed: argcA expected 4, but got 3 shlexec.c:2680: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2681: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', got 'C:\Users\winetest\Documents\shell32_test64.exe'

1 0

Re: [1/2] shell32/tests: Make sure the test executable has an executable name.
by Marvin 28 Dec '15

28 Dec '15

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

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Qian Hong 28 Dec '15

28 Dec '15

I like this change, thank you for the patch. On Mon, Dec 28, 2015 at 5:21 PM, Changhui LIU <liuchanghui(a)linuxdeepin.com> wrote: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > -- Regards, Qian Hong - http://www.winehq.org

1 0

Out-of-date gcc and ld on the testbot build VM
by Hugh McMaster 28 Dec '15

28 Dec '15

The testbot seems to have an out-of-date version of mingw32, or at least, its linker, ld.exe. I'm trying to run tests for GetConsoleScreenBufferInfoEx, a function available on Vista and higher. But the build VM's linker is failing with an undefined reference: reg.o: In function `test_GetConsoleScreenBufferInfoEx': /home/winetest/tools/testbot/var/build-mingw32/programs/reg/tests/../../../../wine/programs/reg/tests/reg.c:489: undefined reference to `__imp__GetConsoleScreenBufferInfoEx@8' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed My machine is able to compile the tests. It also has no trouble building a separate .exe using i686-w64-mingw32-gcc. My machine has: - mingw32 gcc version 4.8.2 (GCC) - mingw32 ld version: GNU ld (GNU Binutils) 2.23.52.20130620 -- Hugh McMaster

3 5

Re: shell32: add SHCreateSessionKey stub (try 2)
by Nikolay Sivov 28 Dec '15

28 Dec '15

> +/************************************************************************* > + * SHCreateSessionKey [SHELL32.723] NT 4.0 > + * > + */ > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %u %p\n", access, hkey); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} 'access' is a 32bit bit mask, return value is HRESULT.

1 0

Re: shell32: add SHCreateSessionKey stub
by Nikolay Sivov 28 Dec '15

28 Dec '15

On 28.12.2015 8:15, Austin English wrote: > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %d %p\n", access, hkey); > + return ERROR_SUCCESS; > +} This is wrong regarding tracing format, return value and formatting. I'll try to find time this week to send an actual implementation. It's fine to have fixed stub in before that of course.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 4).
by Stefan Dösinger 27 Dec '15

27 Dec '15

> Am 23.12.2015 um 16:46 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + file = create_bitmap("palette.bmp", 3, 39, TRUE); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRM2 interface (hr = %x)\n", hr); > + > + file = create_bitmap("8bpp.bmp", 100, 100, FALSE); The first line here seems to be a leftover from the last patch version. The same applies to the V3 function

2 4

Re: ntdll: add RtlCreateUserProcess stub
by Dmitry Timoshkov 27 Dec '15

27 Dec '15

Austin English <austinenglish(a)gmail.com> wrote: > +NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *path, ULONG attributes, RTL_USER_PROCESS_PARAMETERS *parameters, > + PSECURITY_DESCRIPTOR *process_descriptor, PSECURITY_DESCRIPTOR *thread_descriptor, > + HANDLE parent, BOOLEAN inherit, HANDLE debug, HANDLE exception, > + PRTL_USER_PROCESS_INFORMATION info) Some of the parameters use wrong pointer information. Probably it would be better to completely avoid Pxxx prefixes and use normal pointers for all parameters? -- Dmitry.

2 1

Re: pdh: Fix prototype of PdhGetLogFileType[A/W].
by Austin English 27 Dec '15

27 Dec '15

Thanks for fixing it so quickly Sebastian. I came back from holiday and it was already done :). On Thu, Dec 24, 2015 at 4:08 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > As pointed out on the mailing list yesterday, the first parameter can't be a handle. > Output after this patch: > > fixme:pdh:PdhGetLogFileTypeW L"dummy.log", 0x33fd9c: stub > > dlls/pdh/pdh.spec | 4 ++-- > dlls/pdh/pdh_main.c | 8 ++++---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/pdh/pdh.spec b/dlls/pdh/pdh.spec > index 529b92d..41900c8 100644 > --- a/dlls/pdh/pdh.spec > +++ b/dlls/pdh/pdh.spec > @@ -62,8 +62,8 @@ > @ stub PdhGetFormattedCounterArrayW > @ stdcall PdhGetFormattedCounterValue(ptr long ptr ptr) > @ stub PdhGetLogFileSize > -@ stdcall PdhGetLogFileTypeA(ptr ptr) > -@ stdcall PdhGetLogFileTypeW(ptr ptr) > +@ stdcall PdhGetLogFileTypeA(str ptr) > +@ stdcall PdhGetLogFileTypeW(wstr ptr) > @ stub PdhGetLogSetGUID > @ stub PdhGetRawCounterArrayA > @ stub PdhGetRawCounterArrayW > diff --git a/dlls/pdh/pdh_main.c b/dlls/pdh/pdh_main.c > index 036d28b..8854fd7 100644 > --- a/dlls/pdh/pdh_main.c > +++ b/dlls/pdh/pdh_main.c > @@ -1273,17 +1273,17 @@ PDH_STATUS WINAPI PdhSetDefaultRealTimeDataSource( DWORD source ) > /*********************************************************************** > * PdhGetLogFileTypeA (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeA(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeA(const char *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_a(log), type); > return PDH_NOT_IMPLEMENTED; > } > > /*********************************************************************** > * PdhGetLogFileTypeW (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeW(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeW(const WCHAR *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_w(log), type); > return PDH_NOT_IMPLEMENTED; > } > -- > 2.6.4 > > -- -Austin

1 0

Re: [PATCH 7/7] dwrite: Fix identical ranges merging
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 6/7] dwrite: Locale layout ranged attribute is case-insensitive
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 5/7] dwrite: Store optical alignment property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 4/7] dwrite: Store last line wrapping property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 2/7] dwrite: Store per-range typography property
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: [PATCH 1/7] dwrite/tests: One more test for duplicates in IDWriteTypography
by Marvin 26 Dec '15

26 Dec '15

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

1 0

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (resend)
by Nikolay Sivov 26 Dec '15

26 Dec '15

On 25.12.2015 10:30, Zhenbo Li wrote: > +static void test_illegal_xml(IXMLDOMDocument *xmldom) > +{ > + IXMLDOMNode *first, *last; > + VARIANT variant; > + HRESULT hres; > + BSTR bstr; > + > + hres = IXMLDOMDocument_get_baseName(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_baseName(xmldom, &bstr); > + ok(hres == S_FALSE, "get_baseName failed: %08x\n", hres); > + ok(bstr == NULL, "bstr(%p): %s\n", bstr, wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_dataType(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_dataType(xmldom, &variant); > + ok(hres == S_FALSE, "get_dataType failed: %08x\n", hres); > + ok(V_VT(&variant) == VT_NULL, "got %s\n", debugstr_variant(&variant)); > + VariantClear(&variant); > + > + hres = IXMLDOMDocument_get_text(xmldom, &bstr); > + ok(!strcmp_wa(bstr, ""), "text = %s\n", wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_firstChild(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + > + first = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_firstChild(xmldom, &first); > + ok(hres == S_FALSE, "get_firstChild failed: %08x\n", hres); > + ok(first == NULL, "first != NULL\n"); > + > + last = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_lastChild(xmldom, &last); > + ok(hres == S_FALSE, "get_lastChild failed: %08x\n", hres); > + ok(last == NULL, "last != NULL\n"); > +} It makes no sense to test every method on empty tree, test for text string. > + hres = IXMLDOMDocument_QueryInterface(xmldoc, &IID_IObjectSafety, (void**)&safety); > + assert(SUCCEEDED(hres)); > + hres = IObjectSafety_SetInterfaceSafetyOptions(safety, NULL, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER); > + assert(SUCCEEDED(hres)); > + IObjectSafety_Release(safety); This looks weird to me, why the asserts? Did Jacek suggest that?

2 2

Re: [2/2] oleaut32: Align terminating null character in SysAllocStringByteLen.
by Nikolay Sivov 25 Dec '15

25 Dec '15

On 25.12.2015 8:38, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > If SysAllocStringByteLen() is used with an odd length, the two terminating > null bytes are not aligned properly, which means that strlenW() would not > find them. Tests show that Windows appends three terminating null bytes in > this case. > > There is no need to change the memory allocation part because we already > round up to the next bucket size. > > dlls/oleaut32/oleaut.c | 14 ++++++-------- > dlls/oleaut32/tests/vartype.c | 29 +++++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 8 deletions(-) > > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index 75f9cb4..78cb083 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -149,12 +149,9 @@ static bstr_t *alloc_bstr(size_t size) > > if(cache_entry) { > if(WARN_ON(heap)) { > - size_t tail; > - > - memset(ret, ARENA_INUSE_FILLER, FIELD_OFFSET(bstr_t, u.ptr[size+sizeof(WCHAR)])); > - tail = bstr_alloc_size(size) - FIELD_OFFSET(bstr_t, u.ptr[size+sizeof(WCHAR)]); > - if(tail) > - memset(ret->u.ptr+size+sizeof(WCHAR), ARENA_TAIL_FILLER, tail); > + size_t fill_size = (FIELD_OFFSET(bstr_t, u.ptr[size])+2*sizeof(WCHAR)-1) & ~(sizeof(WCHAR)-1); > + memset(ret, ARENA_INUSE_FILLER, fill_size); > + memset((char *)ret+fill_size, ARENA_TAIL_FILLER, bstr_alloc_size(size)-fill_size); > } > ret->size = size; > return ret; > @@ -418,10 +415,11 @@ BSTR WINAPI SysAllocStringByteLen(LPCSTR str, UINT len) > > if(str) { > memcpy(bstr->u.ptr, str, len); > - bstr->u.ptr[len] = bstr->u.ptr[len+1] = 0; > + bstr->u.ptr[len] = 0; > }else { > - memset(bstr->u.ptr, 0, len+sizeof(WCHAR)); > + memset(bstr->u.ptr, 0, len+1); > } > + bstr->u.str[(len+sizeof(WCHAR)-1)/sizeof(WCHAR)] = 0; > > return bstr->u.str; > } > diff --git a/dlls/oleaut32/tests/vartype.c b/dlls/oleaut32/tests/vartype.c > index 7cbb059..d905d37 100644 > --- a/dlls/oleaut32/tests/vartype.c > +++ b/dlls/oleaut32/tests/vartype.c > @@ -5444,7 +5444,9 @@ static void test_SysAllocStringByteLen(void) > { > const OLECHAR szTest[10] = { 'T','e','s','t','\0' }; > const CHAR szTestA[6] = { 'T','e','s','t','\0','?' }; > + char *buf; > BSTR str; > + int i; > > if (sizeof(void *) == 4) /* not limited to 0x80000000 on Win64 */ > { > @@ -5487,6 +5489,7 @@ static void test_SysAllocStringByteLen(void) > > ok (bstr->dwLen == 3, "Expected 3, got %d\n", bstr->dwLen); > ok (!lstrcmpA((LPCSTR)bstr->szString, szTestTruncA), "String different\n"); > + ok (!bstr->szString[2], "String not terminated\n"); > SysFreeString(str); > } > > @@ -5500,6 +5503,32 @@ static void test_SysAllocStringByteLen(void) > ok (!lstrcmpW(bstr->szString, szTest), "String different\n"); > SysFreeString(str); > } > + > + /* Make sure terminating null is aligned properly */ > + buf = HeapAlloc(GetProcessHeap(), 0, 1025); > + ok (buf != NULL, "Expected non-NULL\n"); > + for (i = 0; i < 1024; i++) > + { > + LPINTERNAL_BSTR bstr; > + > + str = SysAllocStringByteLen(NULL, i); > + ok (str != NULL, "Expected non-NULL\n"); > + bstr = Get(str); > + ok (bstr->dwLen == i, "Expected %d, got %d\n", i, bstr->dwLen); > + ok (!bstr->szString[(i+sizeof(WCHAR)-1)/sizeof(WCHAR)], "String not terminated\n"); > + SysFreeString(str); > + > + memset(buf, 0xaa, 1025); > + str = SysAllocStringByteLen(buf, i); > + ok (str != NULL, "Expected non-NULL\n"); > + bstr = Get(str); > + ok (bstr->dwLen == i, "Expected %d, got %d\n", i, bstr->dwLen); > + buf[i] = 0; > + ok (!lstrcmpA((LPCSTR)bstr->szString, buf), "String different\n"); > + ok (!bstr->szString[(i+sizeof(WCHAR)-1)/sizeof(WCHAR)], "String not terminated\n"); > + SysFreeString(str); > + } > + HeapFree(GetProcessHeap(), 0, buf); > } Does this work with disabled cache? > > static void test_SysReAllocString(void) >

4 4

Re: winedump: Add initial version of old (SLTG) typelib dumper.
by Alexandre Julliard 25 Dec '15

25 Dec '15

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +static int _isprint(unsigned char c) > { > - int i; > + return c >= 32 ? 1 : 0; Please don't do that. > + > + assert(print_hex("magic") == 0x47544c53); Please don't do that. > + while (offset < name_table_start + name_table_size) > + { > +/*printf("current offset: %08x (relative to name table start: %08x (%u))\n", > + offset, offset - name_table_start, offset - name_table_start);*/ > + dump_binary(8); > + print_string0(); > + printf("\n"); > +/*printf("current offset: %08x (relative to name table start: %08x (%u))\n", > + offset, offset - name_table_start, offset - name_table_start);*/ Please clean these up. > +#if 0 > + print_short_hex("unknown"); > + print_short_hex("byte order mark"); > + i = tlb_read_short(); > + printf("version = %u.%u\n", i & 0xff, i >> 8); > + print_short_hex("system identifier"); > + print_hex("unknown"); > + printf("\n"); > +#else > + printf("skipping 12 bytes\n"); > + dump_binary(12); > + printf("\n"); > +#endif Same here. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Alexandre Julliard 24 Dec '15

24 Dec '15

Anton Baskanov <baskanov(a)gmail.com> writes: > @@ -2977,7 +2977,8 @@ enum coords_relative > int x; /* caret x position */ > int y; /* caret y position */ > int hide; /* increment for hide count (can be negative to show it) */ > - int state; /* caret state (1=on, 0=off, -1=toggle current state) */ > + int state; /* caret state (1=on, 0=off, -1=toggle current state, > + * -2=on if the position differs, unchanged otherwise) */ Please define constants instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Implement wineserver call for SystemHandleInformation. (v2)
by Marvin 24 Dec '15

24 Dec '15

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

2 1

Re: [2/2] server: Implement wineserver call for SystemHandleInformation.
by Alexandre Julliard 24 Dec '15

24 Dec '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -3265,6 +3265,22 @@ enum coords_relative > VARARG(sd,security_descriptor); /* retrieved security descriptor */ > @END > > + > +struct handle_info > +{ > + process_id_t owner; > + obj_handle_t handle; > + unsigned int access; > +}; > + > +/* Return a list of all opened handles */ > +@REQ(get_system_handles) > +@REPLY > + unsigned int count; /* number of handles */ > + VARARG(data,bytes); /* array of handle_infos */ This is not a bytes array, please write a proper dumping function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] ole32/tests: Some tests for OleRegGetUserType()
by Marvin 24 Dec '15

24 Dec '15

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=19139 Your paranoid android. === wxppro (32 bit compobj) === compobj.c:2250: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 4, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 4, got L"CLSID_StdFont" === w2003std (32 bit compobj) === compobj.c:2250: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2250: Test failed: form 4, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 0, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 1, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 2, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 3, got L"CLSID_StdFont" compobj.c:2266: Test failed: form 4, got L"CLSID_StdFont"

1 0

Re: [PATCH] kernel32: Set error if dstlen < 0 in codepage conversion functions.
by Marvin 24 Dec '15

24 Dec '15

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=19138 Your paranoid android. === build (build) === Could not copy the patch to the VM: the "nc -q0 '10.42.42.130' '4242'" command returned 1

1 0

Re: README: add a note about 64-bit Wine and 32-bit apps (try 2)
by Alexandre Julliard 24 Dec '15

24 Dec '15

Austin English <austinenglish(a)gmail.com> writes: > @@ -80,7 +80,9 @@ Optional support libraries: > to make sure to install the 32-bit versions of these libraries; see > http://wiki.winehq.org/WineOn64bit for details. If you want a true > 64-bit Wine (or a mixed 32-bit and 64-bit Wine setup), see > - http://wiki.winehq.org/Wine64 for details. > + http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine > + build will not run 32-bit applications (which many 64-bit applications > + include and rely upon) without also building 32-bit Wine. I think this should go on the mentioned wiki page instead, preferably with a big warning sign. -- Alexandre Julliard julliard(a)winehq.org

3 9

Re: pdh: add PdhGetLogFileTypeA/W stubs
by Sebastian Lackner 23 Dec '15

23 Dec '15

On 23.12.2015 07:36, Austin English wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=23298 > > The function is undocumented, but from reading the documented > functions, especially PdhGetLogFileSize > (https://msdn.microsoft.com/en-us/library/windows/desktop/aa372639%28v=vs.85…), > I made an educated guess. > When there are two functions with A and W suffix, this strongly suggests that there must be a filename parameter somewhere. This means the current interpretation is definitely not correct. Did you verify if it prints useful values?

1 0

Re: [PATCH] oleaut32: Don't store non-heap-allocated strings in the BSTR cache
by Marvin 23 Dec '15

23 Dec '15

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=19120 Your paranoid android. === wxppro (32 bit vartype) === vartype: unhandled exception c0000005 at 7C929F07 === w2003std (32 bit vartype) === vartype: unhandled exception c0000005 at 7C80ED80 === wvistau64 (32 bit vartype) === vartype: unhandled exception c0000005 at 77BC1C9B vartype: unhandled exception c0000005 at 77BC25BD === w2008s64 (32 bit vartype) === vartype: unhandled exception c0000005 at 771E1C9B vartype: unhandled exception c0000005 at 771E25BD === w7u (32 bit vartype) === vartype: unhandled exception c0000005 at 77D161F6 vartype: unhandled exception c0000005 at 77D4A3CE === w7pro64 (32 bit vartype) === vartype: unhandled exception c0000005 at 770F3526 vartype: unhandled exception c0000005 at 7714AED1 === w8 (32 bit vartype) === vartype: unhandled exception c0000005 at 7712C2A7 vartype: unhandled exception c0000005 at 7719661E === w864 (32 bit vartype) === vartype: unhandled exception c0000005 at 77C00044 vartype: unhandled exception c0000005 at 77C58780 === w1064 (32 bit vartype) === vartype: unhandled exception c0000005 at 7728CCC4 vartype: unhandled exception c0000005 at 772DB260 === wvistau64 (64 bit vartype) === No test summary line found === w2008s64 (64 bit vartype) === No test summary line found === w7pro64 (64 bit vartype) === No test summary line found === w864 (64 bit vartype) === No test summary line found === w1064 (64 bit vartype) === No test summary line found

1 0

Re: [PATCH 1/2] dsound: Simplify error handling when creating a sound buffer.
by Sebastian Lackner 23 Dec '15

23 Dec '15

On 22.12.2015 10:49, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > I run into this and wasted time while fixing the bug during the freeze. > So I am submitting the dsound cleanups I have laying around. > > > dlls/dsound/buffer.c | 46 ++++++++++++++++------------------------------ > 1 file changed, 16 insertions(+), 30 deletions(-) > Are you sure this will work as expected? The destructor makes assumptions about specific variables to be initialized. If I don't miss anything, DirectSoundDevice_RemoveBuffer could trigger an assertion / corrupt nrofbuffers now. This->buffer->ref will also not be initialized. Could you please double check that?

2 1

Re: ole32: Print error message when IPersistStorage_Load fails (Coverity)
by Huw Davies 23 Dec '15

23 Dec '15

On Tue, Dec 22, 2015 at 07:35:08PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > CID 1336207 > > dlls/ole32/compobj.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index 2f55076..b146376 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -3443,7 +3443,9 @@ HRESULT WINAPI CoGetInstanceFromIStorage( > > if (ps) > { > - IPersistStorage_Load(ps, storage); > + hr = IPersistStorage_Load(ps, storage); > + if (FAILED(hr)) > + ERR("failed to load storage\n"); > IPersistStorage_Release(ps); > } I suspect Coverity is expecting us to do something more useful with the return value ;-) How about returning the failure in this case (obviously having released ps first)? Also, just above this hunk, we should probably just return if QI fails. While you're at it, there are other CoCreateInstanceFrom* functions that could do with similar love. Huw.

2 1

Re: winspool: Remove dead code (Clang)
by Alexandre Julliard 23 Dec '15

23 Dec '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -4092,8 +4092,6 @@ static BOOL WINSPOOL_GetPrinter_1(HKEY hkeyPrinter, PRINTER_INFO_1W *pi1, > if(WINSPOOL_GetStringFromReg(hkeyPrinter, DescriptionW, ptr, left, &size)) { > if(space && size <= left) { > pi1->pComment = (LPWSTR)ptr; > - ptr += size; > - left -= size; > } else > space = FALSE; > *pcbNeeded += size; There's a clear pattern to the code here, you don't want to break it. I'd suggest redesigning the helper functions to avoid all this duplication. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] shlwapi: implement URL_ESCAPE_AS_UTF8
by Alexandre Julliard 23 Dec '15

23 Dec '15

Daniel Lehman <dlehman(a)esri.com> writes: > @@ -925,6 +955,20 @@ static void test_UrlEscapeW(void) > FreeWideString(urlW); > FreeWideString(expected_urlW); > } > + > + for(i=0; i<sizeof(TEST_ESCAPEW)/sizeof(TEST_ESCAPEW[0]); i++) { > + WCHAR ret_url[INTERNET_MAX_URL_LENGTH]; > + > + size = INTERNET_MAX_URL_LENGTH; > + ret = pUrlEscapeW(TEST_ESCAPEW[i].url, ret_url, &size, TEST_ESCAPEW[i].flags); > + if(ret == E_POINTER || TEST_ESCAPEW[i].broken) /* <= Win7/Win2k8 */ > + continue; That's not going to test anything for the broken cases. > @@ -1188,10 +1194,29 @@ HRESULT WINAPI UrlEscapeW( > if(cur == '\\' && (int_flags & WINE_URL_BASH_AS_SLASH) && !stop_escaping) cur = '/'; > > if(URL_NeedEscapeW(cur, dwFlags, int_flags) && stop_escaping == FALSE) { > - next[0] = '%'; > - next[1] = hexDigits[(cur >> 4) & 0xf]; > - next[2] = hexDigits[cur & 0xf]; > - len = 3; > + if(dwFlags & URL_ESCAPE_AS_UTF8) { > + char utf[4]; > + int i, ret; > + ret = wine_utf8_wcstombs(WC_ERR_INVALID_CHARS, &cur, 1, utf, sizeof(utf)); This won't work for Unicode surrogates. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [resend v2 2/4] ddraw7/tests: Test GetPriority() on cubemap surfaces.
by Marvin 22 Dec '15

22 Dec '15

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=19110 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [resend 3/4] d3d9: Call wined3d_device_copy_sub_resource_region() instead of wined3d_device_update_surface() in d3d9_dev
by Marvin 22 Dec '15

22 Dec '15

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

1 0

Re: [resend 3/4] ddraw: Check for mipmap sublevel through caps in ddraw_surface7_SetColorKey().
by Stefan Dösinger 22 Dec '15

22 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-12-21 um 18:38 schrieb Riccardo Bortolato: > - wined3d_mutex_lock(); > - if (!surface->wined3d_texture) > - { > - wined3d_mutex_unlock(); > + if (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL) > return DDERR_NOTONMIPMAPSUBLEVEL; > - } > - wined3d_mutex_unlock(); This doesn't work here: ../../../../../src/wine/tools/runtest -q -P wine -T ../../.. -M ddraw.dll -p ddraw_test.exe.so ddraw7 && touch ddraw7.ok ddraw7.c:1767: Test succeeded inside todo block: Failed to set color key, hr 0. ddraw7.c:1772: Test succeeded inside todo block: Failed to get color key, hr 0. ddraw7.c:1773: Test succeeded inside todo block: Got unexpected value 0x000000ff. ddraw7.c:1775: Test succeeded inside todo block: Got unexpected value 0x000000ff. ddraw7.c:9485: Tests skipped: Overlays or some YUV formats not supported, skipping YUV colorfill tests. I guess you forgot to remove the todo_wine markers in my test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWeb5HAAoJEN0/YqbEcdMwvQEP/0GfmyB5nebYlCy/Ffbt4lsE M5Nh6BXRnPlVbVwv1nLDEsujyfxWScAb6BHS6jx5QNnsCauv0/cpUDuzR8V4JHdf ltWqqgWBdqDJb0tG6JA89pw1sZwJxa2j92CE46GHSwozlEGX1LsufkeCJQ24XpqD rLD9TyHTTC8xncBr4BfryacbQgL+rp9OEuDLkvUqU1SyHf/OYyFuDRXhIg1rbflO 5PI+IxjFRN45sRKu4v073EcuPTM1BD8iFiAEAInhHcv+EBIHDqTmMcOl+r31w1Sb kWRcM7RMd7f2mLuWtT3UkHhRxo+nGeY3yhpQrYaKmaKJwzFGVPOfsVFPkPajIzLn iu++t1ZVX40m74WWTVJ6xPFFFaQ6CiPeFcUZquwtfaczTTba0lMwIRjpcQxdVC3R nkAZO/wWzVSWHJD4c8jB+I71uyFaE+Aj7AVLQJts8bFyyAwYizGvL2/Xn5Je1RJN PmX2HIobc0elWkL8qOpDzaJ7hRciLHXlWFB8Ce6GKHtJC90H72LgoKMaZBZFILNz EDwdvl7pMbSJJl2XqyiNmBhSVvBZMDzknLWE56qpprGkcGs6eyCSVOYSHswyDgK8 WjaFf81oQzfho+qH9as/tMRiPV/J2GZTs+IWt+47UX4bUVegTAn7wzOJRAh2tDg4 rV+rvEWoQZgm9g8lqKCq =Yx1L -----END PGP SIGNATURE-----

2 1

Re: [PATCH v2] loader: check return values of wld_mprotect and wld_mmap calls
by Sebastian Lackner 22 Dec '15

22 Dec '15

On 22.12.2015 12:22, Paul Gofman wrote: > Fixes loader crash when compiled using Intel compiler (icc 16.0.1 20151021). > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > loader/preloader.c | 26 +++++++++++++++++--------- > 1 file changed, 17 insertions(+), 9 deletions(-) > Its not my decision, but I don't think its a good idea to add all the (unnecessary) ifs just to make this code compatible with ICC. I assume the compiler doesn't handle inline assembly correctly, but this would mean that there are several more affected places. It would be nice to have a more general solution to fix/workaround this issue. If this is not possible, I would at least suggest to add a workaround to the functions directly, instead of adding checks to all places where they are called.

3 8

Re: mmdevapi: Skip device if GetId fails (Coverity)
by Andrew Eikum 22 Dec '15

22 Dec '15

Here too, please print a WARN. Andrew On Tue, Dec 22, 2015 at 07:35:02PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > CID 752979 > > dlls/mmdevapi/devenum.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/dlls/mmdevapi/devenum.c b/dlls/mmdevapi/devenum.c > index d50d206..5f0ffba 100644 > --- a/dlls/mmdevapi/devenum.c > +++ b/dlls/mmdevapi/devenum.c > @@ -1065,9 +1065,11 @@ static HRESULT WINAPI MMDevEnum_GetDevice(IMMDeviceEnumerator *iface, const WCHA > > for (i = 0; i < MMDevice_count; ++i) > { > + HRESULT hr; > WCHAR *str; > dev = &MMDevice_head[i]->IMMDevice_iface; > - IMMDevice_GetId(dev, &str); > + hr = IMMDevice_GetId(dev, &str); > + if (FAILED(hr)) continue; > > if (str && !lstrcmpW(str, name)) > { > -- > 1.9.1 > > > >

1 0

Re: winmm: Respect return value from joyGetPos (Coverity)
by Andrew Eikum 22 Dec '15

22 Dec '15

This section is already consistently using 8-space tabs, I'd rather not break that. Also I think you should print a WARN when joyGetPos returns an error. Andrew On Tue, Dec 22, 2015 at 07:34:59PM +0100, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > CID 1261597 > > dlls/winmm/joystick.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/winmm/joystick.c b/dlls/winmm/joystick.c > index 6ac67f4..fb30ac8 100644 > --- a/dlls/winmm/joystick.c > +++ b/dlls/winmm/joystick.c > @@ -93,7 +93,8 @@ static void CALLBACK JOY_Timer(HWND hWnd, UINT wMsg, UINT_PTR wTimer, DWORD dwTi > > if (joy->hCapture != hWnd) continue; > > - joyGetPos(i, &ji); > + if (joyGetPos(i, &ji) != JOYERR_NOERROR) continue; > + > pos = MAKELONG(ji.wXpos, ji.wYpos); > > if (!joy->bChanged || > -- > 1.9.1 > > > >

1 0

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it
by André Hentschel 22 Dec '15

22 Dec '15

Am 22.12.2015 um 16:34 schrieb Kira Backes: > Hi, Welcome to Wine development! Some suggestions: I would maybe call the inner struct "mouse". What about "user32: Use MOUSEHOOKSTRUCTEX to improve mouse wheel support" as subject/title?

1 0

Help with configure.ac rule wanted
by Uwe Bonnes 22 Dec '15

22 Dec '15

Hello, for some special hardware, e.g the STLink from ST Microelectronic for debugging an programming Arm microprocessors, I have translation dlls that translates the hardware access to libusb calls. To detect libusb, until recently I added the libusb detection code from ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ However recenty Alexandre did some work around the configuration area and things no longer work. I would appreciate if anybody can help me with coming up with a libusb detection rule for wine. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

3 3

Re: ws2_32: Implement automatic broadcast for UDP sockets on sendto()
by Hans Leidekker 22 Dec '15

22 Dec '15

Hi Bruno, >+ if (wsa->addr->sa_family == WS_AF_INET) >+ { >+ /* When the target IPv4 address ends in 255 we must always send it as >+ * a broadcast. Trying to send the packet without setting SO_BROADCAST >+ * results in EACCES, to avoid that we will manually enable the flag >+ * and send the packet, after that we will restore the disabled flag >+ * behavior. This is the most common estimate as the broadcast address >+ * should actually be calculated using the netmask for the interface. */ It should really be calculated using the netmask, sending a broadcast packet here is wrong if the user is not in a /24 network.

2 2

Re: ws2_32: Add WSAPoll() implementation (resend)
by Marvin 22 Dec '15

22 Dec '15

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=19092 Your paranoid android. === w7u (32 bit sock) === sock.c:640: Test failed: oob_server (ae0): not at the OOB mark: 1

1 0

Re: [PATCH 1/2] winhlp32: fix table formatting
by Nikolay Sivov 22 Dec '15

22 Dec '15

On 21.12.2015 22:59, Jean-Christophe Cardot wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=20977 > Fixes https://bugs.winehq.org/show_bug.cgi?id=14288 > > Fix bugs in the handling of the hlp values in order to generate correct > rtf tables; Read the DPI from the registry (instead of hardcoded 72); > Use font scaling (depends on the version) to compute the rtf values > so that the columns width are correct and precise (compared with MS > winhlp32.exe); Add some comments and DEFINES tu make the code easier > to understand. > This is a first step into making wine's winhlp much better at handling > hlp files and - when time permits - mvp files. > > Tested on Linux (Mageia 5) > Hi, Jean-Christophe. Thanks for working on this. Please try to split this one to several patches, for example one to introduce symbols for magic numbers, one for HLPFILE_ReadFont changes, one for DPI changes etc. It will make it much easier to read. > +#define DEFDPI 96 > +static const WCHAR logpixels_reg[] = > {'S','y','s','t','e','m','\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\','H','a','r','d','w','a','r','e',' > ','P','r','o','f','i','l','e','s','\\','C','u','r','r','e','n','t','\\','S','o','f','t','w','a','r','e','\\','F','o','n','t','s',0}; > +static const WCHAR logpixels[] = {'L','o','g','P','i','x','e','l','s',0}; You sure you need this? Won't it work with GetDevicesCaps() on desktop HDC? Also your mail client wrapped your patch, so it can't be applied. You need to fix the way it sends inline patches, send it as attachment, or use git-send-email to do the job for you.

1 0

Re: [PATCH v3] msvcrt: Rename __libm_sse2_* functions to fix compilation, when using Intel compiler.
by Piotr Caban 22 Dec '15

22 Dec '15

> diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index 2459bf5..270bcda 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -1980,7 +1980,7 @@ void _safe_fprem1(void) > /*********************************************************************** > * __libm_sse2_acos (MSVCRT.@) > */ The patch is still not applying cleanly. For some reason in your diff there are 8 spaces before __libm_sse2_acos while in math.c there are 2 tabs. Thanks, Piotr

2 1

Re: [PATCH v2] msvcrt: Rename __libm_sse2_* functions to fix compilation when using Intel compiler.
by Piotr Caban 22 Dec '15

22 Dec '15

On 12/22/15 11:23, Paul Gofman wrote: > +void __cdecl MSVCRT___libm_sse2_atan2(void) > { > double d1, d2; > __asm__ __volatile__( "movq %%xmm0,%0; movq %%xmm1,%1 " : "=m" > (d1), "=m" (d2) ); > @@ -2046,7 +2046,7 @@ void __cdecl __libm_sse2_atan2(void) Your mail client wraps the lines: Applying: msvcrt: Rename __libm_sse2_* functions to fix compilation when using Intel compiler. fatal: patch fragment without header at line 394: @@ -2046,7 +2046,7 @@ void __cdecl __libm_sse2_atan2(void) Thanks, Piotr

2 1

Re: [PATCH] msvcrt: change __libm_sse2_... functions internal names (exported names preserved) msvcr80, msvcr90, msvcr100, msvcr110, msvcr120: update spec file
by Piotr Caban 22 Dec '15

22 Dec '15

On 12/22/15 10:54, Paul Gofman wrote: > -void __cdecl __libm_sse2_acos(void) > +void __cdecl l__libm_sse2_acos(void) In other places where we need to rename functions "MSVCRT_" prefix is added to function name. Could you please change the function names this way? Also it will be nicer to change the commit message to something like: msvcrt: Rename __libm_sse2_* functions to fix compilation when using Intel compiler. Thanks, Piotr

2 1

Re: [PATCH 2/2] oledb32: GetConversionSize shouldn't fail for null variants. (try 2)
by Huw Davies 22 Dec '15

22 Dec '15

On Tue, Dec 22, 2015 at 09:09:46PM +1100, Alistair Leslie-Hughes wrote: > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index a785457..ac2f6be 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -2627,6 +2627,33 @@ static void test_getconversionsize(void) > ok(hr == S_OK, "got 0x%08x\n", hr); > VariantClear(&var); > > + dst_len = 78; > + V_VT(&var) = VT_NULL; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_VARIANT, DBTYPE_WSTR, NULL, &dst_len, &var); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + dst_len = 0; > + src_len = 20; > + V_VT(&var) = VT_BSTR; > + V_BSTR(&var) = SysAllocString(strW); > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_VARIANT, DBTYPE_STR, &src_len, &dst_len, &var); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + ok(dst_len == 5, "%ld\n", dst_len); > + VariantClear(&var); > + > + dst_len = 0; > + src_len = 20; > + V_VT(&var) = VT_I4; > + V_I4(&var) = 4; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_VARIANT, DBTYPE_STR, &src_len, &dst_len, &var); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + VariantClear(&var); > + > + /* On Windows dst_len will get a value of 110 but we aren't testing this parameter. */ > + V_VT(&var) = VT_NULL; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_VARIANT, DBTYPE_STR, NULL, &dst_len, &var); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + Why did you put the comment on the 2nd VT_NULL conversion rather than the first? Same goes for the unneeded dst_len initiailization (which also applies in the VT_I4 case). If would probably make more sense to group these three together, i.e. move the VT_BSTR case to the top, then have the comment, then the three tests (all of which do not need the dst_len init). Huw.

1 0

Re: [PATCH 2/2] oledb32: GetConversionSize shouldn't fail for null variants.
by Huw Davies 22 Dec '15

22 Dec '15

On Tue, Dec 22, 2015 at 06:32:04PM +1100, Alistair Leslie-Hughes wrote: > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index a785457..55539f9 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -2627,6 +2627,33 @@ static void test_getconversionsize(void) > ok(hr == S_OK, "got 0x%08x\n", hr); > VariantClear(&var); > > + dst_len = 78; > + V_VT(&var) = VT_NULL; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_VARIANT, DBTYPE_WSTR, NULL, &dst_len, &var); > + ok(hr == S_OK, "got 0x%08x\n", hr); You should test dst_len after return. Likewise below. Huw.

4 7

build Wine using Intel compiler (win32)
by Paul Gofman 22 Dec '15

22 Dec '15

Dear all, I compiled Wine with icc and found 2 issues, which I managed to fix in the code. The issues are: 1. Crash in Wine loader (at least with using Intel compiler) Checking return values from all the calls to wld_mprotect in loader/preloader.c solved the issue (apparently syscall was optimized out when return value was not used, which is likely a compiler problem) 2. msvcrt/math.c has a number of trigonometrical functions implementations named __libm_sse2_... (e. g., __libm_sse2_cos). icc substitutes these names for some of trigonometrical functions (e. g., tan is replaced internally by __libm_sse2_tan). This results in endless recursion and stack overflow both in __lib_sse2_tan and the ordinary tan function in msvcrt (which is get aliased to __libm_sse2_tan). I solved this by renaming these functions in the code but keeping the original export name through spec files. Is there any chance for such changes to find the way upstream? If yes, could you please advice how is it best to proceed: create a bug first, or just send a patch (probably 2 separate patches) to wine-patches for review? Thanks, Paul.

2 1

Re: [PATCH 1/2] oledb32: Convert to a BSTR to work out it size
by Huw Davies 22 Dec '15

22 Dec '15

On Tue, Dec 22, 2015 at 06:32:03PM +1100, Alistair Leslie-Hughes wrote: > This makes code for handling variants with DBTYPE_STR and DBTYPE_WSTR > types consistent. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 72714d3..a87cf18 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -1372,10 +1372,22 @@ static HRESULT WINAPI convert_GetConversionSize(IDataConvert* iface, > switch (src_type) > { > case DBTYPE_VARIANT: > - if(V_VT((VARIANT*)src) == VT_BSTR) > - *dst_len = (SysStringLen(V_BSTR((VARIANT*)src))+1) * sizeof(WCHAR); > + { > + VARIANT v; > + > + VariantInit(&v); > + if ((hr = VariantChangeType(&v, (VARIANT*)src, 0, VT_BSTR)) == S_OK) > + { > + *dst_len = (SysStringLen(V_BSTR(&v))+1) * sizeof(WCHAR); > + VariantClear(&v); > + } > else > + { > WARN("DBTYPE_VARIANT(%d)->DBTYPE_WSTR unimplemented\n", V_VT((VARIANT*)src)); This WARN should go away, then it will actually be consistent with the DBTYPE_STR case. Huw.

1 0

EnableShell registry key
by Ruslan Kabatsayev 22 Dec '15

22 Dec '15

Hello, Wine 1.8 announcement mentions EnableShell key: > There is an optional Start Menu in desktop mode, that can be enabled > on a per-desktop basis by setting "EnableShell" to "Y" under > HKCU\Software\Wine\Explorer\Desktops\<name>. But when I tried to use it, I failed with "Y" string key (i.e. only desktop with special name "shell" got the start button). After reading the sources that key appears to be a DWORD, so it has to be created as a DWORD with value of "1". Also, the key isn't listed @ http://wiki.winehq.org/UsefulRegistryKeys . What's it supposed to be — a string or a dword? Is it a bug in implementation, or is it a misdocumentation? And should it also be listed @ UsefulRegistryKeys? Regards, Ruslan

2 1

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 20.12.2015 19:42, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > > The code in SetCaretPos doesn't change the caret state if it's position is unchanged. > Reflect this at the server side to avoid caret corruption. > > try2: > - fixed incorrect if statement in the server > --- > dlls/user32/caret.c | 2 +- > server/protocol.def | 3 ++- > server/queue.c | 5 +++++ > 3 files changed, 8 insertions(+), 2 deletions(-) After playing around a bit more I can confirm that this is the right way to fix it. I was already about to send my sign-off, but then I noticed that it breaks ./tools/make_requests, which doesn't seem to like multiline comments in protocol.def. $ ./tools/make_requests Unrecognized syntax * -2=on if the position differs, unchanged otherwise) */ at ./tools/make_requests line 257, <PROTOCOL> line 2981. Please resend after fixing this issue (probably just make the comment a bit smaller), then I'll add my signoff. ;) Best regards, Sebastian

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 3).
by Stefan Dösinger 21 Dec '15

21 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-12-18 um 14:43 schrieb Aaryaman Vasishta: > +static char *create_bitmap(const char *filename, const int w, const int h, const int type) Just fyi: The const on parameters that are passed by value (non-pointers) doesn't really do much, so we usually leave it out. Feel free to keep it though. > + /* Type 1 bitmaps are 8 bpp whereas type 2 bitmaps are 24bpp. */ > + const int bpp = type == 1 ? 8 : 24; Urk. Why not just pass the bpp? Or a "BOOL palettized"? > + unsigned char *buffer = NULL; > + DWORD written, size; > + int i, j; > + > + /* Calculate size of the BITMAPINFO header */ > + /* Space for 256 color palette would need to be allocated if the bitmap is 8bpp */ > + size = sizeof(BITMAPINFOHEADER); > + if (type == 1) > + size += sizeof(RGBQUAD)* 256; > + > + ZeroMemory(&file_header, sizeof(BITMAPFILEHEADER)); Please use memset. Applies to other places as well. > + file_header.bfType = 0x4d42; Other places in Wine add a /* "BM" */ comment to show what the magic number is. dlls/comctl32/imagelist.c uses (('M' << 8) | 'B'). > + buffer[i] = (i + rand()) % 255; Generally it is a bad idea to use random numbers in tests. It encourages random test failures :-) . I guess you want some kind of irregular pattern. You could e.g. use i % 251 (the highest prime < 256). > +static BOOL test_bitmap_data(const unsigned char *buffer1, const unsigned char *buffer2, const D3DRMIMAGE *img, const int depth, const int version) "BOOL upside_down" would be more explanatory than "version" IMO. That the upside down property is related to the version can easily be seen by checking who calls test_bitmap_data with that parameter. > + /* d3drm aligns the 24bpp texture to 4 bytes in the buffer, with one bype padding from 24bpp texture. */ > + /* The image is palettized if the total number of colors used is <= 256. */ Unless I am missing something the first comment isn't really of a concern in this codepath. > + for (i = 0; i < h; i++) > + { > + offset = version == 1 ? (w * i * 3) : (w * (h - i - 1) * 3); > + for (j = 0; j < w; j++) > + { > + val1 = buffer1[k] == buffer2[offset]; > + val2 = buffer1[k + 1] == buffer2[offset + 1]; > + val3 = buffer1[k + 2] == buffer2[offset + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + k += 4; > + offset += 3; > + } The 24bpp -> 32bpp comment would fit well above this code though. > + /* Test if image information matches that from the header by loading the bitmap seperately. */ "separately", according to my Thunderbird's dictionary. > + ok(check, "Cannot delete image stored in %s (error = %x).\n", file, GetLastError()); The way you're writing GetLastError values is inconsistent (%x vs %d). > +static void test_load_texture1(void) > ... > + file = create_bitmap("8bpp.bmp", 100, 100, 1); > ... > +static void test_load_texture2(void) > ... > + file = create_bitmap("palette.bmp", 3, 39, 2); > ... > +static void test_load_texture3(void) > ... > + file = create_bitmap("24bpp.bmp", 100, 100, 2); - From this it isn't obvious if e.g. the upside down reading of v2 and v3 are a property of the interface version or the input format. Please test all formats with all versions. Also consider testing what happens if a texture is created as IDirect3DRMTexture3 and QI'd to IDirect3DRMTexture1. Does it return upside down image data? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWeF7GAAoJEN0/YqbEcdMwnDsP/2rjF3YySneqr0EW+MURA7po RkUAhNBdtaLUo/iUgbAmaddv5yIm6dt0kkh02o1Ci/+iwOR+GpQ9d11B8s1R2sre T7Sg/WhObJcCVWxiUVOOppH+5Kf5HRs9SznOqPJU7K1ZhdF0+JzAAIR3+ujIb71N +YdCdS+VW1T0YoiJMFbzoO0jX0z9B/fT8DfGWFhiusWa6Be7hyXx6+N0hXh6r1BC hDTxLs91lHcPEUAkGlJVJUMwjlB2L+0YuVpZCoDF6nzrBZuOuf7oByUYgz3st5B/ nSFIc2OuW3r7U5oaGk2B/7U8fA1QJpKECJaerj1ki2LdmMplH+3Pecngizmmq4QY C8ns/DXt7szHNItM+sWTB8nvlI3lIppDV6jGJH1B/cBQDrXM5NC8V2DTqySucToV RNqCiLhiU7EDQ4TJycJJmfOonRix51qzt5fjbbrxQH53TI8mU2T9DtwklLRY3TT8 gV0SL17uiyoL3cexargXnIeov+BTOxmUYzgUpkOG4L1oPGht2ikhIQW/I5ZCs4x/ PJ3fLtMaF5lpyuXBjoThbhOzGc0TC/mXRValVvgePADNSRHbHnRnIRk12ZH7EwRI v38AtVTo83hsTZlAtgHoALy4TUkZU4wH8BPhLgC9+BRJVJ9qa+TRnugQZJYZGVDr j8860n5H0A790o6rbURT =7NBX -----END PGP SIGNATURE-----

1 0

Re: ntdll: Fix NtQueryDirectoryFile behavior on short file names on case insensitive file systems (try2)
by Ken Thomases 21 Dec '15

21 Dec '15

On Dec 21, 2015, at 11:42 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > @@ -2214,11 +2205,7 @@ static int read_directory_getattrlist( int fd, IO_STATUS_BLOCK *io, void *buffer > } > else io->u.Status = restart_scan ? STATUS_NO_SUCH_FILE : STATUS_NO_MORE_FILES; > } > - else if ((errno == ENOENT || errno == ENOTDIR) && !get_dir_case_sensitivity(".")) > - { > - io->u.Status = restart_scan ? STATUS_NO_SUCH_FILE : STATUS_NO_MORE_FILES; > - ret = 0; > - } > + else ret = -1; Setting ret to -1 here is redundant. It will already be -1 if getattrlist() failed. Other than that, looks good to me. > } > else ret = -1; > -Ken

1 0

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 21.12.2015 07:04, Anton Baskanov wrote: > You are right, this would fix the issue, but the Windows behavior is > different. The caret remains in it's current state if it's position is > unchanged. > I've attached a simple test application that demonstrates this. It calls > SetCaretPos on mouse button press with different positions for left and > right buttons. Thanks for providing the testcase. I didn't have time to test it on a Windows machine yet (will do that later), but under the assumption that it works as expected, your approach is indeed more correct. Nevertheless, another possible theory would be that SetCaretPos should leave the state untouched. Could you please check that, too?

1 0

Re: [PATCH 1/7] kernel32/tests: Add path tests for the unusual ./../foo case.
by Sebastian Lackner 21 Dec '15

21 Dec '15

On 21.12.2015 17:51, Jeremy White wrote: > Signed-off-by: Jeremy White <jwhite(a)codeweavers.com> > --- > This patch series address issues found in GetLongPathName and GetShortPathName > as reported in bug https://bugs.winehq.org/show_bug.cgi?id=36859. > Thanks to Dmitry for pointing out GetShortPathName should be checked as well > and for the suggestion to use CheckNameLegalDOS8Dot3W. > --- > dlls/kernel32/tests/path.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c > index 85c4ec3..4504603 100644 > --- a/dlls/kernel32/tests/path.c > +++ b/dlls/kernel32/tests/path.c > @@ -2136,6 +2136,15 @@ static void test_relative_path(void) > ok(ret, "GetShortPathName error %d\n", GetLastError()); > ok(!strcmp(buf, "..\\foo\\file"), "expected ..\\foo\\file, got %s\n", buf); > > + strcpy(buf, "deadbeef"); > + ret = pGetLongPathNameA(".\\..\\foo\\file", buf, MAX_PATH); > + ok(ret, "GetLongPathName error %d\n", GetLastError()); > + ok(!strcmp(buf, ".\\..\\foo\\file"), "expected .\\..\\foo\\file, got %s\n", buf); > + strcpy(buf, "deadbeef"); > + ret = GetShortPathNameA(".\\..\\foo\\file", buf, MAX_PATH); > + ok(ret, "GetShortPathName error %d\n", GetLastError()); > + ok(!strcmp(buf, ".\\..\\foo\\file"), "expected .\\..\\foo\\file, got %s\n", buf); > + > SetCurrentDirectoryA(".."); > DeleteFileA("foo\\file"); > RemoveDirectoryA("foo"); > The patch causes test failures here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so path && touch path.ok path.c:2141: Test failed: GetLongPathName error 2 path.c:2142: Test failed: expected .\..\foo\file, got deadbeef [...] After applying all patches those are gone. Is todo_wine missing maybe?

1 0

Plans
by Alexandre Julliard 21 Dec '15

21 Dec '15

Folks, Wine 1.8 is released, congratulations to everybody! The development branch is now open for business, you can resend patches that had been deferred. However, I expect that things will be slow in the next couple of weeks, since many developers are leaving on vacation. I won't be around a whole lot myself either, so it may take a while before we are caught up. I will try to make a 1.9.0 release this Friday. Michael Stefaniuc is now in charge of maintaining the 1.8 stable branch. Please see http://wiki.winehq.org/StableRules for details. Happy holidays! -- Alexandre Julliard julliard(a)winehq.org

5 6

Re: [resend 2/4] ddraw7/tests: Test GetPriority() on cubemap surfaces.
by Marvin 21 Dec '15

21 Dec '15

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=19070 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2253: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. The test timed out

1 0

Re: ntdll: Fix NtQueryDirectoryFile behavior on short file names on case insensitive file systems
by Marvin 21 Dec '15

21 Dec '15

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=19069 Your paranoid android. === w1064 (32 bit directory) === directory.c:302: Test failed: incorrect long file name: L"longfilename.tmp\7434,"

1 0

Re: kernel32/tests: Add test for process object destruction.
by Marvin 21 Dec '15

21 Dec '15

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=19056 Your paranoid android. === wvistau64 (32 bit process) === process.c:2791: Test failed: WaitForSingleObject returned 258 === wvistau64 (64 bit process) === prporocess: process1 tests executed (0 marked .c:2791: Test failed: Waias todotForSingleObject ret, 0 failures), 0urned 258

2 1

Re: [PATCH] user32/tests: One more activation context test for interthread SendMessage
by Marvin 21 Dec '15

21 Dec '15

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=19044 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10623: Test failed: expected PeekMessage to return FALSE, got 1 === w1064 (32 bit msg) === msg.c:6095: Test failed: Update region shouldn't be empty msg.c:6329: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6331: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6101: Test failed: Regions are different msg.c:6101: Test failed: Regions are different msg.c:6101: Test failed: Regions are different

2 1

Re: services: Consistently use debug functions with WINE_ prefix.
by Michael Stefaniuc 21 Dec '15

21 Dec '15

On 12/21/2015 05:55 AM, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> --- > > Similar mistakes exist in many of the other programs. Is this > something we want to fix for consistency reasons? I did that but the other way around aka consistently use the un-prefixed versions. > > programs/services/rpc.c | 2 +- programs/services/services.c > | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/programs/services/rpc.c b/programs/services/rpc.c > index 89a8c91..591d7d1 100644 --- a/programs/services/rpc.c +++ > b/programs/services/rpc.c @@ -1434,7 +1434,7 @@ DWORD __cdecl > svcctl_EnumServicesStatusExW( needed, returned, > wine_dbgstr_w(group)); > > if (resume_handle) - FIXME("resume handle not > supported\n"); + WINE_FIXME("resume handle not > supported\n"); > > if (!type || !state) return ERROR_INVALID_PARAMETER; diff --git > a/programs/services/services.c b/programs/services/services.c index > 1335837..2ec465e 100644 --- a/programs/services/services.c +++ > b/programs/services/services.c @@ -684,7 +684,7 @@ static DWORD > get_service_binary_path(const struct service_entry *service_entry, > strcatW( redirected, &(*path)[len] ); HeapFree( GetProcessHeap(), > 0, *path ); *path = redirected; - TRACE("redirected to > %s\n", debugstr_w(redirected)); + WINE_TRACE("redirected to > %s\n", debugstr_w(redirected)); } > > return ERROR_SUCCESS; > bye michael

1 0

Re: [PATCH] user32: Implement MOUSEHOOKSTRUCTEX
by Nikolay Sivov 21 Dec '15

21 Dec '15

On 21.12.2015 14:14, Kira Backes wrote: > - Fixes out-of-bounds access for programs which cast to MOUSEHOOKSTRUCTEX > - Fixes mouse wheel support for those programs > - Fixes Bug 38314 > > Signed-off-by: Kira Backes <kira.backes(a)nrwsoft.de> > --- > dlls/user32/message.c | 28 ++++++++++++++++------------ > include/winuser.h | 6 ++++++ > tools/winapi/tests.dat | 3 +++ > 3 files changed, 25 insertions(+), 12 deletions(-) > > diff --git a/dlls/user32/message.c b/dlls/user32/message.c > index 96e7f2e..c1fc45d 100644 > --- a/dlls/user32/message.c > +++ b/dlls/user32/message.c > @@ -2488,7 +2488,7 @@ static BOOL process_mouse_message( MSG *msg, > UINT hw_id, ULONG_PTR extra_info, H > INT hittest; > EVENTMSG event; > GUITHREADINFO info; > - MOUSEHOOKSTRUCT hook; > + MOUSEHOOKSTRUCTEX hookEx; > BOOL eatMsg; > Hi, Kira. Please keep variable name as it is, and resend using git-send-email or as an attachment - your mail client wrapped patch lines breaking a patch.

1 0

Re: [3/4 resend] riched20/tests: Add multibyte character tests for selection.
by Huw Davies 21 Dec '15

21 Dec '15

> diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c > index 6c4195c..7c7200b 100644 > --- a/dlls/riched20/tests/editor.c > +++ b/dlls/riched20/tests/editor.c > @@ -4577,6 +4577,28 @@ static void test_EM_EXSETSEL(void) > + SendMessageA(hwndRichEdit, WM_SETTEXT, 0, (LPARAM)"abcdef\x8e\xf0ghijk"); > + /* 012345 6 78901 */ > + /* 10 */ I find this second comment line confusing. I assume you're trying to show that 'j' is at index 10. Either shift the '1' one place to the right so it's underneath the '0' and lose the '0' in this line, or better still just remove the second comment line completely (most people can figure out that zero after nine means ten). This obviously applies to similar lines in this patch and the next. Huw.

1 0

Re: user32: Set correct caret state in the server in SetCaretPos (try 2)
by Sebastian Lackner 20 Dec '15

20 Dec '15

On 20.12.2015 19:42, Anton Baskanov wrote: > Signed-off-by: Anton Baskanov <baskanov(a)gmail.com> > > The code in SetCaretPos doesn't change the caret state if it's position is unchanged. > Reflect this at the server side to avoid caret corruption. > > try2: > - fixed incorrect if statement in the server > --- > dlls/user32/caret.c | 2 +- > server/protocol.def | 3 ++- > server/queue.c | 5 +++++ > 3 files changed, 8 insertions(+), 2 deletions(-) > I assume the "corruption" you mean is that the state could get out of sync between wineserver and child process. However, is there a specific reason (for example testcase) which shows that this is the right way to fix it? A different (and much easier) possibility would be: - if (ret && !hidden && (x != r.left || y != r.top)) + if (ret && !hidden && (x != r.left || y != r.top || !old_state)) Regards, Sebastian

1 0

Re: user32: Set correct caret state in the server in SetCaretPos
by Dmitry Timoshkov 20 Dec '15

20 Dec '15

Anton Baskanov <baskanov(a)gmail.com> wrote: > @@ -3040,6 +3040,10 @@ DECL_HANDLER(set_caret_info) > if (req->flags & SET_CARET_STATE) > { > if (req->state == -1) input->caret_state = !input->caret_state; > + else if (req->state == -2 && > + (req->x != reply->old_rect.left || > + req->y != reply->old_rect.top)) > + input->caret_state = 1; > else input->caret_state = !!req->state; > } If state == -2 but the additional logic won't match this would fall into unexpected 3rd case. -- Dmitry.

2 1

Re: Wine release 1.8
by Ken Thomases 19 Dec '15

19 Dec '15

On Dec 19, 2015, at 10:05 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > The Wine team is proud to announce that the stable release Wine 1.8 > is now available. Congratulations, all! Cheers, Ken

3 2

Calling convention (__stdcall/__cdecl) mismatches between windef.h and crtdefs.h
by Bob Ha 19 Dec '15

19 Dec '15

Hi, It seems crtdefs.h uses older #ifdef checks.Depending on the inclusion order, crtdefs.h's one is being used, e.g. for msvcp*.dll's windef.h # if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) || defined(__APPLE__) crtdefs.h# ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */ Is this something needed to be modified? Cheers ! Bob

2 1

Re: user32/tests: Use 'start' and 'end' variables in test comparisons
by Dmitry Timoshkov 17 Dec '15

17 Dec '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > - INT start,end; > + unsigned short start, end; This can't work. -- Dmitry.

2 4

Re: user32: Select/deselect edit field text when a combo box gets/loses focus
by Dmitry Timoshkov 17 Dec '15

17 Dec '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > --- a/dlls/user32/combo.c > +++ b/dlls/user32/combo.c > @@ -1215,7 +1215,7 @@ static LRESULT COMBO_Command( LPHEADCOMBO lphc, WPARAM wParam, HWND hWnd ) > case (EN_SETFOCUS >> 8): > > TRACE("[%p]: edit [%p] got focus\n", lphc->self, lphc->hWndEdit ); > - > + SendMessageW( lphc->hWndEdit, EM_SETSEL, 0, -1 ); > COMBO_SetFocus( lphc ); > break; > > @@ -1228,7 +1228,7 @@ static LRESULT COMBO_Command( LPHEADCOMBO lphc, WPARAM wParam, HWND hWnd ) > * notification (only when it happens to be a part of > * the combo). ?? - AK. > */ > - > + SendMessageW( lphc->hWndEdit, EM_SETSEL, -1, 0 ); > COMBO_KillFocus( lphc ); > break; These changes require tests to confirm their correctness, and the tests need to cover the cases when a control is part of a dialog and when it's not. -- Dmitry.

2 2

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message. (try 2)
by Marvin 17 Dec '15

17 Dec '15

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=19005 Your paranoid android. === w1064 (32 bit msg) === msg.c:6139: Test failed: Update region shouldn't be empty msg.c:6373: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6375: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6145: Test failed: Regions are different msg.c:6145: Test failed: Regions are different msg.c:6145: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message.
by Marvin 17 Dec '15

17 Dec '15

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=19004 Your paranoid android. === w1064 (32 bit msg) === msg.c:6135: Test failed: Update region shouldn't be empty msg.c:6369: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6371: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6141: Test failed: Regions are different msg.c:6141: Test failed: Regions are different msg.c:6141: Test failed: Regions are different

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture.
by Stefan Dösinger 16 Dec '15

16 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Cool to see that you're still working on this :-) . Am 2015-12-15 um 16:41 schrieb Aaryaman Vasishta: > + * Copyright 2015 Aaryaman Vasishta I think you can make this 2014-2015. > +static char *create_testbitmap(const char *filename, LPCSTR resource) LPCSTR -> const char * is better IMO. > +{ > + static char path[MAX_PATH]; > + DWORD written; > + HANDLE file; > + HRSRC res; > + void *ptr; > + > + GetTempPathA(sizeof(path)/sizeof(WCHAR), path); Why sizeof(WCHAR)? > + lstrcatA(path, filename); > + > + file = CreateFileA(path, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation failed, at %s, error %d\n", path, > + GetLastError()); > + > + res = FindResourceA(GetModuleHandleA(NULL), resource, (LPCSTR)RT_RCDATA); const char * > + ok( res != 0, "couldn't find resource\n" ); > + ptr = LockResource( LoadResource( GetModuleHandleA(NULL), res )); > + WriteFile( file, ptr, SizeofResource( GetModuleHandleA(NULL), res ), &written, NULL ); > + ok( written == SizeofResource( GetModuleHandleA(NULL), res ), "couldn't write resource\n" ); > + CloseHandle( file ); You have inconsistent style here. ok(foo, "bar\n"); vs ok( foo, "bar\n" ); > +static BOOL test_bitmap_data1(unsigned char *buffer1, unsigned char *buffer2, D3DRMIMAGE *img, int w, int h, int depth) afaics you can make buffer1 and buffer2 const, probably applies to img as well. > + if (img->palette) > + { > + if (depth == 8) > + { > + for (i = 0; i < size; i++) > + { > + if (buffer1[i] != buffer2[i]) > + return FALSE; > + } > + } > + else > + { > + /* d3drm aligns the 24bpp texture to 4 bytes in the buffer, with one bype padding from 24bpp texture. */ > + /* The image is palettized if the total number of colors used is < 256. */ Does this ever happen? A palettized image with != 8 bpp? > + for (i = 0, j = 0; i < w * h; i += 3, j++) > + { > + val1 = img->palette[buffer1[j]].blue == buffer2[i]; > + val2 = img->palette[buffer1[j]].green == buffer2[i + 1]; > + val3 = img->palette[buffer1[j]].red == buffer2[i + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + } > + } Your indentation is wrong here. > + for (i = 0, j = 0; i < w * h; i += 4, j += 3) > + { > + val1 = buffer1[i] == buffer2[j]; > + val2 = buffer1[i + 1] == buffer2[j + 1]; > + val3 = buffer1[i + 2] == buffer2[j + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + } I think you're supposed to use img->bytes_per_line to advance from one line to another. See e.g. how lPitch is handled in ddraw tests. > +static void test_load_texture1(void) > +{ > + HRESULT hr; > + IDirect3DRM *d3drm1 = NULL; > + IDirect3DRMTexture *texture1 = NULL; > + D3DRMIMAGE *d3drm_img = NULL; > + HWND window; > + HBITMAP hbm = NULL; > + BITMAP bm; > + BITMAPFILEHEADER *bmp_header = NULL; > + BITMAPINFO *bmp_info = NULL; > + HANDLE hfile, hmapping = NULL; > + BOOL check; > + DWORD size; > + char *file = NULL; > + unsigned char *buffer = NULL, *buffer1 = NULL, *buffer2 = NULL; > + HDC mem_dc = NULL; > + > + window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, 0, 0, 0, 0); > + file = create_testbitmap("8bpp.bmp", (LPCSTR)MAKEINTRESOURCE(IDD_BITMAPDATA_8BPP)); > + > + hbm = LoadImageA(NULL, file, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE); > + ok(hbm != NULL, "Cannot load image %s (error = %x).\n", file, GetLastError()); > + > + mem_dc = CreateCompatibleDC(NULL); > + ok(mem_dc != NULL, "Cannot create memory device context.\n"); > + > + SelectObject(mem_dc, hbm); > + GetObjectA(hbm, sizeof(bm), &bm); > + > + > + /* Test if image information matches that from the header by loading the bitmap seperately. */ Two newlines. > + hfile = CreateFileA(file, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "Failed to open file at %s, error %d\n", file, > + GetLastError()); > + if (hfile == INVALID_HANDLE_VALUE) > + goto cleanup; > + > + size = GetFileSize(hfile, NULL); > + ok(size != INVALID_FILE_SIZE, "Failed to get file size, error %d\n", GetLastError()); > + if (size == INVALID_FILE_SIZE) > + goto cleanup; > + > + hmapping = CreateFileMappingA(hfile, NULL, PAGE_READONLY, 0, 0, NULL); > + ok(hmapping != NULL, "Cannot create file mapping (error = %x).\n", GetLastError()); > + if (hmapping == NULL) > + goto cleanup; > + > + buffer = MapViewOfFile(hmapping, FILE_MAP_READ, 0, 0, 0); > + ok(buffer != NULL, "Cannot create map view of file (error = %x).\n", GetLastError()); > + if (buffer == NULL) > + goto cleanup; > + > + bmp_header = (BITMAPFILEHEADER *)buffer; > + bmp_info = (BITMAPINFO *)((unsigned char *)buffer + sizeof(BITMAPFILEHEADER)); > + buffer1 = ((unsigned char *)buffer + bmp_header->bfOffBits); This seems a bit unelegant to me, but I don't have a better solution available right now. I guess something along the lines of copying the image into a DIB section with BitBlt may work. > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + hr = IDirect3DRM_LoadTexture(d3drm1, file, &texture1); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", hr); > + d3drm_img = IDirect3DRMTexture_GetImage(texture1); > + todo_wine ok(d3drm_img != NULL, "Could not get a D3DRMIMAGE struct from texture.\n"); > + if (d3drm_img == NULL) > + goto cleanup; > + ok(bmp_info->bmiHeader.biWidth == d3drm_img->width, "Expected texture width == %d, got %d.\n", bmp_info->bmiHeader.biWidth, d3drm_img->width); > + ok(bmp_info->bmiHeader.biHeight == d3drm_img->height, "Expected texture height == %d, got %d.\n", bmp_info->bmiHeader.biHeight, d3drm_img->height); > + buffer2 = (unsigned char *)d3drm_img->buffer1; > + check = test_bitmap_data1(buffer2, buffer1, d3drm_img, bm.bmWidth, bm.bmHeight, bmp_info->bmiHeader.biBitCount); > + ok(check, "Buffer contents do not match that of bitmap.\n"); > + > +cleanup: > + UnmapViewOfFile(buffer); > + CloseHandle(hmapping); > + CloseHandle(hfile); > + DeleteDC(mem_dc); > + DeleteObject(hbm); > + IDirect3DRMTexture_Release(texture1); > + IDirect3DRM_Release(d3drm1); > + check = DeleteFileA(file); > + ok(check, "Cannot delete image stored in %s (error = %x).\n", file, GetLastError()); > + DestroyWindow(window); > +} > + > +static BOOL test_bitmap_data2(unsigned char *buffer1, unsigned char *buffer2, D3DRMIMAGE *img, int w, int h, int depth) If I understand it right and remember it properly from our chat, the difference is that version 2 is upside down. I think that can be handled via a parameter and without duplicating the function. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcIZjAAoJEN0/YqbEcdMw2ZcP/3h4HmIjK2ENd0nhkj4Zae34 XgMQe9gXTRtdmsjIHgcFRDwIfxbjA0XX5CazCFAsL0cz58zzNtMUuugXBeraDzeR 7CTUNPdivsHzVm3V8hRjCDWuGSGZmVHiBNJE2OL0GKVdzYOmRWC3FOMy5ICD/ZdR GDrut5zr59vTieRZieov0Mx3jfAtWkeHLU/MVEFFljCBcUVRj1FIvClrGZDXk3Xn DW82LQrv8QXRtPh8ruLySFgeBDG0iTZ+4N6iIJwWPvd6qbg5Ku0MQOx3K8VsnQi8 7OlcQ8wzIvX8QxXsu1zBQwVNbJBQCup3zC8rqeqg27EoEYPZvQLwIAL/U7xd83Ul s8tFatOV9WD/sBmSa4XY4A1hMkgDqyhNIWrcOd6mm4hUaAbLac60NwNG6cAPtj0w fxlhIegqJ9B7Cs7xhGjFtsO5TqIeLUd0f5k6IWsgEAKv4KVz6pVYKGlrB5PM9jLw Xv8b3usjk9c3eoB5KExb/VhU6ea+sacc6XBGkEJEyu2b5r4gFNfrBRrxvOzKHJ1x xkvle6mmHSn3lxZXmvuEKHZBZPvRNDszvLX4BCuGPRRCpU4JNLY3/aF1kXpX3ks1 RwHYJU/ufJgDvLtYRnBeQOjK4cNdkZyhbH0lrkkcBig38F4xPcjjym+jdPro0X1N voYrN8i/7cKq/ASKNWAD =3KSr -----END PGP SIGNATURE-----

2 1

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture.
by Henri Verbeet 16 Dec '15

16 Dec '15

On 15 December 2015 at 17:41, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > dlls/d3drm/tests/24bpp.bmp | Bin 0 -> 195894 bytes > dlls/d3drm/tests/8bpp.bmp | Bin 0 -> 2142 bytes > dlls/d3drm/tests/Makefile.in | 4 +- > dlls/d3drm/tests/d3drm.c | 400 +++++++++++++++++++++++++++++++++++++++++++ > dlls/d3drm/tests/d3drmrs.rc | 28 +++ > dlls/d3drm/tests/palette.bmp | Bin 0 -> 30054 bytes > dlls/d3drm/tests/resources.h | 26 +++ > 7 files changed, 457 insertions(+), 1 deletion(-) > create mode 100644 dlls/d3drm/tests/24bpp.bmp > create mode 100644 dlls/d3drm/tests/8bpp.bmp > create mode 100644 dlls/d3drm/tests/d3drmrs.rc > create mode 100644 dlls/d3drm/tests/palette.bmp > create mode 100644 dlls/d3drm/tests/resources.h > I suppose I'm missing something subtle, but these bitmaps look like it would take considerably less bytes to just generate them in the test.

2 1

Re: [PATCH 2/5] wined3d: Limit the number of multisample levels reported by wined3d_check_device_multisample_type().
by Henri Verbeet 15 Dec '15

15 Dec '15

On 14 December 2015 at 23:37, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -4426,7 +4428,7 @@ HRESULT CDECL wined3d_check_device_multisample_type(const struct wined3d *wined3 > if (quality_levels) > { > if (multisample_type == WINED3D_MULTISAMPLE_NON_MASKABLE) > - *quality_levels = gl_info->limits.samples; > + *quality_levels = wined3d_log2i(gl_info->limits.samples); > else > *quality_levels = 1; > } I'm not sure this really makes sense. It may make sense to limit the number of non-maskable quality levels to 8, similar to how we limit e.g. shader constants and render targets for d3d9, although that would need a test and a comment. I don't see how you can justify the wined3d_log2i(). As an aside, note that we don't actually support maskable multi-sampling and would need ARB_texture_multisample for that, although applications don't seem to do a lot of masking in practice. D3d10+ only has maskable multi-sampling.

2 2

Re: [PATCH 2/2] d3dx9_36: Make DDS header the same as native. (try 5)
by Matteo Bruni 15 Dec '15

15 Dec '15

2015-12-15 9:13 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> The subject isn't quite right given that the caps field is still different from native. Something like "d3dx9: Improve generated DDS file header." would be better. Again, just deferring until the release, looks good enough otherwise.

1 0

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