March 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] comctl32/propsheet: Make the PROPSHEET_RemovePage function similar to PROPSHEET_CleanUp
by Nikolay Sivov March 9, 2017

March 9, 2017

On 09.03.2017 23:20, Hermès BÉLUSCA-MAÏTO wrote: > [PATCH 2/2] comctl32/propsheet: Make the PROPSHEET_RemovePage function > similar to PROPSHEET_CleanUp: > > - Use an auxiliary psp pointer to hold the psInfo->proppage[index].hpage; > > - Check psInfo->proppage[index].hwndPage before destroying the > associated window. > > /* Destroy page dialog window */ > - DestroyWindow(psInfo->proppage[index].hwndPage); > + if(psInfo->proppage[index].hwndPage) > + DestroyWindow(psInfo->proppage[index].hwndPage); Why is this important?

1 0

Re: [1/4] webservices: Unlock critical section before returning.
by Alexandre Julliard March 9, 2017

March 9, 2017

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Do I have to send feedback to the patches list to make sure it is not missed? ;) Sorry about that. Having replies go to the patches list would make things easier for me, but I expect others prefer to keep wine-patches only for patches. OTOH we already have signoffs in there... -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: [PATCH] user32: Always send WM_NCACTIVATE when changing the foreground window.
by Alexandre Julliard March 9, 2017

March 9, 2017

Alex Henrie <alexhenrie24(a)gmail.com> writes: > + if (send_msg_old) /* old window belongs to other thread */ > + SendNotifyMessageW( previous, WM_WINE_SETACTIVEWINDOW, 0, 0 ); > + else if (send_msg_new) /* old window belongs to us but new one to other thread */ > + ret = set_active_window( 0, NULL, mouse, TRUE ); > + > + if (GetActiveWindow() == hwnd) > { The active window is per-thread but SetForegroundWindow works across threads, so this can't do the right thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 10/10] wininet/tests: Added more HTTP read tests.
by Marvin March 9, 2017

March 9, 2017

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=29364 Your paranoid android. === wxppro (32 bit http) === http.c:5050: Test failed: http.c:314: Test failed: InternetReadFileExW failed: 997 http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:4634: Test failed: expected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) 1 times, received 2 times === wvistau64 (32 bit http) === http.c:5050: Test failed: InternetReadFileExW failed: 997 http.c:5056: Test failed: InternetQueryDataAvailable returned: 1(997) http.c:5056: Test failed: size = 10 http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:5060: Test failed: dwBufferLength = 10 http.c:5061: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 1 times, received 0 times http.c:5062: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 0 times http.c:314: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:314: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:5104: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 1 times, received 2 times http.c:5105: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 2 times === w2008s64 (32 bit http) === http.c:5050: Test failed: InternetReadFileExW failed: 997 http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:5061: Test failed: expected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) 1 times, received 0 times http.c:5062: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 0 times http.c:314: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:4634: Test failed: expected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) 1 times, received 2 times http.c:5105: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 2 times === wvistau64 (64 bit http) === http.c:5050: Test failed: InternetReadFileExW failed: 997 http.c:314: Test failed: http.c:382: 0364:Callback 0000000000CC0014 0xdeadbeef INTERNET_STATUS_CLOSING_CONNECTION 0000000000000000 0 http.c:4731: Test failed: expected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) 1 times, received 2 times === w2008s64 (64 bit http) === http.c:5050: Test failed: http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:5062: Test failed: expected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) 1 times, received 0 times http.c:314: Test failed: unexpected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) http.c:4634: Test failed: expected status 100 (INTERNET_STATUS_REQUEST_COMPLETE) 1 times, received 2 times

2 1

Re: [PATCH 05/10] wininet: Rewrite InternetReadFileEx for http protocol to make use of non-blocking reads.
by Marvin March 9, 2017

March 9, 2017

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=29362 Your paranoid android. === w2008s64 (64 bit http) === http.c:628: Test failed: req_error = 12029 http.c:652: Test failed: expected status 30 (INTERNET_STATUS_SENDING_REQUEST) 1 times, received 0 times http.c:653: Test failed: expected status 31 (INTERNET_STATUS_REQUEST_SENT) 1 times, received 0 times http.c:654: Test failed: expected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) 1 times, received 0 times http.c:655: Test failed: expected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) 1 times, received 0 times http.c:664: Test failed: flags = 8, expected 0 0b30:http: unhandled exception c0000005 at 00000000004162E8

1 0

Re: [PATCH 1/5] winebus.sys: Handle linux input event device via udev
by Sebastian Lackner March 9, 2017

March 9, 2017

