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

Re: Assorted spelling fixes

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4916 Your paranoid android. === w8 (32 bit midi) === midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM

Feb. 15, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Ken Thomases

On Feb 15, 2014, at 6:17 PM, Christopher Thielen wrote: > I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. > > I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. > > Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. Probably you should start by collecting a log with the +ddraw,+d3d,+d3d_surface channels and looking for messages that mention "overlay". >From a cursory look, it seems that wined3d supports some types of overlay surfaces and some operations on those surfaces, but not all. > Is there any easy way to see which DLLs Wine loads when running an application? You can look at a +module log. -Ken

Feb. 15, 2014

Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Hi wine-devel, I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. Is there any easy way to see which DLLs Wine loads when running an application? I appreciate any advice, I'm new but want to help, Christopher Thielen

Feb. 15, 2014

Re: Fixing up the code style

by Henri Verbeet

On 15 February 2014 07:32, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > I'm not sure it's always clear what to do even the case of more > experienced contributors, I've been taking a look at fixing a double > unlock bug in RtlAcquireResourceExclusive ( > http://source.winehq.org/source/dlls/ntdll/rtl.c#L157 ). And the > style there indent-wise is so screwy that it's not clear what I should > do in my patch. This one function currently has (level wise): > 1) Four space indents > 2) A tab indent + a space indent (in some cases just the tab) > 3) A tab indent + a five space indent (alternatively, 13 spaces) > 4) Two tabs + a space indent > > So, what do I do? Do I just change line 190 to fix the bug and keep > the two tab + a space indent? Do I fix just this line to conform to > the standard since it's the only one I need to touch? Do I fix this > one function because a lot of it doesn't conform to the standard? Personally, in this specific case, I'd probably just change the single line, and replace the tabs with spaces there. In a module I'm more familiar with like wined3d I'd probably touch up slightly more. Except for reformatting the entire function, I doubt Alexandre would reject any of your approaches though, provided the patch is otherwise fine. As for the original point of this thread, if Stefan spends considerable amounts of time explaining coding style to new contributors, perhaps it's worth the effort to maintain a page on the wiki, and point people to that instead.

Feb. 15, 2014

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)

by Henri Verbeet

On 15 February 2014 03:45, Ken Thomases <ken(a)codeweavers.com> wrote: > When I implement WGL_WINE_make_current, it will be more complicated again and will need gl_info to check if the extension is supported. (I actually already have that implemented locally. I've been waiting for this pixel format stuff to clear before submitting it.) > Ok, makes sense.

Feb. 15, 2014

Re: [PATCH 2/7] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 3)

by Henri Verbeet

On 15 February 2014 03:52, Ken Thomases <ken(a)codeweavers.com> wrote: > Hmm. I won't be able to double-check until Monday, but I'm pretty sure I got the opengl32 test_setpixelformat() to fail on a real Win7 machine just by commenting out the wglCreateContext() call (and the other tests) that is done before it. That is, running the executable from <https://newtestbot.winehq.org/JobDetails.pl?Key=4752>. > > Assuming it works without the wglCreateContext(), would you prefer the dynamic loading approach to the import I had done? > Yeah.

Feb. 15, 2014

Re: Fixing up the code style

by Nikolay Sivov

On 2/15/2014 10:32, Erich E. Hoover wrote: > On Thu, Feb 13, 2014 at 7:24 AM, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: >> ... >> Maybe, or maybe not. The basic issue still stands. New contributors >> will look at the existing code, and if its inconsistent how are they >> supposed to write code that's consistent in itself. That's not a >> question of pickiness but approach to the problem. >> ... > I'm not sure it's always clear what to do even the case of more > experienced contributors, I've been taking a look at fixing a double > unlock bug in RtlAcquireResourceExclusive ( > http://source.winehq.org/source/dlls/ntdll/rtl.c#L157 ). And the > style there indent-wise is so screwy that it's not clear what I should > do in my patch. This one function currently has (level wise): > 1) Four space indents > 2) A tab indent + a space indent (in some cases just the tab) > 3) A tab indent + a five space indent (alternatively, 13 spaces) > 4) Two tabs + a space indent > > So, what do I do? Please send a fix that changes only what you need to change, why not? > Do I just change line 190 to fix the bug and keep > the two tab + a space indent? Do I fix just this line to conform to > the standard since it's the only one I need to touch? Do I fix this > one function because a lot of it doesn't conform to the standard? > Personally, I would like to have a separate formatting patch to fix > the function so that it's clear that I'm just fixing the one thing - > but that's expressly prohibited under the current guidelines. > >> ... >> My impression was that the answers to that were no and no, with the >> idea that the problem will be fixed by unifying the style together >> with other, functional changes. That way we end up with picky reviews >> and IMO that approach is bad. >> ... > I agree, Sebastian and I have been debating what to do with this > function (and RtlAcquireResourceShared) for some time and style is the > only thing keeping us from submitting the one-line fix for these. I don't see a problem here, if it's a one-line fix just submit it while keeping existing formatting of a changed line, what's a big deal? Yes, sometimes style is inconsistent, sometimes whitespace formatting differs from line to line but that kind of existing code "features" should never stop you from sending a fix. In a situation like that I usually change several lines before and after to use 4 spaces indentation. > Honestly, it would be really great if we could run something like > astyle on the whole codebase so that we were always working off of a > "known good" style. If we could get that implemented then we could > potentially think about verifying the patch style on submission and > auto-rejecting patches that have style problems. Personally, I think > that would be an amazing improvement to our submission process, I don't think it's ever a case that potential contributor decides not to do any work solely after looking at some code style issues and saying - oh, well, what a mess, I'm not going to touch it. What actually happens when people send patches (or attach them to a bug and then disappear) is that patch is wrong in a first place, and code style issues are a second problem that's easy to fix comparing to functional part. Of course if all code uses same style we could simply avoid step 2 but that's not a blocking issue for new contributors. Another thing is that some parts of wine have long time contributors, like wined3d, mshtml, msvcrt or audio bits. Why should we force their maintainers to some particular code style? I personally can live with any decision made regarding reformatting everything, as long as it doesn't use some ugly mixed case names, variable names with type prefixes, LPLPLP stuff and such. Anyway formatting issues never surprised me that much to stop fixing a real problem, but that's probably because I'm constantly jumping from one part to another, and from project to project on my daily job. > but I > have to use K&R style for work and I hate feeling like an idiot when I > slip into the wrong style for a project. > > Best, > Erich > > >

