September 2015 - Wine-devel

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.
by Ken Thomases 30 Sep '15

30 Sep '15

On Sep 30, 2015, at 2:53 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > dlls/user32/driver.c | 16 ++++++++++++++-- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 1 + > dlls/winex11.drv/window.c | 29 +++++++++++++++++++++++++++++ > dlls/winex11.drv/winex11.drv.spec | 1 + > dlls/winex11.drv/x11drv.h | 1 + > dlls/winex11.drv/x11drv_main.c | 1 + > 7 files changed, 48 insertions(+), 2 deletions(-) Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? -Ken

2 2

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)
by Piotr Caban 30 Sep '15

30 Sep '15

Hi, On 09/07/15 16:21, YongHao Hu wrote: > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ > +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* err_code, enum file_type* type) > +{ > + HANDLE handle; > + WIN32_FIND_DATAA data; > + char temppath[MAX_PATH]; > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); > + strcpy(temppath, dest); > + strcat(temppath, "\\*.*"); Is native limiting the path to MAX_PATH characters? What happens if longer path is passed? > + handle = FindFirstFileA(temppath, &data); > + if(handle == INVALID_HANDLE_VALUE) { > + if(GetLastError() == ERROR_PATH_NOT_FOUND) > + *err_code = ERROR_BAD_PATHNAME; > + else > + *err_code = GetLastError(); This doesn't look right. Probably some other function is returning different error on windows and on wine (or different function is used internally). Anyway I don't think we need to be compatible here (at least as long as there's no application that depends on it). > + while(!strcmp(data.cFileName, ".") || !strcmp(data.cFileName, "..")) { > + if(!FindNextFileA(handle, &data)) { > + *err_code = ERROR_SUCCESS; > + *type = status_unknown; > + return NULL; You're leaking handle here. Thanks, Piotr

2 2

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.
by Marvin 30 Sep '15

30 Sep '15

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=16898 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban 29 Sep '15

29 Sep '15

On 09/21/15 15:08, Martin Storsjo wrote: > if(d>MSVCRT_UI64_MAX/10 || hlp<d) { Please also update overflow checking rules (use base instead of 10). > +static void test_strtod(void) > +{ > + test_strtod_str("infinity", INFINITY, 8); > + test_strtod_str("INFINITY", INFINITY, 8); > + test_strtod_str("InFiNiTy", INFINITY, 8); > + test_strtod_str("INF", INFINITY, 3); > + test_strtod_str("-inf", -INFINITY, 4); > + test_strtod_str("inf42", INFINITY, 3); > + test_strtod_str("inffoo", INFINITY, 3); > + test_strtod_str("infini", INFINITY, 3); > + > + test_strtod_str("NAN", NAN, 3); > + test_strtod_str("nan", NAN, 3); > + test_strtod_str("NaN", NAN, 3); > + > + test_strtod_str("0x42", 66, 4); > + test_strtod_str("0X42", 66, 4); > + test_strtod_str("-0x42", -66, 5); > + test_strtod_str("0x1p1", 2, 5); > + test_strtod_str("0x1P1", 2, 5); > + test_strtod_str("0x1p+1", 2, 6); > + test_strtod_str("0x2p-1", 1, 6); > + test_strtod_str("0xA", 10, 3); > + test_strtod_str("0xa", 10, 3); > + test_strtod_str("0xABCDEF", 11259375, 8); > + test_strtod_str("0Xabcdef", 11259375, 8); > + > + test_strtod_str("0x1.1", 1.0625, 5); > + test_strtod_str("0x1.1p1", 2.125, 7); Could you please also add few more tests, like: test_strtod_str("0x1.A", ...); /*to show that part after decimal point is correctly handling hexadecimal digits */ test_strtod_str("0x1p1a", ...); /* to show that exponential part is not handling hexadecimal digits */ Thanks, Piotr

2 1

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.
by Nikolay Sivov 29 Sep '15

29 Sep '15

On 29.09.2015 10:27, Ken Thomases wrote: > If the client requests a bold typeface of a font which doesn't actually provide > a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes > italic by apply a shear transform. > > These techniques work passably when antialiasing is in effect. However, when > antialiasing is disabled at small sizes by the font's GASP table, the results > are horrible. The glyphs have many spurs or appear furry. > > On the theory that fonts disable antialiasing via the GASP table at small sizes > because hinting should produce pixel-perfect results and that that rationale is > voided by the application of procedural bolding or italicizing, we ignore the > GASP table and always antialias for fake bold or italic fonts. Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself. > > There is a new registry setting to disable this and revert to the previous > behavior: > > [HKEY_CURRENT_USER\Software\Wine\Fonts] > "AntialiasFakeBoldOrItalic"="n" What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com>

2 2

Migrating away from Sourceforge
by Austin English 29 Sep '15

29 Sep '15

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.
by Marvin 28 Sep '15

28 Sep '15

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=16895 Your paranoid android. === w1064 (32 bit device) === device.c:2612: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2617: Test failed: The focus window is active. device.c:2625: Test failed: Got unexpected hr 0x88760869. device.c:2631: Test failed: Got unexpect screen size 1152x870. device.c:2646: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=2. device.c:2655: Test failed: Got unexpect screen size 1152x870. device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2676: Test failed: Got unexpect width 1152. device.c:2677: Test failed: Got unexpect height 864.

1 0

Re: ieframe: add a better toolbar bitmap
by Jacek Caban 28 Sep '15

28 Sep '15

Hi Jared, On 09/26/15 20:02, Jared Smudde wrote: > --- > dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes > 1 files changed, 0 insertions(+), 0 deletions(-) That file is generated from ietoolbar.svg, so it's the SVG file that should be changed. You may enable generating those file in your build with --enable-maintainer-mode configure option. Thanks, Jacek

2 1

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.
by Michael Müller 28 Sep '15

28 Sep '15

Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: > From: Michael Müller <michael(a)fds-team.de> > > For https://bugs.winehq.org/show_bug.cgi?id=34558 > > Depending on the compiler optimization flags there is still no guarantee that > everything will fit into the available stack space, no matter if its declared > as static or not. As suspected the idea does not work for all optimization levels. At least GCC merges the content of the functions when using -O2 and therefore reintroduces the problem - even __attribute__ ((noinline)) is not sufficient. As most distributions compile Wine with -02, I would suggest to ignore the patch for now. Maybe we can come up with a more general solution.

2 1

Re: msadpcm32.acm: Stop converting data instead of crashing
by Andrew Eikum 28 Sep '15

28 Sep '15

On Sun, Sep 27, 2015 at 12:42:42AM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > Tomb Raider 3 uses a single archive with all wav files inside, when > playing some specific sounds it passes incorrect lengths of data that > reach the next wav file header. This causes an assert in the code that > is now gracefully handled. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=21000 > diff --git a/dlls/msadp32.acm/msadp32.c b/dlls/msadp32.acm/msadp32.c > index 2c61575..0924163 100644 > --- a/dlls/msadp32.acm/msadp32.c > +++ b/dlls/msadp32.acm/msadp32.c > @@ -249,9 +249,17 @@ static void cvtSSms16K(const ACMDRVSTREAMINSTANCE *adsi, > { > const unsigned char* in_src = src; > > - assert(*src <= 6); > + /* Catch a problem from Tomb Raider III (bug 21000) where it passes > + * invalid data after a valid sequence of blocks */ > + if (*src > 6 || *(src + 1) > 6) > + { > + /* Recalculate the amount of used output buffer. We are not changing > + * nsrc, let's assume the bad data was parsed */ > + *ndst -= nblock * nsamp_blk * adsi->pwfxDst->nBlockAlign; > + ERR("Invalid ADPCM data, stopping conversion\n"); Looks reasonable, thanks. I think you should change that message to a WARN. Audio methods are often called thousands of times per second, so spamming an ERR can be very obnoxious. Andrew

3 3