wine-devel July 2018

wine-devel@winehq.org

74 participants
637 discussions

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.
by Alexandre Julliard 23 Nov '20

23 Nov '20

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > So, I admit I don't really know this code, but looking at it (triggered > by a warning issued by GCC development versions), I noticed that this > variable passed by reference is not initialized here. It's initialized when we return a type, and it doesn't need to be initialized on NULL return. The code is correct, but you could probably set the variable to NULL in the caller to silence the warning. -- Alexandre Julliard julliard(a)winehq.org

2 1

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

22 Nov '20

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

[PATCH v2] Enforce type check in ARRAY_SIZE macro
by janisozaur＠gmail.com 15 Nov '18

15 Nov '18

From: Michał Janiszewski <janisozaur(a)gmail.com> Inspired by kernel check and recent unification of ARRAY_SIZE, provide a way of enforcing the macro can only be applied to actual arrays and not to pointers. v2: Fix parentheses Signed-off-by: Michał Janiszewski <janisozaur(a)gmail.com> --- include/winnt.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/include/winnt.h b/include/winnt.h index 7f822c4aec..b99a375ab0 100644 --- a/include/winnt.h +++ b/include/winnt.h @@ -760,7 +760,26 @@ typedef struct _MEMORY_BASIC_INFORMATION ((type *)((PCHAR)(address) - offsetof(type, field))) #ifdef __WINESRC__ -# define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) +// Validate types used in the expression. +// Based on https://elixir.bootlin.com/linux/v4.17.4/source/include/linux/kernel.h#L71 + +#ifdef __GNUC__ +/** + * Force a compilation error if condition is true, but also produce a + * result (of value 0 and type size_t), so the expression can be used + * e.g. in a structure initializer (or where-ever else comma expressions + * aren't permitted). + */ +#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); })) + +/* &a[0] degrades to a pointer: a different type from an array */ +#define __must_be_array(a) \ + BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0]))) +#else +#define __must_be_array(a) 0 +#endif + +# define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + __must_be_array(x)) #endif /* Types */ -- 2.18.0

2 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong 28 Sep '18

28 Sep '18

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

Wrap-up of wineconf
by Hugh McMaster 17 Sep '18

17 Sep '18

Hi all, Are there any summaries or presentations from Wineconf available for those of us who couldn't attend? (And even those who could...) Hugh

5 6

WineConf 2018 videos
by Henri Verbeet 16 Sep '18

16 Sep '18

The first few WineConf 2018 videos are up at [1]. Currently we have the keynote and the CodeWeavers company update on there. We'll hopefully be uploading more over the next couple of days. We may also upload copies to other hosts like YouTube in the future. [1] https://peertube.mastodon.host/accounts/wineconf2018/videos

1 1

COM tracing ...
by Michael Meeks 21 Aug '18

21 Aug '18

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

[PATCH] kernel32: Set environment variable %PUBLIC% on the process start-up.
by Dmitry Timoshkov 16 Aug '18

16 Aug '18

This patch fixes an installer that has "[%PUBLIC]\Documents" entry for some of the targets being copied from a cabinet file. Under Windows %PUBLIC% environment variable is set to C:\Users\Public. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/kernel32/process.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c index 4e6ba1118e..280f406627 100644 --- a/dlls/kernel32/process.c +++ b/dlls/kernel32/process.c @@ -520,6 +520,7 @@ static void set_additional_environment(void) static const WCHAR computernameW[] = {'C','O','M','P','U','T','E','R','N','A','M','E',0}; static const WCHAR allusersW[] = {'A','L','L','U','S','E','R','S','P','R','O','F','I','L','E',0}; static const WCHAR programdataW[] = {'P','r','o','g','r','a','m','D','a','t','a',0}; + static const WCHAR publicW[] = {'P','U','B','L','I','C',0}; OBJECT_ATTRIBUTES attr; UNICODE_STRING nameW; WCHAR *profile_dir = NULL, *all_users_dir = NULL, *program_data_dir = NULL; @@ -560,6 +561,7 @@ static void set_additional_environment(void) if (p > value && p[-1] != '\\') *p++ = '\\'; strcpyW( p, all_users_dir ); SetEnvironmentVariableW( allusersW, value ); + SetEnvironmentVariableW( publicW, value ); HeapFree( GetProcessHeap(), 0, value ); } -- 2.17.1

3 6

[PATCH] winebus.sys: Do not report HID report read errors unconditionally
by Kai Krakow 15 Aug '18

15 Aug '18

