September 2016 - Wine-Devel

RE: [PATCH] make_unicode: Change handling of Turkish i to match Windows

by Daniel Lehman

>> 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. >> >I could imagine LCMAP_LINGUISTIC_CASING making a difference here. Windows' LCMapString behaves differently but only if LCMAP_LINGUISTIC_CASING is specified. if that flag is not specified, it works just like tolower/toupper Wine's LCMapString currently calls tolowerW and doesn't support the LCMAP_LINGUISTIC_CASING flag. But the current table contains the conversions the LCMAP_LINGUISTIC_CASING flag needs if added in the future Should I change the fix to something like one of the following? Or just add tests with todo_wine for now? I could have msvcrt tolower call LCMapString(LOWERCASE)? Then: - LCMapString(LOWERCASE|CASING) calls the current tolowerW with the conversion - LCMapString(LOWER) calls tolowerW except on certain characters (like Turkish i) - msvcrt tolower variants call LCMapString(LOWER) Or alternatively could there be new tolowerW function that doesn't do the conversion (maybe from a second table make_unicode produces)? Then: - LCMapString(LOWERCASE|CASING) call the current tolowerW with the conversion - LCMapString(LOWERCASE) and msvcrt tolower variants call new tolowerW without the conversion This patch was for the Turkish I but I have 1 other character with the same issue and I'm sure there are more Thanks daniel

Sept. 30, 2016

Re: [PATCH] make_unicode: Change handling of Turkish i to match Windows

by Henri Verbeet

On 30 September 2016 at 14:23, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > 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. > I could imagine LCMAP_LINGUISTIC_CASING making a difference here.

Sept. 30, 2016

Re: [PATCH] make_unicode: Change handling of Turkish i to match Windows

by Dmitry Timoshkov

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.

Sept. 30, 2016

Re: [PATCH v6] winebus.sys: Watch for hid raw device addition and removal

by Aric Stewart

Thanks for the review, just 1 comment On 9/29/16 2:44 PM, Sebastian Lackner wrote: > 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 . . . >> -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. This was mostly because I know that when a memory address is freed wine can give out the same address quite easily. I was unsure how robust our device deletion creation process was for identically named devices so I wanted to add just that one more element of uniqueness so as to avoid this possible problem. I am sure just using native would exhibit the same potential issues. -aric > >> 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; >> >> >> >

Sept. 30, 2016

Some code ambiguity in tab control code.

by John Found

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>

Sept. 29, 2016

Re: [PATCH v6] winebus.sys: Watch for hid raw device addition and removal

by Sebastian Lackner

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; > > >

Sept. 29, 2016

Re: uianimation: add stub dll

by Alexandre Julliard

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

Sept. 28, 2016

Re: shell32/tests: Move test after return

by Alexandre Julliard

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

Sept. 28, 2016

Re: [10/11] kernel32: Implement LCMAP_FULLWIDTH.

by Alexandre Julliard

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

Sept. 28, 2016

Re: [PATCH 5/5] wined3d: Call glGetIntegerv() through the gl_info function pointer.

by Józef Kucia

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.

Sept. 27, 2016

Re: [PATCH v2 1/5] wined3d: Use round() on core profile.

by Henri Verbeet

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.

Sept. 27, 2016

Re: [PATCH] wined3d: Add NVIDIA GTX 675MX to the GPU list.

by Filip Frackiewicz

Understood. I was following the other examples in the code but I will follow your advice for future patches. Thanks again! On Mon, Sep 26, 2016 at 1:30 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 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.

Sept. 26, 2016

Re: [PATCH] wined3d: Add NVIDIA GTX 980 Ti to the GPU list.

by Filip Frackiewicz

Will do, apologies for the hassle and thanks for the constructive feedback :) On Mon, Sep 26, 2016 at 1:30 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 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.

Sept. 26, 2016

Re: [PATCH] wined3d: Add NVIDIA GTX 675MX to the GPU list.

by Henri Verbeet

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.

Sept. 26, 2016

Re: [PATCH] wined3d: Add NVIDIA GTX 980 Ti to the GPU list.

by Henri Verbeet

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.

Sept. 26, 2016

Re: Ancient Parallel Port PIC Programmer - support under newer versions of Wine?

by Alex Henrie

2016-09-24 20:18 GMT-06:00 Bob Wya <bob.mt.wya(a)gmail.com>: > 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? If the program is calling CreateFile("COM1", ...) then symlinks should work fine. If the program is trying to read from or write to the address of the parallel port in memory, you can write a small wrapper to call ioperm and execvp. For example, the following "ioperm" program grants access to the system speaker and calls the "beep" program which plays a tone for 1 second: ---ioperm.c--- #include <stdio.h> #include <sys/io.h> #include <unistd.h> int main(int argc, char* argv[]) { if (ioperm(0x42, 0x61 - 0x42 + 1, 1) == -1) { perror("ioperm"); return 1; } if (execvp(argv[1], argv + 1) == -1) { perror("execvp"); return 1; } return 0; } ---beep.c--- #include <stdio.h> #include <unistd.h> int main() { __asm__("movb $0xB6, %al\n" "outb %al, $0x43\n" "inb $0x61, %al\n" "orb $0x03, %al\n" "outb %al, $0x61\n" "movb $0x64, %al\n" "outb %al, $0x42\n" "movb $0x01, %al\n" "outb %al, $0x42\n"); sleep(1); __asm__("inb $0x61, %al\n" "andb $0xFC, %al\n" "outb %al, $0x61\n"); return 0; } ---compile and run--- cc ioperm.c -o ioperm i686-w64-mingw32-cc beep.c -o beep.exe sudo setcap cap_sys_rawio=ep ioperm ./ioperm wine beep.exe I hope this helps. -Alex

Sept. 25, 2016

Ancient Parallel Port PIC Programmer - support under newer versions of Wine?

by Bob Wya

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

Sept. 25, 2016

Re: [PATCH 1/5] wined3d: Use round() on core profile.

by Henri Verbeet

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().

Sept. 23, 2016

Re: [PATCH 5/5] api-ms-win-service-winsvc-l1-1-0: add dll

by Sebastian Lackner

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?

Sept. 22, 2016

Re: [11/11] kernel32: Implement LCMAP_HALFWIDTH.

by Marvin

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 ''

Sept. 22, 2016

Re: [10/11] kernel32: Implement LCMAP_FULLWIDTH.

by Marvin

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 ''

Sept. 22, 2016

Re: [09/11] kernel32: Implement LCMAP_KATAKANA.

by Marvin

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 ''

Sept. 22, 2016

Re: [08/11] kernel32: Implement LCMAP_HIRAGANA.

by Marvin

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 ''

Sept. 22, 2016

Re: [05/11] kernel32/tests: Add more mapping tests for LCMapString.

by Marvin

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 ''

Sept. 22, 2016

Re: [04/11] kernel32/tests: Add LCMAP_TITLECASE test.

by Marvin

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 ''

Sept. 22, 2016

Re: [03/11] kernel32: Zero is an invalid flag value.

by Marvin

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 ''

Sept. 22, 2016

Re: [02/11] kernel32: Do not allow to combine NORM_IGNORENONSPACE and/or NORM_IGNORESYMBOLS with other LCMAP flags.

by Marvin

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 ''

Sept. 22, 2016

Re: [01/11] kernel32/tests: Consolidate duplicated code for invalid LCMapString flag tests.

by Marvin

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 ''

Sept. 22, 2016

Re: [PATCH v3] winebus.sys: Watch for hid raw device addition and removal

by Aric Stewart

On 9/21/16 5:59 AM, Sebastian Lackner wrote: > 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? > Sure, Here is the full patchset for hidraw. https://www.codeweavers.com/xfer/aric/HID/Hid_Patches_20160921.tgz access-code: sLcm7EZ7 I did not include the iohid and linux event patches in that given set as I know they still need cleaning up and I am working on that. Also many of the later patches probably still need some cleaning up. -aric >> >> >> 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; >> >> >> >

Sept. 21, 2016

Re: [PATCH v3] winebus.sys: Watch for hid raw device addition and removal

by Sebastian Lackner

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; > > >

Sept. 21, 2016

Re: [PATCH 3/7] wined3d: Implement the initial texture data upload on top of wined3d_device_update_sub_resource().

by Henri Verbeet

On 21 September 2016 at 01:26, Michael Müller <michael(a)fds-team.de> wrote: > Didn't this break the initial upload for 3d textures as > wined3d_device_update_sub_resource only supports buffers and 2d textures? > Yeah, it might, in as far that anything that uses that currently works. Shouldn't be terribly hard to fix though.

Sept. 21, 2016

Re: [PATCH 3/7] wined3d: Implement the initial texture data upload on top of wined3d_device_update_sub_resource().

by Michael Müller

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?

Sept. 20, 2016

Re: d3d9/tests: Allow D3D_OK for lost device present (Win10)

by Marvin

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.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Fabian Maurer

Just to make this clear, this patch was my example on how to implement the dx11 functions with d3dx9 code: > Fabian, if you want to send patches for > D3DX11CreateShaderResourceViewFromFileW "duplicating" the relevant > code for the time being, that is fine to me. It might even be easier > to decide how to share the code at that point. My plan was to pull the code out of of d3dx9, make it generic and put it into a place where both d3dx11 and d3dx9 can use it. Once these helpers worked with d3dx9, I'd implement the d3dx11 functions using them. This patch series was a working implementation - like you wanted to see - which duplicates the relevant code so I would know how to share it between versions. But now we're mostly at "write it from scratch". It's fine if you'd rather want a complete rewrite instead of copy&paste with modifications, but I think I made it pretty clear from the beginning this wasn't my intention. I'd make the generic helpers less "hacky" or rewrite parts of them, but I fear I'm not the person to do a good complete rewrite of all this.

Sept. 20, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 21:43:14 +0300 Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Hi, John. > > Please open a bug report and attach sample application code there or at > least a relevant part of it, so we can turn it into a test. Workarounds are > not interesting for Wine. > Bug submitted: #41370; With links to the source code revealing it. Your turn, dear WINE developers. :) Best regards. P.S. I actually found some workaround - simply to not use TTM_GETCURRENTTOOL and to identify the tool only by the NMHDR.idFrom received in the notification. :P -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 20, 2016

Re: oleaut32: Handle xbuf_get erroring out in deserialize_param (and avoid uninitialized read).

by Dmitry Timoshkov

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.

Sept. 20, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Henri Verbeet

On 20 September 2016 at 02:59, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > functions. In theory you could even use native d3dx11 on Wine, > although that might give some misleading results e.g. if Wine's d3d11 > isn't quite doing the right thing. > And you'd have to be careful not to look at e.g. +d3d11 traces when doing that, so I'd recommend against it.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Matteo Bruni

2016-09-20 2:35 GMT+02:00 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. > > I somewhat doubt it. It wasn't too hard to use the d3dx9 parts for d3dx11 And that's exactly the problem. That that's not the proper way of doing it, what your patches do is to take d3dx9 code and hammer it until it works for d3dx11. The result is that it "works" but it isn't pretty, both for the process (you can see the hammering right in the patch series) and the end result (the resulting code in d3dx11 is ugly). BTW, notice that the d3dx9 code isn't particularly nice either, result of years of additions / fixes / changes done by multiple people. It could use a rewrite, if only there was a good reason... For the time being, you have to trust my judgment on the matter (or escalate things, but I'm pretty sure you'll find more of the same). Let me list my main issues with the current patch series: - 2K lines code drop - copying d3dx9 code to d3dx11 while adding a bunch of defines and definitions to make it compile - using wined3d types in d3dx because they happen to match the use case at hand - no tests Each of them is reason enough to reject the series right away. I imagine that it isn't obvious to you why is that and I'm not sure how to convince you in detail, I feel like I'm doing a terrible job at that. I'll try to reply to specific questions (and gladly accept help from other fellow devs). I'll repeat myself to conclude. IMHO the easiest way to generate acceptable patches for this stuff is to follow the "plan" I expressed in my last few emails: start from scratch, adding a small piece at a time, with tests.

