September 2016 - Wine-Devel

Re: [PATCH] ws2_32: accept addrlelen32 parameter is optional
by Bruno Jesus Sept. 6, 2016

Sept. 6, 2016

On Tue, Sep 6, 2016 at 10:38 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/ws2_32/socket.c | 2 +- > dlls/ws2_32/tests/sock.c | 9 +++++++++ > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 79ccfc2..38fa62f 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2653,7 +2653,7 @@ SOCKET WINAPI WS_accept(SOCKET s, struct WS_sockaddr *addr, int *addrlen32) > SERVER_END_REQ; > if (!status) > { > - if (addr && WS_getpeername(as, addr, addrlen32)) > + if (addr && addrlen32 && WS_getpeername(as, addr, addrlen32)) > { > WS_closesocket(as); > return SOCKET_ERROR; > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 2640dd4..8c6ca29 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -4200,6 +4200,15 @@ static void test_accept(void) > ok(socklen != sizeof(ss), "unexpected length\n"); > ok(ss.ss_family, "family not set\n"); Hi, I have the impression that you are leaking the accepted and connector socket from previous tests, can you please check? > + socklen = sizeof(address); > + connector = setup_connector_socket(&address, socklen, FALSE); > + if (connector == INVALID_SOCKET) goto done; > + > + memset(&ss, 0, sizeof(ss)); > + accepted = accept(server_socket, (struct sockaddr *)&ss, NULL); > + ok(accepted != INVALID_SOCKET, "Failed to accept connection, %d\n", WSAGetLastError()); > + ok(!ss.ss_family, "family not set\n"); I believe the comment should be "family set\n", right? But actually your change suggests that the whole structure should be left unmodified so I believe it's better to test the whole structure to ensure the change is fully tested. You could add ss_empty variable, memset it to zero and memcmp both. Please fix the subject ;-) Best wishes, Bruno

1 0

Re: setupapi/tests: Also check for ERROR_CALL_NOT_IMPLEMENTED at the second call to SetupDiCreateDeviceInfoListExW
by Marvin Sept. 6, 2016

Sept. 6, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25601 Your paranoid android. === w1064 (64 bit devinst) === devinst.c:1137: Test failed: Unexpected path \\?\root#legacy_bogus#0001#{6a55b5a4-3f65-11db-b704-0011955c2bdb} devinst.c:1259: Test failed: Expected key to not exist devinst.c:1365: Test failed: Expected key to not exist

1 0

Re: [PATCH 2/2] user32/tests: On Win 8 and later, moving a window off-screen doesn't crop its update region.
by Marvin Sept. 6, 2016

Sept. 6, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25560 Your paranoid android. === w864 (32 bit msg) === msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (32 bit msg) === msg.c:7444: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x001a instead msg.c:7444: Test failed: destroy child on thread exit: 2: the msg 0x0014 was expected, but got msg 0x000f instead msg.c:7444: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 0014 msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (64 bit msg) === msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (64 bit msg) === msg.c:7089: Test failed: SetWindowPos:FrameChangedDeferErase: 10: the msg sequence is not complete: expected 0000 - actual 001a msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

3 2

Re: [PATCH v3 07/20] winebus.sys: Add Linux udev bus
by Thomas Faber Sept. 6, 2016

Sept. 6, 2016

> +NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + NTSTATUS rc = STATUS_NOT_SUPPORTED; You generally want to initialize this with irp->IoStatus.Status. For requests the bus driver doesn't support, it needs to return whatever the drivers higher up the stack decided. E.g. IRP_MN_QUERY_DEVICE_RELATIONS might be handled by a bus driver FDO above, in which case it will likely set the status to success -- and lower-level drivers need to propagate this status unless they have specific reason to override it. This is the reason for the requirement to initialize IoStatus to STATUS_NOT_SUPPORTED when sending the IRP. > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + > + switch(irpsp->MinorFunction) > + { > + case IRP_MN_QUERY_DEVICE_RELATIONS: > + TRACE("IRP_MN_QUERY_DEVICE_RELATIONS\n"); > + break; > + case IRP_MN_QUERY_ID: > + { > + TRACE("IRP_MN_QUERY_ID\n"); > + break; > + } > + case IRP_MN_QUERY_CAPABILITIES: > + TRACE("IRP_MN_QUERY_CAPABILITIES\n"); > + break; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + return rc; > +} > + > +DWORD check_bus_disabled(UNICODE_STRING *registry_path) > +{ > + OBJECT_ATTRIBUTES attr; > + HANDLE key; > + DWORD disabled = 0; > + static const WCHAR disabledW[] = {'D','i','s','a','b','l','e','d',0}; > + static const UNICODE_STRING disabled_str = {sizeof(disabledW) - sizeof(WCHAR), sizeof(disabledW), (WCHAR*)disabledW}; > + > + InitializeObjectAttributes(&attr, registry_path, OBJ_CASE_INSENSITIVE, NULL, NULL); This is another case for OBJ_KERNEL_HANDLE. You basically want this by default in kernel code, unless you specifically intend to pass this handle to an application. > + if (ZwOpenKey(&key, KEY_ALL_ACCESS, &attr) == STATUS_SUCCESS) > + { > + DWORD size; > + KEY_VALUE_PARTIAL_INFORMATION info; > + > + if (ZwQueryValueKey(key, &disabled_str, KeyValuePartialInformation, &info, sizeof(info), &size) == STATUS_SUCCESS) Your 'info' structure isn't large enough to hold DWORD data, since the 'Data' member is a one byte array. > + { > + disabled = *(DWORD*)&info.Data; > + } > + > + ZwClose(key); > + } > + > + return disabled; > +}