Feb. 15, 2014

Re: Fixing up the code style

by Erich E. Hoover

On Thu, Feb 13, 2014 at 7:24 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > ... > Maybe, or maybe not. The basic issue still stands. New contributors > will look at the existing code, and if its inconsistent how are they > supposed to write code that's consistent in itself. That's not a > question of pickiness but approach to the problem. > ... I'm not sure it's always clear what to do even the case of more experienced contributors, I've been taking a look at fixing a double unlock bug in RtlAcquireResourceExclusive ( http://source.winehq.org/source/dlls/ntdll/rtl.c#L157 ). And the style there indent-wise is so screwy that it's not clear what I should do in my patch. This one function currently has (level wise): 1) Four space indents 2) A tab indent + a space indent (in some cases just the tab) 3) A tab indent + a five space indent (alternatively, 13 spaces) 4) Two tabs + a space indent So, what do I do? Do I just change line 190 to fix the bug and keep the two tab + a space indent? Do I fix just this line to conform to the standard since it's the only one I need to touch? Do I fix this one function because a lot of it doesn't conform to the standard? Personally, I would like to have a separate formatting patch to fix the function so that it's clear that I'm just fixing the one thing - but that's expressly prohibited under the current guidelines. > ... > My impression was that the answers to that were no and no, with the > idea that the problem will be fixed by unifying the style together > with other, functional changes. That way we end up with picky reviews > and IMO that approach is bad. > ... I agree, Sebastian and I have been debating what to do with this function (and RtlAcquireResourceShared) for some time and style is the only thing keeping us from submitting the one-line fix for these. Honestly, it would be really great if we could run something like astyle on the whole codebase so that we were always working off of a "known good" style. If we could get that implemented then we could potentially think about verifying the patch style on submission and auto-rejecting patches that have style problems. Personally, I think that would be an amazing improvement to our submission process, but I have to use K&R style for work and I hate feeling like an idiot when I slip into the wrong style for a project. Best, Erich

Feb. 15, 2014

RE: Converting source to unicode, bug 28189

by Hugh McMaster

On Saturday, 15 February 2014 3:00 AM, Akihiro Sagawa wrote: >[My idea] >static int some_function(void) >{ > /* ... */ > output_write(STRING_FOO); > output_write(STRING_BAR); > /* ... */ >} > >static void __cdecl output_write(UINT id, ...) { > /* variable declarations */ > > if (Silent) > return; /* do nothing */ > > /* then, LoadString, FormatMessage, etc. */ } > >Does this work for you? Yes. This makes perfect sense now. Thank you.

Feb. 14, 2014

Re: [PATCH 2/7] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 3)

by Ken Thomases

On Feb 14, 2014, at 11:53 AM, Henri Verbeet wrote: > On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: >> + /* If no opengl32 function has been called, GetPixelFormat() doesn't reflect a >> + prior SetPixelFormat(). So, call wglCreateContext() even though it will fail. */ >> + hglrc = wglCreateContext(hdc); >> + ok(hglrc == NULL, "wglCreateContext succeeded when no pixel format has been set\n"); >> + if (hglrc) wglDeleteContext(hglrc); > I decided to look into this a bit, but could only reproduce it on the > testbot. It seems just loading opengl32 is enough to make > GetPixelFormat() work. (Also see > https://newtestbot.winehq.org/JobDetails.pl?Key=4908.) Hmm. I won't be able to double-check until Monday, but I'm pretty sure I got the opengl32 test_setpixelformat() to fail on a real Win7 machine just by commenting out the wglCreateContext() call (and the other tests) that is done before it. That is, running the executable from <https://newtestbot.winehq.org/JobDetails.pl?Key=4752>. Assuming it works without the wglCreateContext(), would you prefer the dynamic loading approach to the import I had done? -Ken

Feb. 14, 2014

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)

by Ken Thomases

On Feb 14, 2014, at 11:52 AM, Henri Verbeet wrote: > On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: >> -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) >> +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) > This doesn't need "gl_info" either anymore now. It's also a bit > questionable if context_restore_gl_context() has much of a purpose at > all anymore, it's pretty much just a wglMakeCurrent() call, and has > only two callers. When I implement WGL_WINE_make_current, it will be more complicated again and will need gl_info to check if the extension is supported. (I actually already have that implemented locally. I've been waiting for this pixel format stuff to clear before submitting it.) -Ken

Feb. 14, 2014

Re: xmllite: Don't fail the whole parsing process because of unsupported 'xmlns' attribute.

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Do you plan to add more code to xmllite itself or what we have is enough > for taskschd so far? With currectly sent fixes for xmllite I was able to successfully parse pretty complex XML task definitions imported using Tasks Scheduler UI from Windows7. At some point I will also need to generate XML task defs, and I haven't tested that xmllite functionality yet. As long as I don't find other bugs in xmllite I have no plans to spend more time on it. -- Dmitry.

