- wine-devel - winehq.org

Re: Add WWN 377
by Rico Schüller 11 Oct '14

11 Oct '14

On 10.10.2014 21:48, André Hentschel wrote: > diff --git a/news/de/2014101001.xml b/news/de/2014101001.xml > new file mode 100644 > index 0000000..8ad495c > --- /dev/null > +++ b/news/de/2014101001.xml > @@ -0,0 +1,11 @@ > +<news> > + <date>10. Oktober 2014</date> > + <title>World Wine News Ausgabe 377</title> > + <body> > +<a href="{$root}/wwn/377">WWN Ausgabe 377 (en)</a> wurde heute verÃ¶ffentlicht. > +<ul> > +<li><a href="{$root}/wwn/377#Idea for a Wine staging tree">Idea fÃ¼r einen Wine Staging Tree</a></li> <li><a href="{$root}/wwn/377#Idea for a Wine staging tree">Idee ... Cheers Rico

1 0

Re: [PATCH] mshtml/tests: Fix typo.
by Marvin 11 Oct '14

11 Oct '14

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=9465 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

2 1

Re: wined3d: Correctly display fog for right-handed projection matrix (try 6)
by Stefan Dösinger 10 Oct '14

10 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I missed a few things the last time. This list is exhaustive now, at least as far as I'm concerned. I have listed most things for d3d8, but they apply to the d3d9 test as well. Am 2014-10-10 15:21, schrieb Joachim Priesner: > + 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 > + }}}; Minor detail: you left a redundant - in here. (4th row, third column, -0.0f) > + /* 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). */ This is a bit off-topic, but I'm still noting it here: We don't have any tests for the clamp(0.0, 1.0) we do on the oFog output. Hence it may be interesting to check the middle of the screen in case of the foggy shader. If it is half fogged, the clamp is correct. If it is fully fogged the clamp is wrong (keep in mind that "foggy shaders" have reverse fog with start = 1, end = 0). This shouldn't be part of this patch, but it is an idea for a follow-up test if you or anyone else is interested. > + {0, 0, D3DFOG_NONE, D3DFOG_LINEAR, COLOR_UNFOGGED, COLOR_FOGGED}, > + {0, 1, D3DFOG_NONE, D3DFOG_LINEAR, COLOR_UNFOGGED, COLOR_FOGGED}, > + {0, 0, D3DFOG_LINEAR, D3DFOG_LINEAR, COLOR_UNFOGGED, COLOR_FOGGED}, > + {0, 1, D3DFOG_LINEAR, D3DFOG_LINEAR, COLOR_UNFOGGED, COLOR_FOGGED}, > + {0, 0, D3DFOG_LINEAR, D3DFOG_NONE, COLOR_UNFOGGED, COLOR_FOGGED}, > + {0, 1, D3DFOG_LINEAR, D3DFOG_NONE, COLOR_UNFOGGED, COLOR_FOGGED}, Please add a D3DFOG_NONE, D3DFOG_NONE case for completeness. In case of the shaders I expect the same result as with table fog = NONE, vertex fog = LINEAR. In case of fixed function fragment processing I expect fully fogged because it uses the alpha component of the specular color, which defaults to 0. Fogstart = 255 and fogend = 0 in that case, similar to the vertex shader oFog case. > + /* Note: Shaders expect matrices in column-major form, so they have > + * to be transposed if they are not symmetrical (which is the case at the moment). */ > + hr = IDirect3DDevice8_SetVertexShaderConstant(device, 0, &view_mat, 4); > + ok(SUCCEEDED(hr), "SetVertexShaderConstant (view matrix) failed (%08x)\n", hr); > + hr = IDirect3DDevice8_SetVertexShaderConstant(device, 4, &proj_mat, 4); > + ok(SUCCEEDED(hr), "SetVertexShaderConstant (projection matrix) failed (%08x)\n", hr); I'd expect these calls to fail on hardware that does not support shaders. Same for the Set*Shader(NULL) calls later on. Technically you do not need the matrix multiply inside the shader with the new matrices, but if you want to keep them in to make the fixed function and shader codepaths more similar that's OK with me. The D3DPRASTERCAPS_FOGTABLE capability applies to d3d8/9 as well. I don't know if there's any GPU out there that doesn't support table fog other than my ancient ATI 3D Rage. > + IDirect3DDevice8_Present(device, NULL, NULL, NULL, NULL); You are not checking the return value here. > + if (caps.PixelShaderVersion >= D3DPS_VERSION(1, 1)) > + { > + hr = IDirect3DDevice9_CreateVertexShader(device, vertex_shader_code1, &vertex_shader[1]); > + ok(SUCCEEDED(hr), "CreateVertexShader failed (%08x)\n", hr); > + hr = IDirect3DDevice9_CreateVertexShader(device, vertex_shader_code2, &vertex_shader[2]); > + ok(SUCCEEDED(hr), "CreateVertexShader failed (%08x)\n", hr); > ... > + } Please check the vertex shader version separately from the pixel shader one. > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 0385044..23542ff 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c New ddraw tests should go to dlls/ddraw/tests/ddraw*.c. I'm fine with just a ddraw7 test for this. The older ddraw interfaces have a different fog interface (D3DLIGHTSTATE_FOG*, and somehow there's a separate D3DRENDERSTATE_FOGTABLE*). While we could certainly use more tests for this interface it shouldn't be the concern of this patch. > + if (IDirect3DDevice7_BeginScene(device) == D3D_OK) This is not a big issue, but there's no need to have a code branch for BeginScene / EndScene, just let the draws in between fail like you do in d3d8/9. I have never seen a case where BeginScene fails unexpectedly. (Yeah, the existing code isn't consistent on this point.) > + hr = IDirect3DDevice8_SetRenderState(device, D3DRS_FOGEND, end.i); > + ok(SUCCEEDED(hr), "Setting fog end failed (%08x)\n", hr); > ... > + hr = IDirect3DDevice8_SetTransform(device, D3DTS_PROJECTION, &proj_mat); > + ok(SUCCEEDED(hr), "Failed to set projection transform, hr %#x.\n", hr); Another minor style issue: You're mixing %08x and %#x. The preferred one is %#x, but what mostly matters is consistency. Similar for punctuation at the end of the traces. SUCCEEDED(hr) is preferred over hr == D3D_OK. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUOFewAAoJEN0/YqbEcdMwxSYP/jFB5IT9a+7w8JQ7vlziVdGz KZccLwVFSyJqLhEiTIs7B0yz5rWhkjI6HPxzWRPRMVbNTjlUvsiZRLl8FU6hR86A 1G6azwEnMs0/u9LUOfdphBLdj454+E/NJMr1EzkRjL+PMt49RZwSxdCmxPXK/unx yrxLSPuxCjHGhN6K95/xV8fVkbJoa7va8IeKDHhfoFpdpaUqUqyGaSbNCfiyYj6l cyA8ZBlQEEEYBDg8HopQgw99MmfU3BIL4rY984YnsscYMckI5qjOs+joMcUwHscU Vaflkmh5udcj74sdgPguOwigJeLuLzY6zbWzhUGDFzdkXuwfuF0oe+ws/QcNOYX6 r2d/CGa7nYXfTFewR4SODJT+950P8CwuskLsslBAiPpy4uzVcbhKT2oNh7L7vhU1 +o6gYk98ceCaRdZxajf+j2hElg7N9AkWAK/RfLY25d3ALnKKVDbaidWKot3dVcHN nicK89v6jKSmD/FdbVM9/YUi4QzOZM5IJAItG0OuhS0oU/Bfkpr0e7NXvORxdGPC BpRvQrwIJXWiT43aqK8E1w67mE47PMmqoKjO3qVfWLojC0L7KPybDjGtUKj652Qr ixqPlaERPLeRVyAGtpxHlIE2opyx3fOSy/ZSTq6/PzK4GNZ/hgfTLbUff2ixxa+M cL3+mTtlQSBx9yt9BmUG =ZDPP -----END PGP SIGNATURE-----