1 0

Re: [PATCH v3 03/20] ntoskrnl.exe: Implement loading plug and play devices
by Thomas Faber Sept. 6, 2016

Sept. 6, 2016

> @@ -2791,10 +2794,188 @@ done: > } > > > +static NTSTATUS WINAPI internal_complete( DEVICE_OBJECT *device, IRP *irp, void *context ) > +{ > + SetEvent( irp->UserEvent ); > + return STATUS_MORE_PROCESSING_REQUIRED; > +} > + > + > +static NTSTATUS send_device_irp( DEVICE_OBJECT *device, IRP *irp, ULONG_PTR *info ) > +{ > + NTSTATUS status; > + IO_STACK_LOCATION *irpsp; > + HANDLE event = CreateEventA( NULL, FALSE, FALSE, NULL ); > + > + irp->UserEvent = event; > + irpsp = IoGetNextIrpStackLocation( irp ); > + irpsp->CompletionRoutine = internal_complete; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; You probably want a call on cancel too? > + IoCallDriver( device, irp ); > + > + if (irp->IoStatus.u.Status == STATUS_PENDING) > + WaitForSingleObject( event, INFINITE ); STATUS_PENDING is returned from the dispatch routine, it doesn't make sense in irp->IoStatus. (Between your call to IoCallDriver and your completion routine firing, somebody else owns the IRP, meaning you're not allowed to touch it.) > + status = irp->IoStatus.u.Status; > + if (info) > + *info = irp->IoStatus.Information; > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + CloseHandle( event ); > + return status; > +} > + > + > +static NTSTATUS get_device_id( DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCHAR **id ) > +{ > + IO_STACK_LOCATION *irpsp; > + IO_STATUS_BLOCK irp_status; > + IRP *irp; > + > + if (!(irp = IoBuildSynchronousFsdRequest( IRP_MJ_PNP, device, NULL, 0, NULL, NULL, &irp_status ))) > + return STATUS_NO_MEMORY; > + > + irpsp = IoGetNextIrpStackLocation( irp ); > + irpsp->MinorFunction = IRP_MN_QUERY_ID; > + irpsp->Parameters.QueryId.IdType = type; You should initialize irp->IoStatus.Status to STATUS_NOT_SUPPORTED, drivers depend on this (they're supposed to leave it untouched for requests they don't support). > + return send_device_irp( device, irp, (ULONG_PTR *)id ); > +} > + > + > +static BOOL get_driver_for_id( const WCHAR *id, WCHAR *driver ) > +{ > + static const WCHAR serviceW[] = {'S','e','r','v','i','c','e',0}; > + static const UNICODE_STRING service_str = { sizeof(serviceW) - sizeof(WCHAR), sizeof(serviceW), (WCHAR *)serviceW }; > + static const WCHAR critical_fmtW[] = > + {'\\','R','e','g','i','s','t','r','y', > + '\\','M','a','c','h','i','n','e', > + '\\','S','y','s','t','e','m', > + '\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t', > + '\\','C','o','n','t','r','o','l', > + '\\','C','r','i','t','i','c','a','l','D','e','v','i','c','e','D','a','t','a','b','a','s','e', > + '\\','%','s',0}; > + WCHAR buffer[sizeof(KEY_VALUE_PARTIAL_INFORMATION) + MAX_SERVICE_NAME * sizeof(WCHAR)]; > + KEY_VALUE_PARTIAL_INFORMATION *info = (KEY_VALUE_PARTIAL_INFORMATION *)buffer; > + OBJECT_ATTRIBUTES attr; > + UNICODE_STRING key; > + NTSTATUS status; > + HANDLE hkey; > + WCHAR *keyW; > + DWORD len; > + > + if (!(keyW = RtlAllocateHeap( GetProcessHeap(), 0, sizeof(critical_fmtW) + strlenW(id) * sizeof(WCHAR) ))) > + return STATUS_NO_MEMORY; > + > + sprintfW( keyW, critical_fmtW, id ); > + RtlInitUnicodeString( &key, keyW ); > + InitializeObjectAttributes( &attr, &key, OBJ_CASE_INSENSITIVE, NULL, NULL ); This should have OBJ_KERNEL_HANDLE in native, not sure if that is, or ever will be, relevant for Wine. > + status = ZwOpenKey( &hkey, KEY_ALL_ACCESS, &attr ); > + RtlFreeUnicodeString( &key ); > + if (status != STATUS_SUCCESS) > + { > + WARN_(plugplay)( "failed to open critical device database\n" ); > + return FALSE; > + } > + > + status = ZwQueryValueKey( hkey, &service_str, KeyValuePartialInformation, > + info, sizeof(buffer) - sizeof(WCHAR), &len ); > + ZwClose( hkey ); > + if (status != STATUS_SUCCESS || info->Type != REG_SZ) > + { > + TRACE_(plugplay)( "no driver found for %s\n", debugstr_w(id) ); > + return FALSE; > + } > + > + memcpy( driver, info->Data, info->DataLength ); > + driver[ info->DataLength / sizeof(WCHAR) ] = 0; > + TRACE_(plugplay)( "found driver %s for %s\n", debugstr_w(driver), debugstr_w(id) ); > + return TRUE; > +} > + > + > +static void handle_bus_relations( DEVICE_OBJECT *device ) > +{ > + static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > + WCHAR buffer[MAX_SERVICE_NAME + sizeof(servicesW)/sizeof(WCHAR)]; > + WCHAR driver[MAX_SERVICE_NAME] = {0}; > + DRIVER_OBJECT *driver_obj; > + UNICODE_STRING string; > + WCHAR *ids, *ptr; > + NTSTATUS status; > + > + TRACE_(plugplay)( "(%p)\n", device ); > + > + /* We could (should?) do a full IRP_MN_QUERY_DEVICE_RELATIONS query, > + * but we dont have to, We have the DEVICE_OBJECT of the new device > + * so we can simply handle the process here */ > + > + status = get_device_id( device, BusQueryCompatibleIDs, &ids ); PNP (and power, and generally most) IRPs should be sent to the top of the device stack. That generally means you want to throw an IoGetAttachedDeviceReference call in before sending an IRP. > + if (status != ERROR_SUCCESS || !ids) STATUS_SUCCESS? > + { > + ERR_(plugplay)( "Failed to get device IDs\n" ); > + return; > + } > + > + for (ptr = ids; *ptr; ptr += strlenW(ptr) + 1) > + { > + if (get_driver_for_id( ptr, driver )) > + break; > + } > + RtlFreeHeap( GetProcessHeap(), 0, ids ); > + > + if (!driver[0]) > + { > + ERR_(plugplay)( "No matching driver found for device\n" ); > + return; > + } > + > + strcpyW( buffer, servicesW ); > + strcatW( buffer, driver ); > + RtlInitUnicodeString( &string, buffer ); > + if (ZwLoadDriver( &string ) != STATUS_SUCCESS) > + { > + ERR_(plugplay)( "Failed to load driver %s\n", debugstr_w(driver) ); > + return; > + } > + > + strcpyW( buffer, driverW ); > + strcatW( buffer, driver ); > + RtlInitUnicodeString( &string, buffer ); > + if (ObReferenceObjectByName( &string, OBJ_CASE_INSENSITIVE, NULL, > + 0, NULL, KernelMode, NULL, (void **)&driver_obj ) != STATUS_SUCCESS) > + { > + ERR_(plugplay)( "Failed to locate loaded driver %s\n", debugstr_w(driver) ); > + return; > + } > + > + if (driver_obj->DriverExtension->AddDevice) > + status = driver_obj->DriverExtension->AddDevice( driver_obj, device ); > + else > + status = STATUS_NOT_IMPLEMENTED; > + > + ObDereferenceObject( driver_obj ); > + > + if (status != STATUS_SUCCESS) > + ERR_(plugplay)( "AddDevice failed for driver %s\n", debugstr_w(driver) ); > +} > + > + > /*********************************************************************** > * IoInvalidateDeviceRelations (NTOSKRNL.EXE.@) > */ > void WINAPI IoInvalidateDeviceRelations( DEVICE_OBJECT *device_object, DEVICE_RELATION_TYPE type ) > { > - FIXME( "(%p, %i): stub\n", device_object, type ); > + TRACE( "(%p, %i)\n", device_object, type ); > + > + switch (type) > + { > + case BusRelations: > + handle_bus_relations( device_object ); > + break; > + default: > + FIXME( "unhandled relation %i\n", type ); > + break; > + } > } > >

