January 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 6/6] kernel32: Invalid console handles for new processes are 0, not INVALID_HANDLE_VALUE.

by Alistair Leslie-Hughes

On 21/01/15 08:51, Erich E. Hoover wrote: > Several applications rely on the TEB value for fresh invalid console > handles to be zero instead of INVALID_HANDLE_VALUE (fixes Bug #36216 > and Bug #37914). > > +····if·(!params->hStdOutput·||·params->hStdOutput·==·INVALID_HANDLE_VALUE) > +········params->hStdOutput·=·0; The !params->hStdOutput check is redundant since it's already 0. Applies to the other places as well. Best Regards Alistair Leslie-Hughes

Jan. 21, 2015

Re: user32/tests: Don't test function directly when reporting GetLastError()

by Marvin

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=11234 Your paranoid android. === w7u (32 bit msg) === msg.c:12108: Test failed: unexpected hwnd 0014013C

Jan. 21, 2015

Re: About Patch 108345 Pending ( gdiplus: fix get_clip_hrgn when window origin point changed (try 2) )

by Vincent Povirk

I was OK with try 1, and I also have no problems with this version. I think it is a correct change and should be committed.

Jan. 19, 2015

Re: gdi32: Do not enumerate fonts with names that are too long

by Aric Stewart

On 1/16/15 9:52 PM, Dmitry Timoshkov wrote: > Aric Stewart <aric(a)codeweavers.com> wrote: > >> Both the FullName and the FamilyName need to fit in the LOGFONT >> structure. > > What happens with such a font under Windows? I'd expect the name be > simply truncated instead of the font being skipped. In the latter > case the font should not be added to the list at all. > Thanks to Nikolay Sivov for doing tests for me. Windows refuses to install the font. So I have move the code to prevent the face from being added to the font list at all. -aric

Jan. 19, 2015

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.

by Henri Verbeet

On 19 January 2015 at 13:46, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2014-12-08 um 12:04 schrieb Henri Verbeet: > >> - if (device->filter_messages) > >> + if (device->filter_messages && message != WM_DISPLAYCHANGE) > > That seems pretty specific. I'd be curious how other broadcast > > messages are handled. > I did some testing on this and tried to send some messages to the > window from inside the WM_DISPLAYCHANGE message handler. I did not > manage to get any message through, not even WM_DISPLAYCHANGE. > HWND_BROADCAST doesn't help either. Broadcast messages are sent to > other windows (e.g. the device window) as expected. > Perhaps more concretely, if for example the time is changed (e.g. because of an application calling SetSystemTime() or DST adjustments), do you receive WM_TIMECHANGE, or is it filtered?

Jan. 19, 2015

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.

by Henri Verbeet

On 19 January 2015 at 13:59, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2014-12-08 um 12:04 schrieb Henri Verbeet: >>> + { >>> + if (unicode) >>> + DefWindowProcW(window, message, wparam, lparam); >>> + else >>> + DefWindowProcA(window, message, wparam, lparam); >>> + } >>> + } >>> >>> if (unicode) return CallWindowProcW(proc, window, message, wparam, lparam); >> Is this really how it's supposed to work? In particular, should >> DefWindowProc really always get the message before the application >> does, or should we give the application a chance first, and only >> pass to DefWindowProc if it doesn't handle the message? > That's how I read the test results. I get the messages resulting from > the WM_SYSCOMMAND(SC_RESTORE) handling before I see the WM_SYSCOMMAND > message itself. This is different from the other WM_SYSCOMMAND > operations where the WM_SYSCOMMAND arrives first, and the rest of the > messages is triggered by the wndproc calling DefWindowProc. > It's been a while since I looked at this patch set in detail, but IIRC the test didn't distinguish between DefWindowProc or the application getting the message first. I.e., it would still pass if the application got the message before DefWindowProc instead of the other way around, which arguably would be the more logical order. Perhaps I misremember though.

Jan. 19, 2015

Re: [PATCH 2/5] wined3d: Handle the SM4 SV_POSITION pixel shader input semantic in the GLSL shader backend.

by Henri Verbeet

