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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

`setupapi` patch from staging
by Donat Enikeev April 24, 2017

April 24, 2017

Hi Guys, Number of recent well-known games are based on Starling game engine (Adobe Air+Stage3D for gpu rendering), such as: The Banner Saga 2, Samorost 3, The Inner World, Angry Birds. They are are falling into Software rendering mode on plain Wine and thus barely playable (bug #41635) Thanks to Béla Gyebrószki finding @ bug #41653, Wine makes these games consider d3d9 rendering with the following single patch from wine-staging https://github.com/wine-compholio/wine-staging/blob/master/patches/setupapi… This patch implements support of the case when a full driver path is passed to SetupDiGetClassDevs (trace successfully reaching AddDeviceToSet for a game below [1]). I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests? I am asking this, because Adobe stopped Linux support for the Air years ago and we could never see such games ported, and therefore plain Wine's support of gpu acceleration for such games looks important. Thanks in advance Best regards, Donnie [1] 0009:trace:setupapi:SetupDiGetClassDevsExW {4d36e968-e325-11ce-bfc1-08002be10318} L"PCI\\VEN_0000&DEV_0000" (nil) 0x0000000a (nil) (null) (nil) 0009:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 0000000a 0009:trace:setupapi:SetupDiCreateDeviceInfoListExW {4d36e968-e325-11ce-bfc1-08002be10318} (nil) (null) (nil) 0009:trace:setupapi:SETUPDI_EnumerateDevices 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, L"PCI\\VEN_0000&DEV_0000", 0000000a 0009:trace:setupapi:SETUPDI_EnumerateMatchingDeviceInstances L"PCI" L"VEN_0000&DEV_0000" 0009:trace:setupapi:SETUPDI_AddDeviceToSet 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, 0, L"PCI\\VEN_0000&DEV_0000\\13&12345&0", 0

3 6

Re: [PATCH 4/5] server: Added server side mamed pipe read and write implementation and use it for message mode pipes.
by Sebastian Lackner March 15, 2017

March 15, 2017

On 22.02.2017 14:51, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/kernel32/tests/pipe.c | 28 ++- > dlls/ntdll/file.c | 7 +- > dlls/ntdll/tests/file.c | 2 +- > server/async.c | 9 + > server/file.h | 1 + > server/named_pipe.c | 446 > ++++++++++++++++++++++++++++++++++++++++++--- > 6 files changed, 447 insertions(+), 46 deletions(-) As I see this updated patchset allows to return the result immediately, but still uses a USR1 signal to transfer back the IO completion info. Wouldn't it be useful to get rid of that aswell? Also please note that we need to distinguish "immediate returns" and "async returns" to properly implement FileIoCompletionNotificationInformation. This especially means that waiting internally is not an option. > + iosb = async_get_iosb( async ); > + if ((blocking || iosb->status != STATUS_PENDING) > + && !(handle = alloc_handle( current->process, async, SYNCHRONIZE, 0 ))) > + async_terminate( async, get_error() ); I don't think this will work as expected. async_terminate might queue an APC, but the caller will immediately deallocate the async struct in server_write_file because status != STATUS_PENDING.

3 14

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

Re: [PATCH 1/2] server: Added server side named pipe read and write implementation and use it for message mode pipes.
by Sebastian Lackner March 1, 2017

March 1, 2017

On 28.02.2017 14:14, Jacek Caban wrote: > + LIST_FOR_EACH_ENTRY( message, &pipe_end->message_queue, struct pipe_message, entry ) > + avail += message->iosb->in_size - message->read_pos; > + reply_size = min( reply_size, avail ); > + > + if (avail) > + { > + message = LIST_ENTRY( list_head(&pipe_end->message_queue), struct pipe_message, entry ); > + reply_size = min( reply_size, message->iosb->in_size ); > + } Isn't there a problem with this size check? Lets assume we have two messages with 10 byte, for the first one the read_pos = 5. Then avail == 15, and reply_size is clamped to 10 - but it will attempt to copy 10 bytes starting position 5? > + > + if (!(buffer = set_reply_data_size(FIELD_OFFSET( FILE_PIPE_PEEK_BUFFER, Data[reply_size] )))) return; > + buffer->NamedPipeState = 0; /* FIXME */ > + buffer->ReadDataAvailable = avail; > + buffer->NumberOfMessages = 0; /* FIXME */ > + buffer->MessageLength = 0; /* FIXME */ > + if (avail) memcpy( buffer->Data, (const char *)message->iosb->in_data + message->read_pos, reply_size ); > +} > +

2 1

Re: [PATCH] d3dx9_36/tests: Fix a memory leak in test_createtext.
by Matteo Bruni Feb. 28, 2017

Feb. 28, 2017

2017-02-27 7:52 GMT+01:00 Alex Henrie <alexhenrie24(a)gmail.com>: > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 95dd06e466..64b7b8823c 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -4340,8 +4340,7 @@ static void test_createtext(IDirect3DDevice9 *device, HDC hdc, const char *text, > if (!compute_text_mesh(&mesh, text, deviation, extrusion, otm.otmEMSquare, glyphs)) > { > skip("Couldn't create mesh\n"); > - d3dxmesh->lpVtbl->Release(d3dxmesh); > - return; > + goto error; > } > mesh.fvf = D3DFVF_XYZ | D3DFVF_NORMAL; I would go in the other direction and strip all the error checking branches and gotos from those tests. compute_text_mesh() returns FALSE only on allocation failure and that's not supposed to happen in the controlled conditions of the test. It's probably better to just fail and crash in those cases.

2 1

Re: [PATCH 2/2] wineinstall - Add support for parallel builds using 'nproc' to detect cpu count
by Austin English Feb. 28, 2017

Feb. 28, 2017

On Fri, Feb 24, 2017 at 6:30 PM, Chris Morgan <chmorgan(a)gmail.com> wrote: > Parallel builds can greatly reduce the overall build time on modern multi-core processors. > > Fall back to two parallel builds in the case where nproc is unavailable, most modern > processors have at least two cores. > > Use the 'NPROC' value defined by the environment if it is not null. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > tools/wineinstall | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/tools/wineinstall b/tools/wineinstall > index bfd62e3..080d590 100755 > --- a/tools/wineinstall > +++ b/tools/wineinstall > @@ -143,10 +143,19 @@ echo "in the meantime..." > echo > std_sleep > > +# If the NPROC environment variable isn't set use nproc, if available, to determine > +# the number of processors in the system, if not, fall back to a default NPROC value > +if type nproc2 &>/dev/null I don't think this will do what you want ;) Also, I'm pretty sure &> isn't Posix. You'd want something like: if type nproc > /dev/null 2>&1 -- -Austin GPG: 14FB D7EA A041 937B

5 7