2 4

Re: taskschd: Added ITaskDefinition::get_Triggers implementation.
by Marvin Sept. 6, 2016

Sept. 6, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25577 Your paranoid android. === w1064 (32 bit scheduler) === scheduler.c:159: Test failed: expected ERROR_INVALID_NAME, got 0x80070002 scheduler.c:204: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:354: Test failed: expected ERROR_FILE_NOT_FOUND, got 0 scheduler.c:767: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:773: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:941: Test failed: expected ERROR_FILE_NOT_FOUND, got 0 === w1064 (64 bit scheduler) === scheduler.c:159: Test failed: expected ERROR_INVALID_NAME, got 0x80070002 scheduler.c:204: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:354: Test failed: expected ERROR_FILE_NOT_FOUND, got 0 scheduler.c:767: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:773: Test failed: expected ERROR_PATH_NOT_FOUND, got 0x80070002 scheduler.c:941: Test failed: expected ERROR_FILE_NOT_FOUND, got 0

1 0

Re: [PATCH v2] d3d11/tests: Extend GetDC() tests
by Henri Verbeet Sept. 6, 2016

Sept. 6, 2016

On 6 September 2016 at 11:42, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > dlls/d3d11/tests/Makefile.in | 2 +- > dlls/d3d11/tests/d3d11.c | 159 ++++++++++++++++++++++++++++++++++++++----- > 2 files changed, 142 insertions(+), 19 deletions(-) > Unfortunately this fails here on Windows: d3d11.c:8502: Test failed: Got unexpected size 24 for format B8G8R8A8_UNORM. d3d11.c:8516: Test failed: Got unexpected bits 00000000 for format B8G8R8A8_UNORM. d3d11.c:8518: Test failed: Got unexpected size 2686104 for format B8G8R8A8_UNORM. d3d11.c:8520: Test failed: Got unexpected width 9502720 for format B8G8R8A8_UNORM. d3d11.c:8522: Test failed: Got unexpected height 9502720 for format B8G8R8A8_UNORM. d3d11.c:8524: Test failed: Got unexpected plane count 0 for format B8G8R8A8_UNORM. d3d11.c:8526: Test failed: Got unexpected bit count 0 for format B8G8R8A8_UNORM. d3d11.c:8528: Test failed: Got unexpected compression 0x28fd48 for format B8G8R8A8_UNORM. d3d11.c:8530: Test failed: Got unexpected image size 2686324 for format B8G8R8A8_UNORM. d3d11.c:8532: Test failed: Got unexpected horizontal resolution 4316655 for format B8G8R8A8_UNORM. d3d11.c:8534: Test failed: Got unexpected vertical resolution 1 for format B8G8R8A8_UNORM. d3d11.c:8536: Test failed: Got unexpected used colour count 4330808 for format B8G8R8A8_UNORM. d3d11.c:8538: Test failed: Got unexpected important colour count 2686152 for format B8G8R8A8_UNORM. d3d11.c:8540: Test failed: Got unexpected colour masks 0x0028fcb8 0x735a25c5 0x00000000 for format B8G8R8A8_UNORM. d3d11.c:8543: Test failed: Got unexpected section 000020A4 for format B8G8R8A8_UNORM. d3d11.c:8544: Test failed: Got unexpected offset 4228276 for format B8G8R8A8_UNORM. d3d11.c:8502: Test failed: Got unexpected size 24 for format B8G8R8A8_TYPELESS. d3d11.c:8516: Test failed: Got unexpected bits 00000000 for format B8G8R8A8_TYPELESS. d3d11.c:8518: Test failed: Got unexpected size 2686104 for format B8G8R8A8_TYPELESS. d3d11.c:8520: Test failed: Got unexpected width 9502720 for format B8G8R8A8_TYPELESS. d3d11.c:8522: Test failed: Got unexpected height 9502720 for format B8G8R8A8_TYPELESS. d3d11.c:8524: Test failed: Got unexpected plane count 0 for format B8G8R8A8_TYPELESS. d3d11.c:8526: Test failed: Got unexpected bit count 0 for format B8G8R8A8_TYPELESS. d3d11.c:8528: Test failed: Got unexpected compression 0x28fd48 for format B8G8R8A8_TYPELESS. d3d11.c:8530: Test failed: Got unexpected image size 2686324 for format B8G8R8A8_TYPELESS. d3d11.c:8532: Test failed: Got unexpected horizontal resolution 4316655 for format B8G8R8A8_TYPELESS. d3d11.c:8534: Test failed: Got unexpected vertical resolution 1 for format B8G8R8A8_TYPELESS. d3d11.c:8536: Test failed: Got unexpected used colour count 4330808 for format B8G8R8A8_TYPELESS. d3d11.c:8538: Test failed: Got unexpected important colour count 2686152 for format B8G8R8A8_TYPELESS. d3d11.c:8540: Test failed: Got unexpected colour masks 0x0028fcb8 0x735a25c5 0x00000000 for format B8G8R8A8_TYPELESS. d3d11.c:8543: Test failed: Got unexpected section 000020A4 for format B8G8R8A8_TYPELESS. d3d11.c:8544: Test failed: Got unexpected offset 4228276 for format B8G8R8A8_TYPELESS. d3d11.c:8502: Test failed: Got unexpected size 24 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8516: Test failed: Got unexpected bits 00000000 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8518: Test failed: Got unexpected size 2686104 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8520: Test failed: Got unexpected width 9502720 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8522: Test failed: Got unexpected height 9502720 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8524: Test failed: Got unexpected plane count 0 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8526: Test failed: Got unexpected bit count 0 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8528: Test failed: Got unexpected compression 0x28fd48 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8530: Test failed: Got unexpected image size 2686324 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8532: Test failed: Got unexpected horizontal resolution 4316655 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8534: Test failed: Got unexpected vertical resolution 1 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8536: Test failed: Got unexpected used colour count 4330808 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8538: Test failed: Got unexpected important colour count 2686152 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8540: Test failed: Got unexpected colour masks 0x0028fcb8 0x735a25c5 0x00000000 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8543: Test failed: Got unexpected section 000020A4 for format B8G8R8A8_UNORM_SRGB. d3d11.c:8544: Test failed: Got unexpected offset 4228276 for format B8G8R8A8_UNORM_SRGB.