Sept. 20, 2016

Re: Getting backtraces from services without crash dialog

by Austin English

On Wed, Sep 7, 2016 at 8:40 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, Sep 7, 2016 at 8:18 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> I haven't tried this, but my suggestion would be to replace the >> WriteFile in dbg_outputA with a call to wine_dbg_printf, something >> like: >> >> wine_dbg_printf("%.*s", i, line_buff); >> >> On Tue, Sep 6, 2016 at 7:18 PM, Austin English <austinenglish(a)gmail.com> wrote: >>> 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 >>> >>> > > Thanks Vincent. > > The backtraces were interspersed with fixme's (not unexpected), but > other than that, worked great, thanks. > > -- > -Austin > GPG: 14FB D7EA A041 937B FYI, I documented this at https://wiki.winehq.org/Winedbg Thanks again! -- -Austin GPG: 14FB D7EA A041 937B

Sept. 20, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Matteo Bruni

2016-09-20 2:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: >> Yeah, that's certainly not acceptable. Also in general introducing >> dead code (i.e. code that's unused until a later patch) is not okay. > > Well I see. It's just that I didn't want to commit the whole thing as single > patch, since that would make it way less understandable. So I split it up to > show where exactly I changed lines. Regarding "introducing dead code", I > thought it was fine if it was part of a patchset? Obviously all patches in this > set depend on the others. They aren't supposed to be on their own, it's just > way more overseeable like that. Well, obviously a single huge patch wouldn't be okay either. The problem is in how you split stuff over multiple patches. More below... >> You can probably start from a simple implementation of >> D3DX11CreateTextureFromMemory(), without any scaling or format >> conversion and without DDS support. Something like >> 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how >> that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make >> sense to implement D3DX11GetImageInfoFromMemory() first. >> >> Then you should introduce the various other pieces incrementally, as >> they become necessary. You don't want to actually duplicate the code >> keeping all the d3d9-isms, you'll have to rewrite those helpers in a >> way that makes sense for d3d11 (incidentally, that's what I meant with >> this being a useful step before figuring out how generic helpers would >> look like). > > Actually, this is my attempt at a generic helper. > "load_imagedata_from_file_in_memory" and "load_imageinfo_from_file_in_memory" > should be usable for both DX9 and DX11. > The point is, that this is mostly C&P from d3dx9 code. I didn't change too > much, so I figured it would be a bad idea to cut out functionality to add it > later again. You aren't actually stripping functionality from anything. You are implementing a new d3dx11 function. The fact that it happens to be very similar to another function which is already implemented is quite tangential. I'd say it's been more confusing than helping up to this point. Try to go implement the d3dx11 functions as I suggest above. You should "automatically" get a much nicer patch series, with each patch adding some small and easily testable piece of functionality or a test for the aforementioned functionality. I'd start with a stub for D3DX11GetImageInfoFromMemory(). Then one or more patches adding flesh to it AND tests. Sharing code should not be a concern at all at this point. Looking at the d3dx9 code and tests for inspiration is okay but you DON'T want to copy it, that's simply going to be worse than starting from scratch. >> Most importantly, you need to write some tests for all the functions >> you are implementing. The related d3dx9 tests are probably a decent >> starting point, although there are a few new bits that should be >> tested as well (e.g. it would be interesting to test various >> combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to >> do that even before starting to work on the implementation, there >> might be some surprising results. > > Yeah, I don't have tests yet. First I wanted to give you an implementation so > we could decide on where to put the helpers. Also, I kinda don't know how to > write a proper test without running windows (except for a VM). Don't worry about sharing code for the time being. Tests are much more important. WRT the tests there is the testbot (http://testbot.winehq.org/) there you can submit patches and run tests against a number of Windows VMs. You just have to ask for an account first. A local Windows VM should also be fine to test for these d3dx11 functions. In theory you could even use native d3dx11 on Wine, although that might give some misleading results e.g. if Wine's d3d11 isn't quite doing the right thing.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Fabian Maurer

> 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. I somewhat doubt it. It wasn't too hard to use the d3dx9 parts for d3dx11, and it shouldn't be too hard to make it a good generic version. It would make both d3dx9 and d3dx11 simpler, while providing modular abstraction. Just loading a texture or texture information is something that can be standalone. I'm open to change of course, but I'd like to understand the reason behind it. It's not linked to wined3d anymore, only uses the intermediate imageformat. Since a generic imageloader can't rely on DX9 types nor on DX11 and since I didn't want to reinvent the wheel, I just used the implemenation at hand: wined3dformat.

Sept. 20, 2016

Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

by Matteo Bruni

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.

Sept. 20, 2016

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects

by Bruno Jesus

On Mon, Sep 19, 2016 at 9:11 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> On Mon, Sep 19, 2016 at 8:12 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> I have been talking a lot to Elias Vanderstuyft recently, we are aware >> of precision problems and are working to fix it a in better way. For >> now I'm sticking the simple changes that I'm able to test in my real >> hardware. The limit of phase is 35999 because it is related to degrees >> / 100, more than that would wrap. You are probably right that we need >> to clamp to max value before calculating. > > I don't know if we need to clamp or not. My guess is that it just > repeats periodically after that, if such values are allowed at all > (SetParameter might fail). I.e. I would have used something like > (phase % 36000) instead of clamping. > That probably means some more tests are required... > >> It is important to note that >> although we are losing precision you can't really notice it in a >> standard gamepad. > > Sure but it still seems like a good idea to do things right when reasonable. > Notice that I don't mean to blame you or the patch, I had a bit of a > look at the existing code after all... Yes, I agree that if we can make it better it should be better. I just lack the math skills sometimes for things that may look obvious for other people, I even considered opening questions at http://math.stackexchange.com to help improve some equations.

Sept. 20, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Fabian Maurer

> Yeah, that's certainly not acceptable. Also in general introducing > dead code (i.e. code that's unused until a later patch) is not okay. Well I see. It's just that I didn't want to commit the whole thing as single patch, since that would make it way less understandable. So I split it up to show where exactly I changed lines. Regarding "introducing dead code", I thought it was fine if it was part of a patchset? Obviously all patches in this set depend on the others. They aren't supposed to be on their own, it's just way more overseeable like that. > You can probably start from a simple implementation of > D3DX11CreateTextureFromMemory(), without any scaling or format > conversion and without DDS support. Something like > 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how > that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make > sense to implement D3DX11GetImageInfoFromMemory() first. > > Then you should introduce the various other pieces incrementally, as > they become necessary. You don't want to actually duplicate the code > keeping all the d3d9-isms, you'll have to rewrite those helpers in a > way that makes sense for d3d11 (incidentally, that's what I meant with > this being a useful step before figuring out how generic helpers would > look like). Actually, this is my attempt at a generic helper. "load_imagedata_from_file_in_memory" and "load_imageinfo_from_file_in_memory" should be usable for both DX9 and DX11. The point is, that this is mostly C&P from d3dx9 code. I didn't change too much, so I figured it would be a bad idea to cut out functionality to add it later again. It's about extracting the functionality from d3dx9 into something that's reusable. I could have extracted and used it for d3dx9 first, but we don't know yet where to put it.. > Most importantly, you need to write some tests for all the functions > you are implementing. The related d3dx9 tests are probably a decent > starting point, although there are a few new bits that should be > tested as well (e.g. it would be interesting to test various > combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to > do that even before starting to work on the implementation, there > might be some surprising results. Yeah, I don't have tests yet. First I wanted to give you an implementation so we could decide on where to put the helpers. Also, I kinda don't know how to write a proper test without running windows (except for a VM).

Sept. 20, 2016

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects

by Matteo Bruni

2016-09-20 1:34 GMT+02:00 Bruno Jesus <00cpxxx(a)gmail.com>: > On Mon, Sep 19, 2016 at 8:12 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 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... > > Ciao, Italian friend. ;) >>> 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. > > I have been talking a lot to Elias Vanderstuyft recently, we are aware > of precision problems and are working to fix it a in better way. For > now I'm sticking the simple changes that I'm able to test in my real > hardware. The limit of phase is 35999 because it is related to degrees > / 100, more than that would wrap. You are probably right that we need > to clamp to max value before calculating. I don't know if we need to clamp or not. My guess is that it just repeats periodically after that, if such values are allowed at all (SetParameter might fail). I.e. I would have used something like (phase % 36000) instead of clamping. That probably means some more tests are required... > It is important to note that > although we are losing precision you can't really notice it in a > standard gamepad. Sure but it still seems like a good idea to do things right when reasonable. Notice that I don't mean to blame you or the patch, I had a bit of a look at the existing code after all... >> 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. > > I'm planning to throw away the GetParameters code and instead save a > copy of SetParameters value and return it instead. Yeah, that sounds like a good idea for sure.

Sept. 20, 2016

Re: [PATCH 5/5] d3dx11: Implemented D3DX11CompileFromFileW

by Matteo Bruni

2016-09-20 1:56 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > Thanks for your feedback. > >> > + UINT filename_converted_len; >> >> Probably you can call it just "size". > Are you sure? I tried to make it less ambiguous, since there are two sizes > used. Right. Whatever is fine I guess, but using "_size" instead of "_len" seems valuable for consistency. >> 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. > > I fixed the other issues on my local branch and I'll try to get the async parts > right. Cool, looking forward to it.

Sept. 20, 2016

Re: [PATCH 5/5] d3dx11: Implemented D3DX11CompileFromFileW

by Fabian Maurer

Thanks for your feedback. > > + UINT filename_converted_len; > > Probably you can call it just "size". Are you sure? I tried to make it less ambiguous, since there are two sizes used. > 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. I fixed the other issues on my local branch and I'll try to get the async parts right.

Sept. 19, 2016

Re: [PATCH 5/5] d3dx11: Implemented D3DX11CompileFromFileW

by Matteo Bruni

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.

Sept. 19, 2016

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects

by Bruno Jesus

On Mon, Sep 19, 2016 at 8:12 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 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... Ciao, Italian friend. >> 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. I have been talking a lot to Elias Vanderstuyft recently, we are aware of precision problems and are working to fix it a in better way. For now I'm sticking the simple changes that I'm able to test in my real hardware. The limit of phase is 35999 because it is related to degrees / 100, more than that would wrap. You are probably right that we need to clamp to max value before calculating. It is important to note that although we are losing precision you can't really notice it in a standard gamepad. > 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. I'm planning to throw away the GetParameters code and instead save a copy of SetParameters value and return it instead. This will solve the issues about linux -> dinput reconversion, this seems to work but testing takes longer time. Specially because I could not find any game that actually uses this, only effect editing tools. Best wishes, Bruno

Sept. 19, 2016

Re: [PATCH 4/5] d3dx11: Implemented D3DX11CreateShaderResourceViewFromFileW

