April 2016 - Wine-Devel - list.winehq.org

Re: Experimental 64 bit OS X packages ready for testing

by Sebastian Lackner

On 23.04.2016 20:31, Diego Vicioso wrote: > Any updates if it will be included into normal wine or future wine staging packages? > > Sent from my mac > Starting from 1.9.8, the installer packages available at [1] already contain experimental 64-bit support, which can be selected during the installation. Please be aware that there are still lots of issues left (both regular WOW64 issues and also OSX-specific issues), so use this option at your own risk. ;) An improved version of the "hack" mentioned by Michael Müller has been added to Wine Staging to evaluate how good this solution works (or until a better solution is found). Regards, Sebastian [1] https://dl.winehq.org/wine-builds/macosx/download.html

April 25, 2016

Re: [PATCH] kernel32/tests: Add initial tests for GetConsoleFontInfo (v2)

by Sebastian Lackner

On 25.04.2016 11:39, Hugh McMaster wrote: > On Sunday, 24 April 2016 11:43 PM, Sebastian Lackner wrote: > >> You'll have to add a stub first, otherwise it breaks the tests: > > I always thought the if check was supposed to guard against such crashes. This only works when the function name is not present in the spec file yet. When the spec file contains "stub", code will be generated to forward the call to __wine_spec_unimplemented_stub, so the function pointer is never really NULL.

April 25, 2016

Re: [PATCH] kernel32/tests: Add initial tests for GetConsoleFontInfo (v2)

by Hugh McMaster

On Sunday, 24 April 2016 11:43 PM, Sebastian Lackner wrote: > You'll have to add a stub first, otherwise it breaks the tests: I always thought the if check was supposed to guard against such crashes. hmod = GetModuleHandleA("kernel32.dll"); pGetConsoleFontInfo = (void *)GetProcAddress(hmod, "GetConsoleFontInfo"); if (!pGetConsoleFontInfo) { win_skip("GetConsoleFontInfo is not available\n"); return; } Anyway, I'm preparing a new version of the patch with additional tests, as I've worked out the values returned by this function.

April 25, 2016

Re: Fix a heap corruption when printing specific REG_MULTI_SZ values.

by Hugh McMaster

On Sunday, 24 April 2016 10:54 PM, Sebastian Lackner wrote: >On 24.04.2016 14:53, Hugh McMaster wrote: >> On Saturday, 23 April 2016 10:24 PM, Sebastian Lackner wrote: >> >>> On 23.04.2016 11:56, Hugh McMaster wrote: >>>> Which particular cases cause the heap corruption? >>> >>> It happens for example with a string like L"\0\0\0\0". After stripping off >>> the last two "\0" the allocated memory will have a size of 4 characters, >>> but the code below writes 5 characters. You can also test with warn+heap >>> after creating such a registry key. >> >> Such a string is invalid on Windows. You can't add it using regedit (the >> string is trimmed to a single \0 after closing the dialog editor). It also causes >> an error with 'reg add'. > > I've reproduced it by using regedit, so its not just a theoretical issue. Okay, I worked this out. It is possible to create such a string by using the "Modify binary data" menu option. I couldn't create it using the normal dialog editor, as it trims the string back to a single \0. Anyway, this is definitely a bug in reg.exe. Thanks for fixing this.

April 25, 2016

The future of the native theming support

by Ivan Akulinchev

So my GSoC proposal wasn't accepted this year. Probably it was my mistake by applying it too late, but this mail is not about this. Since a big research was already done, it would be fine to implement this feature anyway. The problem is that I still don't know what such people as Alexandre Julliard think about it. I got some positive feedback from normal users and even some Wine developers. However they don't make decisions about the Wine future and I don't want to spend my time if this feature will never get into upstream. As far as I know there already were some attempts to do something in this direction. But interesting patches I found in wine-patches were left without any response and Wine still looks like a monster from 90s. At the same time I see a lot of patches affecting the DirectX API. Is it the official position of the Wine maintainers to keep Wine as an OpenGL wrapper? Of course there are a lot of users who just want to play their Windows games on the Unix-like systems, but the need of working with normal desktop applications is still very high. There also were some questions about integrating new themes to the existing system. If it matters, I found a way to make it transparently for the end users. A new "GTK+" or even "Mac" theme can live together with old MSSTYLES themes without need of switching any "theme drivers" as it was said in my GSoC proposal. Regards, Ivan

April 25, 2016

Re: [PATCH 3/4] d3drm/tests: Replace test_Texture. (v2)

by Aaryaman Vasishta

