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

Wine native fps overlay
by CARLOS RODRIGUEZ May 9, 2017

May 9, 2017

>You suppress the rest of traces, like -all,+fps. >Many thanks i dont know this option can be used at same time, i thinking -all can disable +fpsAlmost forget will be posible wine can add some fps limiter, this will be usefull in many older titles when vsync dont workThanks again

3 2

Re: [PATCH 3/3] mshtml: Use IE version dependent on compatibility mode for conditional comments.
by Marvin May 9, 2017

May 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=30879 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2671: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 1/3] mshtml: Don't expose doScroll in IE11 document mode.
by Marvin May 9, 2017

May 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=30878 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2671: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH] ws2_32: Don't post completion packet if receiving fails with error immediately.
by Bruno Jesus May 9, 2017

May 9, 2017

On Mon, May 8, 2017 at 4:41 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This fixes bug 38980. > > This patch is the equivalent to 1bbe92e7 for receiving operations. > Application in bug 38980 uses libtorrent, which in turn uses boost's > async IO classes. Boost starts IO operations and waits for their results > via IOCP. If the operation fails right away it enqueues a completion > status itself. By failing and enquing a status we broke Boost's > receiving logic - after the first status was read the internal data was > reused elsewhere (though the pointer was not freed). The second IOCP > result caused boost to call libtorrent's callback function with bad > parameters, ultimately causing a segfault or assertion violation in > libtorrent. Awesome work, thanks ;-) Some unused SetLastError calls and since I'm sending an email why not complain more? > Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> > --- > dlls/ws2_32/socket.c | 2 - > dlls/ws2_32/tests/sock.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 127 insertions(+), 2 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 9d27fab..0950754 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -7744,9 +7744,7 @@ static int WS2_recv_base( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, > > if (errno != EAGAIN) > { > - int loc_errno = errno; > err = wsaErrno(); > - if (cvalue) WS_AddCompletion( s, cvalue, sock_get_ntstatus(loc_errno), 0 ); > goto error; > } > } > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 023eb42..7fefff5 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -9299,6 +9299,133 @@ static void test_completion_port(void) > if (dest != INVALID_SOCKET) > closesocket(dest); > > + /* Test IOCP response on successful immediate read. */ > + tcp_socketpair(&src, &dest); > + if (src == INVALID_SOCKET || dest == INVALID_SOCKET) > + { > + skip("failed to create sockets\n"); > + goto end; > + } > + > + bufs.len = sizeof(buf); > + bufs.buf = buf; > + flags = 0; > + > + iret = WSASend(src, &bufs, 1, &num_bytes, 0, &ov, NULL); > + ok(!iret, "WSASend failed - %d\n", iret); Some winsock functions are basically boolean where 0 is true and SOCKET_ERROR is false, so (I believe) in most other places we use "WSASend failed with error %d", GetLastError()). This would require a previous SetLastError. > + ok(num_bytes == sizeof(buf), "Managed to send %d\n", num_bytes); I believe most code in ws2_32 prefer "Expected X, got Y\n". > + > + io_port = CreateIoCompletionPort((HANDLE)dest, previous_port, 125, 0); > + ok(io_port != NULL, "failed to create completion port %u\n", GetLastError()); > + > + set_blocking(dest, FALSE); > + > + Sleep(100); Better to remove the extra new empty line as in the other use of Sleep there is no empty line. Besides it makes it harder for AJ to see you are adding sleep to tests :-) > + > + num_bytes = 0xdeadbeef; > + SetLastError(0xdeadbeef); SetLastError forever alone, no GetLastError. Maybe reuse the format from above? > + flags = 0; > + > + iret = WSARecv(dest, &bufs, 1, &num_bytes, &flags, &ov, NULL); > + ok(!iret, "WSARecv failed - %d\n", iret); > + ok(num_bytes == sizeof(buf), "Managed to read %d\n", num_bytes); Reuse expected/got message format? > + SetLastError(0xdeadbeef); > + key = 0xdeadbeef; > + num_bytes = 0xdeadbeef; > + olp = (WSAOVERLAPPED *)0xdeadbeef; > + > + bret = GetQueuedCompletionStatus( io_port, &num_bytes, &key, &olp, 200 ); > + ok(bret == TRUE, "failed to get completion status %u\n", bret); > + ok(GetLastError() == 0xdeadbeef, "Last error was %d\n", GetLastError()); > + ok(key == 125, "Key is %lu\n", key); > + ok(num_bytes == sizeof(buf), "Number of bytes transferred is %u\n", num_bytes); > + ok(olp == &ov, "Overlapped structure is at %p\n", olp); > + > + /* Test IOCP response on graceful shutdown. */ > + closesocket(src); > + Sleep(100); > + > + num_bytes = 0xdeadbeef; > + SetLastError(0xdeadbeef); No GetLastError. > + flags = 0; > + memset(&ov, 0, sizeof(ov)); > + > + iret = WSARecv(dest, &bufs, 1, &num_bytes, &flags, &ov, NULL); > + ok(!iret, "WSARecv failed - %d\n", iret); > + ok(!num_bytes, "Managed to read %d\n", num_bytes); > + > + SetLastError(0xdeadbeef); > + key = 0xdeadbeef; > + num_bytes = 0xdeadbeef; > + olp = (WSAOVERLAPPED *)0xdeadbeef; > + > + bret = GetQueuedCompletionStatus( io_port, &num_bytes, &key, &olp, 200 ); > + ok(bret == TRUE, "failed to get completion status %u\n", bret); > + ok(GetLastError() == 0xdeadbeef, "Last error was %d\n", GetLastError()); > + ok(key == 125, "Key is %lu\n", key); > + ok(!num_bytes, "Number of bytes transferred is %u\n", num_bytes); > + ok(olp == &ov, "Overlapped structure is at %p\n", olp); > + > + closesocket(src); > + src = INVALID_SOCKET; > + closesocket(dest); > + dest = INVALID_SOCKET; > + > + /* Test IOCP response on hard shutdown. */ > + tcp_socketpair(&src, &dest); > + if (src == INVALID_SOCKET || dest == INVALID_SOCKET) > + { > + skip("failed to create sockets\n"); > + goto end; > + } > + > + bufs.len = sizeof(buf); > + bufs.buf = buf; > + flags = 0; > + memset(&ov, 0, sizeof(ov)); > + > + ling.l_onoff = 1; > + ling.l_linger = 0; > + iret = setsockopt (src, SOL_SOCKET, SO_LINGER, (char *) &ling, sizeof(ling)); > + ok(!iret, "Failed to set linger %d\n", GetLastError()); > + > + io_port = CreateIoCompletionPort((HANDLE)dest, previous_port, 125, 0); > + ok(io_port != NULL, "failed to create completion port %u\n", GetLastError()); > + > + set_blocking(dest, FALSE); > + > + closesocket(src); > + src = INVALID_SOCKET; > + > + Sleep(100); > + > + num_bytes = 0xdeadbeef; > + SetLastError(0xdeadbeef); > + > + /* Somehow a hard shutdown doesn't work on my Linux box. It seems SO_LINGER is ignored. */ AFAIR this is not your fault, it is a bug. WSARecv has a particular behavior of not returning a "0 bytes read", instead it returns error with WSAECONNRESET. Wine simply returns success with 0 bytes, which stands for connection reset in the old recv() way. This explains the 3 todo_wine below. > + iret = WSARecv(dest, &bufs, 1, &num_bytes, &flags, &ov, NULL); > + todo_wine ok(iret == SOCKET_ERROR, "WSARecv failed - %d\n", iret); > + todo_wine ok(GetLastError() == WSAECONNRESET, "Last error was %d\n", GetLastError()); > + todo_wine ok(num_bytes == 0xdeadbeef, "Managed to send %d\n", num_bytes); Expected/got format? If not the sentence is wrong: send/recv. > + > + SetLastError(0xdeadbeef); > + key = 0xdeadbeef; > + num_bytes = 0xdeadbeef; > + olp = (WSAOVERLAPPED *)0xdeadbeef; > + > + bret = GetQueuedCompletionStatus( io_port, &num_bytes, &key, &olp, 200 ); > + todo_wine ok(bret == FALSE, "GetQueuedCompletionStatus returned %u\n", bret ); > + todo_wine ok(GetLastError() == WAIT_TIMEOUT, "Last error was %d\n", GetLastError()); > + todo_wine ok(key == 0xdeadbeef, "Key is %lu\n", key); > + todo_wine ok(num_bytes == 0xdeadbeef, "Number of bytes transferred is %u\n", num_bytes); > + todo_wine ok(!olp, "Overlapped structure is at %p\n", olp); > + > + num_bytes = 0xdeadbeef; > + SetLastError(0xdeadbeef); > + > + closesocket(dest); > + > dest = socket(AF_INET, SOCK_STREAM, 0); > if (dest == INVALID_SOCKET) > { > -- > 2.10.2 > > >

3 2

Re: [APPDB] Remove Steam and GOG from licenses
by Bruno Jesus May 9, 2017

May 9, 2017

On Mon, May 8, 2017 at 6:09 PM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > Steam and GOG are distribution platforms, not licenses. See bug 42970. Entries already using the mistakenly-added items will have to be manually fixed in the live database. What about changing them into a single LICENSE_DIGITAL which would encompass all online platforms.

2 1

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

>> 1) So question is - if winecfg shows up. Is that supported? Is it enough, >> when that _big_ "WARNING:" will be resolved (disappears), is such wine >> package supported? Most of them would be easy to overcome, except >> XInput2 + libOSMesa which needs IMHO deeper dependencies. > >If winecfg runs, that should be good enough. Optional packages can be >backported if necessary. > OK, then I will concentrate on min kernel version :)

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

