March 2015 - Wine-devel - list.winehq.org

[BISECTED REGRESSION] icons in nanocad have black background
by Andrey Skvortsov 27 Mar '15

27 Mar '15

Hi, The issue was originally described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I bisected both issues, but I'll create separate thread to the issue with file dialog. First bad commit that causes black background on icons is: [ b81a7d976e3c3de36a01401d125871d3014e6c67 ] gdi32: Always use the DIB engine for monochrome bitmap rendering. To see how the issue looks like, I attached small screenshots. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Marvin 27 Mar '15

27 Mar '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=12462 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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] schannel_gnutls: when calling pgnutls_server_name_set ensure that the values are sane
by Jacek Caban 27 Mar '15

27 Mar '15

Hi Nikos, On 03/27/15 17:25, Nikos Mavrogiannopoulos wrote: > This patch addresses issue with schan_imp_set_session_target() > translation to gnutls API. It does not pass invalid (null) parameters to > it, as this seems to cause issues. Addresses > https://bugs.winehq.org/show_bug.cgi?id=38134 Take a look at schan_imp_set_session_target caller in schannel.c. It already ensures that passed target is not NULL. If your patch indeed fixes a real problem, it's probably because it also ignores an empty string. That's, however, something that should also be done on caller side. Thanks, Jacek

1 0

Re: [PATCH] wineconsole: Set input stream buffer length per OS limit
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > --- > programs/wineconsole/wineconsole.c | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) > > diff --git a/programs/wineconsole/wineconsole.c b/programs/wineconsole/wineconsole.c > index 3c2faf5..81300ed 100644 > --- a/programs/wineconsole/wineconsole.c > +++ b/programs/wineconsole/wineconsole.c > @@ -797,6 +797,11 @@ static UINT WINECON_ParseOptions(const char* lpCmdLine, struct wc_init* wci) > return 0; > } > > +#define MAXSTRING_NON_NT 128 > +#define MAXSTRING_NT351 260 > +#define MAXSTRING_NT4_W2K 2048 > +#define MAXSTRING_XP 8192 > + Why do you need this mess?

3 3

Re: [PATCH 5/6] wined3d: Introduce a shader_snprintf() function.
by Henri Verbeet 27 Mar '15

27 Mar '15

On 26 March 2015 at 20:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It could be used in more places, some of them need additional rework > though. > I'm not sure this is what you had in mind. I didn't feel like making > these strings heap allocated, it seems to get quite ugly that way. It's not quite fully worked out at this point, but what I have in mind is roughly to use wined3d_shader_buffer. The shader_glsl_priv structure can then keep a list of scratch buffers from which you can get one to construct these kinds of intermediate strings and release back to when you're done with them. It would probably also involve cleanup functions for e.g. glsl_src_param and glsl_dst_param at some point. In principle this patch is in the right direction, but I'd rather avoid putting this in now and then having to change it again later.

1 0

Re: [PATCH] cmd: Add basic handling of Ctrl-C
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > + /* Enable handling of Ctrl-C signals */ > + if (SetConsoleCtrlHandler((PHANDLER_ROUTINE)console_ctrl_handler, TRUE)) > + WINE_TRACE("cmd: Ctrl handler was installed.\n"); > + else > + WINE_ERR("cmd: Unable to install Ctrl handler.\n"); > + Judging by the fact that you needed a cast, that's not right.

3 3

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo
by Erich E. Hoover 27 Mar '15

27 Mar '15

On Thu, Mar 26, 2015 at 2:59 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > On Thu, Mar 26, 2015 at 12:10 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> ... >> The inheritance doesn't occur when function from ntdll are used for setting >> DACL. This makes your code inside server incorrect. Also your code is not >> checking handle permissions correctly. If you try to test it keep in mind >> that if correct inheritance flags are set in security descriptor control >> field the permissions will be filled when you right-click on file and >> display security properties on windows. > > I don’t have the time to write a test at the moment, but I find it > highly unlikely that MS would implement security descriptors in a > high-level DLL. If that were the case then an application could > easily hijack the API in order to permit access to files that would > otherwise be inaccessible. I would guess that > UNPROTECTED_DACL_SECURITY_INFORMATION and SE_DACL_AUTO_INHERITED > probably enter into this somehow. > > Besides that I think we should start implementing stored ACLs first, > before even thinking about implementing suitable inheritance > mechanisms. I submitted a bunch of patches for this some time ago, > but Alexandre wasn’t happy with using extended user attributes to > store this information. I’m just not sure that it’s useful to > implement inheritance without storing the ACLs, it’ll certainly fix > some apps but it will likely break a bunch of others. Whoops, forgot reply-all - sorry for the duplicate Piotr. Best, Erich

2 1

Re: [PATCH 1/5] include: Add Wine-specific theming hook struct to winuser.h
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > @@ -4060,6 +4060,15 @@ WORD WINAPI SYSTEM_KillSystemTimer( WORD ); > WINUSERAPI BOOL CDECL __wine_send_input( HWND hwnd, const INPUT *input ); > #endif > > +/* Wine-specific version of the undocumented structs > + * used by uxtheme to hook into user32. */ > + > +typedef struct > +{ > + WNDPROC DefWindowProcA; > + WNDPROC DefWindowProcW; > +} WINEUSERAPIHOOK; This doesn't belong in winuser.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Redraw themed button on WM_ENABLE.
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > When a themed button received a WM_ENABLE message, comctl32 redraws it, > then passes the message to the parent proc in user32. Unfortunately, this > is the wrong way round - as user32 redraws the window itself, the themed > button will be redrawn as its unthemed counterpart. It sounds like it's only hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] vbscript: Implemented Oct
by Marvin 27 Mar '15

27 Mar '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=12441 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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

2 1