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

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

Re: [4/6] widl: Attributes of the alias are supposed to replace attributes of a tag in the typelib.
by Huw Davies Oct. 26, 2015

Oct. 26, 2015

On Thu, Oct 15, 2015 at 08:47:04PM +0800, Dmitry Timoshkov wrote: > diff --git a/tools/widl/parser.y b/tools/widl/parser.y > index db5897e..1bd9565 100644 > --- a/tools/widl/parser.y > +++ b/tools/widl/parser.y > @@ -1893,6 +1893,10 @@ static type_t *reg_typedefs(decl_spec_t *decl_spec, declarator_list_t *decls, at > { > if (!type->name) > type->name = gen_name(); > + > + /* replace exisitng attributes when generating a typelib */ > + if (do_typelib) > + type->attrs = attrs; > } > > LIST_FOR_EACH_ENTRY( decl, decls, const declarator_t, entry ) I think this is actually correct (typedefs in typelibs are just strange). However, it would be more convincing if you could add version and helpcontext attributes to the typedefs and show that the base type gets those too. Something like: [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753901),restricted] struct _n { int n1; }; [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753902),hidden] typedef struct _n n; [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753903),version(1), helpcontext(1)] typedef struct _n nn; struct _n gets both version and helpcontext from nn (which is interesting as you can't set version or helpcontext attributes on a structure). and also: [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753904),restricted] struct _m { int m1; }; [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753905),hidden, version(2)] typedef struct _m m; [uuid(016fe2ec-b2c8-45f8-b23b-39e53a753906),helpcontext(1)] typedef struct _m mm; To show that _m doesn't get a version. i.e. it doesn't get the union of attributes from m and mm, it just gets the attributes from the last typedef to reference it. Huw.

1 0

Re: [PATCH] d3dx9_36: Supplying a AnimationController isn't an error
by Stefan Dösinger Oct. 26, 2015

Oct. 26, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-26 um 09:56 schrieb Alistair Leslie-Hughes: > + if (anim_controller) { > + *anim_controller = NULL; > + > + FIXME("Animation controller creation not implemented\n"); > + } Do you have an easy way to write this FIXME only if the file has an AnimationSet node? Or maybe even keep returning E_NOTIMPL if the output should be non-NULL? Also the style doesn't follow the general d3d style ('{' goes in its own line). > + ok(frame_hier->Name == NULL, "Expected NULL, got '%s'\n", frame_hier->Name); > + D3DXMatrixIdentity(&transform); > + check_matrix(&frame_hier->TransformationMatrix, &transform); It looks like these are the same tests as the ones right above the call. I'd skip them and only have controller-related test. A test input that should result in a non-NULL controller would be helpful as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWLfs5AAoJEN0/YqbEcdMwAM4P/1NSVVxBt3HGXPjqeF1Z6o93 6qV+C/MJB/82evJpf34zARYBXd6WzdeL+YbUl9K9G2iDZ/KLKf5l5opMnMD7cL1h 841dtZQu4IA3mJtwSY345+7YLcRV0qfYEHwFxvlO7JVqk9UIcsaE/kp+7tUvrFHD V5IIKSQrN6IhcGJDC51XIwcL2xxhgyco+5UOus6m6kKDBr+mpTxCVYpMOA4O/MjB fXoZl3S4SWkmJQwh8l9azycmRQ3y6xtQA8EksOWXxLv1lPhtdeb2LtP5w14vM4dC 3z3rC0NzDIAC+a5uNlhRbH8jb6SIlcdgInKaCaTSo9s8944eagaEh/ED2K4Q47Ub QaTz7JITa55ZnPuhgzms+Y3W8yW4QaEjgAo3L7/C91bVdBvwkBW0NBxIaMEgUU0M r+ZhjZPA2XsJ700k3SpB3BFHyFVT/qOtYLceNcE3d+8uJlmiqCu5xj6N4hojv1g2 gz8Map0/30mtA4b6IWD/kmnETYIZYYz28bzo8p56q25XFMGT1huArqW3JAlEe5Ic cKCUiNp3Visnzk9XJvmuW8wGVPk2Pta6UzdMCRiCF67Elb8Id8qqZc+GKsOm/FLV kSCvrXMaodeWqjnnyQIyI1QBo7Hoc4Q/V0iKiIVsPqvuY1wbmyTeVBdhqc+yKFw3 0llsQI07wd6TIWXgklAM =Xuvx -----END PGP SIGNATURE-----

1 0

Re: [PATCH 01/3] msvcp110: Add tr2_sys__Open_dir implementation.(try2)
by Piotr Caban Oct. 26, 2015

Oct. 26, 2015

Hi, On 10/15/15 06:57, YongHao Hu wrote: > + char temppath[MAX_PATH]; > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); > + if(strlen(dest) > MAX_PATH) { > + *err_code = ERROR_BAD_PATHNAME; > + return NULL; > + } > + strcpy(temppath, dest); > + strcat(temppath, "\\*.*"); There's still possible buffer overflow if e.g. strlen(dest)==MAX_PATH-2. Thanks, Piotr

1 0

Re: [PATCH] oledb32: Support VT_NULL on all conversions (resend)
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=17692 Your paranoid android. === wvistau64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w2008s64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w7pro64 (64 bit convert) === convert.c:2995: Test failed: got 24 === w864 (64 bit convert) === convert.c:2995: Test failed: got 24 === w1064 (64 bit convert) === convert.c:2995: Test failed: got 24

1 0

Re: d3dx10_43: Added D3DXCpuOptimizations stub sync
by Henri Verbeet Oct. 26, 2015

Oct. 26, 2015

On 25 October 2015 at 12:31, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39501 > Perhaps this is not any worse than what we have now, but presumably D3DXCpuOptimizations() is supposed to set global dll state like an ops table. I don't think forwarding will work very well once the implementation actually does something.

1 0

Re: [PATCH 7/7] kernel32/tests: Add tests for GetConsoleFontSize
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=17688 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Re: [PATCH 2/7 v3] kernel32/tests: Add tests for the FALSE pathway of GetCurrentConsoleFont
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=17687 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Wine Staging patch submission
by Hugh McMaster Oct. 26, 2015

Oct. 26, 2015

On Friday, 23 Oct 2015 18:55:18 +0200, Sebastian Lackner wrote: >The development branch has more infrastructure for patch management than just >the wine-patches and wine-devel mailing list, you also have to take into account >the patch status page for example. Even the development branch of Wine, where >most of the patches go upstream right on the next day, needs a way to keep track >of the patch status. > >[...] > >I also think that the suggested solution does not hide anything from the rest of >the Wine developers. The WineHQ bugtracker is publicly available to everyone, >and flexible enough to configure all kind of notifications you want to receive. >I would guess most people are not really interested in Staging tree related >submissions, because even in the month after WineConf, I didn't receive any >offers from "new people" to help cleaning up our patches for example... but if >there is, it doesn't sound like something which is impossible to solve. > >I have no problem with alternative suggestions, but just saying "use the mailing >lists" doesn't work. Mailing lists do not replace proper patch tracking, which >is what we are really talking about here. To bring this discussion full circle, how will Staging pick up patches from wine-patches? And how will this be signified? Will the upstream patch tracker have a "Staged" status assigned by one of the maintainers?

1 0

Re: [PATCH 2/3] dxgi/tests: Add test for maximum frame latency.
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=17680 Your paranoid android. === w1064 (32 bit device) === device.c:1147: Test failed: Got unexpected hr 0, test 16. device.c:1201: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1201: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1201: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1201: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1147: Test failed: Got unexpected hr 0, test 39. device.c:1201: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1201: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: include: Add d3dx10.h file
by Stefan Dösinger Oct. 25, 2015

Oct. 25, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-25 um 19:02 schrieb Andrey Gusev: > +enum _D3DX10_ERR { > + D3DX10_ERR_CANNOT_MODIFY_INDEX_BUFFER = MAKE_DDHRESULT(2900), > + D3DX10_ERR_INVALID_MESH = MAKE_DDHRESULT(2901), > + D3DX10_ERR_CANNOT_ATTR_SORT = MAKE_DDHRESULT(2902), > + D3DX10_ERR_SKINNING_NOT_SUPPORTED = MAKE_DDHRESULT(2903), > + D3DX10_ERR_TOO_MANY_INFLUENCES = MAKE_DDHRESULT(2904), > + D3DX10_ERR_INVALID_DATA = MAKE_DDHRESULT(2905), > + D3DX10_ERR_LOADED_MESH_AS_NO_DATA = MAKE_DDHRESULT(2906), > + D3DX10_ERR_DUPLICATE_NAMED_FRAGMENT = MAKE_DDHRESULT(2907), > + D3DX10_ERR_CANNOT_REMOVE_LAST_ITEM = MAKE_DDHRESULT(2908), > +}; Do you have code that uses this enum? This file doesn't exist in my Windows Kit installation, but it seems to be part of the old DirectX SDK headers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWLUGTAAoJEN0/YqbEcdMwom8P/RVZQofM7SWgQxCXHBNtoIgJ MbsFqCxC5FE8GFkq/omgzCtqCnXFVdEkdfhP+NHmM3J03iOQZJB5yVpq7rmM+rUi 4/otHGsDlo+SCUIS0RmybXTNilQtbIHN7aweJ44j3jfjDxc81MFpLQyL652wltEj 91G4zQgYHl58XZ4XGMPMLxqo+bvl/YzICH/5TqrmLHWdxELypCUU36v4/50/fLua 55qfGflbYyHz/lulWh4qy1LJk0pxkOp+l2H2tqzAvfNjI02WzEK+BOjJOO780vWj +hs3aQPTZSxPIQZVm8nVONPwAFm7Yut4mDo4gSFfXU9PSiKFcFf++7IJdXsQOhzy HTRX+iIUY8bcIyENJ9+0VdRw9m5azeHeaVnn6cs/VJoxcFshnnANeV4MmF4PSzsA UiJpSoAn95+LQL07c2wShFSSQq4CjDczyfDjUq2zSia4DS4J3aFXzvT3lYSThVIr kBzJAbFdKNGzcGe+CkBTRY0QgurJgXA6o4lg5rjm3eiQHUjDi9rQEbfdclF7pd2h 0pgkXxqKycPVPy48VumZE0B6wqiuf60EhKd2iPSJsPiDlTcSxSAEgL2wPxRkYUj0 U/XKOTwAxbackYzSyh/zCKjb+XicKeMoFCwdBXRpTcz7yT+jx/j28pX8yUGwXUc3 LdqniHTL3wiq8r/Tp4hL =nZMZ -----END PGP SIGNATURE-----

1 0

Re: [1/4] combase: Add TRACEs to string functions.
by Alistair Leslie-Hughes Oct. 25, 2015

Oct. 25, 2015

Hi Sebastian, On 25/10/15 14:43, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > @@ -95,6 +100,9 @@ HRESULT WINAPI WindowsCreateStringReference(LPCWSTR ptr, UINT32 len, > HSTRING_HEADER *header, HSTRING *out) > { > struct hstring_private *priv = impl_from_HSTRING_HEADER(header); > + > + TRACE("(%p, %u, %p, %p)\n", ptr, len, header, out); Would it make sense to output ptr as a string? Best Regards Alistair Leslie-Hughes

2 1

Re: winmm: Clear adwInfo when the struct MMIOINFO is initialized by MMIO_Open
by Andrew Eikum Oct. 25, 2015

Oct. 25, 2015

This looks OK to me. What do you think about zeroing the whole structure instead of just some of the fields, just to prevent this problem happening again in the future? In either case, Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> On Fri, Oct 23, 2015 at 06:24:02PM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > The program from bug 35872 registers an IO handler that test adwInfo > and crashes because when MMIO_Open is called these values have > garbage. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=35872 > diff --git a/dlls/winmm/mmio.c b/dlls/winmm/mmio.c > index ad73564..03cadd5 100644 > --- a/dlls/winmm/mmio.c > +++ b/dlls/winmm/mmio.c > @@ -596,6 +596,7 @@ static HMMIO MMIO_Open(LPSTR szFileName, MMIOINFO* refmminfo, DWORD dwOpenFlags, > mmioinfo.pIOProc = NULL; > mmioinfo.pchBuffer = NULL; > mmioinfo.cchBuffer = 0; > + memset(mmioinfo.adwInfo, 0, sizeof(mmioinfo.adwInfo)); > is_unicode = FALSE; > } > > diff --git a/dlls/winmm/tests/mmio.c b/dlls/winmm/tests/mmio.c > index fd5433c..48367ee 100644 > --- a/dlls/winmm/tests/mmio.c > +++ b/dlls/winmm/tests/mmio.c > @@ -599,12 +599,15 @@ static void test_mmioSetBuffer(char *fname) > static LRESULT CALLBACK mmio_test_IOProc(LPSTR lpMMIOInfo, UINT uMessage, LPARAM lParam1, LPARAM lParam2) > { > LPMMIOINFO lpInfo = (LPMMIOINFO) lpMMIOInfo; > + int i; > > switch (uMessage) > { > case MMIOM_OPEN: > if (lpInfo->fccIOProc == FOURCC_DOS) > lpInfo->fccIOProc = mmioFOURCC('F', 'A', 'I', 'L'); > + for (i = 0; i < sizeof(lpInfo->adwInfo) / sizeof(*lpInfo->adwInfo); i++) > + ok(lpInfo->adwInfo[i] == 0, "[%d] Expected 0, got %u\n", i, lpInfo->adwInfo[i]); > return MMSYSERR_NOERROR; > case MMIOM_CLOSE: > return MMSYSERR_NOERROR; > @@ -642,6 +645,18 @@ static void test_mmioOpen_fourcc(void) > mmio.lDiskOffset); > mmioClose(hmmio, 0); > > + /* Same test with NULL info */ > + memset(&mmio, 0, sizeof(mmio)); > + hmmio = mmioOpenA(fname, NULL, MMIO_READ); > + mmioGetInfo(hmmio, &mmio, 0); > + ok(hmmio && mmio.fccIOProc == FOURCC_XYZ, "mmioOpenA error %u, got %4.4s\n", > + mmio.wErrorRet, (LPCSTR)&mmio.fccIOProc); > + ok(mmio.adwInfo[1] == 0, "mmioOpenA sent MMIOM_SEEK, got %d\n", > + mmio.adwInfo[1]); > + ok(mmio.lDiskOffset == 0, "mmioOpenA updated lDiskOffset, got %d\n", > + mmio.lDiskOffset); > + mmioClose(hmmio, 0); > + > mmioInstallIOProcA(FOURCC_XYZ, NULL, MMIO_REMOVEPROC); > > memset(&mmio, 0, sizeof(mmio)); >

2 1

Videos or Slides from WineConf
by Joel Holdsworth Oct. 25, 2015

Oct. 25, 2015

Hi, are there any plans to publish videos or slides from wineconf? Joel

11 15

Re: [PATCH v2] user32: Added a GetDisplayConfigBufferSizes stub
by Marvin Oct. 24, 2015

Oct. 24, 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=17611 Your paranoid android. === w1064 (32 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[1]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[3]: -2

2 1

Re: d3d11: Make impl_from_ID3D11ShaderResourceView() static.
by Józef Kucia Oct. 24, 2015

Oct. 24, 2015

Hi Francois, On Sat, Oct 24, 2015 at 4:05 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/d3d11/view.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/d3d11/view.c b/dlls/d3d11/view.c > index 91f9265..a62c2de 100644 > --- a/dlls/d3d11/view.c > +++ b/dlls/d3d11/view.c > @@ -1189,7 +1189,7 @@ struct d3d_rendertarget_view *unsafe_impl_from_ID3D10RenderTargetView(ID3D10Rend > > /* ID3D11ShaderResourceView methods */ > > -struct d3d_shader_resource_view *impl_from_ID3D11ShaderResourceView(ID3D11ShaderResourceView *iface) > +static struct d3d_shader_resource_view *impl_from_ID3D11ShaderResourceView(ID3D11ShaderResourceView *iface) It should actually be "static inline". Thanks!

1 0

Wine-git no longer compiles
by Bruno Jesus Oct. 23, 2015

Oct. 23, 2015

Hi all, I just pulled today's git and wine no longer compiles: bruno(a)Note:~/programs/wine32$ make make: *** No rule to make target '../wine/Make.vars.in', needed by 'Makefile'. I can see some Makefile changes from Alexandre so probably related, am I the only affected? I'm compiling out of tree and I didn't try make clean yet because rebuilding the whole wine takes a lot of time (over 2 hours). Best wishes, Bruno

3 4

Wine Staging patch submission
by Michael Müller Oct. 23, 2015

Oct. 23, 2015

Dear Wine developers, a lot of changes regarding the integration of Wine Staging have already been realized, but there are also some tasks left. In this email I would like to talk about the ways on how to submit patches that should be integrated into the staging tree. So far most patch submissions were done through our Wine Staging bug tracker, but now we would like to move the patch submission to WineHQ. We had the choice between using a mailing list or using the upstream bug tracker. For the usual development progress a mailing list is perfectly fine, however patches submitted to Wine Staging are usually either complex, or need more work. Often multiple revisions are required, and we think that its much easier to keep track of the progress of a patchset, when all information is collected in one place. Also, it is much easier to use the existing bug tracker than writing tools for a separate staging patch overview page. ;-) * How does it work? We want to add a new component "patches" into the Staging product in the WineHQ bug tracker. If you want so submit a patch, you can then create a new bug report and add your patch as attachment. In case of a patch series, you can either put them into a tar archive, or add several attachments. You can sign-off your patch if you want to indicate that it would be ready for integration into the development branch, and just needs some more testing. Other developers are of course invited to give feedback on those patches, too. If the patch gets accepted, the status changes to FIXED. If the patch fixes a bug and there is no open bug report for this problem yet, we might also change the status to STAGED and move it to the appropriate upstream category. * Which patches should be sent to Staging? Normal patches should be sent to wine-patches. If Alexandre or a reviewer decides that the patch is dangerous or not good enough, they would tell you to try to get it into Staging first. Someone of the Wine Staging team will then be assigned as reviewer, and provide additional feedback / instructions how to proceed. If the patch just needs some additional testing, we will directly add it to Wine Staging. Otherwise we will ask you to create a bug report, where the patch can be improved iteratively. If you already know that your patch is very experimental, you can skip the first step and directly create a bug report as described above. * What happens after my patch got into Staging? This depends a bit on the reason why your patch was added, but usually one or more of the following things will happen: * you continue working on the patch and send us an updated version * someone else improves the patch (list all authors, for example by signing off the modified patch) * we remove / replace your patch if it turns out to be wrong or if we find a better solution * we (or you) send the patch to wine-patches if we think it is ready Although there are quite a few people testing git versions of Wine Staging, it sometimes makes sense to wait till the patch was included for one release to ensure that it does not introduce any regressions. I hope this answers all your questions regarding the patch submission to Wine Staging :-) Regards, Michael

6 6

Re: [PATCH] user32: Added GetDisplayConfigBufferSizes() stub
by Dmitry Timoshkov Oct. 23, 2015

Oct. 23, 2015

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +LONG WINAPI GetDisplayConfigBufferSizes(UINT32 flags, UINT32 *num_path_info, UINT32 *num_mode_info) > +{ > + FIXME("(0x%x %p %p): stub\n", flags, num_path_info, num_mode_info); > + if (num_path_info) *num_path_info = 0; > + if (num_mode_info) *num_mode_info = 0; > + return ERROR_NOT_SUPPORTED; > +} According to MSDN 2nd and 3rd parameters of this API can't be NULL. Also you should probably add a prototype to winuser.h. -- Dmitry.

2 2

Re: [2/2] ntdll: Do not check if object was signaled after user APC in server_select. (resend)
by Marvin Oct. 23, 2015

Oct. 23, 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=17602 Your paranoid android. === w1064 (64 bit sync) === sync.c:1694: Test failed: SleepConditionVariableCS should still return TRUE on crit unlock delay

1 0

Re: [PATCH 2/2] ws2_32: Add support for TF_REUSE_SOCKET to TransmitFile.
by Marvin Oct. 23, 2015

Oct. 23, 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=17597 Your paranoid android. === w2008s64 (32 bit sock) === sock.c:7350: Test failed: bytesReturned isn't supposed to be 1 sock.c:7374: Test failed: GetOverlappedResult failed, error 997

1 0