> >None of those are needed by winecfg. They would be needed by some >applications, though. > I'm aware of it. But the idea is elsewhere... There are two approaches: 1. i will strictly find the lowest kernel on which i'm able to run winecfg but probably not much more... 2. i will find minimum requirements like pcap-v1.8.1 etc. so, that we can get rid of those generic: "configure: libpulse development files not found or __too__ __old__" but user will be given exact version (for Linux and those who care about other OS can do the same). Let's face it - most of programs says for example something like min supported OS: Win7 and higher) Isn't that "Bug 42478 - Undeclared O_CLOEXEC use in qcap DLL" about this? Quick googling sugest "O_CLOEXEC (Since Linux 2.6.23)". With commit dfd22fb294c6ce9c3daba311f96ca3b4933d265c shouldn't be min requirements bumped to linux-2.6.23 ?? Sure there is https://github.com/wine-compholio/wine-staging/blob/master/patches/qcap-O_C… Then two users having wine-2.7, but with totally different behavior, which is definitely harder to support... Maybe that's OK and then wine probably doesn't need nothing like minimum requirements. If we don't play on min requirements = it's normal, that some parts of wine do not work. Why there are two kinds of warning? a) configure: libmpg123 development files not found (or too old), mp3 codec won't be supported. b) configure: WARNING: libgnutls development files not found, no schannel support.

