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. 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=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

Re: [PATCH 1/6] user32/tests: Test minimizing an unminimizable window.
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=9167 Your paranoid android. === w7u (32 bit msg) === msg.c:12149: Test failed: unexpected hwnd 0017014A msg.c:12171: Test failed: bad time 3077e/3078e

2 1

Re: [2/4] server: Support sending process and thread security descriptors for the "new_process" request in the protocol.
by Alexandre Julliard Oct. 1, 2014

Oct. 1, 2014

Joris van der Wel <joris(a)jorisvanderwel.com> writes: > + if (req->process_sd_size > get_req_data_size() || > + req->thread_sd_size > get_req_data_size() - req->process_sd_size || > + req->info_size > get_req_data_size() - req->process_sd_size - req->thread_sd_size) > + { > + close( socket_fd ); > + return; > + } You have to return an error. > + req_info = (const startup_info_t *) > + ((char*)get_req_data() + req->process_sd_size + req->thread_sd_size); > + req_env = (const WCHAR *) > + ((char*)get_req_data() + req->process_sd_size + req->thread_sd_size + req->info_size); > + req_env_size = get_req_data_size() - (req->process_sd_size + req->thread_sd_size + req->info_size); These may not be valid pointers (alignment is not checked) so it would be better to avoid declaring them as variables. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine Gecko 2.34-beta1 release
by Jacek Caban Oct. 1, 2014

Oct. 1, 2014

Hi all, After about a year since the last release, I'm happy to announce that we have a new Wine Gecko packages ready for testing. I'm not attaching a patch this time, because it's quite big and will change over next few weeks (I will be submitting some of those changes, so the patch would be invalid soon). I set up a Wine fork at [1] instead. It contains snapshot of my development tree on top of Wine, so be prepared for forced updates. Let me know if you'd prefer it to be in a different form. This update catches up on development made for 10 Firefox releases that happened meantime. There were many problems that needed to be solved for this to happen. There were tree wide changes breaking our build config as well as API changes, that needed to be fixed. We still have long term problem with API that we use for embedding Gecko (mostly DOM APIs) that is slowly removed from Gecko. We need a long term solution, which means working on auto generated C/C++ bindings based on the new, WebIDL files. I may write a separated mail about that if there is an interest. I decided to make this beta from Gecko tip at the point where it's branched. I usually waited until Gecko enters beta, but I want to catch up on development as much as possible this time. How the final release will look like depends on how testing goes. It will not be sooner than after a bit of Firefox beta. As usually, everything that uses MSHTML is an interesting testing target. Let me know if there are any problems. Thanks, Jacek [1] http://repo.or.cz/w/wine/wine-gecko.git

2 3

Re: [PATCH 4/5] d3d9/tests: Add a test for vs_3_0 shaders using more than 256 constants.
by Stefan Dösinger Oct. 1, 2014

Oct. 1, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-09-30 14:51, schrieb Matteo Bruni: > --- > dlls/d3d9/tests/device.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) I think it would be a good idea to check the behavior of d3d9ex. It may lift some restrictions of plain d3d9. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUK+z6AAoJEN0/YqbEcdMwrrsP/1aU53A4nN8vmohZ4KtnKs42 DYvnr1cJxCjRCTM9c8xcH4t1FAMcbIy0HTygQNrvifvYBZbGqSmkA3vArIRxsIeK t5vSlAFvV14sWi4krsw+sRLzsYtpe1LWji9AW6DpzheJDNl2eaE2oxFRhloPv/KE 9d2O3x/9g0ww/231drtc6RxL5kd7cFs15XKw1LnawurxOB79McuEFkt75OEOFpB6 7wlzQdhe9PI0uiluxhXfKqLF3EehBR4j2KAYQO5O8KpFLMObSUJrdwhvc6Fmlwtb t6vH20mDewuCJF6fliCKyLpM4ujnxuwmBz5sl6D50javzknqX2kzG5PX6jnj8ezR iSBoGZJMY/B+UKKMHgJNzgbP6g3X7LICAs7lBlfuiTdVau+YvUf+8JiNoCkF7NFO aXPuVt/rJ+4k5Q5ZFCq9Vt7dmy9gtJGM8ZJw4z30Nz0v16LSRFQHMfBaqco3HCib todvTsy1/bLwrA6k+ANvWWwJmqKHaLIFm7ZcEZNi5cMxNtAKKHbyPzN19syhFuVU gxlqVtTuB/yT+3Kd7G+1pH2Wr7NZNG1szJfQLVS4ns4PXBtbarINDCYW2fUpfvS6 bpzMjYzWe0ePGN58XRCVqrptx7q6IW3GLueJYq5zSHsRRmawwQx1xJBTA0qAqq7I GworiiALSOo3MMD4YZb+ =42bF -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/5] jscript: Added support for '-' CC expression.
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=9163 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/5] jscript: Added tests for @if/@elif/@else/@end.
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=9160 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: dpnet: Implement IDirectPlay8Address GetComponentByName (try 2)
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=9156 Your paranoid android. === w8 (32 bit address) === Failure running script in VM: timed out waiting for the child process

1 0

DirectPlay
by Michael Müller Oct. 1, 2014

Oct. 1, 2014

Hello Alistair, I am watching your DirectPlay patches for some time and I am very happy that you haven't yet given up implementing it. Most of the Wine developers do not really care much about DirectPlay since there is an easy workaround and no modern game makes use of it. Just today I wrote a fix for a multiplayer lobby client for Age of Empires 2 which also makes use of DP ( https://bugs.winehq.org/show_bug.cgi?id=29384 ). Although using the Windows 98 dlls works, I think it is important for ordinary wine users that it works out of the box. Sometimes Wine is not really that user friendly and I think it is important to enhance these parts to improve the image of wine. Not everybody is searching through the AppDB or bugtracker, instead most people give up if it does not work out of the box. For this reason I am contributing to a project called wine-compholio ( https://github.com/compholio/wine-compholio ) which collects correct patches that did not get upstream because AJ did not like them for some reason (although they were correct) or they didn't get any attention and dropped out of the queue. The idea is to use this project as staging tree and to improve these patches till wine accepts them. We also add our own patches there before we send them upstream so that other people can review and test them. This makes fixes/patches faster available to users as for example Fedora applies all our patches to their wine build. Moreover often developers review your patches before you send them to Wine devel. This makes it easier to get patches upstream since the chance that they contain a critical errors is much lower. If you think this might also help your patches, you can find us in #pipelight / #wine-compholio on FreeNode. However, I just wanted to say thank you that you are still working on DP. Regards, Michael Müller

1 0