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

Re: [PATCH 3/7] d3d9/tests: Test messages on focus loss (v3).
by Henri Verbeet Oct. 6, 2014

Oct. 6, 2014

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 Oct. 6, 2014

Oct. 6, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 6, 2014

Oct. 6, 2014

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 Oct. 6, 2014

Oct. 6, 2014

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 Oct. 6, 2014

Oct. 6, 2014

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 Oct. 5, 2014

Oct. 5, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 5, 2014

Oct. 5, 2014

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 Oct. 5, 2014

Oct. 5, 2014

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 Oct. 4, 2014

Oct. 4, 2014

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 Oct. 4, 2014

Oct. 4, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 4, 2014

Oct. 4, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 3, 2014

Oct. 3, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 3, 2014

Oct. 3, 2014

> 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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=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 Oct. 2, 2014

Oct. 2, 2014

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

1 0

Re: msvcrt: Make the first call to fwrite bufferred (try2)
by Andreas Fuchs Oct. 2, 2014

Oct. 2, 2014

Hi Piotr, Hi all, I traced down this commit as the origin of the regression, where I cannot parse stdout of wine correctly anymore. See also https://bugs.winehq.org/show_bug.cgi?id=37345 I hope, sombody knowledgable (Piotr maybe you as the author) could help me figure this out or even provide a fix... Description: When calling wine from another process after redirecting stdout to a pipe, wine does not flush the stdout-buffer correctly anymore (Wine 1.6 did correctly). Attached is a usecase. To test do: i686-w64-mingw32-gcc helloworld.c gcc callwine.c ./a.out What will happen is: - on a buggy wine it will take 10 seconds and then all of the stdout-buffer is flushed on the exit of the child. (imagine the child would run longer than the 10 seconds) - on a good wine we will see some stdout-content then 10 second sleep and then the rest of the content. This is a regression that happened between 1.7.4 and 1.7.5. The bisect identified commit afec0b00bd6250fe21e8deccbc8116a4aca6a7a4 "msvcrt: Make the first call to fwrite buffered." as problem. The attached patch is a revert of this commit ported forward to 1.7.27. Unfortunately I don't quite grasp the logics of the offending commit. If somebody who knows that patch could help, I'd highly appreciate it. Cheers, Andreas

3 2

Re: [PATCH 1/3] comctl32: Move TaskDialogIndirect function to separate file
by Nikolay Sivov Oct. 2, 2014

Oct. 2, 2014

On 10/1/2014 16:35, Joachim Priesner wrote: > +#include <stdarg.h> > +#include <string.h> > + > +#include "comctl32.h" > +#include "shlwapi.h" > + > +#include "windef.h" > +#include "winbase.h" > +#include "wingdi.h" > +#include "winternl.h" > +#include "dlgs.h" > +#include "wine/debug.h" > +#include "wine/unicode.h" It's unlikely you need all of those. > +#define TD_WARNING_ICON MAKEINTRESOURCEW(-1) > +#define TD_ERROR_ICON MAKEINTRESOURCEW(-2) > +#define TD_INFORMATION_ICON MAKEINTRESOURCEW(-3) > +#define TD_SHIELD_ICON MAKEINTRESOURCEW(-4) Where this comes from? I mean particular id values.

2 2

Re: [PATCH 1/6] user32/tests: Test minimizing an unminimizable window.
by Dmitry Timoshkov Oct. 2, 2014

Oct. 2, 2014

Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This shows that the abesence of a minimization button does not prevent > the application from programmatically minimizing the window. KWin and > fvwm behave like Windows in this regard, whereas Metacity-based WMs > prevent the minimization. My understanding is that not the absence of minimize/maximize button prevents an ability to programmatically minimize/maximize a window, but an item in the system menu. I'd suggest to also add a test for sending WM_SYSCOMMAND/SC_MINIMIZE/SC_MAXIMIZE behaviour. -- Dmitry.

2 2

Re: [PATCH 6/6] d3d8/tests: Test messages on focus loss (v2).
by Marvin Oct. 1, 2014

Oct. 1, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=9170 Your paranoid android. === w8 (32 bit device) === device.c:2325: Test failed: Expected message 0x6 for window 0x1, but didn't receive it. device.c:2330: Test failed: The focus window is active. device.c:2336: Test failed: Got unexpect width 640. device.c:2337: Test failed: Got unexpect height 480. device.c:2477: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:3119: Test failed: Expected wndproc 0x413050, got 0x413050.

2 1