On 27.02.2017 16:09, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 + > dlls/winebus.sys/bus_udev.c | 150 ++++++++++++++++++++++++++++++++++++++++++-- > dlls/winebus.sys/main.c | 26 ++++++++ > 3 files changed, 173 insertions(+), 6 deletions(-) > I assume this is meant as a fallback, if we don't have access to hidraw, right? If you plan to use this as a replacement for dinput, it would be better to implement it without fixed dependency on udev. > > > 0001-winebus.sys-Handle-linux-input-event-device-via-udev.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index effbd4afd0..fed35e8c1e 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -43,3 +43,6 @@ DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > + > +/* General Bus Functions */ > +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 415bd3db08..2dcc7fb442 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -42,6 +42,14 @@ > # include <sys/ioctl.h> > #endif > > +#ifdef HAVE_LINUX_INPUT_H > +# include <linux/input.h> > +# undef SW_MAX > +# if defined(EVIOCGBIT) && defined(EV_ABS) && defined(BTN_PINKIE) > +# define HAS_PROPER_INPUT_HEADER > +# endif > +#endif > + > #define NONAMELESSUNION > > #include "ntstatus.h" > @@ -65,11 +73,15 @@ WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > +static DWORD disable_hidraw = 0; > +static DWORD disable_input = 0; > > static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > +static const WCHAR lnxev_busidW[] = {'L','N','X','E','V',0}; > > #include "initguid.h" > DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); > +DEFINE_GUID(GUID_DEVCLASS_LINUXEVENT, 0x1b932c0d,0xfea7,0x42cd,0x8e,0xaa,0x0e,0x48,0x79,0xb6,0x9e,0xaa); > > struct platform_private > { > @@ -392,6 +404,52 @@ static const platform_vtbl hidraw_vtbl = > hidraw_set_feature_report, > }; > > +#ifdef HAS_PROPER_INPUT_HEADER > + > +static NTSTATUS lnxev_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS lnxev_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS lnxev_begin_report_processing(DEVICE_OBJECT *device) > +{ > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS lnxev_set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > +{ > + *written = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS lnxev_get_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *read) > +{ > + *read = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static NTSTATUS lnxev_set_feature_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > +{ > + *written = 0; > + return STATUS_NOT_IMPLEMENTED; > +} > + > +static const platform_vtbl lnxev_vtbl = { > + compare_platform_device, > + lnxev_get_reportdescriptor, > + lnxev_get_string, > + lnxev_begin_report_processing, > + lnxev_set_output_report, > + lnxev_get_feature_report, > + lnxev_set_feature_report, > +}; > +#endif > + > static void try_add_device(struct udev_device *dev) > { > DWORD vid = 0, pid = 0, version = 0; > @@ -400,6 +458,7 @@ static void try_add_device(struct udev_device *dev) > const char *subsystem; > const char *devnode; > WCHAR *serial = NULL; > + const char* gamepad = NULL; > int fd; > > if (!(devnode = udev_device_get_devnode(dev))) > @@ -419,6 +478,26 @@ static void try_add_device(struct udev_device *dev) > version = get_sysattr_dword(usbdev, "version", 10); > serial = get_sysattr_string(usbdev, "serial"); > } > +#ifdef HAS_PROPER_INPUT_HEADER > + else > + { > + struct input_id device_id = {0}; > + char device_uid[255] = {0}; > + > + if (ioctl(fd, EVIOCGID, &device_id) == -1) > + WARN("ioctl(EVIOCGID) failed: %d %s\n", errno, strerror(errno)); > + if (ioctl(fd, EVIOCGUNIQ(254), device_uid) && device_uid[0]) > + MultiByteToWideChar(CP_UNIXCP, 0, device_uid, -1, serial, 255); I don't think this will work as expected. serial is a NULL pointer, and the check if ioctl() was successful is also done wrong. On error a value < 0 is returned. > + > + gamepad = udev_device_get_property_value(dev, "ID_INPUT_JOYSTICK"); > + vid = device_id.vendor; > + pid = device_id.product; > + version = device_id.version; > + } > +#else > + else > + WARN("Could not get device to query VID, PID, Version and Serial\n"); > +#endif > > TRACE("Found udev device %s (vid %04x, pid %04x, version %u, serial %s)\n", > debugstr_a(devnode), vid, pid, version, debugstr_w(serial)); > @@ -429,6 +508,12 @@ static void try_add_device(struct udev_device *dev) > 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)); > } > +#ifdef HAS_PROPER_INPUT_HEADER > + else if (strcmp(subsystem, "input") == 0) > + { > + device = bus_create_hid_device(udev_driver_obj, lnxev_busidW, vid, pid, version, 0, serial, (gamepad != NULL), &GUID_DEVCLASS_LINUXEVENT, &lnxev_vtbl, sizeof(struct platform_private)); Some linebreaks wouldn't hurt. > + } > +#endif > > if (device) > { > @@ -448,8 +533,17 @@ static void try_add_device(struct udev_device *dev) > > static void try_remove_device(struct udev_device *dev) > { > - DEVICE_OBJECT *device = bus_find_hid_device(&hidraw_vtbl, dev); > - struct platform_private *private; > + DEVICE_OBJECT *device = NULL; > + const char* subsystem; > + struct platform_private* private; > + > + subsystem = udev_device_get_subsystem(dev); > + if (strcmp(subsystem, "hidraw") == 0) > + device = bus_find_hid_device(&hidraw_vtbl, dev); > +#ifdef HAS_PROPER_INPUT_HEADER > + else if (strcmp(subsystem, "input") == 0) > + device = bus_find_hid_device(&lnxev_vtbl, dev); > +#endif It might be easier to just check both after each other, like: device = bus_find_hid_device(...); if (!device) device = bus_find_hid_device(...); > if (!device) return; > > IoInvalidateDeviceRelations(device, RemovalRelations); > @@ -483,8 +577,18 @@ static void build_initial_deviceset(void) > return; > } > > - if (udev_enumerate_add_match_subsystem(enumerate, "hidraw") < 0) > - WARN("Failed to add subsystem 'hidraw' to enumeration\n"); > + if (!disable_hidraw) > + if (udev_enumerate_add_match_subsystem(enumerate, "hidraw") < 0) > + WARN("Failed to add subsystem 'hidraw' to enumeration\n"); > +#ifdef HAS_PROPER_INPUT_HEADER > + if (!disable_input) > + { > + if (udev_enumerate_add_match_subsystem(enumerate, "event") < 0) > + WARN("Failed to add subsystem 'event' to enumeration\n"); Why do you add this match when results are not processed anywhere? > + if (udev_enumerate_add_match_subsystem(enumerate, "input") < 0) > + WARN("Failed to add subsystem 'input' to enumeration\n"); > + } > +#endif > > if (udev_enumerate_scan_devices(enumerate) < 0) > WARN("Enumeration scan failed\n"); > @@ -509,6 +613,7 @@ static void build_initial_deviceset(void) > static struct udev_monitor *create_monitor(struct pollfd *pfd) > { > struct udev_monitor *monitor; > + int systems = 0; > > monitor = udev_monitor_new_from_netlink(udev_context, "udev"); > if (!monitor) > @@ -517,8 +622,27 @@ static struct udev_monitor *create_monitor(struct pollfd *pfd) > return NULL; > } > > - if (udev_monitor_filter_add_match_subsystem_devtype(monitor, "hidraw", NULL) < 0) > - WARN("Failed to add subsystem 'hidraw' to monitor\n"); > + if (!disable_hidraw) > + { > + if (udev_monitor_filter_add_match_subsystem_devtype(monitor, "hidraw", NULL) < 0) > + WARN("Failed to add 'hidraw' subsystem to monitor\n"); > + else > + systems++; > + } > +#ifdef HAS_PROPER_INPUT_HEADER > + if (!disable_input) > + { > + if (udev_monitor_filter_add_match_subsystem_devtype(monitor, "input", NULL) < 0) > + WARN("Failed to add 'input' subsystem to monitor\n"); > + else > + systems++; > + } > +#endif > + if (systems == 0) > + { > + WARN("No subsystems added to monitor\n"); > + goto error; > + } > > if (udev_monitor_enable_receiving(monitor) < 0) > goto error; > @@ -589,6 +713,10 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > { > HANDLE events[2]; > DWORD result; > + 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 WCHAR input_disabledW[] = {'D','i','s','a','b','l','e',' ','i','n','p','u','t',0}; > + static const UNICODE_STRING input_disabled = {sizeof(input_disabledW) - sizeof(WCHAR), sizeof(input_disabledW), (WCHAR*)input_disabledW}; > > TRACE("(%p, %s)\n", driver, debugstr_w(registry_path->Buffer)); > > @@ -602,6 +730,16 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry > driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; > driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = hid_internal_dispatch; > > + disable_hidraw = check_bus_option(registry_path, &hidraw_disabled); > + if (disable_hidraw) > + TRACE("UDEV hidraw devices disabled in registry\n"); > + > +#ifdef HAS_PROPER_INPUT_HEADER > + disable_input = check_bus_option(registry_path, &input_disabled); > + if (disable_input) > + TRACE("UDEV input devices disabled in registry\n"); > +#endif Does it hurt when both hidraw and input event devices are found? If yes, it would be better to filter duplicates somewhere else, instead of using registry keys. > + > if (!(events[0] = CreateEventW(NULL, TRUE, FALSE, NULL))) > goto error; > if (!(events[1] = CreateThread(NULL, 0, deviceloop_thread, events[0], 0, NULL))) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 978540bb17..0388f0263c 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -625,6 +625,32 @@ void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) > LeaveCriticalSection(&ext->report_cs); > } > > +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 (NtOpenKey(&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 (NtQueryValueKey(key, option, KeyValuePartialInformation, info, sizeof(buffer), &size) == STATUS_SUCCESS) > + { > + if (info->Type == REG_DWORD) > + output = *(DWORD*)info->Data; > + } > + > + NtClose(key); > + } > + > + return output; > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