1 0

Re: kernel32: fix incorrect lastpart in GetFullPathNameA with DBCS
by Akihiro Sagawa 10 Oct '14

10 Oct '14

On Thu, 09 Oct 2014 12:03:15 -0500, Aric Stewart wrote: > --- > dlls/kernel32/path.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Hi Aric, Thank you for pointing this out, but unfortunately this seems not to be perfect. Because certain DBCS trail byte range is overlapped its lead byte range [1]. To demonstrate this issue, I attached additional test. The first case (0x955c,0x97a0=表裏) is now pass by your patch, but the second one (0x838f,0x8343,0x8393=ワイン) is failure. In my opinion, the solution is looking up the path separator from the beginning of the string like _mbsrchr() in msvcrt. If you have a further question about this, please contact me. [1] For CP 932 (Japanese Shift JIS), Double byte character: Lead byte (first byte): 0x81-0x9f or 0xe0-0xfc, and Trail byte (second byte): 0x40-0x7e or 0x80-0xfc. Single byte character: 0x00-0x7f, 0xa1-0xdf. Regards, Akihiro Sagawa

2 1

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

10 Oct '14

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 10 Oct '14

10 Oct '14

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 10 Oct '14

10 Oct '14

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 10 Oct '14

10 Oct '14

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 10 Oct '14

