August 2016 - Wine-devel - list.winehq.org

Re: [PATCH 02/11] wined3d: Add WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH flag.
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (mode) > + ERR("Ignoring mode.\n"); I think it's unclear what this means. "Ignoring mode" seems to suggest we're ignoring the mode, but shouldn't, in which case this should be a FIXME instead of an ERR. It could also mean the user of the API supplied a mode, but it has no effect because WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH is not set on the swapchain, in which case this should be a WARN instead of an ERR. > -#define WINED3DPRESENTFLAG_LOCKABLE_BACKBUFFER 0x00000001 > -#define WINED3DPRESENTFLAG_DISCARD_DEPTHSTENCIL 0x00000002 > -#define WINED3DPRESENTFLAG_DEVICECLIP 0x00000004 > -#define WINED3DPRESENTFLAG_VIDEO 0x00000010 > -#define WINED3DPRESENTFLAG_NOAUTOROTATE 0x00000020 > -#define WINED3DPRESENTFLAG_UNPRUNEDMODE 0x00000040 > +#define WINED3DSWAPCHAIN_LOCKABLE_BACKBUFFER 0x00000001 > +#define WINED3DSWAPCHAIN_DISCARD_DEPTHSTENCIL 0x00000002 > +#define WINED3DSWAPCHAIN_DEVICECLIP 0x00000004 > +#define WINED3DSWAPCHAIN_VIDEO 0x00000010 > +#define WINED3DSWAPCHAIN_NOAUTOROTATE 0x00000020 > +#define WINED3DSWAPCHAIN_UNPRUNEDMODE 0x00000040 > +#define WINED3DSWAPCHAIN_ALLOW_MODE_SWITCH 0x00001000 Since you're renaming things, I think I'd prefer these as "WINED3D_SWAPCHAIN_". We'll probably want flags/masks to be unsigned, although it usually doesn't make a difference in practice.

2 1

