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

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