1 0

Re: [PATCH] d3d11/tests: Extend GetDC() tests
by Henri Verbeet Sept. 6, 2016

Sept. 6, 2016

On 5 September 2016 at 21:45, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + static const struct > + { > + const char *name; > + DXGI_FORMAT format; > + unsigned int bit_count; > + DWORD mask_r, mask_g, mask_b; > + BOOL getdc_supported; > + } > + testdata[] = > + { > + {"B8G8R8A8_UNORM", DXGI_FORMAT_B8G8R8A8_UNORM, 32, 0x00000000, 0x00000000, 0x00000000, TRUE }, > + {"B8G8R8A8_TYPELESS", DXGI_FORMAT_B8G8R8A8_TYPELESS, 32, 0x00000000, 0x00000000, 0x00000000, TRUE }, > + {"B8G8R8A8_UNORM_SRGB", DXGI_FORMAT_B8G8R8A8_UNORM, 32, 0x00000000, 0x00000000, 0x00000000, TRUE }, > + }; I guess this was inherited from the d3d9 test, but not all of these fields are very useful in the current form of the test. Do you intend to add more formats later?

2 2

Re: [PATCH v11 3/3] shell32: Implement FolderItems_get_Count.
by Marvin Sept. 6, 2016

Sept. 6, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25567 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH v11 2/3] shell32: Implement FolderItems_Item.
by Marvin Sept. 6, 2016

