January 2012 - Wine-Devel - list.winehq.org

Release plans

by Alexandre Julliard

Happy New Year to everyone! As you probably know, 2012 will be the year when we release 1.4. I know I already said this last year, but this time I mean it... The release features are in good shape now, and the plan is to enter code freeze as soon as the DIB engine can be considered done, which should be Real Soon Now. At this point it looks like there will be a 1.3.37 release (if only because that's a fun release number...), but it's likely that the release after that will be 1.4rc1. This means that if there are changes you want to get in before code freeze, they need to be done in the next 3 weeks or so. I'm thinking in particular of the audio changes that people have been discussing. Now would also be a good time to look for your name on the Regression Hall of Shame (http://source.winehq.org/regressions) and see if you can do something to bring your count down, as I expect the counts will go up again once rc1 is out and users start testing it. And if you don't have any regressions to your name, feel free to tackle some of mine ;-) -- Alexandre Julliard julliard(a)winehq.org

Jan. 2, 2012

Re: new d3d9/device.ok test always fails here, but not a regression?

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > On Sun, Jan 1, 2012 at 6:32 PM, Austin English <austinenglish(a)gmail.com> wrote: >> That _particular_ test never worked, so it's not a regression. A code >> change in d3d itself that broke a previously working test/application >> would be a valid regression. > > IMHO a code change in a d3d test that broke a previously working > "make test" also counts as a regression. > > The test suite is *important*. Breakage in the test suite is not trivial. Obviously it's important, and we have an importance field in bugzilla for that. But the regression keyword has a specific meaning: there has to be a piece of code that worked and then got broken. Bugs in newly added code cannot be regressions. Similarly, if we add a dll and some app starts using it and breaks, technically that's not a regression even though the behavior got worse, because it has always been broken, it just wasn't exercised before. -- Alexandre Julliard julliard(a)winehq.org

Jan. 2, 2012

Re: [PATCH] jscript: functions that return -1 should have signed return (Coverity)

by Jacek Caban

Hi Marcus, On 12/31/11 15:43, Marcus Meissner wrote: > Hi, > > Side issue of CID 5504. > > Ciao, Marcus > --- > dlls/jscript/compile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/jscript/compile.c b/dlls/jscript/compile.c > index 60b0c2e..96497b6 100644 > --- a/dlls/jscript/compile.c > +++ b/dlls/jscript/compile.c > @@ -146,7 +146,7 @@ static BSTR compiler_alloc_bstr(compiler_ctx_t *ctx, const WCHAR *str) > return ctx->code->bstr_pool[ctx->code->bstr_cnt++]; > } > > -static unsigned push_instr(compiler_ctx_t *ctx, jsop_t op) > +static int push_instr(compiler_ctx_t *ctx, jsop_t op) > { > assert(ctx->code_size>= ctx->code_off); > > @@ -328,7 +328,7 @@ static HRESULT compile_member_expression(compiler_ctx_t *ctx, member_expression_ > > #define LABEL_FLAG 0x80000000 > > -static unsigned alloc_label(compiler_ctx_t *ctx) > +static int alloc_label(compiler_ctx_t *ctx) > { > if(!ctx->labels_size) { > ctx->labels = heap_alloc(8 * sizeof(*ctx->labels)); This patch just moves the problem around by introducing a lot of int to unsigned int assignments. Introducing something like INVALID_HANDLE_VALUE would solve the problem here, but I've sent more widespread changes that will fix this problem as well. Thanks, Jacek

Jan. 2, 2012

re: PVS-Studio run against ReactOS: (at least) one bug in wine git

by Dan Kegel

Hey, cool! I added that to http://wiki.winehq.org/StaticAnalysis I figured I'd try running PVS-Studio on the Wine sources in Wine, but it runs in the Visual Studio context, and I can't even load the wine project successfully under warn+heap; see http://bugs.winehq.org/show_bug.cgi?id=29509 (It'd be awesome if we could build wine with visual studio 2005, not only to use it with PVS-Studio, but just for the sake of self-hosting.)

Jan. 2, 2012

Re: new d3d9/device.ok test always fails here, but not a regression?

by Dan Kegel

On Sun, Jan 1, 2012 at 6:32 PM, Austin English <austinenglish(a)gmail.com> wrote: >> http://bugs.winehq.org/show_bug.cgi?id=29094 >> Henri removed the regression keyword and sha1sum without comment. >> >> What's the reasoning there? Is Henri saying there's >> something wrong with my test setup (stock ubuntu), >> or are new tests that cause 'make test' to fail not considered regressions? >> Or something else? > > That _particular_ test never worked, so it's not a regression. A code > change in d3d itself that broke a previously working test/application > would be a valid regression. IMHO a code change in a d3d test that broke a previously working "make test" also counts as a regression. The test suite is *important*. Breakage in the test suite is not trivial. - Dan

Jan. 2, 2012

Re: new d3d9/device.ok test always fails here, but not a regression?

by Austin English

On Sat, Dec 31, 2011 at 11:43, Dan Kegel <dank(a)kegel.com> wrote: > Happy New Year's Eve, everyone! > > 002447357c2b1feca5ef2649429fc55f70238901 > added a IDirect3DDevice9::SetCursorPosition() test to d3d9. > That test never worked here, I think. I filed > http://bugs.winehq.org/show_bug.cgi?id=29094 > for it, and marked it as a regression (since > tests/device.c used to pass, but fails here > after that commit). > > Henri removed the regression keyword and sha1sum without comment. > > What's the reasoning there? Is Henri saying there's > something wrong with my test setup (stock ubuntu), > or are new tests that cause 'make test' to fail not considered regressions? > Or something else? That _particular_ test never worked, so it's not a regression. A code change in d3d itself that broke a previously working test/application would be a valid regression. -- -Austin

Jan. 2, 2012

Strange comdlg32 resource string

by Francois Gouget

André Hentschel pointed me to a strange cmdlg32 resource string: IDS_ABOUTBOX "&About FolderPicker Test" The text seems unlikely to be correct. IDS_ABOUTBOX was introduced in 87b81de0 but was not used even in that patch and as far as I can see it is still not used by Wine. Looking at the Windows comdlg32 dll I see no string resource (but that mostly make me suspicious of the tool I used). Furthermore, none of the other strings in that string table seem to be used either: IDS_DOCUMENTFOLDERS "Document Folders" IDS_PERSONAL "My Documents" IDS_FAVORITES "My Favorites" IDS_PATH "System Path" IDS_DESKTOP "#msgctxt#display name#Desktop" IDS_FONTS "Fonts" IDS_MYCOMPUTER "My Computer" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Jan. 1, 2012