Re: [PATCH 06/11] dxgi: Switch display mode when creating fullscreen swapchains.
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain->fullscreen) > + { > + if (FAILED(hr = wined3d_swapchain_set_fullscreen(swapchain->wined3d_swapchain, > + desc, NULL))) > + { > + WARN("Failed to set fullscreen state, hr %#x.\n", hr); > + wined3d_swapchain_decref(swapchain->wined3d_swapchain); > + goto cleanup; > + } > + > + if (FAILED(hr = IDXGISwapChain_GetContainingOutput(&swapchain->IDXGISwapChain_iface, > + &swapchain->target))) > + { > + struct wined3d_swapchain_desc wined3d_desc = *desc; > + WARN("Failed to get target output for fullscreen swapchain, hr %#x.\n", hr); > + wined3d_desc.windowed = FALSE; > + if (FAILED(hr = wined3d_swapchain_set_fullscreen(swapchain->wined3d_swapchain, > + &wined3d_desc, NULL))) Is this needed, or should swapchain destruction take care of this?

2 1

Re: [PATCH 10/11] dxgi: Add multi-monitor test for IDXGISwapChain_GetContainingOutput().
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/dxgi/tests/device.c | 159 ++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 135 insertions(+), 24 deletions(-) > "dxgi/tests: ", right?

1 0

Re: [PATCH 05/11] dxgi: Implement dxgi_swapchain_SetFullscreenState().
by Henri Verbeet 02 Aug '16

02 Aug '16

On 1 August 2016 at 22:28, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (fullscreen) > + { > + if (target) > + { > + IDXGIOutput_AddRef(target); > + } > + else if (!target && FAILED(hr = IDXGISwapChain_GetContainingOutput(iface, &target))) The "!target" is redundant.

1 0

Re: [PATCH 1/2] msvcp140: Add MSVC 2015 C++ support DLL (try 3)
by Piotr Caban 02 Aug '16

02 Aug '16

On 08/02/16 01:40, Daniel Lehman wrote: > Try 3: > - use commented out externs for vtables > Try 2: > - add -arch to stubs > - use #define in _scprintf Here's the list of stubs that still needs to be changed: ?_Init_cnt(a)_UShinit@std@@0HA :- private: static int std::_UShinit::_Init_cnt ?id@?$codecvt(a)DDU_Mbstatet@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::codecvt<char,char,struct _Mbstatet>::id ?id@?$codecvt(a)GDU_Mbstatet@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::codecvt<unsigned short,char,struct _Mbstatet>::id ?id@?$codecvt(a)_WDU_Mbstatet@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::codecvt<wchar_t,char,struct _Mbstatet>::id ?id@?$messages(a)D@std@@2V0locale(a)2@A :- public: static class std::locale::id std::messages<char>::id ?id@?$messages(a)G@std@@2V0locale(a)2@A :- public: static class std::locale::id std::messages<unsigned short>::id ?id@?$messages(a)_W@std@@2V0locale(a)2@A :- public: static class std::locale::id std::messages<wchar_t>::id ?id@?$money_get(a)DV?$istreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_get<char,class std::istreambuf_iterator<char,struct std::char_traits<char> > >::id ?id@?$money_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_get<unsigned short,class std::istreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$money_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_get<wchar_t,class std::istreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?id@?$money_put(a)DV?$ostreambuf_iterator(a)DU?$char_traits(a)D@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_put<char,class std::ostreambuf_iterator<char,struct std::char_traits<char> > >::id ?id@?$money_put(a)GV?$ostreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_put<unsigned short,class std::ostreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$money_put(a)_WV?$ostreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::money_put<wchar_t,class std::ostreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?id@?$moneypunct(a)D$00(a)std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<char,1>::id ?id@?$moneypunct(a)D$0A@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<char,0>::id ?id@?$moneypunct(a)G$00(a)std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<unsigned short,1>::id ?id@?$moneypunct(a)G$0A@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<unsigned short,0>::id ?id@?$moneypunct(a)_W$00(a)std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<wchar_t,1>::id ?id@?$moneypunct(a)_W$0A@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::moneypunct<wchar_t,0>::id ?id@?$time_get(a)GV?$istreambuf_iterator(a)GU?$char_traits(a)G@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::time_get<unsigned short,class std::istreambuf_iterator<unsigned short,struct std::char_traits<unsigned short> > >::id ?id@?$time_get(a)_WV?$istreambuf_iterator(a)_WU?$char_traits(a)_W@std@@@std@@@std@@2V0locale(a)2@A :- public: static class std::locale::id std::time_get<wchar_t,class std::istreambuf_iterator<wchar_t,struct std::char_traits<wchar_t> > >::id ?intl@?$moneypunct(a)D$00(a)std@@2_NB :- public: static bool const std::moneypunct<char,1>::intl ?intl@?$moneypunct(a)D$0A@@std@@2_NB :- public: static bool const std::moneypunct<char,0>::intl ?intl@?$moneypunct(a)G$00(a)std@@2_NB :- public: static bool const std::moneypunct<unsigned short,1>::intl ?intl@?$moneypunct(a)G$0A@@std@@2_NB :- public: static bool const std::moneypunct<unsigned short,0>::intl ?intl@?$moneypunct(a)_W$00(a)std@@2_NB :- public: static bool const std::moneypunct<wchar_t,1>::intl ?intl@?$moneypunct(a)_W$0A@@std@@2_NB :- public: static bool const std::moneypunct<wchar_t,0>::intl Thanks, Piotr

1 0

Re: [PATCH] ddraw: Fix its vs it's typos
by Marvin 01 Aug '16

01 Aug '16

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=24668 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 2/2] kernel32/tests/thread: Add tests for fiber-local storage.
by Marvin 01 Aug '16

01 Aug '16

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=24663 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH 1/2] kernel32/tests/loader: Add tests for fiber-local storage.
by Marvin 01 Aug '16

01 Aug '16

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=24662 Your paranoid android. === w1064 (32 bit loader) === loader.c:2979: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2979: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2979: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2980: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2987: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 3: Wrong callback count: 0 loader.c:2987: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2988: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:177: Test failed: WriteFile error 1784

1 0

Wine's forked version of fontforge
by Jens Reyer 01 Aug '16

01 Aug '16

Hi, in Debian we're currently moving to enable the maintainer mode to e.g. rebuild Wine's TrueType fonts. AJ already warned us that this is risky: On 04/01/2016 04:54 AM, wine-bugs(a)winehq.org wrote: > https://bugs.winehq.org/show_bug.cgi?id=40391 > > --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- > There is definitely a risk too, particularly for fonts. They are supposed to be > built with our forked version of fontforge > (https://source.winehq.org/git/fontforge.git) that contains a couple of fixes > compared to the upstream version. I really appreciate that warning, thanks again! See a "short" explanation at the end of the mail, why we want to do this anyway. I'd like to figure out how to improve the resulting situation by getting the Wine changes to fontforge applied upstream (and/or in Debian). With "upstream" I mean github.com/fontforge. I will contact them in a later step. Wine and Debian are both using the quite old fontforge version 20120731-b, the patches apply cleanly in Debian. But upstream is actively developing and in Debian someone is working on packaging a recent version (not sure with what outcome, e.g. afaik there is at least one upstream regression blocking an update). Are there any plans in Wine to update to a newer version? Wine's fontforge has 4 changes. I recreated them based on AJ's merge for 20120731-b and by myself for 20160404 to get a *rough* picture of their current state (not tested and I'm absolutely no expert in this): 1. Various hacks to avoid putting timestamps in generated files (AJ). No relevant changes upstream, but there is some work going to allow one to specify the timestamp in order to get the build deterministic/reproducible. Would this make this patch obsolete? I don't know why upstream wants timestamps at all, nor what problems these cause for Wine. Is this Wine specific, or would it make sense to drop timestamping upstream, too? 2. - Avoid outputting trailing spaces in sfd files (AJ). About a third seems to be applied in 20160404. I assume the rest would still be relevant if Wine updated its fontforge version. Is this patch only relevant for creating fonts/glyphs, but not for building the TrueType fonts? Looks like a good candidate for forwarding to upstream. 3. Enable the width of individual bitmap strikes to be altered (Huw Davies). Since the import of upstream version 20120731-b this patch only has a third of its original size. Are the remaining Wine changes still necessary, or are they cruft? If still needed, I guess they should be pushed upstream. In 20160404 not much seems to have changed, but the containing file bitmapview.c was moved ("splitting ui code from fontforge/ to fontforgeexe/"). Same as above: is this only needed when creating fonts? Looks like a candidate for upstream. 4. Don't save the selected state. (Huw Davies) I found no relevant changes upstream. No idea about this. Why are we doing this? ---------------------- The Debian Free Software Guidelines [DFSG] (which are the fundamental basis for the Debian project) mandate that binaries must be accompanied by their source (which is usually ensured by building from source), and that you must be able to modify and redistribute the package with only the software available in Debian. The reasons for these are e.g. philosophical (empowering the user), QA (rebuilding if there was an issue in the build tools), reproducibility (recreate byte-by-byte-identically, e.g. to rule out attacks at a build machine or do QA) or security (a build from correct source code may be manipulated by specific compilers). The TrueType fonts are pre-built with a forked fontforge, which isn't (and very unlikely will ever be) in Debian. To package the pre-built fonts imo we would have to remove Wine from official Debian (main), and move it to the non/semi-official contrib section. For the same reason (AFAIK, I'm not the author of these changes) we're also regenerating opengl files, request code and unicode. This problem was ignored/missed in the past for the Debian Wine packages, yet this is no argument against fixing them now. We definitely don't want Wine removed from Debian, instead keep it in and get it there as good as possible. btw, we're also adding a patch (based on wine staging) to append '(Debian)' to the version string now. btw2, can you recommend some alternative free fonts to install (either as partial replacement or as extension to the Wine fonts)? Greets, and thanks in advance jre [DFSG] https://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg, see also the following chapter "The main archive area".

2 3

Re: [2/3] wininet: Start the first chunk as soon as we have some data.
by Jacek Caban 01 Aug '16

01 Aug '16

Hi Hans, On 19.07.2016 11:27, Hans Leidekker wrote: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/wininet/http.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 2c62d97..c4cf66b 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -2921,6 +2921,7 @@ static DWORD set_content_length(http_request_t *request) > !strcmpiW(encoding, szChunked)) > { > chunked_stream_t *chunked_stream; > + DWORD res; > > chunked_stream = heap_alloc(sizeof(*chunked_stream)); > if(!chunked_stream) > @@ -2935,6 +2936,12 @@ static DWORD set_content_length(http_request_t *request) > memcpy(chunked_stream->buf, request->read_buf+request->read_pos, request->read_size); > chunked_stream->buf_size = request->read_size; > request->read_size = request->read_pos = 0; > + > + res = start_next_chunk(chunked_stream, request); > + if (res != ERROR_SUCCESS) { > + heap_free(chunked_stream); > + return res; > + } It seems to me that you're fixing a problem is a wrong place. start_next_chunk should be called by HTTP_ReceiveRequestData via refill_read_buffer anyway. I'd suggest to investigate why it doesn't work in your case. Also, see the attached test. We shouldn't need any chunk to complete requests. It's an existing problem in current Wine, which may be unrelated to your problem, but having such blocking calls here is not a step in the right direction. Thanks, Jacek

2 2