Sept. 6, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25566 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] d3dxof: avoid some strcpy overflows (Coverity)
by Henri Verbeet Sept. 6, 2016

Sept. 6, 2016

On 4 September 2016 at 11:24, Marcus Meissner <marcus(a)jet.franken.de> wrote: > @@ -532,8 +532,11 @@ static BOOL is_name(parse_buffer* buf) > buf->rem_bytes -= pos; > > TRACE("Found name %s\n", tmp); > + if (strlen(tmp)+1 > sizeof(buf->value)) { > + FIXME("name %s exceeds buffer length\n", tmp); > + return FALSE; > + } > strcpy((char*)buf->value, tmp); > - > return TRUE; > } There are plenty of things wrong with d3dxof, but assuming the preceding code isn't too broken, I don't think this can happen. You should probably just get rid of the "tmp" buffer and use read_bytes() or something similar after calculating "pos" though. (The TRACE can use debugstr_an().) That probably applies to is_string() as well. > @@ -928,6 +937,10 @@ static BOOL parse_template_option_info(parse_buffer * buf) > { > if (get_TOKEN(buf) != TOKEN_NAME) > return FALSE; > + if (strlen((char*)buf->value)+1 > sizeof(cur_template->children[cur_template->nb_children])) { > + FIXME("name %s too long for buffer\n", (char*)buf->value); > + return FALSE; > + } > strcpy(cur_template->children[cur_template->nb_children], (char*)buf->value); Once you've calculated to number of bytes you need to copy anyway, you might as well just use memcpy(). I.e., strcpy() is almost always the wrong choice, for one reason or another.

2 2

Re: [PATCH] winejoystick.drv: Revert 62876f3fc5feb1ca23d27a6de5adca580d963d0c
by Sebastian Lackner Sept. 5, 2016

Sept. 5, 2016

On 03.09.2016 22:21, Bruno Jesus wrote: > Copy & paste fail on the commit ID in previous email, sorry. > > With Aric's intensive steps into commiting HID code it is simpler to revert this patch (which caused a regression) instead of trying alterantive ways to fix it. Specially because HID will change this whole file anyway. > > Superseeds 126184. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41217 > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_linux.c | 35 ++++++++-------------------------- > 1 file changed, 8 insertions(+), 27 deletions(-) I am not sure if it makes much sense to revert your improvements, just because of the ongoing HID work. When I understand the problem correctly, the performance issues can also be fixed without in a different way. I think your previous patch was already in the right direction, my only criticm was the use of malloc/free instead of WINAPI. Regards, Sebastian

3 3

HLSL compiler
by Fabian Maurer Sept. 5, 2016

Sept. 5, 2016

I'd like to take a try at Directx10 support, firstmost hacking the HLSL compiler (namely implementing "fx_4_0"). No guarantee I'll succeed though. First, is there already someone working on this? Don't wanna duplicate the effort again. Second, since there already is an existing parser: Did you plan to simply extend it and make one parser for all HLSL versions, or to duplicate the code and have it separate for each version like the official compiler did it? I think I'd just add it to d3dcompiler_43.

3 7

Re: dsound: Avoid using the COM method implementations directly.
by Andrew Eikum Sept. 5, 2016

Sept. 5, 2016

I guess I'm not opposed to this, but are these changes useful? Andrew On Fri, Sep 02, 2016 at 10:37:33AM +0200, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/dsound/capture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 30870ae..38e3045 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -861,7 +861,7 @@ static ULONG DirectSoundCaptureDevice_Release( > LeaveCriticalSection(&DSOUND_capturers_lock); > > if (device->capture_buffer) > - IDirectSoundCaptureBufferImpl_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > + IDirectSoundCaptureBuffer8_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > > if(device->mmdevice) > IMMDevice_Release(device->mmdevice); > -- > 2.7.4 > >

3 6

Re: [PATCH 1/2] user32/tests: ValidateRect(NULL, &rect) on >= Win 8 no longer invalidates all windows.
by Marvin Sept. 5, 2016

Sept. 5, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25559 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:11043: Test failed: expected PeekMessage to return FALSE, got 1 === w864 (32 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (32 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7438: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (64 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (64 bit msg) === msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:7438: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a msg.c:13933: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

1 0

Re: [PATCH] msi: avoid potential overflow
by Hans Leidekker Sept. 5, 2016

Sept. 5, 2016

On Sat, 2016-09-03 at 22:55 +0200, Marcus Meissner wrote: > the create_test_guid function uses MAX_PATH characters > on both passed strings. While it never fully fills them, just > pass in buffers of that size. I'd prefer to fix create_test_guid instead and update callers that pass MAX_PATH buffers accordingly.

1 0

Re: [PATCH 6/6] ddraw/tests: Add D3DVIEWPORT2 transform tests.
by Marvin Sept. 3, 2016

Sept. 3, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25550 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 4/6] ddraw: Apply legacy clipspace to d3d2.
by Marvin Sept. 3, 2016

Sept. 3, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25549 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 3/6] ddraw/tests: Test d3d2 and 3 drawing with non-standard viewports.
by Marvin Sept. 3, 2016

Sept. 3, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25548 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 2/6] ddraw: Store d3d1 projection matrices in device->legacy_projection.
by Marvin Sept. 3, 2016

Sept. 3, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25547 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 1/6] ddraw/tests: Add position tests for D3DPROCESSVERTICES_TRANSFORM.
by Marvin Sept. 3, 2016