Device reports may come in faster than our consumers could possibly read them, this is especially true for multi-axis events: When you move a stick across its range, it will always generate at least two events, one for the x axis, and one for the y axis. This is not really an error situation, so let's report this situation only once at most. If we already know the multi-event situation, let's skip logging this completely: We won't loose any information anyway because the report contains a complete device state and only axis positions were updated. Thus, this commit adds a parameter to process_hid_report() to let it know if we are currently processing reports that are known to be sent multiple times in sequence (with updated reports). Also, if our consumers are slow to respond, then report the issue only once and not per each occurrence during the duration of one consumer read cycle. Finally, this is not really an error, it's a warning at most, thus degrade the error message to a warning to not pollute peoples consoles and logs with unimportant stuff. Especially during gaming I was seeing screens over screens full of only this single log message. This commit fixes it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43125 CC: Aric Stewart <aric(a)codeweavers.com> Signed-off-by: Kai Krakow <kai(a)kaishome.de> --- dlls/winebus.sys/bus.h | 2 +- dlls/winebus.sys/bus_iohid.c | 2 +- dlls/winebus.sys/bus_sdl.c | 12 ++++++------ dlls/winebus.sys/bus_udev.c | 4 ++-- dlls/winebus.sys/main.c | 18 +++++++++++++++--- 5 files changed, 25 insertions(+), 13 deletions(-) diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h index bf93c04259..1e2989e5c5 100644 --- a/dlls/winebus.sys/bus.h +++ b/dlls/winebus.sys/bus.h @@ -45,7 +45,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; -void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) DECLSPEC_HIDDEN; +void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length, BOOL warn_multi_events) DECLSPEC_HIDDEN; DEVICE_OBJECT* bus_enumerate_hid_devices(const platform_vtbl *vtbl, enum_func function, void* context) DECLSPEC_HIDDEN; /* General Bus Functions */ diff --git a/dlls/winebus.sys/bus_iohid.c b/dlls/winebus.sys/bus_iohid.c index 501a40d26e..74e5d82c9f 100644 --- a/dlls/winebus.sys/bus_iohid.c +++ b/dlls/winebus.sys/bus_iohid.c @@ -135,7 +135,7 @@ static void handle_IOHIDDeviceIOHIDReportCallback(void *context, uint32_t reportID, uint8_t *report, CFIndex report_length) { DEVICE_OBJECT *device = (DEVICE_OBJECT*)context; - process_hid_report(device, report, report_length); + process_hid_report(device, report, report_length, TRUE); } static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) diff --git a/dlls/winebus.sys/bus_sdl.c b/dlls/winebus.sys/bus_sdl.c index 159727f6bc..99a206cb34 100644 --- a/dlls/winebus.sys/bus_sdl.c +++ b/dlls/winebus.sys/bus_sdl.c @@ -683,7 +683,7 @@ static BOOL set_report_from_event(SDL_Event *event) set_button_value(ie->button, ie->state, private->report_buffer); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, TRUE); break; } case SDL_JOYAXISMOTION: @@ -693,7 +693,7 @@ static BOOL set_report_from_event(SDL_Event *event) if (ie->axis < 6) { set_axis_value(private, ie->axis, ie->value); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, FALSE); } break; } @@ -702,7 +702,7 @@ static BOOL set_report_from_event(SDL_Event *event) SDL_JoyBallEvent *ie = &event->jball; set_ball_value(private, ie->ball, ie->xrel, ie->yrel); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, FALSE); break; } case SDL_JOYHATMOTION: @@ -710,7 +710,7 @@ static BOOL set_report_from_event(SDL_Event *event) SDL_JoyHatEvent *ie = &event->jhat; set_hat_value(private, ie->hat, ie->value); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, TRUE); break; } default: @@ -765,7 +765,7 @@ static BOOL set_mapped_report_from_event(SDL_Event *event) if (usage >= 0) { set_button_value(usage, ie->state, private->report_buffer); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, TRUE); } break; } @@ -774,7 +774,7 @@ static BOOL set_mapped_report_from_event(SDL_Event *event) SDL_ControllerAxisEvent *ie = &event->caxis; set_axis_value(private, ie->axis, ie->value); - process_hid_report(device, private->report_buffer, private->buffer_length); + process_hid_report(device, private->report_buffer, private->buffer_length, FALSE); break; } default: diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c index d34e18c71c..47b9758ac2 100644 --- a/dlls/winebus.sys/bus_udev.c +++ b/dlls/winebus.sys/bus_udev.c @@ -768,7 +768,7 @@ static DWORD CALLBACK device_report_thread(void *args) else if (size == 0) TRACE_(hid_report)("Failed to read report\n"); else - process_hid_report(device, report_buffer, size); + process_hid_report(device, report_buffer, size, TRUE); } return 0; } @@ -979,7 +979,7 @@ static DWORD CALLBACK lnxev_device_report_thread(void *args) else if (size == 0) TRACE_(hid_report)("Failed to read report\n"); else if (set_report_from_event(private, &ie)) - process_hid_report(device, private->current_report_buffer, private->buffer_length); + process_hid_report(device, private->current_report_buffer, private->buffer_length, TRUE); } return 0; } diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c index 2f3c05aa96..624ddd5f8d 100644 --- a/dlls/winebus.sys/main.c +++ b/dlls/winebus.sys/main.c @@ -614,11 +614,12 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) return status; } -void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) +void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length, BOOL warn_multi_events) { struct device_extension *ext = (struct device_extension*)device->DeviceExtension; IRP *irp; LIST_ENTRY *entry; + static int overwrite_reported; if (!length || !report) return; @@ -641,8 +642,18 @@ void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) ext->buffer_size = length; } - if (!ext->last_report_read) - ERR_(hid_report)("Device reports coming in too fast, last report not read yet!\n"); + /* + * Device reports may come in faster than our consumers could possibly + * read them, this is especially true for multi-axis events: When you move + * a stick across its range, it will always generate at least two events, + * one for the x axis, and one for the y axis. This is not really an error + * situation, so let's report this situation only once at most. If we + * already know the multi-event situation, let's skip logging this + * completely: We won't loose any information anyway because the report + * contains a complete device state and only axis positions were updated. + */ + if (warn_multi_events && !ext->last_report_read && !overwrite_reported++) + WARN_(hid_report)("Device reports coming in too fast, last report not read yet!\n"); memcpy(ext->last_report, report, length); ext->last_report_size = length; @@ -659,6 +670,7 @@ void process_hid_report(DEVICE_OBJECT *device, BYTE *report, DWORD length) irp->UserBuffer, &irp->IoStatus.Information); ext->last_report_read = TRUE; IoCompleteRequest(irp, IO_NO_INCREMENT); + overwrite_reported = 0; } LeaveCriticalSection(&ext->report_cs); } -- 2.16.4

