- wine-devel - winehq.org

Re: [PATCH 2/2] include: Add a padding WORD to ensure that wWeight is at the correct offset.
by Marvin 13 Oct '16

13 Oct '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=26151 Your paranoid android. === wxppro (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2003std (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7u (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w8 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0

2 1

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation
by Sebastian Lackner 13 Oct '16

13 Oct '16

On 12.10.2016 12:31, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > include/ddk/wdm.h | 2 ++ > 1 file changed, 2 insertions(+) > > > > 0003-include-Define-IoSkipCurrentIrpStackLocation.txt > > > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 5602f7d..5671948 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1175,9 +1175,11 @@ NTSTATUS WINAPI ObCloseHandle(IN HANDLE handle); > # ifdef NONAMELESSSTRUCT > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # else > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # endif > #else > # ifdef NONAMELESSSTRUCT > Is this definition based on a Windows header file? I have only found two versions, either with a "{ ... }" block or with a static inline function. Your definition would not work correctly in a situation like this: if (...) IoSkipCurrentIrpStackLocation(irp); Which would be expanded to: if (...) irp->Tail.Overlay.s.u2.CurrentStackLocation++; irp->CurrentLocation++; Please note that the second statement is no longer conditional. Also, what about the two other #ifdef branches directly below? Regards, Sebastian

3 5

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.
by Sebastian Lackner 12 Oct '16

12 Oct '16

On 11.10.2016 16:21, Jens Reyer wrote: > From: Michael Gilbert <mgilbert(a)debian.org> > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > libs/wine/config.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index 3b5dd68..c0b3bdd 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -68,7 +68,7 @@ static void fatal_error( const char *err, ... ) > fprintf( stderr, "wine: " ); > vfprintf( stderr, err, args ); > va_end( args ); > - exit(1); > + abort(); > } > > /* die on a fatal error */ > @@ -81,7 +81,7 @@ static void fatal_perror( const char *err, ... ) > vfprintf( stderr, err, args ); > perror( " " ); > va_end( args ); > - exit(1); > + abort(); > } > > /* malloc wrapper */ > I'm not sure if this is really a good idea. In contrast to exit, abort() might trigger the creation of a core dump. Unfortunately fatal_[p]error is also used at many places as a shortcut for "fprintf(stderr,...); exit(1)". This means after this change, a lot of users might see "Aborted (core dumped)" even for harmless error messages. Patch 2 is even more misleading, and shows such a message when the user wants to see the WINEDEBUG help: $ WINEDEBUG=help ./wine winecfg [...] Available message classes: err, warn, fixme, trace Aborted (Core dumped) Before changing things in Winelib, it would first be necessary to modify all involved tools and dlls to avoid fatal_[p]error for harmless errors. Regards, Sebastian

4 4

Compile default Visual C++ 6 project with winegcc
by A B 12 Oct '16

12 Oct '16

I'm trying to compile the default sample win32 ,Hello World project . I did winegcc -m32 -o test2 test2.cpp . It runs ok , but resources are not loaded ,there is empty windows title and missing File and Help menus. What is the correct way to make also load the resources?

3 2

Re: [PATCH 4/4] winehid: Implement handing internal ioctls
by Sebastian Lackner 12 Oct '16

12 Oct '16

On 12.10.2016 12:31, Aric Stewart wrote: > Mostly by passing them to the bus driver where platform specific actions > happen > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > > > 0004-winehid-Implement-handing-internal-ioctls.txt > > > diff --git a/dlls/winehid.sys/main.c b/dlls/winehid.sys/main.c > index e8c91bb..7c17321 100644 > --- a/dlls/winehid.sys/main.c > +++ b/dlls/winehid.sys/main.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "winbase.h" > #include "winternl.h" > +#include "winioctl.h" > #include "ddk/wdm.h" > #include "ddk/hidport.h" > #include "wine/debug.h" > @@ -33,6 +34,52 @@ WINE_DEFAULT_DEBUG_CHANNEL(hid_minidriver); > > static HID_MINIDRIVER_REGISTRATION registration; > > +static NTSTATUS WINAPI internal_ioctl(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + Some tracing wouldn't hurt here. > + irp->IoStatus.Information = 0; > + > + switch (irpsp->Parameters.DeviceIoControl.IoControlCode) > + { > + case IOCTL_GET_PHYSICAL_DESCRIPTOR: > + TRACE("IOCTL_GET_PHYSICAL_DESCRIPTOR\n"); > + break; > + case IOCTL_HID_ACTIVATE_DEVICE: > + TRACE("IOCTL_HID_ACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_DEACTIVATE_DEVICE: > + TRACE("IOCTL_HID_DEACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_GET_INDEXED_STRING: > + TRACE("IOCTL_HID_GET_INDEXED_STRING\n"); > + break; I assume there are no plans (yet) to implement those. Shouldn't they be marked as FIXME then? > + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: > + case IOCTL_HID_GET_DEVICE_DESCRIPTOR: > + case IOCTL_HID_GET_REPORT_DESCRIPTOR: > + case IOCTL_HID_GET_STRING: > + case IOCTL_HID_GET_INPUT_REPORT: > + case IOCTL_HID_READ_REPORT: > + case IOCTL_HID_SET_OUTPUT_REPORT: > + case IOCTL_HID_WRITE_REPORT: > + case IOCTL_HID_GET_FEATURE: > + case IOCTL_HID_SET_FEATURE: > + { > + /* All these are handled by the lower level driver */ > + IoSkipCurrentIrpStackLocation(irp); > + return IoCallDriver(((HID_DEVICE_EXTENSION*)device->DeviceExtension)->NextDeviceObject, irp); > + } > + default: > + { > + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n" > + , code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); > + } > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + return irp->IoStatus.u.Status; After IoCompleteRequest the IRP struct should not be accessed anymore. > +} > + > static NTSTATUS WINAPI add_device(DRIVER_OBJECT *driver, DEVICE_OBJECT *device) > { > TRACE("\n"); > @@ -44,6 +91,7 @@ NTSTATUS WINAPI DriverEntry(DRIVER_OBJECT *driver, UNICODE_STRING *path) > { > TRACE("%s\n", debugstr_w(path->Buffer)); > > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = internal_ioctl; > driver->DriverExtension->AddDevice = add_device; > > registration.DriverObject = driver; > > >

1 0

Re: ntdll/tests: Added a test of using NtCancelIoEx on iosb associated with pipe listening.
by Marvin 12 Oct '16

12 Oct '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=26128 Your paranoid android. === w864 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231

1 0

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_STRING for hidraw
by Sebastian Lackner 12 Oct '16

12 Oct '16

