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

Re: [PATCH] d2d1: Use transformed geometry to translate glyph run outline

by Henri Verbeet

On 28 October 2016 at 13:23, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/d2d1/render_target.c | 27 +++++++++++++++++++-------- > 1 file changed, 19 insertions(+), 8 deletions(-) > This is probably fine, but why would you want to do that?

Oct. 28, 2016

Re: [v2 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch

by Piotr Caban

On 10/28/16 13:49, Nikolay Sivov wrote: > On 28.10.2016 14:53, Piotr Caban wrote: >> A FIXME message would be probably also useful since the secure parameter >> is ignored. > > I'm not sure about that, every *sopen_s call will trigger it. I don't know what the secure parameter is meant to do without doing some testing but I don't like the fact that it's ignored without any sign in logs. I guess you have some more information about it, e.g. I don't know why *_s function are passing 1 there. Did you find any documentation for this function? Thanks, Piotr

Oct. 28, 2016

Re: [v3 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch

by Huw Davies

Signed-off-by: Huw Davies <huw(a)codeweavers.com>

Oct. 28, 2016

Re: [v2 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch

by Piotr Caban

On 10/28/16 13:41, Huw Davies wrote: > On Fri, Oct 28, 2016 at 01:43:19PM +0300, Nikolay Sivov wrote: >> diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c >> index 432d5c7..37e5ece 100644 >> --- a/dlls/msvcrt/file.c >> +++ b/dlls/msvcrt/file.c >> @@ -2144,9 +2144,10 @@ static int check_bom(HANDLE h, int oflags, BOOL seek) >> } >> >> /********************************************************************* >> - * _wsopen_s (MSVCRT.@) >> + * _wsopen_dispatch (UCRTBASE.@) >> */ >> -int CDECL MSVCRT__wsopen_s( int *fd, const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode ) >> +int CDECL MSVCRT__wsopen_dispatch( const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode, >> + int *fd, int secure ) >> { >> DWORD access = 0, creation = 0, attrib; >> SECURITY_ATTRIBUTES sa; > > You probably want to add 'secure' to the TRACE() just below here and > change the order of the parameters in that TRACE() to match the new > function. A FIXME message would be probably also useful since the secure parameter is ignored. Thanks, Piotr

Oct. 28, 2016

Re: [v2 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch

by Nikolay Sivov

On 28.10.2016 14:53, Piotr Caban wrote: > On 10/28/16 13:41, Huw Davies wrote: >> On Fri, Oct 28, 2016 at 01:43:19PM +0300, Nikolay Sivov wrote: >>> diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c >>> index 432d5c7..37e5ece 100644 >>> --- a/dlls/msvcrt/file.c >>> +++ b/dlls/msvcrt/file.c >>> @@ -2144,9 +2144,10 @@ static int check_bom(HANDLE h, int oflags, >>> BOOL seek) >>> } >>> >>> /********************************************************************* >>> - * _wsopen_s (MSVCRT.@) >>> + * _wsopen_dispatch (UCRTBASE.@) >>> */ >>> -int CDECL MSVCRT__wsopen_s( int *fd, const MSVCRT_wchar_t* path, int >>> oflags, int shflags, int pmode ) >>> +int CDECL MSVCRT__wsopen_dispatch( const MSVCRT_wchar_t* path, int >>> oflags, int shflags, int pmode, >>> + int *fd, int secure ) >>> { >>> DWORD access = 0, creation = 0, attrib; >>> SECURITY_ATTRIBUTES sa; >> >> You probably want to add 'secure' to the TRACE() just below here and >> change the order of the parameters in that TRACE() to match the new >> function. > > A FIXME message would be probably also useful since the secure parameter > is ignored. I'm not sure about that, every *sopen_s call will trigger it. > > Thanks, > Piotr > > >

Oct. 28, 2016

Re: [PATCH] winebus.sys: Remove dead code

by Aric Stewart

On 10/28/16 4:41 AM, Sebastian Lackner wrote: > It is dead code, but I don't think putting it in a comment makes it > better. In general, commented out code should be avoided because it is > not checked by the compiler. In addition, we might want to implement > driver unloading in the near future, and will have to add the code > back then (including the "if" because failures to create the monitor > are not critical). I am not sure what you are advocating for here. Leaving it as it is hoping that driver unloading is implemented soon? If so then I feel like I should write a full and proper unload function. Fully removing the code without comment bugs me because then we are loosing knowledge. In 1 month, 6 months, years when driver unloading is implemented the need to release the monitor will have to be remember/rediscovered. -aric > > 2016-10-28 3:00 GMT+02:00 Aric Stewart <aric(a)codeweavers.com>: >> >> Coverity 1373717 >> >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/winebus.sys/bus_udev.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> >> >> >> > >

Oct. 28, 2016

Re: [v2 PATCH] ucrtbase: Added _sopen_dispatch/_wsopen_dispatch

by Huw Davies

On Fri, Oct 28, 2016 at 01:43:19PM +0300, Nikolay Sivov wrote: > diff --git a/dlls/msvcrt/file.c b/dlls/msvcrt/file.c > index 432d5c7..37e5ece 100644 > --- a/dlls/msvcrt/file.c > +++ b/dlls/msvcrt/file.c > @@ -2144,9 +2144,10 @@ static int check_bom(HANDLE h, int oflags, BOOL seek) > } > > /********************************************************************* > - * _wsopen_s (MSVCRT.@) > + * _wsopen_dispatch (UCRTBASE.@) > */ > -int CDECL MSVCRT__wsopen_s( int *fd, const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode ) > +int CDECL MSVCRT__wsopen_dispatch( const MSVCRT_wchar_t* path, int oflags, int shflags, int pmode, > + int *fd, int secure ) > { > DWORD access = 0, creation = 0, attrib; > SECURITY_ATTRIBUTES sa; You probably want to add 'secure' to the TRACE() just below here and change the order of the parameters in that TRACE() to match the new function. Huw.

Oct. 28, 2016

Re: [PATCH] winebus.sys: Remove dead code

by Sebastian Lackner

It is dead code, but I don't think putting it in a comment makes it better. In general, commented out code should be avoided because it is not checked by the compiler. In addition, we might want to implement driver unloading in the near future, and will have to add the code back then (including the "if" because failures to create the monitor are not critical). 2016-10-28 3:00 GMT+02:00 Aric Stewart <aric(a)codeweavers.com>: > > Coverity 1373717 > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > >

Oct. 28, 2016

Re: Cmd.exe test cases

by Frédéric Delanoy

On Fri, Oct 28, 2016 at 2:51 AM, Carlos Rafael Ramirez <crramirez(a)gmail.com> wrote: > Hello, > > I want to add some test cases to cmd program. But I don't understand the > structure of them. Where to put the command and where to put the assertion > or expected output? > > I am coding a patch and I want to make it like TDD, first the test fail and > after the fix the test passes. > > Thank you Hi Carlos, Tests for builtins go to test_builitins.cmd (commands) and test_builtins.cmd.exp (expected results) test_cmdline.cmd[.exp] is for command line cmd usage, so not what you want here. make crosstest can be used to create a win executable for testing on native. For more information, see https://wiki.winehq.org/Cmd_Conformance_Tests Regards, Frédéric Delanoy

Oct. 28, 2016

Cmd.exe test cases

by Carlos Rafael Ramirez

Hello, I want to add some test cases to cmd program. But I don't understand the structure of them. Where to put the command and where to put the assertion or expected output? I am coding a patch and I want to make it like TDD, first the test fail and after the fix the test passes. Thank you

Oct. 28, 2016