January 2017 - Wine-devel - list.winehq.org

Re: [PATCH] Rename Mac OS X to macOS
by Nikolay Sivov 23 Jan '17

23 Jan '17

On 23.01.2017 22:19, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > en/winedev-multimedia.sgml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/en/winedev-multimedia.sgml b/en/winedev-multimedia.sgml > index fa04b04..4c95349 100644 > --- a/en/winedev-multimedia.sgml > +++ b/en/winedev-multimedia.sgml > @@ -330,7 +330,7 @@ Kernel space | Client applications > </listitem> > <listitem> > <para> > - Core Audio as introduced in Mac OS X 10.3. Source code resides in > + Core Audio as introduced in macOS 10.3. Source code resides in > <filename class="libraryfile">dlls/winecoreaudio.drv</filename>. > </para> > </listitem> > 10.3 was before macOS renaming, so original sounds better to me.

2 1

Re: [PATCH] programs/winhlp32: Use noyywrap for macro.lex.l
by Fabian Maurer 23 Jan '17

23 Jan '17

On Sunday, January 22, 2017 11:00:26 AM CET Mike Swanson wrote: > diff --git a/programs/winhlp32/macro.lex.l b/programs/winhlp32/macro.lex.l > index 8f6945ca98..ff8a4832d3 100644 > --- a/programs/winhlp32/macro.lex.l > +++ b/programs/winhlp32/macro.lex.l > @@ -20,7 +20,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, > USA */ > %} > -%option noinput nounput never-interactive 8bit > +%option noinput nounput noyywrap never-interactive 8bit > %x quote > %{ > #include "config.h" > @@ -367,7 +367,3 @@ WINHELP_WINDOW* MACRO_CurrentWindow(void) > { > return lex_data ? lex_data->window : Globals.active_win; > } > - > -#ifndef yywrap > -int yywrap(void) { return 1; } > -#endif > -- > 2.11.0 Hello, I applied the patch and it compiles now, but I get a warning: > macro.lex.yy.c:398:0: warning: "yywrap" redefined > macro.lex.yy.c:74:0: note: this is the location of the previous definition You probably want to get rid of that, too. Regards, Fabian

4 5

Re: [PATCH] ws2_32/tests: Fix memcmp size in test_TransmitFile().
by Bruno Jesus 23 Jan '17

23 Jan '17

On Fri, Jan 20, 2017 at 5:54 PM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=42221 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/ws2_32/tests/sock.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 5856718..3c3e443 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -8304,9 +8304,9 @@ static void test_TransmitFile(void) > iret = recv(dest, buf, sizeof(buf), 0); > ok(iret == sizeof(header_msg)+sizeof(footer_msg)+2, > "Returned an unexpected buffer from TransmitFile: %d\n", iret ); > - ok(memcmp(&buf[0], &header_msg[0], sizeof(header_msg)+1) == 0, > + ok(memcmp(&buf[0], &header_msg[0], sizeof(header_msg)) == 0, > "TransmitFile header buffer did not match!\n"); > - ok(memcmp(&buf[sizeof(header_msg)+1], &footer_msg[0], sizeof(footer_msg)+1) == 0, > + ok(memcmp(&buf[sizeof(header_msg)+1], &footer_msg[0], sizeof(footer_msg)) == 0, > "TransmitFile footer buffer did not match!\n"); Hi, you also have to change the sending lengths because it is also using +1. I believe this was a strlen/sizeof misfortune, right? Best wishes, Bruno

3 4

Re: server: Remove dead check in is_cpu_supported().
by Henri Verbeet 22 Jan '17

22 Jan '17

For what it's worth, On 21 January 2017 at 16:25, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > I am wondering about the following piece of code in server/thread.c: > > int is_cpu_supported( enum cpu_type cpu ) > { > unsigned int prefix_cpu_mask = get_prefix_cpu_mask(); > > if (CPU_FLAG(cpu) && (supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu))) return 1; > > that was added as part of > > commit 1e78c99388c61d353cf60787eac6415328f54560 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Fri Nov 22 12:32:48 2013 +0100 > > kernel32: Validate the architecture of newly created processes on the server side. > It's actually older than that, and seems to have been introduced by commit 279defe66e1265eeae3e2a72126c2b2f75e20c99 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Apr 3 14:59:12 2009 +0200 server: Verify that the client is using a supported CPU type. > That means CPU_FLAG(...) is always positive and different from zero > -- unless its parameter is 32 or higher on a 32-bit architecture > (and the 1 shifts out). > But the definition of CPU_FLAG doesn't really matter for this. If "CPU_FLAG(cpu)" evaluates to zero, "supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu)" evaluates to zero as well.

2 1

Re: [PATCH] ws2_32/tests: Fix memcmp size in test_TransmitFile().
by Marvin 22 Jan '17

22 Jan '17

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=27913 Your paranoid android. === w8 (32 bit sock) === sock.c:7995: Test failed: bytesReturned isn't supposed to be 1 sock.c:8019: Test failed: GetOverlappedResult failed, error 0

1 0

TestBot news
by Francois Gouget 21 Jan '17

21 Jan '17

I have upgraded Debian on vm1 from 7 to 8.6 and the filesystem from ext3 to ext4. This gets it a non-antique version of the kernel and QEMU which includes Huw's fix for the ntdll:exception test. So there should be one less unfixable failure for VMs being run on vm1. That said I'm not really happy with the state of things on vm1: for some reason its reverts are much slower than they should be. For instance with the wvista VM doing 3 reverts in a row on otherwise idle machines gives me: vm1 56.361s 46.803s 46.569s vm2 10.206s 9.783s 9.912s vm3 9.583s 8.137s 8.004s One could think that vm2 has much better hardware but that's just not the case: PassMark Disk Disk Host CPU MT ST Type Speed vm1 Xeon E3-1230v2 8855 1940 HD 130 MB/s vm2 Opteron 6128 6959 n/a HD Raid0 144 MB/s vm3 Xeon E3-1226v3 7462 2127 SSD 354 MB/s All hosts have 16 GB of RAM. So vm2 has what looks like a somewhat slower processor and a marginally faster disk thanks to Raid0. That should not be sufficient for it to be 4 times faster, particularly given that vm3 has a disk that's over twice as fast is only marginally faster than vm2. Indeed during the revert vm1 shows no read traffic (lots of RAM to cache that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just uses CPU for the last ~4 seconds. vm3 also shows it's not an AMD vs Intel thing. There may be some missing CPU feature on vm1 but if that's the case I don't see what. So there is still a mystery there and if anyone has an insight into it it would be appreciated. Despite that I have put vm1 back to active duty. But I decided to keep the wvistau64 VM on the vm2 host. This means vm1 essentially only has one VM to take care of and since most of the time it's going to be idle already it should not slow jobs down. I also applied all Windows updates up to 2016/07/25 to the w7u VM. This caused some new failures that Hans started tackling / fixed. Any other new failure on the 3 VMs affected by the upgrade (wvista, wvistau64 and w7u) should be fixable. The configuration of the other two vms, wvista and wvistau64 should be essentially unchanged. Finally I also performed a minor upgrade on vm3: from Debian 8.2 to 8.6. The goal was to see if the minor QEMU upgrade would be sufficient to get Windows 10 to stop crashing when running WineTest. It looks like that's not the case. So the next step will be to grab QEMU 2.7 from the Debian BackPorts but there's a dumb command line incompatibility with libvirt 1.2.9 and there's no easily installable alternative :-( Fortunately I have a qemu wrapper script that should bridge the gap. -- Francois Gouget <fgouget(a)codeweavers.com>

4 9

authz.dll
by André Hentschel 21 Jan '17

21 Jan '17

Hi, while looking through the output of my wip script for detecting wrong spec file entries I came across authz.dll And here we have two suspicious functions: AuthzInitializeContextFromSid and AuthzInitializeContextFromToken Both have a parameter of type "LUID" (a struct, not a pointer) which is defined as: typedef struct _LUID { DWORD LowPart; LONG HighPart; } LUID, *PLUID; The spec-file says this is a long: @ stdcall AuthzInitializeContextFromSid(long ptr long ptr long ptr ptr) @ stdcall AuthzInitializeContextFromToken(long long long ptr long ptr ptr) I think a struct like this deserves two longs ("long long") in the spec file, right?

1 0

Wine and Valgrind / handling SIGILL
by Austin English 20 Jan '17

20 Jan '17

Howdy all, Several months ago, a patch from Sebastian: commit 44fbc018eda12bdee5c2c1e2e40dbdc6a81b27fd Author: Sebastian Lackner <sebastian(a)fds-team.de> Date: Thu Feb 12 11:09:34 2015 +0100 winebuild: Do not access memory below ESP when restoring thread contexts. Based on a patch by John Reiser. for https://bugs.winehq.org/show_bug.cgi?id=14367 Caused problems for running Wine under Valgrind: https://bugs.kde.org/show_bug.cgi?id=344139 There are patches floating around for both Wine and Valgrind (see previous link), but from what I've seen so far, both projects aren't a fan of the current patches. Given that Wine developers like using Valgrind to check for problems, and I know Julian would like to use Wine with Valgrind, I feel like some solution to this problem can be found. Since my efforts at trying to run messages between the two projects hasn't solved it yet, I figured an email thread would work better ;). -- -Austin GPG: 14FB D7EA A041 937B

3 7

Wine-2.0-rc5 source code (Cppcheck 1.72)
by Игорь Чебаненко 20 Jan '17

20 Jan '17

Wine source code scanning with Cppcheck.

1 0

Re: [PATCH 5/5] wined3d: Recognize another Radeon HD 4650 PCI device id.
by Henri Verbeet 19 Jan '17

19 Jan '17

On 18 January 2017 at 21:35, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > For bug 34671, with thanks to winetaste(a)gmx.net for the relevant info. > This still doesn't make sense to me. In what cases does this make a difference? Which of those do we care about? > @@ -2018,8 +2019,8 @@ cards_amd_binary[] = > - {"HD 4670", CARD_AMD_RADEON_HD4600}, /* Radeon RV730 */ > - {"HD 4650", CARD_AMD_RADEON_HD4600}, /* Radeon RV730 */ > + {"HD 4670", CARD_AMD_RADEON_HD4650}, /* Radeon RV730 */ > + {"HD 4650", CARD_AMD_RADEON_HD4650}, /* Radeon RV730 */ This is arbitrary.

2 2