On 12.10.2016 12:12, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 11 +++++++ > 3 files changed, 82 insertions(+) > > > > 0001-winebus.sys-Implement-IOCTL_HID_GET_STRING-for-hidraw.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 9ab242c..9094e17 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -24,6 +24,7 @@ typedef struct > { > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > + NTSTATUS (*get_string)(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 22ea07d..4ded568 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -51,7 +51,9 @@ > #include "winnls.h" > #include "winternl.h" > #include "ddk/wdm.h" > +#include "ddk/hidtypes.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > > #include "bus.h" > > @@ -144,10 +146,78 @@ static NTSTATUS hidraw_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, > #endif > } > > +static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length) > +{ > + struct udev_device *usbdev; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + > + usbdev = udev_device_get_parent_with_subsystem_devtype(private->udev_device, "usb", "usb_device"); > + if (usbdev) > + { > + WCHAR *str = NULL; > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + str = get_sysattr_string(usbdev, "product"); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + str = get_sysattr_string(usbdev, "manufacturer"); > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + str = get_sysattr_string(usbdev, "serial"); > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > + if (str) > + { > + if (strlenW(str) >= length) > + { > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_BUFFER_TOO_SMALL; > + } > + strcpyW(buffer, str); > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_SUCCESS; > + } > + else if (length) > + buffer[0] = 0; > + return STATUS_SUCCESS; Shouldn't it still return STATUS_BUFFER_TOO_SMALL when length == 0? > + } > + else > + { > +#ifdef HAVE_LINUX_HIDRAW_H > + static char str[MAX_PATH] = {0}; Isn't there a risk of race-conditions that multiple HID devices attempt to use this static buffer at the same time? > + > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + ioctl(private->device_fd, HIDIOCGRAWNAME(MAX_PATH), &str); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > +#endif > + if (str[0]) If HAVE_LINUX_HIDRAW_H is not available this will break compilation (str undeclared). > + MultiByteToWideChar(CP_ACP, 0, str, -1, buffer, length); > + else if (length) > + buffer[0] = 0; It would be better to do length checking also in this case. > + > + return STATUS_SUCCESS; > + } > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > + hidraw_get_string, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index ad09ec1..a7b76df 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -421,6 +421,17 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = length; > break; > } > + case IOCTL_HID_GET_STRING: > + { > + DWORD index = (DWORD)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; This will trigger a compilation warning on 64-bit. You have to cast to a ptr-size integer type first, for example: DWORD index = (ULONG_PTR)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; Also, accoding to MSDN, the content of the variable is a composite value: """Parameters.DeviceIoControl.Type3InputBuffer in the I/O stack location of the IRP contains a composite value. The two most significant bytes contain the language ID of the string to be retrieved. The two least significant bytes contain one of the following three constant values...""" > + TRACE("IOCTL_HID_GET_STRING[%i]\n", index); > + irp->IoStatus.u.Status = status = ext->vtbl->get_string(device, > + index, (WCHAR*)(irp->UserBuffer), > + irpsp->Parameters.DeviceIoControl.OutputBufferLength/sizeof(WCHAR)); > + if (status == STATUS_SUCCESS) > + irp->IoStatus.Information = (strlenW((WCHAR*)(irp->UserBuffer)) + 1) * sizeof(WCHAR); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > > >

2 2

Re: [PATCH 1/2] ws2_32: Pass completion routing to NtDeviceIoControlFile in server_ioctl_sock only if caller provided comple
by Marvin 12 Oct '16

12 Oct '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=26126 Your paranoid android. === wvistau64 (32 bit sock) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9)

1 0

Re: [PATCH 1/2] Tests for CertRegisterSystemStore
by Marvin 12 Oct '16

12 Oct '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=26111 Your paranoid android. === w864 (64 bit store) === store.c:2664: Test failed: CertAddCertificateContextToStore failed store.c:2665: Test failed: Unexpected cert3 store: unhandled exception c0000005 at 000000000044B790

1 0

Re: [resend] riched20-add-support-for-EM_PASTESPECIAL
by Huw Davies 12 Oct '16

12 Oct '16

On Tue, Oct 11, 2016 at 10:54:44PM -0600, Kenneth Haley wrote: > partial fix for https://bugs.winehq.org/show_bug.cgi?id=14530 > > Support CF_TEXT & CF_UNICODETEXT clipboard formats. > > Tested on Arch Linux. > > Signed-off-by: K. Haley <haleykd(a)users.sf.net> > --- > dlls/riched20/editor.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > index 8b94ccf..7eeda2a 100644 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -2232,6 +2232,45 @@ static BOOL ME_Paste(ME_TextEditor *editor) > return TRUE; > } > > +static BOOL ME_PasteSpecial(ME_TextEditor *editor, BOOL unicode, UINT cf, REPASTESPECIAL *rps) > +{ > + DWORD dwFormat = SF_TEXT; > + EDITSTREAM es; > + ME_GlobalDestStruct gds; > + > + if (rps != NULL && rps->dwAspect != 0) { > + FIXME("REPASTESPECIAL structure handling not yet implemented\n"); > + } > + > + switch(cf) > + { > + // on XP CF_TEXT appears to paste unicode into W version of controll > + case CF_TEXT: > + case CF_UNICODETEXT: > + cf=CF_UNICODETEXT; > + if (!IsClipboardFormatAvailable(cf)) > + return FALSE; > + es.pfnCallback = ME_ReadFromHGLOBALUnicode; > + dwFormat|=SF_UNICODE; > + if (!unicode) > + FIXME("convert unicode to ANSI\n"); > + break; > + default: > + FIXME("Clipboard formats other than CF_TEXT and CF_UNICODETEXT not yet implemented!\n"); > + return FALSE; > + } > + > + if (!OpenClipboard(editor->hWnd)) > + return FALSE; > + gds.hData = GetClipboardData(cf); > + gds.nLength = 0; > + es.dwCookie = (DWORD_PTR)&gds; > + ME_StreamIn(editor, dwFormat|SFF_SELECTION, &es, FALSE); > + > + CloseClipboard(); > + return TRUE; > +} Sorry, I let this patch slip last time. Thanks for resubmitting. Unfortunately, this needs to be merged with the regular pasting code, which itself needs some work. Probably with regular paste querying for formats we want and calling an underlying 'getdata' function. Paste special would also call this function with the format specified. Additionally, all of this should use the Ole clipboard rather than the user32 api. Also note, we don't want C++ style comments in Wine. Huw.

1 0

Re: wine X button on top bar
by Ken Thomases 12 Oct '16

12 Oct '16

I'm CC'ing the list. Please keep the discussion on the list. On Oct 10, 2016, at 12:26 PM, A B <dianaxxyyzz(a)gmail.com> wrote: > > If we run the command: wine program.exe , does wine save the hwnd of the main window for the program.exe ? And how to get it ? For example if I want to printf in wine logs ,the hwnd of the main window of program.exe , is this hwnd saved somewhere in a wine variable ? The concept of "main window" of a program is purely a human interpretation. There's no such concept in the Win32 API. Therefore, there's no specific variable in Wine which holds the "main" window's handle. You can collect a +win debug log and you'll see the window handle of all of the windows created by the program (along with a lot of activity related to them). It's up to you to determine which is the main window. -Ken

3 5

Re: [PATCH v4 0/2] Don't call exit in the shared library.
by Sebastian Lackner 11 Oct '16

11 Oct '16

On 11.10.2016 16:21, Jens Reyer wrote: > This includes dropping the wrong ones pointed out by Sebastian > Lackner (Thanks a lot! Note however that it always compiled just > fine with these changes) and the rejected ones for wpp (I assume > they are not related to the shared library). Those changes were in an #ifdef block, I assume the code was just never compiled on Debian.

1 0

Re: ntoskrnl.exe: add KeAcquireInStackQueuedSpinLock stub
by Sebastian Lackner 11 Oct '16

11 Oct '16

On 11.10.2016 03:17, Austin English wrote: > For https://bugs.winehq.org/show_bug.cgi?id=41472 > In my header files it is defined as FASTCALL: --- snip --- NTKERNELAPI VOID FASTCALL KeAcquireInStackQueuedSpinLock ( _Inout_ PKSPIN_LOCK SpinLock, _Out_ PKLOCK_QUEUE_HANDLE LockHandle ); --- snip --- You will have to use the DEFINE_FASTCALL*_ENTRYPOINT macros to implement it. In the spec files it should also be marked with -norelay then. Regards, Sebastian

1 0

Re: [PATCH] d2d1: Make some of drawing calls a wrappers over DrawGeometry()
by Henri Verbeet 11 Oct '16

11 Oct '16

On 10 October 2016 at 16:29, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d2d1/render_target.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 42 insertions(+), 3 deletions(-) > This is ok, although for future reference, I'd prefer those as "Implement d2d_d3d_render_target_DrawRectangle().", etc.

1 0

Re: ntdll: give user an error message if WINEARCH is not win32/win64
by Sebastian Lackner 11 Oct '16

11 Oct '16

On 11.10.2016 03:46, Austin English wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=41378 > > See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838474 At the time WINEARCH is checked it is already too late. The wineprefix has already been created (with fallback to the native arch if something weird was passed).

1 0

Re: [PATCH resend] winex11: Send SC_KEYMENU on managed windows.
by Marvin 11 Oct '16

11 Oct '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=26094 Your paranoid android. === w7pro64 (32 bit msg) === msg.c:11036: Test failed: msg.message = 30 instead of WM_TIMER msg.c:11040: Test failed: msg.message = 30 instead of WM_TIMER msg.c:11043: Test failed: msg.message = 30 instead of WM_TIMER === w1064 (64 bit msg) === msg.c:7444: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH 1/2] shell32: add SHRemoveLocalizedName stub
by Dmitry Timoshkov 11 Oct '16

11 Oct '16

Austin English <austinenglish(a)gmail.com> wrote: > +HRESULT SHRemoveLocalizedName(const WCHAR *path) > +{ > + FIXME("%s stub\n", debugstr_w(path)); > + return S_OK; > +} Shouldn't it be WINAPI? -- Dmitry.

2 1

visual studio 6 create file read only
by A B 10 Oct '16

10 Oct '16

Hello , Visual studio 6 create files read only , but photoshop is fine (r,w) . What could be the cause?

1 2

wine X button on top bar
by A B 10 Oct '16

10 Oct '16

Hello, If "Allow windows manager to decorate window" is on. What is the function name that knows a user click this X button and send the WM_CLOSE to the app? Thank you

2 1

Re: [v2 PATCH] d2d1: Support shared bitmaps created from dxgi surface
by Henri Verbeet 10 Oct '16

10 Oct '16

On 8 October 2016 at 19:18, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > -HRESULT d2d_bitmap_create_shared(ID2D1Factory *factory, ID3D10Device *target_device, > +HRESULT d2d_bitmap_create_shared(ID2D1RenderTarget *render_target, ID3D10Device *target_device, > REFIID iid, void *data, const D2D1_BITMAP_PROPERTIES *desc, struct d2d_bitmap **bitmap) > { > + D2D1_BITMAP_PROPERTIES d; > + ID2D1Factory *factory; > + > + ID2D1RenderTarget_GetFactory(render_target, &factory); > + ID2D1Factory_Release(factory); This is a little improper. It does save a few lines, but I'd rather just release it after we're actually done with it. > + else if (IsEqualGUID(iid, &IID_IDXGISurface) || IsEqualGUID(iid, &IID_IDXGISurface1)) "else" is redundant here, although that's minor. > + { > + ID3D10ShaderResourceView *view; > + DXGI_SURFACE_DESC surface_desc; > + IDXGISurface *surface = data; > + ID3D10Resource *resource; > + D2D1_SIZE_U pixel_size; > + HRESULT hr; > + > + if (FAILED(IDXGISurface_QueryInterface(surface, &IID_ID3D10Resource, (void **)&resource))) > + { > + WARN("Failed to get d3d resource from dxgi surface.\n"); > + return E_FAIL; > + } > + > + hr = ID3D10Device_CreateShaderResourceView(target_device, resource, NULL, &view); I think we should validate the dxgi surface's device matches the target device first, like in the IID_ID2D1Bitmap case. It's in fact possible to share dxgi resources between different devices and supposedly even different processes, but doing that would require using IDXGIResource::GetSharedHandle(), ID3D10Device::OpenSharedResource(), and D3D10_RESOURCE_MISC_SHARED, all of which are currently unimplemented in Wine. I'm not sure if d2d1 allows it. > + /* Shared DXGI surface. */ > + desc.type = D2D1_RENDER_TARGET_TYPE_DEFAULT; > + desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; > + desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; > + desc.dpiX = 0.0f; > + desc.dpiY = 0.0f; > + desc.usage = D2D1_RENDER_TARGET_USAGE_NONE; > + desc.minLevel = D2D1_FEATURE_LEVEL_DEFAULT; > + > + hr = ID2D1Factory_CreateDxgiSurfaceRenderTarget(factory1, surface2, &desc, &rt2); > + ok(SUCCEEDED(hr), "Failed to create render target, hr %#x.\n", hr); > + > + bitmap_desc.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM; > + bitmap_desc.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED; > + bitmap_desc.dpiX = 0.0f; > + bitmap_desc.dpiY = 0.0f; > + > + hr = ID2D1RenderTarget_CreateSharedBitmap(rt2, &IID_IDXGISurface, surface2, &bitmap_desc, &bitmap2); > + ok(SUCCEEDED(hr) || broken(hr == E_INVALIDARG) /* vista */, "Failed to create bitmap, hr %#x.\n", hr); It's interesting that this works. I'd expect actually drawing with that bitmap on that render target to be undefined though.

2 2

Running drivers in userspace/VM
by KOLANICH 09 Oct '16

09 Oct '16

Hello everybody. ReactOS project is devoted to making an OS kernel binary compatible with NT kernel. In their official FAQ it is written that they cannot be replaced with GNU/Linux + Wine because of drivers which cannot be run in Wine. I'm a bit sceptical about their OS, so I wonder why cannot drivers be run in wine? Drivers are run in ring 0 or 1, right? Why it is impossible/too complicated to a) expose some privileged instructions into userland through API; b) expose IO space using IOPL; c) make a mock of NT kernel to allow the drivers use its ABI; d) patch the binaries automatically to use API instead of privileged instructions; e) if a driver doesn't works well enough in userland, create a micro-VM using VT-x and VT-d and put there NT kernel mock and the driver?

3 2

Re: [PATCH] d2d1: Support shared bitmaps created using dxgi surface
by Marvin 07 Oct '16

07 Oct '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=26077 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040C9E8 === w2008s64 (32 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040C9E8 === wvistau64 (64 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040C3BC === w2008s64 (64 bit d2d1) === d2d1.c:2194: Test failed: Failed to create bitmap, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040C3BC

1 0

Re: [PATCH v3 5/6] libwine: Don't call exit in the shared library.
by Sebastian Lackner 07 Oct '16

07 Oct '16

On 07.10.2016 18:39, Jens Reyer wrote: > @@ -140,18 +140,18 @@ static int try_mmap_fixed (void *addr, size_t len, int prot, int flags, > mapped and we must fail. */ > for ( i = 0; i < len; i += pagesize ) > if ( mincore( (caddr_t)addr + i, pagesize, &vec ) != -1 ) > - _exit(1); > + abort(); > > /* Perform the mapping with MAP_FIXED set. This is safe > now, as none of the pages is currently in use. */ > result = mmap( addr, len, prot, flags | MAP_FIXED, fildes, off ); > if ( result == addr ) > - _exit(0); > + break; > > if ( result != (void *) -1 ) /* This should never happen ... */ > munmap( result, len ); > > - _exit(1); > + abort(); > } > > /* reap child */ The _exit() calls are happening from a child process here, so there is nothing to change. I also doubt it will compile with the "break;" which is not even inside a loop. Regards, Sebastian

1 0

Re: [PATCH v3 1/6] libport: Don't call exit in the shared library.
by Sebastian Lackner 07 Oct '16

07 Oct '16

On 07.10.2016 18:39, Jens Reyer wrote: > From: Michael Gilbert <mgilbert(a)debian.org> > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > libs/port/spawn.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libs/port/spawn.c b/libs/port/spawn.c > index 97364e7..c1a95a2 100644 > --- a/libs/port/spawn.c > +++ b/libs/port/spawn.c > @@ -55,20 +55,20 @@ int _spawnvp(int mode, const char *cmdname, const char *const argv[]) > if (mode == _P_DETACH) > { > pid = fork(); > - if (pid == -1) _exit(1); > - else if (pid > 0) _exit(0); > + if (pid == -1) abort(); > + else if (pid > 0) return pid; The _exit() calls are happening from a child process here, so there is nothing to change. In fact, returning to the caller even breaks the code. Regards, Sebastian > /* else in grandchild */ > } > > signal( SIGPIPE, SIG_DFL ); > execvp(cmdname, (char **)argv); > - _exit(1); > + abort(); > } > > if (pid == -1) > return -1; > > - if (mode == _P_OVERLAY) exit(0); > + if (mode == _P_OVERLAY) abort(); > > if (mode == _P_WAIT || mode == _P_DETACH) > { >

1 0

Re: wined3d: Add missing '\n' to FIXME() messages.
by Henri Verbeet 07 Oct '16

07 Oct '16

On 6 October 2016 at 15:31, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > + FIXME("unknown_semantics(0x%08x).\n", semantic->usage); Could you change that to something like "Unrecognised semantic usage %#x.\n"? > + if (mmask) FIXME("_unrecognized_modifier(%#x).\n", mmask); Similarly, something like "Unrecognised modifier %#x.\n" would probably be more appropriate here.

1 0

Re: [PATCH 02/16] rpcrt4: Restore original error code when ReadFile fails with ERROR_MORE_DATA.
by Alexandre Julliard 06 Oct '16

06 Oct '16

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -448,6 +448,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, > char *buf = buffer; > BOOL ret = TRUE; > unsigned int bytes_left = count; > + DWORD err = GetLastError(); > > while (bytes_left) > { > @@ -460,6 +461,7 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection, > bytes_left -= bytes_read; > buf += bytes_read; > } > + if (ret) SetLastError(err); I'd suggest using NtReadFile instead. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_DEVICE_ATTRIBUTES for hid devices
by Sebastian Lackner 06 Oct '16

06 Oct '16

On 06.10.2016 04:51, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 1 + > dlls/winebus.sys/main.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 43 insertions(+) > > > > 0001-winebus.sys-Implement-IOCTL_HID_GET_DEVICE_ATTRIBUTES-.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 099558b..342a66b 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -34,3 +34,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 93e56f3..a01d88e 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -299,6 +299,7 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > > udev_driver_obj = driver; > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; I guess you intentionally did not name it "common_*" because non-HID devices might need a different handler, is that correct? > > if (!(events[0] = CreateEventW(NULL, TRUE, FALSE, NULL))) > goto error; > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 09a59d6..ef19322 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -30,7 +30,9 @@ > #include "winternl.h" > #include "winreg.h" > #include "setupapi.h" > +#include "winioctl.h" > #include "ddk/wdm.h" > +#include "ddk/hidport.h" > #include "wine/debug.h" > #include "wine/unicode.h" > #include "wine/list.h" > @@ -346,6 +348,45 @@ NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > return status; > } > > +NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + NTSTATUS rc = irp->IoStatus.u.Status; I would suggest to use rename the variable to "status". > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + struct device_extension *extension = (struct device_extension *)device->DeviceExtension; > + > + TRACE("(%p, %p)\n", device, irp); > + > + switch(irpsp->Parameters.DeviceIoControl.IoControlCode) There is a space missing after "switch". > + { > + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: > + { > + PHID_DEVICE_ATTRIBUTES attr = (PHID_DEVICE_ATTRIBUTES)irp->UserBuffer; It would be better to use HID_DEVICE_ATTRIBUTES * instead of the version with the "P" prefix. Also, please add a check for Parameters.DeviceIoControl.OutputBufferLength to make sure the buffer is big enough. > + TRACE("IOCTL_HID_GET_DEVICE_ATTRIBUTES\n"); > + > + RtlZeroMemory(attr, sizeof(HID_DEVICE_ATTRIBUTES)); Is there any specific reason to use RtlZeroMemory instead of memset? Something like memset(attr, 0, sizeof(*attr)) would be easier. ;) > + attr->Size = sizeof(HID_DEVICE_ATTRIBUTES); > + attr->VendorID = extension->vid; > + attr->ProductID = extension->pid; > + attr->VersionNumber = extension->version; > + irp->IoStatus.u.Status = rc = STATUS_SUCCESS; > + irp->IoStatus.Information = sizeof(HID_DEVICE_ATTRIBUTES); > + break; > + } > + default: > + { > + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); > + break; > + } > + } > + > + if (rc != STATUS_PENDING) > + IoCompleteRequest( irp, IO_NO_INCREMENT ); Do you need to handle asynchronous requests in this function? If not you can remove the if check. For consistency reasons, you should probably remove the space after "(" and before ")" in the IoCompleteRequest call. > + > + return rc; > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

2 1

Problems with WM_DROPFILES
by John Found 06 Oct '16

06 Oct '16

I just realized, that in WINE, my windows receive WM_DROPFILES only if they are top level windows. All children windows never accept WM_DROPFILES, regardless of the presence of WS_EX_ACCEPTFILES or calling DragAcceptFiles() for this child window. In Windows everything works OK and the children correctly receive WM_DROPFILES message. Is it a bug in WINE, or something OS/WM dependent? How to fix it? Is it a good idea, for example, to accept the message in the main window and dispatch it to the respective children windows (by using DragQueryPoint) - this approach should work both in WINE and Windows. WINE v1.9.19 XFCE4 window manager. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

3 7

Re: [PATCH 5/7] wined3d: Avoid destroying active contexts.
by Henri Verbeet 06 Oct '16

06 Oct '16

On 5 October 2016 at 11:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Ideally, a pointer to a swapchain would be completely removed from > struct wined3d_context. Yeah. One of the things that made me hesitate a bit about the first patch in this series is that it was originally an explicit design decision to avoid storing a pointer to the device in the context. At the time we needed the swapchain pointer, I think for the window or DC handle or something. Over time the reasons for having the swapchain pointer mostly went away, and it ended up as more of a way to get around not being able to access the device. Perhaps that's worse than what we were trying to avoid. Still, ideally the context wouldn't have a device pointer either. I think the legitimate accesses to the device are mostly either accessing shared resources like textures and samplers, or using the device to get at the wined3d creation flags. We can probably store the shared resources in some structure inside the device, and then store a pointer to that in the context instead, and probably just copy the flags.

2 3

Re: [PATCH] d2d1/tests: Initial tests for bitmap render target
by Henri Verbeet 06 Oct '16

06 Oct '16

On 5 October 2016 at 17:33, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline BOOL float_eq(FLOAT left, FLOAT right) > +{ > + int x = *(int *)&left; > + int y = *(int *)&right; > + > + if (x < 0) > + x = INT_MIN - x; > + if (y < 0) > + y = INT_MIN - y; > + > + return abs(x - y) <= 8; > +} Not wrong per se, but in the D3D tests that's generally called "compare_float()" and takes an explicit "ulps" argument. Is "8" based on test results or a guess? It seems fairly large for something that shouldn't be a particularly complicated calculation. Also, "float". > + /* Both pixel size and DIP size are specified. */ > + set_size_u(&pixel_size, 128, 128); > + hr = ID2D1HwndRenderTarget_CreateCompatibleRenderTarget(hwnd_rt, &size, &pixel_size, NULL, > + D2D1_COMPATIBLE_RENDER_TARGET_OPTIONS_NONE, &rt); > + ok(SUCCEEDED(hr), "Failed to create render target, hr %#x.\n", hr); > + > + /* Doubled pixel size dimensions with the same DIP size give doubled dpi. */ > + ID2D1BitmapRenderTarget_GetDpi(rt, dpi2, dpi2 + 1); > + ok(dpi[0] == dpi2[0] / 2.0f && dpi[1] == dpi2[1] / 2.0f, "Got dpi mismatch.\n"); As an aside, the reason some of the existing tests use different DPI settings for the x and y axes is to avoid accidentally swapping them in the implementation.

1 0

Re: [PATCH v2] winebus.sys: Implement common IRP_MJ_POWER handling
by Sebastian Lackner 05 Oct '16

05 Oct '16

On 05.10.2016 15:01, Aric Stewart wrote: > > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 1 + > dlls/winebus.sys/main.c | 21 +++++++++++++++++++++ > 3 files changed, 23 insertions(+) I have submitted a patch which initializes all MajorFunction handlers with a stub implementation [1]. This also matches Windows behavior. Please let me know if you think this patch should still be applied (I guess on Windows the bus drivers handle IRP_MJ_POWER, right?) or if we should skip it for now if it was just to fix the crash. [1] http://source.winehq.org/patches/data/126881 Regards, Sebastian

2 1

Re: [PATCH 16/16] ntdll/tests: Added a test of using NtCancelIoEx on iosb associated with pipe listening.
by Marvin 05 Oct '16

05 Oct '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=26052 Your paranoid android. === w864 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w864 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231

1 0

wine-1.8.5-rc2 Available
by Michael Stefaniuc 05 Oct '16

05 Oct '16

Hello guys, wine-1.8.5-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ The commit "user32: Prevent resetting WS_MINIMIZE through SetWindowLong." was deferred as Józef and Alexandre were not convinced about that one. bye michael

2 1

Some code ambiguity in tab control code.
by John Found 05 Oct '16

05 Oct '16

Hi. Trying without success to show tooltips for a tabcontrol, I found the following problems in the source code. Notice, that my skills in C++ are poor, so it is very possible the following is a false alarm. I am quote https://github.com/wine-mirror/wine/blob/master/dlls/comctl32/tab.c (hope it is the proper source code) This seems to be a bug: WM_LBUTTONDOWN is relayed in the WM_MOUSEMOVE handler. But WM_LBUTTONDOWN will always hide the tooltip. WM_MOUSEMOVE instead will set the timer for showing the tooltip. > static LRESULT > TAB_MouseMove (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > { > int redrawLeave; > int redrawEnter; > > if (infoPtr->hwndToolTip) > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > WM_LBUTTONDOWN, wParam, lParam); > > /* Determine which tab to highlight. Redraw tabs which change highlight > ** status. */ > TAB_RecalcHotTrack(infoPtr, &lParam, &redrawLeave, &redrawEnter); > > hottrack_refresh (infoPtr, redrawLeave); > hottrack_refresh (infoPtr, redrawEnter); > > return 0; > } The WM_LBUTTONDOWN is relayed twice? Why? It is not exactly a bug, but sub-optimal. > static LRESULT > TAB_LButtonDown (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > { > POINT pt; > INT newItem; > UINT dummy; > > if (infoPtr->hwndToolTip) > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > WM_LBUTTONDOWN, wParam, lParam); > > if (!(infoPtr->dwStyle & TCS_FOCUSNEVER)) { > SetFocus (infoPtr->hwnd); > } > > if (infoPtr->hwndToolTip) > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > WM_LBUTTONDOWN, wParam, lParam); > -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

2 3

Re: [PATCH] msvcrt: Implement __std_type_info_hash
by Piotr Caban 05 Oct '16

05 Oct '16

Hi Alexandre, On 10/04/16 22:49, GOUJON Alexandre wrote: > - MSVCRT_size_t hash = 0x811c9dc5; > + MSVCRT_size_t hash; > + MSVCRT_size_t fnvPrime; > const char *p; > > + if(sizeof(void*) == sizeof(int)) > + { > + hash = 0x811c9dc5; > + fnvPrime = 0x1000193; > + } > + else > + { > + hash = 0xcbf29ce484222325; > + fnvPrime = 0x100000001b3; > + } > + Please change name of fnvPrime variable to something like fnv_prime. Also you will need to initialize it using #ifdef, something like this should work: #ifdef _WIN64 MSVCRT_size_t hash = ... #else MSVCRT_size_t hash = ... #endif > + return hash ^ (hash >> 32); This will also cause compilation warning during 32-bit compilation. > diff --git a/dlls/ucrtbase/tests/cpp.c b/dlls/ucrtbase/tests/cpp.c > index 1a01fea..659269c 100644 > --- a/dlls/ucrtbase/tests/cpp.c > +++ b/dlls/ucrtbase/tests/cpp.c > @@ -163,7 +163,7 @@ static void test___std_type_info(void) > ti1.mangled[2] = 0; > hash1 = p___std_type_info_hash(&ti1); > #ifdef _WIN64 > - todo_wine ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); > + ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); And this. Thanks, Piotr

3 3

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.
by Henri Verbeet 05 Oct '16

05 Oct '16

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > The swapchain can be destroyed by state_unbind_resources() > if the only reference to a swapchain is kept by a shader resource view. > This happens in d3d10core and d3d11 tests when a device is destroyed > in test_swapchain_flip(). > I think it may be harder to fix than this. If state_unbind_resources() can end up destroying the (primary) swapchain, it's not safe to call context_acquire() afterwards. Which means it's unsafe to unload resources or even unload a different SRV. The reason destroying the RTVs is currently safe, is that we unloaded resources earlier, so releasing the references to the resources for those views shouldn't acquire a context to destroy e.g. the GL texture again, but that's already more fragile than I'd like. Perhaps we should just delay destroying the context until leaving the last level.

2 3

Re: [PATCH] winebus.sys: Implement common IRP_MJ_POWER handling
by Sebastian Lackner 05 Oct '16

05 Oct '16

On 05.10.2016 02:23, Aric Stewart wrote: > +NTSTATUS WINAPI common_power_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE("Device entering power state %i\n", irpsp->Parameters.Power.State.DeviceState); You are ignoring the MinorFunction parameter here. DeviceState is only valid for IRP_MN_SET_POWER, but there are also other IRP_MJ_POWER requests. For those it would be better to keep irp->IoStatus.u.Status set the original value, similar to how its done in common_pnp_dispatch. I would also suggest to add a TRACE with device and irp here (and to common_pnp_dispatch), otherwise it is difficult to interpret the meaning of the logged values. The TRACE in handle_IRP_MN_QUERY_ID could be removed then. Regards, Sebastian > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + return STATUS_SUCCESS; > +} > +

1 0

Re: [PATCH] msinfo32: Display an About dialog when the program is run.
by Hugh McMaster 04 Oct '16

04 Oct '16

On Monday, 3 October 2016 5:14 PM, Alex Henrie wrote: > msinfo32 does not take any command line arguments, so I changed > WINE_FIXME to WINE_TRACE. No. msinfo32 accepts many command line arguments. See, for example, https://support.microsoft.com/en-au/kb/300887. > +#include <shlwapi.h> > + > +#include "resource.h" > +#include "shellapi.h" > #include "wine/debug.h" resource.h should come after wine/debug.h. You might also like to put shellapi.h before shlwapi.h. > int wmain(int argc, WCHAR *argv[]) > { > + static const WCHAR wineSystemInfoW[] = > + {'W','i','n','e',' ','S','y','s','t','e','m',' ','I','n','f','o','r','m','a','t','i','o','n',0}; > + WCHAR systemInfo[64]; > int i; > > - WINE_FIXME("stub:"); > for (i = 0; i < argc; i++) > - WINE_FIXME(" %s", wine_dbgstr_w(argv[i])); > - WINE_FIXME("\n"); > + WINE_TRACE(" %s", wine_dbgstr_w(argv[i])); > + WINE_TRACE("\n"); > + > + LoadStringW(GetModuleHandleW(NULL), STRING_SYSTEM_INFO, systemInfo, sizeof(systemInfo)/sizeof(WCHAR)); > + ShellAboutW(NULL, systemInfo, wineSystemInfoW, NULL); The dialog box text should also be translatable. Add it to the string table as well. > +#include "resource.h" > + > +STRINGTABLE > +{ > + STRING_SYSTEM_INFO, "System Information" > +} > +#define STRING_SYSTEM_INFO 0x170 Why #define this as 0x170? We normally start string tables from, e.g., 100, 101, 1000 or 1001.

2 2

Re: [3/3] winebus.sys: Add implementation for device removal. (v9)
by Aric Stewart 04 Oct '16

04 Oct '16

On 10/3/16 6:29 AM, Sebastian Lackner wrote: > From: Aric Stewart <aric(a)codeweavers.com> > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Second part of 126774. Besides splitting, I've also done the following changes: > > * Rename find_hid_device -> bus_find_hid_device, for consistency with other bus_*_hid_*() functions. > * Do not append timestamp to the device names. To make the code more robust, I've modified > bus_remove_hid_device() to defer the release of the pnp_device pointer. If there are more > problems I would prefer to fix them properly, adding the timestamp seems more like a hack to me. > * Some style improvements. > > @Aric: I'm not sure if you are aware of it, but there is currently still a bug somewhere which > causes a crash during RemovalRelations when trying to remove a driver which was never added properly. > I feel like the right place to fix that is somewhere in ntoskrnl. Are you aware of this issue? > Yes, that bug is fixed by patch 126650, which has not been reviewed or committed yet. -aric > dlls/winebus.sys/bus.h | 16 +++++++-- > dlls/winebus.sys/bus_udev.c | 38 ++++++++++++++++++++-- > dlls/winebus.sys/main.c | 74 ++++++++++++++++++++++++++++++++++++++------ > 3 files changed, 111 insertions(+), 17 deletions(-) > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index dcb50f2..099558b 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -19,8 +19,18 @@ > /* Busses */ > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > > +/* Native device function table */ > +typedef struct > +{ > + int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > +} platform_vtbl; > + > +void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > + > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > - WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, WORD pid, > + DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > + const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > +void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index b1d6c3f..d798c53 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,16 @@ static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > #include "initguid.h" > DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); > > +struct platform_private > +{ > + struct udev_device *udev_device; > +}; > + > +static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > +{ > + return (struct platform_private *)get_platform_private(device); > +} > + > static DWORD get_sysattr_dword(struct udev_device *dev, const char *sysattr, int base) > { > const char *attr = udev_device_get_sysattr_value(dev, sysattr); > @@ -88,6 +98,18 @@ static WCHAR *get_sysattr_string(struct udev_device *dev, const char *sysattr) > return dst; > } > > +static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > +{ > + struct udev_device *dev1 = impl_from_DEVICE_OBJECT(device)->udev_device; > + struct udev_device *dev2 = platform_dev; > + return strcmp(udev_device_get_syspath(dev1), udev_device_get_syspath(dev2)); > +} > + > +static const platform_vtbl hidraw_vtbl = > +{ > + compare_platform_device, > +}; > + > static void try_add_device(struct udev_device *dev) > { > DWORD vid = 0, pid = 0, version = 0; > @@ -123,12 +145,15 @@ static void try_add_device(struct udev_device *dev) > subsystem = udev_device_get_subsystem(dev); > if (strcmp(subsystem, "hidraw") == 0) > { > - device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, > - version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, vid, pid, version, 0, serial, FALSE, > + &GUID_DEVCLASS_HIDRAW, &hidraw_vtbl, sizeof(struct platform_private)); > } > > if (device) > - udev_device_ref(dev); > + { > + impl_from_DEVICE_OBJECT(device)->udev_device = udev_device_ref(dev); > + IoInvalidateDeviceRelations(device, BusRelations); > + } > else > WARN("Ignoring device %s with subsystem %s\n", debugstr_a(devnode), subsystem); > > @@ -137,7 +162,12 @@ static void try_add_device(struct udev_device *dev) > > static void try_remove_device(struct udev_device *dev) > { > - /* FIXME */ > + DEVICE_OBJECT *device = bus_find_hid_device(&hidraw_vtbl, dev); > + if (!device) return; > + > + dev = impl_from_DEVICE_OBJECT(device)->udev_device; > + bus_remove_hid_device(device); > + udev_device_unref(dev); > } > > static void build_initial_deviceset(void) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 1364eab..09a59d6 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -47,13 +47,16 @@ struct pnp_device > > struct device_extension > { > - void *native; /* Must be the first member of the structure */ > + struct pnp_device *pnp_device; > > WORD vid, pid; > DWORD uid, version, index; > BOOL is_gamepad; > WCHAR *serial; > const WCHAR *busid; /* Expected to be a static constant */ > + > + const platform_vtbl *vtbl; > + BYTE platform_private[1]; > }; > > static CRITICAL_SECTION device_list_cs; > @@ -80,6 +83,12 @@ static inline WCHAR *strdupW(const WCHAR *src) > return dst; > } > > +void *get_platform_private(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > + return ext->platform_private; > +} > + > static DWORD get_vidpid_index(WORD vid, WORD pid) > { > struct pnp_device *ptr; > @@ -157,9 +166,9 @@ static WCHAR *get_compatible_ids(DEVICE_OBJECT *device) > return dst; > } > > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > - WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, WORD pid, > + DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > + const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) > { > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e','\\','%','s','#','%','p',0}; > struct device_extension *ext; > @@ -169,16 +178,18 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > WCHAR dev_name[256]; > HDEVINFO devinfo; > NTSTATUS status; > + DWORD length; > > - TRACE("(%p, %s, %p, %04x, %04x, %u, %u, %s, %u, %s)\n", driver, debugstr_w(busidW), native, > - vid, pid, version, uid, debugstr_w(serialW), is_gamepad, debugstr_guid(class)); > + TRACE("(%p, %s, %04x, %04x, %u, %u, %s, %u, %s, %p, %u)\n", driver, debugstr_w(busidW), vid, pid, > + version, uid, debugstr_w(serialW), is_gamepad, debugstr_guid(class), vtbl, platform_data_size); > > if (!(pnp_dev = HeapAlloc(GetProcessHeap(), 0, sizeof(*pnp_dev)))) > return NULL; > > - sprintfW(dev_name, device_name_fmtW, busidW, native); > + sprintfW(dev_name, device_name_fmtW, busidW, pnp_dev); > RtlInitUnicodeString(&nameW, dev_name); > - status = IoCreateDevice(driver, sizeof(*ext), &nameW, 0, 0, FALSE, &device); > + length = FIELD_OFFSET(struct device_extension, platform_private[platform_data_size]); > + status = IoCreateDevice(driver, length, &nameW, 0, 0, FALSE, &device); > if (status) > { > FIXME("failed to create device error %x\n", status); > @@ -190,7 +201,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > > /* fill out device_extension struct */ > ext = (struct device_extension *)device->DeviceExtension; > - ext->native = native; > + ext->pnp_device = pnp_dev; > ext->vid = vid; > ext->pid = pid; > ext->uid = uid; > @@ -199,6 +210,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->is_gamepad = is_gamepad; > ext->serial = strdupW(serialW); > ext->busid = busidW; > + ext->vtbl = vtbl; > > /* add to list of pnp devices */ > pnp_dev->device = device; > @@ -226,10 +238,52 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > else > ERR("failed to get ClassDevs: %x\n", GetLastError()); > > - IoInvalidateDeviceRelations(device, BusRelations); > return device; > } > > +DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) > +{ > + struct pnp_device *dev; > + DEVICE_OBJECT *ret = NULL; > + > + TRACE("(%p, %p)\n", vtbl, platform_dev); > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY(dev, &pnp_devset, struct pnp_device, entry) > + { > + struct device_extension *ext = (struct device_extension *)dev->device->DeviceExtension; > + if (ext->vtbl != vtbl) continue; > + if (ext->vtbl->compare_platform_device(dev->device, platform_dev) == 0) > + { > + ret = dev->device; > + break; > + } > + } > + LeaveCriticalSection(&device_list_cs); > + > + TRACE("returning %p\n", ret); > + return ret; > +} > + > +void bus_remove_hid_device(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > + struct pnp_device *pnp_device = ext->pnp_device; > + > + TRACE("(%p)\n", device); > + > + EnterCriticalSection(&device_list_cs); > + list_remove(&pnp_device->entry); > + LeaveCriticalSection(&device_list_cs); > + > + IoInvalidateDeviceRelations(device, RemovalRelations); > + HeapFree(GetProcessHeap(), 0, ext->serial); > + IoDeleteDevice(device); > + > + /* pnp_device must be released after the device is gone */ > + HeapFree(GetProcessHeap(), 0, pnp_device); > +} > + > static NTSTATUS handle_IRP_MN_QUERY_ID(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; >

2 2

Re: [PATCH 3/7] wined3d: Bind dummy textures to all texture image units.
by Henri Verbeet 03 Oct '16

03 Oct '16

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/wined3d/context.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Not that there's anything wrong with this, but what's the idea behind it?

2 1

Beating the Wineconf drum
by Jeremy White 03 Oct '16

03 Oct '16

Hey folks, A reminder, it's now just 6 weeks until Wineconf. We still have funding available, so write to me privately if you'd like to come, but don't have the funds. We could also use topics for conversation; you can email the wineconf mailing list, or edit the wiki page directly; either way is fine. Cheers, Jeremy p.s. And this is going to be my point of pain: https://www.winehq.org/~jwhite/latest.html

1 0

Re: [PATCH] make_unicode: Change handling of Turkish i to match Windows
by Dmitry Timoshkov 03 Oct '16

03 Oct '16

Daniel Lehman <dlehman(a)esri.com> wrote: > Windows does not lowercase the Turkish dotted i (0x130) as 'i' (0x69) > It also does not uppercase the small dotless I (0x131) to 'I' (0x49) > > Wine does the conversion for both, but Windows leaves them as-is > > the change here is to make Wine mimic Windows for the Turkish i Since you are modifying the win32 side of the unicode tables please add the correponding tests for LCMapString() to dlls/kernel32/tests/locale.c. It's quite possible that msvcrt doesn't use a win32 backend and has its own locale support. -- Dmitry.

3 4

Re: [PATCH v2] d2d1: Initial implementation of HWND render target
by Henri Verbeet 03 Oct '16

03 Oct '16

On 1 October 2016 at 18:12, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +void d2d_d3d_render_target_set_pixel_size(ID2D1RenderTarget *iface, UINT32 width, UINT32 height) > +{ > + struct d2d_d3d_render_target *render_target = impl_from_ID2D1RenderTarget(iface); > + render_target->pixel_size.width = width; > + render_target->pixel_size.height = height; > +} > + I think d2d_d3d_render_target_create_rtv() already does this.

2 1

Re: [PATCH 1/7] wined3d: Use MAX_TEXTURES instead of magic number.
by Henri Verbeet 03 Oct '16

03 Oct '16

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/ati_fragment_shader.c b/dlls/wined3d/ati_fragment_shader.c > index cd32009..7a04f76 100644 > --- a/dlls/wined3d/ati_fragment_shader.c > +++ b/dlls/wined3d/ati_fragment_shader.c > @@ -1307,7 +1307,7 @@ static void atifs_get_caps(const struct wined3d_gl_info *gl_info, struct fragmen > * The proper fix for this is not to use GL_ATI_fragment_shader on cards newer than the > * r200 series and use an ARB or GLSL shader instead > */ > - caps->MaxTextureBlendStages = 8; > + caps->MaxTextureBlendStages = MAX_TEXTURES; For what it's worth, note that ati_fragment_shader.c in particular has a couple of other places with hard 8's as well.

1 0

Re: [PATCH] d3d11: Add stub implementation for deferred context.
by Henri Verbeet 03 Oct '16

03 Oct '16

Other than some minor comments below, the patch itself is mostly ok. Unfortunately, the issue is that it's not clear that this is the right direction for implementing deferred contexts. In particular, it seems likely that we'll handle the difference between immediate and deferred contexts inside wined3d, and only have a single implementation in d3d11. Of course that's one of those things where you won't know how well it works until you try it. On 2 October 2016 at 08:39, Kimmo Myllyvirta <kimmo.myllyvirta(a)gmail.com> wrote: > -»······view.c > +»······view.c \ > +»······deferred.c It's pretty minor, but please keep these ordered. > + if (context) > + { Is it valid for context to be NULL here? The test doesn't cover it. > + *context = (ID3D11DeviceContext *)&object->ID3D11DeviceContext_iface; That cast seems unnecessary.

1 0

Re: [2/2] [v2] kernel32: Implement LCMAP_HALFWIDTH.
by Marvin 02 Oct '16

02 Oct '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=25991 Your paranoid android. === w1064 (32 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [1/2] [v2] kernel32: Implement LCMAP_FULLWIDTH.
by Marvin 02 Oct '16

02 Oct '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=25990 Your paranoid android. === w1064 (32 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [PATCH 6/6] ddraw/tests: Add D3DVIEWPORT2 transform tests.
by Marvin 01 Oct '16

01 Oct '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=25984 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 01 Oct '16

01 Oct '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=25983 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 (v2).
by Marvin 01 Oct '16

01 Oct '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=25982 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 01 Oct '16

01 Oct '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=25981 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 (v2).
by Marvin 01 Oct '16

01 Oct '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=25980 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] d2d1: Initial implementation of HWND render target
by Marvin 01 Oct '16

01 Oct '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=25973 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w2008s64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w7u (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w7pro64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w8 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w864 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w1064 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === wvistau64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w2008s64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w7pro64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w864 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w1064 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174

1 0

Re: [2/2] user32: Also release GMEM_FIXED data in free_cached_data.
by Alexandre Julliard 01 Oct '16

01 Oct '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > I assume the purpose of the check was to detect GMEM_MOVEABLE handles, in order to mimic > WinXP/Win2003 behavior for SetClipboardData. Unfortunately, the cache implemented in > GetClipboardData() also uses GMEM_FIXED, which means even sane apps will leak memory > on each cache flush. > > Tests suggest that Windows Vista+ also release GMEM_FIXED pointers passed to > SetClipboardData, so there is probably no need to keep this hack. That's probably OK, but could you please add the test case too? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v6] winebus.sys: Watch for hid raw device addition and removal
by Sebastian Lackner 01 Oct '16

01 Oct '16

On 29.09.2016 20:48, Aric Stewart wrote: > v2: Correct poll timeout > Style changes > v3: vtable style instead of a callback > v4: Suggestions from Sebastian Lackner > v5: Fixing handling of other native in the compare function > v6: Tweaks suggested by Sebastian Lackner > > Includes an implementation of a common bus_remove_hid_device > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 13 +++++- > dlls/winebus.sys/bus_udev.c | 106 +++++++++++++++++++++++++++++++++++++++++++- > dlls/winebus.sys/main.c | 64 +++++++++++++++++++++----- > 3 files changed, 169 insertions(+), 14 deletions(-) > > > > v6-0001-winebus.sys-Watch-for-hid-raw-device-addition-and-r.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index dcb50f2..719d8fd 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -19,8 +19,17 @@ > /* Busses */ > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > > +/* Native device function table */ > +typedef struct { > + int(*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > +} platform_vtbl; > + > +void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *find_hid_device(const platform_vtbl* vtbl, void *device) DECLSPEC_HIDDEN; > + > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, > WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) DECLSPEC_HIDDEN; > + const GUID *class, const platform_vtbl* vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; > +void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 1525861..b7995bc 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -26,6 +26,11 @@ > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > + > +#ifdef HAVE_SYS_POLL_H > +# include <sys/poll.h> > +#endif > + > #ifdef HAVE_LIBUDEV_H > # include <libudev.h> > #endif > @@ -55,6 +60,10 @@ static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > #include "initguid.h" > DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); > > +struct platform_private { > + struct udev_device *udev_device; > +}; > + > static DWORD get_sysattr_dword(struct udev_device *dev, const char *sysattr, int base) > { > const char *attr = udev_device_get_sysattr_value(dev, sysattr); > @@ -82,6 +91,17 @@ static WCHAR *get_sysattr_string(struct udev_device *dev, const char *sysattr) > return dst; > } > > +static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > +{ > + struct udev_device *dev1 = ((struct platform_private*)get_platform_private(device))->udev_device; There is a whitespace issue in the line above. Also, I would suggest to use a wrapper like for COM interfaces to avoid having this conversion at multiple places. For example: static inline platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) { ... } > + struct udev_device *dev2 = platform_dev; > + return (strcmp(udev_device_get_syspath(dev1), udev_device_get_syspath(dev2))); > +} > + > +static const platform_vtbl hidraw_vtbl = { > + compare_platform_device, > +}; > + > static void try_add_device(struct udev_device *dev) > { > DWORD vid = 0, pid = 0, version = 0; > @@ -117,12 +137,16 @@ static void try_add_device(struct udev_device *dev) > subsystem = udev_device_get_subsystem(dev); > if (strcmp(subsystem, "hidraw") == 0) > { > - device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, > - version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, vid, pid, > + version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW, &hidraw_vtbl, sizeof(struct platform_private)); > } > > if (device) > + { > + ((struct platform_private*)get_platform_private(device))->udev_device = dev; > udev_device_ref(dev); udev_device_ref returns the device, so you could also do the assignment and incref in one line if you prefer. ;) Not really an issue though. > + IoInvalidateDeviceRelations(device, BusRelations); > + } > else > WARN("Ignoring device %s with subsystem %s\n", debugstr_a(devnode), subsystem); > > @@ -164,6 +188,77 @@ static void build_initial_deviceset(void) > udev_enumerate_unref(enumerate); > } > > +/* This is our main even loop for reading devices */ > +static DWORD CALLBACK deviceloop_thread(void *args) > +{ > + struct pollfd plfds[1]; > + struct udev_monitor *monitor = NULL; > + > + monitor = udev_monitor_new_from_netlink(udev_context, "udev"); > + if (!monitor) > + { > + WARN("Unable to get udev monitor, device insertion and removal cannot be tracked\n"); > + goto exit; > + } > + if (udev_monitor_filter_add_match_subsystem_devtype(monitor, "hidraw", NULL) < 0) > + { > + WARN("Failed to add 'hidraw' subsystem to monitor\n"); > + goto exit; > + } > + > + if (udev_monitor_enable_receiving(monitor) < 0) > + { > + WARN("Failed to start monitoring\n"); > + goto exit; > + } > + > + plfds[0].fd = udev_monitor_get_fd(monitor); > + plfds[0].events = POLLIN; > + if (plfds[0].fd < 0) > + { > + WARN("Failed to get monitor fd\n"); > + goto exit; > + } > + /* Run the event loop */ > + while (1) > + { > + struct udev_device *dev; > + const char* action; > + > + if (poll(plfds, 1, -1) <= 0) continue; > + > + TRACE("udev reports device changes\n"); > + dev = udev_monitor_receive_device(monitor); > + if (!dev) > + { > + FIXME("Failed to get device that has changed\n"); > + continue; > + } > + action = udev_device_get_action(dev); > + if (!action) > + WARN("No action recieved\n"); > + else if (strcmp(action, "add") == 0) > + try_add_device(dev); > + else if (strcmp(action, "remove") == 0) > + { > + DEVICE_OBJECT *device = find_hid_device(&hidraw_vtbl, dev); > + if (device) > + { > + struct udev_device *original = ((struct platform_private*)get_platform_private(device))->udev_device; > + bus_remove_hid_device(device); > + udev_device_unref(original); > + } > + } > + udev_device_unref(dev); > + } > + > +exit: > + TRACE("Monitor thread exiting\n"); > + if (monitor) > + udev_monitor_unref(monitor); > + return 1; > +} > + > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > { > TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > @@ -178,6 +273,13 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > > build_initial_deviceset(); > + > + if (!CreateThread(NULL, 0, deviceloop_thread, NULL, 0, NULL)) > + { > + ERR("Unable to create udev device thread\n"); > + return STATUS_UNSUCCESSFUL; Wouldn't it make sense to proceed anyway? The initial device set could still be working properly (and, you are not cleaning up already added drivers here). > + } > + > return STATUS_SUCCESS; > } > > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 1364eab..1cb8031 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -47,13 +47,15 @@ struct pnp_device > > struct device_extension > { > - void *native; /* Must be the first member of the structure */ > - > WORD vid, pid; > DWORD uid, version, index; > BOOL is_gamepad; > WCHAR *serial; > const WCHAR *busid; /* Expected to be a static constant */ > + struct pnp_device *pnp_device; > + const platform_vtbl *vtbl; > + > + BYTE platform_private[1]; > }; > > static CRITICAL_SECTION device_list_cs; > @@ -157,11 +159,11 @@ static WCHAR *get_compatible_ids(DEVICE_OBJECT *device) > return dst; > } > > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, > WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) > + const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) > { > - static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e','\\','%','s','#','%','p',0}; > + static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e','\\','%','s','#','%','p','#','%','x',0}; > struct device_extension *ext; > struct pnp_device *pnp_dev; > DEVICE_OBJECT *device; > @@ -169,16 +171,18 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > WCHAR dev_name[256]; > HDEVINFO devinfo; > NTSTATUS status; > + DWORD length; > > - TRACE("(%p, %s, %p, %04x, %04x, %u, %u, %s, %u, %s)\n", driver, debugstr_w(busidW), native, > + TRACE("(%p, %s, %04x, %04x, %u, %u, %s, %u, %s)\n", driver, debugstr_w(busidW), > vid, pid, version, uid, debugstr_w(serialW), is_gamepad, debugstr_guid(class)); You forgot to add the vtbl and platform_data_size parameters to the TRACE. > > if (!(pnp_dev = HeapAlloc(GetProcessHeap(), 0, sizeof(*pnp_dev)))) > return NULL; > > - sprintfW(dev_name, device_name_fmtW, busidW, native); > + sprintfW(dev_name, device_name_fmtW, busidW, pnp_dev, GetTickCount()); Do you think the memory pointer (pnp_dev) alone is not sufficient? If not, it was already a problem before because "native" is also just a memory address for UDEV. > RtlInitUnicodeString(&nameW, dev_name); > - status = IoCreateDevice(driver, sizeof(*ext), &nameW, 0, 0, FALSE, &device); > + length = FIELD_OFFSET(struct device_extension, platform_private[platform_data_size]); > + status = IoCreateDevice(driver, length, &nameW, 0, 0, FALSE, &device); > if (status) > { > FIXME("failed to create device error %x\n", status); > @@ -190,7 +194,6 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > > /* fill out device_extension struct */ > ext = (struct device_extension *)device->DeviceExtension; > - ext->native = native; > ext->vid = vid; > ext->pid = pid; > ext->uid = uid; > @@ -199,6 +202,8 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->is_gamepad = is_gamepad; > ext->serial = strdupW(serialW); > ext->busid = busidW; > + ext->pnp_device = pnp_dev; > + ext->vtbl = vtbl; > > /* add to list of pnp devices */ > pnp_dev->device = device; > @@ -226,7 +231,6 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > else > ERR("failed to get ClassDevs: %x\n", GetLastError()); > > - IoInvalidateDeviceRelations(device, BusRelations); > return device; > } > > @@ -265,6 +269,46 @@ static NTSTATUS handle_IRP_MN_QUERY_ID(DEVICE_OBJECT *device, IRP *irp) > return status; > } > > +void *get_platform_private(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + return ext->platform_private; > +} > + > +DEVICE_OBJECT *find_hid_device(const platform_vtbl* vtbl, void *device) > +{ > + struct pnp_device *dev, *ptr; > + DEVICE_OBJECT *ret = NULL; > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY_SAFE(dev, ptr, &pnp_devset, struct pnp_device, entry) You do no longer need the _SAFE enumeration here because the deletion is done separately. > + { > + struct device_extension *ext = (struct device_extension*)dev->device->DeviceExtension; > + if ((vtbl == ext->vtbl) && > + (ext->vtbl->compare_platform_device(dev->device, device) == 0)) > + { > + TRACE("Found as device %p\n", dev->device); > + ret = dev->device; > + break; > + } > + } > + LeaveCriticalSection(&device_list_cs); > + return ret; > +} > + > +void bus_remove_hid_device(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + TRACE("Remove hid device %p\n", device); > + EnterCriticalSection(&device_list_cs); > + list_remove(&ext->pnp_device->entry); > + LeaveCriticalSection(&device_list_cs); > + IoInvalidateDeviceRelations(device, RemovalRelations); > + HeapFree(GetProcessHeap(), 0, ext->serial); > + HeapFree(GetProcessHeap(), 0, ext->pnp_device); > + IoDeleteDevice(device); > +} > + > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; > > >

3 2

Re: uianimation: add stub dll
by Alexandre Julliard 28 Sep '16

28 Sep '16

Austin English <austinenglish(a)gmail.com> writes: > For https://bugs.winehq.org/show_bug.cgi?id=41369 > > -- > -Austin > GPG: 14FB D7EA A041 937B > > From ddd3a6f3212f620f6f8379f295e6211f0db17129 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Thu, 22 Sep 2016 01:23:54 -0500 > Subject: [PATCH] uianimation: add stub dll That doesn't seem very useful without the corresponding registrations. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32/tests: Move test after return
by Alexandre Julliard 28 Sep '16

28 Sep '16

André Hentschel <nerv(a)dawncrow.de> writes: > diff --git a/dlls/shell32/tests/shlfolder.c b/dlls/shell32/tests/shlfolder.c > index 1591b7b..1f5dc33 100644 > --- a/dlls/shell32/tests/shlfolder.c > +++ b/dlls/shell32/tests/shlfolder.c > @@ -1588,11 +1588,11 @@ static void test_FolderShortcut(void) { > if (hr != S_OK) return; > > hr = IShellFolder_GetDisplayNameOf(pShellFolder, NULL, SHGDN_FORPARSING, &strret); > - ok(hr == S_OK, "IShellFolder_GetDisplayNameOf(NULL) failed! hr = %08x\n", hr); > if (hr != S_OK) { > IShellFolder_Release(pShellFolder); > return; > } > + ok(hr == S_OK, "IShellFolder_GetDisplayNameOf(NULL) failed! hr = %08x\n", hr); It would be better to check for the expected error instead of disabling the test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/11] kernel32: Implement LCMAP_FULLWIDTH.
by Alexandre Julliard 28 Sep '16

28 Sep '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -3246,6 +3385,24 @@ INT WINAPI LCMapStringEx(LPCWSTR name, DWORD flags, LPCWSTR src, INT srclen, LPW > goto done; > } > > + if (flags & LCMAP_FULLWIDTH) > + { > + len = min(srclen, dstlen); > + buffer = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!buffer) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return 0; > + } > + srclen = map_to_fullwidth(src, srclen, buffer, len); > + if (!srclen) > + { > + HeapFree(GetProcessHeap(), 0, buffer); > + return 0; > + } > + src = buffer; > + } It seems to me that you should be able to do this without allocating an intermediate buffer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Call glGetIntegerv() through the gl_info function pointer.
by Józef Kucia 27 Sep '16

27 Sep '16

On Tue, Sep 27, 2016 at 12:04 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Fixes a1e718ccabc7c330dd16c7face78022965b03e20. > > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > dlls/wined3d/directx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 7ab68aa..05e04e8 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -3629,7 +3629,7 @@ static BOOL wined3d_adapter_init_gl_caps(struct wined3d_adapter *adapter, DWORD > > if (gl_version >= MAKEDWORD_VERSION(3, 2)) > { > - glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &context_profile); > + gl_info->gl_ops.gl.p_glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &context_profile); > checkGLcall("Querying context profile"); > } > if (context_profile & GL_CONTEXT_CORE_PROFILE_BIT) FWIW, there are other places where GL functions aren't called through gl_ops. I've got patches to fix others.

1 0

Re: [PATCH v2 1/5] wined3d: Use round() on core profile.
by Henri Verbeet 27 Sep '16

27 Sep '16

On 27 September 2016 at 00:04, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > v2: Key the use of the round() builtin on the GLSL version used by the > shader. I'm not sure this is exactly what you had in mind but at least > this looks quite a bit nicer to me than v1. > Close enough. I think you can just use shader_glsl_get_version() and "#version %u" in the places you're currently using shader_glsl_get_version_declaration(), but it doesn't matter that much.

1 0

Re: [PATCH] wined3d: Add NVIDIA GTX 675MX to the GPU list.
by Henri Verbeet 26 Sep '16

26 Sep '16

On 24 September 2016 at 00:00, Filip Frąckiewicz <fjfrackiewicz(a)gmail.com> wrote: > - {"NVE4", CARD_NVIDIA_GEFORCE_GTX680}, /* 690 */ > + {"NVE4", CARD_NVIDIA_GEFORCE_GTX680}, /* 690 / 675MX */ It's not wrong, but I don't think this is very useful. In general what's essentially the same GPU is available under many different names and PCI IDs, and the wined3d source code isn't the best place to document those.

2 1

Re: [PATCH] wined3d: Add NVIDIA GTX 980 Ti to the GPU list.
by Henri Verbeet 26 Sep '16

26 Sep '16

On 23 September 2016 at 22:56, Filip Frąckiewicz <fjfrackiewicz(a)gmail.com> wrote: > @@ -2160,6 +2162,7 @@ cards_amd_mesa[] = > cards_nvidia_mesa[] = > { > /* Maxwell */ > + {"NV120", CARD_NVIDIA_GEFORCE_GTX980TI}, /* Titan X */ > {"NV124", CARD_NVIDIA_GEFORCE_GTX970}, > {"NV118", CARD_NVIDIA_GEFORCE_840M}, > {"NV117", CARD_NVIDIA_GEFORCE_GTX750}, Please keep these ordered where possible.

2 1

Ancient Parallel Port PIC Programmer - support under newer versions of Wine?
by Bob Wya 25 Sep '16

25 Sep '16

Can anyone help out with this user question on the WineHQ Forums? forum.winehq.org/viewtopic.php?f=8&t=27503 Since the programmer used to work - with older versions of Wine - I presume that it might still be possible to get it working? Perhaps starting with parallel port device symlinks in "${WINEPREFIX}/dosdevices" ... Any thoughts? -- Thanks, Robert

2 1

Re: [PATCH 1/5] wined3d: Use round() on core profile.
by Henri Verbeet 23 Sep '16

23 Sep '16

On 22 September 2016 at 20:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > dlls/wined3d/directx.c | 5 +++++ > dlls/wined3d/glsl_shader.c | 4 ++-- > dlls/wined3d/wined3d_gl.h | 1 + > 3 files changed, 8 insertions(+), 2 deletions(-) > This works, but I'm not sure it really scales beyond one or two instructions. It also seems to me that what you actually want to know is the GLSL version of the current shader, not entirely unlike shader_glsl_get_version().

1 0

Re: [PATCH 5/5] api-ms-win-service-winsvc-l1-1-0: add dll
by Sebastian Lackner 22 Sep '16

22 Sep '16

On 22.09.2016 19:38, Austin English wrote: > +# Generated from /home/austin/win7-SysWOW64/api-ms-win-service-winsvc-l1-1-0.dll by winedump. [...] > +C_SRCS = \ > + api-ms-win-service-winsvc-l1-1-0_main.c Are you sure this is the version you wanted to submit? And where is the main.c file?

1 0

Re: [11/11] kernel32: Implement LCMAP_HALFWIDTH.
by Marvin 22 Sep '16

22 Sep '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=25911 Your paranoid android. === w1064 (32 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [10/11] kernel32: Implement LCMAP_FULLWIDTH.
by Marvin 22 Sep '16

22 Sep '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=25910 Your paranoid android. === w1064 (32 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [09/11] kernel32: Implement LCMAP_KATAKANA.
by Marvin 22 Sep '16

22 Sep '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=25909 Your paranoid android. === w1064 (32 bit locale) === locale.c:2640: Test failed: LCMapStringEx should fail with bad locale name locale.c:2641: Test failed: unexpected error code -559038737 locale.c:2732: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4468: Test failed: IsValidLocaleName should have failed locale.c:4470: Test failed: IsValidLocaleName should have failed locale.c:4853: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4855: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2640: Test failed: LCMapStringEx should fail with bad locale name locale.c:2641: Test failed: unexpected error code -559038737 locale.c:2732: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4468: Test failed: IsValidLocaleName should have failed locale.c:4470: Test failed: IsValidLocaleName should have failed locale.c:4853: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4855: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [08/11] kernel32: Implement LCMAP_HIRAGANA.
by Marvin 22 Sep '16

22 Sep '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=25908 Your paranoid android. === w1064 (32 bit locale) === locale.c:2636: Test failed: LCMapStringEx should fail with bad locale name locale.c:2637: Test failed: unexpected error code -559038737 locale.c:2728: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4464: Test failed: IsValidLocaleName should have failed locale.c:4466: Test failed: IsValidLocaleName should have failed locale.c:4849: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4851: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2636: Test failed: LCMapStringEx should fail with bad locale name locale.c:2637: Test failed: unexpected error code -559038737 locale.c:2728: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4464: Test failed: IsValidLocaleName should have failed locale.c:4466: Test failed: IsValidLocaleName should have failed locale.c:4849: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4851: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [05/11] kernel32/tests: Add more mapping tests for LCMapString.
by Marvin 22 Sep '16

22 Sep '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=25907 Your paranoid android. === w1064 (32 bit locale) === locale.c:2632: Test failed: LCMapStringEx should fail with bad locale name locale.c:2633: Test failed: unexpected error code -559038737 locale.c:2724: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4460: Test failed: IsValidLocaleName should have failed locale.c:4462: Test failed: IsValidLocaleName should have failed locale.c:4845: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4847: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2632: Test failed: LCMapStringEx should fail with bad locale name locale.c:2633: Test failed: unexpected error code -559038737 locale.c:2724: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4460: Test failed: IsValidLocaleName should have failed locale.c:4462: Test failed: IsValidLocaleName should have failed locale.c:4845: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4847: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [04/11] kernel32/tests: Add LCMAP_TITLECASE test.
by Marvin 22 Sep '16

22 Sep '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=25906 Your paranoid android. === w1064 (32 bit locale) === locale.c:2555: Test failed: LCMapStringEx should fail with bad locale name locale.c:2556: Test failed: unexpected error code -559038737 locale.c:2647: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4383: Test failed: IsValidLocaleName should have failed locale.c:4385: Test failed: IsValidLocaleName should have failed locale.c:4768: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4770: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2555: Test failed: LCMapStringEx should fail with bad locale name locale.c:2556: Test failed: unexpected error code -559038737 locale.c:2647: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4383: Test failed: IsValidLocaleName should have failed locale.c:4385: Test failed: IsValidLocaleName should have failed locale.c:4768: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4770: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [03/11] kernel32: Zero is an invalid flag value.
by Marvin 22 Sep '16

22 Sep '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=25905 Your paranoid android. === w1064 (32 bit locale) === locale.c:2556: Test failed: LCMapStringEx should fail with bad locale name locale.c:2557: Test failed: unexpected error code -559038737 locale.c:2648: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2556: Test failed: LCMapStringEx should fail with bad locale name locale.c:2557: Test failed: unexpected error code -559038737 locale.c:2648: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [02/11] kernel32: Do not allow to combine NORM_IGNORENONSPACE and/or NORM_IGNORESYMBOLS with other LCMAP flags.
by Marvin 22 Sep '16

22 Sep '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=25904 Your paranoid android. === w1064 (32 bit locale) === locale.c:2555: Test failed: LCMapStringEx should fail with bad locale name locale.c:2556: Test failed: unexpected error code -559038737 locale.c:2647: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4383: Test failed: IsValidLocaleName should have failed locale.c:4385: Test failed: IsValidLocaleName should have failed locale.c:4768: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4770: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2555: Test failed: LCMapStringEx should fail with bad locale name locale.c:2556: Test failed: unexpected error code -559038737 locale.c:2647: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4383: Test failed: IsValidLocaleName should have failed locale.c:4385: Test failed: IsValidLocaleName should have failed locale.c:4768: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4770: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [01/11] kernel32/tests: Consolidate duplicated code for invalid LCMapString flag tests.
by Marvin 22 Sep '16

22 Sep '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=25903 Your paranoid android. === w1064 (32 bit locale) === locale.c:2535: Test failed: LCMapStringEx should fail with bad locale name locale.c:2536: Test failed: unexpected error code -559038737 locale.c:2627: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4363: Test failed: IsValidLocaleName should have failed locale.c:4365: Test failed: IsValidLocaleName should have failed locale.c:4748: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4750: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2535: Test failed: LCMapStringEx should fail with bad locale name locale.c:2536: Test failed: unexpected error code -559038737 locale.c:2627: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4363: Test failed: IsValidLocaleName should have failed locale.c:4365: Test failed: IsValidLocaleName should have failed locale.c:4748: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4750: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [PATCH v3] winebus.sys: Watch for hid raw device addition and removal
by Sebastian Lackner 21 Sep '16

21 Sep '16

On 19.09.2016 15:35, Aric Stewart wrote: > v2: Correct poll timeout > Style changes > v3: vtable style instead of a callback > > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 11 +++++- > dlls/winebus.sys/bus_udev.c | 92 ++++++++++++++++++++++++++++++++++++++++++++- > dlls/winebus.sys/main.c | 52 ++++++++++++++++++++++++- > 3 files changed, 152 insertions(+), 3 deletions(-) > Would you mind sharing some of the follow up patches, so that I can check if the vtbl solution really looks better than the previous approach? > > > v3-0004-winebus.sys-Watch-for-hid-raw-device-addition-and-r.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index dcb50f2..cf10e80 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -19,8 +19,17 @@ > /* Busses */ > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > > +/* Native device function table */ > +typedef struct { > + int(*compare_native_device)(DEVICE_OBJECT *device, DEVICE_OBJECT *other); > +} platform_vtbl; > + > +void *get_native_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *find_hid_device(const WCHAR* busidW, void *native) DECLSPEC_HIDDEN; > + > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) DECLSPEC_HIDDEN; > + const GUID *class, platform_vtbl* vtbl) DECLSPEC_HIDDEN; > +void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 1525861..35b198a 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -26,6 +26,11 @@ > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > + > +#ifdef HAVE_SYS_POLL_H > +# include <sys/poll.h> > +#endif > + > #ifdef HAVE_LIBUDEV_H > # include <libudev.h> > #endif > @@ -82,6 +87,17 @@ static WCHAR *get_sysattr_string(struct udev_device *dev, const char *sysattr) > return dst; > } > > +static int compare_native_device(DEVICE_OBJECT *device, DEVICE_OBJECT *other) > +{ > + struct udev_device *dev1 = get_native_device(device); > + struct udev_device *dev2 = get_native_device(other); > + return (strcmp(udev_device_get_syspath(dev1), udev_device_get_syspath(dev2))); > +} > + > +static platform_vtbl hidraw_vtbl = { This should be made const. > + compare_native_device, > +}; > + > static void try_add_device(struct udev_device *dev) > { > DWORD vid = 0, pid = 0, version = 0; > @@ -118,7 +134,7 @@ static void try_add_device(struct udev_device *dev) > if (strcmp(subsystem, "hidraw") == 0) > { > device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, > - version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW, &hidraw_vtbl); > } > > if (device) > @@ -164,6 +180,77 @@ static void build_initial_deviceset(void) > udev_enumerate_unref(enumerate); > } > > +/* This is our main even loop for reading devices */ > +static DWORD CALLBACK deviceloop_thread(void *args) > +{ > + struct pollfd plfds[1]; > + struct udev_monitor *monitor = NULL; > + > + monitor = udev_monitor_new_from_netlink(udev_context, "udev"); > + if (!monitor) > + { > + WARN("Unable to get udev monitor, device insertion and removal cannot be tracked\n"); > + goto exit; > + } > + if (udev_monitor_filter_add_match_subsystem_devtype(monitor, "hidraw", NULL) < 0) > + { > + WARN("Failed to add 'hidraw' subsystem to monitor\n"); > + goto exit; > + } > + > + if (udev_monitor_enable_receiving(monitor) < 0) > + { > + WARN("Failed to start monitoring\n"); > + goto exit; > + } > + > + plfds[0].fd = udev_monitor_get_fd(monitor); > + plfds[0].events = POLLIN; > + if (plfds[0].fd < 0) > + { > + WARN("Failed to get monitor fd\n"); > + goto exit; > + } > + /* Run the event loop */ > + while (1) > + { > + struct udev_device *dev; > + const char* action; > + > + if (poll(plfds, 1, -1) <= 0) continue; > + > + TRACE("udev reports device changes\n"); > + dev = udev_monitor_receive_device(monitor); > + if (!dev) > + { > + FIXME("Failed to get device that has changed\n"); > + continue; > + } > + action = udev_device_get_action(dev); > + if (!action) > + WARN("No action recieved\n"); > + else if (strcmp(action, "add") == 0) > + try_add_device(dev); > + else if (strcmp(action, "remove") == 0) > + { > + DEVICE_OBJECT *device = find_hid_device(hidraw_busidW, dev); > + if (device) > + { > + struct udev_device *original = get_native_device(device); > + bus_remove_hid_device(device); > + udev_device_unref(original); > + } > + } > + udev_device_unref(dev); > + } > + > +exit: > + TRACE("Monitor thread exiting\n"); > + if (monitor) > + udev_monitor_unref(monitor); > + return 1; > +} > + > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > { > TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > @@ -178,6 +265,9 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > > build_initial_deviceset(); > + > + CreateThread(NULL, 0, deviceloop_thread, NULL, 0, NULL); It would be better to check the result here (at least to print an ERR or something like that). > + > return STATUS_SUCCESS; > } > > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 1364eab..c7418e3 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -54,6 +54,7 @@ struct device_extension > BOOL is_gamepad; > WCHAR *serial; > const WCHAR *busid; /* Expected to be a static constant */ > + platform_vtbl *vtbl; > }; > > static CRITICAL_SECTION device_list_cs; > @@ -159,7 +160,7 @@ static WCHAR *get_compatible_ids(DEVICE_OBJECT *device) > > DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) > + const GUID *class, platform_vtbl *vtbl) > { > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e','\\','%','s','#','%','p',0}; > struct device_extension *ext; > @@ -199,6 +200,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->is_gamepad = is_gamepad; > ext->serial = strdupW(serialW); > ext->busid = busidW; > + ext->vtbl = vtbl; > > /* add to list of pnp devices */ > pnp_dev->device = device; > @@ -265,6 +267,54 @@ static NTSTATUS handle_IRP_MN_QUERY_ID(DEVICE_OBJECT *device, IRP *irp) > return status; > } > > +void *get_native_device(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + return ext->native; > +} > + > +DEVICE_OBJECT *find_hid_device(const WCHAR* busidW, void *native) > +{ > + struct pnp_device *dev, *ptr; > + DEVICE_OBJECT *ret = NULL; > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY_SAFE(dev, ptr, &pnp_devset, struct pnp_device, entry) > + { > + struct device_extension *ext = (struct device_extension*)dev->device->DeviceExtension; > + if ((strcmpW(busidW, ext->busid) == 0) && > + (ext->vtbl->compare_native_device(dev->device, native) == 0)) > + { > + TRACE("Found as device %p\n", dev->device); > + ret = dev->device; > + break; > + } > + } > + LeaveCriticalSection(&device_list_cs); > + return ret; > +} > + > +void bus_remove_hid_device(DEVICE_OBJECT *device) > +{ > + struct pnp_device *dev, *ptr; > + TRACE("Remove hid device %p\n", device); > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY_SAFE(dev, ptr, &pnp_devset, struct pnp_device, entry) > + { > + struct device_extension *ext = (struct device_extension*)dev->device->DeviceExtension; > + if (device == dev->device) > + { > + list_remove(&dev->entry); > + IoInvalidateDeviceRelations(dev->device, RemovalRelations); > + HeapFree(GetProcessHeap(), 0, ext->serial); > + IoDeleteDevice(dev->device); > + HeapFree(GetProcessHeap(), 0, dev); > + break; > + } > + } > + LeaveCriticalSection(&device_list_cs); > +} > + > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; > > >

2 1

Re: [PATCH 3/7] wined3d: Implement the initial texture data upload on top of wined3d_device_update_sub_resource().
by Michael Müller 21 Sep '16

21 Sep '16

Am 20.09.2016 um 11:41 schrieb Henri Verbeet: > - wined3d_texture_upload_data(object, i, context, &addr, data[i].row_pitch, data[i].slice_pitch); > - wined3d_texture_validate_location(object, i, WINED3D_LOCATION_TEXTURE_RGB); > - wined3d_texture_invalidate_location(object, i, ~WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_device_update_sub_resource(device, &object->resource, > + i, NULL, data[i].data, data[i].row_pitch, data[i].slice_pitch); Didn't this break the initial upload for 3d textures as wined3d_device_update_sub_resource only supports buffers and 2d textures?

2 1

Re: d3d9/tests: Allow D3D_OK for lost device present (Win10)
by Marvin 20 Sep '16

20 Sep '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=25889 Your paranoid android. === w1064 (32 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1. === w1064 (64 bit d3d9ex) === d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=0. d3d9ex.c:2828: Test failed: Got unexpected hr 0, i=1. d3d9ex.c:2830: Test failed: Got unexpected hr 0, i=1.

1 0

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.
by Matteo Bruni 20 Sep '16

20 Sep '16

2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> It was already mentioned but, at the cost of being annoying, let me reiterate: d3dx* DLLs can't directly use wined3d data types or APIs. They have to go through the respective d3d* client library functions. I suspect that code sharing between d3dx* versions will eventually happen in a somewhat different fashion and trying to build the "final solution" from the ground up is going to be hard. Porting the various pieces of code to d3d[x]11 as necessary, even at the cost of "duplication" in the short term, is probably a better plan.

2 3

Problems with the tooltip controls.
by John Found 20 Sep '16

20 Sep '16

In my program I have window with several toolbars that have to show tooltips on its buttons. As long as the tooltips are dynamical, I am handling the TTN_NEEDTEXTW following way: 1. Send message TTM_GETCURRENTTOOLW to the tooltip control in NMHDR.hwndFrom reveived. 2. Determine from which toolbar the notification comes by using TOOLINFO.hwnd returned. 3. Generate the tooltip text and set the TOOLTIPTEXTW.lpszText to point to the generated text. 4. Return This procedure works in Windows, but not in WINE. In WINE, TTM_GETCURRENTTOOLW always returns FALSE. And there is no other way to determine which of the toolbars generated this message. (or at least I don't know it). Any ideas about some workaround? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

3 6

Re: oleaut32: Handle xbuf_get erroring out in deserialize_param (and avoid uninitialized read).
by Dmitry Timoshkov 20 Sep '16

20 Sep '16

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/dlls/oleaut32/tmarshal.c > +++ b/dlls/oleaut32/tmarshal.c > @@ -1078,7 +1078,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,2); > } > if (debugout) TRACE_(olerelay)("%04x",*arg & 0xffff); > @@ -1088,7 +1091,10 @@ deserialize_param( > if (readit) { > DWORD x; > hres = xbuf_get(buf,(LPBYTE)&x,sizeof(DWORD)); > - if (hres) ERR("Failed to read integer 4 byte\n"); > + if (hres) { > + ERR("Failed to read integer 4 byte\n"); > + x = 0; > + } > memcpy(arg,&x,1); A proper fix would be to avoid a memcpy() if xbuf_get() fails instead of creating bogus input data. -- Dmitry.

1 0

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading
by Nikolay Sivov 20 Sep '16

20 Sep '16

On 13.09.2016 23:11, Fabian Maurer wrote: > +/* temporary defines to not break compilation */ > + > +#define IDirect3DSurface9_GetDesc(p,a) (p)->lpVtbl->GetDesc(p,a) > +#define IDirect3DSurface9_LockRect(p,a,b,c) (p)->lpVtbl->LockRect(p,a,b,c) > +#define IDirect3DSurface9_UnlockRect(p) (p)->lpVtbl->UnlockRect(p) > + ... > +#define INTERFACE IDirect3DSurface9 > +DECLARE_INTERFACE_(IDirect3DSurface9,IDirect3DResource9) I don't think this is acceptable. It should be done in a way that doesn't introduce mess like this.

4 5

Getting backtraces from services without crash dialog
by Austin English 20 Sep '16

20 Sep '16

Howdy all, I asked this in #winehackers, but got no reply. I have a program: http://www.cressi.com/software http://www.cressi.com/easyUp/software/CressiPcInterface_2_0_1_37_Installer.… that installs some device drivers that crash when it is starting up. If I have the crash dialog enabled, I can save their backtraces. If I disable it, all I see is something like: wine: Unhandled page fault on write access to 0x0078d000 at address 0x7bc55e7f (thread 00a1), starting debugger... Is there some way for me to get the backtraces to print to a console (either of the first wine process or of the later running programs? If the dialog is enabled, there are several crashes, which makes that inconvenient. Thanks! -- -Austin GPG: 14FB D7EA A041 937B

2 3

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects
by Matteo Bruni 20 Sep '16

20 Sep '16

2016-09-14 7:25 GMT+02:00 Bruno Jesus <00cpxxx(a)gmail.com>: > Based on idea by Elias Vanderstuyft. > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/dinput/effect_linuxinput.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Thanks for giving dinput and force feedback some love and care lately. I'm going to be a nag though... > diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c > index 9205c9c..bb45792 100644 > --- a/dlls/dinput/effect_linuxinput.c > +++ b/dlls/dinput/effect_linuxinput.c > @@ -632,7 +632,8 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( > > This->effect.u.periodic.magnitude = (tsp->dwMagnitude / 10) * 32; > This->effect.u.periodic.offset = (tsp->lOffset / 10) * 32; > - This->effect.u.periodic.phase = (tsp->dwPhase / 9) * 8; /* == (/ 36 * 32) */ > + /* phase ranges from 0 - 35999 in dinput and 0 - 65535 on linux */ > + This->effect.u.periodic.phase = (tsp->dwPhase / 36) * 65; Probably I'm missing something but... Why don't you actually use 35999 and 65535 in the expression? Relatedly, why not do the multiplication before the division instead of throwing bits of precision away? Maybe phase can go over 35999? If that's the only reason, I'd adjust the phase before doing this computation instead. I guess these points apply to the other effect parameters too. BTW, you didn't change the corresponding piece of code in GetParameters (which, for some reason, uses 33 and 36 as scaling constants...) so that's probably broken now. Or at least more broken than it was before.

2 3

Re: [PATCH 5/5] d3dx11: Implemented D3DX11CompileFromFileW
by Matteo Bruni 20 Sep '16

20 Sep '16

2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/d3dx11_43/async.c | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3dx11_43/async.c b/dlls/d3dx11_43/async.c > index 90c60fa..1e3042b 100644 > --- a/dlls/d3dx11_43/async.c > +++ b/dlls/d3dx11_43/async.c > @@ -1989,16 +1989,36 @@ HRESULT WINAPI D3DX11CompileFromFileA(const char *filename, const D3D10_SHADER_M > return E_NOTIMPL; > } > > + Stray newline. > HRESULT WINAPI D3DX11CompileFromFileW(const WCHAR *filename, const D3D10_SHADER_MACRO *defines, > ID3D10Include *include, const char *entry_point, const char *target, UINT sflags, UINT eflags, > ID3DX11ThreadPump *pump, ID3D10Blob **shader, ID3D10Blob **error_messages, HRESULT *hresult) > { > - FIXME("filename %s, defines %p, include %p, entry_point %s, target %s, sflags %#x, " > + void *file_buffer; > + HRESULT hr; > + DWORD file_size; > + LPSTR filename_converted; Please use "char *" instead. > + UINT filename_converted_len; Probably you can call it just "size". > + > + TRACE("filename %s, defines %p, include %p, entry_point %s, target %s, sflags %#x, " > "eflags %#x, pump %p, shader %p, error_messages %p, hresult %p stub.\n", The "stub" part should go away. > debugstr_w(filename), defines, include, debugstr_a(entry_point), debugstr_a(target), > sflags, eflags, pump, shader, error_messages, hresult); > > - return E_NOTIMPL; > + if (FAILED(hr = map_view_of_file(filename, &file_buffer, &file_size))) > + return hr; > + > + filename_converted_len = WideCharToMultiByte(CP_ACP, 0, filename, -1, NULL, 0, NULL, NULL); > + filename_converted = HeapAlloc(GetProcessHeap(), 0, filename_converted_len); > + WideCharToMultiByte(CP_ACP, 0, filename, -1, filename_converted, filename_converted_len, NULL, NULL); > + > + hr = D3DX11CompileFromMemory(file_buffer, file_size, filename_converted, defines, include, entry_point, target, > + sflags, eflags, pump, shader, error_messages, hresult); > + > + HeapFree(GetProcessHeap(), 0, filename_converted); > + UnmapViewOfFile(file_buffer); > + > + return hr; > } This would be okay otherwise but, as mentioned for patch [4/5], maybe it's a good idea to implement and make use of D3DX11CreateAsyncFileLoaderW() here too.

2 2

Re: [PATCH 4/5] d3dx11: Implemented D3DX11CreateShaderResourceViewFromFileW
by Nikolay Sivov 19 Sep '16

19 Sep '16

On 13.09.2016 23:11, Fabian Maurer wrote: > +HRESULT WINAPI D3DX11CreateShaderResourceViewFromFileW(ID3D11Device *iface, > + WCHAR *filename, D3DX11_IMAGE_LOAD_INFO *load_info_original, ID3DX11ThreadPump *pump, ID3D11ShaderResourceView **view, HRESULT *hresult) > +{ > + D3DX11_IMAGE_LOAD_INFO load_info; > + D3D11_SHADER_RESOURCE_VIEW_DESC desc_view; > + D3D11_TEXTURE2D_DESC desc_texture; > + D3D11_SUBRESOURCE_DATA data_texture; > + ID3D11Texture2D *texture; > + enum wined3d_format_id dst_format; > + UINT dst_pitch; > + D3DXIMAGE_INFO image_info; > + void *file_buffer = NULL; > + DWORD file_size; > + void *image_data = NULL; > + RECT rectSize; > + HRESULT hr; > + > + TRACE("iface %p, filename %s, load_info_original %p, pump %p, view %p, hresult %p.\n", > + iface, debugstr_w(filename), load_info_original, pump, view, hresult); > + > + if (pump) > + FIXME("Unimplemented ID3DX11ThreadPump handling.\n"); Personally I think this function should use D3DX11CreateAsyncFileLoaderW() and D3DX11CreateAsyncShaderResourceViewProcessor() internally, for both async and synchronous cases. This will make support for a thread pump trivial, and will consolidate things like map_view_of_file() in one place.

2 1

Re: [PATCH v2] hid: Stub HidP_TranslateUsagesToI8042ScanCodes
by Sebastian Lackner 19 Sep '16

19 Sep '16

On 15.09.2016 14:08, Aric Stewart wrote: > v2: Corrections pointed out by Sebastian Lackner > > Resolves Bug 39447 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hid/hid.spec | 2 +- > dlls/hid/hidp.c | 9 +++++++++ > include/ddk/hidpi.h | 29 +++++++++++++++++++++++++++++ > 3 files changed, 39 insertions(+), 1 deletion(-) > > > > 0003-hid-Stub-HidP_TranslateUsagesToI8042ScanCodes.txt > > > diff --git a/dlls/hid/hid.spec b/dlls/hid/hid.spec > index 4c5e505..2131af2 100644 > --- a/dlls/hid/hid.spec > +++ b/dlls/hid/hid.spec > @@ -39,6 +39,6 @@ > @ stub HidP_SetUsageValue > @ stub HidP_SetUsageValueArray > @ stub HidP_SetUsages > -@ stub HidP_TranslateUsagesToI8042ScanCodes > +@ stdcall HidP_TranslateUsagesToI8042ScanCodes(ptr long long ptr ptr ptr) > @ stub HidP_UnsetUsages > @ stub HidP_UsageListDifference > diff --git a/dlls/hid/hidp.c b/dlls/hid/hidp.c > index 3d7a12e..c7bfb72 100644 > --- a/dlls/hid/hidp.c > +++ b/dlls/hid/hidp.c > @@ -23,6 +23,7 @@ > #include <stdarg.h> > > #define NONAMELESSUNION > +#include "ntstatus.h" > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > @@ -519,3 +520,11 @@ ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePag > } > return count; > } > + > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext) It wouldn't really hurt to split this extremely long line. Also please note that VOID should usually be avoided in new Wine source, but I will leave that up to you since its your area. The same also applies to the function declaration. > +{ > + FIXME("stub: %p, %i, %i, %p, %p, %p\n", ChangedUsageList, UsageListLength, > + KeyAction, ModifierState, InsertCodesProcedure, InsertCodesContext); > + > + return STATUS_NOT_IMPLEMENTED; > +} > diff --git a/include/ddk/hidpi.h b/include/ddk/hidpi.h > index 4cfac61..833387e 100644 > --- a/include/ddk/hidpi.h > +++ b/include/ddk/hidpi.h > @@ -136,6 +136,34 @@ typedef struct _HIDP_CAPS > USHORT NumberFeatureDataIndices; > } HIDP_CAPS, *PHIDP_CAPS; > > +typedef enum _HIDP_KEYBOARD_DIRECTION { > + HidP_Keyboard_Break, > + HidP_Keyboard_Make > +} HIDP_KEYBOARD_DIRECTION; > + > +typedef struct _HIDP_KEYBOARD_MODIFIER_STATE { > + union { > + struct { > + ULONG LeftControl: 1; > + ULONG LeftShift: 1; > + ULONG LeftAlt: 1; > + ULONG LeftGUI: 1; > + ULONG RightControl: 1; > + ULONG RightShift: 1; > + ULONG RightAlt: 1; > + ULONG RigthGUI: 1; > + ULONG CapsLock: 1; > + ULONG ScollLock: 1; > + ULONG NumLock: 1; > + ULONG Reserved: 21; > + } DUMMYSTRUCTNAME; > + ULONG ul; > + } DUMMYUNIONNAME; It looks like you accidentically used three space indentation here. > +} HIDP_KEYBOARD_MODIFIER_STATE, *PHIDP_KEYBOARD_MODIFIER_STATE; > + > +typedef BOOLEAN NTAPI (*PHIDP_INSERT_SCANCODES) (VOID *Context, CHAR *NewScanCodes, ULONG Length); For GCC it does not seem to matter, but usually the NTAPI should be inside of the brackets. > + > + > NTSTATUS WINAPI HidP_GetButtonCaps(HIDP_REPORT_TYPE ReportType, PHIDP_BUTTON_CAPS ButtonCaps, PUSHORT ButtonCapsLength, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetCaps(PHIDP_PREPARSED_DATA PreparsedData, PHIDP_CAPS Capabilities); > NTSTATUS WINAPI HidP_GetUsages(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, PUSAGE UsageList, PULONG UsageLength, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > @@ -144,6 +172,7 @@ NTSTATUS WINAPI HidP_GetValueCaps(HIDP_REPORT_TYPE ReportType, PHIDP_VALUE_CAPS > NTSTATUS WINAPI HidP_InitializeReportForID(HIDP_REPORT_TYPE ReportType, UCHAR ReportID, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetScaledUsageValue(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, USAGE Usage, PLONG UsageValue, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext); > > #ifndef FACILITY_HID_ERROR_CODE > #define FACILITY_HID_ERROR_CODE 0x11 > > >

1 0

Re: [PATCH] wined3d: Add id for Broadwell Xeon E3 GPU
by Henri Verbeet 19 Sep '16

19 Sep '16

On 16 September 2016 at 15:54, Andrew Kanaber <akanaber(a)chiark.greenend.org.uk> wrote: > "Iris Pro Graphics P6300" on all the Xeon E3-1200v4 chips > (except the E3-1258L v4) This is missing a "Signed-off-by:" line, but seems fine otherwise.

1 0

wine-1.8.5-rc1 Available
by Michael Stefaniuc 17 Sep '16

17 Sep '16

Hello guys, I have pushed wine-1.8.5-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ By chance it has the same amount (66) of patches like wine-1.8.4-rc1. Nothing fancy in this release. Maybe noticeable is that I went over the fixed bugs in 1.9.[0-4] and cherry-picked some more from that era. For the release I would follow the same process: one week for feedback followed by another rc if needed with the final release 3-4 days later. And now the interesting parts from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes. ---------------------------------------------------------------- Bugs fixed in 1.8.5 (total 59): 16971 Windows Movie Maker 2.x needs ole32.dll.StgOpenPropStg 19538 Microsoft Publisher 2007 and 2010 crash when opening documents/templates (TSF manager 'ITextStoreACPSink' must support QI with 'IID_ITextStoreACPServices') 20896 Use-after-free in DdeClientTransaction in user32 dde tests 23298 Windows utility 'relog.exe' crashes on unimplemented function 'pdh.dll.PdhGetLogFileTypeW' 24645 PDF Factory 3.x/4.x installer fails to install printer drivers (winspool.SetPrinterW lacks support for level 8, global default printer settings) 31693 CAPCOM games using gamepad start with axes X/Y pressed up/left 31913 EasyPal version August 6 2012 crashes on unimplemented function msvcp60.dll.??Dstd@@YA?AV?$complex@N@0@ABNABV10@@Z 32491 dbghelp doesn't support DW_FORM_flag_present 32936 SmartMusic 2012/2014 crashes on startup (Core Audio adapter 'PKEY_DeviceInterface_FriendlyName' property not supported) 33140 Photos opened in Nikon Capture NX 2.4 have inverted red and blue channel for displaying. 33398 Word / Excel 2010: crash when clicked (2nd or 3rd times) on a link 33457 An integer overflow @line 268 of dsa.c ? 34281 PlotSoft PDFill 10 fails on startup, reports 'No Fonts found under: C:\\windows\\Fonts' (at least one font name in registry must contain 'truetype' token) 34286 dinput doesn't report DIDOI_ASPECT* for joystick axes 34504 __unDName doesn't support function pointer with type "P8" 34507 __unDName doesn't support data type "$$B" 34870 Multiple games and applications crash on unimplemented function msvcr100.dll _crt_debugger_hook (ArchiCAD 16, Far Cry 4) 35286 Borderlands (Steam) crashes on unimplemented function msvcr90.dll._crt_debugger_hook 35824 UltraISO 'ISODrive.sys' crashes in entry point (SCM doesn't start SERVICE_FILE_SYSTEM_DRIVER type services with winedevice hosting process) 35892 sdb2xml (.NET 2.0 app) crashes on unimplemented function apphelp.dll.SdbGetAppPatchDir 36625 can't set text background color in richedit 38276 IsDialogMessage(NULL,...) must always return FALSE 38310 Trackbar control (msctls_trackbar32) does not send WM_CTLCOLORSTATIC as it does in Windows 39034 SuperTux 0.3.5a crashes on startup 39074 IXMLDOMDocument::cloneNode crash 39181 "When Monster Strikes", "The Vanishing of Ethan Carter Redux" require msvcr120.dll._set_FMA3_enable 39195 msvcr120.dll.nextafter is needed by Sonkwo 39475 PhysX 9.15.0428 installer does not run ('advapi32.RegOpenCurrentUser' must return a real handle instead of 'HKEY_CURRENT_USER' for user root key) 39677 Zararadio crashes when it has to change from a playlist to another. 39744 No sound with winepulse.drv in multiple applications when PulseAudio fails to allocate full buffer 39792 Saturn PCB Design Toolkit 6.86 fails to load, reporting missing 'SHCore.dll' dependency (import descriptors with empty thunk list must be ignored) 39823 "fixme:nls:CompareStringEx semi-stub behavor for flag(s) 0x10000000" appears thousands of times in terminal when running the Lego Mindstorms EV3 software 39852 3DMark03: Mother Nature test: waterfall has no transparency if AllwaysOffScreen=disabled 39861 Windows utility 'relog.exe' crashes on unimplemented function 'pdh.dll.PdhBindInputDataSourceW' 39874 Alien Shooter crashes often with access violation 39892 UFile crashes with runtime error when rendering certain pages 39950 Cabal II can't be opened, needs msvcp100.dll.?lowest@?$numeric_limits@M@std@@SAMXZ 40034 Linksys usb wireless adapter installer needs wlanapi.dll.WlanEnumInterfaces 40035 VMware shared folders network provider fails loading in MPR 40411 Regedit.exe /e only exports HKLM 40580 TASCAM US-16x08 soundcard controller crashes 40734 Unreal Tournament 3 doesn't quit properly when Pulseaudio is used 40757 GOG Galaxy crashes with unimplemented function api-ms-win-crt-stdio-l1-1-0.dll.__stdio_common_vsnwprintf_s 40758 GOG Galaxy crashes with unimplemented function api-ms-win-crt-runtime-l1-1-0.dll._get_wide_winmain_command_line 40815 comctl32: Leftmost position of trackbar not selectable with mouse, slider initial position wrong 40882 Nvidia GT 740M is not correctly recognized 40905 Multiple applications need api-ms-win-crt-runtime-l1-1-0.dll._get_narrow_winmain_command_line (PCSX2 1.4.0, Battle.Net Launcher) 41010 TVS_TRACKSELECT uses wrong hittest region 41015 comctl32/treeview: Alt-Up/Down keyboard shortcuts don't work 41040 VariantChangeTypeEx lead to error when casting IUnknown(nil) -> IDispatch 41044 Age of Mythology: Extended Edition needs api-ms-win-crt-stdio-l1-1-0.dll.__stdio_common_vswprintf_s 41066 Unhandled page fault in RtlWow64EnableFsRedirectionEx when passed bad *old_value pointer 41079 Hauppauge Capture crashes on unimplemented function cfgmgr32.dll.CM_Get_Version 41094 comctl32/treeview: TVS_FULLROWSELECT style does not work 41103 Fails to parse Extended Properties since it has quotes around its value. 41109 8-bit Armies launches with a very small window 41111 CPU-Z driver needs hal.dll.WRITE_PORT_UCHAR 41165 MiTeC System Information X needs unimplemented function wlanapi.dll.WlanCloseHandle 41182 Don't export QT_QPA_PLATFORM ---------------------------------------------------------------- Changes since 1.8.4: Akihiro Sagawa (1): comctl32: Prevent invalid focus change notifications from LVS_OWNERDATA lists. Alex Henrie (2): ole32: Implement StgCreatePropStg. ole32: Implement StgOpenPropStg. Alistair Leslie-Hughes (1): comctl32/trackbar: Use WM_CTLCOLORSTATIC when painting background. Andrew Church (1): dinput: Report DIDOI_ASPECTPOSITION flag for axes objects. Andrew Eikum (3): winepulse.drv: Buffer data locally when needed. winepulse.drv: Don't hold PA-owned buffer between capture callbacks. mmdevapi: Fix some DEVPKEY definitions. Andrey Melnikov (1): gdi32: Handle NULL filename in GetICMProfileA(). André Hentschel (3): winspool: Implement SetPrinterW for level 8. hal: Add WRITE_PORT_UCHAR stub. msvcrt: Don't continue on demangle failure (Coverity). Austin English (6): pdh: Add PdhGetLogFileTypeA/W stubs. pdh: Add PdhBindInputDataSourceA/W stubs. kernel32: Make CompareStringEx semi-stub flag FIXME only show once. wlanapi: Add a stub for WlanEnumInterfaces. wlanapi: Add WlanCloseHandle() stub. apphelp: Add SdbGetAppPatchDir stub. Benjamin Hodgetts (1): wined3d: Add Nvidia 1XXX range to detection list. Bruno Jesus (1): dinput: Use the correct index to remap the axis. Daniel Lehman (1): ucrtbase: Add some wide functions called on startup. Jacek Caban (2): mshtml: Fixed OnStopBinding if it's called called after we aborted document binding. mshtml: Properly convert VT_NULL to string in get_elem_attr_value_by_dispid. Jeremy Audiger (1): wined3d: Add Nvidia GT 740M to the GPU list. Joerg Schiermeier (1): loader/wine.inf: Correct wrong symlink. Józef Kucia (2): user32/tests: Add more tests for setting window styles. user32: Prevent resetting WS_MINIMIZE through SetWindowLong. Kenneth Haley (1): v4 resend: Riched20: allow setting background text color. Matt Robinson (1): ntdll: Catch page fault in RtlWow64EnableFsRedirectionEx. Nikolay Sivov (21): gdi32: Keep font tables tags defined in one place. gdi32: Support special 'ttcf' tag in GetFontData(). oleaut32: Fix return value when converting from NULL interface pointers. ucrtbase: Added __stdio_common_vsnwprintf_s(). ucrtbase: Added __stdio_common_vswprintf_s(). comctl32/treeview: Handle WM_SYSKEYDOWN. comctl32/treeview: Set hot item when hovering over item, not entire row. ucrtbase: Implement _get_narrow_winmain_command_line/_get_wide_winmain_command_line. comctl32/trackbar: Update thumb on range change. comctl32/trackbar: Fix mouse position to thumb position conversion rounding. dbghelp: Recognize DW_FORM_flag_present. oledb32: Support quoted values in initialisation strings. setupapi: Added CM_Get_Version(). user32: Handle invalid dialog handles in IsDialogMessage(). gdi32: Append "TrueType" suffix to registry key names. advapi32: Make RegOpenCurrentUser() return real key handles for current SID. msxml3: Fix cloneNode() for document nodes. comctl32/treeview: Fix hot-tracking with TVS_FULLROWSELECT. comctl32/treeview: Fill full row for TVS_FULLROWSELECT style. msctf: Make ITextStoreACPSink a part of context object. msctf: Added stub ITextStoreACPServices support for context ITextStoreACPSink. Pierre Schweitzer (1): mpr: Add support for REG_EXPAND_SZ for providers path. Piotr Caban (7): msvcp100: Add numeric_limits<*>::lowest implementation. msvcp60: Export more complex numbers operators. msvcr120: Add _set_FMA3_enable stub. msvcrt: Add support for member function pointers demangling in unDName function. msvcrt: Add support for $$B datatype description format in unDName. msvcp120: Add vtordisp field to classes with virtual base. msvcrt: Add _crt_debugger_hook implementation. Sebastian Lackner (3): kernel32: Do not inherit QT_* environment variables to Windows environment. ntdll: Skip unused import descriptors when loading libraries. services: Start SERVICE_FILE_SYSTEM_DRIVER services with winedevice. Stefan Dösinger (2): d3d8: Don't validate 2D texture lock coordinates. wined3d: Rotate through swapchain buffers. Thomas Faller (1): dde: Fix use-after-free. Xiaoshan Sun (1): comctl32/dsa: Handle overflow in DSA_InsertItem(). YongHao Hu (1): msvcr120: Enable MSVCRT__nextafterf when _MSVCR_VER>=120. -- Michael Stefaniuc mstefani(a)winehq.org

2 1

Re: user32/tests: Add space for the mask data to prevent failures on Win 8 and 10.
by Marvin 16 Sep '16

16 Sep '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=25848 Your paranoid android. === w864 (32 bit cursoricon) === cursoricon.c:2625: Test failed: LoadImage() failed with 0. cursoricon.c:2625: Test failed: LoadImage() failed with 0. === w1064 (32 bit cursoricon) === cursoricon.c:2625: Test failed: LoadImage() failed with 0. cursoricon.c:2625: Test failed: LoadImage() failed with 0. === w1064 (64 bit cursoricon) === cursoricon.c:2625: Test failed: LoadImage() failed with 0. cursoricon.c:2625: Test failed: LoadImage() failed with 0.

2 1

Re: [6/6] windowscodecs: Fix 32bppGrayFloat to 8bppGray conversion.
by Dmitry Timoshkov 16 Sep '16

16 Sep '16

Hi Vincent, Vincent Povirk <madewokherd(a)gmail.com> wrote: > From: Vincent Povirk <vincent(a)codeweavers.com> > > Signed-off-by: Vincent Povirk <vincent(a)codeweavers.com> I'm not opposed that you're taking my patches from the staging tree, but in this particular case it's not really clear that the bug with converting 32bppGrayFloat to 8bppGray was debugged and found by somebody else. Adding "Spotted by ..." would be enough and appropriate, since for some reason you didn't like the version of the patch in staging and decided to fix the bug in a different way. -- Dmitry.

2 2

Re: libwine: Do not compare strings "ab-c" and a-bc" as equal.
by Marvin 16 Sep '16

16 Sep '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=25415 Your paranoid android. === w1064 (32 bit locale) === locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name locale.c:2563: Test failed: unexpected error code -559038737 locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name locale.c:2563: Test failed: unexpected error code -559038737 locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got ''

2 1

Re: [PATCH v2] mpr: Implement connected resources enumeration.
by Alexandre Julliard 15 Sep '16

15 Sep '16

Pierre Schweitzer <pierre(a)reactos.org> writes: > @@ -97,7 +99,11 @@ typedef struct _WNetEnumerator > DWORD dwScope; > DWORD dwType; > DWORD dwUsage; > - LPNETRESOURCEW lpNet; > + union > + { > + NETRESOURCEW* net; > + HANDLE* handles; > + }; Please don't use anonymous unions. > @@ -1211,6 +1240,126 @@ static DWORD _enumerateContextW(PWNetEnumerator enumerator, LPDWORD lpcCount, > return ret; > } > > +static DWORD _copyStringToEnumW(WCHAR* source, DWORD* left, void** end) > +{ > + DWORD len; > + void* local = *end; > + > + len = strlenW(source) + 1; > + len *= sizeof(WCHAR); > + if (*left < len) > + return WN_MORE_DATA; > + > + local = (PVOID)((ULONG_PTR)local - len); Please try to use proper pointer arithmetic instead of casting to integer types. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] hid: Stub HidP_TranslateUsagesToI8042ScanCodes
by Sebastian Lackner 15 Sep '16

15 Sep '16

On 14.09.2016 14:05, Aric Stewart wrote: > Resolves Bug 39447 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/hid/hid.spec | 2 +- > dlls/hid/hidp.c | 9 +++++++++ > include/ddk/hidpi.h | 29 +++++++++++++++++++++++++++++ > 3 files changed, 39 insertions(+), 1 deletion(-) > > > > 0001-hid-Stub-HidP_TranslateUsagesToI8042ScanCodes.txt > > > diff --git a/dlls/hid/hid.spec b/dlls/hid/hid.spec > index 4c5e505..2131af2 100644 > --- a/dlls/hid/hid.spec > +++ b/dlls/hid/hid.spec > @@ -39,6 +39,6 @@ > @ stub HidP_SetUsageValue > @ stub HidP_SetUsageValueArray > @ stub HidP_SetUsages > -@ stub HidP_TranslateUsagesToI8042ScanCodes > +@ stdcall HidP_TranslateUsagesToI8042ScanCodes(ptr long long ptr ptr ptr) > @ stub HidP_UnsetUsages > @ stub HidP_UsageListDifference > diff --git a/dlls/hid/hidp.c b/dlls/hid/hidp.c > index 3d7a12e..f42482a 100644 > --- a/dlls/hid/hidp.c > +++ b/dlls/hid/hidp.c > @@ -23,6 +23,7 @@ > #include <stdarg.h> > > #define NONAMELESSUNION > +#include "ntstatus.h" > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > @@ -519,3 +520,11 @@ ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePag > } > return count; > } > + > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext) > +{ > + ERR("stub: %p %i %i %p, %p, %p\n", ChangedUsageList, UsageListLength, > + KeyAction, ModifierState, InsertCodesProcedure, InsertCodesContext); Shouldn't this be a FIXME? And why are there only commas between the last three arguments? > + > + return STATUS_NOT_IMPLEMENTED; > +} > diff --git a/include/ddk/hidpi.h b/include/ddk/hidpi.h > index 4cfac61..853cbac 100644 > --- a/include/ddk/hidpi.h > +++ b/include/ddk/hidpi.h > @@ -136,6 +136,34 @@ typedef struct _HIDP_CAPS > USHORT NumberFeatureDataIndices; > } HIDP_CAPS, *PHIDP_CAPS; > > +typedef enum _HIDP_KEYBOARD_DIRECTION { > + HidP_Keyboard_Break, > + HidP_Keyboard_Make > +} HIDP_KEYBOARD_DIRECTION; > + > +typedef struct _HIDP_KEYBOARD_MODIFIER_STATE { > + union { > + struct { > + ULONG LeftControl: 1; > + ULONG LeftShift: 1; > + ULONG LeftAlt: 1; > + ULONG LeftGUI: 1; > + ULONG RightControl: 1; > + ULONG RightShift: 1; > + ULONG RightAlt: 1; > + ULONG RigthGUI: 1; > + ULONG CapsLock: 1; > + ULONG ScollLock: 1; > + ULONG NumLock: 1; > + ULONG Reserved: 21; > + } DUMMYSTRUCTNAME; > + ULONG ul; > + } DUMMYUNIONNAME; > +} HIDP_KEYBOARD_MODIFIER_STATE, *PHIDP_KEYBOARD_MODIFIER_STATE; > + > +typedef BOOLEAN (*PHIDP_INSERT_SCANCODES) (VOID *Context, CHAR *NewScanCodes, ULONG Length); Are you sure that this isn't a STDCALL callback? > + > + > NTSTATUS WINAPI HidP_GetButtonCaps(HIDP_REPORT_TYPE ReportType, PHIDP_BUTTON_CAPS ButtonCaps, PUSHORT ButtonCapsLength, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetCaps(PHIDP_PREPARSED_DATA PreparsedData, PHIDP_CAPS Capabilities); > NTSTATUS WINAPI HidP_GetUsages(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, PUSAGE UsageList, PULONG UsageLength, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > @@ -144,6 +172,7 @@ NTSTATUS WINAPI HidP_GetValueCaps(HIDP_REPORT_TYPE ReportType, PHIDP_VALUE_CAPS > NTSTATUS WINAPI HidP_InitializeReportForID(HIDP_REPORT_TYPE ReportType, UCHAR ReportID, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > ULONG WINAPI HidP_MaxUsageListLength(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, PHIDP_PREPARSED_DATA PreparsedData); > NTSTATUS WINAPI HidP_GetScaledUsageValue(HIDP_REPORT_TYPE ReportType, USAGE UsagePage, USHORT LinkCollection, USAGE Usage, PLONG UsageValue, PHIDP_PREPARSED_DATA PreparsedData, PCHAR Report, ULONG ReportLength); > +NTSTATUS WINAPI HidP_TranslateUsagesToI8042ScanCodes(USAGE *ChangedUsageList, ULONG UsageListLength, HIDP_KEYBOARD_DIRECTION KeyAction, HIDP_KEYBOARD_MODIFIER_STATE *ModifierState, PHIDP_INSERT_SCANCODES InsertCodesProcedure, VOID *InsertCodesContext); > > #ifndef FACILITY_HID_ERROR_CODE > #define FACILITY_HID_ERROR_CODE 0x11 > > >

1 0

Re: [PATCH v4] ntoskrnl.exe: Send PnP and Power IRPs to plug and play devices
by Sebastian Lackner 15 Sep '16

15 Sep '16

On 14.09.2016 20:58, Aric Stewart wrote: > v2: use same helper function as get_device_id > Suggestions from Sebastian Lackner > v3: shift code to ntoskrnl.c > v4: Suggestions from Sebastian Lackner > > The drivers AddDevice function will be well behaved and call > IoAttachDeviceToDeviceStack. The Plug and Play manager will then > proceed to call IRP_MN_START_DEVICE on the top device of the device > stack. Then a IRP_MJ_POWER/IRP_MN_SET_POWER to PowerDeviceD0. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > > > > v4-0001-ntoskrnl.exe-Send-PnP-and-Power-IRPs-to-plug-and-pl.txt > > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index aebb3de..6c4c984 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -2927,6 +2927,42 @@ static BOOL get_driver_for_id( const WCHAR *id, WCHAR *driver ) > } > > > +static NTSTATUS send_pnp_irp( DEVICE_OBJECT *device, UCHAR minor ) > +{ > + IO_STACK_LOCATION *irpsp; > + IO_STATUS_BLOCK irp_status; Did you forget to declare irp here and in the function below? > + > + if (!(irp = IoBuildSynchronousFsdRequest( IRP_MJ_PNP, device, NULL, 0, NULL, NULL, &irp_status ))) > + return STATUS_NO_MEMORY; > + > + irpsp = IoGetNextIrpStackLocation( irp ); > + irpsp->MinorFunction = minor; > + > + irpsp->Parameters.StartDevice.AllocatedResources = NULL; > + irpsp->Parameters.StartDevice.AllocatedResourcesTranslated = NULL; > + > + return send_device_irp( device, irp, NULL ); > +} > + > + > +static NTSTATUS send_power_irp( DEVICE_OBJECT *device, DEVICE_POWER_STATE power ) > +{ > + IO_STATUS_BLOCK irp_status; > + IO_STACK_LOCATION *irpsp; > + > + if (!(irp = IoBuildSynchronousFsdRequest( IRP_MJ_POWER, device, NULL, 0, NULL, NULL, &irp_status ))) > + return STATUS_NO_MEMORY; > + > + irpsp = IoGetNextIrpStackLocation( irp ); > + irpsp->MinorFunction = IRP_MN_SET_POWER; > + > + irpsp->Parameters.Power.Type = DevicePowerState; > + irpsp->Parameters.Power.State.DeviceState = power; > + > + return send_device_irp( device, irp, NULL ); > +} > + > + > static void handle_bus_relations( DEVICE_OBJECT *device ) > { > static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > @@ -2990,7 +3026,13 @@ static void handle_bus_relations( DEVICE_OBJECT *device ) > ObDereferenceObject( driver_obj ); > > if (status != STATUS_SUCCESS) > + { > ERR_(plugplay)( "AddDevice failed for driver %s\n", debugstr_w(driver) ); > + return; > + } > + > + send_pnp_irp( device, IRP_MN_START_DEVICE ); > + send_power_irp( device, PowerDeviceD0 ); > } > > > > >

1 0

Re: [PATCH v2] ntoskrnl.exe: Implement DevicePropertyEnumeratorName for IoGetDeviceProperty
by Sebastian Lackner 15 Sep '16

15 Sep '16

On 14.09.2016 18:06, Aric Stewart wrote: > v2: Cleanup and resend > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > > > v2-0001-ntoskrnl.exe-Implement-DevicePropertyEnumeratorName.txt > > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index aebb3de..d1b0ee9 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -94,6 +94,8 @@ struct wine_driver > DRIVER_EXTENSION driver_extension; > }; > > +static NTSTATUS get_device_id( DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCHAR **id ); > + > static int wine_drivers_rb_compare( const void *key, const struct wine_rb_entry *entry ) > { > const struct wine_driver *driver = WINE_RB_ENTRY_VALUE( entry, const struct wine_driver, entry ); > @@ -1132,6 +1134,34 @@ NTSTATUS WINAPI IoGetDeviceProperty( DEVICE_OBJECT *device, DEVICE_REGISTRY_PROP > property_buffer, result_length ); > switch (device_property) > { > + case DevicePropertyEnumeratorName: > + { > + DWORD len; > + WCHAR *id, *ptr; > + status = get_device_id( device, BusQueryInstanceID, &id ); > + if (status != STATUS_SUCCESS) > + { > + ERR( "Failed to get device id\n" ); > + break; > + } > + struprW( id ); > + TRACE( "Device ID %s\n",debugstr_w( id ) ); I am not sure if the TRACE is very useful here. Its not the value returned by get_device_id() and not the result returned by this function. Does it really make sense to dump this intermediate value here? > + ptr = strchrW( id, '\\' ); > + if (ptr) > + len = (ptr - id); It would be easier to replace the '\\' with a null character, and then always use strlenW() to get the length. This also allows to simplify the code below. > + else > + len = strlenW( id ); > + *result_length = sizeof( WCHAR ) * (len + 1); > + if (buffer_length < *result_length) > + { > + status = STATUS_BUFFER_TOO_SMALL; You are leaking the id buffer here and in the return path below. > + break; > + } > + > + lstrcpynW( property_buffer, id, len + 1 ); > + ((WCHAR*)property_buffer)[len] = 0; When the string is properly null terminated you could just use memcpy() here and copy *result_length bytes. > + break; > + } > case DevicePropertyPhysicalDeviceObjectName: > { > ULONG used_len, len = buffer_length + sizeof(OBJECT_NAME_INFORMATION); > > >

1 0

Re: [1/4] gdiplus: Add FIXME for EMF records we need to implement.
by Vincent Povirk 14 Sep '16

14 Sep '16

Please don't commit this for now. I did some testing today that suggests GdipPlayMetafileRecord is the wrong place to handle this.

1 0

Re: ucrtbase: Add __std_type_info_hash implementation
by Huw Davies 14 Sep '16

14 Sep '16

Hi Piotr, On Wed, Sep 14, 2016 at 03:23:04PM +0200, Piotr Caban wrote: > +/****************************************************************** > + * __std_type_info_hash (UCRTBASE.@) > + * > + * TODO: 64-bit version of the function uses different constatns typo: 'constatns'. Huw.

1 0

Re: winmm/tests: Remove a test that can crash on Win 8 and 10.
by Marvin 14 Sep '16

14 Sep '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=25794 Your paranoid android. === w8 (32 bit mci) === mci.c:1117: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w864 (32 bit mci) === mci.c:1117: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w1064 (32 bit mci) === mci.c:1117: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w864 (64 bit mci) === mci.c:1117: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w1064 (64 bit mci) === mci.c:1117: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close)

2 1

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d
by Henri Verbeet 13 Sep '16

13 Sep '16

On 10 September 2016 at 00:18, Fabian Maurer <dark.shadow4(a)web.de> wrote: > This change is a measure of code-deduplication and to make these functions reusable in other parts. > I'm not sure how valuable that really is, but wined3d shouldn't depend on dxgi or its headers. I may be open to having these as inline helpers somewhere under include/wine/, but right now the two copies of this don't strike me as a big problem.

4 9

Re: [PATCH v8] winebus.sys: Build initial hidraw device set
by Sebastian Lackner 13 Sep '16

13 Sep '16

On 12.09.2016 16:01, Aric Stewart wrote: > v2: style changes > v4: changes required by previous updates > v6: removed disableing busses > v7: Rebased, suggestions from Sebastian Lackner > v8: More suggestions from Sebastian Lackner Because of the size of the patch I've decided to split it. I've already sent an improved version of the first part including my signoff. An improved version of the second part is already in my stash, but first I would like to discuss a few remaining things. > > Includes implementation of common HID_PNP_CreateDevice > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/Makefile.in | 4 +- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 135 ++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 144 +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 283 insertions(+), 1 deletion(-) > > > > v8-0001-winebus.sys-Build-initial-hidraw-device-set.txt > > > diff --git a/dlls/winebus.sys/Makefile.in b/dlls/winebus.sys/Makefile.in > index 99ff4d2..9d3a0c2 100644 > --- a/dlls/winebus.sys/Makefile.in > +++ b/dlls/winebus.sys/Makefile.in > @@ -1,5 +1,7 @@ > MODULE = winebus.sys > -IMPORTS = ntoskrnl > +IMPORTS = ntoskrnl setupapi > +EXTRALIBS = $(UDEV_LIBS) > +EXTRAINCL = $(UDEV_CFLAGS) > EXTRADLLFLAGS = -Wb,--subsystem,native > > C_SRCS = \ > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 3d53a46..47d146e 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -21,3 +21,4 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, LPVOID native, WORD vid, WORD pid, DWORD version, DWORD uid, const WCHAR *serial, BOOL is_gamepad, const GUID *class) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index f040e60..792422c 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -20,6 +20,19 @@ > > #include "config.h" > #include <stdarg.h> > +#include <unistd.h> > +#include <fcntl.h> > +#include <stdlib.h> > + > +#ifdef HAVE_SYS_IOCTL_H > +# include <sys/ioctl.h> > +#endif > + > +#ifdef HAVE_LIBUDEV_H > +# include <libudev.h> > +#endif > + > +#include <errno.h> > > #define NONAMELESSUNION > > @@ -27,6 +40,7 @@ > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > +#include "winnls.h" > #include "winternl.h" > #include "ddk/wdm.h" > #include "wine/debug.h" > @@ -39,6 +53,116 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > static DRIVER_OBJECT *udev_driver_obj = NULL; > > +#include "initguid.h" > +DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); I haven't found this definition in header files, so I assume this is Wine specific, right? Does Windows have an equivalent which we could use here? > + > +static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > + > +/* udev based PNP support */ > +static struct udev *udev = NULL; > + > +static int try_add_device(struct udev_device *dev) > +{ > + const char *devnode; > + int fd; > + DWORD vid=0, pid=0, uid=0, version=0; > + WCHAR serial[255] = {'0','0','0','0','0',0}; Here you use a default serial with 5 digits "0", but in bus_create_hid_device() only 4 digits. Which of both makes more sense? > + DEVICE_OBJECT *device = NULL; > + struct udev_device *usbdev; > + const char *subsystem; > + > + devnode = udev_device_get_devnode(dev); > + if (!devnode || ((fd = open(devnode, O_RDWR)) == -1)) > + { > + WARN("Unable to open udev device %s\n", debugstr_a(devnode)); > + return 0; > + } > + close(fd); > + > + TRACE("Got udev device %s\n", debugstr_a(devnode)); > + > + usbdev = udev_device_get_parent_with_subsystem_devtype(dev, "usb", > + "usb_device"); > + if (usbdev) > + { > + char *endptr; > + const char *attr; > + attr = udev_device_get_sysattr_value(usbdev, "idVendor"); > + if (attr) > + vid = strtol(attr, &endptr, 16); > + else > + WARN("Could not get idVendor from usb device\n"); > + attr = udev_device_get_sysattr_value(usbdev, "idProduct"); > + if (attr) > + pid = strtol(attr, &endptr, 16); > + else > + WARN("Could not get idProduct from usb device\n"); > + attr = udev_device_get_sysattr_value(usbdev, "version"); > + if (attr) > + version = strtol(attr, &endptr, 10); > + else > + WARN("Could not get version from usb device\n"); > + attr = udev_device_get_sysattr_value(usbdev, "serial"); > + if (attr) > + MultiByteToWideChar(CP_UNIXCP, 0, attr, -1, serial, 255); > + } > + else > + WARN("Could not get underlying usb device to query VID, PID, Version and Serial\n"); > + > + subsystem = udev_device_get_subsystem(dev); > + > + if (strcmp(subsystem, "hidraw") == 0) > + device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, version, uid, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + else > + { > + ERR("Device has unknown subsystem %s\n", subsystem); > + return 0; > + } > + > + if (!device) > + { > + ERR("Failed to create device\n"); > + return 0; > + } > + > + return 1; > +} > + > +static void build_initial_deviceset( void ) > +{ > + struct udev_enumerate *enumerate; > + struct udev_list_entry *udevices, *dev_list_entry; > + > + enumerate = udev_enumerate_new(udev); > + if (!enumerate) > + { > + WARN("Unable to start UDEV enumeration\n"); > + return; > + } > + > + if (udev_enumerate_add_match_subsystem(enumerate, "hidraw") != 0) > + WARN("Failed to add subsystem 'hidraw' to enumeration\n"); > + > + if (udev_enumerate_scan_devices(enumerate) != 0) > + WARN("Enumeration scan failed\n"); > + > + udevices = udev_enumerate_get_list_entry(enumerate); > + > + udev_list_entry_foreach(dev_list_entry, udevices) { > + const char *path; > + struct udev_device *dev; > + > + path = udev_list_entry_get_name(dev_list_entry); > + dev = udev_device_new_from_syspath(udev, path); > + if (!dev) > + WARN("Unable to create device %s\n", debugstr_a(path)); > + else if (!try_add_device(dev)) > + udev_device_unref(dev); > + } > + > + udev_enumerate_unref(enumerate); > +} > + > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > { > TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > @@ -46,6 +170,17 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > udev_driver_obj = driver; > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > > + udev = udev_new(); > + > + if (!udev) > + { > + ERR("Can't create udev\n"); > + return STATUS_UNSUCCESSFUL; > + } > + > + /* PNP Bus initialization */ > + build_initial_deviceset(); > + > return STATUS_SUCCESS; > } > > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 43de25a..f06d5c3 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -18,6 +18,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#include "config.h" > #include <stdarg.h> > > #define NONAMELESSUNION > @@ -26,14 +27,157 @@ > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > +#include "winuser.h" > #include "winternl.h" > +#include "winreg.h" > +#include "setupapi.h" > +#include "cfgmgr32.h" > #include "ddk/wdm.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > +#include "wine/list.h" > > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > +static const WCHAR hwidfmtW[] = {'%','s','\\','V','i','d','_','%','0','4','x','&','P','i','d','_','%','0','4','x','&','%','s','\\','%','i','&','%','s','&','%','x',0}; > +static const WCHAR im_fmtW[] = {'I','M','_','%','i',0}; > +static const WCHAR ig_fmtW[] = {'I','G','_','%','i',0}; > + > +typedef struct _pnp_device { > + struct list entry; > + > + DEVICE_OBJECT *device; > +} pnp_device; > + > +typedef struct { > + void *native; /* Must be the first member of the structure */ So far I do not see any code which depends on the fact that native is the first struct member. Is this comment still valid? If you plan to add code which depends on this in following patches, I would suggest to evaluate if there isn't a better solution (like moving the structs to the header file for example). > + > + DWORD vid, pid, version, uid, index; > + BOOL is_gamepad; > + WCHAR serial[255]; > + WCHAR const *busidW; /* Expected to be a static constant */ > +} extension; > + > +static CRITICAL_SECTION device_list_cs; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &device_list_cs, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": device_list_cs") } > +}; > +static CRITICAL_SECTION device_list_cs = { &critsect_debug, -1, 0, 0, 0, 0 }; > + > +static struct list pnp_devset = LIST_INIT(pnp_devset); > + > +static void add_device(DEVICE_OBJECT *device) > +{ > + pnp_device *pnp_dev; > + > + pnp_dev = HeapAlloc(GetProcessHeap(), 0, sizeof(*pnp_dev)); > + pnp_dev->device = device; > + EnterCriticalSection(&device_list_cs); > + list_add_tail(&pnp_devset, &pnp_dev->entry); > + LeaveCriticalSection(&device_list_cs); > +} > + > +static INT get_vidpid_index(DEVICE_OBJECT *device) > +{ > + pnp_device *ptr; > + int index = 1; > + extension *ext = (extension*)device->DeviceExtension; > + DWORD vidpid = MAKELONG(ext->vid, ext->pid); > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY(ptr, &pnp_devset, pnp_device, entry) > + { > + DWORD device_vidpid; > + > + ext = (extension*)ptr->device->DeviceExtension; > + device_vidpid = MAKELONG(ext->vid, ext->pid); > + > + if (device_vidpid == vidpid) > + index = max(ext->index + 1, index); > + } > + LeaveCriticalSection(&device_list_cs); As mentioned on IRC there is a risk of race-conditions when two threads try to add a device with the same vid/pid. I've already fixed that in my local version, I'm just mentioning it for completeness. > + return index; > +} > + > +static int get_instance_id(DEVICE_OBJECT *device, WCHAR *id) > +{ > + WCHAR index_string[256]; > + extension *ext = (extension*)device->DeviceExtension; > + > + if (ext->is_gamepad) > + sprintfW(index_string, ig_fmtW, ext->index); > + else > + sprintfW(index_string, im_fmtW, ext->index); > + > + return sprintfW(id, hwidfmtW, ext->busidW, ext->vid, ext->pid, index_string, ext->version, ext->serial, ext->uid); Wouldn't it be better to put together the string at once, without intermediate results? > +} > + > +DEVICE_OBJECT* bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, WORD pid, DWORD version, DWORD uid, const WCHAR *serial, BOOL is_gamepad, const GUID *class) > +{ > + NTSTATUS status; > + DEVICE_OBJECT *device; > + static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e', > + '\\','%','s','#','%','p',0}; > + static const WCHAR zero_serialW[]= {'0','0','0','0',0}; > + WCHAR dev_name[255]; > + UNICODE_STRING nameW; > + HDEVINFO devinfo; > + extension *ext; > + > + TRACE("Create HID bus device for native device %p\n", native); > + > + sprintfW(dev_name, device_name_fmtW, busidW, native); > + RtlInitUnicodeString(&nameW, dev_name); > + status = IoCreateDevice(driver, sizeof(extension), &nameW, 0, 0, FALSE, &device); > + if (status) > + { > + FIXME( "failed to create device error %x\n", status ); > + return NULL; > + } > + > + ext = (extension*)device->DeviceExtension; > + ext->native = native; > + ext->vid = vid; > + ext->pid = pid; > + ext->uid = uid; > + ext->is_gamepad = is_gamepad; > + ext->version = version; > + ext->busidW = busidW; > + ext->index = get_vidpid_index(device); > + if (serial) > + lstrcpyW(ext->serial, serial); > + else > + lstrcpyW(ext->serial, zero_serialW); > + > + add_device(device); > + > + devinfo = SetupDiGetClassDevsW(class, NULL, NULL, DIGCF_DEVICEINTERFACE); > + if (!devinfo) > + FIXME("Failed to get ClassDevs: %x\n", GetLastError()); > + else > + { > + SP_DEVINFO_DATA Data; > + WCHAR id[MAX_DEVICE_ID_LEN]; > + > + get_instance_id(device, id); > + Data.cbSize = sizeof(Data); > + if (!SetupDiCreateDeviceInfoW(devinfo, id, class, NULL, NULL, DICD_INHERIT_CLASSDRVS, &Data)) > + FIXME("Failed to create device info: %x\n", GetLastError()); > + else if (!SetupDiRegisterDeviceInfo(devinfo, &Data, 0, NULL, NULL, NULL )) > + FIXME("Failed to Register Device Info: %x\n", GetLastError()); > + SetupDiDestroyDeviceInfoList(devinfo); > + } > + > + IoInvalidateDeviceRelations(device, BusRelations); > + > + return device; > +} > + > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; > > >

2 1

Re: winmm/tests: Add a small Sleep() to prevent a notification test from failing.
by Marvin 13 Sep '16

13 Sep '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=25773 Your paranoid android. === w864 (32 bit mci) === mci: unhandled exception c0000005 at 77479E80 === w1064 (32 bit mci) === mci: unhandled exception c0000005 at 7698851A

2 1

Re: [PATCH] mpr: Implement connected resources enumeration.
by Hugh McMaster 13 Sep '16

13 Sep '16

Hi Pierre, Thanks for working on this. Some comments below. Hugh On Tuesday, 13 September 2016 5:53 AM, Pierre Schweitzer wrote: > @@ -73,6 +74,7 @@ typedef struct _WNetProviderTable > #define WNET_ENUMERATOR_TYPE_GLOBAL 1 > #define WNET_ENUMERATOR_TYPE_PROVIDER 2 > #define WNET_ENUMERATOR_TYPE_CONTEXT 3 >+#define WNET_ENUMERATOR_TYPE_CONNECTED 4 Please align all of the #defines using two or four spaces after the definition. > - LPNETRESOURCEW lpNet; > + union > + { > + NETRESOURCEW * net; > + HANDLE * handles; > + }; We prefer the * to sit directly adjacent to the variable name, so NETRESOURCEW *net (i.e. no space before the variable name). > +static PWNetEnumerator _createConnectedEnumerator(DWORD dwScope, DWORD dwType, > + DWORD dwUsage) > +{ > + PWNetEnumerator ret = HeapAlloc(GetProcessHeap(), > + HEAP_ZERO_MEMORY, sizeof(WNetEnumerator)); These lines do not need to be split. > +#define _copyStringToEnumW(s) \ > + len = strlenW(buffer[i].s) + 1; \ > + len *= sizeof(WCHAR); \ > + if (left < len) \ > + { \ > + ret = WN_MORE_DATA; \ > + break; \ > + } \ > + end = (PVOID)((ULONG_PTR)end - len); \ > + curr->s = end; \ > + memcpy(end, buffer[i].s, len); \ > + left -= len; This would be better understood as a helper function. > +static DWORD _enumerateConnectedW(PWNetEnumerator enumerator, DWORD * user_count, > + VOID * user_buffer, DWORD * user_size) Please fix the * position. Also, please align the second line of arguments beneath PWNetEnumerator. 'VOID' should be 'void'. > +{ > + DWORD ret, index, count, size, i, len, left; > + PVOID end; > + LPNETRESOURCEW curr, buffer; > + PHANDLE handles; Avoid LPnnn and Pnnn syntax. Use void *, NETRESOURCEW * and HANDLE * instead. This mistake happens later on in your patch too. > + if (!user_count) > + return WN_BAD_POINTER; > + if (!user_buffer) > + return WN_BAD_POINTER; > + if (!user_size) > + return WN_BAD_POINTER; Unless you plan to change this code in another patch, you can combine these into two lines. > + if (handles[index] == 0) > + { > + ret = providerTable->table[index].openEnum(enumerator->dwScope, > + enumerator->dwType, > + enumerator->dwUsage, > + NULL, &handles[index]); > + if (ret != WN_SUCCESS) > + continue; > + } > + > + ret = providerTable->table[index].enumResource(handles[index], > + &count, > + buffer, > + &size); Line formatting. > + for (index = 0; index < providerTable->numProviders; index++) > + { > + if (providerTable->table[index].dwEnumScopes && handles[index] != 0) > + providerTable->table[index].closeEnum(handles[index]); > + } You can remove the != 0 statement since you don't use it for providerTable->table[index].dwEnumScopes.

1 0

Re: setupapi/tests: Try to delete pre-existing key
by Marvin 12 Sep '16

12 Sep '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=25761 Your paranoid android. === w1064 (64 bit devinst) === devinst.c:1142: Test failed: Unexpected path \\?\root#legacy_bogus#0001#{6a55b5a4-3f65-11db-b704-0011955c2bdb} devinst.c:1264: Test failed: Expected key to not exist devinst.c:1370: Test failed: Expected key to not exist

1 0

Re: [PATCH v7] winebus.sys: Build initial hidraw device set
by Sebastian Lackner 12 Sep '16

12 Sep '16

On 08.09.2016 20:07, Aric Stewart wrote: > v2: style changes > v4: changes required by previous updates > v6: removed disableing busses > v7: Rebased, suggestions from Sebastian Lackner > > Includes implementation of common HID_PNP_CreateDevice > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/Makefile.in | 3 +- > dlls/winebus.sys/bus.h | 2 + > dlls/winebus.sys/bus_udev.c | 117 ++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 156 +++++++++++++++++++++++++++++++++++++++++++ > loader/wine.inf.in | 15 +++-- > 5 files changed, 288 insertions(+), 5 deletions(-) > > > > v7-0002-winebus.sys-Build-initial-hidraw-device-set.txt > > > diff --git a/dlls/winebus.sys/Makefile.in b/dlls/winebus.sys/Makefile.in > index 99ff4d2..2d29105 100644 > --- a/dlls/winebus.sys/Makefile.in > +++ b/dlls/winebus.sys/Makefile.in > @@ -1,5 +1,6 @@ > MODULE = winebus.sys > -IMPORTS = ntoskrnl > +IMPORTS = ntoskrnl setupapi > +EXTRALIBS = $(UDEV_LIBS) It might be useful to set EXTRAINCL aswell, for example: EXTRAINCL = $(UDEV_CFLAGS) The value is also obtained using pkg-config. In my case its empty but I don't know if thats true for all systems. > EXTRADLLFLAGS = -Wb,--subsystem,native > > C_SRCS = \ > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 3d53a46..09920dd 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -21,3 +21,5 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, LPVOID native, WORD vid, WORD pid, DWORD version, DWORD uid, const WCHAR *serial, BOOL is_gamepad, const GUID *class) DECLSPEC_HIDDEN; > +DWORD check_bus_option(UNICODE_STRING *registry_path, const UNICODE_STRING *option) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index f040e60..e6319cb 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -20,6 +20,19 @@ > > #include "config.h" > #include <stdarg.h> > +#include <unistd.h> > +#include <fcntl.h> > +#include <stdlib.h> > + > +#ifdef HAVE_SYS_IOCTL_H > +# include <sys/ioctl.h> > +#endif > + > +#ifdef HAVE_LIBUDEV_H > +# include <libudev.h> > +#endif > + > +#include <errno.h> > > #define NONAMELESSUNION > > @@ -27,6 +40,7 @@ > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > +#include "winnls.h" > #include "winternl.h" > #include "ddk/wdm.h" > #include "wine/debug.h" > @@ -39,13 +53,116 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > static DRIVER_OBJECT *udev_driver_obj = NULL; > > +#include "initguid.h" > +DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); > + > +static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > + > +/* udev based PNP support */ > +static struct udev *udev = NULL; > + > +static void try_add_device(void *dev) The parameter should have the type "struct udev_device *". > +{ > + const char *devnode; > + int fd; > + DWORD vid=0, pid=0, uid=0, version=0; > + WCHAR serial[255] = {'0','0','0','0','0',0}; > + DEVICE_OBJECT *device = NULL; > + struct udev_device *usbdev; > + const char *subsystem; > + > + devnode = udev_device_get_devnode(dev); According to the documentation this function can also return NULL under specific circumstances: "the device node file name of the udev device, or NULL if no device node exists". > + if ((fd = open(devnode, O_RDWR)) == -1) > + { > + TRACE("Unable to open udev device %s\n",devnode); Please use debugstr_a() for tracing strings of arbitrary length. It also wouldn't hurt to promote it to a WARN() and trace an error description, for example using strerror(). > + return; > + } > + close(fd); > + > + TRACE("Got udev device %s\n", devnode); Similar to above, please use debugstr_a(). > + > + usbdev = udev_device_get_parent_with_subsystem_devtype(dev, "usb", > + "usb_device"); > + if (usbdev) > + { > + char *endptr; > + const char *srl = NULL; > + vid = strtol(udev_device_get_sysattr_value(usbdev,"idVendor"), &endptr, 16); > + pid = strtol(udev_device_get_sysattr_value(usbdev,"idProduct"), &endptr, 16); > + version = strtol(udev_device_get_sysattr_value(usbdev,"version"), &endptr, 10); Those calls could fail: "the content of a sys attribute file, or NULL if there is no sys attribute value.". > + srl = udev_device_get_sysattr_value(usbdev,"serial"); > + if (srl) > + MultiByteToWideChar(CP_UNIXCP, 0, srl, -1, serial, 255); > + } > + > + subsystem = udev_device_get_subsystem(dev); > + > + if (strcmp(subsystem, "hidraw") == 0) > + device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, version, uid, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + else > + ERR("Device has unknown subsystem %s\n", subsystem); > + > + if (!device) > + ERR("Failed to create device\n"); > +} > + > +static void build_initial_deviceset(void *udev, const char **subsystems) The function takes a parameter "udev", but there is also a global variable with the same name. This seems a bit redundant. Also, I would suggest to remove the subsystems parameter here, and enumerate all types of devices which are supported. You can still filter them in try_add_device if required later. > +{ > + struct udev_enumerate *enumerate; > + struct udev_list_entry *udevices, *dev_list_entry; > + const char **p; > + > + enumerate = udev_enumerate_new(udev); > + p = subsystems; > + while (*p) > + { > + udev_enumerate_add_match_subsystem(enumerate, *p); > + p++; > + } > + udev_enumerate_scan_devices(enumerate); > + udevices = udev_enumerate_get_list_entry(enumerate); > + > + udev_list_entry_foreach(dev_list_entry, udevices) { > + const char *path; > + struct udev_device *dev; > + > + path = udev_list_entry_get_name(dev_list_entry); > + dev = udev_device_new_from_syspath(udev, path); > + try_add_device(dev); According to the documentation some of these udev functions can fail. It would be better to catch errors here, especially for udev_enumerate_new() and udev_device_new_from_syspath(). There are also refcounting issues, udev_device_new_from_syspath creates a new object which must be released when no longer needed (for example if try_add_device fails). > + } > + > + udev_enumerate_unref(enumerate); > +} > + > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > { > + static const WCHAR hidraw_disabledW[] = {'D','i','s','a','b','l','e',' ','h','i','d','r','a','w',0}; > + static const UNICODE_STRING hidraw_disabled = {sizeof(hidraw_disabledW) - sizeof(WCHAR), sizeof(hidraw_disabledW), (WCHAR*)hidraw_disabledW}; > + static const char *hidraw = "hidraw"; > + static const char *subsystems[2] = {0, 0}; > + > TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > > udev_driver_obj = driver; > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > > + if (check_bus_option(registry_path, &hidraw_disabled)) > + TRACE("UDEV hidraw devices disabled in registry\n"); > + else > + subsystems[0] = hidraw; > + > + udev = udev_new(); > + > + if (!udev) > + { > + ERR("Can't create udev\n"); > + return STATUS_UNSUCCESSFUL; > + } > + > + /* PNP Bus initialization */ > + if (subsystems[0]) > + build_initial_deviceset(udev, subsystems); > + > return STATUS_SUCCESS; > } > > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 43de25a..94f1b4b 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -18,6 +18,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#include "config.h" > #include <stdarg.h> > > #define NONAMELESSUNION > @@ -26,14 +27,143 @@ > #define WIN32_NO_STATUS > #include "windef.h" > #include "winbase.h" > +#include "winuser.h" > #include "winternl.h" > +#include "winreg.h" > +#include "setupapi.h" > +#include "cfgmgr32.h" > #include "ddk/wdm.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > +#include "wine/list.h" > > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > +static const WCHAR hwidfmtW[] = {'%','s','\\','V','i','d','_','%','0','4','x','&','P','i','d','_','%','0','4','x','&','%','s','\\','%','i','&','%','s','&','%','p',0}; > +static const WCHAR im_fmtW[] = {'I','M','_','%','i',0}; > +static const WCHAR ig_fmtW[] = {'I','G','_','%','i',0}; > + > +typedef struct _pnp_device { > + struct list entry; > + > + DEVICE_OBJECT *device; > + DWORD vidpid; It would not really be necessary to store the vid/pid information twice. You can also access it using device->DeviceExtension. > +} pnp_device; > + > +typedef struct { > + LPVOID native; /* Must be the first member of the structure */ > + > + DWORD vid, pid, version, uid; > + BOOL is_gamepad; > + WCHAR serial[255]; > + WCHAR const *busidW; /* Expected to be a static constant */ > +} extension; > + > +static struct list pnp_devset = LIST_INIT(pnp_devset); Its up to you if you want to add it now, but sooner or later you will need locking for such a list when it can be accessed by multiple threads. Also, as I saw that you have to convert the list back to a linear array in some of the functions implemented in following patches. Do you think it makes sense to store it as an array from the start? (Lock would still be needed but no conversion). > + > +static void add_device(DEVICE_OBJECT *device, DWORD vidpid) > +{ > + pnp_device *pnp_dev; > + > + pnp_dev = HeapAlloc(GetProcessHeap(), 0, sizeof(*pnp_dev)); > + pnp_dev->device = device; > + pnp_dev->vidpid = vidpid; > + list_add_tail(&pnp_devset, &pnp_dev->entry); > +} > + > +static INT get_vidpid_index(DEVICE_OBJECT *device, DWORD vidpid) > +{ > + pnp_device *ptr; > + int index = 0; > + LIST_FOR_EACH_ENTRY(ptr, &pnp_devset, pnp_device, entry) > + { > + if (ptr->vidpid == vidpid) > + index++; > + if (ptr->device == device) > + return index; > + } > + ERR("Device not found in list\n"); > + return 0; > +} Does this work properly when elements are deleted? You might return the same index for different devices. > + > +static int get_instance_id(DEVICE_OBJECT *device, WCHAR *id) > +{ > + int idx; > + WCHAR index_string[256]; > + > + extension *ext = (extension*)device->DeviceExtension; > + > + idx = get_vidpid_index(device, MAKELONG(ext->vid,ext->pid)); > + > + if (ext->is_gamepad) > + sprintfW(index_string, ig_fmtW, idx); > + else > + sprintfW(index_string, im_fmtW, idx); > + > + return sprintfW(id, hwidfmtW, ext->busidW, ext->vid, ext->pid, index_string, ext->version, ext->serial, ext->uid); It looks like you use %p in the format string, but uid has type DWORD? > +} > + > +DEVICE_OBJECT* bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, LPVOID native, WORD vid, WORD pid, DWORD version, DWORD uid, const WCHAR *serial, BOOL is_gamepad, const GUID *class) > +{ Please note that LPVOID types should be avoided in new wine code. > + NTSTATUS status; > + DEVICE_OBJECT *device; > + static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e', > + '\\','%','s','#','%','p',0}; > + static const WCHAR zero_serialW[]= {'0','0','0','0',0}; > + WCHAR dev_name[255]; > + UNICODE_STRING nameW; > + HDEVINFO devinfo; > + extension *ext; > + > + TRACE("Create HID bus device for native device %p\n", native); > + > + sprintfW(dev_name, device_name_fmtW, busidW, native); > + RtlInitUnicodeString(&nameW, dev_name); > + status = IoCreateDevice(driver, sizeof(extension), &nameW, 0, 0, FALSE, &device); > + if (status) > + { > + FIXME( "failed to create device error %x\n", status ); > + return NULL; > + } > + > + ext = (extension*)device->DeviceExtension; > + ext->native = native; At least for udev the device object has to be released. It looks like the logic is currently missing (also in your draft patches). In order to fix that it will probably be necessary to store additional information in each device object. > + ext->vid = vid; > + ext->pid = pid; > + ext->uid = uid; > + ext->is_gamepad = is_gamepad; > + ext->version = version; > + ext->busidW = busidW; > + if (serial) > + lstrcpyW(ext->serial, serial); > + else > + lstrcpyW(ext->serial, zero_serialW); > + > + add_device(device, MAKELONG(vid, pid)); > + > + devinfo = SetupDiGetClassDevsW(class, NULL, NULL, DIGCF_DEVICEINTERFACE); > + if (!devinfo) > + FIXME( "failed to get ClassDevs %x\n", GetLastError()); > + else > + { > + SP_DEVINFO_DATA Data; > + WCHAR id[MAX_DEVICE_ID_LEN]; > + > + get_instance_id(device, id); > + Data.cbSize = sizeof(Data); > + SetupDiCreateDeviceInfoW(devinfo, id, class, NULL, NULL, DICD_INHERIT_CLASSDRVS, &Data); > + if (!SetupDiRegisterDeviceInfo(devinfo, &Data, 0, NULL, NULL, NULL )) > + FIXME( "failed to Register Device Info %x\n", GetLastError()); > + SetupDiDestroyDeviceInfoList(devinfo); How does this correspond to similar code in hidclass.sys/device.c. Do we really need both? Why does hidclass contain a call to SetupDiCreateDeviceInterfaceW but not this version? > + } > + > + IoInvalidateDeviceRelations(device, BusRelations); > + > + return device; > +} > + > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; > @@ -59,6 +189,32 @@ NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > return status; > } > > +DWORD check_bus_option(UNICODE_STRING *registry_path, const UNICODE_STRING *option) > +{ > + OBJECT_ATTRIBUTES attr; > + HANDLE key; > + DWORD output = 0; > + > + InitializeObjectAttributes(&attr, registry_path, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL); > + if (ZwOpenKey(&key, KEY_ALL_ACCESS, &attr) == STATUS_SUCCESS) > + { > + DWORD size; > + char buffer[FIELD_OFFSET(KEY_VALUE_PARTIAL_INFORMATION, Data[sizeof(DWORD)])]; > + > + KEY_VALUE_PARTIAL_INFORMATION *info = (KEY_VALUE_PARTIAL_INFORMATION*)buffer; > + > + if (ZwQueryValueKey(key, option, KeyValuePartialInformation, info, sizeof(buffer), &size) == STATUS_SUCCESS) > + { > + if (info->Type == REG_DWORD) > + output = *(DWORD*)info->Data; > + } > + > + ZwClose(key); > + } > + > + return output; > +} I think it would be better to add this in a later patch. Currently there is only support for one subsystem, so it would not make much sense to disable it. > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > diff --git a/loader/wine.inf.in b/loader/wine.inf.in > index 4e29026..a29b99f 100644 > --- a/loader/wine.inf.in > +++ b/loader/wine.inf.in > @@ -48,7 +48,8 @@ AddReg=\ > SessionMgr,\ > Tapi,\ > Timezones,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.NT] > RegisterDlls=RegisterDllsSection > @@ -73,7 +74,8 @@ AddReg=\ > Tapi,\ > Timezones,\ > VersionInfo,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.ntamd64] > RegisterDlls=RegisterDllsSection > @@ -100,7 +102,8 @@ AddReg=\ > Tapi,\ > Timezones,\ > VersionInfo.ntamd64,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [Wow64Install] > RegisterDlls=RegisterDllsSection > @@ -115,7 +118,8 @@ AddReg=\ > Misc,\ > Tapi,\ > VersionInfo.ntamd64,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.Services] > AddService=BITS,0,BITSService > @@ -3383,3 +3387,6 @@ HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-Shanghai-EnableGame",0x1 > HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-Solitaire-EnableGame",0x10001,0x00000001 > HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-SpiderSolitaire-EnableGame",0x10001,0x00000001 > HKLM,Software\Wine\LicenseInformation,"Shell-PremiumInBoxGames-Chess-EnableGame",0x10001,0x00000001 > + > +[PlatformBus] > +HKLM,System\CurrentControlSet\Services\UDEV,"Disable hidraw",0x10001,0x00000000 It does not make sense to add registry keys for user-defined settings in wine.inf. This would have the disadvantage that they will get reset on each wine prefix update. The correct solution is to assume default settings when registry keys are not present. > > >

2 3

Re: [v3 PATCH] d2d1: Initial implementation of DC render target
by Henri Verbeet 12 Sep '16

12 Sep '16

On 11 September 2016 at 22:49, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > v2: skip test if device creation fails > I think that's fine, but now you're leaking the device on success.

1 0

Wine slow load somewhere after 1.9.16
by Bruno Jesus 12 Sep '16

12 Sep '16

Hi all, for unknown reasons at some point since the past month I get this most of the times I try to start anything in wine: err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84 "../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 001d, blocked by 001e, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84 "../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 001c, blocked by 001e, retrying (60 sec) These are always the first 2 lines in the log and it takes some seconds before it goes on. I'll try a regression test but would like to know if I'm the only one affected. Best wishes, Bruno

2 2

Wine Staging release notes
by Theodore Dubois 11 Sep '16

11 Sep '16

The latest release notes on the Wine Staging website are for 1.9.11, which was in May. What’s been improved since then? Also, why aren’t the release notes for 1.9.18 up on the website? ~Theodore

2 1

Re: [v2 PATCH] d2d1: Initial implementation of DC render target
by Sebastian Lackner 11 Sep '16

11 Sep '16

On 11.09.2016 22:24, Nikolay Sivov wrote: > + ok(sizeu.width == 0.0f, "got width %u.\n", sizeu.width); > + ok(sizeu.height == 0.0f, "got height %u.\n", sizeu.height); This looks like a copy&paste error. Shouldn't those be integer values?

1 0

Re: [4/4] jscript: Simplify create_utc_string and add basic tests.
by Marvin 11 Sep '16

11 Sep '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=25750 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [3/4] jscript: Simplify date_to_string and add basic tests.
by Marvin 11 Sep '16

11 Sep '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=25749 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [2/4] jscript: Allocate string of correct size in Date toLocaleDateString method.
by Marvin 11 Sep '16

11 Sep '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=25748 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [1/4] jscript: Properly handle \0 characters in Array join method.
by Marvin 11 Sep '16

11 Sep '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=25747 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d
by Nikolay Sivov 10 Sep '16

10 Sep '16

On 10.09.2016 1:18, Fabian Maurer wrote: > This change is a measure of code-deduplication and to make these functions reusable in other parts. > Kept in wined3d.dll instead of dxgi.dll to make sure dll-overrides of dxgi doesn't break things in other parts. > New source-file since further additions will follow. > What dxgi dll-overrides? Without private interfaces between d3d10/11 and dxgi we can't use native one anyway, can we?

2 3

Re: kernel32/tests: Don't test CloseHandle
by Marvin 10 Sep '16

10 Sep '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=25735 Your paranoid android. === w8 (32 bit console) === console.c:1497: Test failed: [13] Expected output count to be 0, got 23550478 console.c:1497: Test failed: [15] Expected output count to be 0, got 23550478 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 23550478 console.c:1741: Test failed: [13] Expected output count to be 0, got 23550478 console.c:1741: Test failed: [15] Expected output count to be 0, got 23550478 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 23550478 === w864 (32 bit console) === console.c:2619: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2625: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2632: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2639: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [13] Expected output count to be 0, got 2507489323 console.c:1497: Test failed: [15] Expected output count to be 0, got 2507489323 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 2507489323 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [13] Expected output count to be 0, got 2507489323 console.c:1741: Test failed: [15] Expected output count to be 0, got 2507489323 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 2507489323 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1 === w1064 (32 bit console) === console.c:2619: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2625: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2632: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2639: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [13] Expected output count to be 0, got 80193794 console.c:1497: Test failed: [15] Expected output count to be 0, got 80193794 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 80193794 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [13] Expected output count to be 0, got 80193794 console.c:1741: Test failed: [15] Expected output count to be 0, got 80193794 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 80193794 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1 === w864 (64 bit console) === console.c:2619: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2625: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2632: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2639: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:2619: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2625: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2632: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2639: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1322: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1497: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1497: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1741: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2200: Test failed: [7] Expected count to be 0, got 1 console.c:2266: Test failed: [7] Expected count to be 0, got 1 console.c:2332: Test failed: [7] Expected count to be 0, got 1

1 0

Re: kernel32/tests: Don't test function directly when reporting GetLastError()
by Marvin 10 Sep '16

10 Sep '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=25734 Your paranoid android. === w8 (32 bit console) === console.c:1498: Test failed: [13] Expected output count to be 0, got 2480191978 console.c:1498: Test failed: [15] Expected output count to be 0, got 2480191978 console.c:1498: Test failed: [18] Expected output count to be 3735928559, got 2480191978 console.c:1742: Test failed: [13] Expected output count to be 0, got 2480191978 console.c:1742: Test failed: [15] Expected output count to be 0, got 2480191978 console.c:1742: Test failed: [18] Expected output count to be 3735928559, got 2480191978 === w864 (32 bit console) === console.c:2620: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2626: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2633: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2640: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1323: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1498: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [13] Expected output count to be 0, got 3813979195 console.c:1498: Test failed: [15] Expected output count to be 0, got 3813979195 console.c:1498: Test failed: [18] Expected output count to be 3735928559, got 3813979195 console.c:1742: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [13] Expected output count to be 0, got 3813979195 console.c:1742: Test failed: [15] Expected output count to be 0, got 3813979195 console.c:1742: Test failed: [18] Expected output count to be 3735928559, got 3813979195 console.c:2201: Test failed: [7] Expected count to be 0, got 1 console.c:2267: Test failed: [7] Expected count to be 0, got 1 console.c:2333: Test failed: [7] Expected count to be 0, got 1 === w1064 (32 bit console) === console.c:2620: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2626: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2633: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2640: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1323: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1498: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [13] Expected output count to be 0, got 1998939738 console.c:1498: Test failed: [15] Expected output count to be 0, got 1998939738 console.c:1498: Test failed: [18] Expected output count to be 3735928559, got 1998939738 console.c:1742: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [13] Expected output count to be 0, got 1998939738 console.c:1742: Test failed: [15] Expected output count to be 0, got 1998939738 console.c:1742: Test failed: [18] Expected output count to be 3735928559, got 1998939738 console.c:2201: Test failed: [7] Expected count to be 0, got 1 console.c:2267: Test failed: [7] Expected count to be 0, got 1 console.c:2333: Test failed: [7] Expected count to be 0, got 1 === w864 (64 bit console) === console.c:2620: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2626: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2633: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2640: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1323: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1498: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2201: Test failed: [7] Expected count to be 0, got 1 console.c:2267: Test failed: [7] Expected count to be 0, got 1 console.c:2333: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:2620: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2626: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2633: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2640: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1323: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1498: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1498: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1742: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2201: Test failed: [7] Expected count to be 0, got 1 console.c:2267: Test failed: [7] Expected count to be 0, got 1 console.c:2333: Test failed: [7] Expected count to be 0, got 1

1 0

Re: [resend PATCH] d2d1: Initial implementation of DC render target
by Alexandre Julliard 09 Sep '16

09 Sep '16

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > > Resending so bot can pick it up this time. > > dlls/d2d1/Makefile.in | 3 +- > dlls/d2d1/d2d1_private.h | 16 + > dlls/d2d1/dc_render_target.c | 875 +++++++++++++++++++++++++++++++++++++++++++ > dlls/d2d1/factory.c | 50 ++- > dlls/d2d1/render_target.c | 36 ++ > dlls/d2d1/tests/d2d1.c | 11 +- > 6 files changed, 976 insertions(+), 15 deletions(-) > create mode 100644 dlls/d2d1/dc_render_target.c It breaks the tests here: ../../../tools/runtest -q -P wine -T ../../.. -M d2d1.dll -p d2d1_test.exe.so d2d1 && touch d2d1.ok d2d1.c:531: Tests skipped: Failed to create device, skipping tests. d2d1.c:683: Tests skipped: Failed to create device, skipping tests. d2d1.c:879: Tests skipped: Failed to create device, skipping tests. d2d1.c:1014: Tests skipped: Failed to create device, skipping tests. d2d1.c:1302: Tests skipped: Failed to create device, skipping tests. d2d1.c:1744: Tests skipped: Failed to create device, skipping tests. d2d1.c:1814: Tests skipped: Failed to create device, skipping tests. d2d1.c:2033: Tests skipped: Failed to create device, skipping tests. d2d1.c:2194: Tests skipped: Failed to create device, skipping tests. d2d1.c:2303: Tests skipped: Failed to create device, skipping tests. d2d1.c:2482: Tests skipped: Failed to create device, skipping tests. d2d1.c:2553: Tests skipped: Failed to create device, skipping tests. d2d1.c:2689: Test failed: Got unexpected hr 0x80004005. d2d1.c:2689: Test failed: Got unexpected hr 0x80004005. d2d1.c:2689: Test failed: Got unexpected hr 0x80004005. d2d1.c:2700: Test failed: Failed to create target, hr 0x80004005. wine: Unhandled page fault on read access to 0x00000114 at address 0x7eff3a86 (thread 012e), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] mscoree: There can be only one QI implementation i a COM object!
by Vincent Povirk 09 Sep '16

09 Sep '16

These look like 2 separate COM objects to me. They have different IUnknown pointers and a different set of implemented interfaces. Is there a reason to link them? On Thu, Sep 8, 2016 at 2:25 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/mscoree/config.c | 29 +++++++++-------------------- > 1 file changed, 9 insertions(+), 20 deletions(-) > > diff --git a/dlls/mscoree/config.c b/dlls/mscoree/config.c > index b8bf882..a52a521 100644 > --- a/dlls/mscoree/config.c > +++ b/dlls/mscoree/config.c > @@ -73,18 +73,19 @@ static inline ConfigFileHandler *impl_from_ISAXErrorHandler(ISAXErrorHandler *if > static HRESULT WINAPI ConfigFileHandler_QueryInterface(ISAXContentHandler *iface, > REFIID riid, void **ppvObject) > { > - if (IsEqualGUID(riid, &IID_ISAXContentHandler) || > - IsEqualGUID(riid, &IID_IUnknown)) > - { > - *ppvObject = iface; > - } > + ConfigFileHandler *This = impl_from_ISAXContentHandler(iface); > + > + if (IsEqualGUID(riid, &IID_ISAXContentHandler) || IsEqualGUID(riid, &IID_IUnknown)) > + *ppvObject = &This->ISAXContentHandler_iface; > + else if (IsEqualGUID(riid, &IID_ISAXErrorHandler)) > + *ppvObject = &This->ISAXErrorHandler_iface; > else > { > WARN("Unsupported interface %s\n", debugstr_guid(riid)); > return E_NOINTERFACE; > } > > - ISAXContentHandler_AddRef(iface); > + IUnknown_AddRef((IUnknown*)*ppvObject); > > return S_OK; > } > @@ -377,20 +378,8 @@ static const struct ISAXContentHandlerVtbl ConfigFileHandlerVtbl = > static HRESULT WINAPI ConfigFileHandler_Error_QueryInterface(ISAXErrorHandler *iface, > REFIID riid, void **ppvObject) > { > - if (IsEqualGUID(riid, &IID_ISAXErrorHandler) || > - IsEqualGUID(riid, &IID_IUnknown)) > - { > - *ppvObject = iface; > - } > - else > - { > - WARN("Unsupported interface %s\n", debugstr_guid(riid)); > - return E_NOINTERFACE; > - } > - > - ISAXErrorHandler_AddRef(iface); > - > - return S_OK; > + ConfigFileHandler *This = impl_from_ISAXErrorHandler(iface); > + return ISAXContentHandler_QueryInterface(&This->ISAXContentHandler_iface, riid, ppvObject); > } > > static ULONG WINAPI ConfigFileHandler_Error_AddRef(ISAXErrorHandler *iface) > -- > 2.7.4 > >

2 3

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.
by Ken Thomases 09 Sep '16

09 Sep '16

On Sep 7, 2016, at 10:48 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Module: wine > Branch: master > Commit: 761d244970dd189b1a639121e668a5089fd0112d > URL: http://source.winehq.org/git/wine.git/?a=commit;h=761d244970dd189b1a639121e… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Sep 7 11:35:14 2016 +0900 > > winex11: Remove support for synthesizing clipboard formats. > > Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> > > --- > > dlls/winex11.drv/clipboard.c | 454 ++------------------------------------ > dlls/winex11.drv/winex11.drv.spec | 1 - > 2 files changed, 14 insertions(+), 441 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=761d244970dd189b1a639… Either I'm missing something or this isn't correct. You've made user32 synthesize formats when a Windows app puts one text format on the clipboard but not the others, but you haven't handled the case were an external program has put some text on the clipboard. For example, if some non-Wine X client puts UTF8_STRING but not STRING or text/plain on the clipboard, a Windows program will see CF_UNICODETEXT, but not CF_TEXT or CF_OEMTEXT. That shouldn't be possible. -Ken

3 6

Re: [1/3] jscript: Properly handle \0 characters in String to{Lower,Upper}Case methods.
by Sebastian Lackner 09 Sep '16

09 Sep '16

On 09.09.2016 12:03, Jacek Caban wrote: > On 08.09.2016 23:52, Sebastian Lackner wrote: >> diff --git a/dlls/jscript/tests/api.js b/dlls/jscript/tests/api.js >> index c7f2bcd..e7b55fc 100644 >> --- a/dlls/jscript/tests/api.js >> +++ b/dlls/jscript/tests/api.js >> @@ -661,6 +661,8 @@ tmp = "tEsT".toLowerCase(); >> ok(tmp === "test", "''.toLowerCase() = " + tmp); >> tmp = "tEsT".toLowerCase(3); >> ok(tmp === "test", "''.toLowerCase(3) = " + tmp); >> +tmp = ("tE" + String.fromCharCode(0) + "sT").toLowerCase(); >> +ok(tmp === "te" + String.fromCharCode(0) + "st", "''.toLowerCase() = " + tmp); >> >> tmp = "".toUpperCase(); >> ok(tmp === "", "''.toUpperCase() = " + tmp); >> @@ -672,6 +674,8 @@ tmp = "tEsT".toUpperCase(); >> ok(tmp === "TEST", "''.toUpperCase() = " + tmp); >> tmp = "tEsT".toUpperCase(3); >> ok(tmp === "TEST", "''.toUpperCase(3) = " + tmp); >> +tmp = ("tE" + String.fromCharCode(0) + "sT").toUpperCase(); >> +ok(tmp === "TE" + String.fromCharCode(0) + "ST", "''.toUpperCase() = " + tmp); >> >> tmp = "".anchor(); >> ok(tmp === "<A NAME=\"undefined\"></A>", "''.anchor() = " + tmp); > > FWIW "\0" escape should work here, but that's fine with me. No, unfortunately that doesn't work yet. The lexer currently stores string literals in a \0 terminated string (see unescape in lex.c). The tests would pass, but only by luck because both strings are truncated. As soon as this issue is fixed we can use "\0" everywhere of course.

1 0

Re: [PATCH] ws2_32/tests: Add more SIO_ADDRESS_LIST_CHANGE tests
by Marvin 09 Sep '16

09 Sep '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=25719 Your paranoid android. === w7pro64 (32 bit sock) === sock.c:7766: Test failed: bytesReturned isn't supposed to be 1 sock.c:7790: Test failed: GetOverlappedResult failed, error 0

1 0

Re: [3/3] jscript: Allocate string of correct size in Date toTimeString method.
by Marvin 08 Sep '16

08 Sep '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=25702 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [2/3] jscript: Properly handle \0 characters in String indexOf method.
by Marvin 08 Sep '16

08 Sep '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=25701 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: [1/3] jscript: Properly handle \0 characters in String to{Lower, Upper}Case methods.
by Marvin 08 Sep '16

08 Sep '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=25700 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0

Re: shlwapi: Use debugstr_w() in TRACE() message.
by Nikolay Sivov 08 Sep '16

08 Sep '16

On 08.09.2016 23:51, Andrey Gusev wrote: > - TRACE("(%p, 0x%08x, %p, %p, %p, %p, %p, 0x%08x)\n", hUSKey, dwIndex, > - pszValueName, pcchValueNameLen, pdwType, pvData, pcbData, enumRegFlags); > + TRACE("(%p, 0x%08x, %s, %p, %p, %p, %p, 0x%08x)\n", hUSKey, dwIndex, > + debugstr_w(pszValueName), pcchValueNameLen, pdwType, pvData, pcbData, enumRegFlags); This is wrong, it's an out parameter.

1 0

Re: [PATCH] bcrypt/tests: Show that BCryptGetFipsAlgorithmMode checks a registry key
by Sebastian Lackner 08 Sep '16

08 Sep '16

On 08.09.2016 22:11, Bruno Jesus wrote: > + if (!RegOpenKeyW(HKEY_LOCAL_MACHINE, policyKeyVistaW, &hkey)) > + { Why do you open the key when you don't use it? > + if (!RegGetValueW(HKEY_LOCAL_MACHINE, policyKeyVistaW, policyValueVistaW, > + RRF_RT_REG_DWORD, NULL, &enabled, &count)) enabled has the type BOOLEAN and a size of 1 byte. Did you want to pass "value" instead? > + { > + expected = !!enabled; > + } > + RegCloseKey(hkey); > + }

1 0

Re: [PATCH] bcrypt/tests: Add more BCryptGetFipsAlgorithmMode tests
by Sebastian Lackner 08 Sep '16

08 Sep '16

On 08.09.2016 13:53, Bruno Jesus wrote: > From: Kai Blaschke <kai.blaschke(a)kb-dev.net> > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > --- > dlls/bcrypt/tests/Makefile.in | 2 +- > dlls/bcrypt/tests/bcrypt.c | 49 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 49 insertions(+), 2 deletions(-) > > diff --git a/dlls/bcrypt/tests/Makefile.in b/dlls/bcrypt/tests/Makefile.in > index 0f130b1..1bf7d2c 100644 > --- a/dlls/bcrypt/tests/Makefile.in > +++ b/dlls/bcrypt/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = bcrypt.dll > -IMPORTS = bcrypt user32 > +IMPORTS = bcrypt user32 advapi32 > > C_SRCS = \ > bcrypt.c > diff --git a/dlls/bcrypt/tests/bcrypt.c b/dlls/bcrypt/tests/bcrypt.c > index 9bd2cea..d16735c 100644 > --- a/dlls/bcrypt/tests/bcrypt.c > +++ b/dlls/bcrypt/tests/bcrypt.c > @@ -61,14 +61,61 @@ static void test_BCryptGenRandom(void) > > static void test_BCryptGetFipsAlgorithmMode(void) > { > - NTSTATUS ret; > + static const WCHAR policyKeyVistaW[] = { > + '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','\\', > + 'L','s','a','\\', > + 'F','I','P','S','A','l','g','o','r','i','t','h','m','P','o','l','i','c','y',0}; > + static const WCHAR policyValueVistaW[] = {'E','n','a','b','l','e','d',0}; > + static const WCHAR policyKeyXPW[] = { > + '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','\\', > + 'L','s','a',0}; > + static const WCHAR policyValueXPW[] = { > + 'F','I','P','S','A','l','g','o','r','i','t','h','m','P','o','l','i','c','y',0}; > + HKEY hkey; > + BOOLEAN expected; > + BOOLEAN result; > BOOLEAN enabled; > + DWORD value, count = sizeof(value); > + NTSTATUS ret; > > ret = BCryptGetFipsAlgorithmMode(&enabled); > ok(ret == STATUS_SUCCESS, "Expected STATUS_SUCCESS, got 0x%x\n", ret); > > ret = BCryptGetFipsAlgorithmMode(NULL); > ok(ret == STATUS_INVALID_PARAMETER, "Expected STATUS_INVALID_PARAMETER, got 0x%x\n", ret); > + > + expected = FALSE; > + > + if (!RegOpenKeyW(HKEY_LOCAL_MACHINE, policyKeyVistaW, &hkey)) > + { > + if (!RegGetValueW(HKEY_LOCAL_MACHINE, policyKeyVistaW, policyValueVistaW, > + RRF_RT_REG_DWORD, NULL, &enabled, &count)) > + { > + expected = !!enabled; > + } > + RegCloseKey(hkey); > + } > + else if (!RegOpenKeyW(HKEY_LOCAL_MACHINE, policyKeyXPW, &hkey)) > + { > + if (!RegGetValueW(HKEY_LOCAL_MACHINE, policyKeyXPW, policyValueXPW, > + RRF_RT_REG_DWORD, NULL, &enabled, &count)) > + { > + expected = !!enabled; > + } > + RegCloseKey(hkey); > + } > + > + ret = BCryptGetFipsAlgorithmMode(&result); > + ok(!ret, "expected status STATUS_SUCCESS(0), got 0x%08X\n", ret); > + ok(result == expected, "expected result %d, got %d\n", expected, result); > + > + ret = BCryptGetFipsAlgorithmMode(NULL); > + ok(ret == STATUS_INVALID_PARAMETER, > + "expected status STATUS_INVALID_PARAMETER(0xC000000D), got 0x%08X\n", ret); Is it intentional that you test everything twice? It would be sufficient to add the "result == expected" check to the existing testcase above. > } > > static void format_hash(const UCHAR *bytes, ULONG size, char *buf) >

2 1

Re: user32/tests: Fix incorrect usage of broken() function. (v2)
by Marvin 08 Sep '16

08 Sep '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=25693 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: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:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

1 0

Re: [PATCH] d2d1: Initial implementation of DC render target
by Marvin 08 Sep '16

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

1 0

Re: jscript/tests: Fix incorrect usage of broken() function.
by Jacek Caban 08 Sep '16

08 Sep '16

Hi Sebastian, On 9/8/16 11:13 AM, Sebastian Lackner wrote: > diff --git a/dlls/jscript/tests/jscript.c b/dlls/jscript/tests/jscript.c > index f949b9d..fb647a5 100644 > --- a/dlls/jscript/tests/jscript.c > +++ b/dlls/jscript/tests/jscript.c > @@ -659,7 +659,7 @@ static void test_aggregation(void) > > hres = CoCreateInstance(&CLSID_JScript, (IUnknown*)0xdeadbeef, CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > &IID_IUnknown, (void**)&unk); > - ok(hres == CLASS_E_NOAGGREGATION || broken(E_INVALIDARG) /* win2k */, > + ok(hres == CLASS_E_NOAGGREGATION || broken(hres == E_INVALIDARG) /* win2k */, If it's really broken only on win2k, I'd rather remove it. Thanks, Jacek

1 0

Re: user32/tests: Fix incorrect usage of broken() function.
by Marvin 08 Sep '16

08 Sep '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=25673 Your paranoid android. === w8 (32 bit msg) === msg.c:15529: Test failed: wrong error 31 === w864 (32 bit msg) === msg.c:15529: Test failed: wrong error 31 === w1064 (32 bit msg) === msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 msg.c:15529: Test failed: wrong error 31 === w864 (64 bit msg) === msg.c:15529: Test failed: wrong error 31 === w1064 (64 bit msg) === msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 msg.c:15529: Test failed: wrong error 31

2 1

Re: shell32/tests: Fix incorrect usage of broken() function.
by Nikolay Sivov 08 Sep '16

08 Sep '16

On 08.09.2016 12:23, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/shell32/tests/shelldispatch.c | 2 +- > dlls/shell32/tests/shfldr_special.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/tests/shelldispatch.c b/dlls/shell32/tests/shelldispatch.c > index 9a47c67..70146cb 100644 > --- a/dlls/shell32/tests/shelldispatch.c > +++ b/dlls/shell32/tests/shelldispatch.c > @@ -346,7 +346,7 @@ static void test_items(void) > ok(r == S_OK, "Folder::Items failed: %08x\n", r); > ok(!!items, "items is null\n"); > r = FolderItems_QueryInterface(items, &IID_FolderItems2, (void**)&items2); > - ok(r == S_OK || broken(E_NOINTERFACE) /* xp and later */, "FolderItems::QueryInterface failed: %08x\n", r); > + ok(r == S_OK || broken(r == E_NOINTERFACE) /* xp and later */, "FolderItems::QueryInterface failed: %08x\n", r); Does it really fail anywhere? I don't see that on test results page. > ok(!!items2 || broken(!items2) /* xp and later */, "items2 is null\n"); > r = FolderItems_QueryInterface(items, &IID_FolderItems3, (void**)&items3); > ok(r == S_OK, "FolderItems::QueryInterface failed: %08x\n", r); > diff --git a/dlls/shell32/tests/shfldr_special.c b/dlls/shell32/tests/shfldr_special.c > index 6d61220..dd4cc04 100644 > --- a/dlls/shell32/tests/shfldr_special.c > +++ b/dlls/shell32/tests/shfldr_special.c > @@ -166,7 +166,7 @@ if (0) > > details.str.u.pOleStr = NULL; > hr = IShellFolder2_GetDetailsOf(folder, NULL, 0, &details); > - ok(hr == S_OK || broken(E_NOTIMPL) /* W2K */, "got 0x%08x\n", hr); > + ok(hr == S_OK || broken(hr == E_NOTIMPL) /* W2K */, "got 0x%08x\n", hr); > if (SHELL_OsIsUnicode()) SHFree(details.str.u.pOleStr); Win2K case could as well be removed. > > /* test every column if method is implemented */ >

2 2

Re: [PATCH 2/2] dxgi: Added partial implementation of GetDC()/ReleaseDC()
by Henri Verbeet 08 Sep '16

08 Sep '16

On 7 September 2016 at 20:50, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d3d11/tests/d3d11.c | 6 +++--- > dlls/dxgi/dxgi_private.h | 1 + > dlls/dxgi/surface.c | 32 ++++++++++++++++++++++++++++---- > 3 files changed, 32 insertions(+), 7 deletions(-) > This causes test failures: ../../../tools/runtest -q -P wine -T ../../.. -M d3d10_1.dll -p d3d10_1_test.exe.so d3d10_1 && touch d3d10_1.ok d3d10_1.c:723: Test succeeded inside todo block: Failed to get DC, hr 0. d3d10_1.c:732: Test succeeded inside todo block: Failed to release DC, hr 0.

1 0

Re: [2/3] vcomp: Implement _vcomp_reduction_r4 and add tests.
by Henri Verbeet 08 Sep '16

08 Sep '16

On 8 September 2016 at 08:21, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Yes, there are really bool_and and bool_or reduction operations for float/double. > I decided to explicitly write down the comparison with 0.0 in this case because > it otherwise looks like a mistake. According to my tests all values != 0.0 are > seen as true (without any small epsilon to avoid rounding errors... well). > I'd expect it to just look at the bit pattern, but just for laughs, what about -0.0f?

2 1

Re: vcomp: Implement _vcomp_reduction_r4 and add tests. (v2)
by Marvin 08 Sep '16

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

1 0

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus
by Sebastian Lackner 08 Sep '16

08 Sep '16

On 06.09.2016 17:14, Aric Stewart wrote: > v2: Style changes > v4: Updated with corrections from Thomas Faber > > Includes a common function to check if a bus is enabled and a base common > HID IRP_MJ_PNP handler > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/Makefile.in | 5 ++- > dlls/winebus.sys/bus.h | 24 +++++++++++ > dlls/winebus.sys/bus_hid_common.c | 89 +++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/bus_udev.c | 78 ++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 8 +++- > loader/wine.inf.in | 15 +++++-- > 6 files changed, 213 insertions(+), 6 deletions(-) > create mode 100644 dlls/winebus.sys/bus.h > create mode 100644 dlls/winebus.sys/bus_hid_common.c > create mode 100644 dlls/winebus.sys/bus_udev.c > > > > v4-0008-winebus.sys-Add-Linux-udev-bus.txt > > > diff --git a/dlls/winebus.sys/Makefile.in b/dlls/winebus.sys/Makefile.in > index c3e31cc..7e4e97f 100644 > --- a/dlls/winebus.sys/Makefile.in > +++ b/dlls/winebus.sys/Makefile.in > @@ -1,5 +1,8 @@ > MODULE = winebus.sys > +IMPORTS = ntoskrnl > EXTRADLLFLAGS = -Wb,--subsystem,native > > C_SRCS = \ > - main.c > + main.c \ > + bus_hid_common.c \ > + bus_udev.c \ > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > new file mode 100644 > index 0000000..a6f08b2 > --- /dev/null > +++ b/dlls/winebus.sys/bus.h > @@ -0,0 +1,24 @@ > +/* > + * Copyright 2016 Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +/* Busses */ > +NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > + > +/* HID Plug and Play Bus */ > +NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +DWORD check_bus_disabled(UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_hid_common.c b/dlls/winebus.sys/bus_hid_common.c > new file mode 100644 > index 0000000..c98a0dd > --- /dev/null > +++ b/dlls/winebus.sys/bus_hid_common.c It looks like main.c remains almost completely empty after your series. What about adding all common helper functions there? > @@ -0,0 +1,89 @@ > +/* plug and play Bus like functionality for HID busses > + * > + * Copyright 2016 CodeWeavers, Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#define NONAMELESSUNION > +#include <stdarg.h> > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "winternl.h" > +#include "winioctl.h" > +#include "ddk/wdm.h" > +#include "winreg.h" > +#include "setupapi.h" Some of the headers are not really required yet. I would suggest to move them to the patches where they are actually needed. > +#include "regstr.h" > +#include "cfgmgr32.h" > +#include "wine/debug.h" > +#include "wine/unicode.h" > +#include "wine/list.h" > + > +#include "bus.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > + > +NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + NTSTATUS rc = irp->IoStatus.u.Status; > + 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 | OBJ_KERNEL_HANDLE, NULL, NULL); > + if (ZwOpenKey(&key, KEY_ALL_ACCESS, &attr) == STATUS_SUCCESS) > + { > + DWORD size; > + char buffer[sizeof(KEY_VALUE_PARTIAL_INFORMATION) + sizeof(DWORD)]; Not a critical issue, but the buffer size will be one byte too big. For a correct size computation you will have to use something like: char buffer[FIELD_OFFSET( KEY_VALUE_PARTIAL_INFORMATION, Data[sizeof(DWORD] )]; > + KEY_VALUE_PARTIAL_INFORMATION *info = (KEY_VALUE_PARTIAL_INFORMATION*)buffer; > + > + if (ZwQueryValueKey(key, &disabled_str, KeyValuePartialInformation, info, sizeof(buffer), &size) == STATUS_SUCCESS) > + { Please also check the info->Type here. > + disabled = *(DWORD*)info->Data; > + } > + > + ZwClose(key); > + } > + > + return disabled; > +} > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > new file mode 100644 > index 0000000..101bdeb > --- /dev/null > +++ b/dlls/winebus.sys/bus_udev.c > @@ -0,0 +1,78 @@ > +/* Plug and Play support for hid devices found through udev > + * > + * Copyright 2016 CodeWeavers, Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "config.h" > +#include "wine/port.h" > +#include <stdarg.h> > + > +#ifdef HAVE_SYS_IOCTL_H > +# include <sys/ioctl.h> > +#endif > + > +#include <errno.h> > + > +#define NONAMELESSUNION > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windef.h" > +#include "winbase.h" > +#include "winternl.h" > +#include "winioctl.h" > +#include "ddk/wdm.h" > +#include "winnls.h" > +#include "wine/debug.h" > +#include "bus.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +#ifdef SONAME_LIBUDEV > + > +static DRIVER_OBJECT *udev_driver_obj = NULL; > + > +static VOID WINAPI unload(DRIVER_OBJECT *driver) > +{ > + TRACE("Linux udev Driver Unload\n"); > +} > + > +NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + TRACE("Linux udev Driver Init\n"); > + > + udev_driver_obj = driver; > + driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > + driver->DriverUnload = unload; > + > + if (check_bus_disabled(registry_path)) > + { > + TRACE("UDEV plug and play bus disabled in registry\n"); > + return STATUS_SUCCESS; Wouldn't it be better to return an error such that IoCreateDriver() fails? > + } > + > + return STATUS_SUCCESS; > +} > + > +#else > + > +NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) > +{ > + TRACE("Dummy Linux udev Driver Init\n"); > + return STATUS_SUCCESS; Similar to above, wouldn't it be better to return an error? > +} > + > +#endif /* SONAME_LIBUDEV */ > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index d495cd9..4690baf 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -28,11 +28,17 @@ > #include "ddk/wdm.h" > #include "wine/debug.h" > > +#include "bus.h" > + > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > - TRACE( "(%p, %s)\n", driver, debugstr_w(path->Buffer) ); > + static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > + static UNICODE_STRING udev = {sizeof(udevW) - sizeof(WCHAR), sizeof(udevW), (WCHAR*)udevW}; > + > + TRACE( "Wine Platform Bus(%p, %s)\n", driver, debugstr_w(path->Buffer) ); > + IoCreateDriver(&udev, udev_driver_init); > > return STATUS_SUCCESS; > } > diff --git a/loader/wine.inf.in b/loader/wine.inf.in > index 85dbef1..b595693 100644 > --- a/loader/wine.inf.in > +++ b/loader/wine.inf.in > @@ -48,7 +48,8 @@ AddReg=\ > SessionMgr,\ > Tapi,\ > Timezones,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.NT] > RegisterDlls=RegisterDllsSection > @@ -73,7 +74,8 @@ AddReg=\ > Tapi,\ > Timezones,\ > VersionInfo,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.ntamd64] > RegisterDlls=RegisterDllsSection > @@ -100,7 +102,8 @@ AddReg=\ > Tapi,\ > Timezones,\ > VersionInfo.ntamd64,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [Wow64Install] > RegisterDlls=RegisterDllsSection > @@ -115,7 +118,8 @@ AddReg=\ > Misc,\ > Tapi,\ > VersionInfo.ntamd64,\ > - LicenseInformation > + LicenseInformation,\ > + PlatformBus > > [DefaultInstall.Services] > AddService=BITS,0,BITSService > @@ -3397,3 +3401,6 @@ HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-Shanghai-EnableGame",0x1 > HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-Solitaire-EnableGame",0x10001,0x00000001 > HKLM,Software\Wine\LicenseInformation,"Shell-InBoxGames-SpiderSolitaire-EnableGame",0x10001,0x00000001 > HKLM,Software\Wine\LicenseInformation,"Shell-PremiumInBoxGames-Chess-EnableGame",0x10001,0x00000001 > + > +[PlatformBus] > +HKLM,System\CurrentControlSet\Services\UDEV,"Disabled",0x10001,0x00000000 > > >

3 5

Re: [2/3] user32: Add missing calls to GlobalUnlock in render_synthesized_dib.
by Alexandre Julliard 08 Sep '16

08 Sep '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > These seem to be missing, or are they left out intentionally? Other render_*() > functions properly unlock the clipboard data. It's not intentional, I just missed them while moving code around. In practice it doesn't matter because the lock count is not used for anything meaningful, but it's still better to keep them paired. Thanks for catching this! -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: jscript: Do not include terminating \0 in result returned by Date_toLocale{Date, Time}String.
by Marvin 07 Sep '16

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

1 0

Re: jscript: Do not include terminating \0 in result returned by Date_toLocale{Date, Time}String.
by Marvin 07 Sep '16

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

1 0

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.
by Sebastian Lackner 07 Sep '16

07 Sep '16

On 07.09.2016 12:57, Sebastian Lackner wrote: > On 07.09.2016 10:50, Sebastian Lackner wrote: >> From: Sebastian Lackner <sebastian(a)fds-team.de> >> >> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> >> >> v3: Fixed another false compiler warning in String_concat (missed during >> previous review). >> --- >> >> dlls/jscript/array.c | 6 +++--- >> dlls/jscript/date.c | 22 +++++++++++----------- >> dlls/jscript/error.c | 4 ++-- >> dlls/jscript/function.c | 4 ++-- >> dlls/jscript/global.c | 22 +++++++++++----------- >> dlls/jscript/jsregexp.c | 4 ++-- >> dlls/jscript/jsstr.c | 17 +++++++++-------- >> dlls/jscript/jsstr.h | 6 +++--- >> dlls/jscript/number.c | 4 ++-- >> dlls/jscript/object.c | 4 ++-- >> dlls/jscript/string.c | 24 ++++++++++++------------ >> 11 files changed, 59 insertions(+), 58 deletions(-) >> > > Just to make sure that there is no confusion (because of the spoofed From: header), > this version was sent by Jacek and not by me. Thanks for fixing this remaining issue. > > Regards, > Sebastian > Sending to the wine-devel mailing list this time... ;)

2 1

Re: winmm/tests: Pass the full size of MIDIHDR to midiOutPrepareHeader().
by Marvin 07 Sep '16

07 Sep '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=25634 Your paranoid android. === w1064 (32 bit midi) === midi.c:290: Test failed: midiOutOpen(dev=0) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR midi.c:290: Test failed: midiOutOpen(dev=-1) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR === w1064 (64 bit midi) === midi.c:290: Test failed: midiOutOpen(dev=0) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR midi.c:290: Test failed: midiOutOpen(dev=-1) rc=MMSYSERR_ERROR midi.c:489: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR

2 1

Re: [PATCH v3 06/20] configure: Add support for udev
by Sebastian Lackner 07 Sep '16

07 Sep '16

On 02.09.2016 14:16, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > configure | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > configure.ac | 14 +++++++ > include/config.h.in | 6 +++ > 3 files changed, 137 insertions(+) > > > > v3-0006-configure-Add-support-for-udev.txt > > > diff --git a/configure b/configure > index 9808e11..3904a8b 100755 > --- a/configure > +++ b/configure > @@ -652,6 +652,8 @@ FONTCONFIG_CFLAGS > CUPS_CFLAGS > CAPI20_LIBS > CAPI20_CFLAGS > +UDEV_LIBS > +UDEV_CFLAGS > OSS4_CFLAGS > ALSA_LIBS > GSTREAMER_LIBS > @@ -1589,6 +1591,8 @@ GSTREAMER_CFLAGS > GSTREAMER_LIBS > CAPI20_CFLAGS > CAPI20_LIBS > +UDEV_LIBS > +UDEV_CFLAGS > FONTCONFIG_CFLAGS > FONTCONFIG_LIBS > JPEG_CFLAGS > @@ -2273,6 +2277,7 @@ Optional Packages: > --without-sane do not use SANE (scanner support) > --without-tiff do not use TIFF > --without-v4l do not use v4l1 (v4l support) > + --without-udev do not use udev > --without-xcomposite do not use the Xcomposite extension > --without-xcursor do not use the Xcursor extension > --without-xinerama do not use Xinerama (multi-monitor support) > @@ -2342,6 +2347,8 @@ Some influential environment variables: > CAPI20_CFLAGS > C compiler flags for capi20, overriding pkg-config > CAPI20_LIBS Linker flags for capi20, overriding pkg-config > + UDEV_CFLAGS C compiler flags for udev, overriding pkg-config > + UDEV_LIBS Linker flags for udev, overriding pkg-config > FONTCONFIG_CFLAGS > C compiler flags for fontconfig, overriding pkg-config > FONTCONFIG_LIBS > @@ -3543,6 +3550,12 @@ if test "${with_tiff+set}" = set; then : > fi > > > +# Check whether --with-udev was given. > +if test "${with_udev+set}" = set; then : > + withval=$with_udev; > +fi > + > + > # Check whether --with-v4l was given. > if test "${with_v4l+set}" = set; then : > withval=$with_v4l; > @@ -12899,6 +12912,108 @@ esac > enable_wineoss_drv=${enable_wineoss_drv:-no} > fi > > +if test "x$with_udev" != "xno" > +then > + if ${UDEV_CFLAGS:+false} :; then : > + if ${PKG_CONFIG+:} false; then : > + UDEV_CFLAGS=`$PKG_CONFIG --cflags udev 2>/dev/null` > +fi > +fi > + > +if ${UDEV_LIBS:+false} :; then : > + if ${PKG_CONFIG+:} false; then : > + UDEV_LIBS=`$PKG_CONFIG --libs udev 2>/dev/null` > +fi > +fi > + > + > +$as_echo "$as_me:${as_lineno-$LINENO}: udev cflags: $UDEV_CFLAGS" >&5 > +$as_echo "$as_me:${as_lineno-$LINENO}: udev libs: $UDEV_LIBS" >&5 > +ac_save_CPPFLAGS=$CPPFLAGS > +CPPFLAGS="$CPPFLAGS $UDEV_CFLAGS" > +for ac_header in libudev.h > +do : > + ac_fn_c_check_header_mongrel "$LINENO" "libudev.h" "ac_cv_header_libudev_h" "$ac_includes_default" > +if test "x$ac_cv_header_libudev_h" = xyes; then : > + cat >>confdefs.h <<_ACEOF > +#define HAVE_LIBUDEV_H 1 > +_ACEOF > + > +fi > + > +done > + > + if test "$ac_cv_header_libudev_h" = "yes" -a "$ac_cv_header_libudev_h" = "yes" > + then > + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -ludev" >&5 > +$as_echo_n "checking for -ludev... " >&6; } > +if ${ac_cv_lib_soname_udev+:} false; then : > + $as_echo_n "(cached) " >&6 > +else > + ac_check_soname_save_LIBS=$LIBS > +LIBS="-ludev $LIBS" > + cat confdefs.h - <<_ACEOF >conftest.$ac_ext > +/* end confdefs.h. */ > + > +/* Override any GCC internal prototype to avoid an error. > + Use char because int might match the return type of a GCC > + builtin and then its argument prototype would still apply. */ > +#ifdef __cplusplus > +extern "C" > +#endif > +char udev_new (); > +int > +main () > +{ > +return udev_new (); > + ; > + return 0; > +} > +_ACEOF > +if ac_fn_c_try_link "$LINENO"; then : > + case "$LIBEXT" in > + dll) ac_cv_lib_soname_udev=`$ac_cv_path_LDD conftest.exe | grep "udev" | sed -e "s/dll.*/dll/"';2,$d'` ;; > + dylib) ac_cv_lib_soname_udev=`$OTOOL -L conftest$ac_exeext | grep "libudev\\.[0-9A-Za-z.]*dylib" | sed -e "s/^.*\/$libudev\.[0-9A-Za-z.]*dylib$.*$/\1/"';2,$d'` ;; > + *) ac_cv_lib_soname_udev=`$READELF -d conftest$ac_exeext | grep "NEEDED.*libudev\\.$LIBEXT" | sed -e "s/^.*\\[\$libudev\\.$LIBEXT[^ ]*\$\\].*$/\1/"';2,$d'` > + if ${ac_cv_lib_soname_udev:+false} :; then : > + ac_cv_lib_soname_udev=`$LDD conftest$ac_exeext | grep "libudev\\.$LIBEXT" | sed -e "s/^.*$libudev\.$LIBEXT[^ ]*$.*$/\1/"';2,$d'` > +fi ;; > + esac > +fi > +rm -f core conftest.err conftest.$ac_objext \ > + conftest$ac_exeext conftest.$ac_ext > + LIBS=$ac_check_soname_save_LIBS > +fi > +if ${ac_cv_lib_soname_udev:+false} :; then : > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: not found" >&5 > +$as_echo "not found" >&6; } > + > +else > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_soname_udev" >&5 > +$as_echo "$ac_cv_lib_soname_udev" >&6; } > + > +cat >>confdefs.h <<_ACEOF > +#define SONAME_LIBUDEV "$ac_cv_lib_soname_udev" > +_ACEOF > + > + UDEV_LIBS="-ludev" > + > +fi > + fi > +CPPFLAGS=$ac_save_CPPFLAGS > +test -z "$UDEV_CFLAGS" || UDEV_CFLAGS=`echo " $UDEV_CFLAGS" | sed 's/ -I$[^/]$/ -I\$(top_builddir)\/\1/g'` > +test -z "$UDEV_LIBS" || UDEV_LIBS=`echo " $UDEV_LIBS" | sed 's/ -L$[^/]$/ -L\$(top_builddir)\/\1/g'` > + > +fi > +if test "x$ac_cv_lib_soname_udev" = "x"; then : > + case "x$with_udev" in > + x) as_fn_append wine_notices "|libudev ${notice_platform}development files not found, hidraw HID will not be supported." ;; > + xno) ;; > + *) as_fn_error $? "libudev ${notice_platform}development files not found, hidraw HID will not be supported. > +This is an error since --with-udev was requested." "$LINENO" 5 ;; > +esac > +fi > + > if test "x$with_capi" != "xno" > then > if ${CAPI20_CFLAGS:+false} :; then : > @@ -17349,6 +17464,8 @@ ALSA_LIBS = $ALSA_LIBS > OSS4_CFLAGS = $OSS4_CFLAGS > CAPI20_CFLAGS = $CAPI20_CFLAGS > CAPI20_LIBS = $CAPI20_LIBS > +UDEV_CFLAGS = $UDEV_CFLAGS > +UDEV_LIBS = $UDEV_LIBS > CUPS_CFLAGS = $CUPS_CFLAGS > FONTCONFIG_CFLAGS = $FONTCONFIG_CFLAGS > FONTCONFIG_LIBS = $FONTCONFIG_LIBS > diff --git a/configure.ac b/configure.ac > index f02ab98..524777d 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -103,6 +103,7 @@ AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib],[do not use Zlib (data co > > AC_ARG_WITH(wine-tools,AS_HELP_STRING([--with-wine-tools=DIR],[use Wine tools from directory DIR])) > AC_ARG_WITH(wine64, AS_HELP_STRING([--with-wine64=DIR],[use the 64-bit Wine in DIR for a Wow64 build])) > +AC_ARG_WITH(udev, AS_HELP_STRING([--without-udev],[do not use udev])) This list is sorted alphabetically. > > AC_CANONICAL_HOST > > @@ -1519,6 +1520,19 @@ WINE_NOTICE_WITH(oss,[test "x$ac_cv_member_oss_sysinfo_numaudioengines" != xyes] > [OSS sound system found but too old (OSSv4 needed), OSS won't be supported.], > [enable_wineoss_drv]) > > +dnl **** Check for libudev**** There is a space missing before the "****". > +if test "x$with_udev" != "xno" > +then > + WINE_PACKAGE_FLAGS(UDEV,[udev],,,, > + [AC_CHECK_HEADERS([libudev.h]) > + if test "$ac_cv_header_libudev_h" = "yes" -a "$ac_cv_header_libudev_h" = "yes" > + then > + WINE_CHECK_SONAME(udev,udev_new,AC_SUBST(UDEV_LIBS,"-ludev"),,[$UDEV_LIBS]) Do we want to link directly against udev or load it at runtime (wine_dlopen)? For direct linking it would be better to use AC_CHECK_LIB to match the existing configure.ac code (the only exception I've found is OpenAL). For loading at runtime there is no need to define UDEV_LIBS. > + fi]) > +fi > +WINE_NOTICE_WITH(udev,[test "x$ac_cv_lib_soname_udev" = "x"], > + [libudev ${notice_platform}development files not found, hidraw HID not supported.]) > + > dnl **** Check for capi4linux **** > if test "x$with_capi" != "xno" > then > diff --git a/include/config.h.in b/include/config.h.in > index 382beb6..b9f9f19 100644 > --- a/include/config.h.in > +++ b/include/config.h.in > @@ -378,6 +378,9 @@ > /* Define to 1 if you have the <libproc.h> header file. */ > #undef HAVE_LIBPROC_H > > +/* Define to 1 if you have the <libudev.h> header file. */ > +#undef HAVE_LIBUDEV_H > + > /* Define to 1 if you have the <libunwind.h> header file. */ > #undef HAVE_LIBUNWIND_H > > @@ -1466,6 +1469,9 @@ > /* Define to the soname of the libXxf86vm library. */ > #undef SONAME_LIBXXF86VM > > +/* Define to the soname of the libudev library. */ > +#undef SONAME_LIBUDEV > + > /* Define to 1 if the `S_IS*' macros in <sys/stat.h> do not work properly. */ > #undef STAT_MACROS_BROKEN > > > >

1 0

Re: [PATCH v4 3/20] ntoskrnl.exe: Implement loading plug and play devices
by Sebastian Lackner 07 Sep '16

07 Sep '16

On 04.09.2016 03:12, Aric Stewart wrote: > + WCHAR buffer[sizeof(KEY_VALUE_PARTIAL_INFORMATION) + MAX_SERVICE_NAME * sizeof(WCHAR)]; I just noticed that the buffer size is wrong here. It should be something like: char buffer[FIELD_OFFSET( KEY_VALUE_PARTIAL_INFORMATION, Data[MAX_SERVICE_NAME * sizeof(WCHAR)] )]; After this change I am basically fine, but the function is not really used before patch [9/20] in your series. To make sure all pieces work together as expected I would prefer to wait with my signoff until more pieces of winebus have been accepted. By the way, as already mentioned on IRC, there is no need to have all ~20 patches pending on the wine-patches website. It would be better to focus on a small subset of about 5 patches at a time, otherwise it gets really difficult to figure out how they are supposed to apply (126325 fails for example). If you want to share a fully working version, it would be better to provide tarballs on wine-devel imho. Regards, Sebastian

1 0

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.
by Jacek Caban 07 Sep '16

07 Sep '16

Hi Sebastian, The patch looks mostly good, but I get a compiler warning (a false one, but still): In file included from jsval.h:22:0, from jscript.h:377, from array.c:25: array.c: In function ‘array_join’: jsstr.h:109:7: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] if(!--str->ref) ^ array.c:243:25: note: ‘ret’ was declared here jsstr_t **str_tab, *ret; ^ Thanks, Jacek

2 1

Re: [1/2] jscript: Return NULL if jsstr_substr fails.
by Jacek Caban 07 Sep '16

07 Sep '16

Hi Sebastian, I took a deeper look at this. It seems that we have at least two more jsstr_alloc_buf callers to fix (jsstr_concat and JSGlobal_decodeURIComponent). All those seem to be mistakes caused by wrong choice of function signature, requiring not intuitive error handling. I'd prefer to change the root of those problems, making the function: jsstr_t *jsstr_alloc_buf(unsigned,WCHAR**) This should avoid similar mistakes in the future. This will be much larger patch than you originally meant, so please let me know if you'd like to prepare a patch or should I take care of that. Thanks, Jacek

2 3

Re: [PATCH 1/6] ddraw/tests: Add position tests for D3DPROCESSVERTICES_TRANSFORM.
by Henri Verbeet 07 Sep '16

07 Sep '16

On 3 September 2016 at 21:42, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + color = get_surface_color(rt, 18, 18); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); > + color = get_surface_color(rt, 22, 18); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); > + color = get_surface_color(rt, 18, 22); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); ... > + color = get_surface_color(rt, 222, 418); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); > + color = get_surface_color(rt, 218, 422); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); > + color = get_surface_color(rt, 222, 422); > + ok(compare_color(color, 0x00000000, 1), "Got unexpected color %#x\n", color); These fail on Windows here: ddraw1.c:9659: Test failed: Got unexpected color 0xff ddraw1.c:9661: Test failed: Got unexpected color 0xff ddraw1.c:9663: Test failed: Got unexpected color 0xff ddraw1.c:9670: Test failed: Got unexpected color 0xff ddraw1.c:9672: Test failed: Got unexpected color 0xff ddraw1.c:9674: Test failed: Got unexpected color 0xff As an aside, that's also why we usually use 0x%08x for colours.

2 2

Re: [PATCH] ws2_32/tests: Add non-interactive SIO_ADDRESS_LIST_CHANGE tests
by Marvin 07 Sep '16

07 Sep '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=25617 Your paranoid android. === w7pro64 (64 bit sock) === sock.c:7753: Test failed: bytesReturned isn't supposed to be 1 sock.c:7799: Test failed: Waiting for timeout failed with 0 + errno 997

2 1

Re: [v2 PATCH] ws2_32: accept addrlen32 parameter is optional
by Marvin 07 Sep '16

07 Sep '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=25613 Your paranoid android. === w7pro64 (64 bit sock) === sock.c:7765: Test failed: bytesReturned isn't supposed to be 1 sock.c:7811: Test failed: Waiting for timeout failed with 0 + errno 997

1 0

Re: [PATCH] ws2_32: accept addrlelen32 parameter is optional
by Bruno Jesus 07 Sep '16

07 Sep '16

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 06 Sep '16

06 Sep '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=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 06 Sep '16

06 Sep '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=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 06 Sep '16

06 Sep '16

> +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 06 Sep '16

06 Sep '16

> @@ -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 06 Sep '16

06 Sep '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=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 06 Sep '16

06 Sep '16

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 06 Sep '16

06 Sep '16

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 06 Sep '16

06 Sep '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=25567 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH v11 2/3] shell32: Implement FolderItems_Item.
by Marvin 06 Sep '16

06 Sep '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=25566 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH] d3dxof: avoid some strcpy overflows (Coverity)
by Henri Verbeet 06 Sep '16

06 Sep '16

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 05 Sep '16

05 Sep '16

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 05 Sep '16

05 Sep '16

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 05 Sep '16

05 Sep '16

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 05 Sep '16

05 Sep '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=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 05 Sep '16

05 Sep '16

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 03 Sep '16

03 Sep '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=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 03 Sep '16

03 Sep '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=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 03 Sep '16

03 Sep '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=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 03 Sep '16

03 Sep '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=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 03 Sep '16

03 Sep '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=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 03 Sep '16

03 Sep '16

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 03 Sep '16

03 Sep '16

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 02 Sep '16

02 Sep '16

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 02 Sep '16

02 Sep '16

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

Re: [3/3] imm32,user32: Create and destroy the default IME window implicitly. (try 9; resend)
by Sebastian Lackner 02 Sep '16

02 Sep '16

On 23.08.2016 15:13, Akihiro Sagawa wrote: > > Try 9: > - Withdraw try 8 changes as we have ImmDisableIME now. > - Rebased and resolve conflicts against ImmDisableIME patch. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 99 +++++++++++++++++++++++++++++++++++----------- > dlls/imm32/imm32.spec | 1 + > dlls/imm32/tests/imm32.c | 12 +++--- > dlls/user32/misc.c | 4 +- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 26 ++++++++++++ > dlls/user32/win.h | 1 + > 7 files changed, 113 insertions(+), 31 deletions(-) This patch broke various user32 tests in virtual desktop mode, for example: $ (cd dlls/user32/tests/; make broadcast.ok) ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so broadcast && touch broadcast.ok broadcast.c:174: Test failed: Asynchronous message sent instead broadcast.c:152: Test failed: Returned: 0 broadcast.c:153: Test failed: Asynchronous message sent instead broadcast.c:174: Test failed: Asynchronous message sent instead broadcast.c:238: Test failed: Returned: 0 broadcast.c:239: Test failed: Asynchronous message sent instead broadcast.c:257: Test failed: Asynchronous message sent instead broadcast.c:238: Test failed: Returned: 0 broadcast.c:239: Test failed: Asynchronous message sent instead broadcast.c:257: Test failed: Asynchronous message sent instead broadcast.c:298: Test failed: Returned: 0 error 1460 broadcast.c:299: Test failed: Asynchronous message sent instead broadcast.c:309: Test failed: Returned: 0 error 1460 broadcast.c:310: Test failed: Asynchronous message sent instead broadcast.c:320: Test failed: Returned: 0 error 1460 broadcast.c:321: Test failed: Asynchronous message sent instead broadcast.c:332: Test failed: Asynchronous message sent instead make: *** [Makefile:197: broadcast.ok] Fehler 17 Could you please take a look?

2 4

Re: [PATCH 2/2] ole32/tests: Update tests to the new channel hook info structure.
by Huw Davies 02 Sep '16

02 Sep '16

On 2 Sep 2016, at 11:32, Huw Davies <huw(a)codeweavers.com> wrote: > > Also add tests for method number and causality. Please ignore this, I’ve sent a better version that doesn’t trace() garbage when the new structs are in use. Huw.

1 0

Re: [PATCH] winejoystick.drv: Fix long time consuming task of looking for joysticks
by Sebastian Lackner 02 Sep '16

02 Sep '16

On 01.09.2016 05:18, Bruno Jesus wrote: > + joysticks = scandir(p, &files, filter_js, sort_js); Usually malloc-like allocations should be avoided in the Wine source. I am not sure if Alexandre is willing to make an exception in this case because its only a very small amount of memory - nevertheless, replacing with a different directory enumeration mechanism should also not be too difficult. Regards, Sebastian

2 1

Re: user32/tests: Mark a test failure with todo_wine.
by Alexandre Julliard 02 Sep '16

02 Sep '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > I am getting very consistently test failures here: > > clipboard.c:199: Test failed: 0002: seqno unchanged > clipboard.c:199: Test failed: 0082: seqno unchanged > > Also, currently the clipboard tests trigger all kind of other race-conditions > and bugs in winex11. Are you already aware of those issues, Alexandre? Yes, the stricter tests reveal all sorts of issues with the X11 implementation. I'll get to that once the user32 side works correctly. I don't get the above failure though (not that it means much, sequence number support is also fairly broken). -- Alexandre Julliard julliard(a)winehq.org

1 0

Maximum OpenGL version
by Fabian Maurer 02 Sep '16

02 Sep '16

Currently looking at the directx11 implementation, and I noticed I first need to set a "MaxVersionGL" in the registry to enable creation of 4.3 context and so DX11 support. What's the reason behind this? The change is from a1e718ccabc7c330dd16c7face78022965b03e20 (wined3d: Add a setting for the maximum OpenGL version to use). Why do we need to set the maximum version instead of just using the highest context we can get (and still use) ? Fabian Maurer

3 6

Re: [PATCH 3/3] ddraw/tests: Port test_transform_vertices to ddraw2 and ddraw4.
by Marvin 01 Sep '16

01 Sep '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=25522 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/3] ddraw/tests: Test matrices in TransformVertices.
by Marvin 01 Sep '16

01 Sep '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=25521 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/3] ddraw/tests: Make the vec parameter of compare_vec4 const.
by Marvin 01 Sep '16

01 Sep '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=25520 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: Add a simple 3D APIs demo
by Matteo Bruni 01 Sep '16

01 Sep '16

2016-08-19 21:41 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > This adds a 3d-demo wine application. It will allow users to check that their > system can handle at least basic WGL, D3D8 and D3D9 before they need to look > deeper into their problem. > > Signed-off-by: Ruslan Kabatsayev <b7.10110111(a)gmail.com> > --- > configure | 26 +- > configure.ac | 1 + > programs/3d-demo/Makefile.in | 14 + > programs/3d-demo/common.c | 107 ++++++ > programs/3d-demo/common.h | 36 ++ > programs/3d-demo/d3d.c | 605 ++++++++++++++++++++++++++++++++ > programs/3d-demo/d3d8.c | 2 + > programs/3d-demo/d3d9.c | 2 + > programs/3d-demo/demo.rc | 61 ++++ > programs/3d-demo/main.c | 175 +++++++++ > programs/3d-demo/resource.h | 33 ++ > programs/3d-demo/wgl.c | 473 +++++++++++++++++++++++++ > programs/3d-demo/winehq_logo_glass.png | Bin 0 -> 31512 bytes > 13 files changed, 1517 insertions(+), 18 deletions(-) > create mode 100644 programs/3d-demo/Makefile.in > create mode 100644 programs/3d-demo/common.c > create mode 100644 programs/3d-demo/common.h > create mode 100644 programs/3d-demo/d3d.c > create mode 100644 programs/3d-demo/d3d8.c > create mode 100644 programs/3d-demo/d3d9.c > create mode 100644 programs/3d-demo/demo.rc > create mode 100644 programs/3d-demo/main.c > create mode 100644 programs/3d-demo/resource.h > create mode 100644 programs/3d-demo/wgl.c > create mode 100644 programs/3d-demo/winehq_logo_glass.png I have a few pretty generic suggestions. You don't need to include configure changes in the patch, they will be regenerated by Alexandre anyway since those depend on the version of the autotools. Did you look into adding those tests to dxdiag instead of as a separate program? I don't think a separate program is necessarily bad but if integrating into dxdiag is reasonable it's probably better to do that from the start. Avoid camelCase or similar mixed-case identifier styles, just use lowercase_with_underscores. For pointer declarations you want to stick the '*' to the variable, not the type. Also please avoid LPTYPES, just use explicit pointer types. C++ comments (// comment) aren't allowed in Wine sources. Please replace them with normal C comments (/* comment */), or drop them entirely if they don't add anything that isn't clear from just looking at the code. It would be better to use explicit float constants when assigning to float variables (e.g. D3DMATERIAL). There aren't many other general style rules in Wine (it's mostly about using the style already used in the component so for new components you're mostly free to pick your own) as long as there is consistency. I see you mixing space after ',' with no space, pick one (preferably the space variant IMO) and stick to it. We usually use parentheses with the "sizeof" operator in Wine sources, so while it's not strictly required it would probably be nice to follow the general trend. More specific comments: I'd split this over multiple patches. You can probably make an initial patch adding the program with no real functionality, then multiple patches adding the various graphical API demos. In that regard, the d3d8 / d3d9 "merged" handling via macros seems a bit obfuscating to me. Just replicating the code twice seems cleaner. Maybe you can create a few helper functions for the common code. BTW, you can probably make things a bit more structured by moving the main loop to common code and have it call API backend functions. You'd have for each backend a structure like: static const struct render_backend d3d9_backend { d3d9_list_modes, d3d9_init, d3d9_draw, d3d9_wndproc, d3d9_destroy, }; (just an idea WRT the actual functions, I haven't really looked in detail) and you'd pass the structure from the selected API to the "main loop" function. I don't think you're using GLU anymore (good) so you should drop the glu32 import. I haven't looked in detail at the actual demos / renderers but I think there is enough stuff to work on already :)

4 6

Re: [v2] Add a GUI for dxdiag program
by Matteo Bruni 01 Sep '16

01 Sep '16

2016-08-27 10:26 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > This adds a dialog with only System tab, reflecting what save-to-file > functionality currently provides. It can also save the report as file > from the GUI in a way similar to its Windows counterpart. > This version now also shows DMI information which current dxdiagn.dll doesn't > provide, but may do so in the future. Also some spacing issues are fixed. > > Signed-off-by: Ruslan Kabatsayev <b7.10110111(a)gmail.com> > --- > programs/dxdiag/Makefile.in | 3 +- > programs/dxdiag/dxdiag.rc | 64 +++++++++++ > programs/dxdiag/dxdiag_private.h | 9 +- > programs/dxdiag/main.c | 20 ++-- > programs/dxdiag/main_dialog.c | 220 ++++++++++++++++++++++++++++++++++++++ > programs/dxdiag/resource.h | 56 ++++++++++ > 6 files changed, 356 insertions(+), 16 deletions(-) > create mode 100644 programs/dxdiag/main_dialog.c > create mode 100644 programs/dxdiag/resource.h Hi Ruslan, first of all, I think this patch should be splitted. For example, you could split the "save all information" button functionality, together with the common dialog include and dll linkage, to a separate patch. Aside from that, I have some additional comments. I'm not exactly a Win32 GUI expert so I might certainly have missed something significant. Anyway... > diff --git a/programs/dxdiag/Makefile.in b/programs/dxdiag/Makefile.in > index 437cc5e..d971a55 100644 > --- a/programs/dxdiag/Makefile.in > +++ b/programs/dxdiag/Makefile.in > @@ -1,10 +1,11 @@ > MODULE = dxdiag.exe > APPMODE = -mwindows -municode > -IMPORTS = dxguid ole32 oleaut32 user32 > +IMPORTS = dxguid ole32 oleaut32 user32 comdlg32 Keep it sorted alphabetically. > > C_SRCS = \ > information.c \ > main.c \ > + main_dialog.c \ > output.c Formatting. > +IDD_SYSTEM_TAB DIALOG 0, 0, 387, 176 > +STYLE DS_SETFONT | WS_CHILDWINDOW > +FONT 8, "Ms Shell Dlg" > +{ > + GROUPBOX "System Information", IDC_SYSINFO_GROUP, 3, 65, 381, 136, 0, WS_EX_LEFT > + LTEXT "If you know what area is causing the problem, click the appropriate tab above. Otherwise, you can use the ""Next Page"" button below to visit each page in sequence.", IDC_SYSTEMTAB_LABEL1, 9, 37, 344, 17, SS_LEFT, WS_EX_LEFT > + LTEXT "This tool reports information about the DirectX components and drivers installed on your system. It lets you test functionality and diagnose problems.", IDC_SYSTEMTAB_LABEL2, 9, 11, 370, 17, SS_LEFT, WS_EX_LEFT This text seems way too similar to the text in the original application. I'm not sure it adds much, maybe just dropping it entirely is fine? > + RTEXT "Current Date/Time:", IDC_SYSTEMTAB_DATETIME_LABEL, 10, 74, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_DATETIME_VALUE, 153, 74, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Computer name:", IDC_SYSTEMTAB_PCNAME_LABEL, 10, 84, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_PCNAME_VALUE, 153, 84, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Operating System:", IDC_SYSTEMTAB_OS_LABEL, 10, 94, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_OS_VALUE, 153, 94, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Language:", IDC_SYSTEMTAB_LANG_LABEL, 10, 104, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_LANG_VALUE, 153, 104, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "System Manufacturer:", IDC_SYSTEMTAB_VENDOR_LABEL, 10, 114, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_VENDOR_VALUE, 153, 114, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "System Model:", IDC_SYSTEMTAB_MODEL_LABEL, 10, 124, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_MODEL_VALUE, 153, 124, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "BIOS:", IDC_SYSTEMTAB_BIOS_LABEL, 10, 134, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_BIOS_VALUE, 153, 134, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Processor:", IDC_SYSTEMTAB_CPU_LABEL, 10, 144, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_CPU_VALUE, 153, 144, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Memory:", IDC_SYSTEMTAB_RAM_LABEL, 10, 154, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_RAM_VALUE, 153, 154, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "Page File:", IDC_SYSTEMTAB_PAGEFILE_LABEL, 10, 164, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_PAGEFILE_VALUE, 153, 164, 227, 9, SS_LEFT, WS_EX_LEFT > + > + RTEXT "DirectX Version:", IDC_SYSTEMTAB_DXVERSION_LABEL, 10, 174, 140, 9, SS_RIGHT, WS_EX_LEFT > + LTEXT "", IDC_SYSTEMTAB_DXVERSION_VALUE, 153, 174, 227, 9, SS_LEFT, WS_EX_LEFT > + > + AUTOCHECKBOX "Check for WHQL digital signatures", IDC_WHQL_CHECKBOX, 10, 186, 369, 9, 0, WS_EX_LEFT > } Similarly here. Not sure about these, I'd drop the unused entries though. > - WINE_FIXME("Information dialog is not implemented\n"); > + DialogBoxW(hInst,(WCHAR*)MAKEINTRESOURCE(IDD_MAIN),NULL,main_dlg_proc); Space after the commas. Also you don't need to cast, just use MAKEINTRESOURCEW() (see for example notepad/dialog.c). > +extern HINSTANCE hInstance; Please avoid camelcase or hungarian notation. > +extern struct dxdiag_information * dxdiag_info; The '*' should be next to the variable name, as in the preexisting dxdiag sources. > +void set_main_dialog_tab(int new_tab_index) > +{ > + RECT tab_rect; > + POINT top_left, bottom_right; > + const HWND new_tab = main_dialog_tabs[new_tab_index]; > + int tab = 0; > + for(;tab<MAIN_DIALOG_TAB_COUNT;++tab) > + ShowWindow(main_dialog_tabs[tab], SW_HIDE); Please leave a blank line between variable declarations and code. Stick to consistently having a whitespace between the '<' and its operands and after the ';'. Also, but this is probably just my preference, I'd initialize tab to 0 in the "for" instead. > +void main_dialog_insert_tab(int index, int caption_id, int template_id, DLGPROC dlg_proc) > +{ > + WCHAR tab_caption[MAX_STRING_LEN]; > + const TCITEMW tab_item = {.pszText = tab_caption, .mask = TCIF_TEXT}; Designated initializers aren't allowed in C89. > + LoadStringW(hInstance, caption_id, tab_caption, sizeof tab_caption/sizeof tab_caption[0]); Parentheses around the sizeof operand. > +void populate_system_tab(void) > +{ > + const HWND page = main_dialog_tabs[SYSTEM_TAB_INDEX]; > + const struct system_information zeros = {0}; > + const struct system_information*const si = dxdiag_info ? &dxdiag_info->system_info : &zeros; Spaces. > +void save_info_dialog(HWND parent) > +{ > + static const WCHAR filter[] = {'T','e','x','t',' ','f','i','l','e',' ','(','*','.','t','x','t',')',0, '*','.','t','x','t',0, > + 'X','M','L',' ','f','i','l','e',' ','(','*','.','x','m','l',')',0, '*','.','x','m','l',0,0}; > + OPENFILENAMEW ofn = {0}; > + WCHAR filename[MAX_PATH]; > + filename[0] = 0; You can initialize filename right in the definition, like: WCHAR filename[MAX_PATH] = {0}; Actually, do you need to initialize it at all? > + ofn.lStructSize = sizeof ofn; > + ofn.hwndOwner = parent; > + ofn.lpstrFilter = filter; > + ofn.lpstrFile = filename; > + ofn.nMaxFile = MAX_PATH; > + ofn.Flags = OFN_EXPLORER|OFN_HIDEREADONLY|OFN_OVERWRITEPROMPT; Spaces. > +void update_dxdiag_info(void) > +{ > + const HWND checkbox = GetDlgItem(main_dialog, IDC_WHQL_CHECKBOX); > + const HWND save_all_button = GetDlgItem(main_dialog, IDC_SAVE_INFO); > + const BOOL check_whql = SendMessageW(checkbox, BM_GETCHECK, 0L, 0L) == BST_CHECKED; > + free_dxdiag_information(dxdiag_info); > + dxdiag_info = collect_dxdiag_information(check_whql); > + /* update the dialog before showing error message */ > + populate_tabs(); > + if(!dxdiag_info) Nitpick, space after "if". > +INT_PTR CALLBACK system_tab_proc(HWND hsystab, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + switch(msg) > + { > + case WM_COMMAND: > + switch(HIWORD(wparam)) > + { > + case BN_CLICKED: > + switch(wparam) > + { > + case IDC_WHQL_CHECKBOX: > + { > + update_dxdiag_info(); > + return TRUE; > + } > + } This looks pretty ugly. You don't need a separate block inside the case so you can just drop the inner braces. Actually I don't think you're ever going to have other buttons in the system tab so the switch seems unnecessary.

2 3

Re: Bruno Jesus : xinput1_3: Stub XInputGetStateEx.
by Huw Davies 01 Sep '16

01 Sep '16

On 1 Sep 2016, at 15:55, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: 0fe758046ddc0f37944b8a3e075b8a5fdc5d81a4 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=0fe758046ddc0f37944b8a3e0… > > Author: Bruno Jesus <00cpxxx(a)gmail.com> > Date: Wed Aug 31 15:17:44 2016 -0300 > > xinput1_3: Stub XInputGetStateEx. > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> > + if (pXInputGetStateEx_Ordinal) > + ok (pXInputGetStateEx_Ordinal == pXInputGetStateEx, "XInputGetStateEx in the wrong ordinal\n"); > + else > + ok (broken(1), "XInputGetStateEx not found in this dll version\n”) Hi Bruno, This is causing test failures: https://testbot.winehq.org/JobDetails.pl?Key=25476 https://test.winehq.org/data/tests/xinput1_3:xinput.html Could you take a look? Thanks, Huw.

2 1

Experimental gcc optimization for 64-bit wine
by Daniel Santos 01 Sep '16

01 Sep '16

Over the last two weeks I've been working on an experimental gcc optimization for wine that out-of-lines the expensive prologues & epilogues required for an ms x64 abi function to call a 64-bit sysv function. The theory is that the added expense of each function executing a few extra instructions to facilitate this will be offset by the reduction in instruction cache misses. As far as I can tell, gcc's ix86 back end has never supported any type of out-of-line pro/epilogue stubs, so adding this support has been somewhat tedious as it tends to get broken by subsequent optimization passes. It currently works in many cases, but in other cases produces bad code so this is a work in progress. None the less, I thought it was interesting enough to post the current results in terms of .text size reduction. On gcc 5.4.0 (with the 8-byte aligned stack assumption flaw corrected), the total .text size of all dlls on my build was 45.2MiB while the out-of-lined build was 35.9MiB, a reduction of 20.5%, so it looks promising so far. I presume it will be a little while before all of the flaws are worked out so that it always produces good code, but once there I can start to produce some real performance numbers. It's probably also worth mentioning that the ideal long-term solution is to find ways eliminate the register save/restores through various means-- static analysis, better evaluation of branch costs, and other optimizations in Wine its self. For example, there are many WINAPI functions who's only sysv call is to wine_dbg_log() via a TRACE(). Just marking this function as __attribute__((__cold__)) should reduce the number of unneeded register save/restores in the function's main path by a great amount. (I haven't actually tested it yet.) Daniel

2 3

Re: wintrust/tests: Fix test for pfnAddSgnr2Chain.
by Marvin 01 Sep '16

01 Sep '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=25506 Your paranoid android. === w864 (32 bit softpub) === softpub: unhandled exception c0000005 at 77723ED2 === w1064 (32 bit softpub) === softpub: unhandled exception c0000005 at 768AC81B === w864 (64 bit softpub) === softpub: unhandled exception c0000005 at 00007FFB7AFF266C === w1064 (64 bit softpub) === softpub.c:254: Test failed: Expected S_OK, got 00000001 softpub.c:257: Test failed: Expected S_OK, got 00000001 softpub: unhandled exception c0000005 at 00007FFC77A79A5D

1 0

Re: rpcrt4/tests: Remove an unnecessary and confusing message.
by Marvin 01 Sep '16

01 Sep '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=25500 Your paranoid android. === w864 (32 bit rpc) === rpc.c:812: Test failed: GUID does not appear to contain a MAC address: {f03f0f60-7046-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:812: Test failed: GUID does not appear to contain a MAC address: {ab19995e-7047-11e6-be78-e71666c2e04a}

1 0

Re: [PATCH] msctf/tests: Return interface pointers instead of pointers to impl structure
by Marvin 01 Sep '16

01 Sep '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=25492 Your paranoid android. === w864 (64 bit inputprocessor) === inputprocessor.c:831: Test failed: Deactivation came unexpectedly

2 1

Re: [PATCH 5/5] ddraw/tests: Extend TransformVertices invalid data tests.
by Marvin 01 Sep '16

01 Sep '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=25491 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: ntoskrnl.exe: Stub IoInvalidateDeviceRelations.
by Aric Stewart 01 Sep '16

01 Sep '16

On 9/1/16 2:28 AM, Sebastian Lackner wrote: > From: Aric Stewart <aric(a)codeweavers.com> > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > After we have reduced the size of the implementation a lot, it feels a bit > unnecessary to add a separate pnp_manager.c file. > > @ Aric: Are you fine with this change, or do you have significantly more > PnP work after those initial four patches? > I am find with it being in ntoskrnl.c if that is the decision as to what is best. It does affect the rest of the patch set so if this is where Alexandre agree it should go then that would be useful to get committed so that I can rebase the rest. Also one of my earlier patches (125976) has an implementation of get_device_id in ntoskrnl.c which of course can be replace by the version in this set of patches. -aric > For patch 2 I have some more feedback which I will reply separately. > > dlls/ntoskrnl.exe/ntoskrnl.c | 10 ++++++++++ > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- > include/ddk/wdm.h | 1 + > 3 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c > index a2cbb74..507ffdd 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.c > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c > @@ -4,6 +4,7 @@ > * Copyright (C) 2007 Alexandre Julliard > * Copyright (C) 2010 Damjan Jovanovic > * Copyright (C) 2016 Sebastian Lackner > + * Copyright (C) 2016 CodeWeavers, Aric Stewart > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -2788,3 +2789,12 @@ done: > CloseServiceHandle( service_handle ); > return status; > } > + > + > +/*********************************************************************** > + * IoInvalidateDeviceRelations (NTOSKRNL.EXE.@) > + */ > +void WINAPI IoInvalidateDeviceRelations( DEVICE_OBJECT *device_object, DEVICE_RELATION_TYPE type ) > +{ > + FIXME( "(%p, %i): stub\n", device_object, type ); > +} > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 5408e91..1c4d08f 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -400,7 +400,7 @@ > @ stdcall IoInitializeIrp(ptr long long) > @ stdcall IoInitializeRemoveLockEx(ptr long long long long) > @ stdcall IoInitializeTimer(ptr ptr ptr) > -@ stub IoInvalidateDeviceRelations > +@ stdcall IoInvalidateDeviceRelations(ptr long) > @ stub IoInvalidateDeviceState > @ stub IoIsFileOriginRemote > @ stub IoIsOperationSynchronous > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 68694af..0024968 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1234,6 +1234,7 @@ PVOID WINAPI IoGetDriverObjectExtension(PDRIVER_OBJECT,PVOID); > PDEVICE_OBJECT WINAPI IoGetRelatedDeviceObject(PFILE_OBJECT); > void WINAPI IoInitializeIrp(IRP*,USHORT,CCHAR); > VOID WINAPI IoInitializeRemoveLockEx(PIO_REMOVE_LOCK,ULONG,ULONG,ULONG,ULONG); > +void WINAPI IoInvalidateDeviceRelations(PDEVICE_OBJECT,DEVICE_RELATION_TYPE); > NTSTATUS WINAPI IoWMIRegistrationControl(PDEVICE_OBJECT,ULONG); > > PKTHREAD WINAPI KeGetCurrentThread(void); >

1 0

Re: [PATCH 3/5] ddraw: Fix offscreen flag handling in TransformVertices.
by Marvin 01 Sep '16

01 Sep '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=25490 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). The test timed out

1 0

Re: [PATCH 2/5] ddraw: Copy extra vertex data in viewport::TransformVertices.
by Marvin 01 Sep '16

01 Sep '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=25489 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/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c (v2).
by Marvin 01 Sep '16

01 Sep '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=25488 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === 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 3/4] xinput1_3: Stub XInputGetStateEx
by Marvin 01 Sep '16

01 Sep '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=25476 Your paranoid android. === wxppro (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w2003std (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === wvistau64 (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w8 (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w864 (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w1064 (32 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === wvistau64 (64 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w864 (64 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal === w1064 (64 bit xinput) === xinput.c:242: Test failed: XInputGetStateEx in the wrong ordinal

1 0

Re: [PATCH v2 2/4] ntoskrnl.exe: Implement loading plug and play devices
by Sebastian Lackner 01 Sep '16

01 Sep '16

On 31.08.2016 18:38, Aric Stewart wrote: > v2: No longer maintaining a device store > Suggestions from Sebastian Lackner > > We are not handling installing drivers just yet, so we 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 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 specify a [Service] value representing > the driver. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/pnp_manager.c | 196 +++++++++++++++++++++++++++++++++++++++- > include/ddk/wdm.h | 3 +- > 2 files changed, 197 insertions(+), 2 deletions(-) > > > > v2-0002-ntoskrnl.exe-Implement-loading-plug-and-play-device.txt > > > diff --git a/dlls/ntoskrnl.exe/pnp_manager.c b/dlls/ntoskrnl.exe/pnp_manager.c > index 7ebd07d..04b218b 100644 > --- a/dlls/ntoskrnl.exe/pnp_manager.c > +++ b/dlls/ntoskrnl.exe/pnp_manager.c > @@ -17,6 +17,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#define NONAMELESSUNION > #include <stdarg.h> > #include "ntstatus.h" > #define WIN32_NO_STATUS > @@ -24,14 +25,207 @@ > #include "winbase.h" > #include "winternl.h" > #include "ddk/wdm.h" > +#include "wine/unicode.h" > #include "wine/debug.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > +#define MAX_SERVICE_NAME 260 > + > +static NTSTATUS WINAPI internal_complete(DEVICE_OBJECT *deviceObject, 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; > + > + IoCallDriver(device, irp); > + > + if (irp->IoStatus.u.Status == STATUS_PENDING) > + WaitForSingleObject(event, INFINITE); > + > + 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; > + > + irp = IoBuildSynchronousFsdRequest(IRP_MJ_PNP, device, NULL, 0, NULL, NULL, &irp_status); > + if (irp == NULL) > + return STATUS_NO_MEMORY; > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->MinorFunction = IRP_MN_QUERY_ID; > + irpsp->Parameters.QueryId.IdType = type; > + return send_device_irp(device, irp, (ULONG_PTR*)id); > +} > + > +static NTSTATUS find_driver_for_id(const WCHAR *id, WCHAR *driver) > +{ > + NTSTATUS rc; > + 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}; > + > + HANDLE hkey; > + WCHAR *regW; > + UNICODE_STRING key; > + OBJECT_ATTRIBUTES attr; > + > + regW = HeapAlloc(GetProcessHeap(), 0, sizeof(critical_fmtW) + strlenW(id) * sizeof(WCHAR)); > + sprintfW(regW, critical_fmtW, id); > + RtlInitUnicodeString(&key, regW); > + > + InitializeObjectAttributes(&attr, &key, OBJ_CASE_INSENSITIVE, NULL, NULL); > + rc = ZwOpenKey(&hkey, KEY_ALL_ACCESS, &attr); > + if (rc == STATUS_SUCCESS) > + { > + static const WCHAR serviceW[] = {'S','e','r','v','i','c','e',0}; > + static const UNICODE_STRING serviceStr = {sizeof(serviceW) - sizeof(WCHAR), sizeof(serviceW), (WCHAR*)serviceW}; > + KEY_VALUE_PARTIAL_INFORMATION *info; > + DWORD total_size = sizeof(*info) + MAX_SERVICE_NAME * sizeof(WCHAR); > + > + info = HeapAlloc(GetProcessHeap(), 0, total_size); > + > + rc = ZwQueryValueKey(hkey, &serviceStr, KeyValuePartialInformation, info, total_size, &total_size); > + if (rc == STATUS_SUCCESS && info->Type == REG_SZ && info->DataLength < MAX_SERVICE_NAME * sizeof(WCHAR)) > + { > + WCHAR *service = (WCHAR*)info->Data; > + TRACE("Got service %s\n",debugstr_w(service)); > + strcpyW(driver, service); > + } > + else > + { > + if (info->Type != REG_SZ) > + ERR("Failed to get Service from registry entry, Bad type\n"); > + else if (info->DataLength >= MAX_SERVICE_NAME * sizeof(WCHAR)) > + ERR("Failed to get Service from registry entry, Buffer too small\n"); > + else > + ERR("Failed to get Service from registry entry (%x)\n",rc); I don't think it makes sense to trace this an error, especially when you use a TRACE for the lack of a critical device database key. > + } > + HeapFree(GetProcessHeap(), 0, info); > + ZwClose(hkey); > + } > + else > + TRACE("Failed to find Critical Device Database entry for %s\n",debugstr_w(id)); > + HeapFree(GetProcessHeap(), 0, regW); > + return rc; > +} > + > +static void handle_bus_relations(DEVICE_OBJECT *device) > +{ > + static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > + static const WCHAR servicesW[] = {'\\','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', > + '\\','S','e','r','v','i','c','e','s', > + '\\',0}; > + > + NTSTATUS status; > + WCHAR *id, *idptr; > + WCHAR driver[MAX_SERVICE_NAME] = {0}; > + WCHAR fullname[MAX_PATH]; > + DRIVER_OBJECT *driver_obj; > + UNICODE_STRING driverName; > + WCHAR driverKey[MAX_PATH]; > + UNICODE_STRING driverPath; You'll have to allocate bigger buffers for the concatenated strings. In fact, a single buffer should be sufficient for both the fullname and the driver key. > + > + TRACE("Device %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, &id); > + if (status != ERROR_SUCCESS || !id) > + { > + ERR("Failed to get device IDs\n"); > + return; > + } > + > + idptr = id; > + while(*idptr != 0) > + { > + TRACE("Checking for id %s\n",debugstr_w(idptr)); > + if (find_driver_for_id(idptr, driver) == STATUS_SUCCESS) > + break; > + idptr += (strlenW(idptr) + 1); > + } > + HeapFree(GetProcessHeap(), 0, id); > + > + if (!driver[0]) > + { > + ERR("No matching driver found for device\n"); > + return; > + } > + > + strcpyW(driverKey, servicesW); > + strcatW(driverKey, driver); > + RtlInitUnicodeString(&driverPath, driverKey); > + if (ZwLoadDriver(&driverPath) != STATUS_SUCCESS) > + { > + ERR("Failed to load driver %s\n", debugstr_w(driver)); > + return; > + } > + > + strcpyW(fullname, driverW); > + strcatW(fullname, driver); > + RtlInitUnicodeString(&driverName, fullname); > + if (ObReferenceObjectByName(&driverName, OBJ_CASE_INSENSITIVE, NULL, > + 0, NULL, KernelMode, NULL, (void**)&driver_obj) != STATUS_SUCCESS) > + { > + ERR("Failed to locate loaded driver %s\n", debugstr_w(driver)); > + return; > + } > + > + if (!driver_obj->DriverExtension->AddDevice) > + status = STATUS_NOT_IMPLEMENTED; > + else > + status = driver_obj->DriverExtension->AddDevice(driver_obj, device); > + > + ObDereferenceObject(driver_obj); > + > + if (status != STATUS_SUCCESS) > + ERR("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); > + } > } > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index bd3b323..e893ba2 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -48,6 +48,7 @@ typedef NTSTATUS (WINAPI *PDRIVER_INITIALIZE)(struct _DRIVER_OBJECT *, PUNICODE_ > typedef NTSTATUS (WINAPI *PDRIVER_DISPATCH)(struct _DEVICE_OBJECT *, struct _IRP *); > typedef void (WINAPI *PDRIVER_STARTIO)(struct _DEVICE_OBJECT *, struct _IRP *); > typedef void (WINAPI *PDRIVER_UNLOAD)(struct _DRIVER_OBJECT *); > +typedef NTSTATUS (WINAPI *PDRIVER_ADD_DEVICE)(struct _DRIVER_OBJECT *, struct _DEVICE_OBJECT *); > > typedef struct _DISPATCHER_HEADER { > UCHAR Type; > @@ -336,7 +337,7 @@ typedef struct _DEVICE_RELATIONS *PDEVICE_RELATIONS; > > typedef struct _DRIVER_EXTENSION { > struct _DRIVER_OBJECT *DriverObject; > - PVOID AddDevice; > + PDRIVER_ADD_DEVICE AddDevice; > ULONG Count; > UNICODE_STRING ServiceKeyName; > } DRIVER_EXTENSION, *PDRIVER_EXTENSION; > > >

1 0

Re: [PATCH 2/2] winhttp: Also pass hostname to jsproxy
by Nikolay Sivov 31 Aug '16

31 Aug '16

On 31.08.2016 22:21, Andrew Eikum wrote: > > +static inline char *strdupWA_sized( const WCHAR *src, DWORD size ) > +{ > + char *dst = NULL; > + if (src) > + { > + int len = WideCharToMultiByte( CP_ACP, 0, src, size, NULL, 0, NULL, NULL ) + 1; > + if ((dst = heap_alloc( len ))) > + { > + WideCharToMultiByte( CP_ACP, 0, src, len, dst, size, NULL, NULL ); > + dst[len - 1] = 0; > + } > + } > + return dst; > +} > + This is usually called strndup* in Wine dlls. Also 'len' and 'size' seem to be misplaced, and I'm not sure it will do the right thing if for negative size, unless it's not meant to ever be negative.

1 0

Re: [PATCH 1/4] xinput1_3: Better trace all functions
by Sebastian Lackner 31 Aug '16

31 Aug '16

On 31.08.2016 20:17, Bruno Jesus wrote: > - FIXME("(%d %p %p) Stub!\n", dwUserIndex, pDSoundRenderGuid, pDSoundCaptureGuid); > + FIXME("(index %u, render guid %p, capture guid %p) Stub!\n", index, render_guid, capture_guid); debugstr_guid() would be more appropriate for tracing GUIDs.

2 2

How to find out the source code function from compiled running address
by Bruno Jesus 31 Aug '16

31 Aug '16

Hi all. While trying to run a crashing application I used a debugger and found out the crash is inside wined3d, I then started looking for ways to convert that address back into what function it should be so I can breakpoint it and check. At first I got into http://www.nirsoft.net/utils/dll_export_viewer.html and it looked like what I needed but the program does not seem to work in Wine DLLs. Adding +d3d,+relay and checking the calls is awfully verbose, but I'm still trying it. Part of the function showing the addresses, last line crashes: wined3d.dll:7EBCEF19 mov eax, [ebp+8] wined3d.dll:7EBCEF1C mov eax, [eax+0EC54h] wined3d.dll:7EBCEF22 mov edx, [ebp-0Ch] wined3d.dll:7EBCEF25 shl edx, 2 wined3d.dll:7EBCEF28 add eax, edx wined3d.dll:7EBCEF2A mov eax, [eax] Is there anyway to find out where is this function in the source code? Best regards, Bruno

3 3

Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath
by Vincent Povirk 31 Aug '16

31 Aug '16

We really need an implementation that doesn't rely on gdi32.

2 6

Re: [PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.
by Sebastian Lackner 31 Aug '16

31 Aug '16

On 30.08.2016 21:30, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 40 ++++++++-------------------------------- > 1 file changed, 8 insertions(+), 32 deletions(-) > Wouldn't it be better to use a macro similar to LIST_INIT() for that (to allow later changes of the internal structure)?

2 2

Re: [2/8] webservices: Implement WsAddCustomHeader.
by Sebastian Lackner 31 Aug '16

31 Aug '16

On 31.08.2016 14:35, Hans Leidekker wrote: > + if (WsXmlStringEquals( desc->elementLocalName, &msg->header[i]->name, NULL ) && > + WsXmlStringEquals( desc->elementNs, &msg->header[i]->ns, NULL ) == S_OK) This looks suspicious because it does not match the follow up patch. are you missing a == S_OK maybe?

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