10 Oct '14

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 10 Oct '14

10 Oct '14

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 09 Oct '14

09 Oct '14

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 09 Oct '14

09 Oct '14

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 09 Oct '14

09 Oct '14

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 08 Oct '14

08 Oct '14

> +#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 08 Oct '14

08 Oct '14

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 08 Oct '14

08 Oct '14

-----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 Игорь Чебаненко 08 Oct '14

08 Oct '14

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 08 Oct '14

08 Oct '14

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 08 Oct '14

08 Oct '14

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 07 Oct '14

07 Oct '14

-----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 07 Oct '14

07 Oct '14

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 07 Oct '14

07 Oct '14

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 07 Oct '14

07 Oct '14

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 06 Oct '14

06 Oct '14

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 06 Oct '14

06 Oct '14

> #: 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 06 Oct '14

06 Oct '14

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 06 Oct '14

06 Oct '14

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 06 Oct '14

06 Oct '14

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 06 Oct '14

06 Oct '14

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

Re: [PATCH 3/7] d3d9/tests: Test messages on focus loss (v3).
by Henri Verbeet 06 Oct '14

06 Oct '14

On 6 October 2014 13:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - device = create_device(d3d9, device_window, focus_window, FALSE); > - if (!device) > + present_parameters.Windowed = FALSE; > + present_parameters.hDeviceWindow = device_window; > + present_parameters.SwapEffect = D3DSWAPEFFECT_DISCARD; > + present_parameters.BackBufferWidth = 640; > + present_parameters.BackBufferHeight = 480; > + present_parameters.BackBufferFormat = D3DFMT_A8R8G8B8; > + if (FAILED(IDirect3D9_CreateDevice(d3d9, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, focus_window, > + D3DCREATE_SOFTWARE_VERTEXPROCESSING, &present_parameters, &device))) We're just hoping the display resolution isn't already 640x480 here, right? I'd also rather see this using create_device(). Or perhaps some variant like create_device_pp() taking a D3DPRESENT_PARAMETERS structure, although it seems to me that the issue you're running into is just that screen_width and screen_height aren't very good choices for the backbuffer dimensions in the general case.

2 1

Re: [PATCH 5/7] d3d8/tests: Test messages on focus loss (v3).
by Marvin 06 Oct '14

06 Oct '14

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=9281 Your paranoid android. === w8 (32 bit device) === device.c:2489: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3131: Test failed: Expected wndproc 0x413080, got 0x413080.

1 0

Re: [PATCH 4/7] d3d9/tests: Port test_wndproc to d3d9ex (v2).
by Henri Verbeet 06 Oct '14

06 Oct '14

On 6 October 2014 13:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + ret = pEnumDisplaySettingsExA(NULL, ENUM_CURRENT_SETTINGS, &orig_mode, 0); Why the Ex versions here? > + user32_handle = GetModuleHandleA("user32.dll"); > + pEnumDisplaySettingsExA = (void*)GetProcAddress(user32_handle, "EnumDisplaySettingsExA"); > + pChangeDisplaySettingsExA = (void*)GetProcAddress(user32_handle, "ChangeDisplaySettingsExA"); I also suspect we don't need to get these through GetProcAddress() on any setup where we still run the tests.