Sept. 3, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=25546 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Where is my address space?
by Snorri Sturluson Sept. 2, 2016

Sept. 2, 2016

I’m trying to understand the memory usage of Wine. My focus is to make EVE Online run on the Mac as smoothly as possible, and one of the issues I’m running into is that the game runs out of memory in heavy scenes, especially when running at high resolutions on Macs with Retina screens. On Windows, a scene with 300 ships in space may be running in 2.1GB of page file usage, but the same scene under Wine will show a Virtual Memory size of 3.5GB or more. Once the Virtual Memory size (as shown by the Activity Monitor) gets too close to the 4GB mark I start getting errors from Wine, failing to allocate memory, usually leading to a crash. There is a significant difference even when running at the same resolution on both Windows and Mac, and further pronounced if I run in the full 5k resolution of an iMac. Can anyone explain this big difference in memory use between the Windows and Wine sessions? Or give me ideas on how I can figure it out? Or better yet, have suggestions on how to reduce it? Best regards, Snorri Sturluson CCP Games

4 9

"outsb" Emulation
by Morten Welinder Sept. 2, 2016

Sept. 2, 2016

I'm sorry, it's all my fault! Let me explain. A while ago -- well, 20+ years ago -- I was reading Wine code over and discovered a number of problems big and small. I have no recollection of what they actually were, but I shipped the list off to Alexandre who took at least some of my suggestions. Including one that was wrong. And that is why we have code like http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/instr.c… That FIXME is old -- older than the bug, actually. The answer is that no, it's not correct, but it used to be. "outsb" allows segment override, even if insb does not, see http://x86.renejeschke.de/html/file_module_x86_id_223.html The wine source file has gone though a few renames since then. I tracked it back to here: http://source.winehq.org/git/wine.git/history/58371aa361c7b119a5880b2f69d84… The first bad version occurs on 960114 -- so long ago that two-digit years were still a thing. I realize that it doesn't matter in practical terms. The code is unlikely to have been run multiple times over the past 20 years. Still, it's my fault. Morten Welinder PS: Please don't take my word for it. I really don't want to return in 2036 with an update. PPS: Keep up the good work!