Right, makes sense. I will resend this patch with the changes today. Fwiw, I've intentionally not added tests in patch 4/4 to validate the image struct in InitFromImage right now. I will include them in the implementation patch for this function. I'll be using a helper function which would validate the struct and return a BOOL, which would be re-used for CreateTexture as well. Cheers, Aaryaman On Mon, Apr 25, 2016 at 3:21 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > Am 2016-04-24 um 21:49 schrieb Aaryaman Vasishta: > > My bad, that was a copy mistake. Will resend patch. > Even better than not checking would be to fill the array with some > dummy value and checking that the content wasn't touched. > > I also recommend to re-order the tests so that failing tests are > grouped together. That way you don't have to re-fill the array with a > dummy value after a succeeding test. > > (try 2 sending this. Forgive me if it arrives twice) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXHT/uAAoJEN0/YqbEcdMwaXkP/iKRAq8nY5GxoETGm9pUZPML > xFzwsmiRGidQv+TpXX3e5jAvgljxZMAVdlapZwQlvzdlZQxkjS5DcbcSAwrRDxHB > QeRPaneMttPqYEQ7YCqpRt77/UNHtgTxjxF3RXMn1TIutnsTMiO6s4weyb0BbSdP > PTdqyAnV9XFqmUZDVcHq/4pvoX/XEnrk5zxkv6+kJo5vqAYLMjRrB4Lu+g8oqgPE > 1polBPIcRluYX+VWFNHWVSwmBOlO6MMDa4JLj5WbN/m0i/XQOYD5JjcXeF5cxBwd > jZ+8d2wvta8Sgl1oDKAGw+saHEKFBth9+zVa9AfcDUrNgsrq52DYneAXrGnsjfk3 > llL7Twz71eLtMo4YgRqLXLYxA5KCJSVvpwn8EaKBoCrUmv/pP/0j0MIZvMGXiQQG > /acO/bC2EsgkLW69Tj4D4fymeJNJlk5sZf7QbeNCh61JPRlSZblsSJVt4DkiBG/l > 7CKZXqtHOZhfqa1MUGXxEajyv25KoUIcinPtKTFGAv2CLk1dm3hj3FteRJJ7M6Ag > FTKN7k+67wJZUIrHLXYBWn1xjTmoYnbL5FHrDlGsEkTt655hEyhgzoL/e4XVnWdl > Hh9F9ntrGN487AX6bD5zNMf0oBizVhDPyXzFHXIc/+pl3PYceexhXN0REJ61NAmJ > qPqkXyPFigb34w/IzuVU > =n5WM > -----END PGP SIGNATURE----- >

April 25, 2016

Re: [PATCH 3/4] d3drm/tests: Replace test_Texture. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-04-24 um 21:49 schrieb Aaryaman Vasishta: > My bad, that was a copy mistake. Will resend patch. Even better than not checking would be to fill the array with some dummy value and checking that the content wasn't touched. I also recommend to re-order the tests so that failing tests are grouped together. That way you don't have to re-fill the array with a dummy value after a succeeding test. (try 2 sending this. Forgive me if it arrives twice) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXHT/uAAoJEN0/YqbEcdMwaXkP/iKRAq8nY5GxoETGm9pUZPML xFzwsmiRGidQv+TpXX3e5jAvgljxZMAVdlapZwQlvzdlZQxkjS5DcbcSAwrRDxHB QeRPaneMttPqYEQ7YCqpRt77/UNHtgTxjxF3RXMn1TIutnsTMiO6s4weyb0BbSdP PTdqyAnV9XFqmUZDVcHq/4pvoX/XEnrk5zxkv6+kJo5vqAYLMjRrB4Lu+g8oqgPE 1polBPIcRluYX+VWFNHWVSwmBOlO6MMDa4JLj5WbN/m0i/XQOYD5JjcXeF5cxBwd jZ+8d2wvta8Sgl1oDKAGw+saHEKFBth9+zVa9AfcDUrNgsrq52DYneAXrGnsjfk3 llL7Twz71eLtMo4YgRqLXLYxA5KCJSVvpwn8EaKBoCrUmv/pP/0j0MIZvMGXiQQG /acO/bC2EsgkLW69Tj4D4fymeJNJlk5sZf7QbeNCh61JPRlSZblsSJVt4DkiBG/l 7CKZXqtHOZhfqa1MUGXxEajyv25KoUIcinPtKTFGAv2CLk1dm3hj3FteRJJ7M6Ag FTKN7k+67wJZUIrHLXYBWn1xjTmoYnbL5FHrDlGsEkTt655hEyhgzoL/e4XVnWdl Hh9F9ntrGN487AX6bD5zNMf0oBizVhDPyXzFHXIc/+pl3PYceexhXN0REJ61NAmJ qPqkXyPFigb34w/IzuVU =n5WM -----END PGP SIGNATURE-----

April 24, 2016

Re: [PATCH 3/4] d3drm/tests: Replace test_Texture. (v2)

by Aaryaman Vasishta