1 0

Wine staging tree
by Michael Müller 06 Oct '14

06 Oct '14

Hi, since I already revealed our staging tree idea in a mail which I accidentally send to wine-devel, I think it is time to explain the whole idea. Before you start complaining, please carefully read the whole mail, and especially note that we're in no way trying to compete with vanilla Wine (which seems to be the main counter-argument I've heard so far). Wine is a huge project and it is easy to introduce new regressions or to have mistakes in your patches. For this reason all patches need to be accepted by AJ to keep a good code quality. Nevertheless it is not unusual that patches drop out of the list because they don't get any attention or contributors get frustrated because sending try XX is a slow process of gaining feedback. Just to be clear: I think its absolutely essential that Wine has a stable and very well tested code base, so I'm _not_ suggesting to change the submission rules. Nevertheless its sometimes impossible to test a patch, without having some user feedback. Besides that, there is a huge gap between Wine user perspective and Wine developer perspective: Users sometimes would prefer to use an early beta version of a patch (which might not be the perfect solution, but the application at least works), whereas developers prefer a well-tested and 100% correct solution. For this reason we converted wine-compholio (which was previously used to provide patches for Silverlight / Pipelight) to some kind of staging tree. We add patches there which may not be yet be completely ready for wine-patches, for example some features are not fully implemented yet or need additional testing. This makes it possible for other developers to take a look at them before they reach wine-patches and they can give you feedback and point out possible mistakes. This is especially suited for new contributors. Just think about all the GSoC students, which spend months to implement new features, and at the end the code is lost and not really maintained anymore, because it wasn't in a perfect shape yet to go upstream. That shouldn't happen at my opinion. Besides the possibility of getting feedback, your patches will also be tested by regular users to reveal regressions. We follow the same release cycle as Wine (with usually 1 days offset) and provide prebuilt packages for: Ubuntu, Arch Linux, Debian, OpenSUSE, Fedora, Mageia 4 and there are also 3rd party builds for other distributions like Slackware. Fedora directly integrates our patches into their wine package. Some users also prefer wine-compholio since they get patches for their software earlier, and developers have the advantage to know about regressions faster. Although being a staging tree, we don't want to break too much stuff for our users and therefore do not accept any hacks like PlayOnLinux. If there is a highly demanded application with a known workaround, we may consider making an exception - but we _definitely_ don't want to end up like PlayOnLinux ;-). We always try to find a compromise between the user and the developers perspective. However, If you introduce regressions and don't fix them till the next release we may consider dropping the patches again. Since our aim is to get patches upstream, our repo does not contain the whole wine source code but only patches to make this task easy. We also use a sophisticated patch system which creates a Makefile that automatically figures out dependencies between patchsets and prevents adding patches that do not apply, but explaining all that would be too much for this mail ;-). If you think this might be a great idea and/or you want to make use of it, you can find all required information at: https://github.com/compholio/wine-compholio https://github.com/compholio/wine-compholio/blob/master/DEVELOPER.md We also try to improve existing patches from bugs or patches which did not get upstream, so don't be surprised if you find one your patches in our repo. ;-) There is currently no mailing list for suggesting patches (as mentioned at the beginning our original plan was to wait a bit more, before officially announcing this idea), but you can either talk to us in #wine-compholio on FreeNode or open a bug report on github to propose patches. We neither want to prevent anybody from sending their patches upstream, nor to be a competitor to Wine, we just want to give some optional extra help for both developers and users. Instead of having lots of private developer work-in-progress branches, this makes it possible to create a combined version, and users get an easy way to test fixes without compiling wine on their own (for example if you have a fix for a bug and want other people to verify whether it solves the problem for them). Regards, Michael

9 13

Re: msvcrt: Added _fclose_nolock() implementation.
by Piotr Caban 06 Oct '14

06 Oct '14

On 10/04/14 18:53, Iván Matellanes wrote: > Added _fclose_nolock() implementation. Could you please also change _fclose implementation so it calls _fclose_nolock internally? This will avoid some code duplication. Thanks, Piotr