3 7

[PATCH 1/5] kernel32: Don't clear WINEDEBUG in the debugger process.
by Zebediah Figura 15 Aug '18

15 Aug '18

While this does avoid usually undesired debug output, it also makes debugging winedbg.exe practically impossible. Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- dlls/kernel32/except.c | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/dlls/kernel32/except.c b/dlls/kernel32/except.c index bff8ce2..03fb46d 100644 --- a/dlls/kernel32/except.c +++ b/dlls/kernel32/except.c @@ -173,7 +173,7 @@ static BOOL start_debugger(PEXCEPTION_POINTERS epointers, HANDLE hEvent) { OBJECT_ATTRIBUTES attr; UNICODE_STRING nameW; - char *cmdline, *env, *p; + char *cmdline; HANDLE hDbgConf; DWORD bAuto = TRUE; PROCESS_INFORMATION info; @@ -287,27 +287,12 @@ static BOOL start_debugger(PEXCEPTION_POINTERS epointers, HANDLE hEvent) } } - /* make WINEDEBUG empty in the environment */ - env = GetEnvironmentStringsA(); - for (p = env; *p; p += strlen(p) + 1) - { - if (!memcmp( p, "WINEDEBUG=", sizeof("WINEDEBUG=")-1 )) - { - char *next = p + strlen(p); - char *end = next + 1; - while (*end) end += strlen(end) + 1; - memmove( p + sizeof("WINEDEBUG=") - 1, next, end + 1 - next ); - break; - } - } - TRACE("Starting debugger %s\n", debugstr_a(cmdline)); memset(&startup, 0, sizeof(startup)); startup.cb = sizeof(startup); startup.dwFlags = STARTF_USESHOWWINDOW; startup.wShowWindow = SW_SHOWNORMAL; - ret = CreateProcessA(NULL, cmdline, NULL, NULL, TRUE, 0, env, NULL, &startup, &info); - FreeEnvironmentStringsA( env ); + ret = CreateProcessA(NULL, cmdline, NULL, NULL, TRUE, 0, NULL, NULL, &startup, &info); if (ret) { -- 2.7.4

3 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2018