by Matteo Bruni

2016-09-13 22:27 GMT+02:00 Nikolay Sivov <bunglehead(a)gmail.com>: > 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. Yeah, it would be nice. The async and sync cases should be able to share most of the code, with the only difference being that in the async case the function will call AddWorkItem on the thread pump object while in the sync case it will call the data loader / data processor methods itself. While it might be an option to ignore the thread pump case in the initial implementation, it seems clearly better to structure things to use data loader + data processor objects from the start.

Sept. 19, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Matteo Bruni

2016-09-13 22:28 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: >> I don't think this is acceptable. It should be done in a way that >> doesn't introduce mess like this. > > I split the patches but I didn't know how to do it . For not breaking > compilation, I added these temporary defines. The later patch removes those > again. Yeah, that's certainly not acceptable. Also in general introducing dead code (i.e. code that's unused until a later patch) is not okay. You can probably start from a simple implementation of D3DX11CreateTextureFromMemory(), without any scaling or format conversion and without DDS support. Something like 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make sense to implement D3DX11GetImageInfoFromMemory() first. Then you should introduce the various other pieces incrementally, as they become necessary. You don't want to actually duplicate the code keeping all the d3d9-isms, you'll have to rewrite those helpers in a way that makes sense for d3d11 (incidentally, that's what I meant with this being a useful step before figuring out how generic helpers would look like). Most importantly, you need to write some tests for all the functions you are implementing. The related d3dx9 tests are probably a decent starting point, although there are a few new bits that should be tested as well (e.g. it would be interesting to test various combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to do that even before starting to work on the implementation, there might be some surprising results.

Sept. 19, 2016

Re: [PATCH 1/2] dinput: Fix phase conversion on periodic effects

by Matteo Bruni

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.

Sept. 19, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 14:01:21 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Wrote a quick test and they seem to be 0x28 and 0x2c respectively, so > I guess that's not your problem. > > Andrew BTW, I tested with pointer set to 0 and still have return value of FALSE, so according to the source you posted, it seems that `infoPtr->nCurrentTool == -1` for this tooltip control. The control is created automatically by the toolbar. Here is the code that create the toolbar (some labels are arguments of the whole function): ; Create toolbar xor esi,esi invoke GetModuleHandleW,esi mov edi, eax invoke CreateWindowExW, esi, cToolbarClassName, NULL, \ WS_CHILD or \ WS_VISIBLE or \ WS_CLIPSIBLINGS or \ WS_CLIPCHILDREN or \ TBSTYLE_TRANSPARENT or \ TBSTYLE_FLAT or \ TBSTYLE_TOOLTIPS or \ TBSTYLE_WRAPABLE, \ esi, esi, esi, esi, \ [.ParentWindow], [.ToolbarID], \ edi, NULL mov ebx,eax stdcall SubclassWindow, ebx, CoolToolbarProc invoke SetPropW, ebx, [propAutoSize], TRUE invoke SendMessageW, ebx, TB_BUTTONSTRUCTSIZE, TToolbarButton.size, esi ; make arrows for dropdown buttons invoke SendMessageW, ebx, TB_GETEXTENDEDSTYLE, esi, esi or eax,TBSTYLE_EX_DRAWDDARROWS invoke SendMessageW, ebx, TB_SETEXTENDEDSTYLE, esi, eax ; Set image lists invoke SendMessageW, ebx, TB_SETIMAGELIST, esi, [.ImagesNormal] invoke SendMessageW, ebx, TB_SETDISABLEDIMAGELIST, esi, [.ImagesDisabled] ; make tooltip to appear on not active main window. invoke SendMessageW, ebx, TB_GETTOOLTIPS, 0, 0 mov esi, eax invoke GetWindowLongW, esi, GWL_STYLE or eax, TTS_ALWAYSTIP or TTS_NOPREFIX invoke SetWindowLongW, esi, GWL_STYLE, eax ; Set tooltip delay time. invoke SendMessageW, esi, TTM_SETDELAYTIME, TTDT_AUTOMATIC, 600 -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Andrew Eikum

On Mon, Sep 19, 2016 at 09:56:59PM +0300, John Found wrote: > On Mon, 19 Sep 2016 13:39:27 -0500 > Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > > On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > > > 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. > > > > That message in Wine should only return FALSE in a few scenarios: > > > > http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… > > > > Check that your cbSize member is valid, and if so, maybe look into why > > Wine doesn't think there is a tool currently selected. > > > > Andrew > > What is the values of TTTOOLINFOW_V1_SIZE and TTTOOLINFOW_V2_SIZE? I tried to search for them, but there is some very > obfuscated C code... :'( > > I am using a structure with size = 28h = 40 bytes > Wrote a quick test and they seem to be 0x28 and 0x2c respectively, so I guess that's not your problem. Andrew

Sept. 19, 2016

Re: Problems with the tooltip controls.

by John Found

On Mon, 19 Sep 2016 13:39:27 -0500 Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > > 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. > > That message in Wine should only return FALSE in a few scenarios: > > http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… > > Check that your cbSize member is valid, and if so, maybe look into why > Wine doesn't think there is a tool currently selected. > > Andrew What is the values of TTTOOLINFOW_V1_SIZE and TTTOOLINFOW_V2_SIZE? I tried to search for them, but there is some very obfuscated C code... :'( I am using a structure with size = 28h = 40 bytes struct TOOLINFO .cbSize dd ? .uFlags dd ? .hwnd dd ? .uId dd ? .Rect RECT .hInst dd ? .lpszText dd ? ends It seems that Windows accepts it, but WINE not. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Nikolay Sivov

On Monday, 19 September 2016, John Found <johnfound(a)asm32.info> wrote: > 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? > > Hi, John. Please open a bug report and attach sample application code there or at least a relevant part of it, so we can turn it into a test. Workarounds are not interesting for Wine. > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound(a)asm32.info <javascript:;>> > > >

Sept. 19, 2016

Re: Problems with the tooltip controls.

by Andrew Eikum

On Mon, Sep 19, 2016 at 09:30:20PM +0300, John Found wrote: > 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. That message in Wine should only return FALSE in a few scenarios: http://source.winehq.org/git/wine.git/blob/5a9f7ef06df15e26acf46b0210dd7697… Check that your cbSize member is valid, and if so, maybe look into why Wine doesn't think there is a tool currently selected. Andrew

Sept. 19, 2016

Problems with the tooltip controls.

by John Found

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>

Sept. 19, 2016

Re: [PATCH v2] hid: Stub HidP_TranslateUsagesToI8042ScanCodes

by Sebastian Lackner

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 > > >

Sept. 19, 2016

Re: [PATCH] wined3d: Add id for Broadwell Xeon E3 GPU

by Henri Verbeet

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.

Sept. 19, 2016

Re: wine-1.8.5-rc1 Available

by André Hentschel

Am 16.09.2016 um 00:43 schrieb Michael Stefaniuc: > 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/ Tried it in buildroot, no problems

Sept. 17, 2016

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

by Huw Davies

On 16 Sep 2016, at 15:27, Marvin <testbot(a)winehq.org> wrote: > 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. This is a different issue. Huw.

Sept. 16, 2016

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

by Marvin

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.

Sept. 16, 2016

Re: [6/6] windowscodecs: Fix 32bppGrayFloat to 8bppGray conversion.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Oh, I didn't think of that, sorry. If you are going to resend the patch please consider adding an explanation why a separate branch is required to handle the conversion. -- Dmitry.

Sept. 16, 2016

Re: [6/6] windowscodecs: Fix 32bppGrayFloat to 8bppGray conversion.

by Vincent Povirk

Oh, I didn't think of that, sorry. On Thu, Sep 15, 2016 at 10:06 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > 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.

Sept. 16, 2016

Re: [6/6] windowscodecs: Fix 32bppGrayFloat to 8bppGray conversion.

by Dmitry Timoshkov

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.

Sept. 16, 2016

Re: libwine: Do not compare strings "ab-c" and a-bc" as equal.

by Bernhard Übelacker

Am 27.08.2016 um 15:32 schrieb Marvin: > 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 '' > > These are existing failures.

Sept. 16, 2016

wine-1.8.5-rc1 Available

by Michael Stefaniuc

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(a)N@0(a)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(a)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

Sept. 15, 2016

Re: [PATCH v2] mpr: Implement connected resources enumeration.

by Alexandre Julliard

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

Sept. 15, 2016

Re: [PATCH] hid: Stub HidP_TranslateUsagesToI8042ScanCodes

by Sebastian Lackner

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 > > >

Sept. 15, 2016

Re: [PATCH v4] ntoskrnl.exe: Send PnP and Power IRPs to plug and play devices

by Sebastian Lackner

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 ); > } > > > > >

Sept. 15, 2016

Re: [PATCH v2] ntoskrnl.exe: Implement DevicePropertyEnumeratorName for IoGetDeviceProperty

by Sebastian Lackner

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); > > >

Sept. 15, 2016

Re: [1/4] gdiplus: Add FIXME for EMF records we need to implement.

by Vincent Povirk

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

Sept. 14, 2016

Re: ucrtbase: Add __std_type_info_hash implementation

by Huw Davies

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.

Sept. 14, 2016

Re: winmm/tests: Remove a test that can crash on Win 8 and 10.

by Huw Davies

On 13 Sep 2016, at 19:06, Marvin <testbot(a)winehq.org> wrote: > > 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) These are fixed by my other patch. Huw.

Sept. 14, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Fabian Maurer

> I don't think this is acceptable. It should be done in a way that > doesn't introduce mess like this. I split the patches but I didn't know how to do it . For not breaking compilation, I added these temporary defines. The later patch removes those again.

Sept. 13, 2016

Re: [PATCH 4/5] d3dx11: Implemented D3DX11CreateShaderResourceViewFromFileW

by Nikolay Sivov

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.

Sept. 13, 2016

Re: [PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading

by Nikolay Sivov

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.

Sept. 13, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

> Fabian, if you want to send patches for > D3DX11CreateShaderResourceViewFromFileW "duplicating" the relevant > code for the time being, that is fine to me. It might even be easier > to decide how to share the code at that point. Thanks, I sent the patches to the patches mailing list, I hope that's fine. I split them a bit so it's more visible which part I changed, it's really a lot copy&paste. You probably need to apply all patches at once, since they don't make much sense each on their own, but it shouldn't break compilation even if you just apply one. Also, if you want something to test it with, I implemented it for the samples from http://www.rastertek.com/dx11tut05.html. Currently still needs native d3dcompiler to work though. I'd be happy to hear some feedback, especially since it's a fairly big set of patches.

Sept. 13, 2016

Re: winmm/tests: Remove a test that can crash on Win 8 and 10.

by Marvin

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)

Sept. 13, 2016

Re: [PATCH v8] winebus.sys: Build initial hidraw device set

by Aric Stewart

On 9/13/16 4:28 AM, Sebastian Lackner wrote: > 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? > Correct this is Wine specific. I dont feel like it is appropriate to use any other class guid because hidraw devices are hidraw devices, they are not anything else. We do not want any application to search for a know class guid and get these devices unexpectedly. >> + >> +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? > Either, they are place holders. I must have just miscounted on one of them. I have not counted how many "0" are in the windows placeholder as really it makes no material difference. >> + 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). > This becomes important in the winehid.sys driver. We could put this in a common header somewhere but I always find that putting something non-windows in a header file to be a real fight. >> + >> + 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. > Thanks, we discussed this on IRC. >> + 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? > Either way. Either you have 2 hwidfmtW versions or 2 im_fmtW versions. I am not attached to one or the other. -aric >> +} >> + >> +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; >> >> >> >