1 0

Re: [PATCH 2/2] gameux: Use CLSIDFromString() instead of shell32 equivalent
by Marvin 06 Oct '14

06 Oct '14

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=9268 Your paranoid android. === w8 (32 bit gameexplorer) === No test summary line found

1 0

[PATCH] dbghelp: implement DW_TAG_const_type in dwarf2_parse_udt_type
by David Heidelberger 05 Oct '14

05 Oct '14

Also solve spamming debug output with these messages: fixme:dbghelp_dwarf:dwarf2_parse_udt_type Unhandled Tag type 0x26 at ctx(0x33c42c,L"ourlib.so.0"), for debug_info(abbrev:0x1360224,symt:0x159ed70) Signed-off-by: David Heidelberger <david.heidelberger(a)ixit.cz> --- dlls/dbghelp/dwarf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c index e7c36b0..1f85f6b 100644 --- a/dlls/dbghelp/dwarf.c +++ b/dlls/dbghelp/dwarf.c @@ -1453,6 +1453,9 @@ static struct symt* dwarf2_parse_udt_type(dwarf2_parse_context_t* ctx, case DW_TAG_subprogram: dwarf2_parse_subprogram(ctx, child); break; + case DW_TAG_const_type: + dwarf2_parse_const_type(ctx, child); + break; case DW_TAG_structure_type: case DW_TAG_class_type: case DW_TAG_union_type: -- 2.1.1

1 0

Re: [PATCH] kernel32/nls: Added support for LOCALE_SOPENTYPELANGUAGETAG
by Alistair Leslie-Hughes 05 Oct '14

05 Oct '14

On 05/10/14 07:14, Nikolay Sivov wrote: > --- > > +WINBASEAPI·INT·········WINAPI·GetLocaleInfoEx(LPCWSTR,LCTYPE,LPWSTR,INT); > This looks like it doesn't belong to this patch. Best Regards Alistair Leslie-Hughes

2 1

Win10 winetest results
by André Hentschel 04 Oct '14

04 Oct '14

Hi, i tried winetest on a fresh win10 (technical preview) install... because of the error number i can't upload it to test.winehq.org for easier review... But here they are: http://wine.dawncrow.de/win10/res164F.tmp http://wine.dawncrow.de/win10/resB470.tmp

1 0

Re: [PATCH] ntdll: test also FullDirectoryInformation
by Marvin 04 Oct '14

04 Oct '14

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=9261 Your paranoid android. === w2000pro (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === wxppro (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === wvistau64 (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === w2008s64 (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === w7u (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === w8 (32 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === wvistau64 (64 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1 === w2008s64 (64 bit directory) === directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 1, single_entry 1 directory.c:251: Test failed: not enough data in directory (72 expected, 70 got, fnamelen 2), restart 0, single_entry 1

1 0

Re: wined3d: Correctly display fog for right-handed projection matrix (try 5)
by Marvin 04 Oct '14

04 Oct '14

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

2 1

Re: [PATCH 5/5] ws2_32: Return WSAEINVAL if "out_size" is smaller than the minimum size for SIO_ADDRESS_LIST_QUERY.
by Marvin 03 Oct '14

03 Oct '14

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=9245 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000

2 1

Re: [PATCH] jscript: Ignore BOM mark in next_token. (try 5)
by Nikolay Sivov 03 Oct '14

03 Oct '14

> static BOOL skip_spaces(parser_ctx_t *ctx) > { > - while(ctx->ptr < ctx->end && isspaceW(*ctx->ptr)) { > + while(ctx->ptr < ctx->end && (isspaceW(*ctx->ptr) || *ctx->ptr == 0xFEFF /* UTF16 BOM */)) { > if(is_endline(*ctx->ptr++)) > ctx->nl = TRUE; > } This looks correct according to ECMA-252 section 7.2 - all of the following is a whitespace: - tab and vertical tab, 0x9 and 0xb; - form feed 0xc - space 0x20 - NBSP 0xa0 - UTF-16 BOM 0xfeff - any other Unicode "space separator" Hopefully isspaceW() covers everything but the BOM. What worries me is that isspaceW() itself is used in numerous places in code on its own. So probably we need more tests to cover more cases where space separators could be used, and later have our own is_space() call that will conform to the standard.

3 5

Re: [PATCH] user32/tests: Test minimizing an unminimizable window. (v2)
by Marvin 02 Oct '14

02 Oct '14

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=9217 Your paranoid android. === w7u (32 bit msg) === msg.c:11961: Test failed: got message 102 msg.c:11966: Test failed: bad wparam 201a/2260 msg.c:11978: Test failed: bad wparam 201a/2260 msg.c:11985: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:11987: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:11994: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:11996: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12003: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12005: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12012: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12014: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12021: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12023: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12031: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12034: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12039: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12041: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12049: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12057: Test failed: bad wparam 201a/2260 msg.c:12061: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12069: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12071: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12073: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12082: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12085: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12087: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12093: Test failed: no messages: 0: the msg sequence is not complete: expected 0000 - actual 0102 msg.c:12095: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12097: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a msg.c:12102: Test failed: Unicode WM_CHAR: 0: in msg 0x0102 expecting wParam 0x2260 got 0x201a0081 msg.c:12111: Test failed: bad wparam 81/30fb msg.c:12118: Test failed: bad wparam 81/30fb msg.c:12129: Test failed: bad wparam 3f/81 msg.c:12131: Test failed: no message msg.c:12134: Test failed: bad wparam 3f/81 msg.c:12144: Test failed: bad wparam 3f/81 msg.c:12150: Test failed: unexpected hwnd 00060150 msg.c:12152: Test failed: bad wparam 81/81 msg.c:12161: Test failed: bad wparam 3f/81 msg.c:12168: Test failed: unexpected hwnd 00000000 msg.c:12170: Test failed: bad wparam 81/81 msg.c:12171: Test failed: bad lparam 0 msg.c:12183: Test failed: bad wparam 3f/81 msg.c:12188: Test failed: bad wparam 3f/81 msg.c:12190: Test failed: no message msg.c:12193: Test failed: bad wparam 3f/81 msg.c:12195: Test failed: no message msg.c:12198: Test failed: bad wparam 3f/81

1 0

Re: [2/3] shlwapi: Fix swapped argument order in SHMapHandle.
by Marvin 02 Oct '14

02 Oct '14

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=9214 Your paranoid android. === wvistau64 (32 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === w2008s64 (32 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === wvistau64 (64 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487 === w2008s64 (64 bit ordinal) === ordinal.c:548: Test failed: SHMapHandle failed: 6 ordinal.c:551: Test failed: SHLockShared failed: 87 ordinal.c:557: Test failed: SHUnlockShared failed: 487

1 0

Re: [1/3] shlwapi/tests: Add test for SHMapHandle.
by Marvin 02 Oct '14

02 Oct '14

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=9213 Your paranoid android. === wvistau64 (32 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === w2008s64 (32 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === wvistau64 (64 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487 === w2008s64 (64 bit ordinal) === ordinal.c:549: Test failed: SHMapHandle failed: 6 ordinal.c:553: Test failed: SHLockShared failed: 87 ordinal.c:560: Test failed: SHUnlockShared failed: 487

1 0

Re: [PATCH 3/3] jscript: Added support for relational CC expressions.
by Marvin 02 Oct '14

02 Oct '14

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=9211 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/3] jscript: Added support for '==' CC expression.
by Marvin 02 Oct '14

02 Oct '14

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=9210 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [2/2] kernel32/tests: Add tests for FindFirstFileExA with FIND_FIRST_EX_CASE_SENSITIVE flag.
by Marvin 02 Oct '14

02 Oct '14

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=9200 Your paranoid android. === wvistau64 (32 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [1/2] kernel32/tests: Add tests for FindFirstFileExA with FIND_FIRST_EX_LARGE_FETCH flag.
by Marvin 02 Oct '14

02 Oct '14

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=9199 Your paranoid android. === wvistau64 (32 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:367: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: Assorted spelling/grammar fixes
by Marvin 02 Oct '14

02 Oct '14

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel