September 2016 - Wine-Devel

Re: winmm/tests: Remove a test that can crash on Win 8 and 10.
by Marvin Sept. 14, 2016

Sept. 14, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 13, 2016

Sept. 13, 2016

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 Sept. 13, 2016

Sept. 13, 2016

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 Sept. 13, 2016

Sept. 13, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 13, 2016

Sept. 13, 2016

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 Sept. 12, 2016

Sept. 12, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 12, 2016

Sept. 12, 2016

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 Sept. 12, 2016

Sept. 12, 2016

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 Sept. 12, 2016

Sept. 12, 2016

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 Sept. 11, 2016

Sept. 11, 2016

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 Sept. 11, 2016

Sept. 11, 2016

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 Sept. 11, 2016

Sept. 11, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 11, 2016

Sept. 11, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 11, 2016

Sept. 11, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 11, 2016

Sept. 11, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 10, 2016

Sept. 10, 2016

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 Sept. 10, 2016

Sept. 10, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 10, 2016

Sept. 10, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 9, 2016

Sept. 9, 2016

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 Sept. 9, 2016

Sept. 9, 2016

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 Sept. 9, 2016

Sept. 9, 2016

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 Sept. 9, 2016

Sept. 9, 2016

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 Sept. 8, 2016

Sept. 8, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 8, 2016

Sept. 8, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Sept. 8, 2016

Sept. 8, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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