1 0

Re: [RFC] README: Update Linux version requirement to 2.3.31.
by wylda＠volny.cz May 8, 2017

May 8, 2017

>> >> Isn't commit https://source.winehq.org/git/wine.git/commitdiff/9f06a197c8c156acf21d8d809… >> about this? > >For that specific issue, yes. But it would be interesting to find out if >there are other issues that we aren't aware of, and whether they would >be worth trying to fix. Plan was: Debian 3.0 Woody i386 ===================== * Released 2002-07-19 * kernel v2.2.20, v2.4.6 kernel is also included Debian 3.1 Sarge i386 ===================== * Released 2005-06-06 * Linux kernel v2.4.27, v2.6.8 Debian 4.0 Etch i386 ==================== * Released 2007-04-08 * Linux kernel v2.6.18 After getting these, i started with Etch and wine-2.7. I installed all needed & available *-dev packages. Nevertheless i got: configure: XInput2 headers not found, the XInput 2 extension won't be supported. configure: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported. configure: OpenCL development files not found, OpenCL won't be supported. configure: pcap development files not found, wpcap won't be supported. configure: liblcms2 development files not found, Color Management won't be supported. configure: libpulse development files not found or too old, Pulse won't be supported. configure: gstreamer-1.0 base plugins development files not found, gstreamer support disabled configure: OSS sound system found but too old (OSSv4 needed), OSS won't be supported. configure: libudev development files not found, plug and play won't be supported. configure: libmpg123 development files not found (or too old), mp3 codec won't be supported. configure: libopenal development files not found (or too old), OpenAL won't be supported configure: openal-soft development files not found (or too old), XAudio2 won't be supported configure: WARNING: libgnutls development files not found, no schannel support. configure: Finished. Do 'make' to compile Wine. 1) So question is - if winecfg shows up. Is that supported? Is it enough, when that _big_ "WARNING:" will be resolved (disappears), is such wine package supported? Most of them would be easy to overcome, except XInput2 + libOSMesa which needs IMHO deeper dependencies. Anyway, configure suggest "do make". In that case compilation fails with: gcc -c -o v4l.o ../../../wine_git_src/dlls/qcap/v4l.c -I. -I../../../wine_git_src/dlls/qcap \ -I../../include -I../../../wine_git_src/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings \ -Wpointer-arith -gdwarf-2 -fno-omit-frame-pointer ../../../wine_git_src/dlls/qcap/v4l.c: In function ‘qcap_driver_init’: ../../../wine_git_src/dlls/qcap/v4l.c:802: error: ‘O_CLOEXEC’ undeclared (first use in this function) ../../../wine_git_src/dlls/qcap/v4l.c:802: error: (Each undeclared identifier is reported only once ../../../wine_git_src/dlls/qcap/v4l.c:802: error: for each function it appears in.) make[1]: *** [v4l.o] Error 1 make[1]: Leaving directory `/build/wine_git_bin_32/dlls/qcap' 2) And this also happens with "./configure --without-v4l" so probably real bug? 3) That "libpcap0.8-dev" isn't that old. So i looked closer and it appears, that it fails because of missing "port.h". IMHO that comes from kernel headers as i have it in v4.9, but not in v2.6.18. So minimum is not 2.3.31, but 2.6.18+ / 3.x ? or where that port.h appeared for the first time ?? ... configure:6945: checking pcap/pcap.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking pcap/pcap.h presence configure:6945: gcc -E conftest.c configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking for pcap/pcap.h configure:6945: result: yes configure:6945: checking poll.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking poll.h presence configure:6945: gcc -E conftest.c configure:6945: $? = 0 configure:6945: result: yes configure:6945: checking for poll.h configure:6945: result: yes configure:6945: checking port.h usability configure:6945: gcc -c -g -O0 conftest.c >&5 conftest.c:93:18: error: port.h: No such file or directory Before taking any other steps, i'll try to wait for feedback on 1), 2) and 3) Regards, W.

3 2

Re: [v5 PATCH 1/4] mfplat: Implement MFTRegister
by Alexandre Julliard May 8, 2017

May 8, 2017

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + if (cinput && input_types) > + { > + size = cinput * sizeof(MFT_REGISTER_TYPE_INFO); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + memcpy(types, input_types, size); > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; Again, why do you need a copy? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/9] winemac.drv: EnumDisplayDevices placeholder implementation
by Ken Thomases May 8, 2017

May 8, 2017

Hi, Thanks for taking this up again… On Apr 24, 2017, at 3:48 PM, Donat Enikeev <donat(a)enikeev.net> wrote: > > Based on Ken Thomases <ken(a)codeweavers.com> staging patches > > Signed-off-by: Donat Enikeev <donat(a)enikeev.net> > --- > dlls/winemac.drv/display.c | 51 +++++++++++++++++++++++++++++++++++++++ > dlls/winemac.drv/winemac.drv.spec | 1 + > 2 files changed, 52 insertions(+) This doesn't build: display.c:1007:13: error: use of undeclared identifier 'monitors' if (monitors[iDevNum].dwFlags & MONITORINFOF_PRIMARY) ^ display.c:1010:80: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ display.c:1010:45: error: use of undeclared identifier 'monitors' memcpy(lpDisplayDevice->DeviceName, monitors[iDevNum].szDevice, sizeof(monitors[iDevNum].szDevice)); ^ Is this patch written on the assumption that some other staging patches have already been applied? Beyond that, can you explain the rationale of moving the implementation of EnumDisplayDevices to the drivers? My patches implemented it in user32 based on EnumDisplayMonitors() and GetMonitorInfoW(). It may be somewhat clunky, but has the advantage that it ensures all three functions return mutually consistent results. Since you appear to have dropped my patches which caused GetMonitorInfoW() to return unique names for the displays, they are no longer consistent. GetMonitorInfoW() always uses "\\.\DISPLAY1" for all monitors while this implementation of EnumDisplayDevices() attempts to use "\\.\DISPLAY2", etc., for secondary and subsequent monitors. For what it's worth, my original patches were rejected because Alexandre wanted the tracking and management of displays and display modes centralized in the explorer process[1]. I have my reservations about that approach, mind you. ;) [1] https://www.winehq.org/pipermail/wine-devel/2014-March/103680.html Issues with other patches in the series: Patch 1: \ No newline at end of file Patches 1 and 2 ought to come after 3. In the current order, they introduce dead code. -Ken

2 3