1 0

Re: [2/2] imm32: Set the default IME window title and styles as in native.
by Alexandre Julliard Sept. 2, 2016

Sept. 2, 2016

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 6 ++++-- > dlls/imm32/tests/imm32.c | 9 +++++++++ > 2 files changed, 13 insertions(+), 2 deletions(-) It fails here: ../../../tools/runtest -q -P wine -T ../../.. -M imm32.dll -p imm32_test.exe.so imm32 && touch imm32.ok imm32.c:888: Test failed: got make: *** [imm32.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Implementing Fiber-Local Storage Callbacks: sharing data between DLLs
by John Sheu Sept. 2, 2016

Sept. 2, 2016

TL;WR: I'd like to share a struct definition between ntdll and kernel32, passed through the PEB. Is this kosher according to Wine style/design, and if so, which header should I stick it in? -- I'd like to have fiber-local storage callbacks in Wine. http://source.winehq.org/git/wine.git/commit/556fef3d http://source.winehq.org/git/wine.git/commit/ab11a5ae http://source.winehq.org/git/wine.git/commit/4e8f43f4 So, after writing the conformance tests, it's time to implement the feature :-) I've got the feature all done, except for one issue. The proximate issue is that when NtTerminateProcess is used on Windows, FLS callbacks are not called for threads that are aborted (and those threads do not get a DLL_THREAD_DETACH notification). However, if during DLL_PROCESS_DETACH the FLS slot is then freed, then the callbacks are called on behalf of those (already-terminated) threads by the process-detaching thread. The behavior appears to be thus: if the thread is exited cleanly (through LdrShutdownThread), then the FLS callbacks are called for that thread; otherwise on an unclean exit the FLS slots for the thread are transferred to some global list, and the callbacks for that list are called when FlsFree is later called. The underlying problem regards doing that transfer to the global list. LdrShutdownThread and its other friends reside in ntdll, so ntdll will have to know how to manage FLS. The FLS API however resides in kernel32, so kernel32 will have to know, as well. For this purpose I'd like to pass a common struct between ntdll and kernel32 through PEB.FlsListHead. What I see though is that include/winternl.h contains (almost all) publicly Microsoft-documented struct definitions, and I don't see anywhere else where such common structs are presently shared between two DLLs. So is it the case that the convention in Wine is to not do such things as sharing structs, or is this also done elsewhere and I just need to find the right header for it? Thanks, -John Sheu

4 6