Feb. 14, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Henri Verbeet

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Unfortunately different implementations(Windows-NV and Mac-AMD tested) interpret some colors vastly > + * differently, so we need a max diff of 18. */ And actually, is there any chance the "vastly differently" here is because of using BT.601 vs. BT.709 coefficients, or not including the headroom/footroom scaling + offsets?

Feb. 14, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Henri Verbeet

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - HRESULT color; > - DWORD ref_color_left, ref_color_right; > + DWORD ref_color_left, ref_color_right, color; > If you're cleaning it up anyway, you may as well make that a D3DCOLOR. > + static const struct > + { > + DWORD in; /* The input color. */ > + DWORD uyvy_left; /* "in" interpreted as uyvy and transformed to RGB, pixel 1/1. */ > + DWORD uyvy_right; /* "in" interpreted as uyvy and transformed to RGB, pixel 2/1. */ > + DWORD yuy2_left; /* "in" interpreted as yuy2 and transformed to RGB, pixel 1/1. */ > + DWORD yuy2_right; /* "in" interpreted as yuy2 and transformed to RGB, pixel 2/1. */ > + } > + test_data[] = > + { > + {0x00000000, 0x00008700, 0x00008700, 0x00008700, 0x00008700}, > + {0xff000000, 0x00008700, 0x004bff1c, 0x00b30000, 0x00b30000}, > + {0x00ff0000, 0x00b30000, 0x00b30000, 0x00008700, 0x004bff1c}, > + {0x0000ff00, 0x004bff1c, 0x00008700, 0x000030e1, 0x000030e1}, > + {0x000000ff, 0x000030e1, 0x000030e1, 0x004bff1c, 0x00008700}, > + {0xffff0000, 0x00b30000, 0x00ffd01c, 0x00b30000, 0x00ffd01c}, > + {0xff00ff00, 0x004bff1c, 0x004bff1c, 0x00b300e1, 0x00b300e1}, > + {0xff0000ff, 0x000030e1, 0x004bffff, 0x00ffd01c, 0x00b30000}, > + {0x00ffff00, 0x00ffd01c, 0x00b30000, 0x000030e1, 0x004bffff}, > + {0x00ff00ff, 0x00b300e1, 0x00b300e1, 0x004bff1c, 0x004bff1c}, > + {0x0000ffff, 0x004bffff, 0x000030e1, 0x004bffff, 0x000030e1}, > + {0xffffff00, 0x00ffd01c, 0x00ffd01c, 0x00b300e1, 0x00ff79ff}, > + {0xffff00ff, 0x00b300e1, 0x00ff79ff, 0x00ffd01c, 0x00ffd01c}, > + {0xffffffff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff}, > + {0x4cff4c54, 0x00ff0000, 0x00ff0000, 0x000b8b00, 0x00b6ffa3}, > + {0x00800080, 0x00000000, 0x00000000, 0x0000ff00, 0x0000ff00}, > + {0xff80ff80, 0x00ffffff, 0x00ffffff, 0x00ff00ff, 0x00ff00ff}, > + {0x1c6b1cff, 0x000000fd, 0x000000fd, 0x006dff45, 0x0000d500}, > }; ... > - for(fmt = 0; fmt < 2; fmt++) { > - if(fmt == 0) { > - format = D3DFMT_UYVY; > - fmt_string = "D3DFMT_UYVY"; > - } else { > + for (fmt = 0; fmt < 2; fmt++) > + { > + if (fmt) > + { > format = D3DFMT_YUY2; > fmt_string = "D3DFMT_YUY2"; > } > + else > + { > + format = D3DFMT_UYVY; > + fmt_string = "D3DFMT_UYVY"; > + } ... > + if (fmt) > + { > ref_color_left = test_data[i].yuy2_left; > ref_color_right = test_data[i].yuy2_right; > } > + else > + { > + ref_color_left = test_data[i].uyvy_left; > + ref_color_right = test_data[i].uyvy_right; > + } > There's probably a nicer way to do all that.

Feb. 14, 2014

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Henri Verbeet

On 13 February 2014 14:52, Martin Storsjo <martin(a)martin.st> wrote: > + IDirect3DSurface9 *surface = NULL, *target = NULL; You don't need those to be NULL. > + HRESULT color; You'll want to use D3DCOLOR instead of HRESULT here. > + /* Some (all?) Windows drivers do not support YUV 3D textures, only 2D surfaces in > + * StretchRect. Thus use StretchRect to draw the YUV surface onto the screen instead > + * of drawPrimitive. */ > + if (IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0, > + D3DRTYPE_SURFACE, format) != D3D_OK) > + { > + skip("%s is not supported.\n", fmt_string); > + continue; > + } You should also verify the StretchRect() is supported with CheckDeviceFormatConversion(). > + BYTE Y = (color >> 16) & 0xff; > + BYTE U = (color >> 8) & 0xff; > + BYTE V = (color >> 0) & 0xff; It's probably just as easy to just store the separate components to begin with. > + hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT); > + ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr); > + > + /* Native D3D can't resist filtering the YUY surface, even though we asked it not to > + * do so above. To prevent running into precision problems, read at points with some > + * margin within the rect. */ That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.

Feb. 14, 2014