Sept. 13, 2016

Re: winmm/tests: Add a small Sleep() to prevent a notification test from failing.

by Huw Davies

On 13 Sep 2016, at 11:14, Marvin <testbot(a)winehq.org> wrote: > 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 These are unrelated. Huw.

Sept. 13, 2016

Re: winmm/tests: Add a small Sleep() to prevent a notification test from failing.

by Marvin

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

Sept. 13, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Michael Stefaniuc

On 09/12/2016 10:50 PM, Matteo Bruni wrote: > 2016-09-12 10:37 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: >> On 10 September 2016 at 18:47, Fabian Maurer <dark.shadow4(a)web.de> wrote: >>> I mean, I >>> could make a copy from all the d3dx9 code for d3dx11, but it seems more >>> logical to not just duplicate code. >>> But where would I put the code to use it in both d3dx9 and d3dx11? A new >>> folder d3dx_shared for PARENTSRC? >>> >> It's largely up to Matteo and Alexandre, but I think there are a few >> options. We could for example use a single PARENTSRC for d3dx9/10/11. >> That would still require some thought, since while I'd expect many >> things to be similar or the same between d3dx9/10/11, there are also a >> considerable number of differences. Another option could be a static >> library like libwpp or libwine_port, although that's not a popular >> option. Maybe it's warranted for d3dx. Maybe there are other options >> as well. > > I don't quite know what would be the best solution yet. Maybe a static > library for the code in common between d3dx9/10/11 + PARENTSRC for the > various _xx versions would be sensible, yes. It's going to be quite a > bit of work to make the common, d3dx version-agnostic helper functions > to put in the static lib though (including figuring out what they > should look like). On the upside, that can be done incrementally, > moving stuff there piece by piece as needed. The static library was also my goal for the dmusic and related DLLs. Alexandre wasn't convinced so the incremental way to get there was to duplicate the dmobject.[ch] files. "Duplicate" as there are 8 copies, I just need to resurrect my dmusic cleanup to make those files even bigger and add more churn to them ;) bye michael

Sept. 13, 2016

Re: [PATCH v8] winebus.sys: Build initial hidraw device set

by Sebastian Lackner

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; > > >

Sept. 13, 2016

Re: [PATCH] mpr: Implement connected resources enumeration.

by Hugh McMaster

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.

Sept. 13, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Matteo Bruni

2016-09-12 10:37 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 10 September 2016 at 18:47, Fabian Maurer <dark.shadow4(a)web.de> wrote: >> I mean, I >> could make a copy from all the d3dx9 code for d3dx11, but it seems more >> logical to not just duplicate code. >> But where would I put the code to use it in both d3dx9 and d3dx11? A new >> folder d3dx_shared for PARENTSRC? >> > It's largely up to Matteo and Alexandre, but I think there are a few > options. We could for example use a single PARENTSRC for d3dx9/10/11. > That would still require some thought, since while I'd expect many > things to be similar or the same between d3dx9/10/11, there are also a > considerable number of differences. Another option could be a static > library like libwpp or libwine_port, although that's not a popular > option. Maybe it's warranted for d3dx. Maybe there are other options > as well. I don't quite know what would be the best solution yet. Maybe a static library for the code in common between d3dx9/10/11 + PARENTSRC for the various _xx versions would be sensible, yes. It's going to be quite a bit of work to make the common, d3dx version-agnostic helper functions to put in the static lib though (including figuring out what they should look like). On the upside, that can be done incrementally, moving stuff there piece by piece as needed. The single d3dx* PARENTSRC idea seems a bit more messy, while the hypothetical multiple PARENTSRC route I mentioned for d3dcompiler doesn't seem a good fit here. I'm afraid this is one of those cases where it's going to be clear if a certain route is practical only after the fact i.e. once someone writes the patches or fails trying... Fabian, if you want to send patches for D3DX11CreateShaderResourceViewFromFileW "duplicating" the relevant code for the time being, that is fine to me. It might even be easier to decide how to share the code at that point.

Sept. 12, 2016

Re: setupapi/tests: Try to delete pre-existing key

by Marvin

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

Sept. 12, 2016

Re: [PATCH v7] winebus.sys: Build initial hidraw device set

by Aric Stewart

On 9/12/16 8:08 AM, Sebastian Lackner wrote: > On 12.09.2016 14:41, Aric Stewart wrote: >>>> >>>> Does this work properly when elements are deleted? You might return the same index >>>> for different devices. >> As far as I understand, this index does not need to be unique to a device, just unique for in given device set of active devices, so this should be ok. > > I don't think its guaranteed to be unique at all. Lets assume we have three > devices with the same vidpid (index 1, 2, 3). The second one gets removed > (index 1, 3) and a fourth one gets added. It will then attempt to use index > 3 which is still in use. Is that not a problem? > Yes, my logic is clearly flawed. I will re-works it, thanks for noticing! >>>> 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. >>>> >> That is coming in a later patch where I handle device removals. You are right that part of that will need to be moved here for the error case. > > If it was part of your draft series I must have missed it. How exactly are you > planning to implement it? Does it make sense to store a release function as part > of each device, or maybe even a Vtable? > Yeah, I was avoiding vtables as much as possible. You can see it in patch 126373. But clearly my error handling here needs work which I am giving it. >>>> 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? >>>> >> These part of registry manipulations are done on windows via device installation. So setupapi is used to make these keys and then they are just expected to be there for installed devices. Since we are trying to handle native devices that have not been installed in this method we have to add the proper registry information more dynamically. That both areas have to do similar things that is why the code is similar. >> >> These bus devices do not have any Interfaces, that is why we have no call to SetupDiCreateDeviceInterfaceW. > > Okay, thanks for the explanation. I still find it a bit odd when we have all > this code with a similar purpose at different places though, especially when > it looks very different. The hidclass version for example will leak the devinfo > handle on various error paths and returns ERROR_* codes instead of NTSTATUS > values. This version here might have other issues (at least missing error > handling for some of the functions). If the code duplication cannot be avoided, > it might at least be useful to keep the code a bit more synchronized to these > other versions (after fixing them, of course). > I will work on the error handling in this chunk of code. Patches to fix up the hidclass stuff are welcome! :) I will try to circle back to that also since you have identified issues. I have not found a good way to avoid this duplication. There are functions like DiInstallDriver or UpdateDriverForPlugAndPlayDevices, but they expect an INF file with the driver information specified. I have not found a clean way to just do these step programmatically in the windows API. -aric >> >> >> I will work on integrating all the other changes. thanks! >> >> -aric >> > > Regards, > Sebastian >

Sept. 12, 2016

Re: [PATCH v7] winebus.sys: Build initial hidraw device set

by Sebastian Lackner

On 12.09.2016 14:41, Aric Stewart wrote: >> > >> > Does this work properly when elements are deleted? You might return the same index >> > for different devices. > As far as I understand, this index does not need to be unique to a device, just unique for in given device set of active devices, so this should be ok. I don't think its guaranteed to be unique at all. Lets assume we have three devices with the same vidpid (index 1, 2, 3). The second one gets removed (index 1, 3) and a fourth one gets added. It will then attempt to use index 3 which is still in use. Is that not a problem? >> > 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. >> > > That is coming in a later patch where I handle device removals. You are right that part of that will need to be moved here for the error case. If it was part of your draft series I must have missed it. How exactly are you planning to implement it? Does it make sense to store a release function as part of each device, or maybe even a Vtable? >> > 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? >> > > These part of registry manipulations are done on windows via device installation. So setupapi is used to make these keys and then they are just expected to be there for installed devices. Since we are trying to handle native devices that have not been installed in this method we have to add the proper registry information more dynamically. That both areas have to do similar things that is why the code is similar. > > These bus devices do not have any Interfaces, that is why we have no call to SetupDiCreateDeviceInterfaceW. Okay, thanks for the explanation. I still find it a bit odd when we have all this code with a similar purpose at different places though, especially when it looks very different. The hidclass version for example will leak the devinfo handle on various error paths and returns ERROR_* codes instead of NTSTATUS values. This version here might have other issues (at least missing error handling for some of the functions). If the code duplication cannot be avoided, it might at least be useful to keep the code a bit more synchronized to these other versions (after fixing them, of course). > > > I will work on integrating all the other changes. thanks! > > -aric > Regards, Sebastian

Sept. 12, 2016

Re: [PATCH v7] winebus.sys: Build initial hidraw device set

by Aric Stewart

Thanks for the review! On 9/12/16 3:24 AM, Sebastian Lackner wrote: > 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 >> >> +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. As far as I understand, this index does not need to be unique to a device, just unique for in given device set of active devices, so this should be ok. > >> + >> +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. > That is coming in a later patch where I handle device removals. You are right that part of that will need to be moved here for the error case. >> + 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? > These part of registry manipulations are done on windows via device installation. So setupapi is used to make these keys and then they are just expected to be there for installed devices. Since we are trying to handle native devices that have not been installed in this method we have to add the proper registry information more dynamically. That both areas have to do similar things that is why the code is similar. These bus devices do not have any Interfaces, that is why we have no call to SetupDiCreateDeviceInterfaceW. I will work on integrating all the other changes. thanks! -aric >> + } >> + >> + 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. > >> >> >> >

Sept. 12, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

> In the first place it's conceptual, wined3d is Wine's equivalent to > the D3D driver interface, it shouldn't be concerned with high-level > utility functionality like D3DX. Second, and related, as Michael > mentioned, Microsoft's d3dx9 doesn't depend directly on the D3D driver > interface. You can use Microsoft's d3dx9 on Wine, and ideally you > should be able to use a Win32 build of Wine's d3dx9 as a drop-in > replacement on Windows, without additional dependencies. Ah well I see, makes sense. > It's largely up to Matteo and Alexandre, but I think there are a few > options. We could for example use a single PARENTSRC for d3dx9/10/11. > That would still require some thought, since while I'd expect many > things to be similar or the same between d3dx9/10/11, there are also a > considerable number of differences. Another option could be a static > library like libwpp or libwine_port, although that's not a popular > option. Maybe it's warranted for d3dx. Maybe there are other options > as well. Well, there are differences between d3dx9 and d3dx11, but it's possible to deduplicate at least a part of the code. I'm trying to get it done with texture loading, but I'd need to know where to put it. At least parsing the DDS or using WIC to load images, and the converter functions are nearly exactly the same. The only other option I see would be to not care about extracting these code parts and making a full blown copy in d3dx11 like I have it on my temporary branch. It works, but to me it seems like a bad approach.

Sept. 12, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Henri Verbeet