On 19 January 2015 at 14:31, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-01-19 um 13:44 schrieb Henri Verbeet: >> This is (mostly) equivalent to the vPos register in SM3. >> ... >> + if (!strcmp(semantic_name, "SV_POSITION")) >> + shader_addline(buffer, "ps_in[%u]%s = vpos%s;\n", >> + shader->u.ps.input_reg_map[i], reg_mask, reg_mask); > The vpos variable has the d3d9 0.5 pixel offset applied, which to my knowledge is not correct for d3d10. Is this intentional? (I guess yes, either for simplicity to make patch 3 work and / or because we're still adding the offset on the vertex side even in d3d10.) > Sort of. I'm deferring a bunch of details like pixel centers until there's enough infrastructure in place to just port the equivalent d3d9 tests to d3d10.

Jan. 19, 2015

Re: [PATCH 2/5] wined3d: Handle the SM4 SV_POSITION pixel shader input semantic in the GLSL shader backend.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-19 um 13:44 schrieb Henri Verbeet: > This is (mostly) equivalent to the vPos register in SM3. > ... > + if (!strcmp(semantic_name, "SV_POSITION")) > + shader_addline(buffer, "ps_in[%u]%s = vpos%s;\n", > + shader->u.ps.input_reg_map[i], reg_mask, reg_mask); The vpos variable has the d3d9 0.5 pixel offset applied, which to my knowledge is not correct for d3d10. Is this intentional? (I guess yes, either for simplicity to make patch 3 work and / or because we're still adding the offset on the vertex side even in d3d10.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUvQcWAAoJEN0/YqbEcdMwutkP/irVdyJWjIwnAnwgltjehO9A Vp4CZneYnbnAP/SJjhvsY7RwhHdUelzhv8wX8m9q0Y92jPMtvTt6OMAdppxATSOY Bo70j7fpaMJbRG/GCrDSCp3geyzN/1p6CQu5JfahVuSBOGg7EIDdR0OA4hA9aDEE R/pzerlOuvIY8vMOejYk99wBWEOLWJUcWNfrRq30ASnyIK6wcBhr3QLdcRI8/57m +MtFG53+R6wGdRQih1PfmDP4CJnfhr33TQgKod9ezYGyNcS8X/rRTq3mE0uqq3TJ 7+S4A21o7j2nEBlEWlwt6op7Yg2xhMan5znQU/MwREFaGGPWdapNpl1NxpWM/wp0 zm992j3TgpCqHLCW0u8Z5t2fClWuyU8IcZWsLql2FVZa3DvG6QOeXS3oEVlw5jxu fU9iMiJeh7Aywt8tvro4kG5opA2CCUFUJu1Cf7FBQpAUtHYqY5B1vm67fzeMfLt5 C2XC6L79dK0L0YenFqrGWQOU5/u4skW5Cgi5Yt5AKx0Ifk4gTrPq1/pSCeEFUS+T H2ZjZCqCYYp7NCWSXQSpBSFcVE7bURfJNBC3j9TTBCoT/pCOTKr8vv6Dqn0pjxku 6hdmAEaW7vUKr6ucUopgDNQ6E+aCdaofUMqJuhlOAOL8arthwIPZbO2hb8lLTSBq Smb3+zJL2d2YBZZelE4f =0cAR -----END PGP SIGNATURE-----

Jan. 19, 2015

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-12-08 um 12:04 schrieb Henri Verbeet: >> + { >> + if (unicode) >> + DefWindowProcW(window, message, wparam, lparam); >> + else >> + DefWindowProcA(window, message, wparam, lparam); >> + } >> + } >> >> if (unicode) return CallWindowProcW(proc, window, message, wparam, lparam); > Is this really how it's supposed to work? In particular, should > DefWindowProc really always get the message before the application > does, or should we give the application a chance first, and only > pass to DefWindowProc if it doesn't handle the message? That's how I read the test results. I get the messages resulting from the WM_SYSCOMMAND(SC_RESTORE) handling before I see the WM_SYSCOMMAND message itself. This is different from the other WM_SYSCOMMAND operations where the WM_SYSCOMMAND arrives first, and the rest of the messages is triggered by the wndproc calling DefWindowProc. The test doesn't check for the absence of a message at specific points in the message sequence though, so I guess it would not fail if d3d9 called the window proc, then DefWindowProc and then the window proc again. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBAgAGBQJUvP+uAAoJEN0/YqbEcdMw8k8P9iSVe6GAZxoN/C2lcdvlaDNo E1IPKzeAAkD6E9+7t+NscbV10iKKaiH1SWM94ETH6NdJBPQvY3R93/6Nj1BbxFgF GnOgmWmOXb6iUr7XOzV4qeuNlaTk3MYARGT2JQVMa2OvO+Irac/epOTrzNhF0osL jatwgGtmG8SSpdybEZDamkeirE9uci2rBu5tomluh4A3twmaeQ6ZBsfUmL9VmqCE gO+zmuHauPe03UCzz3v/P0iIkgYlIRZcLsJSPFVHEFfG9a5cbo2/sHSFGmCmzlDV TWrkaclu9AmKhXB/1f04E4Jhmei3pdyuOxH+3doZ87KSsOgq07n8n/1ith9JmjCd We3kwQhzQhzzm40C76fx3/lrdjaxy2Ar5k1G1YIu65MFjWOcjyUNcRM3A5gzo61I ZrsxFfKeAUBtmN7ruFSpDdWVqVA9Cj0lxGnOY3L/EWGf/urY5KeFRsHE+hLutvr1 wSUUJQJ0sY9eJdCAWqEQwsFv3QATfwPu8QI6TuifYICp/Lt056bfM1q4rgJjks65 lPVFsdy875aB/1wcaH7afTBLMNEOzqGyIo7CE6o0vK0hOUR7UwQs7Le5q1xAjFr2 ZMhK+uqaZICufoBdQk8q63Dr8mwxj/8LAjnsP3op3ZPiO/YnQf13Q+xst0fxOGSq 3nGMTa9rkf4PD6z8J9A= =nwva -----END PGP SIGNATURE-----

Jan. 19, 2015

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2014-12-08 um 12:04 schrieb Henri Verbeet: >> - if (device->filter_messages) >> + if (device->filter_messages && message != WM_DISPLAYCHANGE) > That seems pretty specific. I'd be curious how other broadcast > messages are handled. I did some testing on this and tried to send some messages to the window from inside the WM_DISPLAYCHANGE message handler. I did not manage to get any message through, not even WM_DISPLAYCHANGE. HWND_BROADCAST doesn't help either. Broadcast messages are sent to other windows (e.g. the device window) as expected. It is possible that WM_DISPLAYCHANGE and WM_IME_NOTIFY are generated by d3d9 rather than just whitelisted. The behavior is also different if the device is created by a thread that does not own the window. In this case the owning thread has to pump messages, otherwise CreateDevice gets stuck. A lot more messages can be seen, but not WM_WINDOWPOSCHANGING / WM_WINDOWPOSCHANGED. I don't plan to spend more time on the filtering behavior until we find an application that has trouble with the current code though. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUvPy+AAoJEN0/YqbEcdMwnfUQAILuR3RdaNvJ0DZIB5b3ifgm o/dhCRM9za3+y/TVm0k/nQBtYduVsAFk4vFvvOjE0gc+pddVhcFE+FFPv/BaXSLN jGhyJyOiDMn+4ETzDLw4AzpAkx0eVZfAJSbonDgWLLHCyYbolPjg8V3G/62Vaj85 GSEG5icXxAIRRZgjyDaqdEEI3u/oYsdBtl8EssmhJ0t8qr7vjyfgCrn7MuWngnxu CB2+qDTWU3zxoam03VFM+W3fKWtmHOhI/S1kknepBtv50X4ny/ZwqmbgFQDL4pIw Ejlh9AH/cGkrwWTGOEYr8M2ZSNSM4IRmCCFz4GUkZOhJ3tnn1lCOKdn4P1x8CSFy oqELJQmE0shrBLUVWE3sgldjqYUFhCjPbBM0gVF8J9t1VQQVd8+txqirJx5ki6Kr I8ZEspoCOPdw5ojj9HuI7slJh3xP1jD7YtrfjAwEdINwblSAhHanBRItFg+jSO5I mS6c89WKLzD6qr8ibgazhWIgCdHIyJjLvCTWonQQrUAjGVdUM/NQMzzkpBpxt7IP V4qqeypZ9072tK90s8gP/s0Uq9FR3pUYKEWsS9Fu2+7EZAGSvCEGdldjMvDWh2gd P9NbXooR3BoR/eTEXysT63jy/YeBPDJNpkK7T20qIbRmt/vUYipkA8QvPs478TLy XsrUtSA3DN2OqHBNENVI =LK+0 -----END PGP SIGNATURE-----

Jan. 19, 2015