3 5

Re: [PATCH 2/8] wined3d: Unbind textures in context_bind_shader_resources().
by Henri Verbeet March 9, 2017

March 9, 2017

On 9 March 2017 at 10:03, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > > The WINED3D_LEGACY_TEXTURE_BINDING flag should prevent from generating > the "No resource view bound at index" warnings in D3D9-, allows to > safely unbind resources in context_bind_shader_resources(), and make it > easier easier to add support for more samplers in D3D10+. > The issue is texture bindings set through wined3d_device_set_texture(), right? Could we get rid of wined3d_device_set_texture() and create shader resource views for those textures instead, similar to how we create rendertarget views in d3d9, etc.? IIRC one of the issues was interactions with sampler and texture stage states. Tangentially, how does this work with "Aon9" shaders?

2 3

Re: [PATCH] crypt32/tests: Fix a memory leak in testFindCRL.
by Erich E. Hoover March 8, 2017

March 8, 2017

On Sun, Feb 26, 2017 at 11:52 PM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > ... > + store = CertOpenStore(CERT_STORE_PROV_MEMORY, 0, 0, > + CERT_STORE_CREATE_NEW_FLAG, NULL); > + if (!store) return; > + > ... Would you mind adding an error when this happens? Otherwise we may not know that these tests did not run. Best, Erich

2 2

Re: [PATCH 5/5] d3d9/tests: Fix pixel shader version check in test_pointsize().
by Marvin March 8, 2017