My bad, that was a copy mistake. Will resend patch. On Mon, Apr 25, 2016 at 1:31 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-04-24 um 16:50 schrieb Aaryaman Vasishta: > > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > > + ok(hr == E_INVALIDARG, "GetClassName failed with %x\n", hr); > > + ok(size == sizeof("Texture") - 1, "wrong size: %u\n", size); > > + ok(!strcmp(cname, "Texture"), "Expected cname to be \"Texture\", > but got \"%s\"\n", cname); > The strcmp check here is misleading. The content is a leftover from the > previous successful call. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXHSYsAAoJEN0/YqbEcdMwVzUQAI5igH0GyGwby4/FQMWpOaDl > gXwxyST6BOhwnMfSNSdY/yFT0WqgLxm23+uE1fDsApaENRTEn1JzfSC8/DzeSeEd > KHv4QU2KeHlRtLl01CWJclwGgwgdCaP1b1+8mSzxXtWgfjZ2RRtGJON4STzDqLvt > G8DYYKJVEAgGQXq2o4N0ZtqRJmmOyOY9iR6Etwz1SoUOe3PgKHwbHEeAJ9YmbbzV > zJKkYxdEjuRcyO6Z5xXb5XLV2OBdYD/pqYPMwodQWfJIaht0Ui2GYrSI7Tw1b+DL > d/B6M6gYfYm9DAivlL5DflZoyLI4OIm95BRmOgtJZ3EY+qsR0UPuHEybCZnzy0u5 > 0qQNTGs4+sWecIcFQMmtOqj5wcesV0XPLiRr3nAPMuuIaiBNO3Yyvxu2f/KyLIEa > 3E3u6HmJtnyLJPK1btsc1mjsr21LpBA2sQ2AXYV/9wfQyIBhKUdk9gsC9lYNQEvm > eVRCtTg4BDIUTxze8lXGqslyio/5IEPr1dX0suX5Rj61tpcDgp6C1MdSiHZkliM3 > dTuk7Wu3dfdXCAZfGS/J+QfoQfXwP6NqYhIx6bzY48XGeL/N+m9rGC2lG1mMVROu > xW5lgCuZ5/Vt2Z7+qzfEVuI0HxQ+cXO86IEq1RClvszje+1stblLpTQDrAg/hy6G > X1q4jNhSjnxRP6Q0r2Ls > =39F6 > -----END PGP SIGNATURE----- >

April 24, 2016

Re: [PATCH 3/4] d3drm/tests: Replace test_Texture. (v2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-04-24 um 16:50 schrieb Aaryaman Vasishta: > + hr = IDirect3DRMTexture_GetClassName(texture1, &size, cname); > + ok(hr == E_INVALIDARG, "GetClassName failed with %x\n", hr); > + ok(size == sizeof("Texture") - 1, "wrong size: %u\n", size); > + ok(!strcmp(cname, "Texture"), "Expected cname to be \"Texture\", but got \"%s\"\n", cname); The strcmp check here is misleading. The content is a leftover from the previous successful call. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXHSYsAAoJEN0/YqbEcdMwVzUQAI5igH0GyGwby4/FQMWpOaDl gXwxyST6BOhwnMfSNSdY/yFT0WqgLxm23+uE1fDsApaENRTEn1JzfSC8/DzeSeEd KHv4QU2KeHlRtLl01CWJclwGgwgdCaP1b1+8mSzxXtWgfjZ2RRtGJON4STzDqLvt G8DYYKJVEAgGQXq2o4N0ZtqRJmmOyOY9iR6Etwz1SoUOe3PgKHwbHEeAJ9YmbbzV zJKkYxdEjuRcyO6Z5xXb5XLV2OBdYD/pqYPMwodQWfJIaht0Ui2GYrSI7Tw1b+DL d/B6M6gYfYm9DAivlL5DflZoyLI4OIm95BRmOgtJZ3EY+qsR0UPuHEybCZnzy0u5 0qQNTGs4+sWecIcFQMmtOqj5wcesV0XPLiRr3nAPMuuIaiBNO3Yyvxu2f/KyLIEa 3E3u6HmJtnyLJPK1btsc1mjsr21LpBA2sQ2AXYV/9wfQyIBhKUdk9gsC9lYNQEvm eVRCtTg4BDIUTxze8lXGqslyio/5IEPr1dX0suX5Rj61tpcDgp6C1MdSiHZkliM3 dTuk7Wu3dfdXCAZfGS/J+QfoQfXwP6NqYhIx6bzY48XGeL/N+m9rGC2lG1mMVROu xW5lgCuZ5/Vt2Z7+qzfEVuI0HxQ+cXO86IEq1RClvszje+1stblLpTQDrAg/hy6G X1q4jNhSjnxRP6Q0r2Ls =39F6 -----END PGP SIGNATURE-----

April 24, 2016

Re: WineHQ upgrade breaking dinput8:dinput?

by Francois Gouget

I have added binaries compiled with my MinGW with -O2 and -O0, and compiled with the TestBot compiler. I also added assembly files and compiler version information. All of this is available at: http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz For immediate reference: My compiler is the Debian Testing compiler (buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The TestBot compiler is the Debian 7.4 compiler (not buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And the WineTest.exe binary is compiled with the Debian 8 compiler which is presumably close to the current Debian Testing one. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

April 24, 2016