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

Re: [6/6] oleaut32/tests: Add a bunch of new tests for typelib generation.
by Marvin Oct. 26, 2015

Oct. 26, 2015

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=17373 Your paranoid android. === build (build) === Make failed

3 2

Re: d3dx9: Add adjacency generation for D3DXCreateCylinder()
by Matteo Bruni Oct. 26, 2015

Oct. 26, 2015

2015-10-26 14:33 GMT+01:00 Gediminas Jakutis <gediminas(a)varciai.lt>: > --- > dlls/d3dx9_36/mesh.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) Please resend with your Signed-off-by tag, preferably via git send-email. Otherwise the patch looks good to me. Some kind of test for the adjacency data would be nice to have, maybe in a followup patch...

2 3

Re: include: Add d3dx10.h file
by Nikolay Sivov Oct. 26, 2015

Oct. 26, 2015

> +#include "d3dx10.h" This doesn't look right.

2 2

Re: [PATCH 2/6] wined3d: Keep track of FBOs through the GL names.
by Henri Verbeet Oct. 26, 2015

Oct. 26, 2015

On 22 October 2015 at 23:38, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The next two patches will improve integration with the fixed up depth > stencil and context_enum_surface_fbo_entries. fbo_entry->d3d_* will > remain for logging in context_check_fbo_status. > I'm not sure that really makes sense. I think it may be better to move the "d3d" parts of the logging like locations and surface pointers to entry creation, and get things like attachment dimensions and sample counts from OpenGL instead.

1 0

Re: [PATCH 1/6] wined3d: Prepare GL resources before looking for an FBO entry.
by Henri Verbeet Oct. 26, 2015

Oct. 26, 2015

On 22 October 2015 at 23:38, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > It is a bit unfortunate that we have to do this every draw now... > You may not have to, as such. You could just make doing a prepare_location()/load_location() a requirement before calling context_apply_fbo_state(). For things like draws you currently already need to call load_location(), but e.g. full clears depend on context_apply_fbo_state() to call prepare_location(). I think it would make sense to move those to the caller as well.

1 0

Report from wine-presentation at ubucon
by Maik Wagner Oct. 26, 2015

Oct. 26, 2015

Dear wine-Team, I would like to report on my activities at the ubucon convention in Berlin which took place this weekend. My talk was scheduled at 10 am but due to daylight saving time I could sleep one hour longer. I brought my Slackware 14.1 laptop and presented the latest 1.7.53 and showed some basic stuff as in the forums some people wouldn't know what version they are running. So I showed them how to find out their version with "wine --version" and how to create a prefix, using winecfg to switch between versions and eventually did a test for the AppDB as it's always useful to have new reports and made clear that testing should be done in a clean prefix. In total there were about 130 people coming to Berlin and in my talk we were about eight people who seemed very interested. One of them talked to me afterwards that he really appreciates on what wine is doing and during the talk I mentioned the start of DirectX11 development. Codeweavers supplied me with a polo shirt which I wore during the presentation to make it look more professional. I also mentioned things like reading the World Wine News and when a new version is coming out and that the development has shifted towards time-based releases. Last but not least I showed them some live testing on a demo mentioning that demo versions are very useful. I attached a photo of me which was taken by one of the participants at the beginning using my mobile phone camera. Have a good week, Maik

2 1

Re: [PATCH] mmdevapi: Fix win10 test failures
by Marvin Oct. 26, 2015

Oct. 26, 2015

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=17699 Your paranoid android. === w8 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:259: Test failed: Position 2167 expected 1527 capture.c:311: Test failed: GCP 14336 vs. BufferSize 21996 capture.c:316: Test failed: Position 3191 gap 1216 capture.c:336: Test failed: Position 4279 expected 3639 capture.c:361: Test failed: Position 5303 expected 4087 === w864 (32 bit capture) === capture.c:181: Test failed: Position 119 expected 0 capture.c:231: Test failed: Position 2167 expected 567 capture.c:259: Test failed: Position 2167 expected 567 capture.c:316: Test failed: Position 3191 gap 2176 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:259: Test failed: Position 2167 expected 1527 capture.c:311: Test failed: GCP 12992 vs. BufferSize 21996 capture.c:316: Test failed: Position 4151 gap 2176 capture.c:336: Test failed: Position 5239 expected 4599 capture.c:337: Test failed: flags 1 capture.c:361: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:259: Test failed: Position 2167 expected 1463 capture.c:316: Test failed: Position 3191 gap 1280 capture.c:361: Test failed: Position 4727 expected 4087 === w1064 (64 bit capture) === capture.c:311: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:336: Test failed: Position 5239 expected 4663 capture.c:361: Test failed: Position 5687 expected 5111