Re: [PATCHv4 2/3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Henri Verbeet

On 13 February 2014 13:05, Martin Storsjo <martin(a)martin.st> wrote: > static HRESULT arbfp_blit_alloc(struct wined3d_device *device) > { > + struct arbfp_blit_priv *priv; > device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); > if(!device->blit_priv) { > ERR("Out of memory\n"); > return E_OUTOFMEMORY; > } > + priv = device->blit_priv; > + > + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) > + { > + ERR("Failed to initialize rbtree.\n"); > + HeapFree(GetProcessHeap(), 0, device->blit_priv); > + device->blit_priv = NULL; > + return E_OUTOFMEMORY; > + } > + > return WINED3D_OK; > } > The following is probably slightly nicer: static HRESULT arbfp_blit_alloc(struct wined3d_device *device) { - device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); - if(!device->blit_priv) { - ERR("Out of memory\n"); + struct arbfp_blit_priv *priv; + + if (!(priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*priv)))) return E_OUTOFMEMORY; + + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) + { + ERR("Failed to initialize rbtree.\n"); + HeapFree(GetProcessHeap(), 0, priv); + return E_FAIL; } + + device->blit_priv = priv; + return WINED3D_OK; } > + if (desc) > + HeapFree(GetProcessHeap(), 0, desc); There's no point in checking for NULL before HeapFree(). Perhaps more importantly, I think it makes more sense to insert the rbtree entries in arbfp_blit_set(), instead of duplicating the code between gen_p8_shader() and gen_yuv_shader().

Feb. 14, 2014

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

Feb. 14, 2014

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

Feb. 14, 2014

Re: [PATCH 2/7] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 3)

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > + /* If no opengl32 function has been called, GetPixelFormat() doesn't reflect a > + prior SetPixelFormat(). So, call wglCreateContext() even though it will fail. */ > + hglrc = wglCreateContext(hdc); > + ok(hglrc == NULL, "wglCreateContext succeeded when no pixel format has been set\n"); > + if (hglrc) wglDeleteContext(hglrc); I decided to look into this a bit, but could only reproduce it on the testbot. It seems just loading opengl32 is enough to make GetPixelFormat() work. (Also see https://newtestbot.winehq.org/JobDetails.pl?Key=4908.)

Feb. 14, 2014

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) > +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) This doesn't need "gl_info" either anymore now. It's also a bit questionable if context_restore_gl_context() has much of a purpose at all anymore, it's pretty much just a wglMakeCurrent() call, and has only two callers.

Feb. 14, 2014

Re: [PATCH 5/5] d3dx9: Handle pixel formats larger than 32 bits in surface loading / filtering functions.

by Matteo Bruni