On 10 September 2016 at 18:47, Fabian Maurer <dark.shadow4(a)web.de> wrote: > On Saturday, September 10, 2016 6:33:04 PM CEST you wrote: >> >> Unfortunately d3dx dlls shouldn't depend on wined3d either. We've >> typically handled sharing across different versions of d3dx using >> PARENTSRC. > > I see, what's the reason behind this? After all, d3dx_36 depends on d3d9 which > in turn depends on wined3d. Just curious, I'll make it different if this is > your standard. > In the first place it's conceptual, wined3d is Wine's equivalent to the D3D driver interface, it shouldn't be concerned with high-level utility functionality like D3DX. Second, and related, as Michael mentioned, Microsoft's d3dx9 doesn't depend directly on the D3D driver interface. You can use Microsoft's d3dx9 on Wine, and ideally you should be able to use a Win32 build of Wine's d3dx9 as a drop-in replacement on Windows, without additional dependencies. > I can put the conversion functions in dxgi and make it public by using the > .spec file, but I really don't know about the actual texture loader. DXGI isn't really the right place either, for similar reasons. In general, we'd like to limit the number of Wine-specific exports. > I mean, I > could make a copy from all the d3dx9 code for d3dx11, but it seems more > logical to not just duplicate code. > But where would I put the code to use it in both d3dx9 and d3dx11? A new > folder d3dx_shared for PARENTSRC? > It's largely up to Matteo and Alexandre, but I think there are a few options. We could for example use a single PARENTSRC for d3dx9/10/11. That would still require some thought, since while I'd expect many things to be similar or the same between d3dx9/10/11, there are also a considerable number of differences. Another option could be a static library like libwpp or libwine_port, although that's not a popular option. Maybe it's warranted for d3dx. Maybe there are other options as well.

Sept. 12, 2016

Re: [PATCH v7] winebus.sys: Build initial hidraw device set

by Sebastian Lackner

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. > > >

Sept. 12, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Michael Stefaniuc

On 09/10/2016 06:47 PM, Fabian Maurer wrote: > On Saturday, September 10, 2016 6:33:04 PM CEST you wrote: >> >> Unfortunately d3dx dlls shouldn't depend on wined3d either. We've >> typically handled sharing across different versions of d3dx using >> PARENTSRC. > > I see, what's the reason behind this? After all, d3dx_36 depends on d3d9 which > in turn depends on wined3d. Just curious, I'll make it different if this is > your standard. Not really, you can use d3dx_36 on Windows thus use that d3d9 without depending on wined3d. bye michael

Sept. 12, 2016

Re: [v3 PATCH] d2d1: Initial implementation of DC render target

by Henri Verbeet

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.

Sept. 12, 2016

Re: Wine slow load somewhere after 1.9.16

by Austin English

On Sep 12, 2016 12:09 AM, "Bruno Jesus" <00cpxxx(a)gmail.com> wrote: > > On Sun, Sep 4, 2016 at 2:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > 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. > > Also sometimes I have this while trying to start an application (also > in completely random situations): > > err:winediag:nulldrv_CreateWindow Application tried to create a > window, but no driver could be loaded. > err:winediag:nulldrv_CreateWindow The explorer process failed to start. > err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 > err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 I've seen this as well.

Sept. 12, 2016

Re: Wine slow load somewhere after 1.9.16

by Bruno Jesus

On Sun, Sep 4, 2016 at 2:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > 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. Also sometimes I have this while trying to start an application (also in completely random situations): err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow The explorer process failed to start. err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 err:ole:apartment_createwindowifneeded CreateWindow failed with error 0

Sept. 12, 2016

Re: Wine Staging release notes

by Michael Müller

Am 09.09.2016 um 00:13 schrieb Theodore Dubois: > 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 Most of the release notes were written by me and I stopped writing them when I did not have enough time for it. Preparing the release (rebasing work, testing, building packages) already takes a lot of time. Anyway, I decided to continue providing release notes, but in a more minimalist way, similar to the development release news. I put the 1.9.18 notes online, so that you get an idea how they will look in the future. Regards, Michael

Sept. 11, 2016

Re: [v2 PATCH] d2d1: Initial implementation of DC render target

by Sebastian Lackner

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?

Sept. 11, 2016

Re: [4/4] jscript: Simplify create_utc_string and add basic tests.

by Marvin

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

Sept. 11, 2016

Re: [3/4] jscript: Simplify date_to_string and add basic tests.

by Marvin

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

Sept. 11, 2016

Re: [2/4] jscript: Allocate string of correct size in Date toLocaleDateString method.

by Marvin

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

Sept. 11, 2016

Re: [1/4] jscript: Properly handle \0 characters in Array join method.

by Marvin

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

Sept. 11, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

On Saturday, September 10, 2016 6:33:04 PM CEST you wrote: > > Unfortunately d3dx dlls shouldn't depend on wined3d either. We've > typically handled sharing across different versions of d3dx using > PARENTSRC. I see, what's the reason behind this? After all, d3dx_36 depends on d3d9 which in turn depends on wined3d. Just curious, I'll make it different if this is your standard. I can put the conversion functions in dxgi and make it public by using the .spec file, but I really don't know about the actual texture loader. I mean, I could make a copy from all the d3dx9 code for d3dx11, but it seems more logical to not just duplicate code. But where would I put the code to use it in both d3dx9 and d3dx11? A new folder d3dx_shared for PARENTSRC?

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Henri Verbeet

On 10 September 2016 at 18:28, Fabian Maurer <dark.shadow4(a)web.de> wrote: > Well I'm currently implementing "D3DX11CreateShaderResourceViewFromFileW", and > to make things easier I wanted to make a generic textureloader for both DX11 > and DX9 in wined3d (mostly moving code from DX9). > That works fine, but since it works with WINED3D formats, they need to be > converted in d3dx11. But I'd need to duplicate the conversion code a third > time for that. And that's what I wanted to avoid, it seems like a lot of > unnecessary duplication. Unfortunately d3dx dlls shouldn't depend on wined3d either. We've typically handled sharing across different versions of d3dx using PARENTSRC.

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

On Saturday, September 10, 2016 6:20:16 PM CEST Henri Verbeet wrote: > 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. Well I'm currently implementing "D3DX11CreateShaderResourceViewFromFileW", and to make things easier I wanted to make a generic textureloader for both DX11 and DX9 in wined3d (mostly moving code from DX9). That works fine, but since it works with WINED3D formats, they need to be converted in d3dx11. But I'd need to duplicate the conversion code a third time for that. And that's what I wanted to avoid, it seems like a lot of unnecessary duplication.

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

On Saturday, September 10, 2016 6:57:05 PM CEST you wrote: > > The ones defined in include/wine/winedxgi.idl. Oh I see, didn't know about these. So do you think it would make more sense to put them into dxgi? Since they're converters for wined3d formats, they could still fit in wined3d. Also, since I was trying to limit dependencies, and since I need wined3d later anyways, I figured it make sense to put it in there.

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Henri Verbeet

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.

Sept. 10, 2016

Re: kernel32/tests: Don't test CloseHandle

by Marvin

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

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Nikolay Sivov

On 10.09.2016 18:54, Fabian Maurer wrote: > On Saturday, September 10, 2016 6:44:09 PM CEST you wrote: >> What dxgi dll-overrides? Without private interfaces between d3d10/11 and >> dxgi we can't use native one anyway, can we? > What private interfaces? I was under the expression dxgi only exports the > official supported functions, but no private functions or interfaces. The ones defined in include/wine/winedxgi.idl.

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Fabian Maurer

On Saturday, September 10, 2016 6:44:09 PM CEST you wrote: > > What dxgi dll-overrides? Without private interfaces between d3d10/11 and > dxgi we can't use native one anyway, can we? What private interfaces? I was under the expression dxgi only exports the official supported functions, but no private functions or interfaces.

Sept. 10, 2016

Re: [PATCH] Moved wined3dformat <-> dxgi_format conversion functions into wined3d

by Nikolay Sivov

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?

Sept. 10, 2016

Re: kernel32/tests: Don't test function directly when reporting GetLastError()

by Marvin

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

Sept. 10, 2016

Re: [resend PATCH] d2d1: Initial implementation of DC render target

by Nikolay Sivov

On 09.09.2016 18:00, Alexandre Julliard wrote: > 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... > Must be about d3d10/11 device creation failure on your system. I'll have to add a skip for that.

Sept. 9, 2016

Re: [resend PATCH] d2d1: Initial implementation of DC render target

by Alexandre Julliard

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

Sept. 9, 2016

Re: [PATCH 2/2] mscoree: There can be only one QI implementation i a COM object!

by Michael Stefaniuc

On 09/09/2016 04:25 PM, Vincent Povirk wrote: >> Uhm... those are two different interfaces but they were already >> implemented in the same COM object aka struct ConfigFileHandler. >> See my first patch were the AddRef and Release methods were already >> forwarded from ISAXErrorHandler to ISAXContentHandler. So I just cleaned >> up COM for the single COM object. > > A COM object is not the same as a struct. A single struct can > implement multiple COM objects (we do this for many interfaces in > windowscodecs where we have a "container" object that always contains First time I hit that. All the others were COM violations. > at least one child), or a single COM object can be implemented via > multiple structs. I have merged quite a few of those during the COM cleanup as there is no advantage in splitting up the IFoo_iface field over multiple structs but I have seen different downsides (complex/more code, refcounting done wrong, memory leaks). > The identity of a COM object is determined by the result of calling > QueryInterface with IID_IUnknown. In this case, QueryInterface returns > different IUnknown pointers for each interface in the struct, so they Then you need to comment that as this is the exception of how COM is implemented in the rest of Wine. And more importantly it is indistinguishable from a COM violation bug, > are different objects. This imposes some requirements on their > behavior, but there's no requirement that the refcounts of two > different objects be unrelated, or that the reference counting be > implemented in any specific way. In this particular case you are right. But in general the refcount is visible to applications. while(IFoo_Release(iface)); is a common pattern. > There's no reason they have to be different objects here, but there That's my point. Principle of the least surprise, if you don't need to use a non standard construct then don't do it. > are many other structs in windowscodecs that implement multiple COM > objects which must be separate. > >> The alternative is to split the struct ConfigFileHandler. But as this is >> not part of the API/ABI and the applications cannot get to those COM >> interfaces it doesn't matters. Also the ISAXXMLReader just needs the two >> COM interfaces, how those are implemented it doesn't matters either. > > There's no requirement that a single struct can only implement one COM > object. The implementation of most encoders and decoders in > windowscodecs is greatly simplified by putting multiple objects in one > struct. Then just use a union for all those interface fields. That makes it obvious on what is going on. But afair there are other patterns used throughout Wine that deal with a similar problem. bye michael

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Vincent Povirk

> Once this is working, I believe it will be possible to reimplement the > driver side using only the exported Win32 clipboard APIs. I admit that I > haven't finished that part yet, so there may turn out to be a need for > some private hooks, but I'm hoping we can do without. I think we will at least need some sort of hook in OpenClipboard, so that the driver can poll the host clipboard if it needs to. The driver will also have to ensure that multiple processes don't compete for clipboard ownership when a non-Wine application holds the host clipboard. It probably has to be done in the explorer process. Otherwise, we'd have lifetime issues as well - any other process might be killed before the clipboard changes. There are still problems to be solved, but I like the direction this is taking.

Sept. 9, 2016

Re: [PATCH 2/2] mscoree: There can be only one QI implementation i a COM object!

by Vincent Povirk

