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

Re: [PATCH] schannel_gnutls: when calling pgnutls_server_name_set ensure that the values are sane

by Jacek Caban

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

March 27, 2015

[BISECTED REGRESSION] file dialog does not shown

by Andrey Skvortsov

Hi, original problem is described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I have the same problem with running Nanocad 5.1. The file open/import dialog does not open with wine-1.7.39. I bisected the problem to commit: [bbf2cce16041e90d621a1f5889ea1bd760e21a0e] comdlg32: Do not modify dialog resource directly. I reverted this commit on latest wine and that fixed my issue with file open dialog. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

March 27, 2015

[BISECTED REGRESSION] icons in nanocad have black background

by Andrey Skvortsov

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

March 27, 2015

RE: [PATCH] wineconsole: Set input stream buffer length per OS limit

by Hugh McMaster

On Thu, 26 Mar 2015 15:22:33 +0100, Stefan Dösinger wrote: > Am 2015-03-26 um 13:58 schrieb Hugh McMaster: > > The Windows command line (cmd or command.com) limits the maximum > > length of an input string. [1] > Do we care about this? Do you have an application that depends on this > kind of limit? Wineconsole currently has fixed buffer of 256 chars. Any input from a terminal that is longer than 256 bytes is truncated. (See also bug 34814.) It is easy to test this with a (deliberately) small buffer, say 32 chars, by altering line 833 in programs/wineconsole/wineconsole.c. Then with a test program: ./wine wineconsole cmd /k ../c.exe -abc -def -ghi -jkl strlen(wci.ptr): 35, malloc'ed: 32 WCHARs [strlen only reads from 'cmd' onwards] input: cmd /k ../c.exe -abc -def -ghi -jkl GetLastError(): 122 [MultiByteToWideChar error: The data area passed to a system call is too small.] lstrlenW(buffer): 32 output: cmd /k ../c.exe -abc -def -ghi - [32 characters. 'jkl' is missing]

March 27, 2015

Re: [PATCH 5/6] wined3d: Introduce a shader_snprintf() function.

by Henri Verbeet

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.

March 27, 2015

RE: [PATCH] cmd: Add basic handling of Ctrl-C

by Hugh McMaster

On Thu, 26 Mar 2015 15:15:34 +0100, Stefan Dösinger wrote: > Am 2015-03-26 um 13:46 schrieb Hugh McMaster: > > The PHANDLER_ROUTINE is a pointer to the function handler. MSDN's > > own example [1] on installing a Ctrl handler uses a cast. > > > > Otherwise, what would you suggest? > If the function signature (including calling convention) matches the > one SetConsoleCtrlHandler expects the compiler should accept it > without a cast and without a warning. > > In your patch you should probably use WINAPI for console_ctrl_handler. The compiler accepted "BOOL WINAPI console_ctrl_handler" without warnings. Thanks. I'll send a new patch.

March 27, 2015

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo

by Piotr Caban

> 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. I'll send a test that shows the lack of inheritance in NtSetSecurityObject. Of course it's not a problem in the API, if we have rights to change the permissions we can do whatever we want anyway. >> 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. I don't think complete support for storing security descriptors needs to be done first. This is the step in correct direction. Thanks, Piotr

March 27, 2015

Re: [PATCH 1/5] include: Add Wine-specific theming hook struct to winuser.h

by Alexandre Julliard

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

March 27, 2015

Re: [PATCH] comctl32: Redraw themed button on WM_ENABLE.

by Alexandre Julliard

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

March 27, 2015

Re: winegcc & stdin

by Ruslan Kabatsayev

Hi, On Fri, Mar 27, 2015 at 1:54 AM, Leon Bogaert <leonbogaert(a)gmail.com> wrote: > I'm getting an error when using winegcc with stdin: > >> >> $ cat test.c | winegcc -xc -c - >> gcc: warning: ‘-x c’ after last input file has no effect >> gcc: error: -E or -x required when input is from standard input >> winegcc: gcc failed > > > Does anyone know what I could be doing wrong? I'm trying to use stdin > because that's what the go (cgo) build tool is trying to use. I think it's not you who does something wrong, it's winegcc which runs gcc a bit wrongly. If you look at gcc command line arguments, you'll get something like -fshort-wchar -DWINE_UNICODE_NATIVE -D_REENTRANT -fPIC -DWIN64 -D_WIN64 -D__WIN64 -D__WIN64__ -DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WINNT -D__WINNT__ -D__stdcall=__attribute__((ms_abi)) -D__cdecl=__attribute__((ms_abi)) -D_stdcall=__attribute__((ms_abi)) -D_cdecl=__attribute__((ms_abi)) -D__fastcall=__attribute__((ms_abi)) -D_fastcall=__attribute__((ms_abi)) -D__declspec(x)=__declspec_##x -D__declspec_align(x)=__attribute__((aligned(x))) -D__declspec_allocate(x)=__attribute__((section(x))) -D__declspec_deprecated=__attribute__((deprecated)) -D__declspec_dllimport=__attribute__((dllimport)) -D__declspec_dllexport=__attribute__((dllexport)) -D__declspec_naked=__attribute__((naked)) -D__declspec_noinline=__attribute__((noinline)) -D__declspec_noreturn=__attribute__((noreturn)) -D__declspec_nothrow=__attribute__((nothrow)) -D__declspec_novtable=__attribute__(()) -D__declspec_selectany=__attribute__((weak)) -D__declspec_thread=__thread -D__int8=char -D__int16=short -D__int32=int -D__int64=long -D__WINE__ -c - -xc -isystem/usr/include/wine/windows Notice that '-xc' has moved after '-c -'. Maybe this should be considered a bug of winegcc. > > Leon > > > Ruslan

March 27, 2015