March 8, 2017

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=29312 Your paranoid android. === w8 (32 bit visual) === visual.c:7931: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:8099: Test failed: Got unexpected color 0x00ff0000 for no color attribute test. === w864 (64 bit visual) === visual.c:7947: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7995: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8099: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [PATCH 4/5] d3d9/tests: Skip test_vshader_input() if PS 3.0 isn't supported.
by Marvin March 8, 2017

March 8, 2017

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=29311 Your paranoid android. === w864 (32 bit visual) === visual.c:8099: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [2/8] webservices: Protect messages with a critical section.
by Sebastian Lackner March 8, 2017

March 8, 2017

On 08.03.2017 11:25, Hans Leidekker wrote: > + } > } > > msg->is_addressed = TRUE; Not sure if it matters, but previously this was skipped in case of a failure. Also please note that depending on how many objects are used by an application, a separate CS for each might significantly increase memory usage. > - return S_OK; > + > + LeaveCriticalSection( &msg->cs ); > + return hr; [...] > - msg->init = init; > - msg->state = WS_MESSAGE_STATE_INITIALIZED; > - return write_envelope( msg ); > + if ((hr = write_envelope( msg )) == S_OK) > + { > + msg->init = init; > + msg->state = WS_MESSAGE_STATE_INITIALIZED; > + } Here, the new code also does something else than the old one. Previously the msg fields were changed unconditionally.

2 1

Re: [5/8] webservices: Protect writers with a critical section.
by Sebastian Lackner March 8, 2017

March 8, 2017

