October 2014 - Wine-Devel - list.winehq.org

Re: wined3d: Correctly display fog for right-handed projection matrix (try 6)
by Marvin Oct. 10, 2014

Oct. 10, 2014

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=9439 Your paranoid android. === w8 (32 bit visual) === visual.c:2716: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 6/6] wined3d: Don't replicate shader limits values for each shader.
by Henri Verbeet Oct. 10, 2014

Oct. 10, 2014

On 9 October 2014 18:01, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static const struct wined3d_shader_limits vs_limits[] = This doesn't really need to be global. It's not even that I mind that much for this kind of static const array, but it actually makes things easier to keep it local to shader_set_limits(). > struct wined3d_shader_limits > { > + unsigned int min_version; > + unsigned int max_version; > unsigned int sampler; > unsigned int constant_int; > unsigned int constant_float; You don't need that to be part of wined3d_shader_limits.

1 0

Re: [PATCH 5/6] d3d9/tests: Port the unsupported shaders test to D3D9Ex.
by Henri Verbeet Oct. 10, 2014

Oct. 10, 2014

On 9 October 2014 18:00, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void test_unsupported_shaders(void) In principle I like this better than "test_wrong_shader()", but could you then please update the d3d8 and d3d9 tests as well? It's a lot easier to find equivalent tests between D3D versions if they at least have the same name.

1 0

Re: [PATCH 1/2] d3d8/tests: Don't check the foreground window if we're not in foreground.
by Francois Gouget Oct. 10, 2014

Oct. 10, 2014

On Wed, 8 Oct 2014, Stefan Dösinger wrote: [...] > There are many more failures in d3d8:device when the test is not in > foreground. Those failures write static lines and I'd prefer the testbot > to be changed to run them in foreground instead. What do you mean by that? The TestBot runs a command line tool in an iconized console. In turn that tool runs the test binary. However I'm not aware of it preventing test windows from being in the foreground. Maybe the console windows being iconized somehow gets inherited by the windows created by the test binary, but shouldn't the test just request to bring its windows to the foreground? -- Francois Gouget <fgouget(a)codeweavers.com>

3 2

Re: [3/3] msvcrt: Added _fflush_nolock() implementation
by Piotr Caban Oct. 10, 2014

Oct. 10, 2014

On 10/09/14 19:52, Iván Matellanes wrote: > @@ -921,22 +921,36 @@ int CDECL MSVCRT_fflush(MSVCRT_FILE* file) > { > if(!file) { > msvcrt_flush_all_buffers(MSVCRT__IOWRT); > + } else if(file->_flag & MSVCRT__IOWRT || file->_flag & MSVCRT__IOREAD) { > + int ret; > + > + MSVCRT__lock_file(file); > + ret = MSVCRT__fflush_nolock(file); > + MSVCRT__unlock_file(file); > + > + return ret; > + } > + return 0; > +} file->_flag should be checked inside the lock (it's already done inside fflush_nolock). Could you please change the code to something like this: if(!file) msvcrt_flush_all_buffers(MSVCRT__IOWRT); MSVCRT__lock_file(file); ret = MSVCRT__fflush_nolock(file); MSVCRT__unlock_file(file); Thanks, Piotr

1 0

Re: kernel32: fix incorrect lastpart in GetFullPathNameA with DBCS
by Dmitry Timoshkov Oct. 10, 2014

Oct. 10, 2014

Aric Stewart <aric(a)codeweavers.com> wrote: > --- a/dlls/kernel32/path.c > +++ b/dlls/kernel32/path.c > @@ -271,7 +271,8 @@ DWORD WINAPI GetFullPathNameA( LPCSTR name, DWORD len, LPSTR buffer, > > if (*p != '\\') > { > - while ((p > buffer + 2) && (*p != '\\')) p--; > + while ((p > buffer + 2) && > + ((*p != '\\') || IsDBCSLeadByte(*(p-1)))) p--; This probably should depend on whether ansi or oem code page is active. -- Dmitry.

1 0

Re: [PATCH 1/2] d3d8/tests: Don't check the foreground window if we're not in foreground.
by Henri Verbeet Oct. 9, 2014

Oct. 9, 2014

On 8 October 2014 14:37, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > These two patches fix test failures when the process is not in > foreground that print changing error lines. This avoids generating > warnings from the testbot whenever d3d8/tests/device.c is touched. > > There are many more failures in d3d8:device when the test is not in > foreground. Those failures write static lines and I'd prefer the testbot > to be changed to run them in foreground instead. Why does this affect d3d8, but not d3d9?

2 1

Re: [PATCH 7/7] mshtml: Added script element readyState and onreadystatechange tests.
by Marvin Oct. 9, 2014

Oct. 9, 2014

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=9400 Your paranoid android. === w7u (32 bit script) === script.c:632: Test failed: L"elem.readyState = loading" === w8 (32 bit script) === script.c:632: Test failed: L"elem.readyState = loading" script.c:632: Test failed: L"extern_res_script_rs = loaded0,eval,complete1, expected eval,complete1,"

1 0

Re: [PATCH 1/3] kernel32: Support UTF-7 in MultiByteToWideChar. (try 2)
by Alexandre Julliard Oct. 9, 2014

Oct. 9, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Sorry, I noticed a couple of errors in the utf7_mbstowcs and > utf7_wcstombs documentation. They are now corrected. You still haven't addressed the issues I mentioned last time around. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: msvcr90: Prefer native dll if manifest is not present
by Nikolay Sivov Oct. 8, 2014

Oct. 8, 2014

> +#if _MSVCR_VER == 90 > + static const WCHAR msvcr90W[] = {'m','s','v','c','r','9','0','.','d','l','l',0}; > + ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) }; > + > + if(FindActCtxSectionStringW(FIND_ACTCTX_SECTION_KEY_RETURN_HACTCTX, NULL, > + ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION, msvcr90W, &askd)) { > + ReleaseActCtx(askd.hActCtx); > + return TRUE; > + } > + > + return FALSE; > +#endif It looks like you won't be using context handle anyway, so you can just set flags to zero, and return FindActCtxSectionStringW() value immediately.

2 1

Re: [PATCH 1/2] d3d8/tests: Don't check the foreground window if we're not in foreground.
by Marvin Oct. 8, 2014

Oct. 8, 2014

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=9361 Your paranoid android. === w8 (32 bit device) === device.c:3043: Test failed: Expected wndproc 0x412d00, got 0x412d00.

1 0

Re: msvcr90: Prefer native dll if manifest is not present
by Stefan Dösinger Oct. 8, 2014

Oct. 8, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-08 16:35, schrieb Piotr Caban: > DVDFab 9.x is distributed with custom version of msvcr90.dll that > is not compatible with normal dll. I think this comment should go into the code because Alexandre removes it from the commit log. It will be hard to find out the reason for this code without it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUNU0oAAoJEN0/YqbEcdMwalAP/2PgH8yjUYkTImTuMCeFj0+z ZBNVOkDz6+1/qeWZvA7YdnkZ8GqBaAZ48KBTgMMFyjUjiot2Ee2SbfyEJfHGBNE3 PBBaLzWIoxxkSDzkVK4A5XTDqx3gAueiTX79dS3cYd1R2Zb+rnFSkDkxSv0S03Q0 xY/ig2KDcYnm5BXfPcrV9PKTsBzLrJ+73t+4uBh3cKY623V8umZObyjq9yYNdwFn lSH3fIhUM60U6r4xMOw4YkiI7GJ5otlf7ORAA6zh+4N0oKwkcPiC6NJ3a/HLW6xG dyw9fQ3183puDWE+3Fi0ufHSTcbp6evMqY4WhOWwNYRNTjQdMcIY23S6rATGfqS9 TieSwABJ4L3quQ0zjmw920x4rTh7/XAMC3gEpXjlFF23LniHDnQtKjwckHk5a2vh qqDQ7+y7bywb6CDGUJCo/Mp6mT5Mt4qcL3/CZtuCsLM5FLYgvAXaGw3IYTCCxAnF F198/g1En1zjdbJmvDWAda4YAD9ffdmkWrppW0Oq7p8klyd35OktJ4LS6ULqb2jo K90+Ss+5N55rmhfGqPRgWifu+gRK3bdO08YpKkhhGyv6J+5DFyyB7uBqbSnjMNbR 25M2aPGvH4jB9vDD9DVSkt4q35FDmHVRYThW+3L3W92q0WatHhyWwoMTY6f+rvGj ftkB6MWECB/XTl1QxMQW =qeov -----END PGP SIGNATURE-----

1 0

Wine 1.7.28 source code
by Игорь Чебаненко Oct. 8, 2014

Oct. 8, 2014

Hello,I scanned Wine 1.7.28 source code with cppcheck 1.63. I hope my scanning will get attention. Threre's lots of false-positives,but,I think,in my file you will see interesting things. P.S Thank you for Wine. It is very interesting,and important open source project.

3 2

Re: kernel32: add a stub for GetSystemFileCacheSize (2/2)
by Alistair Leslie-Hughes Oct. 8, 2014

Oct. 8, 2014

On 08/10/14 06:37, Austin English wrote: > > @·stub·SetSystemFileCacheSize > +@·stdcall·SetSystemFileCacheSize(long·long·long)·kernel32.SetSystemFileCacheSize > This patch doesn't match the subject. Best Regards Alistair Leslie-Hughes

2 1

Re: [PATCH] mscoree: Use E_NOT_SUFFICIENT_BUFFER definition
by Marvin Oct. 8, 2014

Oct. 8, 2014

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=9344 Your paranoid android. === wxppro (32 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === wvistau64 (32 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === w2008s64 (32 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === w7u (32 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === w8 (32 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === wvistau64 (64 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f === w2008s64 (64 bit mscoree) === mscoree.c:343: Test failed: CreateConfigStream returned 8007007f

2 1

Re: wined3d: Correctly display fog for right-handed projection matrix (try 5)
by Stefan Dösinger Oct. 7, 2014

Oct. 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2014-10-04 00:24, schrieb Joachim Priesner: > + static const D3DMATRIX proj_mat_rh = > + {{{ > + 0.828732f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.104976f, 0.0f, 0.0f, > + 0.0f, 0.0f, -1.0001f, -1.0f, > + 0.0f, 0.0f, -0.010001f, 0.0f > + }}}; > ... > + static const D3DMATRIX view_mat_rh = > + {{{ > + 1.0f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.0f, 0.0f, 0.0f, > + 0.0f, 0.0f, -0.1f, 0.0f, > + 0.0f, 0.0f, 0.0f, 1.0f > + }}}; I'm sorry that this reply is a bit late, but I've been wondering if you need the complicated projection matrix to show the abs() in the vertex pipeline. If I understand it correctly, a view and projection matrix like this should do the job as well with the same input coordinates: static const D3DMATRIX proj_mat = {{{ 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f }}}; static const D3DMATRIX view_mat = {{{ 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, -0.1f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f }}}; The test results with these matrices are identical, and the test correctly detects the defect in Wine. The test is much easier to follow. Am I missing something? As an added bonus you could replace the 10.0f in the input vertices with 1.0 and the -0.1f in the view matrix with -1.0f. Some other suggestions: > +/* Some color constants to make tests easier to read. */ > +#define COLOR_FOG 0xff00ff00 > +#define COLOR_FOGGED 0x0000ff00 > +#define COLOR_UNFOGGED 0x00ff0000 > +#define COLOR_CLEAR 0xffff00ff IMHO it would be nicer to either use an enum in the scope of fog_righthanded_test (preferred) or #undef them after the function. > + static struct > + { > + struct vec3 position; > + DWORD diffuse; > + } > + quad[] = > + { > + {{-1.0f, -1.0f, 10.0f}, COLOR_UNFOGGED}, > + {{-1.0f, 1.0f, 10.0f}, COLOR_UNFOGGED}, > + {{ 1.0f, -1.0f, 10.0f}, COLOR_UNFOGGED}, > + {{ 1.0f, 1.0f, 10.0f}, COLOR_UNFOGGED}, > + }; Always drawing a gradient would be better. That avoids other fog setup problems that lead to either always fogged or never fogged quads. Also, this can be static const in d3d8 and d3d9. > + hr = IDirect3DDevice8_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, COLOR_CLEAR, 1.0f, 0); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_Clear failed (%08x)\n", hr); Do you need the Z buffer? Just disable the depth test, no need to clear it. > + /* Basic vertex shader with fog computation ("foggy"). > + * Using the vertex' x coordinate as fog coordinate so that all test cases that use vertex fog > + * will have a gradient from fully fogged (green, left) to unfogged (red, right). */ > + static const DWORD vertex_shader_code2[] = > + { > + 0xfffe0100, /* vs_1_0 */ > ... > + 0x0000ffff, /* END */ > + }; > + > + /* Basic pixel shader */ Two indentation issues here. The comment needs one extra space, the closing bracket has one too many. I suspect your editor screwed this up when you copied the code from d3d9 to d3d8. > + if (caps.PixelShaderVersion >= D3DPS_VERSION(2, 0)) > + { > + hr = IDirect3DDevice9_CreateVertexShader(device, vertex_shader_code3, &vertex_shader[3]); > + ok(SUCCEEDED(hr), "CreateVertexShader failed (%08x)\n", hr); > + hr = IDirect3DDevice9_CreatePixelShader(device, pixel_shader_code2, &pixel_shader[2]); > + ok(SUCCEEDED(hr), "CreatePixelShader failed (%08x)\n", hr); > + } else { > + skip("No shader model 2 support, skipping some fog tests.\n"); > + } Curly bracket placement. This applies to a few other places. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUNGWtAAoJEN0/YqbEcdMw/+YQAIQxmRjeNMne0+f9AuCwtNVJ /MrhsXPnCFDWbYE6BTXM8/2CvlM5DzhCya2AQg8UFW4qMXQJmijTorCjDF0e7Vc7 RvuP4xJXsqhKDhyoYfSzcX8WYkJZcVow0tQIz++qKfjMbgqnGwoWocYdNgyymy9v pU6Q/shM1qv2PUkDNuMAJI7Tv09R5muYEyi9sfRa+grFGQwDJGQpgOXwP5oR2DWM wjlTIO7wMkXY0XGE5DInxE+slaF2gECrKrHRM+1HNicNq5hGOwYwdm/JcBA9qxGQ uv+w0WMKR0n4FPtJBHXcm3/qshUyBvzSsMSEilfBwOzrrclOx9ctNEuogqufEpF9 6yGuX0PEp+W9g9rN6rCMMBjYmGJdal2bY2F1KQ+iLAYHhMsahy+fibIGEwE7Yugg +ffx3RONm335mpZqQh5NrtHAwf3iLEEA7PQQawW5UKCoKANpV03KyZBFJLZ1lOC4 cEQLQQNo7p/M0211bm4dTN8SSYvucloDSuzwe+PqCNvyL8xJyJCiHMHuVX2cFdgt 7qPA13LdKze/7S4Jk1JjL31tTEdMCGZJSekkTEAJ7C/c01L3DiDVywn9VNVXdPsR 8oW8pfZI0t1g2/Miq08mP1T+IWTftYOQaHyiYrQ73hu8PtDgY3C92JHwV4SmvPUI UxItWlY/H/8FLJG5v5dt =dUDt -----END PGP SIGNATURE-----

1 0

Re: server: KeyNameInformation returns the full name of the key. (try 2)
by Alexandre Julliard Oct. 7, 2014

Oct. 7, 2014

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 2: > - Use `for' loops instead of `while' loops in get_key_full_name function. > - Introduce full_name variable to avoid tricky free() condition check at > end of enum_key function. You should be able to do this without allocating memory. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] d3d8/tests: Introduce a create_device_pp function for custom present parameters.
by Marvin Oct. 7, 2014

Oct. 7, 2014

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=9329 Your paranoid android. === w8 (32 bit device) === device.c:2401: Test failed: Expected foreground window 000B00F8, got 0002004C. device.c:3043: Test failed: Expected wndproc 0x412bd0, got 0x412bd0.

1 0

Re: ntdll: Introduce new function wine_server_set_reply_user for user provided pointers.
by Alexandre Julliard Oct. 7, 2014

Oct. 7, 2014

Sebastian Lackner <sebastian(a)fds-team.de> writes: > This patch is an alternative strategy for fixing the issue described > in http://source.winehq.org/patches/data/106864. Please note that the > patches 2-4 from the previous series are still valid, and can be > applied independently. > > Although Andre_H and ehoover told me that this solution will not be > accepted, I'll give it a try, because its the cleanest approach I can > think of. > > There is a huge amount of wineserver calls that use > wine_server_set_reply incorrectly, and manually adding code to all > these functions seems very complicated. In ntdll we have to use > virtual_check_buffer_for_write, everywhere else we have to use > IsBadWritePtr. And even if we have added that, it could still break > things: When we add the check at the top of each affected function, > and return some general error codes, it could break apps which expect > a page fault exception in some other code branch. There are few places that need this, and even fewer where it's an actual problem in practice. In fact it wouldn't be a problem at all except for your writecopy hack, which is in itself a questionable change. You'll need more convincing arguments for this series. -- Alexandre Julliard julliard(a)winehq.org

1 0

wine crashed on exiting inside gdiplus.
by Hin-Tak Leung Oct. 6, 2014

Oct. 6, 2014

It is probably not important, just in case it is something easily fixable, I just got a crash on exit inside gdiplus. $ git describe wine-1.7.28 the backtrace is: Backtrace: =>0 0x7dcfed37 ipicture_pixel_width+0x7(pic=0xfeeefeee) [/home/Nobak-Hin-Tak/tmp-git/wine/dlls/gdiplus/../../include/ocidl.h:1221] in gdiplus (0x00e7e428) 1 0x7dd0b61b GdipGetImageBounds+0x15a(image=0x4eb5d40, srcRect=0xe7e548, srcUnit=0xe7e4c4) [/home/Nobak-Hin-Tak/tmp-git/wine/dlls/gdiplus/image.c:2182] in gdiplus (0x00e7e488) 2 0x7dce6f9e get_graphics_bounds+0x17d(graphics=<is not available>, rect=<is not available>) [/home/Nobak-Hin-Tak/tmp-git/wine/dlls/gdiplus/graphics.c:1999] in gdiplus (0x00e7e508) 3 0x7dcf2065 GdipGetDC+0xe4(graphics=<is not available>, hdc=<is not available>) [/home/Nobak-Hin-Tak/tmp-git/wine/dlls/gdiplus/graphics.c:5719] in gdiplus (0x00e7e598) 4 0x00bad6c0 (0x00e7e5e8) 5 0x00bad65c (0x00e7e608) ... ... 0x7dcfed37 ipicture_pixel_width+0x7 [/home/Nobak-Hin-Tak/tmp-git/wine/dlls/gdiplus/../../include/ocidl.h:1221] in gdiplus: movl 0x0(%eax),%edx 1221 return This->lpVtbl->get_Width(This,pWidth);

1 0

Re: po: Update German translation.
by Joachim Priesner Oct. 6, 2014

Oct. 6, 2014

> #: jscript.rc:40 > > -#, fuzzy > -#| msgid "Subject Key Identifier" > > msgid "Expected identifier" > > -msgstr "SchlÃ¼sselkennung des Antragstellers" > +msgstr "Erwarteter Bezeichner" This should probably read "Bezeichner erwartet". Best Joachim

1 0

Re: [PATCH 7/7] user32/tests: Test WM_SYSCOMMAND(SC_MINIMIZE) on an unminimizable window.
by Marvin Oct. 6, 2014

Oct. 6, 2014

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=9283 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 6: the msg 0x0046 was expected, but got msg 0x0088 instead msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 7: the msg 0x0083 was expected, but got msg 0x0046 instead msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 10: the msg 0x0047 was expected, but got msg 0x0083 instead msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 11: the msg 0x0003 was expected, but got msg 0x0085 instead msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 12: the msg 0x0005 was expected, but got msg 0x000d instead msg.c:4466: Test failed: SendMessage( WM_SYSCOMMAND, SC_MINIMIZE ):popup, unminimizable: 14: the msg sequence is not complete: expected 0000 - actual 0047 === w7u (32 bit msg) === msg.c:12187: Test failed: unexpected hwnd 00080150 msg.c:12209: Test failed: bad time 30ba3/30bb3

2 1

Re: [1/4] ntdll: Trigger write watches before passing userdata pointer to wait_reply.
by Alexandre Julliard Oct. 6, 2014

Oct. 6, 2014

Sebastian Lackner <sebastian(a)fds-team.de> writes: > The reply_data field sometimes points directly to user-provided > memory. That's not supposed to happen. Callers that do that should be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/7] wined3d: Restore the display mode on focus loss (v2).
by Henri Verbeet Oct. 6, 2014

Oct. 6, 2014

On 6 October 2014 13:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static BOOL wined3d_swapchain_mode_changed(const struct wined3d_swapchain *swapchain) > +{ > + return swapchain->desc.backbuffer_width != swapchain->original_mode.width > + || swapchain->desc.backbuffer_height != swapchain->original_mode.height > + || swapchain->desc.backbuffer_format != swapchain->original_mode.format_id > + || swapchain->desc.refresh_rate != swapchain->original_mode.refresh_rate; > +} > + > void wined3d_swapchain_activate(struct wined3d_swapchain *swapchain, BOOL activate) > { > if (!activate) > + { > + if (wined3d_swapchain_mode_changed(swapchain)) > + { > + if (FAILED(wined3d_set_adapter_display_mode(swapchain->device->wined3d, > + swapchain->device->adapter->ordinal, &swapchain->original_mode))) > + ERR("Failed to set display mode.\n"); > + > + swapchain->reapply_mode = TRUE; This seems to imply that if an application created a fullscreen swapchain at the current display resolution, but then some external mode change happened, we should keep the mode from the external mode change on focus loss, but then change it on reset. That may be correct, but it's certainly more complicated than just resetting the original mode on focus loss, and I don't see tests. As a follow up, it would perhaps also be interesting to verify that in some of the places where we're currently using "original_mode", we really shouldn't be using EnumDisplaySettings() with ENUM_REGISTRY_SETTINGS instead.

2 2

Re: [PATCH 6/7] user32/tests: Test minimizing an unminimizable window. (v2)
by Marvin Oct. 6, 2014

Oct. 6, 2014

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=9282 Your paranoid android. === w7u (32 bit msg) === msg.c:12150: Test failed: unexpected hwnd 0011013C msg.c:12172: Test failed: bad time 31592/315a2

1 0