1 0

Re: [PATCH] ucrtbase: Implement some printf functions
by Martin Storsjö Oct. 26, 2015

Oct. 26, 2015

On Thu, 15 Oct 2015, Martin Storsjo wrote: > Not all functions are implemented (yet not all variants are > implemented in the normal msvcrt either). > > The new functions are more generalized and are C99 compliant. > They take an options parameter that e.g. for the snprintf > family of functions indicate whether the truncation and return > value should be handled as before or in the standards compliant > way. > > Some rudimentary tests are added (based on the msvcrt printf tests), > testing to make sure the snprintf truncation/return values are > handled correctly. > > These new functions also should support the C99 conversion > specifiers; this is not yet implemented. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > .../api-ms-win-crt-stdio-l1-1-0.spec | 10 +- > dlls/msvcrt/file.c | 28 +++ > dlls/msvcrt/printf.h | 20 ++ > dlls/msvcrt/wcs.c | 34 +++ > dlls/ucrtbase/tests/Makefile.in | 1 + > dlls/ucrtbase/tests/printf.c | 259 +++++++++++++++++++++ > dlls/ucrtbase/ucrtbase.spec | 10 +- > 7 files changed, 352 insertions(+), 10 deletions(-) > create mode 100644 dlls/ucrtbase/tests/printf.c > > diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h > index 4757931..bd2dbf3 100644 > --- a/dlls/msvcrt/printf.h > +++ b/dlls/msvcrt/printf.h > @@ -64,6 +64,26 @@ static int FUNC_NAME(puts_clbk_str)(void *ctx, int len, const APICHAR *str) > return len; > } > > +static int FUNC_NAME(puts_clbk_str_c99)(void *ctx, int len, const APICHAR *str) > +{ > + struct FUNC_NAME(_str_ctx) *out = ctx; > + > + if(!out->buf) > + return len; > + > + if(out->len - 1 < len) { > + memcpy(out->buf, str, (out->len - 1)*sizeof(APICHAR)); > + out->buf += out->len - 1; > + out->len = 1; > + return len; > + } > + > + memcpy(out->buf, str, len*sizeof(APICHAR)); > + out->buf += len; > + out->len -= len; > + return len; > +} > + FWIW, this gives warnings about puts_clbk_str_c99_w being defined but unused. It will be necessary later in case someone wants to implement the wchar versions of the printf functions for ucrtbase, but what should be done in the meantime? Just define this function somewhere else in wcs.c instead? // Martin

2 2

Re: [2/2] user32/tests: Add some tests for WM_MDIGETACTIVE.
by Marvin Oct. 26, 2015

Oct. 26, 2015

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=17696 Your paranoid android. === w1064 (32 bit win) === win.c:6703: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6725: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6703: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6703: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6703: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6703: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6703: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6725: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6703: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6725: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3462: Test failed: hwnd 000000000003019A message 0118 === w1064 (64 bit win) === win.c:6703: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6725: Test failed: 0x80/0x1050000: window rect 0,0-1024,768

1 0

Re: [1/2] user32/tests: Move MDI tests out of the WM_CREATE handler.
by Marvin Oct. 26, 2015

Oct. 26, 2015

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=17695 Your paranoid android. === w8 (32 bit win) === win.c:3416: Test failed: hwnd 00030148 message 0118 === w1064 (32 bit win) === win.c:6657: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6679: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6657: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6657: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6657: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6657: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6657: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6679: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6657: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6679: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3416: Test failed: hwnd 00000000000A01A0 message 0118 === w1064 (64 bit win) === win.c:6657: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6679: Test failed: 0x80/0x1050000: window rect 0,0-1024,768

2 1