On 08.03.2017 11:25, Hans Leidekker wrote: > + if ((hr = write_set_element_namespace( writer )) != S_OK) goto done; > + if ((hr = write_startelement( writer )) != S_OK) goto done; > + if ((hr = write_endstartelement( writer )) != S_OK) goto done; > writer->state = WRITER_STATE_ENDSTARTELEMENT; > + > +done: > + LeaveCriticalSection( &writer->cs ); > return S_OK; You should return hr here. > for (i = offset; i < count; i++) > { > const char *ptr = (const char *)array + (offset + i) * type_size; > - if ((hr = write_element_node( writer, NULL, localname, ns )) != S_OK) return hr; > + if ((hr = write_element_node( writer, NULL, localname, ns )) != S_OK) goto done; > if ((hr = write_type( writer, WS_ELEMENT_TYPE_MAPPING, type, NULL, WS_WRITE_REQUIRED_POINTER, > - &ptr, sizeof(ptr) )) != S_OK) return hr; > - if ((hr = write_endelement_node( writer )) != S_OK) return hr; > + &ptr, sizeof(ptr) )) != S_OK) goto done; > + if ((hr = write_endelement_node( writer )) != S_OK) goto done; > } > > - return S_OK; > +done: > + LeaveCriticalSection( &writer->cs ); > + return hr; It looks like hr will be undefined here if count == 0 > } > > /************************************************************************** > @@ -2392,9 +2662,20 @@ HRESULT WINAPI WsWriteXmlBuffer( WS_XML_WRITER *handle, WS_XML_BUFFER *buffer, W > > if (!writer || !xmlbuf) return E_INVALIDARG; > > - if ((hr = write_flush( writer )) != S_OK) return hr; > - if ((hr = write_grow_buffer( writer, xmlbuf->size )) != S_OK) return hr; > + EnterCriticalSection( &writer->cs ); > + > + if (writer->magic != WRITER_MAGIC) > + { > + LeaveCriticalSection( &writer->cs ); > + return E_INVALIDARG; > + } > + > + if ((hr = write_flush( writer )) != S_OK) goto done; > + if ((hr = write_grow_buffer( writer, xmlbuf->size )) != S_OK) goto done; > write_bytes( writer, xmlbuf->ptr, xmlbuf->size ); > + > +done: > + LeaveCriticalSection( &writer->cs ); > return S_OK; Here you should also use hr.

1 0

Re: [PATCH] kernel32/tests: Add 64bit number tests for FormatMessage[A|W] (try 2)
by Sebastian Lackner March 8, 2017

March 8, 2017

On 08.03.2017 15:42, Bruno Jesus wrote: > + { -1, "-1", 2}, > + { ULL(0xFFFFFFFF,0xFFFFFFFF), "-1", 2}, You can remove the second test. 0xffffffffffffffff and -1 are just different representations for the same number. Best regards, Sebastian

2 1

Re: bcrypt: Add a builtin sha384/sha512 implementation. (v2)
by Sebastian Lackner March 8, 2017

March 8, 2017

On 08.03.2017 12:17, Jacek Caban wrote: > On 08.03.2017 12:03, Sebastian Lackner wrote: >> +void sha512_init(SHA512_CTX *ctx) >> +{ >> + ctx->len = 0; >> + ctx->h[0] = 0x6a09e667f3bcc908; >> + ctx->h[1] = 0xbb67ae8584caa73b; >> + ctx->h[2] = 0x3c6ef372fe94f82b; >> + ctx->h[3] = 0xa54ff53a5f1d36f1; >> + ctx->h[4] = 0x510e527fade682d1; >> + ctx->h[5] = 0x9b05688c2b3e6c1f; >> + ctx->h[6] = 0x1f83d9abfb41bd6b; >> + ctx->h[7] = 0x5be0cd19137e2179; > > > I think those are still not portable, because those constants are too > large. You may use something like ((ULONG64)0x6a09e667<<32)|0xf3bcc908. > > > Jacek I was wondering about that too, but it looks like we have already various places where 64-bit consts are used without any ugly tricks. Examples are in tests, include files, and also implementation code. Is it really necessary? Or is it only the suffix which causes trouble? Best regards, Sebastian

2 1

Re: [4/5] bcrypt: Add a builtin sha384/sha512 implementation.
by Hans Leidekker March 8, 2017

March 8, 2017

On Tue, 2017-03-07 at 23:16 +0100, Sebastian Lackner wrote: > +void sha384_init(SHA512_CTX *ctx) > +{ > + ctx->len = 0; > + ctx->h[0] = 0xcbbb9d5dc1059ed8ULL; > + ctx->h[1] = 0x629a292a367cd507ULL; > + ctx->h[2] = 0x9159015a3070dd17ULL; > + ctx->h[3] = 0x152fecd8f70e5939ULL; > + ctx->h[4] = 0x67332667ffc00b31ULL; > + ctx->h[5] = 0x8eb44a8768581511ULL; > + ctx->h[6] = 0xdb0c2e0d64f98fa7ULL; > + ctx->h[7] = 0x47b5481dbefa4fa4ULL; We try to avoid the (U)LL suffix. The patch set looks good otherwise.

2 1

Re: [PATCH] d3dx9/tests: Add test for out of bound array selector in effect.
by Matteo Bruni March 7, 2017

March 7, 2017

2017-03-07 18:47 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> Hi Paul! Patch looks mostly good to me BUT I have a couple comments anyway... > --- > dlls/d3dx9_36/tests/effect.c | 159 ++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 141 insertions(+), 18 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index b3845c5..fe84173 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -3813,6 +3813,33 @@ static const DWORD test_effect_preshader_effect_blob[] = > #define TEST_EFFECT_PRESHADER_VSHADER_POS 2458 > #define TEST_EFFECT_PRESHADER_VSHADER_LEN 13 > > +static BOOL test_effect_preshader_compare_shader(IDirect3DDevice9 *device, int expected_shader_index) > +{ > + IDirect3DVertexShader9 *vshader; > + void *byte_code; > + unsigned int byte_code_size; > + HRESULT hr; > + BOOL ret; > + > + if (FAILED(hr = IDirect3DDevice9_GetVertexShader(device, &vshader)) || !vshader) > + return FALSE; It seems preferable to keep the detailed ok() calls from the old test instead of a generic ok() message on the return value of test_effect_preshader_compare_shader(). I guess you want to avoid to have ambiguous ok() calls in this helper. Until we get something like the with_context() thing from https://source.winehq.org/patches/data/131137 just passing a string with the test name to the helper function and using that in the ok() messages should do the trick. > + hr = effect->lpVtbl->BeginPass(effect, 1); > + todo_wine ok(hr == E_FAIL, "Got result %#x.\n", hr); > + if (SUCCEEDED(hr)) > + effect->lpVtbl->EndPass(effect); > + > + hr = effect->lpVtbl->BeginPass(effect, 1); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); That reminds me, do we have tests for two BeginPass() calls without an EndPass() in between? Might be interesting to see what happens both with the same or different pass index. Other somewhat interesting cases might be BeginPass() outside of Begin() / End() and multiple Begin() / End() / EndPass() calls in a row. It should probably be in a separate patch though. BTW, I think it's somewhat idiomatic to call it "out of bounds" even when technically there is a single bound involved.

2 3

Interested in Wine Outreachy Application
by Sreya Mittal March 7, 2017

March 7, 2017

Hi, I am Sreya Mittal pursuing my Btech in Computer Science at International Institute of Information Technology, Hyderabad. I am interested in getting started with open-source contributions and looking forward to becoming a part of Wine and Outreachy community. I am proficient in C. This would help in the work. I would be grateful if I could get a few pointers regarding how to get started. Thank you, Sreya

4 5

Re: kernel32: add stub for GetCurrentPackageFullName
by Sebastian Lackner March 7, 2017

March 7, 2017

On 04.03.2017 11:05, Louis Lenders wrote: > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -629,6 +629,7 @@ > @ stdcall GetCurrentDirectoryA(long ptr) > @ stdcall GetCurrentDirectoryW(long ptr) > @ stdcall GetCurrentPackageId(ptr ptr) > +@ stdcall GetCurrentPackageFullName(ptr ptr) > @ stdcall -norelay GetCurrentProcess() > @ stdcall -norelay GetCurrentProcessId() > @ stdcall GetCurrentProcessorNumber() ntdll.NtGetCurrentProcessorNumber In this case its too late, but please make sure to keep the specfile ordered alphabetically in the future.

2 1

Re: [PATCH v2 2/5] winebus.sys: Build device reports for linux event devices
by Roderick Colenbrander March 7, 2017

March 7, 2017

Hi Aric, I have had a quick look over this patch and have some initial feedback, maybe more later if time permits. For the absolute and relative axes don't hard code the minimum and maximum values for the report descriptors. These are not correct for many devices e.g. Xbox controllers use 16-bit absolute axes, while DS3/DS4 for example use 8-bit. In addition xbox controllers use signed data, while DS3/DS4 use unsigned (0-255)Also many devices use signed data. You should rely on the absinfo data returned by EVIOCGABS and base your input ranges on that. Thanks, Roderick On Mon, Feb 27, 2017 at 9:32 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > v2: Updates from Sebastian Lackner > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 438 +++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 436 insertions(+), 2 deletions(-) > > > > >

2 2

Re: qcap: Fix compile error when O_CLOEXEC is not defined.
by Alexandre Julliard March 7, 2017

March 7, 2017

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Defining to 0 ensures that it doesn't do any harm. If we don't > care about ancient systems, we can probably also remove the fcntl call. > On modern systems, setting CLOEXEC twice (via open and fcntl) shouldn't > hurt. I'm too lazy to check, but I'm wondering if passing O_CLOEXEC would cause the open to fail on an ancient system, and whether we should be checking for EINVAL and retrying... -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH v2 3/5] winebus.sys: Process device reports for linux event devices
by Roderick Colenbrander March 7, 2017

March 7, 2017

Hi Aric, Some quick feedback on this patch as well. High-level looks okay (need to have a deeper dive), one thing really implement proper support for EV_SYN and particular you MUST handle SYN_DROPPEPD, it has bitten me many times. Basically if you don't process input fast enough (can happen for various reason either you are too slow or device is too fast), evdev drops input and you can't trust the state. When input is dropped SYN_DROPPED is sent and you must follow the required procedures to recover (ignore any input data until next SYN_REPORT). I'm not sure how you are marking the end of input reports, but you may want to mark a report completed based on the proper SYN flag as well else you may build up unneeded input latency. Didn't follow too closely what you are doing yet. Thanks, Roderick On Mon, Feb 27, 2017 at 9:33 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > v2: Updates from Sebastian Lackner > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 203 ++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 197 insertions(+), 6 deletions(-) > > > > >

1 1

Re: [PATCH 5/5] usp10/tests: Add shaping tests for fLogicalOrder and fRTL.
by Sebastian Lackner March 7, 2017

March 7, 2017

On 02.03.2017 09:38, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/usp10/tests/usp10.c | 153 +++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 148 insertions(+), 5 deletions(-) > I'm getting a lot of test failures after this series (starting with patch 2): $ (cd dlls/usp10/tests/; make test) ../../../tools/runtest -q -P wine -T ../../.. -M usp10.dll -p usp10_test.exe.so usp10 && touch usp10.ok fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly usp10.c:1662: Test failed: 0: invalid LogClust(8) usp10.c:1662: Test failed: 1: invalid LogClust(7) usp10.c:1662: Test failed: 2: invalid LogClust(6) usp10.c:1662: Test failed: 3: invalid LogClust(6) usp10.c:1662: Test failed: 4: invalid LogClust(4) usp10.c:1662: Test failed: 5: invalid LogClust(3) usp10.c:1662: Test failed: 6: invalid LogClust(1) usp10.c:1662: Test failed: got incorrect number of glyphs (9) usp10.c:1662: Test failed: 2: uJustification incorrect (2) usp10.c:1662: Test failed: 2: fClusterStart incorrect (0) usp10.c:1662: Test failed: 3: fClusterStart incorrect (1) usp10.c:1662: Test failed: 3: fDiacritic incorrect (0) usp10.c:1662: Test failed: 3: fZeroWidth incorrect (0) usp10.c:1662: Test failed: 5: fClusterStart incorrect (0) usp10.c:1662: Test failed: 5: fDiacritic incorrect (1) usp10.c:1662: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1662: Test failed: 7: uJustification incorrect (0) usp10.c:1662: Test failed: 8: uJustification incorrect (0) usp10.c:1662: Test failed: 8: fClusterStart incorrect (1) usp10.c:1662: Test failed: 8: fDiacritic incorrect (0) usp10.c:1662: Test failed: Got unexpected glyphProp2[6].sva.uJustification 0, expected 0x2. usp10.c:1662: Test failed: Got unexpected glyphProp2[6].sva.fClusterStart 0x1, expected 0. usp10.c:1662: Test failed: Got unexpected glyphProp2[7].sva.uJustification 0x2, expected 0. usp10.c:1662: Test failed: Got unexpected glyphProp2[7].sva.fClusterStart 0, expected 0x1. fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:get_cluster_advance multi-glyph reversed clusters found fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:GPOS_convert_design_units_to_device Font with lfWidth set not handled properly fixme:uniscribe:SHAPE_GetFontFeatureTags Filtering not implemented Is this a problem with the fonts shipped on Archlinux, or is something going wrong on the Wide side? The font "Estrangelo Edessa" is provided by /usr/share/fonts/OTF/SyrCOMEdessa.otf which can be downloaded at https://www.archlinux.org/packages/extra/any/xorg-fonts-misc/download/. If you need any logs or want me to open a bug report, please let me know. Best regards, Sebastian

2 4

[v5 00/20] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri March 6, 2017

March 6, 2017

This is v5 of this series. The four previous submissions can be found here [1], here [2], here[3], and here [4]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. Please see details in the change log. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. === How does it impact applications? There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[6]. For instance, these applications rely on sidt returning a non- accessible memory location[6]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The consensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[7] does not support applications that use these instructions. It relies on WineHQ for this [8]. Furthermore, the applications for which the concern was raised run in protected mode [6]. Please note that UMIP is always enabled for both 64-bit and 32-bit Linux builds. However, emulation of the UMIP-protected instructions is not done for 64-bit processes. 64-bit user space applications will receive the SIGSEGV signal when UMIP instructions causes a general protection fault. === How are UMIP-protected instructions emulated? This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return hard-coded dummy values as the base of the global descriptor and interrupt descriptor tables. These hard-coded values correspond to memory addresses that are near the end of the kernel memory map. This is also the case for virtual-8086 mode tasks. In all my experiments in x86_32, the base of GDT and IDT was always a 4-byte address, even for 16-bit operands. Thus, my emulation code does the same. In all cases, the limit of the table is set to 0. * STR and SLDT return 0 as the segment selector. This looks appropriate since we are providing a dummy value as the base address of the global descriptor table. * SMSW returns the value with which the CR0 register is programmed in head_32/64.S at boot time. This is, the following bits are enabled: CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for Extension Type, which will always be 1 in recent processors with UMIP; CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment Mask. As per the Intel 64 and IA-32 Architectures Software Developer's Manual, SMSW returns a 16-bit results for memory operands. However, when the operand is a register, the results can be up to CR0[63:0]. Since the emulation code only kicks-in in x86_32, we return up to CR[31:0]. * The proposed emulation code is handles faults that happens in both protected and virtual-8086 mode. === How is this series laid out? ++ Fix bugs in MPX address evaluator I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate library file that both MPX and UMIP can access and avoid code duplication. Before creating the new library, I fixed a couple of bugs that I found in how MPX determines the address contained in the instruction and operands. ++ Provide a new x86 instruction evaluating library With bugs fixed, the MPX evaluating code is relocated in a new insn-eval.c library. The basic functionality of this library is extended to obtain the segment descriptor selected by either segment override prefixes or the default segment by the involved registers in the calculation of the effective address. It was also extended to obtain the default address and operand sizes as well as the segment base address. Also, support to process 16-bit address encodings. Armed with this arsenal, it is now possible to determine the linear address onto which the emulated results shall be copied. This code supports Normal 32-bit and 64-bit (i.e., __USER32_CS and/or __USER_CS) protected mode, virtual-8086 mode, 16-bit protected mode with 32-bit base address. ++ Emulate UMIP instructions A new fixup_umip_exception functions inspect the instruction at the instruction pointer. If it is an UMIP-protected instruction, it executes the emulation code. This uses all the address-computing code of the previous section. ++ Add self-tests Lastly, self-tests are added to entry_from_v86.c to exercise the most typical use cases of UMIP-protected instructions in a virtual-8086 mode. ++ Extensive tests Extensive tests were performed to test all the combinations of ModRM, SiB and displacements for 16-bit and 32-bit encodings for the ss, ds, es and fs segments. Tests also include a 64-bit program that uses segmentation via FS and GS. For this purpose, I temporarily, and not as part of this patchset, enabled UMIP support for 64-bit process with the intention to test the computations of linear addresses in 64-bit mode, including the extra R8-R15 registers. Extensive test is also implemented for virtual-8086 tasks. Code of these tests can be found here [9] and here [10]. [1]. https://lwn.net/Articles/705877/ [2]. https://lkml.org/lkml/2016/12/23/265 [3]. https://lkml.org/lkml/2017/1/25/622 [4]. https://lkml.org/lkml/2017/2/23/40 [5]. https://www.winehq.org/ [6]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [7]. http://www.dosemu.org/ [8]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [9]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… [10]. https://github.com/01org/luv-yocto/commit/a72a7fe7d68693c0f4100ad86de6ecabd… Thanks and BR, Ricardo Changes since V4: * Audited patches to use braces in all the branches of conditional. statements, except those in which the conditional action only takes one line. * Implemented support in 64-builds for both 32-bit and 64-bit tasks in the instruction evaluating library. * Split segment selector function in the instruction evaluating library into two functions to resolve the segment type by instruction override or default and a separate function to actually read the segment selector. * Fixed a bug when evaluating 32-bit effective addresses with 64-bit kernels. * Split patches further for for easier review. * Use signed variables for computation of effective address. * Fixed issue with a spurious static modifier in function insn_get_addr_ref found by kbuild test bot. * Removed comparison between true and fixup_umip_exception. * Reworked check logic when identifying erroneous vs invalid values of the SiB base and index. Changes since V3: * Limited emulation to 32-bit and 16-bit modes. For 64-bit mode, a general protection fault is still issued when UMIP-protected instructions are executed with CPL > 0. * Expanded instruction-evaluating code to obtain segment descriptor along with their attributes such as base address and default address and operand sizes. Also, support for 16-bit encodings in protected mode was implemented. * When getting a segment descriptor, this include support to obtain those of a local descriptor table. * Now the instruction-evaluating code returns -EDOM when the value of registers should not be used in calculating the effective address. The value -EINVAL is left for errors. * Incorporate the value of the segment base address in the computation of linear addresses. * Renamed new instruction evaluation library from insn-kernel.c to insn-eval.c * Exported functions insn_get_reg_offset_* to obtain the register offset by ModRM r/m, SiB base and SiB index. * Improved documentation of functions. * Split patches further for easier review. Changes since V2: * Added new utility functions to decode the memory addresses contained in registers when the 16-bit addressing encodings are used. This includes code to obtain and compute memory addresses using segment selectors for real-mode address translation. * Added support to emulate UMIP-protected instructions for virtual-8086 tasks. * Added self-tests for virtual-8086 mode that contains representative use cases: address represented as a displacement, address in registers and registers as operands. * Instead of maintaining a static variable for the dummy base addresses of the IDT and GDT, a hard-coded value is used. * The emulated SMSW instructions now return the value with which the CR0 register is programmed in head_32/64.S This is: PE | MP | ET | NE | WP | AM. For x86_64, PG is also enabled. * The new file arch/x86/lib/insn-utils.c is now renamed as arch/x86/lib/ insn-kernel.c. It also has its own header. This helps keep in sync the the kernel and objtool instruction decoders. Also, the new insn-kernel.c contains utility functions that are only relevant in a kernel context. * Removed printed warnings for errors that occur when decoding instructions with invalid operands. * Added more comments on fixes in the instruction-decoding MPX functions. * Now user_64bit_mode(regs) is used instead of test_thread_flag(TIF_IA32) to determine if the task is 32-bit or 64-bit. * Found and fixed a bug in insn-decoder in which X86_MODRM_RM was incorrectly used to obtain the mod part of the ModRM byte. * Added more explanatory code in emulation and instruction decoding code. This includes a comment regarding that copy_from_user could fail if there exists a memory protection key in place. * Tested code with CONFIG_X86_DECODER_SELFTEST=y and everything passes now. * Prefixed get_reg_offset_rm with insn_ as this function is exposed via a header file. For clarity, this function was added in a separate patch. Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Thanks and BR, Ricardo Ricardo Neri (20): x86/mpx: Use signed variables to compute effective addresses x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel x86/insn-eval: Add utility functions to get register offsets x86/insn-eval: Add utility functions to get segment selector x86/insn-eval: Add utility function to get segment descriptor x86/insn-eval: Add utility function to get segment descriptor base address x86/insn-eval: Add functions to get default operand and address sizes x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero insn/eval: Incorporate segment base in address computation x86/insn: Support both signed 32-bit and 64-bit effective addresses x86/insn-eval: Add support to resolve 16-bit addressing encodings x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/umip: Force a page fault when unable to copy emulated result to user x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention selftests/x86: Add tests for User-Mode Instruction Prevention arch/x86/Kconfig | 10 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn-eval.h | 23 + arch/x86/include/asm/umip.h | 15 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 +- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 305 ++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 832 ++++++++++++++++++++++++++ arch/x86/mm/mpx.c | 120 +--- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 14 files changed, 1256 insertions(+), 122 deletions(-) create mode 100644 arch/x86/include/asm/insn-eval.h create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-eval.c -- 2.9.3

2 22

Re: [PATCH] makedep: touch the .tab.c file to ensure ordering
by Alexandre Julliard March 6, 2017

March 6, 2017

Marcus Meissner <marcus(a)jet.franken.de> writes: > .tab.c and .tab.h are created too close together to confuse > make. Ensure a bit better ordering by touching mcy.tab.c I don't think that's better. It shouldn't make any difference, except maybe making it a little harder to reproduce. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Reproducible builds
by wylda＠volny.cz March 6, 2017

March 6, 2017

> Od: André Hentschel <nerv(a)dawncrow.de> >>>>>> Am 2017-02-19 um 10:00 schrieb wylda(a)volny.cz: >>>>>>> Anyway, there are 7 files out of 2750 which _always_ pickup some random >>>>>>> value and use that consistently. Why are these libraries built >>>>>>> inconsitently? Is that intentional? An example is attached. >>>>> >>>>> Thanks. These "random" value come from: >>>>> >>>>> * olepro_t.res >>>>> * std_ole_v2_t.res >>>>> * wuapi_tlb_t.res >>> >>> When i do: >>> >>> export WIDL_TIME_OVERRIDE="0" >>> rm dlls/olepro32/olepro_t.res >>> make -k dlls/olepro32 >>> md5sum -b dlls/olepro32/olepro_t.res >>> >>> then i always get different MD5 checksum. >>> >>> Marcus, could you send me your dlls/olepro32/Makefile please? >>> What is your distro? >> >> I tried above for both 32bit and 64bit directories, always gives the same md5 in those. >> >> openSUSE Tumbleweed, with currently gcc 6.3.1+r245113, binutils-2.27, flex-2.6.1, bison-3.0.4 >> > >I can reproduce the bug with the instructions above >Linux Mint 18.1, gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4), binutils 2.26.1, flex 2.6, biso 3.0.4 >the first bad value is at offset 269h >Which is datatype2 from MSFT_TypeInfoBase > >So initializing datatype2 in add_typedef_typeinfo or the following patch fixes the problem for me: > >diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c >index 137bb2d..7904e45 100644 >--- a/tools/widl/write_msft.c >+++ b/tools/widl/write_msft.c >@@ -798,6 +798,7 @@ static int encode_type( > if (!alignment) alignment = &scratch; > if (!decoded_size) decoded_size = &scratch; > >+ *decoded_size = 0; > > switch (vt) { > case VT_I1: > Thank Stefan / Marcus / Andre. This fixed 6 files. 7th file is libdinput.a, which also has some random stuff inside. This was for 32bit chroot. In 64bit chroot these 6 files are also fixed now. libdinput.a differs again. But 64bit chroot also shows 2 other files: * /bin/wmc * /lib64/wine/msi.dll.so These last two differs in Build-id's SHA1 of the .note.gnu.build-id section. Debian Stretch 9.0 Multiarch: * gcc (Debian 6.3.0-6) 6.3.0 20170205 * binutils 2.27.90.20170124-2 * flex 2.6.1-1.3 * bison 3.0.4.dfsg-1 Regards, W.

3 5