2014-02-14 17:03 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 14 February 2014 15:53, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> + if (format->bits[c]) >> + { >> + mask = format->bits[c] == 32 ? ~0U : (1 << format->bits[c]) - 1; > You could probably also do that as "mask = ~0u >> (32 - > format->bits[c]);", since you already need to check "format->bits[c]" > for 0 anyway. > Good point, I'll resend this patch with that change.

Feb. 14, 2014

Re: [PATCH 5/5] d3dx9: Handle pixel formats larger than 32 bits in surface loading / filtering functions.

by Henri Verbeet

On 14 February 2014 15:53, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (format->bits[c]) > + { > + mask = format->bits[c] == 32 ? ~0U : (1 << format->bits[c]) - 1; You could probably also do that as "mask = ~0u >> (32 - format->bits[c]);", since you already need to check "format->bits[c]" for 0 anyway.

Feb. 14, 2014

Re: Converting source to unicode, bug 28189

by Akihiro Sagawa

On Fri, 14 Feb 2014 06:25:38 -0500, Hugh McMaster wrote: > >7. Silent handling: Many times, it refers Silent variable before > > calling output_write function. How about moving the check to the > > function? > Do you mean that I should add the Silent boolean value as a variable > in the function call? No. I meant: [Existing code] static int some_function(void) { /* ... */ if (Silent) { output_write(STRING_FOO); output_write(STRING_BAR); } /* ... */ } [My idea] static int some_function(void) { /* ... */ output_write(STRING_FOO); output_write(STRING_BAR); /* ... */ } static void __cdecl output_write(UINT id, ...) { /* variable declarations */ if (Silent) return; /* do nothing */ /* then, LoadString, FormatMessage, etc. */ } Does this work for you?

Feb. 14, 2014

Re: [PATCH 2/2] mshtml: Use IWebBrowserPriv2IE9 instead of IWebBrowserPriv2IE8 in tests on IE9+.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4905 Your paranoid android. === w8 (32 bit htmldoc) === htmldoc.c:2858: Test failed: unexpected command 74 htmldoc.c:2858: Test failed: unexpected command 74

Feb. 14, 2014

Re: xmllite: Don't fail the whole parsing process because of unsupported 'xmlns' attribute.

by Nikolay Sivov

On 2/14/2014 11:23, Dmitry Timoshkov wrote: > This patch allows to successfully parse pretty complex XML task definitions. > > Please apply after other xmllite fixes. I think it's fine to relax a check here as you did if it really helps. Same applies to other patches. My main problem with all of that is that whole reader code needs to be revised and partially rewritten at some point (better sooner than later), to properly support chunked reads and corresponding state updates. Looking at it now I don't actually like the way I did it, it's not easily extensible and not very clean. Do you plan to add more code to xmllite itself or what we have is enough for taskschd so far?

Feb. 14, 2014

Re: configure: Add import library for xmllite.

by Henri Verbeet

On 14 February 2014 08:23, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > -WINE_CONFIG_DLL(xmllite) > +WINE_CONFIG_DLL(xmllite,,[implib]) That's auto-generated by make_makefiles from Makefile.in.

Feb. 14, 2014

Re: ws2_32: Fix some edge cases for getaddrinfo in BSD and OSX

by Bruno Jesus

On Fri, Feb 14, 2014 at 9:27 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> wrote: > >> + /* servname tweaks required by OSX and BSD kernels */ >> + if (!servname) >> + serv = NULL; >> + else if (!servname[0]) >> + serv = "0"; >> + else >> + serv = servname; > > Shouldn't 'serv = "0"' be 'serv = ""' ? No, that is the trick. Linux supports both "" and "0" but OSX/BSD does not support "". So turning the "" into "0" solves the issue. > -- > Dmitry. Bruno

Feb. 14, 2014

Re: ws2_32: Fix some edge cases for getaddrinfo in BSD and OSX

by Dmitry Timoshkov

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > + /* servname tweaks required by OSX and BSD kernels */ > + if (!servname) > + serv = NULL; > + else if (!servname[0]) > + serv = "0"; > + else > + serv = servname; Shouldn't 'serv = "0"' be 'serv = ""' ? -- Dmitry.

Feb. 14, 2014

RE: Converting source to unicode, bug 28189

by Hugh McMaster

Hi Akihiro, Many thanks for your comments. On Friday, 14 February 2014 3:06 AM, Akihiro Sagawa wrote: >Regarding your patch, attachment #47519, I roughly read the code and post comments at the following points: >5. Double quote handling: command_line is advanced when the code > finds a double quote character. When it updates wsCommandLine? Good catch! :) >7. Silent handling: Many times, it refers Silent variable before > calling output_write function. How about moving the check to the > function? Do you mean that I should add the Silent boolean value as a variable in the function call?

Feb. 14, 2014

Re: [PATCH 5/5] tests: Allow broken results to cause failures on the "windows" platform as well.

by Henri Verbeet

On 14 February 2014 11:58, Alexandre Julliard <julliard(a)winehq.org> wrote: > Couldn't you simply set the platform to "windows_broken" or something > like that? > In practice that's probably good enough, although strictly speaking it would break win_skip(). I don't care too strongly, I mostly sent this in in case someone else found it useful as well.

Feb. 14, 2014

Re: ws2_32: Fix some edge cases for getaddrinfo in BSD and OSX

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4901 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (b34): unexpectedly at the OOB mark: 0 === wvistau64 (32 bit sock) === sock.c:557: Test failed: oob_server (744): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 753E9799 === w2008s64 (32 bit sock) === sock.c:547: Test failed: oob_server (768): unexpectedly at the OOB mark: 0 sock.c:557: Test failed: oob_server (768): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 757C9799 === wvistau64 (64 bit sock) === sock.c:557: Test failed: oob_server (b5c): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:547: Test failed: oob_server (a54): unexpectedly at the OOB mark: 0 sock.c:557: Test failed: oob_server (a54): unexpectedly at the OOB mark: 0 sock.c:326: Test failed: do_synchronous_recv (a54): error 10054: sock.c:572: Test failed: oob_server (a54): not at the OOB mark: 1

Feb. 14, 2014

Re: [PATCH 5/5] tests: Allow broken results to cause failures on the "windows" platform as well.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > include/wine/test.h | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/include/wine/test.h b/include/wine/test.h > index f8b608f..c81fe11 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -208,6 +208,9 @@ const char *winetest_platform = "windows"; > /* report successful tests (BOOL) */ > static int report_success = 0; > > +/* fail on broken() */ > +static int fail_broken = 0; > + > /* passing arguments around */ > static int winetest_argc; > static char** winetest_argv; > @@ -289,7 +292,7 @@ void winetest_set_location( const char* file, int line ) > > int broken( int condition ) > { > - return (strcmp(winetest_platform, "windows") == 0) && condition; > + return !fail_broken && condition; > } > > /* > @@ -636,6 +639,8 @@ int main( int argc, char **argv ) > if (GetEnvironmentVariableA( "WINETEST_DEBUG", p, sizeof(p) )) winetest_debug = atoi(p); > if (GetEnvironmentVariableA( "WINETEST_INTERACTIVE", p, sizeof(p) )) winetest_interactive = atoi(p); > if (GetEnvironmentVariableA( "WINETEST_REPORT_SUCCESS", p, sizeof(p) )) report_success = atoi(p); > + if (GetEnvironmentVariableA( "WINETEST_FAIL_BROKEN", p, sizeof(p) )) fail_broken = atoi(p); > + else fail_broken = strcmp( winetest_platform, "windows" ); Couldn't you simply set the platform to "windows_broken" or something like that? -- Alexandre Julliard julliard(a)winehq.org

Feb. 14, 2014

Re: ntdll: add a stub for NtSetLdtEntries/ZwSetLdtEntries

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Jan 27, 2014 at 3:48 PM, Austin English <austinenglish(a)gmail.com>wrote: > > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26268 (tested with Kwik > > Support). > > > > -- > > -Austin > > > > Any comments on this patch? It's clearly wrong. -- Dmitry.

Feb. 14, 2014

Re: dpnet: Use registry for lookup in IDirectPlay8Peer (try 2)

by Alistair Leslie-Hughes

Hi Bruno, On 14/02/2014 8:30 PM, Bruno Jesus wrote: > On Fri, Feb 14, 2014 at 5:28 AM, Alistair Leslie-Hughes > Not really, because when you add a size to a pointer it increments in > the pointer size and not bytes. So WCHAR *ptr=0; ptr+=10; > printf("%p\n", p); would print 0x14 (20 in decimal although we just > added 10 to it). The theory is correct. However RegGetValueW returns the size of the buffer we would need to allocate including the null terminator. In your example it would return 20 (9+1*sizeof(WCHAR)) and not 10. Best Regards Alistair Leslie-Hughes

Feb. 14, 2014

Re: dpnet: Use registry for lookup in IDirectPlay8Peer (try 2)

by Bruno Jesus

On Fri, Feb 14, 2014 at 5:28 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi Bruno, > > > On 14/02/2014 10:18 AM, Bruno Jesus wrote: >> >> On Thu, Feb 13, 2014 at 1:23 AM, Alistair Leslie-Hughes >> <leslie_alistair(a)hotmail.com> wrote: >> You are only reading the key value in the first loop to trace it, >> maybe you could simplify this loop with a single RegGetValueW call and >> no memory allocation just to get the size required and in the next >> loop where you really copy the data you could trace it. > > > Thanks for you feedback. I've re-factored the patch and it's alot cleaner > than the first few iterations. > > Its still needs to be a char cast since RegGetValueW returns the size in > bytes which would make the offset incorrect. Not really, because when you add a size to a pointer it increments in the pointer size and not bytes. So WCHAR *ptr=0; ptr+=10; printf("%p\n", p); would print 0x14 (20 in decimal although we just added 10 to it). > Best Regards > Alistair Leslie-Hughes Bruno

Feb. 14, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-14 00:08, schrieb Marvin: > === w8 (32 bit visual) === visual.c:10474: Test failed: Failed to > draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test > failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, > expected 0x00008700, format D3DFMT_YUY2. visual.c:10487: Test > failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, > expected 0x00008700, format D3DFMT_YUY2. Patch 2 fixes those issues. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/dYtAAoJEN0/YqbEcdMwnUkP/R/jBsozPhUxXxuQ4hYmDHmi ZLeWZIzp7KwEjJB+UxzpZlDKOCtPc5lfhIxYIViqviF9XRx/rAoVMJp5TFoRQNT5 RQVe6hO1cnXexGOZ0MHE11w51lsV49XEtPXntyb8jTGyhFpsMvJrIX6Kb8spqlG+ YMzUdHO2fzFpTnDiR2unOnGZwwHXbkz8XWWkdwJuF2xzUj3GEutd03OxXawPcWcR mdvxg+XphWNevxsaNCv7z8jknu7VycVhXfPB9bdCHN91iOFACh9b6nmp6pfPAVHm NDnycvPXQj3wi8e49uhFE2nvPqmXc0jpdGn0XNk3bQ2Jpu5QSczpQQkVehhjbcJ2 cSAO1W+uc9eIkILnd1enLtrwJv82ySf3cXMzBcXpex9q9LgL/A5zM3mIetjQEWJS zOYeBGxD6PoMeMoqdjZcwstE6FxUHdH7E9b4Wbe2iNXA4EEeQO46ALKydjCzxe+l x2YUOWR5ArMLFJzCQYdD2E+SOw21urO9+FiwDqHlAHj5AcHoEi20R5a5Nw2amlt7 q9PR8suYjxnlOEk7yW6Gn7ppAQNGqbR9cR03oPdjkjhl6M+Z9Bjbq/y6WcOKCzHg wPCpOxVwTARL46N6q4vdHyxXBrqyWy+oqFXjTzr3aChsVfxQ51AZ/savzFluau8E qYNb8N0PvYPB6DgGPCbx =5Znm -----END PGP SIGNATURE-----

Feb. 14, 2014

Re: dpnet: Use registry for lookup in IDirectPlay8Peer (try 2)

by Alistair Leslie-Hughes

Hi Bruno, On 14/02/2014 10:18 AM, Bruno Jesus wrote: > On Thu, Feb 13, 2014 at 1:23 AM, Alistair Leslie-Hughes > <leslie_alistair(a)hotmail.com> wrote: > You are only reading the key value in the first loop to trace it, > maybe you could simplify this loop with a single RegGetValueW call and > no memory allocation just to get the size required and in the next > loop where you really copy the data you could trace it. Thanks for you feedback. I've re-factored the patch and it's alot cleaner than the first few iterations. Its still needs to be a char cast since RegGetValueW returns the size in bytes which would make the offset incorrect. Best Regards Alistair Leslie-Hughes

Feb. 14, 2014

Re: [PATCH 5/7] ddraw/tests: Test that DirectDraw4 doesn't modify the pixel format of the window it targets.

by Ken Thomases

On Feb 13, 2014, at 7:01 PM, Marvin wrote: > === w8 (32 bit ddraw4) === > ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. Not related to my patch. -Ken

Feb. 13, 2014

Re: [PATCH 5/7] ddraw/tests: Test that DirectDraw4 doesn't modify the pixel format of the window it targets.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4892 Your paranoid android. === w8 (32 bit ddraw4) === ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001.

Feb. 13, 2014

Re: [PATCH 3/7] d3d8/tests: Test that Direct3D8 doesn't modify the pixel format of the window it targets.

by Ken Thomases

On Feb 13, 2014, at 6:35 PM, Marvin wrote: > === w8 (32 bit device) === > device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. > device.c:3268: Test failed: Expected wndproc 0x4100c0, got 0x4100c0. Not related to my patch. -Ken

Feb. 13, 2014

Re: [PATCH 3/7] d3d8/tests: Test that Direct3D8 doesn't modify the pixel format of the window it targets.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4890 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x4100c0, got 0x4100c0.

Feb. 13, 2014

Re: [PATCH 5/5] ddraw/tests: Port test_private_data to ddraw4.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4886 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001.

Feb. 13, 2014

Re: [PATCH 4/5] d3d8/tests: Add a test for sub resource private data.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4885 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x410530, got 0x410530.

Feb. 13, 2014

Re: dpnet: Use registry for lookup in IDirectPlay8Peer (try 2)

by Bruno Jesus

On Thu, Feb 13, 2014 at 1:23 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Corrected pointer arithmetic. > Corrected assign memory for RegGetValueW calls. > > Changelog: > dpnet: Use registry for lookup in IDirectPlay8Peer > > > Best Regards > Alistair Leslie-Hughes > > > Hi, here are my thoughts about this patch, as I told you before I'm really looking forward for your dpnet work =) I'm not used to review patches so if I do something wrong I ask for sorry in advance. + if(!pcReturned || !pcbEnumData) + return E_POINTER; This checks together with the error tests could be in a different patch as they are not related to the main subject of the patch. + while(nextKeyNameResult == ERROR_SUCCESS) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, NULL, &size); + if(res == ERROR_SUCCESS) + { + WCHAR *buf = HeapAlloc(GetProcessHeap(), 0, size); + if(buf) + { + res = RegGetValueW( key, provider, friendly, RRF_RT_REG_SZ, NULL, buf, &size); + if(res == ERROR_SUCCESS) + { + TRACE("%s=%s\n", debugstr_w(provider), debugstr_w(buf)); + + req_size += sizeof(DPN_SERVICE_PROVIDER_INFO) + (size * sizeof(WCHAR)); + + (*pcReturned)++; + } You are only reading the key value in the first loop to trace it, maybe you could simplify this loop with a single RegGetValueW call and no memory allocation just to get the size required and in the next loop where you really copy the data you could trace it. + char *infoend = ((char *)pSPInfoBuffer + (sizeof(DPN_SERVICE_PROVIDER_INFO) * (*pcReturned))); Since you are copying WCHAR data infoend should be a WCHAR pointer and it could be done like this AFAICS: WCHAR *infoend = (WCHAR *)(pSPInfoBuffer + *pcReturned); + while(nextKeyNameResult == ERROR_SUCCESS) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, NULL, &size); + + if(res == ERROR_SUCCESS) + { + WCHAR *buf = HeapAlloc(GetProcessHeap(), 0, size); + if(buf) + { + res = RegGetValueW(key, provider, friendly, RRF_RT_REG_SZ, NULL, buf, &size); + if(res == ERROR_SUCCESS) + { + pSPInfoBuffer[count].guid = CLSID_DP8SP_TCPIP; + pSPInfoBuffer[count].pwszName = (LPWSTR)(infoend + offset); + lstrcpyW(pSPInfoBuffer[count].pwszName, buf); + What if you read data directly over infoend buffer? This would eliminate the need for buf memory allocation and the strcpy. You would only have to set the pwszName. + offset += size-1; If you do a -1 here the next string will overwrite the NULL terminator from the previous string, won't it? If you decide to copy directly over the infoend buffer you could also get rid from the offset variable since you could do infoend += size instead. Best regards, Bruno

Feb. 13, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4882 Your paranoid android. === w8 (32 bit visual) === visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 2/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 2/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 1/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 1/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 1/1, expected 0x000b8b00, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 2/1, expected 0x00b6ffa3, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 1/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 2/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 1/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 2/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10474: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10483: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 1/1, expected 0x006dff45, format D3DFMT_YUY2. visual.c:10487: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 2/1, expected 0x0000d500, format D3DFMT_YUY2.

Feb. 13, 2014

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 15:49, schrieb Stefan Dösinger: > Looks good, thanks! > > Wrt the testbot failures: It looks like > CheckDeviceFormatConversion is in fact the right way to check this > - I missed a sentence in the msdn page. I'll send a patch to handle > this in this test and yuv_color_test. Real Windows drivers seem to > agree with our interpretation of CheckDeviceFormatConversion. I've sent a patch (id 102467) that should take care of the testbot failures on the Windows 8 machine. The fix should conceptually work for your test as well. I'm not entirely sure why Henri didn't ack your patches, but my guess it's because of the testbot failure or he was just waiting a day for the dust to settle. If not I'm sure he'll voice his concerns. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/U4sAAoJEN0/YqbEcdMwjqkQAJJWOztWX1qVURmKdH8Kzve8 COnAyRN4sDdexdEL3m7GzeGq269+tLPriGcePnqkqpERUYI5tRE+rixOQeojG4Ee F6o4CxoG/MOxaxTNt7ZAx5k7ZGq3Of35I8cO1pM4ENJR0VSaot1KCGjfQj7dkoU+ 1f55VHNp8JGY8Mi7bsKkKe5IZf0I3cJHtVQ9l/SKGaaee62eT5QJKBRvLpdkLxTk Eb7OlJi5zs3YWetKxEZmQS7+lvXSmZt7JsWl2BjxKKCYr3X3L54cSwjngv8TwKF8 EY0i2F9L+aPMXYqmtF5DeMlVgEVmAwSG1qTfGULaocLLu5AaR2HFiRUisRrxpkRq dq6BIFBqE9sGY4gDrJaLk9JTRg8W4zTwbX7lonMTI/wu7i2NwmIF1zo3yuypozLH GUpvoUqgys4DF6Xq+yQKg9Hedx/Eu9KzBdtQtJ5lgq8TbZuzuDtarBUZr5V2Mus0 N+gHx57wTAAzeldQ676hueVOPTH8zz3hk5TihWMA2OISyoGojNnTaaPOuiIZ4a4Y 6HZCTaWHCdMDk8Uf2P3M0Bnrh+o9lJddwToNPim8dvhI17HLIzWiThsKMHjcwK4I U9Ov4IvSdRYySAgPBXb/5Tx4L3e4wzUOogIOw9f5uyctluq5vW9Cc0z0d4siOfOe 2yNNPm+SJVbR5nmoqDHx =uLek -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Sebastian Lackner

Am 13.02.2014 15:24, schrieb Stefan Dösinger: > Am 2014-02-13 14:57, schrieb Jacek Caban: > Martin, Michael or Sebastian: If you are reading this thread maybe you > can share your thoughts from the point of view of someone who isn't a > long-term contributor. > I have to agree with Stefan, for someone new trying to contribute to the project its really confusing. Often not even inside a single DLL a unique style is used, and especially tests are often even a bit worse. When someone wants to contribute, he might just think that there isn't any code style restriction at all. But even with the knowledge that there is one, its sometimes not very clear what the rules are exactly. Noone would start by creating statistics first, to figure out what the most commonly used style is. To sum it up, I would also support the idea to refactor the whole code base. Several methods (ordered from best to worst): * refactor the code globally, such that every component uses the same style. This would be the easiest method for people to check their own code, since they can just use a checktool on the whole wine source. * at least a single code style for each DLL/component individually, and someone who documents the used code style for every component if its not obvious (like a header field or as part of the spec file?). * as a last option, but very complicated, and most likely not worth the effort: instead of refactoring Wine could provide some git precommit hook / other check tool, to test patches if they match the rules for a specific component BTW: with "git blame -w" its not even necessary to run it twice ;) Regards, Sebastian

Feb. 13, 2014

Re: [PATCH 1/3] atl: Share atl_ax.c with atl100.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/atl/Makefile.in | 3 ++- > dlls/atl/atl.spec | 18 +++++++++--------- > dlls/atl/atl_main.c | 48 ------------------------------------------------ > dlls/atl100/atl_ax.c | 15 ++++++++++----- > 4 files changed, 21 insertions(+), 63 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M atl.dll -p atl_test.exe.so atl_ax && touch atl_ax.ok atl_ax.c:133: Test failed: wcex.style 00004008 make[1]: *** [atl_ax.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2014

Re: urlmon: Unregister window class on DLL unload.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -83,15 +83,50 @@ static LRESULT WINAPI notif_wnd_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM > return DefWindowProcW(hwnd, msg, wParam, lParam); > } > > +static const WCHAR wszURLMonikerNotificationWindow[] = > + {'U','R','L',' ','M','o','n','i','k','e','r',' ', > + 'N','o','t','i','f','i','c','a','t','i','o','n',' ','W','i','n','d','o','w',0}; > + > +static ATOM notif_wnd_class; > + > +static CRITICAL_SECTION notif_wnd_class_cs; > +static CRITICAL_SECTION_DEBUG notif_wnd_class_cs_dbg = { > + 0, 0, &notif_wnd_class_cs, > + { &notif_wnd_class_cs_dbg.ProcessLocksList, &notif_wnd_class_cs_dbg.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": notif_wnd_class") } > +}; > +static CRITICAL_SECTION notif_wnd_class_cs = { &notif_wnd_class_cs_dbg, -1, 0, 0, 0, 0 }; > + > +static BOOL ensure_notif_wnd_class(void) > +{ > + EnterCriticalSection(&notif_wnd_class_cs); > + > + if(!notif_wnd_class) { > + static WNDCLASSEXW wndclass = { > + sizeof(wndclass), 0, notif_wnd_proc, 0, 0, > + NULL, NULL, NULL, NULL, NULL, > + wszURLMonikerNotificationWindow, NULL > + }; > + > + wndclass.hInstance = hProxyDll; > + notif_wnd_class = RegisterClassExW(&wndclass); > + } > + > + LeaveCriticalSection(&notif_wnd_class_cs); > + > + return notif_wnd_class != 0; > +} You don't really need a whole new critical section for this. Just use InitOnce or interlocked functions. -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2014

Re: Converting source to unicode, bug 28189

by Akihiro Sagawa

On Thu, 13 Feb 2014 07:35:21 -0500, Hugh McMaster wrote: > I've put together a draft patch to address bug 28189, regsvr32: > No usage in wineconsole. > > I'm using resource strings and have converted all of the printf calls > to WriteConsoleW. > > I also converted the source to Unicode, but overall, there are few > coding points I'm not quite sure about. > > If someone could look over the changes and offer some feedback, > I'd certainly appreciate it. > > URL: http://bugs.winehq.org/show_bug.cgi?id=28189 Hello Hugh, Regarding your patch, attachment #47519, I roughly read the code and post comments at the following points: 1. Dead assignment: In output_write function, len and ret initial value will overwrite by function return value. You don't need to initialize them. 2. Memory leaking: if (!strA) is true, calling LocalFree(str) is necessary before return. 3. Usage indent: I'm not sure about STRING_USAGE and spaceSpaceW. Another command line tool, e.g. cmd.exe, doesn't do like this. Additionally, it might confuse po translators. 4. /I option handing: lstrcmpiW isn't compatible with strncasecmp. 5. Double quote handling: command_line is advanced when the code finds a double quote character. When it updates wsCommandLine? 6. Needless changes: `/**' -> `/*', pointer asterisk position, a space character after C-language keyword. Please follow surround coding style. 7. Silent handling: Many times, it refers Silent variable before calling output_write function. How about moving the check to the function? Hope these comments are helpful. Regards, Akihiro Sagawa

Feb. 13, 2014