wine-devel June 2019

73 participants
565 discussions

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.

by Alexandre Julliard

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

3 years, 5 months

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)

by Gerald Pfeifer

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

3 years, 5 months

TestBot and graphics tests

by Francois Gouget

Here are some things I've learned about PCI-passthrough recently, which would be one way (probably the best) to add "real hardware" to the TestBot. I don't want to give anyone false hopes though: this just went from "this is a mysterious thing I need to learn about" to "I think I know how to do it but have not tried it yet". So graphics card PCI-passthrough is now relatively well documented on the Internet and seems to have seen some use-cases that would indicate it may even be reasonably usable. * There are two machines intended to run real GPU tests for Wine: cw1-hd6800 and cw2-gtx560. For now they are only used to run WineTest daily on Windows 8.1, Windows 10 1507, 1709, 1809 and Linux. That's quite a bunch but it would be much better if they were integrated with the TestBot as that would allow developers to submit their own tests. So I had a look at what it would imply to convert them to VM hosts using QEmu + PCI-passthrough. * First one needs a processor with hardware virtualisation support. For Intel that's VT-d. Both machines have an Intel Core 2600 which supports VT-d. Good. * Second the motherboard too needs to support VT-d. Both machines have an ASRock P67 Extreme4 motherboard. Unfortunately UEFI says "unsupported" next to the "VT-d" setting for the motherboard :-( It looks like there was some confusion as to whether the P67 chipset supported VT-d initially. From what I gathered it's only Q67 that does but this caused some manufacturers, among which ASRock, to initially claim support and later retract it. * Then one needs to add the intel_iommu=on option to the kernel command line (resp. amd_iommu). This is should make all the PCI devices appear in /sys/kernel/iommu_groups. But that folder remains empty which confirms that full VT-d support is missing. * Another important aspect is to have a graphics card which is hot-restartable. In some cases when a VM's graphics card is crashed the only way to reset it is to reboot the host. The TestBot is likely to crash the graphics card, particularly if we do a hard-power off on the VMs like we currently do, and it would relaly be annoying to have to reboot the host everytime the graphics card goes belly up. I don't know if the AMD HD6800 and Nvidia GTX560 are suitable but it's quite possible they are not. All I know for now is that we should avoid AMD's R9 line of graphics cards. I still need to find a couple of suitable reasonably lower power graphics cards: one AMD and one Nvidia. * Then one needs to prevent the host from using the graphics card. Usually that's done by having the host use the processor's IGP and dedicating the discrete GPU to the VMs. Unfortunately the 2600's IGP cannot be active when there's a discrete card so that route is denied to us. Fortunately there's quite a bit of documentation on how to shut down not just X but also the Linux virtual consoles to free the GPU and hand it over to the VMs after boot. Doing so means losing KVM access to the host which is a bit annoying in case something goes wrong. So ideally we'd make sure this does not happen in grub's "safe mode" boot option. * Although I have not done any test yet I'm reasonably certain that PCI-passthrough rules out live snapshots: QEmu would have no way to restore the graphics card's internal state. - For Windows VMs that's not an issue: if we provide a power off snapshot the TestBot already knows how to power on the VM and wait for it to boot (as long as the boot is shorter than the connection timeout but it works out usually). - For Linux VM's that's more of an issue: the TestBot will power on the VM as usual. The problem is when it updates Wine: after recompiling everything it deletes the old snapshot and creates a new one from the current state of the VM, which means a live snapshot. So the TestBot will need to be modified so it knows when and how to power off the VM and take a powered off snapshot. * Since the VM has full control of the graphics card QEmu has no access to the content of the screen. That's not an issue for the normal TestBot operation, just for the initial VM setup. Fortunately the graphics card is connected to a KVM so the screen can be accessed through that means. It does mean assigning the mouse and keyboard to the VM too. Should that prove impractical there are a bunch of other options too: VNC, LookingGlass, Synergy, etc. But the less needs to be installed in the VMs the better. * Also the TestBot uses QEmu to take the screenshots. But QEmu does not have access to the content of the screen. The fix is to use a tool to take the screenshots from within the VM and use TestAgent to retrieve them. On Linux there are standard tools we can use. On Windows there's code floating around we can use. So the next steps would be: * Maybe test on my box using the builtin IGP. But that likely won't be very conclusive beyond confirming the snapshot issues, screen access, etc. * Find a suitable AMD or Nvidia graphics card and test that on my box. That would allow me to fully test integration with the TestBot, check for stability issues, etc. * Then see what can be done with the existing cw1 and cw2 boxes. -- Francois Gouget <fgouget(a)codeweavers.com>

3 years, 8 months

Call for WineConf 2019 presentations

by Aric Stewart

Hello, Again this year I am helping coordinate the talks and presentations! I hope that people find it helpful and useful! Last work worked out well enough that I am sticking to the same rough format. I think it worked for most other people as well! If you would like to give a presentation! Please e-mail wineconf(a)winehq.org or me directly! I will keep the Wiki updated with presentations and scheduling as we get it worked out. When you propose your talk if you have a preference toward a time slot and Saturday or Sunday please express that. General Guidelines: * Please provide an estimate of how long your talk will be. We are shooting for approximate 40 minute slots with between 15-20 minutes of talk and with likely an equal amount of question and discussion time afterward. Generally shorter talks are not an issue, however longer talks will need to be discussed and will be considered based on the rest of the schedule. * Topics should obviously be of interest to the other attendees, i.e., the broader Wine community, but note that that doesn't imply the talk has to be about Wine itself * If you have a preferred time and date for your talk please indicate that to me when you submit your talk. We will try to make it work as best we can. Here are the rough proposed slots, They will be changed and modified as required by the addenda as it gets fleshed out. Understand that even with this shift toward a scheduled day we will not disrupt productive conversation to fit to the schedule. The schedule will warp and flow as required to facilitate the talk, not force the talks to conform to it. This does mean if you are planing to try to attend a given talk you will likely want to arrive a bit early and understand if when you arrive the schedule is either behind or ahead of plan. Daily Slots: 09:00 - 09:40 slot 1 09:45 - 10:25 slot 2 10:30 - 11:00 break 11:00 - 11:40 slot 3 12:00 - 13:00 lunch break 13:00 - 13:40 slot 4 13:45 - 14:25 slot 5 14:30 - 15:00 break 15:00 - 15:40 slot 6 15:45 - 16:25 slot 7 16:25 - 17:00 Overflow time / small group discussion / short presentations We will track proposed presentations on the WineConf Wiki: https://wiki.winehq.org/WineConf2019 Likely we will have open time at the conference which we will propose presentations and fill at the time. We have never had a problem finding things we all want to talk about. thanks! -aric

4 years, 7 months

[PATCH v3 0/6] winex11.drv: Fix several cursor and focus issues

by Rémi Bernon

This is a resend of several patches with some addtional ones. This should address cursor and focus related issues in winex11.drv. Many games are grabbing and warping the cursor to keep it inside their window. There's apparently no way in Xlib to prevent XWarpPointer to succeed even if some other application have active grab on the pointer, so each application should behave. The first two patches should make Wine be nicer in this regard. The focus issue is covered by the four other patches. As keyboard grab notifications are send as focus events, Wine sometimes loses tracks of the current focus state. Fixing this and using these notifications helps deciding whether it is safe or not to ask for a cursor grab / warp. Rémi Bernon (6): winex11.drv: Do not set clipping_cursor when clip window is mapped winex11.drv: Only call XWarpPointer if we can get exclusive grab winex11.drv: Print the FocusIn/FocusOut mode in trace message winex11.drv: Do not react to keyboard grab focus events winex11.drv: Only grab or warp the cursor when keyboard isn't grabbed winex11.drv: Retry last ClipCursor when grab is released dlls/winex11.drv/event.c | 57 ++++++++++++++++++++++++++++++++++++--- dlls/winex11.drv/mouse.c | 46 +++++++++++++++++++++++++++++++ dlls/winex11.drv/x11drv.h | 2 ++ 3 files changed, 102 insertions(+), 3 deletions(-) -- 2.20.1

4 years, 8 months

Unhandled Page fault on write access - Wine 4.4 - NetBSD i386

by zerous

Hi, Wine-4.4 throws Unhandled Page fault on write access errors on NetBSD i386 -current. I did some debugging and found that it was due to _lwp_makecontext(3) segfaulting as it tried to access memory that was out-of-bounds. However, the real reason was pthread_attr_setstack(3) setting up a guard of 65536 bytes which Wine didn't account for. I am aware that the manpage of pthread_attr_setstack(3) is dated and it states that no default guard will be allocated. I will indeed send a patch to amend that. In order to work around the issue, I have tried setting the guard to 0 explicitly using pthread_attr_setguardsize(3). As far as I know this change shouldn't affect any other platforms. Additionally, it also solves the initial problem I had, which was wine giving me black windows instead of the UI; an inadvertent side-effect of the same issue. OK? -- zerous

4 years, 8 months

[PATCH v2 1/6] user32: Add support for RIDEV_NOLEGACY flag.

by Derek Lesho

Signed-off-by: Derek Lesho <dereklesho52(a)Gmail.com> --- dlls/user32/rawinput.c | 2 +- server/queue.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/dlls/user32/rawinput.c b/dlls/user32/rawinput.c index 2085fd3f9f..120de073c8 100644 --- a/dlls/user32/rawinput.c +++ b/dlls/user32/rawinput.c @@ -250,7 +250,7 @@ BOOL WINAPI DECLSPEC_HOTPATCH RegisterRawInputDevices(RAWINPUTDEVICE *devices, U TRACE("device %u: page %#x, usage %#x, flags %#x, target %p.\n", i, devices[i].usUsagePage, devices[i].usUsage, devices[i].dwFlags, devices[i].hwndTarget); - if (devices[i].dwFlags & ~RIDEV_REMOVE) + if (devices[i].dwFlags & ~(RIDEV_REMOVE|RIDEV_NOLEGACY)) FIXME("Unhandled flags %#x for device %u.\n", devices[i].dwFlags, i); d[i].usage_page = devices[i].usUsagePage; diff --git a/server/queue.c b/server/queue.c index 24239916af..0ab5adfead 100644 --- a/server/queue.c +++ b/server/queue.c @@ -372,6 +372,9 @@ static void set_cursor_pos( struct desktop *desktop, int x, int y ) static const struct hw_msg_source source = { IMDT_UNAVAILABLE, IMO_SYSTEM }; struct message *msg; + if (current->process->rawinput_mouse && + current->process->rawinput_mouse->flags & RIDEV_NOLEGACY) return; + if (!(msg = alloc_hardware_message( 0, source, get_tick_count() ))) return; msg->msg = WM_MOUSEMOVE; @@ -1668,6 +1671,9 @@ static int queue_mouse_message( struct desktop *desktop, user_handle_t win, cons msg_data->rawinput.mouse.data = input->mouse.data; queue_hardware_message( desktop, msg, 0 ); + + if (device->flags & RIDEV_NOLEGACY) + return FALSE; } for (i = 0; i < ARRAY_SIZE( messages ); i++) @@ -1793,6 +1799,9 @@ static int queue_keyboard_message( struct desktop *desktop, user_handle_t win, c msg_data->rawinput.kbd.scan = input->kbd.scan; queue_hardware_message( desktop, msg, 0 ); + + if (device->flags & RIDEV_NOLEGACY) + return FALSE; } if (!(msg = alloc_hardware_message( input->kbd.info, source, time ))) return 0; -- 2.21.0

4 years, 8 months

[PATCH 1/2] user32/edit: In EM_POSFROMCHAR return correct position for empty lines

by Fabian Maurer

Fix with permission from ROS Jira Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47305 Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> --- dlls/user32/edit.c | 2 +- dlls/user32/tests/edit.c | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/dlls/user32/edit.c b/dlls/user32/edit.c index 3c5331f9dc..6c758c3911 100644 --- a/dlls/user32/edit.c +++ b/dlls/user32/edit.c @@ -1102,7 +1102,7 @@ static LRESULT EDIT_EM_PosFromChar(EDITSTATE *es, INT index, BOOL after_wrap) x -= es->x_offset; } else - x = es->x_offset; + x = (lw > 0 ? es->x_offset : -es->x_offset); if (es->style & ES_RIGHT) x = w - (lw - x); diff --git a/dlls/user32/tests/edit.c b/dlls/user32/tests/edit.c index d0374c02a3..31f20fbc12 100644 --- a/dlls/user32/tests/edit.c +++ b/dlls/user32/tests/edit.c @@ -1142,6 +1142,9 @@ static void test_edit_control_4(void) int lo, hi, mid; int ret; int i; + HDC dc; + SIZE size; + RECT rect; trace("EDIT: Test EM_CHARFROMPOS and EM_POSFROMCHAR\n"); hwEdit = create_editcontrol(ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0); @@ -1251,6 +1254,22 @@ static void test_edit_control_4(void) ret = SendMessageA(hwEdit, EM_POSFROMCHAR, 2, 0); ok(-1 == ret, "expected -1 got %d\n", ret); DestroyWindow(hwEdit); + + /* Test newline when the edit control is scrolled to the right */ + + hwEdit = create_editcontrol(ES_MULTILINE | ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0); + SendMessageA(hwEdit, WM_SETTEXT, 0, (LPARAM)"wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww\r\n\r\n"); + SendMessageA(hwEdit, EM_SETSEL, 40, 40); + + dc = GetDC(hwEdit); + GetClientRect(hwEdit, &rect); + GetTextExtentPoint32A(dc, "w", 1, &size); + ReleaseDC(hwEdit, dc); + lo = (short)LOWORD(SendMessageA(hwEdit, EM_POSFROMCHAR, 42, 0)); + ret = (short)LOWORD(SendMessageA(hwEdit, EM_POSFROMCHAR, 40, 0)); + ret = size.cx * (-40) + ret; + ok(ret == lo, "expected %d got %d\n", ret, lo); + DestroyWindow(hwEdit); } /* Test if creating edit control without ES_AUTOHSCROLL and ES_AUTOVSCROLL -- 2.21.0

4 years, 9 months

Ubuntu 19.10 will be 64 bit only

by Rosanne DiMesio

https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-w… A user has already asked about this on the forum. https://forum.winehq.org/viewtopic.php?f=8&t=32565 The immediate question for me is whether to even bother trying to package Wine for Ubuntu 19.10 and up. The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions. I could build pure 64 bit Wine packages for Ubuntu. We've been telling users for 10 years that pure 64 bit Wine is not supported, but with so many systems going 64 bit only, perhaps it's time to reconsider that policy. There are certainly more 64 bit Windows apps now than there used to be, so it wouldn't be completely useless. The downside of doing that is that we will spend a lot of time explaining to users that pure 64 bit Wine will not run 32 bit programs, no matter how many places we plaster that information. The upside is that if we change that policy, I'm ready to go with pure 64 bit CentOS 7 packages. Thoughts? Perhaps this should be discussed at WineConf? -- Rosanne DiMesio dimesio(a)earthlink.net

4 years, 9 months

[PATCH] msvcrt: Fix handling of dst == src in wcscpy_s.

by Dmitry Timoshkov

Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/msvcrt/tests/string.c | 5 +++++ dlls/msvcrt/wcs.c | 13 +++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c index 0f1ee47d17..da6478c1b1 100644 --- a/dlls/msvcrt/tests/string.c +++ b/dlls/msvcrt/tests/string.c @@ -1020,6 +1020,11 @@ static void test_wcscpy_s(void) ok(ret == 0, "expected 0 got %d\n", ret); ok(lstrcmpW(szDest, szLongText) == 0, "szDest != szLongText\n"); + /* dest == source */ + ret = p_wcscpy_s(szDest, 18, szDest); + ok(ret == 0, "expected 0 got %d\n", ret); + ok(lstrcmpW(szDest, szLongText) == 0, "szDest != szLongText\n"); + /* Copy smaller buffer size */ errno = EBADF; szDest[0] = 'A'; diff --git a/dlls/msvcrt/wcs.c b/dlls/msvcrt/wcs.c index e62ac25edc..6b8c7bbe0f 100644 --- a/dlls/msvcrt/wcs.c +++ b/dlls/msvcrt/wcs.c @@ -2041,16 +2041,21 @@ INT CDECL MSVCRT_wcscpy_s( MSVCRT_wchar_t* wcDest, MSVCRT_size_t numElement, con if(!MSVCRT_CHECK_PMT(wcDest)) return MSVCRT_EINVAL; if(!MSVCRT_CHECK_PMT(numElement)) return MSVCRT_EINVAL; - wcDest[0] = 0; - - if(!MSVCRT_CHECK_PMT(wcSrc)) return MSVCRT_EINVAL; + if(!MSVCRT_CHECK_PMT(wcSrc)) + { + wcDest[0] = 0; + return MSVCRT_EINVAL; + } size = strlenW(wcSrc) + 1; if(!MSVCRT_CHECK_PMT_ERR(size <= numElement, MSVCRT_ERANGE)) + { + wcDest[0] = 0; return MSVCRT_ERANGE; + } - memcpy( wcDest, wcSrc, size*sizeof(WCHAR) ); + memmove( wcDest, wcSrc, size*sizeof(WCHAR) ); return 0; } -- 2.20.1

4 years, 9 months

Jump to page:

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