> Uhm... those are two different interfaces but they were already > implemented in the same COM object aka struct ConfigFileHandler. > See my first patch were the AddRef and Release methods were already > forwarded from ISAXErrorHandler to ISAXContentHandler. So I just cleaned > up COM for the single COM object. A COM object is not the same as a struct. A single struct can implement multiple COM objects (we do this for many interfaces in windowscodecs where we have a "container" object that always contains at least one child), or a single COM object can be implemented via multiple structs. The identity of a COM object is determined by the result of calling QueryInterface with IID_IUnknown. In this case, QueryInterface returns different IUnknown pointers for each interface in the struct, so they are different objects. This imposes some requirements on their behavior, but there's no requirement that the refcounts of two different objects be unrelated, or that the reference counting be implemented in any specific way. There's no reason they have to be different objects here, but there are many other structs in windowscodecs that implement multiple COM objects which must be separate. > The alternative is to split the struct ConfigFileHandler. But as this is > not part of the API/ABI and the applications cannot get to those COM > interfaces it doesn't matters. Also the ISAXXMLReader just needs the two > COM interfaces, how those are implemented it doesn't matters either. There's no requirement that a single struct can only implement one COM object. The implementation of most encoders and decoders in windowscodecs is greatly simplified by putting multiple objects in one struct.

Sept. 9, 2016

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

by Sebastian Lackner

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.

Sept. 9, 2016

Re: [PATCH 2/2] mscoree: There can be only one QI implementation i a COM object!

by Michael Stefaniuc

On 09/09/2016 02:45 AM, Vincent Povirk wrote: > 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? Uhm... those are two different interfaces but they were already implemented in the same COM object aka struct ConfigFileHandler. See my first patch were the AddRef and Release methods were already forwarded from ISAXErrorHandler to ISAXContentHandler. So I just cleaned up COM for the single COM object. The alternative is to split the struct ConfigFileHandler. But as this is not part of the API/ABI and the applications cannot get to those COM interfaces it doesn't matters. Also the ISAXXMLReader just needs the two COM interfaces, how those are implemented it doesn't matters either. bye michael > > 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 >> >> > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Manager, APAC/EMEA IT Network Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > The way I envisioned this was that synthesis would be entirely a > query-time phenomenon, perhaps with some caching within user32. So, > CountClipboardFormats(), EnumClipboardFormats(), > IsClipboardFormatAvailable(), and GetClipboardData() would call into > the driver and get a list of the real formats. User32 would then add > in any missing formats that are synthesized from those real formats > and include them in the count/enumeration/availability check. And, of > course, GetClipboardData() would actually synthesize the data, as > necessary. None of this would be "stored" on the clipboard in the > sense of SetClipboardData(). The drivers would not be informed of the > synthesized formats or data. Going beyond synthesized formats, the high-level vision is that there will be a fully functional clipboard implementation in user32, that should pass all the tests and allow copy/paste between apps inside the same prefix, even with no driver implementation at all. Once this is working, I believe it will be possible to reimplement the driver side using only the exported Win32 clipboard APIs. I admit that I haven't finished that part yet, so there may turn out to be a need for some private hooks, but I'm hoping we can do without. -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > What is the plan with respect to replacing the synthesized content? > As user32 currently stands, GetClipboardData() can call > render_synthesized_format() which calls SetClipboardData(). After > that, how do you distinguish between CF_TEXT synthesized from > CF_UNICODETEXT and app-provided CF_TEXT? If an app does > SetClipboardData(CF_UNICODETEXT, L"string one"), then > GetClipboardData(CF_TEXT) gives "string one", then the app calls > SetClipboardData(CF_UNICODETEXT, L"string two"), but > GetClipboardData(CF_TEXT) still gives "string one". The same applies > if it's the X11 driver making the calls to SetClipboardData() due to > the X selection owner setting new data. > > Will the X11 driver clear the clipboard on each update by the other X > client? If so, will Wine be stealing selection ownership from the > other X client each time it changes? Given multiple Wine processes, > will they be competing for it? Probably the X11 driver will request the data lazily, but yes, it would clear the clipboard when the selection changed, and assert ownership in the Win32 sense. That doesn't imply it will be stealing X11 selection ownership. It will only do that when it's the app that empties the clipboard, not the driver itself. -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Ken Thomases

On Sep 8, 2016, at 10:37 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > What is the plan with respect to replacing the synthesized content? As user32 currently stands, GetClipboardData() can call render_synthesized_format() which calls SetClipboardData(). After that, how do you distinguish between CF_TEXT synthesized from CF_UNICODETEXT and app-provided CF_TEXT? If an app does SetClipboardData(CF_UNICODETEXT, L"string one"), then GetClipboardData(CF_TEXT) gives "string one", then the app calls SetClipboardData(CF_UNICODETEXT, L"string two"), but GetClipboardData(CF_TEXT) still gives "string one". Hmm. Actually, to my surprise, this is exactly how Windows behaves. I guess the synthesized format is fixed on the first GetClipboardData() and is not re-synthesized even if the source format is changed. -Ken

Sept. 9, 2016

Re: [PATCH] ws2_32/tests: Add more SIO_ADDRESS_LIST_CHANGE tests

by Marvin

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

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Ken Thomases

On Sep 8, 2016, at 7:55 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Ken Thomases <ken(a)codeweavers.com> writes: > >> On Sep 7, 2016, at 10:48 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >>> 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. > > The plan is that the driver will be modified to go through the Windows > API. So if some X client puts text on the clipboard, the X11 driver will > do a SetClipboardData(CF_UNICODETEXT), and user32 will then synthesize > the others. I'm not sure that's feasible. The Mac pasteboard doesn't provide notification of when other apps change it. If you own the pasteboard, you can be notified when some other app takes ownership and you lose it, but that's it. What is the plan with respect to replacing the synthesized content? As user32 currently stands, GetClipboardData() can call render_synthesized_format() which calls SetClipboardData(). After that, how do you distinguish between CF_TEXT synthesized from CF_UNICODETEXT and app-provided CF_TEXT? If an app does SetClipboardData(CF_UNICODETEXT, L"string one"), then GetClipboardData(CF_TEXT) gives "string one", then the app calls SetClipboardData(CF_UNICODETEXT, L"string two"), but GetClipboardData(CF_TEXT) still gives "string one". The same applies if it's the X11 driver making the calls to SetClipboardData() due to the X selection owner setting new data. Will the X11 driver clear the clipboard on each update by the other X client? If so, will Wine be stealing selection ownership from the other X client each time it changes? Given multiple Wine processes, will they be competing for it? The way I envisioned this was that synthesis would be entirely a query-time phenomenon, perhaps with some caching within user32. So, CountClipboardFormats(), EnumClipboardFormats(), IsClipboardFormatAvailable(), and GetClipboardData() would call into the driver and get a list of the real formats. User32 would then add in any missing formats that are synthesized from those real formats and include them in the count/enumeration/availability check. And, of course, GetClipboardData() would actually synthesize the data, as necessary. None of this would be "stored" on the clipboard in the sense of SetClipboardData(). The drivers would not be informed of the synthesized formats or data. -Ken

Sept. 9, 2016

Re: [v2] preloader: Allow a debugger to find ld.so's rendezvous-struct

by Keno Fischer

Ok, that can probably be done with some linker script magic, since this is merely a warning in the assembler. I'll take a look at that. On Thu, Sep 8, 2016 at 10:36 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Keno Fischer <keno(a)juliacomputing.com> writes: > >> Whether .dynamic is writable depends on the architecture (I believe >> the only one on which it isn't is MIPS, but I could be wrong about >> that). Looks like binutils doesn't take that into account when issuing >> this diagnostic in the assembler and expects .dynamic to have >> SHF_ALLOC only. Probably something to complain about to them. I don't >> believe there's an actual problem though, just an incorrect >> diagnostic. > > We don't want to introduce build warnings though, so even if this is a > binutils bug it would have to be avoided somehow. > > -- > Alexandre Julliard > julliard(a)winehq.org

Sept. 9, 2016

Re: [v2] preloader: Allow a debugger to find ld.so's rendezvous-struct

by Alexandre Julliard

Keno Fischer <keno(a)juliacomputing.com> writes: > Whether .dynamic is writable depends on the architecture (I believe > the only one on which it isn't is MIPS, but I could be wrong about > that). Looks like binutils doesn't take that into account when issuing > this diagnostic in the assembler and expects .dynamic to have > SHF_ALLOC only. Probably something to complain about to them. I don't > believe there's an actual problem though, just an incorrect > diagnostic. We don't want to introduce build warnings though, so even if this is a binutils bug it would have to be avoided somehow. -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2016

Re: [v2] preloader: Allow a debugger to find ld.so's rendezvous-struct

by Keno Fischer

Whether .dynamic is writable depends on the architecture (I believe the only one on which it isn't is MIPS, but I could be wrong about that). Looks like binutils doesn't take that into account when issuing this diagnostic in the assembler and expects .dynamic to have SHF_ALLOC only. Probably something to complain about to them. I don't believe there's an actual problem though, just an incorrect diagnostic.

Sept. 9, 2016

Re: [v2] preloader: Allow a debugger to find ld.so's rendezvous-struct

by Alexandre Julliard

Keno Fischer <keno(a)juliacomputing.com> writes: > @@ -123,6 +123,18 @@ static struct wine_preload_info preload_info[] = > { 0, 0 } /* end of list */ > }; > > +/* A fake .dynamic section through which we can inform the debugger of the > + address of the chain-loaded dynamic linker's rendezvous struct */ > +__asm__( > +".section .dynamic,\"aw\"\n" > +".global _DYNAMIC\n" > +"_DYNAMIC: .quad 21\n" // DT_DEBUG > +".quad 0\n" > +".quad 0\n" > +".quad 0\n" > +".previous\n" > +); This is causing a warning here: gcc -m32 -c -o preloader.o preloader.c -I. -I../include -D__WINESRC__ -fno-builtin -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror -g -O2 -fno-diagnostics-show-caret {standard input}: Assembler messages: {standard input}:5: Warning: setting incorrect section attributes for .dynamic -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Alexandre Julliard

Ken Thomases <ken(a)codeweavers.com> writes: > On Sep 7, 2016, at 10:48 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> 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. The plan is that the driver will be modified to go through the Windows API. So if some X client puts text on the clipboard, the X11 driver will do a SetClipboardData(CF_UNICODETEXT), and user32 will then synthesize the others. -- Alexandre Julliard julliard(a)winehq.org

Sept. 9, 2016

Re: [PATCH 2/2] mscoree: There can be only one QI implementation i a COM object!

by Vincent Povirk

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 > >

Sept. 9, 2016

Re: [3/3] jscript: Allocate string of correct size in Date toTimeString method.

by Marvin

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

Sept. 8, 2016

Wine Staging release notes

by Theodore Dubois

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

Sept. 8, 2016

Re: [2/3] jscript: Properly handle \0 characters in String indexOf method.

by Marvin

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

Sept. 8, 2016

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

by Marvin

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

Sept. 8, 2016

Re: Alexandre Julliard : winex11: Remove support for synthesizing clipboard formats.

by Ken Thomases

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

Sept. 8, 2016

Re: shlwapi: Use debugstr_w() in TRACE() message.

by Nikolay Sivov

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.

Sept. 8, 2016

Re: [PATCH] bcrypt/tests: Show that BCryptGetFipsAlgorithmMode checks a registry key

by Sebastian Lackner

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); > + }

Sept. 8, 2016

Re: [PATCH] bcrypt/tests: Add more BCryptGetFipsAlgorithmMode tests

by Bruno Jesus

On Thu, Sep 8, 2016 at 11:36 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Is it intentional that you test everything twice? It would be > sufficient to add the "result == expected" check to the existing > testcase above. Oops, you are right. When Kai made these tests there were no previous tests, I'll fix and resend. Thanks =)

Sept. 8, 2016

Re: user32/tests: Fix incorrect usage of broken() function. (v2)

by Marvin

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

Sept. 8, 2016

Re: [PATCH] d2d1: Initial implementation of DC render target

by Marvin

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

Sept. 8, 2016

Re: jscript/tests: Fix incorrect usage of broken() function.

by Jacek Caban

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

Sept. 8, 2016

Re: [PATCH] bcrypt/tests: Add more BCryptGetFipsAlgorithmMode tests

by Sebastian Lackner

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) >

Sept. 8, 2016

Re: user32/tests: Fix incorrect usage of broken() function.

by Sebastian Lackner

On 08.09.2016 13:04, Marvin wrote: > 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 > > The test failure in line 15529 looks new, I fear you'll have to send an updated version and catch this error (ERROR_GEN_FAILURE), too.

Sept. 8, 2016

Re: user32/tests: Fix incorrect usage of broken() function.

by Marvin

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

Sept. 8, 2016

Re: shell32/tests: Fix incorrect usage of broken() function.

by Nikolay Sivov

On 08.09.2016 13:27, Sebastian Lackner wrote: > On 08.09.2016 12:19, Nikolay Sivov wrote: >> 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. > > Without the broken() it fails basically everywhere: > https://newtestbot.winehq.org/JobDetails.pl?Key=25676 > > Please note that I'm not adding the broken(...), it was already there before > but used incorrectly and hiding this test failure. If you have a different > solution in mind, feel free to propose an alternative patch. No, you're right, broken() was an equivalent of '|| 1' before your change, so this test could never fail on windows. > >> >>> 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 */ >>> >> >> >> >

Sept. 8, 2016

Re: shell32/tests: Fix incorrect usage of broken() function.

by Sebastian Lackner

On 08.09.2016 12:19, Nikolay Sivov wrote: > 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. Without the broken() it fails basically everywhere: https://newtestbot.winehq.org/JobDetails.pl?Key=25676 Please note that I'm not adding the broken(...), it was already there before but used incorrectly and hiding this test failure. If you have a different solution in mind, feel free to propose an alternative patch. > >> 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 */ >> > > >

Sept. 8, 2016

Re: shell32/tests: Fix incorrect usage of broken() function.

by Nikolay Sivov

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 */ >

Sept. 8, 2016

Re: [PATCH 2/2] dxgi: Added partial implementation of GetDC()/ReleaseDC()

by Henri Verbeet

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.

Sept. 8, 2016

Re: [2/3] vcomp: Implement _vcomp_reduction_r4 and add tests.

by Sebastian Lackner

On 08.09.2016 11:18, Henri Verbeet wrote: > 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? > > Thanks for the feedback. I've sent an updated version including tests for -0.0, which shows that the current implementation matches Windows behavior. Of course that does not necessarily mean that they implement it the same way, but its at least not just matching the bit pattern of +0.0. Regards, Sebastian

Sept. 8, 2016

Re: vcomp: Implement _vcomp_reduction_r4 and add tests. (v2)

by Marvin

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

Sept. 8, 2016

Re: [2/3] vcomp: Implement _vcomp_reduction_r4 and add tests.

by Henri Verbeet

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?

Sept. 8, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Aric Stewart

On 9/7/16 9:05 PM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> On 9/7/16 8:14 PM, Alexandre Julliard wrote: >>> Aric Stewart <aric(a)codeweavers.com> writes: >>> >>>> On 9/7/16 5:08 AM, Sebastian Lackner wrote: >>>>> Wouldn't it be better to return an error such that IoCreateDriver() fails? >>>> >>>> No I personally don't think so. We are successfully loading just disabled or not doing anything. >>> >>> How is this useful? And why do you need a disable option? >> >> It mostly comes from when the hidraw bus and linux event bus where >> separate drivers. Where there would be a real reason to want to be >> able to disable one or the other. >> >> There could be future cases as well where multiple drivers are loaded >> in the base winebus.sys and a user would want to have granularity in >> their ability to turn individual ones on and off. > > If that ever becomes needed, I'd suggest to then split the drivers so > that they can be controlled individually through the standard service > interface. It doesn't seem necessary for the first version though. > ok v6 patches for the 2 parts that changed sent to remove disabling whole busses -aric

Sept. 8, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > On 9/7/16 8:14 PM, Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> On 9/7/16 5:08 AM, Sebastian Lackner wrote: >>>> Wouldn't it be better to return an error such that IoCreateDriver() fails? >>> >>> No I personally don't think so. We are successfully loading just disabled or not doing anything. >> >> How is this useful? And why do you need a disable option? > > It mostly comes from when the hidraw bus and linux event bus where > separate drivers. Where there would be a real reason to want to be > able to disable one or the other. > > There could be future cases as well where multiple drivers are loaded > in the base winebus.sys and a user would want to have granularity in > their ability to turn individual ones on and off. If that ever becomes needed, I'd suggest to then split the drivers so that they can be controlled individually through the standard service interface. It doesn't seem necessary for the first version though. -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2016

Re: [2/3] user32: Add missing calls to GlobalUnlock in render_synthesized_dib.

by Alexandre Julliard

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

Sept. 8, 2016

Re: Getting backtraces from services without crash dialog

by Austin English

On Wed, Sep 7, 2016 at 8:18 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > I haven't tried this, but my suggestion would be to replace the > WriteFile in dbg_outputA with a call to wine_dbg_printf, something > like: > > wine_dbg_printf("%.*s", i, line_buff); > > On Tue, Sep 6, 2016 at 7:18 PM, Austin English <austinenglish(a)gmail.com> wrote: >> 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 >> >> Thanks Vincent. The backtraces were interspersed with fixme's (not unexpected), but other than that, worked great, thanks. -- -Austin GPG: 14FB D7EA A041 937B

Sept. 8, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Aric Stewart

On 9/7/16 8:14 PM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> On 9/7/16 5:08 AM, Sebastian Lackner wrote: >>> Wouldn't it be better to return an error such that IoCreateDriver() fails? >> >> No I personally don't think so. We are successfully loading just disabled or not doing anything. > > How is this useful? And why do you need a disable option? > It mostly comes from when the hidraw bus and linux event bus where separate drivers. Where there would be a real reason to want to be able to disable one or the other. There could be future cases as well where multiple drivers are loaded in the base winebus.sys and a user would want to have granularity in their ability to turn individual ones on and off. -aric

Sept. 8, 2016

Re: Getting backtraces from services without crash dialog

by Vincent Povirk

I haven't tried this, but my suggestion would be to replace the WriteFile in dbg_outputA with a call to wine_dbg_printf, something like: wine_dbg_printf("%.*s", i, line_buff); On Tue, Sep 6, 2016 at 7:18 PM, Austin English <austinenglish(a)gmail.com> wrote: > 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 > >

Sept. 8, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > On 9/7/16 5:08 AM, Sebastian Lackner wrote: >> Wouldn't it be better to return an error such that IoCreateDriver() fails? > > No I personally don't think so. We are successfully loading just disabled or not doing anything. How is this useful? And why do you need a disable option? -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Aric Stewart

On 9/7/16 5:08 AM, Sebastian Lackner wrote: > 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 ++- . . . >> + 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? No I personally don't think so. We are successfully loading just disabled or not doing anything. > >> + } >> + >> + 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? Same as above. > >> +} >> + >> +#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 >> >> >> >

Sept. 7, 2016

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

by Marvin

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

Sept. 7, 2016

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

by Marvin

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

Sept. 7, 2016

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.

by Jacek Caban

On 07.09.2016 17:55, Sebastian Lackner wrote: > 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. Yeah, sorry about that. Jacek

Sept. 7, 2016

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.

by Sebastian Lackner

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... ;)

Sept. 7, 2016

Re: winmm/tests: Pass the full size of MIDIHDR to midiOutPrepareHeader().

by Huw Davies

On 7 Sep 2016, at 11:24, Marvin <testbot(a)winehq.org> wrote: > === 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 These are unrelated. Interestingly, a quick google[1] suggested calling CoInitialiseEx() prior to calling midiOutOpen(), and indeed doing so does fix these errors. Huw. [1] http://stackoverflow.com/questions/31752786/midioutopen-on-windows-10-using…

Sept. 7, 2016

Re: winmm/tests: Pass the full size of MIDIHDR to midiOutPrepareHeader().

by Marvin

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

Sept. 7, 2016

Re: [PATCH v4 7/20] winebus.sys: Add Linux udev bus

by Sebastian Lackner

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 > > >

Sept. 7, 2016

Re: [PATCH v3 06/20] configure: Add support for udev

by Sebastian Lackner

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 > > > >

Sept. 7, 2016

Re: [PATCH v4 3/20] ntoskrnl.exe: Implement loading plug and play devices

by Sebastian Lackner

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

Sept. 7, 2016

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.

by Sebastian Lackner

On 07.09.2016 10:34, Jacek Caban wrote: > 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 > > Thanks, I didn't encounter that with my compiler (GCC 6.1.1). I've sent an updated version.

Sept. 7, 2016

Re: [1/2] jscript: Return NULL if jsstr_substr fails.

by Jacek Caban

On 07.09.2016 08:45, Sebastian Lackner wrote: > On 06.09.2016 15:26, Sebastian Lackner wrote: >> On 06.09.2016 12:27, Jacek Caban wrote: >>> 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 >>> >>> >> Good catch. Yes, the current function signature makes it very easy to do >> things wrong. If you want me to prepare an updated patch I can do that, >> but I also don't mind if you want to prepare a patch yourself. >> >> Best regards, >> Sebastian >> > I've just sent a patch, but feel free to ignore it if you have already been > working on your own version. Thanks. > By the way, there is another aspect which makes jsstr_alloc_buf very hard to > use, which is that we have to know the exact buffer size in advance. As a > result there are also places where it is done wrong, for example > Date_toTimeString which passes the maximum required buffer size, but does not > update ->length_flags afterwards. Are you fine with adding something like > > jsstr_shrink_buf(jsstr_t *) > or > jsstr_shrink_buf(jsstr_t *, unsigned) > > to fix this, or do we really want to fix the length calculation instead? I'm not opposed to this function if really needed, but in cases where we can avoid it, I'd much rather do that. In case of Date_toTimeStringi avoiding it seems easy. There is constant and relatively small maximum buffer size and the code path is not performance critical, so I'd say that using a buffer on stack to prepare the result and then pass it to jsstr_alloc would be nicer IMHO. Thanks, Jacek

Sept. 7, 2016

Re: jscript: Change prototype of jsstr_alloc_buf and fix some error handling issues.

by Jacek Caban

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

Sept. 7, 2016

Re: [PATCH 1/6] ddraw/tests: Add position tests for D3DPROCESSVERTICES_TRANSFORM.

by Henri Verbeet

On 6 September 2016 at 21:16, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2016-09-05 um 12:16 schrieb Henri Verbeet: >> 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 > Sounds like the clear isn't limited to the viewport dimensions. I > vaguely remember seeing that on Windows before. Is that on AMD? > AMD, yes.

Sept. 7, 2016

Re: [1/2] jscript: Return NULL if jsstr_substr fails.

by Sebastian Lackner

On 06.09.2016 15:26, Sebastian Lackner wrote: > On 06.09.2016 12:27, Jacek Caban wrote: >> 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 >> >> > > Good catch. Yes, the current function signature makes it very easy to do > things wrong. If you want me to prepare an updated patch I can do that, > but I also don't mind if you want to prepare a patch yourself. > > Best regards, > Sebastian > I've just sent a patch, but feel free to ignore it if you have already been working on your own version. By the way, there is another aspect which makes jsstr_alloc_buf very hard to use, which is that we have to know the exact buffer size in advance. As a result there are also places where it is done wrong, for example Date_toTimeString which passes the maximum required buffer size, but does not update ->length_flags afterwards. Are you fine with adding something like jsstr_shrink_buf(jsstr_t *) or jsstr_shrink_buf(jsstr_t *, unsigned) to fix this, or do we really want to fix the length calculation instead? Regards, Sebastian

Sept. 7, 2016

Re: [PATCH] ws2_32/tests: Add non-interactive SIO_ADDRESS_LIST_CHANGE tests

by Bruno Jesus

On Wed, Sep 7, 2016 at 12:04 AM, Marvin <testbot(a)winehq.org> wrote: > 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 Well known handle failure, clean run https://testbot.winehq.org/JobDetails.pl?Key=25615

Sept. 7, 2016

Re: [PATCH] ws2_32/tests: Add non-interactive SIO_ADDRESS_LIST_CHANGE tests

by Marvin

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

Sept. 7, 2016

Re: [v2 PATCH] ws2_32: accept addrlen32 parameter is optional

by Marvin

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

Sept. 7, 2016

Re: [PATCH] ws2_32: accept addrlelen32 parameter is optional

by Bruno Jesus

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

Sept. 7, 2016

Getting backtraces from services without crash dialog

by Austin English

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

Sept. 7, 2016

Re: [PATCH 1/6] ddraw/tests: Add position tests for D3DPROCESSVERTICES_TRANSFORM.

by Stefan Dösinger

Am 2016-09-05 um 12:16 schrieb Henri Verbeet: > 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 Sounds like the clear isn't limited to the viewport dimensions. I vaguely remember seeing that on Windows before. Is that on AMD? It will be a while before I can send an updated patch. My next weekends are full...

Sept. 6, 2016

Re: setupapi/tests: Also check for ERROR_CALL_NOT_IMPLEMENTED at the second call to SetupDiCreateDeviceInfoListExW

by Marvin

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

Sept. 6, 2016

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

by Piotr Caban

On 05/09/16 12:30, Huw Davies wrote: >> === w864 (32 bit msg) === >> msg.c:13939: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 > This has never worked on Win 8 or Win 10: > https://www.winehq.org/pipermail/wine-devel/2016-August/114541.html > > Piotr, could you take a look please? I'll take a look on it when I'm back from vacation (next week). Thanks, Piotr

Sept. 6, 2016

Re: [PATCH v3 07/20] winebus.sys: Add Linux udev bus

by Thomas Faber

> +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; > +}

Sept. 6, 2016

Re: [PATCH v3 03/20] ntoskrnl.exe: Implement loading plug and play devices

by Aric Stewart

On 9/6/16 8:56 AM, Thomas Faber wrote: > Yep, the new version addresses all of my concerns, thanks. > > One more thing, should this function not call ObReferenceObject, > or does that not make a difference in Wine (yet)? > >> +/*********************************************************************** >> + * IoGetAttachedDeviceReference (NTOSKRNL.EXE.@) >> + */ >> +DEVICE_OBJECT* WINAPI IoGetAttachedDeviceReference( DEVICE_OBJECT *device ) >> +{ >> + TRACE( "semi-stub: %p\n", device ); >> + return IoGetAttachedDevice(device); >> } > > Thanks, > Thomas > It makes no difference in Wine (yet) as we are not ref-counting devices yet. That is why I put in the semi-stub message. Thanks, -aric > > On 2016-09-04 04:13, Aric Stewart wrote: >> Well I carved out some time to get a v4 our the door this evening. >> >> Thanks again for the review! >> -aric >> >> On 9/2/16 4:03 PM, Thomas Faber wrote: >>>> @@ -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; >>>> + } >>>> } >>>> >>>> >

Sept. 6, 2016

Re: [PATCH v3 03/20] ntoskrnl.exe: Implement loading plug and play devices

by Thomas Faber

Yep, the new version addresses all of my concerns, thanks. One more thing, should this function not call ObReferenceObject, or does that not make a difference in Wine (yet)? > +/*********************************************************************** > + * IoGetAttachedDeviceReference (NTOSKRNL.EXE.@) > + */ > +DEVICE_OBJECT* WINAPI IoGetAttachedDeviceReference( DEVICE_OBJECT *device ) > +{ > + TRACE( "semi-stub: %p\n", device ); > + return IoGetAttachedDevice(device); > } Thanks, Thomas On 2016-09-04 04:13, Aric Stewart wrote: > Well I carved out some time to get a v4 our the door this evening. > > Thanks again for the review! > -aric > > On 9/2/16 4:03 PM, Thomas Faber wrote: >>> @@ -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; >>> + } >>> } >>> >>>

Sept. 6, 2016

Re: [1/2] jscript: Return NULL if jsstr_substr fails.

by Sebastian Lackner

On 06.09.2016 12:27, Jacek Caban wrote: > 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 > > Good catch. Yes, the current function signature makes it very easy to do things wrong. If you want me to prepare an updated patch I can do that, but I also don't mind if you want to prepare a patch yourself. Best regards, Sebastian

Sept. 6, 2016

Re: taskschd: Added ITaskDefinition::get_Triggers implementation.

by Marvin

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

Sept. 6, 2016

Re: [PATCH v2] d3d11/tests: Extend GetDC() tests

by Henri Verbeet

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.

Sept. 6, 2016

Re: [1/2] jscript: Return NULL if jsstr_substr fails.

by Jacek Caban

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

Sept. 6, 2016

Re: [PATCH] d3d11/tests: Extend GetDC() tests

by Henri Verbeet

On 6 September 2016 at 11:01, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Not right now, no. I think it's safe to remove masks and bit count, as > all documented formats are 8888. I think it's better to keep > getdc_supported though, making it easy to add unsupported cases later. > Maybe, but validating the code for those cases would require adding them.

Sept. 6, 2016

Re: [PATCH] d3d11/tests: Extend GetDC() tests

by Nikolay Sivov

On 06.09.2016 11:54, Henri Verbeet wrote: > 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? > Not right now, no. I think it's safe to remove masks and bit count, as all documented formats are 8888. I think it's better to keep getdc_supported though, making it easy to add unsupported cases later.

Sept. 6, 2016

Re: [PATCH] d3d11/tests: Extend GetDC() tests

by Henri Verbeet

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?

Sept. 6, 2016

Re: include: Avoid overflow (warning) in RGBA_MAKE.

by Henri Verbeet

On 6 September 2016 at 08:41, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > >> --- a/include/d3dtypes.h >> +++ b/include/d3dtypes.h >> @@ -53,7 +53,7 @@ typedef LONG D3DFIXED; >> #define RGBA_GETRED(rgb) (((rgb) >> 16) & 0xff) >> #define RGBA_GETGREEN(rgb) (((rgb) >> 8) & 0xff) >> #define RGBA_GETBLUE(rgb) ((rgb) & 0xff) >> -#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | ((g) << 8) | (b))) >> +#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((unsigned)(a) << 24) | ((r) << 16) | ((g) << 8) | (b))) > > This is a public header, probably you need to fix the callers of this macro > instead. > Signed overflow is undefined, so this change is compatible. It's also unlikely to be an issue in practice on any architecture we support. I might have preferred something similar to D3DCOLOR_ARGB though. That's not to say the users of the macro don't have room for improvement.

Sept. 6, 2016

Re: include: Avoid overflow (warning) in RGBA_MAKE.

by Dmitry Timoshkov

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > --- a/include/d3dtypes.h > +++ b/include/d3dtypes.h > @@ -53,7 +53,7 @@ typedef LONG D3DFIXED; > #define RGBA_GETRED(rgb) (((rgb) >> 16) & 0xff) > #define RGBA_GETGREEN(rgb) (((rgb) >> 8) & 0xff) > #define RGBA_GETBLUE(rgb) ((rgb) & 0xff) > -#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((a) << 24) | ((r) << 16) | ((g) << 8) | (b))) > +#define RGBA_MAKE(r, g, b, a) ((D3DCOLOR) (((unsigned)(a) << 24) | ((r) << 16) | ((g) << 8) | (b))) This is a public header, probably you need to fix the callers of this macro instead. -- Dmitry.

Sept. 6, 2016

Re: [PATCH v11 3/3] shell32: Implement FolderItems_get_Count.

by Marvin

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

Sept. 6, 2016

Re: [PATCH v11 2/3] shell32: Implement FolderItems_Item.

by Marvin

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

Sept. 6, 2016

Re: [PATCH] d3dxof: avoid some strcpy overflows (Coverity)

by Henri Verbeet

On 6 September 2016 at 01:41, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Hmm, unless there is something guaranteeing that the name can't be > longer than 100 bytes (and there might be, I haven't looked too > deeply) a check is still needed. Right, it checks the input buffer size, but not the output buffer size. Still, you effectively calculate the length of the name in "pos".

Sept. 6, 2016

Re: [PATCH] winejoystick.drv: Revert 62876f3fc5feb1ca23d27a6de5adca580d963d0c

by Matteo Bruni

2016-09-05 19:20 GMT+02:00 Sebastian Lackner <sebastian(a)fds-team.de>: > On 05.09.2016 18:28, Bruno Jesus wrote: >> On Monday, September 5, 2016, Sebastian Lackner <sebastian(a)fds-team.de> >> wrote: >> >>> 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 <javascript:;>> >>>> --- >>>> 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. >> >> >> Hiho, nobody ever complained about a similar problem before, the patch was >> benefiting only myself and really the HID changes are going to erase all >> the code so it would be a "temporary change". Investing more time in the >> other patch is waste of time IMO. > > If it was fixing a real bug for you, it most likely also affected other users > (even if there is no bug report about it). Yeah, reverting a fix because it introduces a regression when there is a potential clean fix for the regression itself doesn't seem like the right choice, ever.

Sept. 5, 2016

Re: HLSL compiler

by Matteo Bruni

2016-09-05 19:57 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>: > On Friday, September 2, 2016 7:45:04 PM CEST you wrote: >> I don't see a parser rule for function calls at the moment. Looking at >> my private branch, I have an additional VAR_IDENTIFIER '(' >> func_arguments ')' rule for the postfix_expr nonterminal. >> >> In general, the parser should be in pretty decent shape, if missing >> some rules. Everything else (IR transformation / optimization, >> codegen) is just not there at the moment. >> >> Somewhat related: the current IR probably isn't quite optimal. It's a >> tree IR, quite strongly inspired by the one from the current GLSL >> compiler in Mesa. At least two issues with it are that memory usage >> can get relatively high and some optimizations are difficult to do >> with it. Fortunately we don't need to do too much optimization since >> there is another compiler down the line (e.g. GLSL compiler in the >> OpenGL drivers) which should be able to cover up our shortcomings... > > Thanks, I think I can work with that. Probably need to implement a few DX11 > functions first if I want to test it though. > > Also, I should probably write some tests. How would one go about that, just > compile a few shaders and try if we can render them? Though I feel like it > would be better to test the bytecode somehow to rule out errors in wined3d. Have a look at the existing tests in d3dcompiler_43/tests/hlsl.c. There is room for improvement there (like adding more tests with interesting constructs e.g. loops) but those should be an okay starting point.

Sept. 5, 2016