- wine-devel - winehq.org

Re: [PATCH 7/7] d3dx9: Support skip_constants parameter for effect.
by Matteo Bruni 18 Jul '17

18 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > HRESULT d3dx_create_param_eval(struct d3dx9_base_effect *base_effect, void *byte_code, > unsigned int byte_code_size, D3DXPARAMETER_TYPE type, > - struct d3dx_param_eval **peval, ULONG64 *version_counter) DECLSPEC_HIDDEN; > + struct d3dx_param_eval **peval, ULONG64 *version_counter, > + const char **skip_constants_names, unsigned int skip_constant_name_count) DECLSPEC_HIDDEN; I think you can get rid of the "_name" part in those parameters, for brevity. > +static HRESULT parse_skip_constants_string(char *skip_constants, const char ***names, > + unsigned int *name_count) It's a bit a matter of personal taste but triple pointers look quite ugly to me. In this case you could e.g. return "names" in place of HRESULT. > +{ > + const char *name; > + char *s; > + unsigned int size = INITIAL_CONST_NAMES_SIZE; > + > + *names = HeapAlloc(GetProcessHeap(), 0, sizeof(*names) * size); > + if (!*names) > + return E_OUTOFMEMORY; > + > + *name_count = 0; > + s = skip_constants; > + while ((name = next_valid_constant_name(&s))) > + { > + if (*name_count == size) > + { > + size *= 2; > + *names = HeapReAlloc(GetProcessHeap(), 0, *names, sizeof(*names) * size); > + if (!*names) > + return E_OUTOFMEMORY; I think you're leaking memory on failure here. > + } > + (*names)[(*name_count)++] = name; > + } > + *names = HeapReAlloc(GetProcessHeap(), 0, *names, *name_count * sizeof(*names)); > + if (!*names) > + return E_OUTOFMEMORY; And here. > + for (i = 0; i < skip_constants_name_count; ++i) > + { > + struct d3dx_parameter *param; > + > + param = get_parameter_by_name(base, NULL, skip_constants_names[i]); > + if (param) > + { > + for (j = 0; j < base->technique_count; ++j) > + { > + if (is_parameter_used(param, &base->techniques[j])) > + { > + WARN("Parameter %s found in skip_constants is used in technique %u.\n", > + debugstr_a(skip_constants_names[i]), j); > + HeapFree(GetProcessHeap(), 0, skip_constants_buffer); > + HeapFree(GetProcessHeap(), 0, skip_constants_names); > + d3dx9_base_effect_cleanup(base); > + return D3DERR_INVALIDCALL; > + } > + } > + } > + else > + { > + TRACE("Parameter %s found in skip_constants not found.\n", > + debugstr_a(skip_constants_names[i])); This one sounds a bit awkward ("found... not found"). Maybe just rewrite that as "skip_constants parameter %s not found". You could apply the same trick to the previous message too. > + for (j = 0; j < skip_constant_name_count; ++j) > + { > + if (!strcmp(cdesc[index].Name, skip_constants_names[j])) I assume the skip_constants thing isn't used often and, when it is, very few constants (1-3) are in the list. If that's not the case, we might want to use an rbtree for the constant names.

2 2

Re: [PATCH v2] user32: should restore owned window when restoring owner window.
by Andrew Eikum 18 Jul '17

18 Jul '17

On Tue, Jul 18, 2017 at 04:47:05PM +0800, jiang.biao2(a)zte.com.cn wrote: > Is this the right place to commit patches for wine? > > could somebody help to review this patch? > This is the right place to send patches. Your patch needs tests to show that it is correct, and to detect regressions from future changes. Here are some good places to start: https://wiki.winehq.org/Developer_FAQ https://wiki.winehq.org/Submitting_Patches https://wiki.winehq.org/Conformance_Tests Andrew

1 0

Re: [PATCH 4/5] msvcr120: Don't set errno in expm1.
by Piotr Caban 18 Jul '17

18 Jul '17

On 07/18/17 06:33, Alex Henrie wrote: > @@ -2421,7 +2421,6 @@ double CDECL MSVCR120_expm1(double x) > #else > double ret = exp(x) - 1; > #endif > - if (!isfinite(ret)) *MSVCRT__errno() = MSVCRT_ERANGE; > return ret; > } The function behaves differently depending on the reason of overflow. It doesn't set ERANGE errno if x == INFINITY (as your tests show). But it does set it when e.g. x == 10e100. Thanks, Piotr

1 0

Re: [PATCH 5/5] ucrtbase/tests: Add tests for errno with math functions.
by Piotr Caban 18 Jul '17

18 Jul '17

On 07/18/17 06:33, Alex Henrie wrote: > +#define INF 1.0/0.0 Please define infinity in the same way as it's done in other tests. You can use __port_infinity or call p_strtod("inf"...) to obtain it. Thanks, Piotr

1 0

Re: [PATCH 2/8] regedit: Determine the number of values and subkeys before exporting any data
by Alexandre Julliard 18 Jul '17

18 Jul '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 212 +++++++++++++++++++-------------------------- > 1 file changed, 91 insertions(+), 121 deletions(-) This doesn't seem to be an improvement. The registry can change while you are exporting it, you can't rely on querying things beforehand. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/6 v3] gdiplus: Store newer gdi+ version in created GdipRegions
by Vincent Povirk 17 Jul '17

17 Jul '17

It'd be very surprising to me if native does this and also requires a recognized version number, as that would break compatibility with 1.0 for no good reason. Based on the spec, they might only be checking the top 20 bits.

2 1

D3D Shaders - how does it work?
by Thomas Berger 17 Jul '17

17 Jul '17

Hi, i'm digging in the shader code for some hours right now, to understand what must be done to fix #41173 [1] and #40873 [2]. Right now, i don't really understand how the declaration of variables works in detail. Is there any documentation how the handling and registering of variables works, or should the could be documentation enough? [1] https://bugs.winehq.org/show_bug.cgi?id=41173 [2] https://bugs.winehq.org/show_bug.cgi?id=40873 Greetings, Thomas

4 5

Re: [PATCH] rsaenh: do not use stack variables out of frame (Coverity)
by Jacek Caban 17 Jul '17

17 Jul '17

On 15.07.2017 10:07, Marcus Meissner wrote: > 1414721 Pointer to local outside scope > > These harmless looking assignments are of the form: > > algid = BCRYPT_SHA512_ALGORITHM; > > with ../../include/bcrypt.h:#define BCRYPT_SHA512_ALGORITHM (const WCHAR []){'S','H','A','5','1','2',0} > this is > algid = temporary allocated stack variable > > The stack array however goes invalid as soon as it leaves the "switch" case. > > Use a stack temporary array to avoid this confusion. This actually shows a huge problem with using (const WCHAR []){ .... } casts in Wine. In this case it's meant to replace L"..." for wide strings and that in mind, affected code is perfectly fine. It's definition in header that is not compatible. Sadly, I don't see a good solution for that. We could just not not use such casts and use static const variables in headers like we do in many other cases, but that has its own problems. Jacek

1 0

Wineconf sponsorship
by Jeremy White 17 Jul '17

17 Jul '17

Hi folks, This is a reminder that the Wine Project uses it's donations to sponsor travel to the annual Wine conference for contributors to Wine. So if you think Wineconf sounds cool, but you can't afford to go, please think again. I can't promise that we'll sponsor everyone, or that we can cover the full cost, but we are very cheerful to try! I'd also invite people that contribute, but perhaps not as developers, to also write in. We are interested in expanding the voices at the conference, and you would be very welcome. You can email me directly to request a sponsorship (or, if you prefer, hit up any of the other committee members - Alexandre, Austin, Marcus, or Michael). Cheers, Jeremy

1 0

Re: [PATCH 3/3] dwrite: Explicitly check rendering parameters pointer passed to DrawGlyphRun()
by Marvin 17 Jul '17

17 Jul '17

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=32333 Your paranoid android. === wvistau64 (32 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w2008s64 (32 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w8 (32 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f04:font: unhandled exception c0000005 at 004278C7 === w864 (32 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0eb0:font: unhandled exception c0000005 at 004278C7 === wvistau64 (64 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w2008s64 (64 bit font) === font.c:1348: Test failed: Unexpected hr 0. === w864 (64 bit font) === font.c:5017: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0e8c:font: unhandled exception c0000005 at 00000000004235C2

1 0

Re: [PATCH 2/3] dwrite: Use antialias mode set for bitmap render target
by Marvin 17 Jul '17

17 Jul '17

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=32332 Your paranoid android. === wvistau64 (32 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w2008s64 (32 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w8 (32 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f54:font: unhandled exception c0000005 at 004278F7 === w864 (32 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f74:font: unhandled exception c0000005 at 004278F7 === wvistau64 (64 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w2008s64 (64 bit font) === font.c:1349: Test failed: Unexpected hr 0. === w864 (64 bit font) === font.c:5018: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f9c:font: unhandled exception c0000005 at 00000000004235F2

1 0

Re: [PATCH 1/3] dwrite: Improve rendering parameters validation
by Marvin 17 Jul '17

17 Jul '17

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=32331 Your paranoid android. === w8 (32 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0ed8:font: unhandled exception c0000005 at 00427387 === w864 (32 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0f54:font: unhandled exception c0000005 at 00427387 === w864 (64 bit font) === font.c:4957: Test failed: Failed to create glyph run analysis, hr 0x80070057. 0e88:font: unhandled exception c0000005 at 0000000000423152

1 0

Re: [PATCH 2/6 v2] gdiplus: Test drawing metafile image to emf+ file
by Marvin 15 Jul '17

15 Jul '17

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=32319 Your paranoid android. === wxppro (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2003std (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === wvistau64 (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2008s64 (32 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === wvistau64 (64 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record === w2008s64 (64 bit metafile) === metafile.c:54: Test failed: draw image metafile.2: Expected record type 0x4008, got 0x4025 metafile.c:54: Test failed: draw image metafile.3: Expected record type 0x1, got 0x402c metafile.c:54: Test failed: draw image metafile.4: Expected record type 0x4001, got 0x4008 metafile.c:54: Test failed: draw image metafile.5: Expected record type 0x4008, got 0x1 metafile.c:54: Test failed: draw image metafile.6: Expected record type 0x4008, got 0x4001 metafile.c:54: Test failed: draw image metafile.7: Expected record type 0x401b, got 0x4008 metafile.c:54: Test failed: draw image metafile.8: Expected record type 0x21, got 0x4008 metafile.c:54: Test failed: draw image metafile.9: Expected record type 0x62, got 0x4008 metafile.c:54: Test failed: draw image metafile.10: Expected record type 0x4c, got 0x4008 metafile.c:54: Test failed: draw image metafile.11: Expected record type 0x22, got 0x4008 metafile.c:54: Test failed: draw image metafile.12: Expected record type 0x4002, got 0x4008 metafile.c:54: Test failed: draw image metafile.13: Expected record type 0xe, got 0x401b metafile.c:54: Test failed: draw image metafile.14: Expected record type 0x401b, got 0x21 metafile.c:54: Test failed: draw image metafile.15: Expected record type 0x21, got 0x62 metafile.c:54: Test failed: draw image metafile.16: Expected record type 0x62, got 0x4c metafile.c:54: Test failed: draw image metafile.17: Expected record type 0x4c, got 0x22 metafile.c:54: Test failed: draw image metafile.18: Expected record type 0x22, got 0x4002 metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x401a record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4026 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x21 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x62 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x4c record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0x22 record metafile.c:140: Test failed: draw image metafile: Unexpected EMF+ 0x4002 record metafile.c:177: Test failed: draw image metafile: Unexpected EMF 0xe record

1 0

Re: [PATCH v2 1/3] explorerframe: Implement ITaskbarList::AddTab() and ::DeleteTab().
by Alexandre Julliard 14 Jul '17

14 Jul '17

Zebediah Figura <zfigura(a)codeweavers.com> writes: > ITaskbarList is an interface which allows applications to manually > control which windows appear on the taskbar, as well as what state > they are in (e.g. activated, flashing, progress bar). It also exposes > a function to "redirect" activation to other windows in a process. > > In particular, when using multiple documents in Excel 2010, the > application will delete the button for its main window, and redirect > activation of dummy windows to the child windows containing the > documents. > > Version 2 of this patch: use an internal window message instead of > calling the graphics driver directly. This is necessary because the > interface allows modifying the buttons attached to other processes' > windows. This looks very ad-hoc. I'd like to see a design that would show a credible path towards implementing the entire interface. We can't add new private messages for every bit of functionality. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] gdiplus: Add support for creating image object containing metafile
by Vincent Povirk 14 Jul '17

14 Jul '17

This could use a test, just to verify that native can read the emf we create. On Fri, Jul 14, 2017 at 8:18 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/metafile.c | 47 > ++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 44 insertions(+), 3 deletions(-) > > > > >

1 0

Re: [PATCH 1/2] msvcp140: Implement _Stat and _Lstat (v3).
by Piotr Caban 14 Jul '17

14 Jul '17

Hi Stefan, On 07/13/17 17:40, Stefan Dösinger wrote: > +enum msvcp140_file_type { > + msvcp140_file_type_not_found = -1, msvcp140_file_type_none, msvcp140_file_type_regular, > + msvcp140_file_type_directory, msvcp140_file_type_symlink, msvcp140_file_type_block, > + msvcp140_file_type_character, msvcp140_file_type_fifo, msvcp140_file_type_socket, msvcp140_file_type_unknown > +}; Did you consider changing current structure instead of defining new one? I'm talking about something like: enum file_type { #if _MSVCP_VER < 140 status_unknown, file_not_found, #else file_not_found = -1, status_unknown, #endif regular_file, directory_file, ... } Thanks to it you will be able to use the same implementation of _Open_dir/_Read_dir in msvcp120 and msvcp140. > + *permissions = (attr & FILE_ATTRIBUTE_READONLY)?0555:0777; You should also handle permission==NULL case. Thanks, Piotr

2 2

Re: [PATCH 2/2] winhttp/tests: Make sure that all notifications were called before the end of a test.
by Marvin 14 Jul '17

14 Jul '17

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=32295 Your paranoid android. === w8 (32 bit notification) === notification.c:602: Test failed: some notifications were missing: 800

1 0

Re: [PATCH 1/2] winhttp/tests: Use notification flags to explicitly mark notifications that should signal an event.
by Marvin 14 Jul '17

14 Jul '17

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=32294 Your paranoid android. === w8 (32 bit notification) === notification.c:272: Test failed: got 00000102 notification.c:290: Test failed: unexpected function 8, expected 1. probably some notifications were missing notification.c:90: Test failed: 290: expected status 0x00000800 got 0x00000400 notification.c:91: Test failed: 290: expected function 8 got 1 notification.c:294: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:90: Test failed: 294: expected status 0x00000800 got 0x00000400 notification.c:91: Test failed: 294: expected function 8 got 2 notification.c:301: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:90: Test failed: 301: expected status 0x00000800 got 0x00000010 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:90: Test failed: 301: expected status 0x00000800 got 0x00000020 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:91: Test failed: 301: expected function 8 got 3 notification.c:311: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:90: Test failed: 311: expected status 0x00000800 got 0x00000040 notification.c:91: Test failed: 311: expected function 8 got 4 notification.c:90: Test failed: 311: expected status 0x00000800 got 0x00000080 notification.c:91: Test failed: 311: expected function 8 got 4

1 0

wine-2.0.2-rc3 Available
by Michael Stefaniuc 13 Jul '17

13 Jul '17

Hello guys, I have pushed wine-2.0.2-rc3 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes since rc2: - Added Steam fix bye michael

1 0

Re: [PATCH 2/6] gdiplus: Add helper for saving path objects in metafile
by Dmitry Timoshkov 13 Jul '17

13 Jul '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > +typedef struct EmfPlusPath > +{ > + DWORD Version; > + DWORD PathPointCount; > + DWORD PathPointFlags; > + /* PathPoints[] */ > + /* PathPointTypes[] */ > + /* AlignmentPadding */ > + BYTE data[1]; > +} EmfPlusPath; ... > +static GpStatus METAFILE_AddPathObject(GpMetafile *metafile, GpPath *path, DWORD *id) > +{ ... > + object_record->ObjectData.path.Version = 0xDBC01002; > + object_record->ObjectData.path.PathPointCount = path->pathdata.Count; > + object_record->ObjectData.path.PathPointFlags = 0; This looks very similar to the buffer format returned by GdipGetRegionData(), is it possible to use that API instead of a custom generator? -- Dmitry.

3 2

Meson buildsystem - does make it sense for Wine?
by David Heidelberg 13 Jul '17

13 Jul '17

As I recently discovered Meson build system [1] (compatible with Linux, FreeBSD, Windows, Android etc.) which tends to be preferred replacement for autotools (at least recently by many projects). [2] I didn't found any discussion regarding to porting Wine build system. I wounder what is your opinion, could Meson can improve wine build times? Also maybe simplified crossbuilds? Thank you David [1] http://mesonbuild.com/ [2] https://www.youtube.com/watch?v=ae9_rNuFaQM

2 1

Re: [4/5] [v2] ntdll: Provide more accurate virtual memory counters. (rebased)
by Alex Henrie 13 Jul '17

13 Jul '17

I don't think this patch is going to be accepted without showing that it makes some application usable that previously was not. -Alex

2 3

Re: [PATCH v2 1/2] explorer: Improve tray sizing and style.
by Alexandre Julliard 13 Jul '17

13 Jul '17

Zebediah Figura <zfigura(a)codeweavers.com> writes: > v2: use appropriate system metrics. > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > --- > programs/explorer/systray.c | 20 +++++++++++--------- > 1 file changed, 11 insertions(+), 9 deletions(-) It's mainly a matter of taste, but this doesn't look better to me. In particular having buttons remain pushed when active feels wrong. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcp140: Implement _Stat and _Lstat (v2).
by Stefan Dösinger 13 Jul '17

13 Jul '17

Am 2017-07-13 um 15:05 schrieb Stefan Dösinger: +enum msvcp140_file_type { + file_type_not_found = -1, file_type_none, file_type_regular, + file_type_directory, file_type_symlink, file_type_block, + file_type_character, file_type_fifo, file_type_socket, file_type_unknown +}; Please skip this patch for now, with the changes needed to handle _Open_dir I feel it'd be better to consistently use msvcp140_file_type for the name of the enum type and the enum values. I don't plan any functional changes beyond this cosmetic one, so it should be good to review though.

1 0

Re: [2/6] wsdapi: Add code to create SOAP envelope from header and body elements.
by Alexandre Julliard 13 Jul '17

13 Jul '17

Owen Rudge <orudge(a)codeweavers.com> writes: > +#define WCHAR_URN_COLON 'u','r','n',':' > +#define WCHAR_HTTP_COLON_SLASH_SLASH 'h','t','t','p',':','/','/' > +#define WCHAR_SCHEMAS 's','c','h','e','m','a','s' > +#define WCHAR_SOAP 's','o','a','p' > +#define WCHAR_XMLSOAP 'x','m','l',WCHAR_SOAP > +#define WCHAR_ORG 'o','r','g' > +#define WCHAR_WS_SLASH 'w','s','/' > +#define WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG WCHAR_SCHEMAS,'.',WCHAR_XMLSOAP,'.',WCHAR_ORG > +#define WCHAR_DISCOVERY 'd','i','s','c','o','v','e','r','y' > +#define WCHAR_MESSAGE 'M','e','s','s','a','g','e' > +#define WCHAR_SEQUENCE 'S','e','q','u','e','n','c','e' > + > +static const WCHAR addressingNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG,'/', > + WCHAR_WS_SLASH,'2','0','0','4','/','0','8','/','a','d','d','r','e','s','s','i','n','g', 0 }; > + > +static const WCHAR discoveryNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + WCHAR_SCHEMAS_DOT_XML_SOAP_DOT_ORG,'/', > + WCHAR_WS_SLASH,'2','0','0','5','/','0','4','/',WCHAR_DISCOVERY, 0 }; > + > +static const WCHAR envelopeNsUri[] = { > + WCHAR_HTTP_COLON_SLASH_SLASH, > + 'w','w','w','.','w','3','.',WCHAR_ORG,'/', > + '2','0','0','3','/','0','5','/',WCHAR_SOAP,'-','e','n','v','e','l','o','p','e', 0 }; > + > +static const WCHAR addressingPrefix[] = { 'w','s','a', 0 }; > +static const WCHAR discoveryPrefix[] = { 'w','s','d', 0 }; > +static const WCHAR envelopePrefix[] = { WCHAR_SOAP, 0 }; > +static const WCHAR headerString[] = { 'H','e','a','d','e','r', 0 }; > +static const WCHAR actionString[] = { 'A','c','t','i','o','n', 0 }; > +static const WCHAR messageIdString[] = { WCHAR_MESSAGE,'I','D', 0 }; > +static const WCHAR toString[] = { 'T','o', 0 }; > +static const WCHAR relatesToString[] = { 'R','e','l','a','t','e','s','T','o', 0 }; > +static const WCHAR appSequenceString[] = { 'A','p','p',WCHAR_SEQUENCE, 0 }; > +static const WCHAR instanceIdString[] = { 'I','n','s','t','a','n','c','e','I','d', 0 }; > +static const WCHAR messageNumberString[] = { WCHAR_MESSAGE,'N','u','m','b','e','r', 0 }; > +static const WCHAR sequenceIdString[] = { WCHAR_SEQUENCE,'I','d', 0 }; > +static const WCHAR emptyString[] = { 0 }; I think this would be more readable (and more greppable) without the #defines. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ws2_32: Set return size when calling WSAIoctl with WS_SIO_GET_EXTENSION_FUNCTION_POINTER.
by Sebastian Lackner 13 Jul '17

13 Jul '17

On 13.07.2017 06:20, Alistair Leslie-Hughes wrote: > This is a backbort of the above change, borrowed from Codeweavers. :) > > Target: 2.0.* branch. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/ws2_32/socket.c | 1 + > 1 file changed, 1 insertion(+) > It probably does not matter in practice (and I don't think we have any tests for it yet), but please note that this not equivalent to the code we have in the development branch. It also changes error handling in a completely unrelated situation (when a extension is not found). Why not just backport 914e401aa9d5401893c3807d51e3f19fc7a7ab38 plus the fix?

2 1

Re: [PATCH 4/5 v3] msvcr120: Add acosh.
by Alex Henrie 12 Jul '17

12 Jul '17

Alexandre, when you apply these patches, you don't have to keep the "From: Alex Henrie" line. The acosh and atanh implementations are now more Piotr's work than they are mine, although I'm happy to sign off on them. -Alex

1 0

Re: [PATCH 4/5 v2] msvcr120: Add acosh.
by Alex Henrie 12 Jul '17

12 Jul '17

/********************************************************************* + * acosh (MSVCR120.@) + */ +double CDECL MSVCR120_acosh(double x) +{ + if (x < 1) { + *MSVCRT__errno() = MSVCRT_EDOM; + return NAN; + } +#ifdef HAVE_ACOSH + return acosh(x); +#else + if (!isfinite(x*x)) return log(2) + log(x); + return log(x + sqrt(x*x-1)); +#endif +} + +/********************************************************************* + * acoshf (MSVCR120.@) + */ +float CDECL MSVCR120_acoshf(float x) +{ +#ifdef HAVE_ACOSHF + return acoshf(x); +#else + return MSVCR120_acosh(x); +#endif +} Thanks for the help. Are you sure that acosh and atanh require bounds checking, but acoshf and atanhf do not? Also, aren't they supposed to set an exception flag if x is less than 1? -Alex

2 1

wine-2.0.2-rc2 Available
by Michael Stefaniuc 12 Jul '17

12 Jul '17

Hello guys, I have pushed wine-2.0.2-rc2 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Changes rc1: - Added the commit "ddraw: Validate the "surface" pointer before creating the surface in CreateSurface()." Required by patches included in rc1 that were trading crashes for mem leaks (Thanks Sebastian and Henri). Please let me if you feel strongly about the inclusion of the outstanding Steam fix into wine-2.0.2. As it isn't in devel yet I would tend to defer it to 2.0.3 and I'm not opposed to do an earlier release for that in early to mid August. thanks bye michael

1 0

Re: [PATCH 8/9] msvcr120: Add expm1.
by Piotr Caban 12 Jul '17

12 Jul '17

On 07/10/17 06:55, Alex Henrie wrote: > +float CDECL MSVCR120_expm1f(float x) > +{ > +#ifdef HAVE_EXPM1F > + return expm1f(x); > +#else > + return exp(x) - 1; > +#endif > +} Please set errno on invalid arguments. Thanks, Piotr

1 0

Re: [PATCH 2/3] Add mfuuid.lib
by Alexandre Julliard 11 Jul '17

11 Jul '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +DEFINE_GUID(CLSID_MFReadWriteClassFactory, 0x48e2ed0f, 0x98c2, 0x4a37, 0xbe, 0xd5, 0x16, 0x63, 0x12, 0xdd, 0xd8, 0x3f); > +DEFINE_GUID(CLSID_MFSourceReader, 0x1777133c, 0x0881, 0x411b, 0xa5, 0x77, 0xad, 0x54, 0x5f, 0x07, 0x14, 0xc4); > +DEFINE_GUID(CLSID_MFSinkWriter, 0xa3bbfb17, 0x8273, 0x4e52, 0x9e, 0x0e, 0x97, 0x39, 0xdc, 0x88, 0x79, 0x90); > + > +DEFINE_GUID(MF_SINK_WRITER_ASYNC_CALLBACK, 0x48cb183e, 0x7b0b, 0x46f4, 0x82, 0x2e, 0x5e, 0x1d, 0x2d, 0xda, 0x43, 0x54); > +DEFINE_GUID(MF_SINK_WRITER_DISABLE_THROTTLING, 0x08b845d8, 0x2b74, 0x4afe, 0x9d, 0x53, 0xbe, 0x16, 0xd2, 0xd5, 0xae, 0x4f); > +DEFINE_GUID(MF_SINK_WRITER_D3D_MANAGER, 0xec822da2, 0xe1e9, 0x4b29, 0xa0, 0xd8, 0x56, 0x3c, 0x71, 0x9f, 0x52, 0x69); > +DEFINE_GUID(MF_SINK_WRITER_ENCODER_CONFIG, 0xad91cd04, 0xa7cc, 0x4ac7, 0x99, 0xb6, 0xa5, 0x7b, 0x9a, 0x4a, 0x7c, 0x70); > + > +DEFINE_GUID(MF_READWRITE_DISABLE_CONVERTERS, 0x98d5b065, 0x1374, 0x4847, 0x8d, 0x5d, 0x31, 0x52, 0x0f, 0xee, 0x71, 0x56); > +DEFINE_GUID(MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS, 0xa634a91c, 0x822b, 0x41b9, 0xa4, 0x94, 0x4d, 0xe4, 0x64, 0x36, 0x12, 0xb0); > +DEFINE_GUID(MF_READWRITE_MMCSS_CLASS, 0x39384300, 0xd0eb, 0x40b1, 0x87, 0xa0, 0x33, 0x18, 0x87, 0x1b, 0x5a, 0x53); > +DEFINE_GUID(MF_READWRITE_MMCSS_PRIORITY, 0x43ad19ce, 0xf33f, 0x4ba9, 0xa5, 0x80, 0xe4, 0xcd, 0x12, 0xf2, 0xd1, 0x44); > +DEFINE_GUID(MF_READWRITE_MMCSS_CLASS_AUDIO, 0x430847da, 0x0890, 0x4b0e, 0x93, 0x8c, 0x05, 0x43, 0x32, 0xc5, 0x47, 0xe1); > +DEFINE_GUID(MF_READWRITE_MMCSS_PRIORITY_AUDIO, 0x273db885, 0x2de2, 0x4db2, 0xa6, 0xa7, 0xfd, 0xb6, 0x6f, 0xb4, 0x0b, 0x61); > +DEFINE_GUID(MF_READWRITE_D3D_OPTIONAL, 0x216479d9, 0x3071, 0x42ca, 0xbb, 0x6c, 0x4c, 0x22, 0x10, 0x2e, 0x1d, 0x18); I don't see any of these in the PSDK mfuuid library. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 2/2] user32: Activate another window upon minimizing.
by Marvin 11 Jul '17

11 Jul '17

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=32251 Your paranoid android. === w7u (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00AC013C fg 000301B4 in hook HCBT_MINMAX win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500D8 fg 000301B4 in hook HCBT_MINMAX === w7pro64 (32 bit win) === win.c:9852: Test failed: expected 000A015E, got 0006011E win.c:9858: Test failed: expected 000A015E, got 0006011E win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00070134 fg 00070160 in hook HCBT_MINMAX === w7pro64 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000000000007015A fg 0000000000070160 in hook HCBT_MINMAX

1 0

Re: [PATCH v2 1/2] user32/tests: Add tests for activating windows.
by Marvin 11 Jul '17

11 Jul '17

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=32250 Your paranoid android. === w7pro64 (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00070106 fg 00070160 in hook HCBT_MINMAX === w864 (32 bit win) === win.c:2331: Test failed: expected !100 win.c:2331: Test failed: expected !100 === w7pro64 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000070106 fg 0000000000070160 in hook HCBT_MINMAX

1 0

Re: [PATCH 3/3] user32/tests: Use todo_wine for failing z-order tests.
by Marvin 11 Jul '17

11 Jul '17

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=32243 Your paranoid android. === wxppro (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00020152 win.c:9961: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 000400F6 win.c:9961: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00050120 win.c:9961: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9961: Test failed: GetActiveWindow() = 00080124 win.c:9961: Test failed: GetFocus() = 00080124 === w7u (32 bit win) === win.c:3001: Test failed: 0011013C: expected next 00000000, got 000301B8 win.c:3003: Test failed: 00100192: expected prev 000301AC, got 000A01B6 win.c:3004: Test failed: 000301AC: expected next 00100192, got 00000000 win.c:3005: Test failed: 000901BA: expected prev 000A01B6, got 0011013C win.c:3006: Test failed: 000A01B6: expected next 000901BA, got 00100192 win.c:3015: Test failed: 0011013C: expected next 00000000, got 000301B8 win.c:3016: Test failed: 00100192: expected prev 000301AC, got 000A01B6 win.c:3017: Test failed: 000301AC: expected next 00100192, got 00000000 win.c:3018: Test failed: 000901BA: expected prev 000A01B6, got 0011013C win.c:3019: Test failed: 000A01B6: expected next 000901BA, got 00100192 win.c:3001: Test failed: 0012013C: expected next 00000000, got 000301B8 win.c:3003: Test failed: 000B01B6: expected prev 000301AC, got 009E015A win.c:3004: Test failed: 000301AC: expected next 000B01B6, got 00000000 win.c:3005: Test failed: 000901BA: expected prev 009E015A, got 0012013C win.c:3006: Test failed: 009E015A: expected next 000901BA, got 000B01B6 win.c:3015: Test failed: 0012013C: expected next 00000000, got 000301B8 win.c:3016: Test failed: 000B01B6: expected prev 000301AC, got 009E015A win.c:3017: Test failed: 000301AC: expected next 000B01B6, got 00000000 win.c:3018: Test failed: 000901BA: expected prev 009E015A, got 0012013C win.c:3019: Test failed: 009E015A: expected next 000901BA, got 000B01B6 === w7pro64 (32 bit win) === win.c:9968: Test failed: expected 000B015E, got 00050024 === w8 (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0009012E fg 000400FA in hook HCBT_MINMAX === wvistau64 (64 bit win) === win.c:9961: Test failed: GetActiveWindow() = 0000000000050120 win.c:9961: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9961: Test failed: GetActiveWindow() = 0000000000080124 win.c:9961: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9968: Test failed: expected 00000000000B015E, got 000000000006011E === w864 (64 bit win) === win.c:9968: Test failed: expected 00000000000B015C, got 0000000000050028

1 0

Re: [PATCH 2/3] user32: Activate another window upon minimizing.
by Marvin 11 Jul '17

11 Jul '17

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=32242 Your paranoid android. === wxppro (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00020152 win.c:9939: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 000400F6 win.c:9939: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00050120 win.c:9939: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9939: Test failed: GetActiveWindow() = 00080124 win.c:9939: Test failed: GetFocus() = 00080124 === w7pro64 (32 bit win) === win.c:9946: Test failed: expected 000B00FC, got 0006011E === w8 (32 bit win) === win.c:9946: Test failed: expected 000B0132, got 0006011A === w864 (32 bit win) === win.c:9946: Test failed: expected 000B015C, got 0004001C === wvistau64 (64 bit win) === win.c:9939: Test failed: GetActiveWindow() = 0000000000050120 win.c:9939: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9939: Test failed: GetActiveWindow() = 0000000000080124 win.c:9939: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9852: Test failed: expected 00000000000A015A, got 0000000000050024 win.c:9858: Test failed: expected 00000000000A015A, got 0000000000050024 win.c:9946: Test failed: expected 00000000000B015A, got 0000000000050024 === w864 (64 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000050192 fg 0000000000050020 in hook HCBT_MINMAX === w1064 (64 bit win) === win.c:9946: Test failed: expected 0000000000080042, got 000000000003002E

1 0

Re: [PATCH 1/3] user32/tests: Add tests for activating windows.
by Marvin 11 Jul '17

11 Jul '17

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=32241 Your paranoid android. === wxppro (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00020152 win.c:9940: Test failed: GetFocus() = 00020152 === w2003std (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 000400F6 win.c:9940: Test failed: GetFocus() = 000400F6 === wvistau64 (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00050120 win.c:9940: Test failed: GetFocus() = 00050120 === w2008s64 (32 bit win) === win.c:9940: Test failed: GetActiveWindow() = 00080124 win.c:9940: Test failed: GetFocus() = 00080124 === w7u (32 bit win) === win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00A70144 fg 000B0188 in hook HCBT_MINMAX win.c:999: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000700F8 fg 000B0188 in hook HCBT_MINMAX win.c:9962: Test failed: expected 000B00F0, got 000801AA win.c:9981: Test failed: expected 000B00F0, got 000801AA === wvistau64 (64 bit win) === win.c:9940: Test failed: GetActiveWindow() = 0000000000050120 win.c:9940: Test failed: GetFocus() = 0000000000050120 === w2008s64 (64 bit win) === win.c:9940: Test failed: GetActiveWindow() = 0000000000080124 win.c:9940: Test failed: GetFocus() = 0000000000080124 === w7pro64 (64 bit win) === win.c:9947: Test failed: expected 00000000000B015E, got 0000000000050024

1 0

Re: [PATCH 3/6] gdiplus: Support GdipSetSmoothingMode in metafiles
by Vincent Povirk 11 Jul '17

11 Jul '17

According to the spec, SmoothingModeHighSpeed also does no antialiasing.

2 1

Re: [PATCH 7/9] msvcr120: Add erfc.
by Piotr Caban 11 Jul '17

11 Jul '17

On 07/10/17 06:55, Alex Henrie wrote: > /********************************************************************* > + * erfc (MSVCR120.@) > + */ > +double CDECL MSVCR120_erfc(double x) > +{ > +#ifdef HAVE_ERFC > + return erfc(x); > +#else > + FIXME( "not implemented\n" ); > + return 0.0; > +#endif You can return 1.0 - MSVCR120_erf(x) if erfc is not available. Thanks, Piotr

2 2

Re: winhttp/tests: Make notification tests more strict.
by Marvin 11 Jul '17

11 Jul '17

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=32231 Your paranoid android. === w7pro64 (32 bit notification) === notification.c:219: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 219: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:226: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:236: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:248: Test failed: unexpected function 2, expected 8. probably some notifications were missing notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:282: Test failed: unexpected function 2, expected 1. probably some notifications were missing notification.c:90: Test failed: 282: expected function 2 got 1 notification.c:315: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 315: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 315: expected function 8 got 2 notification.c:322: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:332: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 341: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 341: expected function 1 got 8 === w1064 (64 bit notification) === notification.c:219: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 219: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:226: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:89: Test failed: 226: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 226: expected function 8 got 3 notification.c:90: Test failed: 219: expected function 8 got 2 notification.c:236: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:89: Test failed: 236: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 236: expected function 8 got 4 notification.c:248: Test failed: unexpected function 2, expected 8. probably some notifications were missing notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:89: Test failed: 248: expected status 0x00000400 got 0x00000800 notification.c:90: Test failed: 248: expected function 2 got 8 notification.c:282: Test failed: unexpected function 2, expected 1. probably some notifications were missing notification.c:90: Test failed: 282: expected function 2 got 1 notification.c:315: Test failed: unexpected function 8, expected 2. probably some notifications were missing notification.c:89: Test failed: 315: expected status 0x00000800 got 0x00000400 notification.c:90: Test failed: 315: expected function 8 got 2 notification.c:322: Test failed: unexpected function 8, expected 3. probably some notifications were missing notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000010 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:89: Test failed: 322: expected status 0x00000800 got 0x00000020 notification.c:90: Test failed: 322: expected function 8 got 3 notification.c:332: Test failed: unexpected function 8, expected 4. probably some notifications were missing notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000040 notification.c:90: Test failed: 332: expected function 8 got 4 notification.c:89: Test failed: 332: expected status 0x00000800 got 0x00000080 notification.c:90: Test failed: 332: expected function 8 got 4

1 0

Re: [PATCH 4/4] msvcp140: Implement _Stat and _Lstat.
by Marvin 11 Jul '17

11 Jul '17

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=32230 Your paranoid android. === wvistau64 (32 bit msvcp140) === 0504:msvcp140: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit msvcp140) === 0504:msvcp140: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 1/2] advapi32/tests: Statically link to ConvertSidToStringSidA()
by Dmitry Timoshkov 11 Jul '17

11 Jul '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > -static BOOL (WINAPI *pConvertSidToStringSidA)( PSID pSid, LPSTR *str ); > static BOOL (WINAPI *pConvertStringSidToSidA)( LPCSTR str, PSID pSid ); ... > - pConvertSidToStringSidA = (void *)GetProcAddress(hmod, "ConvertSidToStringSidA"); > pConvertStringSidToSidA = (void *)GetProcAddress(hmod, "ConvertStringSidToSidA"); ... > - if( !pConvertSidToStringSidA || !pConvertStringSidToSidA ) > + if( !pConvertStringSidToSidA ) What's so special about ConvertSidToStringSidA and why same logic won't apply to ConvertStringSidToSidA and possibly others? -- Dmitry.

2 2

Re: [PATCH 7/7] gdiplus: Add EMF+ properties records tests
by Piotr Caban 11 Jul '17

11 Jul '17

On 07/11/17 11:42, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdiplus/tests/metafile.c | 78 > +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 78 insertions(+) > I've sent it incorrectly so it wasn't picked by testbot. Here are the results: https://testbot.winehq.org/JobDetails.pl?Key=32226 Thanks, Piotr

1 0

Re: [PATCH 2/6] gdiplus: Support GdipSetPixelOffsetMode in metafiles
by Dmitry Timoshkov 11 Jul '17

11 Jul '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > + if(graphics->pixeloffset == mode) > + return Ok; This particular change would need an approproate test case to confirm that repetitive GdipSetPixelOffsetMode() calls with the same value won't generate new records. Same applies to other patches in the series. -- Dmitry.

1 1

Re: [PATCH 1/7] d3dx9/tests: Add test for skip_constants effect parameter.
by Matteo Bruni 11 Jul '17

11 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void test_effect_skip_constants(IDirect3DDevice9 *device) > +{ > + HRESULT hr; > + ID3DXEffect *effect; > + unsigned int passes_count; > + D3DXVECTOR4 fvect; > + unsigned int i; > + > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, "v3", 0, NULL, &effect, NULL); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + if (SUCCEEDED(hr)) > + effect->lpVtbl->Release(effect); > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, "v4", 0, NULL, &effect, NULL); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + if (SUCCEEDED(hr)) > + effect->lpVtbl->Release(effect); > + > + hr = D3DXCreateEffectEx(device, test_effect_skip_constants_blob, sizeof(test_effect_skip_constants_blob), > + NULL, NULL, " v1#,.+-= &\t\nv2*/!\"'v5 v6[1]", 0, NULL, &effect, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); Maybe also add a test with the "expected" syntax for the skip_constants parameters? MSDN mentions a semicolon-separated list. Of course it's not strictly needed, given this test... > + > + todo_wine > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v1", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + todo_wine > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v2", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, "v3", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(effect->lpVtbl->IsParameterUsed(effect, "v4", "tech0"), > + "Unexpected IsParameterUsed result.\n"); > + ok(!effect->lpVtbl->IsParameterUsed(effect, "v5", "tech0"), > + "Unexpected IsParameterUsed result.\n"); What about "v6"?

2 1

Re: [PATCH 5/7] d3dx9: Fail effect creation when shader parameter evaluator creation fails.
by Matteo Bruni 11 Jul '17

11 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -6099,8 +6100,9 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * > { > if (FAILED(hr = d3dx9_create_object(base, object))) > return hr; > - d3dx_create_param_eval(base, object->data, object->size, param->type, > - &param->param_eval, get_version_counter_ptr(base)); > + if (FAILED(hr = d3dx_create_param_eval(base, object->data, object->size, param->type, > + &param->param_eval, get_version_counter_ptr(base)))) > + return hr; > } > break; > > @@ -6138,8 +6140,11 @@ static HRESULT d3dx9_parse_resource(struct d3dx9_base_effect *base, const char * It looks like you missed another call to d3dx_create_param_eval() in between these two.

2 1

Re: [PATCH 2/5] regedit: Use 'return' statements in delete_registry_key() to allow for memory clean-up
by Alexandre Julliard 11 Jul '17

11 Jul '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -1593,11 +1593,11 @@ void delete_registry_key(WCHAR *reg_key_name) > > if (!(key_class = parse_key_name(reg_key_name, &key_name))) { > output_message(STRING_INCORRECT_REG_CLASS, reg_key_name); > - exit(1); > + return; > } > if (!*key_name) { > output_message(STRING_DELETE_REG_CLASS_FAILED, reg_key_name); > - exit(1); > + return; If the process is going to exit anyway, freeing memory is a waste of time. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 3/9] msvcr120: Remove precompiler check for asinh.
by Piotr Caban 11 Jul '17

11 Jul '17

On 07/10/17 06:55, Alex Henrie wrote: > asinh is part of C89, so it is guaranteed to be present. Are you sure about it? As far as I know it's part of C99. The manual for asinh looks strange (it says that it conforms to C89 and gives test macro that checks for never standards). Thanks, Piotr

4 7

Re: [PATCH 6/7] d3dx9: Implement d3dx_shader_get_raw_constant_info() function.
by Matteo Bruni 10 Jul '17

10 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/d3dx9_private.h | 3 +++ > dlls/d3dx9_36/shader.c | 18 ++++++++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/dlls/d3dx9_36/d3dx9_private.h b/dlls/d3dx9_36/d3dx9_private.h > index db80490..bfb3909 100644 > --- a/dlls/d3dx9_36/d3dx9_private.h > +++ b/dlls/d3dx9_36/d3dx9_private.h > @@ -355,4 +355,7 @@ HRESULT d3dx_param_eval_set_shader_constants(ID3DXEffectStateManager *manager, s > struct d3dx_param_eval *peval, BOOL update_all) DECLSPEC_HIDDEN; > BOOL is_param_eval_input_dirty(struct d3dx_param_eval *peval, ULONG64 update_version) DECLSPEC_HIDDEN; > > +const D3DXSHADER_CONSTANTINFO *d3dx_shader_get_raw_constant_info(ID3DXConstantTable *iface, > + D3DXHANDLE constant) DECLSPEC_HIDDEN; > + > #endif /* __WINE_D3DX9_PRIVATE_H */ > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 4dbecb1..11527c8 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -682,6 +682,7 @@ HRESULT WINAPI D3DXPreprocessShaderFromResourceW(HMODULE module, const WCHAR *re > } > > struct ctab_constant { > + const D3DXSHADER_CONSTANTINFO *raw_constant_info; > D3DXCONSTANT_DESC desc; > struct ctab_constant *constants; > }; > @@ -946,6 +947,22 @@ static HRESULT WINAPI ID3DXConstantTableImpl_GetDesc(ID3DXConstantTable *iface, > return D3D_OK; > } > > +const D3DXSHADER_CONSTANTINFO *d3dx_shader_get_raw_constant_info(ID3DXConstantTable *iface, D3DXHANDLE constant) > +{ > + struct ID3DXConstantTableImpl *const_table = impl_from_ID3DXConstantTable(iface); > + struct ctab_constant *c = get_valid_constant(const_table, constant); > + > + TRACE("const_table %p, constant %p.\n", const_table, constant); > + > + if (!c) > + { > + WARN("Invalid argument specified.\n"); > + return NULL; > + } > + > + return c->raw_constant_info; > +} > + > static HRESULT WINAPI ID3DXConstantTableImpl_GetConstantDesc(ID3DXConstantTable *iface, D3DXHANDLE constant, > D3DXCONSTANT_DESC *desc, UINT *count) > { > @@ -2052,6 +2069,7 @@ HRESULT WINAPI D3DXGetShaderConstantTableEx(const DWORD *byte_code, DWORD flags, > { > object->constants[i].desc.RegisterCount = constant_info[i].RegisterCount; > } > + object->constants[i].raw_constant_info = &constant_info[i]; > } > > *constant_table = &object->ID3DXConstantTable_iface; I don't like this all that much. If you need access to the original D3DXSHADER_CONSTANTINFO only for the Reserved field, as in the next patch, I'd say just store that one in struct ctab_constant. Then, for the retrieval part, I don't think it makes much sense to hide our internals from ourselves. You could move the definition of struct ctab_constant to d3dx9_private.h and introduce an internal function to return it from the constant table. You could then entirely replace the use of ID3DXConstantTable_GetConstantDesc(), if you want. Otherwise you can keep that part as-is for the time being and make use of the new function only to get to the Reserved data. Actually, if you go with the latter, it probably makes sense to merge this patch into the next.

1 0

Re: [PATCH 4/7] d3dx9: Get rid of init_set_constants() function.
by Matteo Bruni 10 Jul '17

10 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 58 ++++++++++++++--------------------------------- > 1 file changed, 17 insertions(+), 41 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index cabddcd..1aaf59d 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -305,7 +305,8 @@ static unsigned int get_reg_components(unsigned int table) > > #define PRES_BITMASK_BLOCK_SIZE (sizeof(unsigned int) * 8) > > -static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstantTable *ctab); > +static HRESULT init_set_constants_param(struct d3dx_const_tab *const_tab, ID3DXConstantTable *ctab, > + D3DXHANDLE hc, struct d3dx_parameter *param); With some function reordering this forward declaration shouldn't be necessary at all.

1 0

Re: [PATCH 3/7] d3dx9: Simplify init and cleanup in get_constants_desc().
by Matteo Bruni 10 Jul '17

10 Jul '17

2017-07-06 13:15 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 17 +++-------------- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2fb14ab..cabddcd 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -618,10 +618,6 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > D3DXHANDLE hc; > unsigned int i; > > - out->inputs = cdesc = NULL; > - out->inputs_param = NULL; > - out->input_count = 0; > - inputs_param = NULL; > hr = D3DXGetShaderConstantTable(byte_code, &ctab); > if (FAILED(hr) || !ctab) > { > @@ -635,8 +631,8 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > goto err_out; > } > > - cdesc = HeapAlloc(GetProcessHeap(), 0, sizeof(*cdesc) * desc.Constants); > - inputs_param = HeapAlloc(GetProcessHeap(), 0, sizeof(*inputs_param) * desc.Constants); > + out->inputs = cdesc = HeapAlloc(GetProcessHeap(), 0, sizeof(*cdesc) * desc.Constants); > + out->inputs_param = inputs_param = HeapAlloc(GetProcessHeap(), 0, sizeof(*inputs_param) * desc.Constants); > if (!cdesc || !inputs_param) > { > hr = E_OUTOFMEMORY; > @@ -678,16 +674,9 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab > } > } > out->input_count = desc.Constants; > - out->inputs = cdesc; > - out->inputs_param = inputs_param; > hr = init_set_constants(out, ctab); > - ID3DXConstantTable_Release(ctab); > - return hr; > err_out: > - HeapFree(GetProcessHeap(), 0, cdesc); > - HeapFree(GetProcessHeap(), 0, inputs_param); > - if (ctab) > - ID3DXConstantTable_Release(ctab); > + ID3DXConstantTable_Release(ctab); > return hr; > } It would be a nice cleanup to rename the err_out: label to cleanup:, done: or similar.

1 0

Re: [PATCH 1/2] widl: Only generate Proxy Stubs when functions have the call_as attribute
by Nikolay Sivov 10 Jul '17

10 Jul '17

On 10.07.2017 7:43, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=43302 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > tools/widl/header.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/widl/header.c b/tools/widl/header.c > index 7b97158..e48b488 100644 > --- a/tools/widl/header.c > +++ b/tools/widl/header.c > @@ -1172,7 +1172,7 @@ static void write_method_proto(FILE *header, const type_t *iface) > { > const var_t *func = stmt->u.var; > > - if (!is_local(func->attrs)) { > + if (is_callas(func->attrs)) { > const char *callconv = get_attrp(func->type->attrs, ATTR_CALLCONV); > if (!callconv) callconv = "STDMETHODCALLTYPE"; > /* proxy prototype */ > This is wrong, 'call_as' is used to map different method to be used for remote calls. Midl certainly does not limit prototype generation like that. You mentioned 'odl' attribute on bug report, it's irrelevant too.

2 2

Re: [v2 PATCH] widl: Only generate Proxy Stubs when functions have the call_as attribute
by Huw Davies 10 Jul '17

10 Jul '17

On Mon, Jul 10, 2017 at 10:11:42AM +0000, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=43302 > > v2: Merge two matches together. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/unknwn.idl | 10 ++++++++++ > tools/widl/header.c | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/include/unknwn.idl b/include/unknwn.idl > index 78a2d9db18..7856a7f504 100644 > --- a/include/unknwn.idl > +++ b/include/unknwn.idl > @@ -46,6 +46,16 @@ interface IUnknown > ULONG Release(); > } > > +cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown* This, REFIID riid, void **ppvObject);") > +cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > + > cpp_quote("#ifdef SAVE_WIDL_C_INLINE_WRAPPERS") > cpp_quote("#define WIDL_C_INLINE_WRAPPERS") > cpp_quote("#endif") > diff --git a/tools/widl/header.c b/tools/widl/header.c > index 7b971582db..e48b488ae3 100644 > --- a/tools/widl/header.c > +++ b/tools/widl/header.c > @@ -1172,7 +1172,7 @@ static void write_method_proto(FILE *header, const type_t *iface) > { > const var_t *func = stmt->u.var; > > - if (!is_local(func->attrs)) { > + if (is_callas(func->attrs)) { > const char *callconv = get_attrp(func->type->attrs, ATTR_CALLCONV); > if (!callconv) callconv = "STDMETHODCALLTYPE"; > /* proxy prototype */ On further testing with midl v7, /Os does emit Proxy/Stub prototypes for all functions. Since widl essentially runs in this mode, I'd prefer to keep this behaviour if possible. In the bug you mention redefinition errors in qmgrprxy. How are you getting these? Huw.

1 1

Wine appimage request
by Dpto Catastro Topografia MuniSantaCruz 10 Jul '17

10 Jul '17

Hello, I have used this software and it has been very useful to me, I am a surveyor engineer and free software user. A year ago in the world linux have agreed to generate universal packages self-contained with everything they need to install on any linux distribution. Of which there are today 3; Simon Peter's appimage, Gnome flatpak and Canonical snaps. The advantage of these packages is that they use everything in the same package to work, libraries and so on. Hence they can be installed in any linux distribution. It would be great to see the WINE in appimage or in flatpak or snap, and avoid using the terminal for new users. I somehow defend myself with the terminal but sometimes it is still somewhat annoying and tedious. I leave you the links of these new packaging technologies, so that you can analyze them and may in the not too distant future offer some of these simple packages. In fact I prefer appimage, I downloaded several of these applications with this type of package and is simple to use and distribute. Flatpak and snap are still using the terminal to install them, the snaps are fairly simple (it will be installed in the gnome and kde software center in 2018), flatpak the gnome desktop and kde install it from the software center to install packages Flatpak. Appimage has its own charm and does not use the terminal, just make executable and run. Thank you Links Http://appimage.org/ Http://flatpak.org/ Https://snapcraft.io/ atte Luis V --

1 0

Re: [PATCH 5/5] d3drm: Assign animation key ids
by Henri Verbeet 10 Jul '17

10 Jul '17

On 10 July 2017 at 12:40, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static BOOL d3drm_animation_get_next_key_id(struct d3drm_animation_keys *keys, DWORD *id) > +{ > + DWORD i; > + > + if (keys->next_unused <= keys->last_id) > + { > + *id = keys->next_unused++; > + return TRUE; > + } > + > + if (keys->next_free <= keys->last_id) > + { > + *id = keys->next_free; > + keys->next_free = ~0u; > + return TRUE; > + } > + > + if (keys->count == keys->last_id - keys->first_id + 1) > + return FALSE; > + > + /* Worst case, look for the spot from the beginning. */ > + for (i = 0, *id = keys->first_id; i < keys->count; i++, ++*id) > + { > + if (*id != keys->keys[i].id) > + break; > + } Does that work? The keys aren't necessarily ordered by ID, right? Regardless, it may be easier to make use of the fact that we never shrink the keys array.

1 0

Re: server: Don't allow APCs on objects associated with completion port.
by Marvin 10 Jul '17

10 Jul '17

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=32203 Your paranoid android. === w7u (32 bit sock) === sock.c:6121: Test failed: Expected event sequence [FD_WRITE(0)], got [] sock.c:6142: Test failed: Expected event sequence [FD_READ(0) FD_CLOSE(0)], got [FD_WRITE(0) FD_CLOSE(10053)] sock.c:6145: Test failed: Failed to empty buffer: -1 - 10054 sock.c:6146: Test failed: Expected event sequence [FD_READ(0)], got [] sock.c:6149: Test failed: Failed to empty buffer: -1 - 10054

1 0

Re: [PATCH 2/2] msvcp140: Implement _File_size.
by Piotr Caban 10 Jul '17

10 Jul '17

On 07/09/17 22:14, Stefan Dösinger wrote: > static int (__cdecl *p_To_wide)(const char *src, WCHAR *dst); > +static ULONGLONG(__cdecl *p_File_size)(WCHAR const*); Please add a space after ULONGLONG. > +static void test_File_size(void) > +{ > + ULONGLONG val; > + HANDLE file; > + LARGE_INTEGER file_size; > + WCHAR test_f1_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','f','1',0}; > + WCHAR test_f2_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','f','2',0}; > + WCHAR test_dir_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r',0}; > + WCHAR test_ne_W[] = {'t','r','2','_','t','e','s','t','_','d','i','r','/','n','e',0}; > + CreateDirectoryW(test_dir_W, NULL); Could you please create the test files in temp directory? Also please rename the directory (these are no longer tr2 namespace tests). > +/* _File_size, msvcp140 version. Different error handling. */ > +ULONGLONG __cdecl _File_size(WCHAR const* path) > +{ > + WIN32_FILE_ATTRIBUTE_DATA fad; > + > + TRACE("(%s)\n", debugstr_w(path)); > + if(!GetFileAttributesExW(path, GetFileExInfoStandard, &fad)) > + return ~0ULL; > + if(fad.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + return 0; We don't need to handle the directory separately here. It will have file size set to 0 anyway. Thanks, Piotr

1 0

Re: advapi32/tests: Add tests for RegSetValueExW and RegQueryValueExW.
by Alexandre Julliard 10 Jul '17

10 Jul '17

Jactry Zeng <jzeng(a)codeweavers.com> writes: > Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com> > --- > dlls/advapi32/tests/registry.c | 46 > +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) I don't see how this is different from the existing tests. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: user.exe16: Fix an incorrect use of ADD_TO_T in FormatMessage16.
by Henri Verbeet 10 Jul '17

10 Jul '17

On 9 July 2017 at 18:53, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > ADD_TO_T actually consists of two statements > > #define ADD_TO_T(c) \ > *t++=c;\ > if (t-target == talloced) {\ > target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,talloced*2);\ > t = target+talloced;\ > talloced*=2;\ > } > > so > > for (x=b; *x; x++) ADD_TO_T(*x); > > does _not_ actually do what one might expect/hope. > > Fixed thusly, in line with other usage. > Alternatively, it shouldn't be hard to either fix the macro or replace it with a function.

1 0

Re: [PATCH 2/2] include: Add Proxy stubs for IUnknown
by Huw Davies 10 Jul '17

10 Jul '17

On Mon, Jul 10, 2017 at 04:43:49AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/unknwn.idl | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/unknwn.idl b/include/unknwn.idl > index 78a2d9d..7856a7f 100644 > --- a/include/unknwn.idl > +++ b/include/unknwn.idl > @@ -46,6 +46,16 @@ interface IUnknown > ULONG Release(); > } > > +cpp_quote("HRESULT STDMETHODCALLTYPE IUnknown_QueryInterface_Proxy(IUnknown* This, REFIID riid, void **ppvObject);") > +cpp_quote("void __RPC_STUB IUnknown_QueryInterface_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_AddRef_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_AddRef_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") > +cpp_quote("ULONG STDMETHODCALLTYPE IUnknown_Release_Proxy(IUnknown* This);") > +cpp_quote("void __RPC_STUB IUnknown_Release_Stub(IRpcStubBuffer* This, IRpcChannelBuffer* pRpcChannelBuffer,") > +cpp_quote(" PRPC_MESSAGE pRpcMessage, DWORD* pdwStubPhase);") What do you need these for? Huw.

1 0

Re: msvcp140: implement _To_byte
by Nikolay Sivov 09 Jul '17

09 Jul '17

On 08.07.2017 22:33, Mikhail Paulyshka wrote: > Signed-off-by: Mikhail Paulyshka <me(a)mixaill.tk> > --- > dlls/msvcp140/msvcp140.spec | 2 +- > dlls/msvcp140/tests/msvcp140.c | 49 ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcp90/locale.c | 10 +++++++++ > 3 files changed, 60 insertions(+), 1 deletion(-) > Hi, and thanks for the patch. Some comments in addition to Stefan's reply: > + static const WCHAR test_2[] = {0xfe95, 0xfea0, 0xfea6, 0}; //some arabic glyphs These are characters, not glyphs. Also please use C-style comments - /**/.

3 2

Re: notepad: Fix string length calculating.
by Nikolay Sivov 09 Jul '17

09 Jul '17

Do we have RegSetValueExW tests to justify this?

3 2

Re: msvcp140: implement _To_byte
by Stefan Dösinger 09 Jul '17

09 Jul '17

Hi, I was about to implement this function too, but it seems you've beaten me by two days :-) . Am 2017-07-08 um 17:55 schrieb Mikhail Paulyshka: > + WCHAR longstr[MAX_PATH + 3]; > + memset(longstr, 'A', sizeof(longstr)); This memset doesn't do what you probably expect. It doesn't fill the string with 'A's, but instead with U+4141 characters (䅁, http://www.fileformat.info/info/unicode/char/4141/index.htm). > + if (!src || !dst) > + return 0; This is redundant. WideCharToMultiByte checks this for you and returns 0. I noticed this after sending the _To_wide patch and will send a patch removing the redundant check from _To_wide.

2 3

Re: [PATCH] notepad: Use the default window position and size.
by Henri Verbeet 08 Jul '17

08 Jul '17

On 8 July 2017 at 01:58, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > @@ -775,17 +774,9 @@ int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE prev, LPSTR cmdline, int show) > info.cbSize = sizeof(info); > GetMonitorInfoW( monitor, &info ); > > - x = main_rect.left; > - y = main_rect.top; > - if (main_rect.left >= info.rcWork.right || > - main_rect.top >= info.rcWork.bottom || > - main_rect.right < info.rcWork.left || > - main_rect.bottom < info.rcWork.top) > - x = y = CW_USEDEFAULT; > - > Globals.hMainWnd = > - CreateWindowW(className, winName, WS_OVERLAPPEDWINDOW, x, y, > - main_rect.right - main_rect.left, main_rect.bottom - main_rect.top, > + CreateWindowW(className, winName, WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > NULL, NULL, Globals.hInstance, NULL); > if (!Globals.hMainWnd) > { Why would you want to do that? But if we're going to ignore it, we probably shouldn't bother saving and loading the window position to/from the registry either.

3 3

Compile MFC application
by MAX Trifonov 08 Jul '17

08 Jul '17

Hello I try compile my application with winemaker ... winemaker --lower-uppercase --mfc -I/home/max/libffc-master/Include -I/home/max/wine/include DN After make I have got result: wineg++ -c -I/home/max/libffc-master/Include -I/home/max/wine/include -I. -o Big.o Big.cpp In file included from /home/max/wine/include/windows.h:70:0, from /home/max/libffc-master/Include/FFC/Globals.h:6, from /home/max/libffc-master/Include/afx.h:13, from /home/max/libffc-master/Include/afxwin.h:13, from StdAfx.h:16, from Big.cpp:2: /home/max/wine/include/winscard.h:22:20: fatal error: wtypes.h: Why wtypes.h not included ? -- MAX Trifonov

1 0

Re: [PATCH 1/2] explorer: Improve tray sizing and style.
by Dmitry Timoshkov 08 Jul '17

08 Jul '17

Zebediah Figura <zfigura(a)codeweavers.com> wrote: > - SetWindowPos( win->button, 0, pos, 0, start_button_width, tray_height, > + SetWindowPos( win->button, 0, pos, 0, start_button_width, tray_height - 4, > SWP_NOZORDER | SWP_NOACTIVATE | SWP_SHOWWINDOW ); ... > - SetWindowPos( win->button, 0, pos, 0, width, tray_height, > + SetWindowPos( win->button, 0, pos, 0, width, tray_height - 4, > SWP_NOZORDER | SWP_NOACTIVATE | SWP_SHOWWINDOW ); ... > tray_width = GetSystemMetrics( SM_CXSCREEN ); > tray_height = max( icon_cy, size.cy ); > + tray_height = max( tray_height, 26 ); ... > start_button_width = size.cx; > - SetWindowPos( tray_window, HWND_TOPMOST, 0, GetSystemMetrics( SM_CYSCREEN ) - tray_height, > - tray_width, tray_height, SWP_NOACTIVATE | SWP_SHOWWINDOW ); > + SetWindowPos( tray_window, HWND_TOPMOST, -2, GetSystemMetrics(SM_CYSCREEN) - tray_height - 2, > + tray_width + 4, tray_height + 4, SWP_NOACTIVATE | SWP_SHOWWINDOW ); I guess that magic -4/-2 are caused by added WS_THICKFRAME style, if that's the case an appropriate system metric should be used instead to make the code work for different visual themes. 26 above also needs to be changed to an appropriate system metric. -- Dmitry.

1 0

Re: [PATCH 3/3] mfplat/tests: Add MFCreateAttributes test
by Marvin 08 Jul '17

08 Jul '17

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

1 0

Re: [PATCH] include: Support all version of BackgroundCopyManager from bits.h
by Alexandre Julliard 07 Jul '17

07 Jul '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -22,12 +22,6 @@ > > #include "bits.idl" > > -#define DO_NO_IMPORTS > -#include "bits1_5.idl" > -#include "bits2_0.idl" > -#include "bits2_5.idl" > -#include "bits3_0.idl" This breaks the registration: ../../../tools/runtest -q -P wine -T ../../.. -M qmgr.dll -p qmgr_test.exe.so job && touch job.ok job.c:700: Test failed: Tests need BITS 2.0 or higher job.c:719: Test failed: Tests need BITS 2.5 or higher Makefile:285: recipe for target 'job.ok' failed make: *** [job.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Handle IMAGE_REL_BASED_DIR64 for arm64 in the same way as for x86_64
by Jacek Caban 07 Jul '17

07 Jul '17

Hi Martin, On 07.07.2017 12:39, Martin Storsjo wrote: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 518a99f..3b784bf 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2476,7 +2476,7 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count > case IMAGE_REL_BASED_HIGHLOW: > *(int *)((char *)page + offset) += delta; > break; > -#ifdef __x86_64__ > +#if defined(__x86_64__) || defined(__aarch64__) Could it use simply #ifdef _WIN64? Thanks, Jacek

1 0

Re: [1/2] vcomp: Add ARM64 support
by Alexandre Julliard 07 Jul '17

07 Jul '17

Sebastian Lackner <sebastian(a)fds-team.de> writes: > On 05.07.2017 21:23, André Hentschel wrote: >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> dlls/vcomp/main.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 45 insertions(+) >> > > I have no ARM64 setup available, so please double-check that it actually > compiles before applying the patch. ;) It doesn't: aarch64-linux-android-clang -c -o main.o ../../../wine/dlls/vcomp/main.c -I. -I../../../wine/dlls/vcomp -I../../include \ -I../../../wine/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits \ -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -g -O2 -fno-caret-diagnostics -Wno-tautological-constant-out-of-range-compare -Wno-enum-conversion -Wno-sometimes-uninitialized -Wno-ignored-attributes -Wno-array-bounds -Wno-absolute-value -Wno-unused-function -Wno-incompatible-pointer-types -Wno-invalid-source-encoding <inline asm>:36:2: error: too few operands for instruction Makefile:166: recipe for target 'main.o' failed make: *** [main.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] vcomp: Add ARM64 support
by Sebastian Lackner 07 Jul '17

07 Jul '17

On 05.07.2017 21:23, André Hentschel wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/vcomp/main.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > Just recently it was mentioned on the mailing lists that compilers do not support ms_va_list on ARM64 yet. Does your code rely on any compiler patches, or do you assume that va_list == ms_va_list?

2 2

Re: [PATCH 3/6] msi: Correctly format the template field for MsiProcessMessage().
by Hans Leidekker 07 Jul '17

07 Jul '17

This one no longer applies after [PATCH v2 2/6] msi: Implement UI messages for dialogs: $ curl --silent -o - https://source.winehq.org/patches/data/135555 | git apply --verbose Checking patch dlls/msi/dialog.c... Checking patch dlls/msi/msi.rc... Checking patch dlls/msi/msipriv.h... Checking patch dlls/msi/package.c... Checking patch dlls/msi/resource.h... Checking patch dlls/msi/tests/package.c... error: while searching for: MsiCloseHandle(hpkg); ok_sequence(closehandle_sequence, "MsiCloseHandle()", TRUE); CoUninitialize(); DeleteFileA(msifile); DeleteFileA("forcecodepage.idt"); error: patch failed: dlls/msi/tests/package.c:9552 error: dlls/msi/tests/package.c: patch does not apply

1 0

Re: [PATCH 3/5] msi: Implement UI messages for dialogs.
by Alexandre Julliard 06 Jul '17

06 Jul '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msi/action.c | 74 +++++++++++++-------------- > dlls/msi/custom.c | 2 +- > dlls/msi/dialog.c | 55 +++++++++++++++++++- > dlls/msi/msi.rc | 3 +- > dlls/msi/msipriv.h | 1 + > dlls/msi/package.c | 7 +++ > dlls/msi/resource.h | 1 + > dlls/msi/tests/package.c | 130 +++++++++++++++++++++++++++++++++++++++++++++-- > 8 files changed, 225 insertions(+), 48 deletions(-) This is causing the test to leave behind a winetest-package.msi file. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32/tests: A spelling fix in a comment.
by Marvin 06 Jul '17

06 Jul '17

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=32127 Your paranoid android. === wvistau64 (64 bit sock) === sock.c:8273: Test failed: bytesReturned isn't supposed to be 1 sock.c:8297: Test failed: GetOverlappedResult failed, error 997

1 0

Re: [PATCH 2/2] regedit: Null-terminate REG_EXPAND_SZ and REG_MULTI_SZ data if the parsed hex data does not end in a null-te
by Marvin 06 Jul '17

06 Jul '17

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=32126 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/2] regedit: Hex data lines may be terminated by a semicolon
by Marvin 06 Jul '17

06 Jul '17

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=32125 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/5] msi: Don't increment the refcount when creating dialogs.
by Hans Leidekker 06 Jul '17

06 Jul '17

On Wed, 2017-07-05 at 23:31 -0500, Zebediah Figura wrote: > We should only ever have one dialog anyway, and this is destroyed > when we close the package. It causes a crash in a random installer here: $ ./wine msiexec /i "XPSEP XP and Server 2003 32 bit.msi" fixme:ntdll:NtLockFile I/O completion on lock not implemented yet err:msi:msiobj_addref Invalid handle! err:msi:msiobj_addref Invalid handle! wine: Unhandled page fault on read access to 0x57e5896d at address 0x7ed68688 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x57e5896d in 32-bit code (0x7ed68688). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ed68688 ESP:0032d078 EBP:0032d088 EFLAGS:00210202( R- -- I - - - ) EAX:57e5896d EBX:7edaf2f4 ECX:00151018 EDX:7ed686d0 ESI:57e58949 EDI:00000045 Stack dump: 0x0032d078: 00150c40 7edaee74 00150c40 00150c40 0x0032d088: 0032d0e8 7ed6b4ae 7ed84b14 00000016 0x0032d098: 0032d0c8 7edaee40 4d430003 00000000 0x0032d0a8: 00000000 00000000 00000000 00000000 0x0032d0b8: 4d430000 0014947c 0000001c 7bc4fc76 0x0032d0c8: 0032d0f0 7edaf2f4 7edaee40 00150c40 Backtrace: =>0 0x7ed68688 find_cached_table+0x28(db=<is not available>, name="EventMapping") [/home/hans/wine/dlls/msi/../../include/wine/unicode.h:216] in msi (0x0032d088) 1 0x7ed6b4ae get_table+0x1d() in msi (0x0032d0e8) 2 0x7ed6c9e8 TABLE_CreateView+0xe7(db=0x7edaee40, name="EventMapping", view=0x14946c) [/home/hans/wine/dlls/msi/table.c:2179] in msi (0x0032d128) 3 0x7ed72857 WHERE_CreateView+0xe6(db=0x7edaee40, view=0x32d1e4, tables="EventMapping", cond=0x149400) [/home/hans/wine/dlls/msi/where.c:1242] in msi (0x0032d178) fixme:dbghelp_dwarf:compute_location Only supporting one reg (ebp/22 -> -2) 4 0x7ed75cd2 sql_parse+0xd71(info=0x32d9f4) [/home/hans/wine/dlls/msi/sql.y:506] in msi (0x0032d9d8) 5 0x7ed763af MSI_ParseSQL+0x4e(db=0x7edaee40, command="SELECT * FROM `EventMapping` WHERE `Dialog_` = 'ProgressForm' AND `Control_` = 'NextButton'", phview=0x154370, mem=0x15437c) [/home/hans/wine/dlls/msi/sql.y:1002] in msi (0x0032da18) 6 0x7ed49012 MSI_DatabaseOpenViewW+0x71() in msi (0x0032da58) 7 0x7ed4911f MSI_OpenQuery+0x8e(db=0x7edaee40, view=0x32dac4, fmt="SELECT * FROM `EventMapping` WHERE `Dialog_` = '%s' AND `Control_` = '%s'") [/home/hans/wine/dlls/msi/msiquery.c:163] in msi (0x0032da98) 8 0x7ed21ce2 dialog_map_events+0x31(dialog=<is not available>, control=<is not available>) [/home/hans/wine/dlls/msi/dialog.c:761] in msi (0x0032dad8) 9 0x7ed26a9e msi_dialog_add_control+0xad(dialog=0x15e0b8, rec=0x154218, szCls="BUTTON", style=0x18010000) [/home/hans/wine/dlls/msi/dialog.c:791] in msi (0x0032db18) 10 0x7ed28dfa msi_dialog_button_control+0xf9(dialog=0x15e0b8, rec=0x154218) [/home/hans/wine/dlls/msi/dialog.c:1011] in msi (0x0032db58) 11 0x7ed22070 msi_dialog_create_controls+0xaf(rec=0x154218, param=0x15e0b8) [/home/hans/wine/dlls/msi/dialog.c:3475] in msi (0x0032db88) 12 0x7ed49a2a MSI_IterateRecords+0x79(view=0x1f0e48, count=0x0(nil), func=0x7ed21fc0, param=0x15e0b8) [/home/hans/wine/dlls/msi/msiquery.c:188] in msi (0x0032dbd8) 13 0x7ed264f2 MSIDialog_WndProc+0xb71(hwnd=<couldn't compute location>, msg=<couldn't compute location>, wParam=<couldn't compute location>, lParam=<couldn't compute location>) [/home/hans/wine/dlls/msi/dialog.c:3502] in msi (0x0032dcd8) 14 0x7e9ee37a WINPROC_wrapper+0x19() in user32 (0x0032dd18) 15 0x7e9ee9ba call_window_proc+0x49(hwnd=0x2005a, msg=0x1, wp=0, lp=0x32e050, result=0x32dde8, arg=0x7ed25980) [/home/hans/wine/dlls/user32/winproc.c:245] in user32 (0x0032dd68) 16 0x7e9f0ce5 WINPROC_call_window+0xc4(hwnd=0x2005a, msg=0x1, wParam=0, lParam=0x32e050, result=0x32dde8, unicode=0x1, mapping=2124605252) [/home/hans/wine/dlls/user32/winproc.c:920] in user32 (0x0032ddb8) 17 0x7e9b4b14 call_window_proc+0x63(hwnd=0x2005a, msg=0x1, wparam=0, lparam=0x32e050, unicode=0x1, same_thread=0x1, mapping=2124605252) [/home/hans/wine/dlls/user32/message.c:2224] in user32 (0x0032de18) 18 0x7e9bbb0e send_message+0x1bd(info=0x32dea4, res_ptr=0x32dea0, unicode=0x1) [/home/hans/wine/dlls/user32/message.c:3269] in user32 (0x0032de88) 19 0x7e9bbd61 SendMessageW+0x50(hwnd=<couldn't compute location>, msg=<couldn't compute location>, wparam=<couldn't compute location>, lparam=<couldn't compute location>) [/home/hans/wine/dlls/user32/message.c:3469] in user32 (0x0032ded8) 20 0x7e9e54aa WIN_CreateWindowEx+0xba9(cs=0x32e050, className="MsiDialogCloseClass", module=(nil), unicode=0x1) [/home/hans/wine/dlls/user32/win.c:1641] in user32 (0x0032e038) 21 0x7e9df098 CreateWindowExW+0x72(exStyle=<couldn't compute location>, className=<couldn't compute location>, windowName=<couldn't compute location>, style=<couldn't compute location>, x=<couldn't compute location>, y=<couldn't compute location>, width=<couldn't compute location>, height=<couldn't compute location>, parent=<couldn't compute location>, menu=<couldn't compute location>, instance=<couldn't compute location>, data=<couldn't compute location>) [/home/hans/wine/dlls/user32/win.c:1776] in user32 (0x0032e088) 22 0x7ed231c6 dialog_run_message_loop+0x65() in msi (0x0032e0f8) 23 0x7ed2ad43 event_do_dialog+0x42(package=0x13f538, name=<is not available>, parent=(nil), destroy_modeless=0x1) [/home/hans/wine/dlls/msi/dialog.c:4349] in msi (0x0032e128) 24 0x7ed2c0e9 ACTION_DialogBox+0x48(package=0x13f538, dialog="ProgressForm") [/home/hans/wine/dlls/msi/dialog.c:4567] in msi (0x0032e168) 25 0x7ed4c8ca MSI_ProcessMessage+0x5d9(package=0x13f538, eMessageType=INSTALLMESSAGE_SHOWDIALOG, record=0x146d60) [/home/hans/wine/dlls/msi/package.c:1794] in msi (0x0032f288) 26 0x7ed2bfc7 ACTION_ShowDialog+0x76(package=0x13f538, dialog="ProgressForm") [/home/hans/wine/dlls/msi/dialog.c:4522] in msi (0x0032fac8) 27 0x7ecfad88 ACTION_HandleCustomAction.part+0x77() in msi (0x0032faf8) 28 0x7ed0ab3c ACTION_PerformUIAction+0xab() in msi (0x0032fb38) 29 0x7ed0acdc ITERATE_Actions+0x13b(row=0x152b60, param=0x13f538) [/home/hans/wine/dlls/msi/action.c:499] in msi (0x0032fb78) 30 0x7ed49a2a MSI_IterateRecords+0x79(view=0x146928, count=0x0(nil), func=0x7ed0aba0, param=0x13f538) [/home/hans/wine/dlls/msi/msiquery.c:188] in msi (0x0032fbc8) 31 0x7ed0b463 MSI_InstallPackage+0x4f2(package=0x13f538, szPackagePath="XPSEP XP and Server 2003 32 bit.msi", szCommandLine=0x0(nil)) [/home/hans/wine/dlls/msi/action.c:604] in msi (0x0032fc18) 32 0x7ed3dd51 MsiInstallProductW+0xc0(szPackagePath=<is not available>, szCommandLine=<is not available>) [/home/hans/wine/dlls/msi/msi.c:251] in msi (0x0032fc68) 33 0x7efefbee WinMain+0x73d(hInstance=<is not available>, hPrevInstance=<is not available>, lpCmdLine=<is not available>, nCmdShow=<is not available>) [/home/hans/wine/programs/msiexec/msiexec.c:994] in msiexec (0x0032fd48) 34 0x7efee904 main+0xc3(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/hans/wine/dlls/winecrt0/exe_main.c:49] in msiexec (0x0032fde8) 35 0x7eff12ff __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/hans/wine/dlls/winecrt0/exe_entry.c:36] in msiexec (0x0032fe38) 36 0x7b45ee6c call_process_entry+0xb() in kernel32 (0x0032fe58) 37 0x7b45fe09 start_process+0x68(entry=<couldn't compute location>) [/home/hans/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0032fe98) 38 0x7bc7e5b0 call_thread_func_wrapper+0xb() in ntdll (0x0032feb8) 39 0x7bc813a1 call_thread_func+0xb0(entry=0x7b45fda0, arg=0x7eff1290, frame=0x32ffc8) [/home/hans/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0032ffa8) 40 0x7bc7e58e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 41 0x7bc53473 start_process+0x12(arg=0xffaf6bd8) [/home/hans/wine/dlls/ntdll/loader.c:3083] in ntdll (0x0032ffe8) 42 0xf757d81d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 43 0xf757d980 wine_switch_to_stack+0x1f(func=0x7bc53460, arg=0xffaf6bd8, stack=0x330000) [/home/hans/wine/libs/wine/port.c:77] in libwine.so.1 (0xffaf6ba8) 44 0x7bc5911a LdrInitializeThunk+0x239(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/hans/wine/dlls/ntdll/loader.c:3144] in ntdll (0xffaf6bf8) 45 0x7b465c33 __wine_kernel_init+0x962() [/home/hans/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffaf7ae8) 46 0x7bc59ee3 __wine_process_init+0x152() [/home/hans/wine/dlls/ntdll/loader.c:3353] in ntdll (0xffaf7b58) 47 0xf757bbe3 wine_init+0x292(argc=0x4, argv=0xffaf8094, error="", error_size=0x400) [/home/hans/wine/libs/wine/loader.c:974] in libwine.so.1 (0xffaf7ba8) 48 0x7c000aaa main+0x79(argc=<is not available>, argv=<is not available>) [/home/hans/wine/loader/main.c:258] in <wine-loader> (0xffaf7fe8) 49 0xf739ea63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7ed68688 find_cached_table+0x28 [/home/hans/wine/dlls/msi/../../include/wine/unicode.h:216] in msi: cmpw 0x24(%esi),%di 216 while (*str1 && (*str1 == *str2)) { str1++; str2++; }

1 0

Re: [PATCH 2/5] msi: Add a basic internal UI implementation.
by Marvin 06 Jul '17

06 Jul '17

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=32104 Your paranoid android. === w7u (32 bit msi) === The task timed out

1 0

Re: [2/2] vcomp/tests: Test more arguments with a callback
by Sebastian Lackner 05 Jul '17

05 Jul '17

On 05.07.2017 21:23, André Hentschel wrote: > - p_vcomp_fork(TRUE, 5, fork_uintptr_cb, (UINT_PTR)1, (UINT_PTR)(MAXUINT_PTR - 2), > - (UINT_PTR)3, (UINT_PTR)(MAXUINT_PTR - 4), (UINT_PTR)5); > + p_vcomp_fork(TRUE, 12, fork_uintptr_cb, (UINT_PTR)1, (UINT_PTR)(MAXUINT_PTR - 2), > + (UINT_PTR)3, (UINT_PTR)(MAXUINT_PTR - 4), (UINT_PTR)5, > + (UINT_PTR)6, (UINT_PTR)7, (UINT_PTR)8, (UINT_PTR)9, > + (UINT_PTR)10, (UINT_PTR)11); Shouldn't the second argument be 11?

2 1

Re: [PATCH 3/3] d3dx9/tests: Add tests for array of samplers.
by Matteo Bruni 05 Jul '17

05 Jul '17

2017-06-28 13:28 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: Sorry for the delayed reviews. I did it at last... > #define test_effect_preshader_compare_shader_bytecode(a, b, c, d) \ > @@ -4505,12 +4551,38 @@ static void test_effect_preshader(IDirect3DDevice9 *device) > hr = IDirect3DDevice9_GetSamplerState(device, 0, D3DSAMP_MAGFILTER, &value); > ok(hr == D3D_OK, "Got result %#x.\n", hr); > todo_wine ok(value == 3, "Unexpected sampler 0 magfilter %u.\n", value); > + > + hr = IDirect3DDevice9_GetSamplerState(device, 1, D3DSAMP_MINFILTER, &value); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + ok(value == 1, "Unexpected sampler 1 minfilter %u.\n", value); > + hr = IDirect3DDevice9_GetSamplerState(device, 1, D3DSAMP_MAGFILTER, &value); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + todo_wine > + ok(value == 1, "Unexpected sampler 1 magfilter %u.\n", value); Not new or really related to this patch: any idea about what's going on with the magfilter state computation? I didn't really look into it, does it have to do with default parameter values by any chance?

2 7

Re: [PATCH] dmime: Rename IPersistStreamImpl_Load functions
by Michael Stefaniuc 05 Jul '17

05 Jul '17

Hello Alistair, On 07/05/2017 08:17 AM, Alistair Leslie-Hughes wrote: > When a log had IPersistStreamImpl_Load entry from dmime, it's > quiet confusing to which of the _Load function was used. could you please change the "persist_stream" part of the new name to "IPersistStream"? That way it is consistent with the other method names. thanks bye michael > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmime/lyricstrack.c | 4 ++-- > dlls/dmime/markertrack.c | 4 ++-- > dlls/dmime/paramcontroltrack.c | 4 ++-- > dlls/dmime/segment.c | 4 ++-- > dlls/dmime/segtriggertrack.c | 4 ++-- > dlls/dmime/seqtrack.c | 4 ++-- > dlls/dmime/sysextrack.c | 4 ++-- > dlls/dmime/tempotrack.c | 4 ++-- > dlls/dmime/timesigtrack.c | 4 ++-- > dlls/dmime/wavetrack.c | 4 ++-- > 10 files changed, 20 insertions(+), 20 deletions(-) > > diff --git a/dlls/dmime/lyricstrack.c b/dlls/dmime/lyricstrack.c > index 70382735d5..66293526dc 100644 > --- a/dlls/dmime/lyricstrack.c > +++ b/dlls/dmime/lyricstrack.c > @@ -240,7 +240,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI lyrics_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -252,7 +252,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + lyrics_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/markertrack.c b/dlls/dmime/markertrack.c > index 852948ab40..0fe72f9c91 100644 > --- a/dlls/dmime/markertrack.c > +++ b/dlls/dmime/markertrack.c > @@ -188,7 +188,7 @@ static const IDirectMusicTrackVtbl dmtrack_vtbl = { > IDirectMusicTrackImpl_Clone > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI marker_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -200,7 +200,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + marker_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/paramcontroltrack.c b/dlls/dmime/paramcontroltrack.c > index affea1da90..a7bc873c97 100644 > --- a/dlls/dmime/paramcontroltrack.c > +++ b/dlls/dmime/paramcontroltrack.c > @@ -240,7 +240,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI param_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -252,7 +252,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + param_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/segment.c b/dlls/dmime/segment.c > index ad8561fcae..be4a850556 100644 > --- a/dlls/dmime/segment.c > +++ b/dlls/dmime/segment.c > @@ -1171,7 +1171,7 @@ static inline IDirectMusicSegment8Impl *impl_from_IPersistStream(IPersistStream > return CONTAINING_RECORD(iface, IDirectMusicSegment8Impl, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI seg_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicSegment8Impl *This = impl_from_IPersistStream(iface); > HRESULT hr; > @@ -1248,7 +1248,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + seg_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/segtriggertrack.c b/dlls/dmime/segtriggertrack.c > index d1b208a6d0..17d5da2db5 100644 > --- a/dlls/dmime/segtriggertrack.c > +++ b/dlls/dmime/segtriggertrack.c > @@ -456,7 +456,7 @@ static inline IDirectMusicSegTriggerTrack *impl_from_IPersistStream(IPersistStre > return CONTAINING_RECORD(iface, IDirectMusicSegTriggerTrack, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI trigger_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicSegTriggerTrack *This = impl_from_IPersistStream(iface); > DMUS_PRIVATE_CHUNK Chunk; > @@ -505,7 +505,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + trigger_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/seqtrack.c b/dlls/dmime/seqtrack.c > index 2d80db75cd..7e74fa6036 100644 > --- a/dlls/dmime/seqtrack.c > +++ b/dlls/dmime/seqtrack.c > @@ -242,7 +242,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI track_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -254,7 +254,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + track_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/sysextrack.c b/dlls/dmime/sysextrack.c > index 431fca7227..ba7a8fdc7c 100644 > --- a/dlls/dmime/sysextrack.c > +++ b/dlls/dmime/sysextrack.c > @@ -242,7 +242,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI sys_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -254,7 +254,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + sys_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/tempotrack.c b/dlls/dmime/tempotrack.c > index 70de44228f..3c6f957571 100644 > --- a/dlls/dmime/tempotrack.c > +++ b/dlls/dmime/tempotrack.c > @@ -320,7 +320,7 @@ static inline IDirectMusicTempoTrack *impl_from_IPersistStream(IPersistStream *i > return CONTAINING_RECORD(iface, IDirectMusicTempoTrack, dmobj.IPersistStream_iface); > } > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *pStm) > +static HRESULT WINAPI tempo_persist_stream_Load(IPersistStream *iface, IStream *pStm) > { > IDirectMusicTempoTrack *This = impl_from_IPersistStream(iface); > DMUS_PRIVATE_CHUNK Chunk; > @@ -375,7 +375,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + tempo_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/timesigtrack.c b/dlls/dmime/timesigtrack.c > index 9bd7450264..72fdac8cbe 100644 > --- a/dlls/dmime/timesigtrack.c > +++ b/dlls/dmime/timesigtrack.c > @@ -189,7 +189,7 @@ static const IDirectMusicTrackVtbl dmtack_vtbl = { > IDirectMusicTrackImpl_Clone > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI time_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -201,7 +201,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + time_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; > diff --git a/dlls/dmime/wavetrack.c b/dlls/dmime/wavetrack.c > index bc6e3ca413..20656a9362 100644 > --- a/dlls/dmime/wavetrack.c > +++ b/dlls/dmime/wavetrack.c > @@ -249,7 +249,7 @@ static const IDirectMusicTrack8Vtbl dmtrack8_vtbl = { > IDirectMusicTrack8Impl_Join > }; > > -static HRESULT WINAPI IPersistStreamImpl_Load(IPersistStream *iface, IStream *stream) > +static HRESULT WINAPI wave_persist_stream_Load(IPersistStream *iface, IStream *stream) > { > FIXME(": Loading not implemented yet\n"); > return S_OK; > @@ -261,7 +261,7 @@ static const IPersistStreamVtbl persiststream_vtbl = { > dmobj_IPersistStream_Release, > dmobj_IPersistStream_GetClassID, > unimpl_IPersistStream_IsDirty, > - IPersistStreamImpl_Load, > + wave_persist_stream_Load, > unimpl_IPersistStream_Save, > unimpl_IPersistStream_GetSizeMax > }; >

1 0

Re: [PATCH] mmdevapi/tests: Use standard wine_dbgstr_longlong.
by Marvin 05 Jul '17

05 Jul '17

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=32062 Your paranoid android. === w7u (32 bit render) === render.c:1029: Test failed: Position 6592 too far after playing 100ms === w864 (32 bit render) === render.c:1255: Test failed: GetBuffer large (20671) at iteration 2

1 0

Re: [PATCH 2/5] msi: Add a basic internal UI implementation.
by Marvin 04 Jul '17

04 Jul '17

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=32025 Your paranoid android. === w7u (32 bit msi) === The task timed out

3 3

Re: [1/5] libwine: Added a wine_mmap_is_in_reserved_area_ex function which returns boundary address.
by Alexandre Julliard 04 Jul '17

04 Jul '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > include/wine/library.h | 1 + > libs/wine/mmap.c | 23 ++++++++++++++++++++++- > libs/wine/wine.map | 1 + > 3 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/include/wine/library.h b/include/wine/library.h > index 242bb69..0920c60 100644 > --- a/include/wine/library.h > +++ b/include/wine/library.h > @@ -79,6 +79,7 @@ extern void *wine_anon_mmap( void *start, size_t size, int prot, int flags ); > extern void wine_mmap_add_reserved_area( void *addr, size_t size ); > extern void wine_mmap_remove_reserved_area( void *addr, size_t size, int unmap ); > extern int wine_mmap_is_in_reserved_area( void *addr, size_t size ); > +extern int wine_mmap_is_in_reserved_area_ex( void *addr, size_t size, void **boundary ); > extern int wine_mmap_enum_reserved_areas( int (*enum_func)(void *base, size_t size, void *arg), > void *arg, int top_down ); > I'm afraid we don't want to add functions either. It should be possible to implement what you want without changing the libwine interface. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Definition (or not) of IDXGIResource methods
by Ben "Root" Anderson 04 Jul '17

04 Jul '17

On Mon, Jul 3, 2017 at 1:52 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I expect ultimately you'll need some way to get at the underlying > OpenGL object. One way to go about that may to for example extend the > IWineDXGIDevice interface in include/wine/winedxgi.idl with a method > to retrieve the underlying OpenGL object of a resource. Thanks for the tip. It'll likely make a good temporary hack until I put together the (sizable) proper solution. The added functions may even wind up being a part of said solution. > There are some details to take care of there though. For one, while > wined3d is implemented on top OpenGL, that's an implementation detail > and may not be true forever. A D3D surface/texture could be backed by > an OpenGL texture, an OpenGL renderbuffer, both, or something else > entirely, so you'll probably want some kind of interface to negotiate > the kind of representation you're requesting. Even if for simplicity > we assume we have a D3D texture backed by an OpenGL texture, that > doesn't guarantee that at any given time that OpenGL texture is > current/coherent. (See also, wined3d_texture_load_location(), > wined3d_texture_validate_location(), > wined3d_texture_invalidate_location(), etc.) So you may need a way to > flush/synchronise that OpenGL texture as well. And while > IWineDXGIDevice may be a good way to prove the concept, that's an > internal interface that doesn't make any guarantees about interface > stability, so for something that you'd want to use to interface with > external software, it would be best to create a separate interface > that does make those kinds of guarantees. Yeah, I definitely want to avoid interfaces that aren't agnostic to the underlying implementation, at which point it makes more sense to instead implement the relevant Windows APIs. My current plan is to make and submit a patch to wine-staging that implements VK_KHX_external_memory_win32 and the Direct3D/DXGI functionality needed to interact with that extension from Direct3D; this implementation would very probably lean on GL_EXT_memory_object and related extensions. Then, I'd use those interfaces to import the textures into a Vulkan instance, which is then passed to the compositor. > Finally, does this need to work with arbitrary resources, or do you > only need this for e.g. swapchain buffers? It needs to work not with swapchain buffers, but a pair of ID3D11Texture2D objects that are created by the application for the express purpose of being passed to the API I'm wrapping. One or both of these textures may or may not also be presented by the application in its own window through the usual D3D process, but I do not know and am not supposed to know whether they are, and shouldn't care. (Some apps actually render and present a completely separate scene in their window.) I need to ultimately pass the textures to the native Linux version of the compositor in a form it can digest (specifically, either a GL texture or render buffer name, or a VkImage and associated instance structs), which then (among other things) presents it in the HMD using its own (Vulkan) swapchains.

2 1

Re: [PATCH 3/4] d3drm: Initial support for storing animation keys
by Henri Verbeet 04 Jul '17

04 Jul '17

On 4 July 2017 at 09:43, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static int d3drm_animation_cmp_min(const struct d3drm_animation_keys *keys, D3DVALUE left, D3DVALUE right, DWORD *cur) > +{ > + if (left == right) > + { > + while (*cur > 0 && left == keys->keys[*cur - 1].time) > + (*cur)--; > + return 0; > + } Does this really need to happen inside the comparison function? I.e., couldn't you just use a single comparison function, bsearch(), and do the fixup for duplicates afterwards? > +static DWORD d3drm_animation_get_index(struct d3drm_animation_keys *keys, D3DVALUE time, > + int (*compare_func)(const struct d3drm_animation_keys *keys, D3DVALUE left, D3DVALUE right, DWORD *cur)) > +{ > + int min = 0, max = keys->count - 1; unsigned/SIZE_T, right? > +static BOOL d3drm_animation_get_range(struct d3drm_animation_keys *keys, D3DVALUE time_min, D3DVALUE time_max, > + DWORD *min, DWORD *max) > +{ > + if (keys->count == 0) > + return FALSE; > + > + if (time_min > keys->keys[keys->count - 1].time || time_max < keys->keys[0].time) > + return FALSE; > + > + *min = d3drm_animation_get_index(keys, time_min, d3drm_animation_cmp_min); > + *max = d3drm_animation_get_index(keys, time_max, d3drm_animation_cmp_max); This is pretty minor, but note that to find *max you'd only have to search through *min to the end, instead of through the entire range. > + if (!key || key->dwSize != sizeof(*key)) > + return E_INVALIDARG; We usually print a WARN for cases where the application passes us questionable data. That's certainly not a strict requirement, but on occasion it does tend to make it slightly easier to figure out where things start failing. > + memmove(keys->keys + index + 1, keys->keys + index, sizeof(*keys->keys) * (keys->count - index)); We'd typically write those as "&keys->keys[index + 1]", etc. That's purely stylistic, of course. > + if (d3drm_animation_get_range(&animation->rotate, time_min, time_max, &min, &max)) > + { > + *count += max - min + 1; > + > + for (i = min; i <= max && keys; i++, cur++) > + { > + keys[cur].dwSize = sizeof(*keys); > + keys[cur].dwKeyType = D3DRMANIMATION_ROTATEKEY; > + keys[cur].dvTime = animation->rotate.keys[i].time; > + keys[cur].dwID = 0; /* FIXME */ > + keys[cur].u.dqRotateKey = animation->rotate.keys[i].u.rotate; > + } > + } Minor, but note that it would probably be more convenient if d3drm_animation_get_range() returned a pointer to animation->rotate.keys[min] and a count.

1 0

Re: [PATCH 5/5] msi: Correctly format the template field for MsiProcessMessage().
by Marvin 04 Jul '17

04 Jul '17

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=32028 Your paranoid android. === wxppro (32 bit package) === 0a08:package: unhandled exception c0000005 at 00000738

1 0

Re: [PATCH 4/5] msi: Don't increment the refcount when creating dialogs.
by Marvin 04 Jul '17

04 Jul '17

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=32027 Your paranoid android. === wxppro (32 bit package) === 09f0:package: unhandled exception c0000005 at 00000000

1 0

Re: [PATCH 3/5] msi: Implement UI messages for dialogs.
by Marvin 04 Jul '17

04 Jul '17

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=32026 Your paranoid android. === wxppro (32 bit package) === 09f0:package: unhandled exception c0000005 at 00000000

1 0

wine-2.0.2-rc1 Available
by Michael Stefaniuc 03 Jul '17

03 Jul '17

Hello guys, I have pushed wine-2.0.2-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ This version features 88 commits: - Some patches deferred from 2.0.1 - The compilation fixes for the prediluvian gcc 2.95 (but untested if those are enough) - Some simple "crash fix" commits that have no bugzilla entries - The usual assortment of bug fixes And now the interesting parts from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes ---------------------------------------------------------------- Bugs fixed in 2.0.2 (total 61): 2624 In dialogs, an incorrect extra WM_ERASEBKGND is sent after WM_PAINT 10858 BlueByte Game Channel fails to install 14606 TreeView + right click doesn't work the way it does in native windows 20215 Extra mouse buttons do not work in Firefox 23302 Not standard background color in Wine configuration 25625 Implement PROPSHEET_InsertPage 30378 Xuzhou network client crashes at start 30764 regedit: a key created from right-click context menu is in incorrect position 33717 regedit: Sorting registry keys on refreshing 33987 Secret Files 3 demo shows only some parts of background in ConfigTool 35563 Custom game development library expects non-zero value for ProcessVmCounters info class member 'WorkingSetSize' 37404 A right click on a registry key does not select it 37976 Poedit 1.7.4 crashes on unimplemented function msvcr120.dll.??0_ReentrantBlockingLock@details@Concurrency@@QAE@XZ 39685 Multiple applications crash on startup, need unimplemented function msvcr120.dll.??0event@Concurrency@@QAE@XZ (Rollcage Redux v1.3.8, ARC client, Playstation Now) 39856 Regedit: Default registry key is not the same as on Windows 39895 MalwareBytes Anti-malware software needs msvcr100.dll.lldiv implementation 40629 Noto Nastaliq Urdu font crashes notepad during shaping 40798 ACDSee Pro 9 (64-bit) needs msvcr120.dll.??0event@Concurrency@@QEAA@XZ 40948 Multiple apps need api-ms-win-crt-locale-l1-1-0.dll.__initialize_lconv_for_unsigned_char 40956 unimplemented function msvcr110.dll._Lock_shared_ptr_spin_lock when starting Zoner Photo Studio 18 41408 Multiple applications crash on unimplemented function msvcp140.dll.??0task_continuation_context@Concurrency@@AAE@XZ 41472 kolotibablo needs ntoskrnl.exe.KeAcquireInStackQueuedSpinLock 41753 Steep (Ubisoft) needs iphlpapi.dll.GetUnicastIpAddressEntry 41928 Mortal Kombat X needs msvcr110.dll._get_dstbias 42017 Silence d3d11_immediate_context_OMSetBlendState spam at console 42129 Steam client - unimplemented function mfreadwrite.dll.MFCreateSourceReaderFromMediaSource 42138 bug when running reaktor 6: "Unhandled exception: unimplemented function concrt140.dll.??0_ReentrantBlockingLock@details@Concurrency@@QAE@XZ called in 32-bit code (0x7b43bf1c)." 42206 Gauntlet character screen background is corrupted. 42209 Native Instruments Native Access 1.0.25 (R37) crashes on unimplemented function concrt140.dll.??1_ReentrantBlockingLock@details@Concurrency@@QAE@XZ 42239 Kontact 5.6 needs api-ms-win-crt-time-l1-1-0.dll._Wcsftime 42240 Kontact 5.6 needs concrt140.dll.??0_ReentrantBlockingLock@details@Concurrency@@QEAA@XZ 42271 Final Fantasy X needs msvcr110.dll.__crtUnhandledException 42449 Multiple apps need function msvcr120.dll.fesetround (0 A.D., BeamNG.drive) 42463 ZmLearn crash at startup: "Assertion 'm->state == STATE_PASSIVE' failed at pulse/mainloop.c:787, function pa_mainloop_prepare(). Aborting." 42465 winhttp set_cookies() violates RFC6265 string comparison rules 42487 Free Devanagari font Samanata crashes during GPOS processing 42490 Assertion failure when clicking boxes in altWinDirStat 42510 InternetOpenUrl does not send query parameters for HTTPS urls 42559 Adobe Reader DC: No longer installs (Unimplemented function msi.dll.MsiGetComponentPathExW) 42575 Multiple applications need msvcp140.dll.?_LogScheduleTask@_TaskEventLogger@details@Concurrency@@QAEX_N@Z 42576 Poedit crashes on start on unimplemented function msvcp140.dll.?_Reset@_ContextCallback@details@Concurrency@@AAEXXZ 42578 WSAStringToAddress fails to parse IP v6 addresses with port number 42626 unimplemented function msvcr110.dll.__crtUnhandledException 42651 ViStart: fails to install, needs ntoskrnl.exe.IoReportResourceForDetection 42655 Aliens vs. Predator (2010) needs d3dx11_42.dll.D3DX11FilterTexture 42657 ACDSee Pro 9 needs msvcr120.dll.?Alloc@Concurrency@@YAPEAX_K@Z 42658 Playstation Now needs msvcr120.dll.?Alloc@Concurrency@@YAPAXI@Z 42688 Native Acces crashes on unimplemented msvcp140.dll.?__ExceptionPtrCompare@@YA_NPBX0@Z 42703 Excel 2010 does not work: unimplemented function oleaut32.dll.GetAltMonthNames 42736 scanf doesn't work as expected when using format string contains non-ascii chars 42774 WinHttpQueryAuthSchemes fails to return the correct supported value for multiple WWW-Authenticate 42798 MsiGetPatchInfoEx returns incorrect values for UNINSTALLABLE, PATCHSTATE properties 42834 Steuer-Spar-Erklärung 2017 crashes with critical error 42876 iTunes needs function msvcp140.dll._Lock_shared_ptr_spin_lock 42986 wine can't be compiled by gcc-2.95.4 (amstream/mediastream.c) 42991 wine can't be compiled by gcc-2.95.4 (dmusic/port.c) 42992 wine can't be compiled by gcc-2.95.4 (dwrite/opentype.c) 42993 wine can't be compiled by gcc-2.95.4 (gdiplus/metafile.c) 42994 wine can't be compiled by gcc-2.95.4 (mscoree/assembly.c) 42995 wine can't be compiled by gcc-2.95.4 (netprofm/list.c) 43127 Multiple 64-bit applications crash with stack overflow errors when Wine is compiled with GCC 7.x (set_context_reg in ntdll/signal_x86_64.c assumes Xmm registers are aligned) ---------------------------------------------------------------- Changes since 2.0.1: Alex Henrie (7): winecfg: Paint text on About tab with the right background color. ntdll: Implement ProcessVmCounters for Linux. user32: Translate WM_(NC)XBUTTONUP to WM_APPCOMMAND in DefWindowProc. comctl32: Return TRUE from LVM_REDRAWITEMS with bad indices. ddraw: Don't crash if writing out a new ddraw2 surface segfaults. ddraw: Don't crash if writing out a new ddraw4 surface segfaults. ddraw: Don't crash if writing out a new ddraw7 surface segfaults. Alistair Leslie-Hughes (3): winhttp/tests: Added multi Authenticate header test. include: Add mfreadwrite.idl. mfreadwrite: Add MFCreateSourceReaderFromMediaSource stub. Andrey Gusev (1): d3dx11: Add D3DX11FilterTexture stub. André Hentschel (4): include: Add the new version of the IP_ADAPTER_UNICAST_ADDRESS structure. iphlpapi: Add GetUnicastIpAddressEntry implementation. hidclass.sys: Fix compilation on systems that don't support nameless structs. winebus.sys: Fix compilation on systems that don't support nameless structs. Aric Stewart (1): usp10: Fix Contextual Shaping for Languages with RTL write order. Austin English (2): ntoskrnl.exe: Add KeAcquireInStackQueuedSpinLock stub. ntoskrnl.exe: Add IoReportResourceForDetection stub. Björn Bidar (1): wined3d: Add NVIDIA GTX 1080 Ti to the GPU list. Bruno Jesus (2): ws2_32/tests: Rework WSAStringToAddress tests. ws2_32: Fix WSAStringToAddress parsing for IPv6. Christopher Berner (1): wined3d: Add Nvidia TitanX (Pascal). Daniel Lehman (1): msvcrt: Add Concurrency::event stubs. Fabian Maurer (5): user32/tests: Add tests for windows when first shown with WS_VISIBLE or RedrawWindow. user32/tests: Add tests for windows when first shown with SetWindowPos. user32/tests: Add tests for windows when first shown if they have children. user32/tests: Add WM_NCPAINT tests for windows crossing screen or maximized. user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown. Gijs Vermeulen (1): msvcrt: Add stub for Concurrency::Alloc. Hans Leidekker (7): msi: Implement MsiGetComponentPathExA/W. winhttp: Parse cookie attributes. winhttp: Cookie attributes are case-insensitive. winhttp: Ignore unknown schemes in WinHttpQueryAuthSchemes. msi: Properly handle DWORD registry values in MsiGetPatchInfoEx. netprofm: Fix compilation on systems that don't support nameless unions. winhttp: Fix a memory leak in insert_header (Valgrind). Hugh McMaster (4): comctl32: Improve right-click handling in treeview controls. regedit: Call TrackPopupMenu() from WM_CONTEXTMENU. regedit: Select the targeted treeview item on right mouse click. regedit: Sort treeview children on refresh. Huw D. M. Davies (1): shell32: Avoid leaking icon handles. Jacek Caban (1): msvcrt: Added lldiv implementation. Jakub Bartmiński (1): regedit: Fall back to tree root on invalid path. Józef Kucia (11): d3d11: Try to avoid spurious blend state FIXMEs(). wined3d: Add ARB_texture_buffer_object extension. wined3d: Create dummy buffer textures. wined3d: Add initial support for shader buffer views. wined3d: Do not pass LOD to texelFetch() for buffer resources. wined3d: Implement buffer samplers. amstream: Fix compilation on systems that don't support nameless unions. dmusic: Fix compilation on systems that don't support nameless structs or unions. mscoree: Fix compilation on systems that don't support nameless unions. gdiplus: Fix compilation on systems that don't support nameless unions. dxgi: Fix HMODULE leak in register_d3d10core_layers(). Michael Müller (2): cabinet: Set index of folder in FDICopy callback. wininet: Handle query parameters for HTTPS urls in InternetOpenUrlW. Michael Stefaniuc (1): dmloader: Avoid a crash on a NULL string pointer. Nikolay Sivov (8): oleaut32: Implement GetAltMonthNames(). dwrite: Make CreateFontFaceFromHdc() properly fail on unsupported font format. regedit: Sort each of top level branches separately. usp10: Ignore device tables with invalid delta format. dwrite: Fix compilation failure regarding nameless unions. schedsvc: Fix xml buffer leak (Valgrind). dwrite: Fix file object leak. shell32: Fix string leak. Peter Hater (1): comctl32/propsheet: Added PSM_INSERTPAGE implementation. Piotr Caban (16): msvcp110: Add _Lock_shared_ptr_spin_lock implementation. msvcp140: Add task_continuation_context constructor implementation. msvcp140: Add _ContextCallback implementation. msvcp140: Add _TaskEventLogger class implementation. msvcr: Add _Wcsftime implementation. msvcr100: Add reader_writer_lock class stub. msvcr100: Add _ReentrantBlockingLock class implementation. msvcrt: Add __ExceptionPtrCopyException implementation. msvcrt: Add __ExceptionPtrCompare implementation. msvcr: Add __crtUnhandledException implementation. msvcr120: Add fesetround implementation. msvcrt: Fix handling of unsigned chars in scanf format. msvcrt: Fix wide characters handling in wscanf functions. msvcr: Add _get_dstbias implementation. ucrtbase: Add __initialize_lconv_for_unsigned_char implementation. msvcr110: Add _Lock_shared_ptr_spin_lock implementation. Sebastian Lackner (3): rasapi32: Set *lpcDevices in RasEnumDevicesA. ntdll: Do not cast unaligned pointer to M128A in set_context_reg. mmdevapi: Use InitOnce to initialize audio drivers. Thierry Vermeylen (1): wnaspi32: Do not crash on SC_GETSET_TIMEOUTS. Viktor Semykin (2): windowscodecs/tests: Test for png codec seeking too far. windowscodecs: Fixed loading png from streams. -- Michael Stefaniuc mstefani(a)winehq.org

1 0

Re: [PATCH 2/2] make_unicode: Update to Unicode to version 10 I added "Bottom_And_Left", but i have no idea, if my change is correct
by Aric Stewart 03 Jul '17

03 Jul '17

Please do not change existing values. You can add new ones to the end. -aric On 7/2/17 5:23 PM, Detlef Riekenberg wrote: > -- > Bye bye ... Detlef > > Signed-off-by: Detlef Riekenberg <wine.dev(a)web.de> > --- > tools/make_unicode | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/tools/make_unicode b/tools/make_unicode > index f9c2917..5bbc5b8 100755 > --- a/tools/make_unicode > +++ b/tools/make_unicode > @@ -23,7 +23,7 @@ use strict; > > # base URLs for www.unicode.org files > my $MAPPINGS = "http://www.unicode.org/Public/MAPPINGS"; > -my $UNIDATA = "http://www.unicode.org/Public/9.0.0/ucd"; > +my $UNIDATA = "http://www.unicode.org/Public/10.0.0/ucd"; > my $REPORTS = "http://www.unicode.org/reports"; > my $RFCS = "http://www.rfc-editor.org/rfc"; > my $VERTICALPATH = "http://www.unicode.org/Public/vertical/revision-17"; > @@ -190,9 +190,10 @@ my %matra_types = > "Top_And_Left" => 0x09, > "Top_And_Left_And_Right" => 0x0a, > "Bottom_And_Right" => 0x0b, > - "Top_And_Bottom_And_Right" => 0x0c, > - "Overstruck" => 0x0d, > - "Invisible" => 0x0e > + "Bottom_And_Left" => 0x0c, > + "Top_And_Bottom_And_Right" => 0x0d, > + "Overstruck" => 0x0e, > + "Invisible" => 0x0f > ); > > my %nameprep_flags = >

1 0

Re: [4/7] ntdll: Allow map_view() to allocate fixed memory between reserved area and non-reserved area.
by Alexandre Julliard 03 Jul '17

03 Jul '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -551,11 +551,12 @@ void wine_mmap_remove_reserved_area( void *addr, size_t size, int unmap ) > * Check if the specified range is included in a reserved area. > * Returns 1 if range is fully included, 0 if range is not included > * at all, and -1 if it is only partially included. > + * When returning -1, set the boundary address if the pointer is supplied. > * > * Note: the reserved areas functions are not reentrant, caller is > * responsible for proper locking. > */ > -int wine_mmap_is_in_reserved_area( void *addr, size_t size ) > +int wine_mmap_is_in_reserved_area( void *addr, size_t size, void **boundary ) libwine is supposed to be backwards compatible, you can't change its interface. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/4] msi: Add a basic internal UI implementation.
by Marvin 03 Jul '17

03 Jul '17

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=31999 Your paranoid android. === w7u (32 bit msi) === The task timed out

3 2

Re: [PATCH] make_unicode: Update vertical spec to revision 17
by Alexandre Julliard 03 Jul '17

03 Jul '17

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -26,7 +26,8 @@ my $MAPPINGS = "http://www.unicode.org/Public/MAPPINGS"; > my $UNIDATA = "http://www.unicode.org/Public/9.0.0/ucd"; > my $REPORTS = "http://www.unicode.org/reports"; > my $RFCS = "http://www.rfc-editor.org/rfc"; > -my $VERTICALDATA = "http://www.unicode.org/Public/vertical/revision-15"; > +my $VERTICALPATH = "http://www.unicode.org/Public/vertical/revision-17"; > +my $VERTICALFILE = "VerticalOrientation-17.txt"; This doesn't seem to make any difference in the generated file, should it? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 05/10 v4] gdiplus: Support SetTextRenderingHint in metafiles
by Nikolay Sivov 03 Jul '17

03 Jul '17

On 06/30/2017 07:14 PM, Piotr Caban wrote: > +GpStatus METAFILE_AddSimpleProperty(GpMetafile *metafile, SHORT prop, SHORT val) > +{ > + EmfPlusRecordHeader *hint_record; > + GpStatus stat; > + > + if (metafile->metafile_type != MetafileTypeEmfPlusOnly && metafile->metafile_type != MetafileTypeEmfPlusDual) > + return Ok; > + > + stat = METAFILE_AllocateRecord(metafile, sizeof(*hint_record), (void**)&hint_record); > + if (stat != Ok) return stat; > + > + hint_record->Type = prop; > + hint_record->Flags = val; > + > + METAFILE_WriteRecords(metafile); > + return Ok; > +} This is not specific to text rendering hint parameter anymore, local variable should be just "record".

2 1

Re: [PATCH 03/10 v4] gdiplus: Add functions for managing metafile objects id
by Vincent Povirk 03 Jul '17

03 Jul '17

This seems like overkill to me? I don't see the need for per-object refcounting. Every drawing operation that uses an object is just going to end with a series of releases, and after it returns all refcounts should be 0. + /* TODO: object id should be released on object dispose */ I don't think this approach is possible. It would require every object to be aware of which metafiles are using it, and every operation that modifies the object would have to release them. Bitmap objects can refer to an application buffer that could be modified without any call into gdiplus. (Or, Bitmaps could be modified by an ImageAttributes, in which case we can't reuse them except with an identical ImageAttributes.) If we wanted to reuse Bitmaps, we'd have to compare the data. For other large types like Paths, maybe keeping an id to detect whether it changed would make sense. For types of bounded size, it probably would be easier to store a complete copy.

2 2

Re: [PATCH] kernel32: Fix GetModuleHandleEx() spec file entry
by Chris Robinson 02 Jul '17

02 Jul '17

On 07/02/2017 01:26 AM, Nikolay Sivov wrote: > -@ stdcall GetModuleHandleExA(long ptr ptr) > -@ stdcall GetModuleHandleExW(long ptr ptr) > +@ stdcall GetModuleHandleExA(long str ptr) > +@ stdcall GetModuleHandleExW(long wstr ptr) Depending on the flags, the second parameter might not actually be a string. e.g. if GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS is set, the second parameter is any address within the module's address space.

2 1

Definition (or not) of IDXGIResource methods
by Ben "Root" Anderson 30 Jun '17

30 Jun '17

I've been studying the DXGI code with an eye for implementing the DirectX-side shared resource functionality so that an application would hopefully be able to share Direct3D textures with a Vulkan instance, and what I'm seeing has me rather confused. IDXGIResource appears to be declared, with a number of methods, in include/dxgi.idl. I'm not clear on what exactly an IDL file is, but my impression is it's similar to a specfile, except for headers of C++ interfaces. In any case, none of the methods declared appear to have any definition anywhere in Wine. The logical conclusion would be they're automatically generated stubs. But that doesn't make sense, because the DXGI test at dlls/dxgi/tests/device.c calls IDXGIResource_GetUsage and appears to expect it to succeed, implying that it's implemented *somewhere*. What am I missing?

2 1

Re: winedump: Add initial support for handling EMF+ records
by Dmitry Timoshkov 30 Jun '17

30 Jun '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > #define EMRCASE(x) case x: printf("%-20s %08x\n", #x, length); break > +#define EMRPLUSCASE(x) case x: printf(" %-20s %04x %08x\n", #x, header->Flags, header->Size); break; ';' at the end is redundant. EMRCASE macro intentionally omits it. > + /* Hand EMF+ records */ > + if (length >= 16 && !memcmp((char*)PRD(offset + 12, sizeof(unsigned int)), "EMF+", 4)) A typo in the comment. -- Dmitry.

2 1

Re: [PATCH 1/9 v3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Dmitry Timoshkov 30 Jun '17

30 Jun '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > +static GpStatus METAFILE_CreateCompressedImageStream(GpImage *image, IStream **stream, DWORD *size) > +{ > + static const CLSID png_clsid = { 0x557cf406, 0x1a04, 0x11d3, > + { 0x9a, 0x73, 0x0, 0x0, 0xf8, 0x1e, 0xf3, 0x2e } }; > + LARGE_INTEGER zero; > + STATSTG statstg; > + GpStatus stat; > + HRESULT hr; > + > + *size = 0; > + > + hr = CreateStreamOnHGlobal(NULL, TRUE, stream); > + if (FAILED(hr)) return hresult_to_status(hr); > + > + stat = GdipSaveImageToStream(image, *stream, &png_clsid, NULL); Even internally gdiplus shouldn't do this kind of hacks IMO, if there is a need for a shortcut for a particular encoder class id it's better to add a helper. Have a look at the encoder/decoder tests how it's supposed to look like. -- Dmitry.

2 3

Re: [PATCH 3/9 v3] gdiplus: Add support for ImageAttributes when drawing image to metafile
by Dmitry Timoshkov 30 Jun '17

30 Jun '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > @@ -259,7 +278,7 @@ static DWORD METAFILE_AddObjectId(GpMetafile *metafile) > id = 0; > for (i=1; i<sizeof(metafile->objects_table)/sizeof(metafile->objects_table[0]); i++) > { > - if (metafile->objects_table[id] < metafile->objects_table[i]) > + if (metafile->objects_table[id] > metafile->objects_table[i]) This looks strange to change this right in the next patch. -- Dmitry.

2 1

Re: [PATCH 3/4 v2] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk 29 Jun '17

29 Jun '17

+ draw_image_record->SrcRect.Width = units_to_pixels(srcwidth, srcUnit, metafile->image.xres);; + draw_image_record->SrcRect.Height = units_to_pixels(srcheight, srcUnit, metafile->image.yres);; One semicolon is probably enough. I think we should put a little more effort into object management up front. I would start it by having the Add*Object functions return an id to the caller, and adding a ReleaseObjects function to indicate that the current objects are no longer needed. For now, we could just implement this as a counter that we reset to 0.

1 0

Re: [PATCH 3/4] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk 29 Jun '17

29 Jun '17

I don't fully understand the spec, so I could be wrong about this, but I think for texture brushes we'll need the ability to create an EmfPlusImage structure without an EmfPlusObject record.

2 3

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings
by Alexandre Julliard 29 Jun '17

29 Jun '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > This patch fixes bugs 10767 and 32490, amongst other bugs. > It also fixes subkey sorting issues in regedit's treeview control. > > From: Dmitry Timoshkov <dtimoshkov(a)codeweavers.com> > > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/tests/locale.c | 9 +++---- > libs/wine/collation.c | 60 ++++++++++++++++++++++---------------------- > 2 files changed, 34 insertions(+), 35 deletions(-) That's a generated file, changes would have to be made in the generating script instead (tools/make_unicode). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] msi: Fix a buffer overrun.
by Austin English 29 Jun '17

29 Jun '17

On Thu, Jun 29, 2017 at 12:09 AM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=43257 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/msi/package.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index bf6ae10..3a75a1c 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1812,17 +1812,17 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > { > WCHAR template_s[1024]; > WCHAR *template_rec, *template; > - DWORD length; > > LoadStringW(msi_hInstance, IDS_INFO, template_s, 1024); > > - res = MSI_RecordGetStringW(record, 0, NULL, &length); > + res = MSI_RecordGetStringW(record, 0, NULL, &len); > if (res != ERROR_SUCCESS && res != ERROR_MORE_DATA) > return res; > len++; > template_rec = msi_alloc(len * sizeof(WCHAR)); > if (!template_rec) return ERROR_OUTOFMEMORY; > - MSI_RecordGetStringW(record, 0, template_rec, &length); > + MSI_RecordGetStringW(record, 0, template_rec, &len); > + len++; > > template = msi_alloc((len + strlenW(template_s)) * sizeof(WCHAR)); > if (!template) return ERROR_OUTOFMEMORY; > -- > 2.7.4 > > > Works for me, thanks. -- -Austin GPG: 14FB D7EA A041 937B

1 0

Re: [PATCH 1/6] include: Support wine_dbgstr_longlong in tests
by Michael Stefaniuc 29 Jun '17

29 Jun '17

Hello Alistair, On 06/29/2017 02:43 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/wine/test.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/wine/test.h b/include/wine/test.h > index af602c0..d8e5490 100644 > --- a/include/wine/test.h > +++ b/include/wine/test.h > @@ -68,6 +68,7 @@ extern const char *wine_dbgstr_wn( const WCHAR *str, int n ); > extern const char *wine_dbgstr_guid( const GUID *guid ); > extern const char *wine_dbgstr_rect( const RECT *rect ); > static inline const char *wine_dbgstr_w( const WCHAR *s ) { return wine_dbgstr_wn( s, -1 ); } > +extern const char *wine_dbgstr_longlong( ULONGLONG ll ); > > /* strcmpW is available for tests compiled under Wine, but not in standalone > * builds under Windows, so we reimplement it under a different name. */ > @@ -541,6 +542,17 @@ const char *wine_dbgstr_rect( const RECT *rect ) > return res; > } > > +const char *wine_dbgstr_longlong( ULONGLONG ll ) > +{ > + char *res; The other functions have an empty line after the variable declarations. > + res = get_temp_buffer( 17 ); > + if (sizeof(ll) > sizeof(unsigned long) && ll >> 32) > + sprintf(res, "%lx%08lx", (unsigned long)(ll >> 32), (unsigned long)ll); Either place a space after the opening parenthesis and before the closing one or don't but please stay consistent inside a function. The file prefers the variant with the spaces. > + else > + sprintf(res, "%lx", (unsigned long)ll); > + return res; The other debug functions with variable length output release the unused part of the temp buffer. You can waste up to 15 bytes here. > +} > + > /* Find a test by name */ > static const struct test *find_test( const char *name ) > { > thanks bye michael

1 0

Re: [PATCH] libs/wine: Use Windows collation when sorting and comparing strings
by Marvin 29 Jun '17

29 Jun '17

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=31953 Your paranoid android. === w7u (32 bit locale) === locale.c:2927: Test failed: qsort using lstrcmpA failed for element 6 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 7 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 8 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 9 locale.c:2927: Test failed: qsort using lstrcmpA failed for element 10 locale.c:2935: Test failed: qsort using CompareStringA failed for element 6 locale.c:2935: Test failed: qsort using CompareStringA failed for element 7 locale.c:2935: Test failed: qsort using CompareStringA failed for element 8 locale.c:2935: Test failed: qsort using CompareStringA failed for element 9 locale.c:2935: Test failed: qsort using CompareStringA failed for element 10 locale.c:2943: Test failed: qsort using sort keys failed for element 6 locale.c:2943: Test failed: qsort using sort keys failed for element 7 locale.c:2943: Test failed: qsort using sort keys failed for element 8 locale.c:2943: Test failed: qsort using sort keys failed for element 9 locale.c:2943: Test failed: qsort using sort keys failed for element 10

1 0

Re: [2/7] webservices: Add an index to the static dictionary.
by Alexandre Julliard 29 Jun '17

29 Jun '17

Hans Leidekker <hans(a)codeweavers.com> writes: > +static const ULONG dict_sorted[] = > +{ > + 81, 91, 129, 314, 185, 164, 346, 66, 235, 305, 14, 6, 114, 97, 96, 94, 11, 95, 110, 451, > + 443, 121, 213, 7, 71, 82, 431, 343, 74, 75, 73, 59, 447, 445, 467, 163, 472, 463, 453, 409, Why is it so large? Shouldn't it be the same size as the strings array? -- Alexandre Julliard julliard(a)winehq.org

2 1

What are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries?
by Alan W. Irwin 28 Jun '17

28 Jun '17

In the past (in the Wine 1.6 era) I used an old snapshot (4.7.2) of MinGW/MSYS on wine to build applications with success, and I would like to stick with that snapshot for Wine Staging 2.10 since I have found in the past later versions of MinGW/MSYS were not as reliable as 4.7.2. However, since that snapshot was initially installed with Wine 1.6 (or maybe even earlier) I assume its default header locations and library locations refer to some old wine version, and the general question is how do I override those to refer to the equivalent Wine Staging 2.10 locations. I have a simple test programme (attached) that illustrates the problem: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx z:/home/wine/wine_staging/test_rand_s.cxx: In function 'int main()': z:/home/wine/wine_staging/test_rand_s.cxx:18:5: error: 'errno_t' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:18:21: error: expected ';' before 'err' z:/home/wine/wine_staging/test_rand_s.cxx:23:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:23:31: error: 'rand_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:26:53: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:29:60: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:32:18: error: 'printf_s' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:9: error: 'err' was not declared in this scope z:/home/wine/wine_staging/test_rand_s.cxx:37:31: error: 'rand_s' was not declared in this scope (I presume those errors are due to those functions not being defined by Wine way back when). That compile issue is solved as follows: bash.exe-3.1$ g++ /z/home/wine/wine_staging/test_rand_s.cxx -I/z/opt/wine-staging/include/wine/msvcrt -I/z/opt/wine-staging/in clude/wine/windows C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x35): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x4c): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xa6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xc6): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xdc): undefined reference to `rand_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0xf3): undefined reference to `printf_s' C:\users\wine\Temp\cckTYgsp.o:test_rand_s.cxx:(.text+0x124): undefined reference to `printf_s' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\users\wine\Temp\cckTYgsp .o: bad reloc address 0x13 in section `.eh_frame' z:/home/wine/wine_staging/mingw-4.7.2/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation collect2.exe: error: ld returned 1 exit status However, that compile fix obviously leaves the above link issue which I attempted to solve by appending the options -L/z/opt/wine-staging/lib/wine -lmsvcrt which worked (in the sense that that library was found) but apparently that particular library does not implement rand_s and printf_s since the same link errors occurred as above. So what are the -l options I should be using to assure I am using the Wine Staging 2.10 versions of the standard system libraries? N.B. I realize this issue would likely be taken care of automatically if I installed the latest version of MinGW/MSYS on the Wine Staging 2.10 platform. But I have my reasons explained above why I would prefer to use the 4.7.2 snapshot of MinGW/MSYS instead. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

1 0

Re: [6/6] wsdapi/tests: Add tests for WSDXMLGetValueFromAny.
by Marvin 28 Jun '17

28 Jun '17

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=31935 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/6] wsdapi: Implement IWSDUdpAddress_Get/SetSockAddr.
by Marvin 28 Jun '17

28 Jun '17

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=31934 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/6] wsdapi: Implement IWSDUdpAddress_Get/SetMessageType.
by Marvin 28 Jun '17

28 Jun '17

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=31933 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/6] wsdapi: Implement IWSDUdpAddress_Get/SetPort.
by Marvin 28 Jun '17

28 Jun '17

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=31932 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/6] wsdapi: Implement IWSDUdpAddress_GetTransportAddress[Ex].
by Marvin 28 Jun '17

28 Jun '17

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=31931 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/3] gdiplus: Add partial support for GdipDrawImagePointsRect on metafile
by Vincent Povirk 28 Jun '17

28 Jun '17

Can we keep the code for generating an EmfplusImage structure separate from this? We'll want to reuse it for EmfPlusDrawImage and EmfPlusTextureBrushOptionalData.

2 1

Re: [PATCH v2] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk 28 Jun '17

28 Jun '17

I don't understand this part. On Tue, Jun 27, 2017 at 5:27 PM, Zebediah Figura <z.figura12(a)gmail.com> wrote: > @@ -2175,8 +2182,7 @@ static void widen_dashed_figure(GpPath *path, GpPen *pen, int start, int end, > if (dash_index % 2 == 0 && num_tmp_points != 0) > { > /* last dash overflows last segment */ > - tmp_points[num_tmp_points] = path->pathdata.Points[end]; > - widen_open_figure(tmp_points, pen, 0, num_tmp_points, > + widen_open_figure(tmp_points, pen, 0, num_tmp_points-1, > draw_start_cap ? pen->startcap : LineCapFlat, pen->customstart, > closed ? LineCapFlat : pen->endcap, pen->customend, last_point); > }

2 1

WineConf RSVP
by Jacek Caban 28 Jun '17

28 Jun '17

Hi all, Jeremy has set up RSVP page for this year conference: https://www.winehq.org/wineconf/rsvp Please fill the form if you're planning to attend. The pool of rooms for participants is reserved until middle of October. However, some rooms will be released in the end of July unless we know that we need them. That said, an information about number of participants is important for organization reasons. Thanks, Piotr and Jacek

1 0

Re: [v2 PATCH] dmime: Query the Sound buffer for supported interfaces
by Michael Stefaniuc 28 Jun '17

28 Jun '17

Hello Alistair, On 06/28/2017 08:46 AM, Alistair Leslie-Hughes wrote: > v2: Fix compile warning. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmime/audiopath.c | 18 +++++++----------- > dlls/dmime/tests/dmime.c | 23 +++++++++++++++++++++++ > 2 files changed, 30 insertions(+), 11 deletions(-) > > diff --git a/dlls/dmime/audiopath.c b/dlls/dmime/audiopath.c > index 04f0af03d0..211f2156f2 100644 > --- a/dlls/dmime/audiopath.c > +++ b/dlls/dmime/audiopath.c > @@ -137,17 +137,13 @@ static HRESULT WINAPI IDirectMusicAudioPathImpl_GetObjectInPath (IDirectMusicAud > case DMUS_PATH_BUFFER: > if (This->pDSBuffer) > { > - if (IsEqualIID (iidInterface, &IID_IDirectSoundBuffer8)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSoundBuffer8, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else if (IsEqualIID (iidInterface, &IID_IDirectSound3DBuffer)) { > - IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, &IID_IDirectSound3DBuffer, ppObject); > - TRACE("returning %p\n",*ppObject); > - return S_OK; > - } else { > - FIXME("Bad iid\n"); > - } you need to add tests for all the interfaces supported by the DirectSoundBuffer object too: IID_IDirectSoundNotify, IID_IDirectSound3DBuffer, IID_IKsPropertySet. But if native supports the query for those too this can be simplified even further to a return IDirectSoundBuffer8_QueryInterface(This->pDSBuffer, iidInterface, ppObject); The extra tracing isn't really needed as IDirectSoundBuffer8_QueryInterface() already does that. And any serious dmusic tracing needs to include the dsound debug channels anyway. > + if(IDirectSoundBuffer8_QueryInterface (This->pDSBuffer, iidInterface, ppObject) == S_OK) { Just in case you insist on keeping the extra tracing: "if" is not a function so please have a space between it and the "(". And no space between the function name and "(". > + TRACE("returning %p\n",*ppObject); Please add a space after the "," thanks bye michael > + return S_OK; > + } > + > + WARN("Unsupported iid %s\n", debugstr_guid(iidInterface)); > + return E_NOINTERFACE; > } > break; > > diff --git a/dlls/dmime/tests/dmime.c b/dlls/dmime/tests/dmime.c > index a154eac50b..13c6afbfec 100644 > --- a/dlls/dmime/tests/dmime.c > +++ b/dlls/dmime/tests/dmime.c > @@ -23,6 +23,7 @@ > #include <wine/test.h> > #include <dmusici.h> > #include <audioclient.h> > +#include <guiddef.h> > > #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0])) > > @@ -45,8 +46,11 @@ static void test_COM_audiopath(void) > IDirectMusicAudioPath *dmap; > IUnknown *unk; > IDirectMusicPerformance8 *performance; > + IDirectSoundBuffer *dsound; > + IDirectSoundBuffer8 *dsound8; > ULONG refcount; > HRESULT hr; > + DWORD buffer = 0; > > hr = CoCreateInstance(&CLSID_DirectMusicPerformance, NULL, CLSCTX_INPROC_SERVER, > &IID_IDirectMusicPerformance8, (void**)&performance); > @@ -89,6 +93,25 @@ static void test_COM_audiopath(void) > ok(refcount == 5, "refcount == %u, expected 5\n", refcount); > refcount = IUnknown_Release(unk); > > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer, (void**)&dsound); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer_Release(dsound); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IDirectSoundBuffer8, (void**)&dsound8); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IDirectSoundBuffer8_Release(dsound8); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &IID_IUnknown, (void**)&unk); > + ok(hr == S_OK, "Failed: %08x\n", hr); > + IUnknown_Release(unk); > + > + hr = IDirectMusicAudioPath_GetObjectInPath(dmap, DMUS_PCHANNEL_ALL, DMUS_PATH_BUFFER, buffer, &GUID_NULL, > + 0, &GUID_NULL, (void**)&dsound8); > + ok(hr == E_NOINTERFACE, "Failed: %08x\n", hr); > + > while (IDirectMusicAudioPath_Release(dmap) > 1); /* performance has a reference too */ > IDirectMusicPerformance8_CloseDown(performance); > IDirectMusicPerformance8_Release(performance); >

1 0

Rerun TestBot tasks that timeout?
by Francois Gouget 28 Jun '17

28 Jun '17

The hope would be that the timeout was due to an external factor and that the task won't time out on the second try. But it's also quite likely that that the timeout is caused by an issue with the test itself and then it would time out again, and again. So with the default 3 tries this would result in tripling the time it takes to get the results (so 6 minutes and 3 reverts). Furthermore timeouts are not that common (particularly spurious ones) so it may not be worth changing anything. If we do want to do something the patch would be simple. I believe something like the patch below would do the trick. We could also have a single retry in such a case but this would require to special-case the code. diff --git a/testbot/bin/WineRunTask.pl b/testbot/bin/WineRunTask.pl index 1663c105..0cb0ea18 100755 --- a/testbot/bin/WineRunTask.pl +++ b/testbot/bin/WineRunTask.pl @@ -765,4 +765,5 @@ FatalTAError(undef, $TAError, $PossibleCrash) if (defined $TAError); # Wrap up # -WrapUpAndExit($NewStatus, $TaskFailures); +# Don't retry running a timed out test if it has failures anyway +WrapUpAndExit($NewStatus, $TaskFailures, ($TaskTimedOut and $TaskFailures == 1)); -- 2.11.0

1 0

Re: [v2 PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin 28 Jun '17

28 Jun '17

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=31909 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] oledb32: Support DBTYPE_DBTIMESTAMP to DBTYPE_WSTR in DataConvert
by Marvin 28 Jun '17

28 Jun '17

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=31908 Your paranoid android. === wxppro (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2003std (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === wvistau64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w2008s64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7u (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w7pro64 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w8 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w864 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4 === w1064 (32 bit convert) === convert.c:1028: Test failed: got 4 convert.c:1037: Test failed: got 4 convert.c:1046: Test failed: got 4

1 0

Re: [PATCH] gdiplus: Scale widened dashes to the pen width.
by Vincent Povirk 27 Jun '17

27 Jun '17

If the dash_pos variable is relative to pen width, we need to fix the other references to it. It doesn't make sense to compare it directly with segment_length and segment_pos. Or we could scale the whole dash_pattern array by pen width at the start.

2 2

Fwd: Improvements to the heap allocator
by Andrea Canciani 27 Jun '17

27 Jun '17

The original message was apparently blocked by the mailing list rules/filter. Now I am subscribed to wine-devel, sorry if you get the message twice. Andrea ---------- Forwarded message ---------- From: Andrea Canciani <ranma42(a)gmail.com> Date: Fri, Jun 23, 2017 at 9:29 AM Subject: Improvements to the heap allocator To: wine-devel(a)winehq.org Yesterday I opened a bug report about a performance issue in the wine heap allocator: https://bugs.winehq.org/show_bug.cgi?id=43224 Since I was also asking for some suggestions about what the preferred fix would be, Sebastian Lackner pointed to this mailing list. The bug report contains the source code for a program that has an allocation pattern that is very bad (for the current wine allocator). This appears to be a known problem, but I was unable to find any test/benchmark that shows such degenerate behavior. So far none of the attempts at fixing it seem to have landed. Some possible approaches are: 1. ensure that the freelist sizes cover all (alignment rounded) sizes up to a certain value; 2. when looking up for a free block, start from the freelist whose smallest element is at least as big as the desired block; 3. implement more complex free block management. #1 would fix the issue for some allocations sizes, but for bigger allocations the problem would stay the same. #2 would fix the performance problem at the cost of increased memory usage: for some sizes it would be possible that after a block is allocated and freed, the following allocation for that size does not re-use that memory (if the free block is stored in a freelist together with smaller blocks). #3 would increase the complexity of the code; to keep it under control, it might be possible to re-use the red-black tree implementation already available in wine. To avoid regressing performance, the smallest blocks might still be handled with simple freelists (fixed as in #1), while larger blocks are managed in a tree. Some of the current/previous attempts at tackling this issue are: - https://github.com/wine-compholio/wine-staging/blob/ master/patches/ntdll-Heap_FreeLists/0001-ntdll-Improve- heap-allocation-performance-by-using-m.patch (implements #1) - https://github.com/laino/wine-patches (IIUC, a combination of #1 and #3, in which the code tries to keep the freelist length under control, but AFAICT there is no guaranteed bound) I would like to try and work on fixing this, but there are some decision to make that might depend on constraints I am not aware of. Would the solution I propose (#3, rbtree based, with some tuning for small allocation sizes) be acceptable? Are there any benchmarks that a new implementation should strive to improve or at least avoid regressing? Suggestions and alternative solutions are welcome :) Sorry for the long message, thank you for your patience Andrea

1 0

Re: [v5 2/3] d3dx9: Get rid of constant's length checking for matrix in set_constants().
by Matteo Bruni 27 Jun '17

27 Jun '17

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > When count in const_upload_info is calculated precisely (considering actual > constant set length), boolean matrix setting fall in direct copy path, unless > transpose is required. The case of incomplete last row for matrix should be > handled in set_constants() for transposed boolean constant only. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - added check for constant size not exceeding parameter size. The check for > non array, non struct constants should be sufficient as the dimensions of > arrays and structs are derived from const_set data and register counts > from constant description is not used for them. I don't understand what you mean here. > @@ -1417,6 +1433,16 @@ static HRESULT init_set_constants_param(struct d3dx_const_tab *const_tab, ID3DXC > && !info.transpose && info.minor == info.major_stride > && info.count == get_offset_reg(const_set.table, const_set.register_count) > && info.count * sizeof(unsigned int) <= param->bytes; > + if (info.minor_remainder && !const_set.direct_copy && !info.transpose) > + FIXME("Incomplete last row for not transposed matrix which cannot be directly copied, parameter %s.\n", > + debugstr_a(param->name)); > + > + if (info.major_count > info.major > + || (info.major_count == info.major && info.minor_remainder)) > + { > + WARN("Constant dimensions exceed parameter size.\n"); > + return D3DERR_INVALIDCALL; > + } It seems to me that this catches all the problematic cases.

2 2

Re: [v5 1/3] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni 27 Jun '17

27 Jun '17

2017-06-22 15:11 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v5: > - Removed assert for parameter data length. The check for constant size not exceeding parameter size > is in the next patch. Otherwise the code would be changed right in the next patch after modifying > get_const_upload_info(), while before that the check is redundant. Yeah, it would have been slightly preferable with the check in a separate patch before this one. The check would have been redundant in practice but that's a bit of an "implementation detail". Certainly not a big deal though.

1 0

Re: [PATCH 2/2] d3drm: Store animation options
by Henri Verbeet 27 Jun '17

27 Jun '17

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_SetOptions(IDirect3DRMAnimation2 *iface, D3DRMANIMATIONOPTIONS options) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + static const DWORD supported_options = D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION > + | D3DRMANIMATION_SPLINEPOSITION | D3DRMANIMATION_SCALEANDROTATION | D3DRMANIMATION_POSITION; > + > + TRACE("iface %p, options %#x.\n", iface, options); > + > + if (options && !(options & supported_options)) > + return D3DRMERR_BADVALUE; Should that be "if (options & ~supported_options)"? The test is ambiguous about that. > @@ -6776,6 +6777,42 @@ static void test_animation(void) > IDirect3DRMFrame3_Release(frame3); > IDirect3DRMFrame_Release(frame); > > + /* Animation options. */ > + options = IDirect3DRMAnimation_GetOptions(animation); > + ok(options == (D3DRMANIMATION_CLOSED | D3DRMANIMATION_LINEARPOSITION), > + "Unexpected default options %#x.\n", options); > + > + /* Undefined mask value */ > + hr = IDirect3DRMAnimation_SetOptions(animation, 0xdeadbeef); > + ok(hr == D3DRMERR_BADVALUE, "Unexpected hr %#x.\n", hr); 0xdeadbeef is a bit of a poor test value here, since it will trigger both the "D3DRMANIMATION_OPEN | D3DRMANIMATION_CLOSED" and "D3DRMANIMATION_LINEARPOSITION | D3DRMANIMATION_SPLINEPOSITION" paths as well. Is it valid to set 0 as an option? Is it valid to set e.g. D3DRMANIMATION_OPEN, but not one of D3DRMANIMATION_LINEARPOSITION and D3DRMANIMATION_SPLINEPOSITION? I.e., is it just invalid to set conflicting options, or should always exactly one of OPEN/CLOSED and LINEARPOSITION/SPLINEPOSITION be set?

2 3

Re: [PATCH 1/2] d3drm: Store animated frame pointer in animation object
by Henri Verbeet 27 Jun '17

27 Jun '17

On 27 June 2017 at 10:17, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > static HRESULT WINAPI d3drm_animation1_SetFrame(IDirect3DRMAnimation *iface, IDirect3DRMFrame *frame) > { > - FIXME("iface %p, frame %p.\n", iface, frame); > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation(iface); > + HRESULT hr = D3DRM_OK; > > - return E_NOTIMPL; > + TRACE("iface %p, frame %p.\n", iface, frame); > + > + if (frame) > + { > + hr = IDirect3DRMFrame_QueryInterface(frame, &IID_IDirect3DRMFrame3, (void **)&animation->frame); > + if (SUCCEEDED(hr)) > + IDirect3DRMFrame3_Release(animation->frame); > + } > + else > + animation->frame = NULL; > + > + return hr; > } There's nothing necessarily wrong with this, but I feel the following alternative is worth pointing out: struct d3drm_frame *f = unsafe_impl_from_IDirect3DRMFrame(frame); ... animation->frame = f ? &f->IDirect3DRMFrame3_iface : NULL; return D3DRM_OK; or even ... return d3drm_animation2_SetFrame(&animation->IDirect3DRMAnimation2_iface, f ? &f->IDirect3DRMFrame3_iface : NULL); which is a pattern that's used in ddraw for this kind of thing.

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Clemens Tamme 27 Jun '17

27 Jun '17

ok, i will rewrite so the same terms are used in the docs of GdipAddPathLine and GdipAddPathEllipse 2017-06-26 22:18 GMT+02:00 Marvin <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Assigned". > > This means that the patch has been assigned to a reviewer. If the > reviewer signs off on the patch, it will be committed, otherwise > you'll receive advice on how to improve it. If you don't hear anything > after a couple of weeks, please resend the patch. >

1 0

Re: [PATCH v3 1/4] msi/tests: Add tests for external UI callback.
by Marvin 27 Jun '17

27 Jun '17

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=31868 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 3/4] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin 27 Jun '17

27 Jun '17

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=31865 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 2/4] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin 27 Jun '17

27 Jun '17

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=31864 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v2 1/4] msi/tests: Add tests for external UI callback.
by Marvin 27 Jun '17

27 Jun '17

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=31863 Your paranoid android. === wvistau64 (32 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9397: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [v3 2/2] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin 26 Jun '17

26 Jun '17

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=31853 Your paranoid android. === w7u (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9860: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9864: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9867: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk 26 Jun '17

26 Jun '17

This description is probably more complicated than it needs to be. If we want consistency with the GdipAddPathLine description, we can state it in terms of the newfigure value, which is ignored on input and TRUE on output. On Sat, Jun 24, 2017 at 11:26 AM, Clemens Tamme <clemens.tamme(a)gmail.com> wrote: > + * As an ellipse is always a new subpath the current subpath of the given path > + * cannot be continued afterwards. Additionally, the next thing added to the > + * path will be the start of the next subpath.

1 0

Re: [1/3] server: Add field for window display affinity.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Andrew Wesie <awesie(a)gmail.com> writes: > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > include/wine/server_protocol.h | 9 ++++++--- > server/protocol.def | 3 +++ > server/request.h | 4 +++- > server/window.c | 4 ++++ > 4 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h > index d31579c..f442a94 100644 > --- a/include/wine/server_protocol.h > +++ b/include/wine/server_protocol.h > @@ -47,7 +47,7 @@ struct reply_header > > struct request_max_size > { > - int pad[16]; > + int pad[18]; > }; You can't change the request size. Also note that this is a generated file, updated by tools/make_requests. Do you have an app that uses this across processes? Otherwise you can probably simply store a local flag for now. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Hans Leidekker 26 Jun '17

26 Jun '17

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -822,6 +823,8 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > CHAR szPackage[12]; > MSIHANDLE hPackage; > > + CoInitialize(NULL); > + > sprintf(szPackage, "#%u", hdb); > res = MsiOpenPackageA(szPackage, &hPackage); > if (res != ERROR_SUCCESS) > @@ -837,22 +840,39 @@ static UINT package_from_db(MSIHANDLE hdb, MSIHANDLE *handle) > return res; > } > > + CoUninitialize(); > + Why do you need this? > -static void create_test_file(const CHAR *name) > +static void create_file_data(LPCSTR name, LPCSTR data, DWORD size) > { > HANDLE file; > DWORD written; > > file = CreateFileA(name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > ok(file != INVALID_HANDLE_VALUE, "Failure to open file %s\n", name); > - WriteFile(file, name, strlen(name), &written, NULL); > + if (file == INVALID_HANDLE_VALUE) > + return; > + > + WriteFile(file, data, strlen(data), &written, NULL); > WriteFile(file, "\n", strlen("\n"), &written, NULL); > + > + if (size) > + { > + SetFilePointer(file, size, NULL, FILE_BEGIN); > + SetEndOfFile(file); > + } > + > CloseHandle(file); > } You're not using this in this patch set.

3 3

Re: [PATCH 4/5] msi: Implement INSTALLMESSAGE_INITIALIZE and INSTALLMESSAGE_TERMINATE.
by Marvin 26 Jun '17

26 Jun '17

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=31839 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Marvin 26 Jun '17

26 Jun '17

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=31838 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH 1/5] msi/tests: Add tests for external UI callback.
by Marvin 26 Jun '17

26 Jun '17

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=31836 Your paranoid android. === wvistau64 (32 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ" === wvistau64 (64 bit package) === package.c:9405: Test failed: MsiOpenPackage with valid db: in msg 0x0b000000 field 2: expected "", got "þþ"

1 0

Re: [PATCH v3] configure: Avoid clobbering x18 on arm64 within wine
by André Hentschel 26 Jun '17

26 Jun '17

1 0

Re: [v2 PATCH 1/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet 26 Jun '17

26 Jun '17

On 26 June 2017 at 01:16, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); That's a little misleading. > + > + *out = NULL; > + return CLASS_E_CLASSNOTAVAILABLE; > +}

1 0

Re: [PATCH 5/5] msi: Implement UI messages in MsiOpenPackage().
by Hans Leidekker 26 Jun '17

26 Jun '17

> @@ -1610,6 +1617,35 @@ UINT MSI_OpenPackageW(LPCWSTR szPackage, MSIPACKAGE **pPackage) > if (gszLogFile) > package->log_file = CreateFileW( gszLogFile, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); > + > + /* FIXME: when should these messages be sent? */ > + data_row = MSI_CreateRecord(3); > + /* FIXME: field 0 should be NULL */ > + MSI_RecordSetInteger(data_row, 1, 0); > + MSI_RecordSetInteger(data_row, 2, package->num_langids ? package->langids[0] : 0); > + MSI_RecordSetInteger(data_row, 3, msi_get_string_table_codepage(package->db->strings)); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + info_row = MSI_CreateRecord(0); > + GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, time_format, timet, 100); > + GetDateFormatW(LOCALE_USER_DEFAULT, 0, NULL, date_format, datet, 100); > + LoadStringW(msi_hInstance, IDS_INFO_LOGGINGSTART, info_template, 1024); > + sprintfW(info_message, info_template, datet, timet); > + MSI_RecordSetStringW(info_row, 0, info_message); > + MSI_ProcessMessage(package, INSTALLMESSAGE_INFO|MB_ICONHAND, info_row); > + > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); > + > + productname = msi_dup_property(package->db, INSTALLPROPERTY_PRODUCTNAMEW); > + MSI_RecordSetInteger(data_row, 1, 1); > + MSI_RecordSetStringW(data_row, 2, productname); > + MSI_RecordSetStringW(data_row, 3, NULL); > + MSI_ProcessMessage(package, INSTALLMESSAGE_COMMONDATA, data_row); Error handling.

1 0

Re: [PATCH 3/5] msi: Send the correct UI messages upon calling MsiDoAction().
by Hans Leidekker 26 Jun '17

26 Jun '17

On Sun, 2017-06-25 at 21:13 -0500, Zebediah Figura wrote: > @@ -156,18 +158,12 @@ static const WCHAR szValidateProductID[] = > static const WCHAR szWriteEnvironmentStrings[] = > {'W','r','i','t','e','E','n','v','i','r','o','n','m','e','n','t','S','t','r','i','n','g','s',0}; > > -static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > +static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action, LPCWSTR description, LPCWSTR template) > { > - static const WCHAR Query_t[] = > - {'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', > - '`','A','c','t','i','o', 'n','T','e','x','t','`',' ', > - 'W','H','E','R','E', ' ','`','A','c','t','i','o','n','`',' ','=', > - ' ','\'','%','s','\'',0}; > - MSIRECORD * row; > - > - row = MSI_QueryGetRecord( package->db, Query_t, action ); > - if (!row) > - return; > + MSIRECORD *row = MSI_CreateRecord(3); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetStringW(row, 2, description); > + MSI_RecordSetStringW(row, 3, template); Please check the result of the MSI_CreateRecord call. > @@ -175,28 +171,21 @@ static void ui_actionstart(MSIPACKAGE *package, LPCWSTR action) > static void ui_actioninfo(MSIPACKAGE *package, LPCWSTR action, BOOL start, > UINT rc) > { > - MSIRECORD * row; > - static const WCHAR template_s[]= > - {'A','c','t','i','o','n',' ','s','t','a','r','t',' ','%','s',':',' ', > - '%','s', '.',0}; > - static const WCHAR template_e[]= > - {'A','c','t','i','o','n',' ','e','n','d','e','d',' ','%','s',':',' ', > - '%','s', '.',' ','R','e','t','u','r','n',' ','v','a','l','u','e',' ', > - '%','i','.',0}; > + MSIRECORD *row; > + WCHAR template[1024]; > static const WCHAR format[] = > {'H','H','\'',':','\'','m','m','\'',':','\'','s','s',0}; > WCHAR message[1024]; > WCHAR timet[0x100]; > > GetTimeFormatW(LOCALE_USER_DEFAULT, 0, NULL, format, timet, 0x100); > - if (start) > - sprintfW(message,template_s,timet,action); > - else > - sprintfW(message,template_e,timet,action,rc); > - > - row = MSI_CreateRecord(1); > - MSI_RecordSetStringW(row,1,message); > - > + LoadStringW(msi_hInstance, start ? IDS_INFO_ACTIONSTART : IDS_INFO_ACTIONENDED, template, 1024); > + sprintfW(message, template, timet); > + > + row = MSI_CreateRecord(2); > + MSI_RecordSetStringW(row, 0, message); > + MSI_RecordSetStringW(row, 1, action); > + MSI_RecordSetInteger(row, 2, !rc); Same here.

1 0

Re: [PATCH 1/2] tools/winedbg: Add support for printing floating point registers.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > @@ -237,6 +237,14 @@ static struct dbg_internal_var be_x86_64_ctx[] = > {CV_AMD64_R13, "R13", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R13), dbg_itype_unsigned_long_int}, > {CV_AMD64_R14, "R14", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R14), dbg_itype_unsigned_long_int}, > {CV_AMD64_R15, "R15", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, R15), dbg_itype_unsigned_long_int}, > + {CV_AMD64_ST0, "ST0", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[ 0]), dbg_itype_long_real}, > + {CV_AMD64_ST0+1, "ST1", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[10]), dbg_itype_long_real}, > + {CV_AMD64_ST0+2, "ST2", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[20]), dbg_itype_long_real}, > + {CV_AMD64_ST0+3, "ST3", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[30]), dbg_itype_long_real}, > + {CV_AMD64_ST0+4, "ST4", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[40]), dbg_itype_long_real}, > + {CV_AMD64_ST0+5, "ST5", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[50]), dbg_itype_long_real}, > + {CV_AMD64_ST0+6, "ST6", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[60]), dbg_itype_long_real}, > + {CV_AMD64_ST0+7, "ST7", (DWORD_PTR*)FIELD_OFFSET(CONTEXT, FloatSave.RegisterArea[70]), dbg_itype_long_real}, This doesn't build: ../../../wine/include/winnt.h:757:42: error: ‘CONTEXT {aka struct _CONTEXT}’ has no member named ‘FloatSave’ ../../../wine/programs/winedbg/be_x86_64.c:240:53: note: in expansion of macro ‘FIELD_OFFSET’ -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] tools/winedbg: Add support for printing SSE (XMM) registers.
by Alexandre Julliard 26 Jun '17

26 Jun '17

Zebediah Figura <z.figura12(a)gmail.com> writes: > + for (cnt = 0; cnt < 8; cnt++) > + { > + dbg_printf( " xmm%u: uint=%016llx%016llx", cnt, > + xmm_area->XmmRegisters[cnt].High, xmm_area->XmmRegisters[cnt].Low ); Please avoid %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Improve DelNode and tests
by Alexandre Julliard 26 Jun '17

26 Jun '17

"katahiromz ." <katayama.hirofumi.mz(a)gmail.com> writes: > @@ -327,6 +328,149 @@ done: > return HRESULT_FROM_WIN32(dwLastError); > } > > +static HRESULT DELNODE_delete_file(LPWSTR fname) > +{ > + if (GetFileAttributesW(fname) != INVALID_FILE_ATTRIBUTES) > + { > + SetFileAttributesW(fname, FILE_ATTRIBUTE_NORMAL); > + if (DeleteFileW(fname)) > + { > + return S_OK; > + } > + } There shouldn't be any reason to retrieve attributes first. > + /* generate a path with wildcard suitable for iterating */ > + fname_len = lstrlenW(fname); > + if (fname_len && fname[fname_len - 1] != L'\\') > + { > + fname[fname_len++] = L'\\'; Please don't use wide character constants. > C_SRCS = \ > advpack.c \ > + delnode.c \ > files.c \ > install.c Please don't create a new file, the tests should go into files.c. > +static const NODEW s_nodesW[] = > +{ > + { L"dir1", TRUE }, /* 0 */ > + { L"dir1\\dir2", TRUE }, /* 1 */ > + { L"dir1\\dir2\\file1", FALSE }, /* 2 */ You can't use wide character strings in Wine. > +START_TEST(delnode) > +{ > + s_hAdvPack = LoadLibraryA("advpack.dll"); > + if (s_hAdvPack == NULL) > + { > + skip("unable to load advpack.dll\n"); > + return; > + } This shouldn't be necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Martin Storsjö 26 Jun '17

26 Jun '17

On Sat, 24 Jun 2017, André Hentschel wrote: > Am 21.06.2017 um 12:39 schrieb Martin Storsjo: >> On aarch64/arm64, clang/LLVM feels free to use x18 for normal code >> generation on linux (while the register is reserved on iOS/darwin). >> For windows/arm64, this register must not be clobbered. >> >> If targeting arm64, check for the clang cflags that allows this >> register to be left untouched. >> >> This makes sure that wine for aarch64 built with clang doesn't >> crash immediately on startup. >> >> Signed-off-by: Martin Storsjo <martin(a)martin.st> >> --- >> Now with the sign-off included, which was forgotten in v1. >> --- >> configure.ac | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/configure.ac b/configure.ac >> index 7ae29f7..5b5a1d8 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -179,6 +179,11 @@ case $host in >> CFLAGS="$CFLAGS -marm" >> AC_SUBST(TARGETFLAGS,"-marm") >> ;; >> + aarch64*) >> + # Clang needs these flags in order not to clobber the x18 register >> + WINE_TRY_CFLAGS([-Xclang -target-feature -Xclang +reserve-x18], >> + [CFLAGS="$CFLAGS -Xclang -target-feature -Xclang +reserve-x18"]) >> + ;; >> i[[3456789]]86*) >> enable_win16=${enable_win16:-yes} >> ;; >> > > I think it's worthwhile adding it > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> FWIW, in case Alexandre also reconsiders merging it since you think it's worthwhile adding it - I reposted a v3, using the gcc compatible flag syntax and with an improved commit message. // Martin

1 0

Re: [4/6] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName. (v2)
by Dmitry Timoshkov 25 Jun '17

25 Jun '17

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > +static const WCHAR *map_shortname_to_schema(const GUID *format, const WCHAR *name) > +{ > + UINT i; > + > + /* It appears that the only metadata formats > + * that support schemas are xmp and xmpstruct. > ++ */ Oops. I hope that a typo in the comment won't require another resend. Alexandre, could you please remove extra '+' in the comment above if the patch gets accepted? Thanks. -- Dmitry.

1 0

Re: [6/7] windowscodecs: Add some tests for IWICMetadataQueryReader.
by Vincent Povirk 25 Jun '17

25 Jun '17

> + if (CompareStringW(LOCALE_NEUTRAL, NORM_IGNORECASE, queryW, len-1, name, len-1) == CSTR_EQUAL && decoder_data[j].query[len - 1] != 0) > + { > + if (winetest_debug > 1) > + trace("query: %s\n", wine_dbgstr_w(queryW + len - 1)); > + PropVariantInit(&value); Shouldn't this be PropVariantClear?

2 1

Re: [5/7] windowscodecs: Add initial implementation of IWICMetadataQueryReader::GetMetadataByName.
by Vincent Povirk 25 Jun '17

25 Jun '17

> + if (vt == VT_CLSID) > + { > + id->u.puuid = CoTaskMemAlloc(sizeof(GUID)); > + if (!id->u.puuid) return E_OUTOFMEMORY; > + > + hr = UuidFromStringW(next_token.u.bstrVal, id->u.puuid); > + } > + else > + hr = PropVariantChangeType(id, &next_token, 0, vt); > + PropVariantClear(&next_token); > + if (hr != S_OK) > + { > + PropVariantClear(id); > + PropVariantClear(schema); > + return hr; > + } > + > + id->vt = vt; Assigning the vt at the end of this is a bit strange. I don't know any situation here where PropVariantChangeType will succeed without giving you the requested vt, and if it did, changing it would be unsafe. I can see you need it in the VT_CLSID case, but then it would make more sense to set it there. In fact, this version will leak memory if UuidFromStringW fails. + if (!elem.len) break; When can this happen? + new_value.vt = VT_UNKNOWN; + hr = MetadataQueryReader_CreateInstance(This->block, root, (IWICMetadataQueryReader **)&new_value.u.punkVal); I think you need to clear new_value first here?

2 1

Re: [PATCH v2] configure: Avoid clobbering x18 on arm64 when building with clang
by Alexandre Julliard 24 Jun '17

24 Jun '17

Martin Storsjo <martin(a)martin.st> writes: > On aarch64/arm64, clang/LLVM feels free to use x18 for normal code > generation on linux (while the register is reserved on iOS/darwin). > For windows/arm64, this register must not be clobbered. This would have to be made the default system-wide, fixing it on the Wine side isn't good enough since we call system libraries. -- Alexandre Julliard julliard(a)winehq.org

3 7

Re: [PATCH] gdiplus: Write API doc for GdipAddPathEllipse and GdipAddPathEllipseI
by Vincent Povirk 24 Jun '17

24 Jun '17

+ * GenericError If conversion from arc to bezier curve fails When would this happen? Best I can tell, it isn't supposed to be possible, and the check is just coding defensively. + * Ok If ecerything works out as expected Typo.

2 1

Re: [3/3] user32/tests: Add test for GetWindowDisplayAffinity.
by Marvin 23 Jun '17

23 Jun '17

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=31812 Your paranoid android. === w7u (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (32 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8 === w7pro64 (64 bit win) === win.c:9858: Test failed: SetWindowDisplayAffinity returned with 8 win.c:9862: Test failed: GetWindowDisplayAffinity returned unexpected affinity 0 win.c:9865: Test failed: SetWindowDisplayAffinity returned with 8

2 1

Re: [PATCH 2/2] d3drm: Added IDirect3DRMWrap stub
by Henri Verbeet 23 Jun '17

23 Jun '17

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_wrap_QueryInterface(IDirect3DRMWrap *iface, REFIID riid, void **out) > +{ > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMWrap) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + IDirect3DRMWrap_AddRef(iface); > + *out = iface; > + return S_OK; > + } > + > + WARN("%s not implemented, returning E_NOINTERFACE.\n", debugstr_guid(riid)); > + > + *out = NULL; > + return E_NOINTERFACE; > +} Likewise, while E_NOINTERFACE would normally be the expected value, that's not a given with d3drm. > +static ULONG WINAPI d3drm_wrap_Release(IDirect3DRMWrap *iface) > +{ > + struct d3drm_wrap *wrap = impl_from_IDirect3DRMWrap(iface); > + ULONG refcount = InterlockedDecrement(&wrap->ref); > + > + TRACE("%p decreasing refcount to %u.\n", iface, refcount); > + > + if (!refcount) > + { > + d3drm_object_cleanup((IDirect3DRMObject *)iface, &wrap->obj); > + //IDirect3DRM_Release(mesh->d3drm); C99 comment. > @@ -109,10 +109,10 @@ static void test_class_name_(unsigned int line, IDirect3DRMObject *object, const > ok_(__FILE__, line)(hr == D3DRM_OK, "Failed to get classname size, hr %#x.\n", hr); > ok_(__FILE__, line)(size == strlen(name) + 1, "wrong size: %u\n", size); > > - size = 1; > + size = size2 = *name ? 1 : 0; I think "!!*name" would be more obvious, but don't care strongly.

1 0

Re: [PATCH 1/2] d3drm: Added IDirect3DRMAnimation stub
by Henri Verbeet 23 Jun '17

23 Jun '17

On 23 June 2017 at 15:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static HRESULT WINAPI d3drm_animation2_QueryInterface(IDirect3DRMAnimation2 *iface, REFIID riid, void **out) > +{ > + struct d3drm_animation *animation = impl_from_IDirect3DRMAnimation2(iface); > + > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > + || IsEqualGUID(riid, &IID_IUnknown)) > + { > + *out = &animation->IDirect3DRMAnimation_iface; > + } > + else if (IsEqualGUID(riid, &IID_IDirect3DRMAnimation2)) > + { > + *out = &animation->IDirect3DRMAnimation2_iface; > + } > + else > + { > + *out = NULL; > + WARN("%s not implemented, returning CLASS_E_CLASSNOTAVAILABLE.\n", debugstr_guid(riid)); > + return CLASS_E_CLASSNOTAVAILABLE; I suspect CLASS_E_CLASSNOTAVAILABLE is correct, since other d3drm interfaces are unusual like that as well, but it would be good to have that backed up by the tests.

1 0

Re: [PATCH 1/4] d3drm: Make it possible to create material objects with CreateObject().
by Henri Verbeet 22 Jun '17

22 Jun '17

On 21 June 2017 at 14:39, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index fc19b97b8b..6c2903226a 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1404,6 +1404,8 @@ static void test_object(void) > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame2 }, > { &CLSID_CDirect3DRMFrame, &IID_IDirect3DRMFrame3 }, > { &CLSID_CDirect3DRMLight, &IID_IDirect3DRMLight }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial }, > + { &CLSID_CDirect3DRMMaterial, &IID_IDirect3DRMMaterial2 }, > }; > IDirect3DRM *d3drm1; > IDirect3DRM2 *d3drm2; > @@ -1429,7 +1431,8 @@ static void test_object(void) > { > BOOL takes_ref = IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMeshBuilder) || > IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMFrame) || > - IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight); > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMLight) || > + IsEqualGUID(tests[i].clsid, &CLSID_CDirect3DRMMaterial); If there are going to be more of these, it probably makes sense to just include the information as a field in tests[].

2 1

Re: winhttp: Reset content length when a redirect creates a new connection.
by Alistair Leslie-Hughes 22 Jun '17

22 Jun '17

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>

1 0

Re: [PATCH 4/4] d3drm: Make it possible to create meshes with CreateObject().
by Henri Verbeet 22 Jun '17

22 Jun '17

On 21 June 2017 at 14:39, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > diff --git a/dlls/d3drm/d3drm_private.h b/dlls/d3drm/d3drm_private.h > index 1b00e1a36d..af79b43292 100644 > --- a/dlls/d3drm/d3drm_private.h > +++ b/dlls/d3drm/d3drm_private.h > @@ -147,6 +147,30 @@ struct d3drm_mesh_builder > DWORD *material_indices; > }; > > +struct mesh_group > +{ > + unsigned nb_vertices; > + D3DRMVERTEX* vertices; > + unsigned nb_faces; > + unsigned vertex_per_face; > + DWORD face_data_size; > + unsigned* face_data; > + D3DCOLOR color; > + IDirect3DRMMaterial2* material; > + IDirect3DRMTexture3* texture; > +}; Not new, but misleading "*" placement.

1 0

Re: [PATCH 1/2] Update make_specfiles to handle ucrtbase's _o_* functions
by Alexandre Julliard 22 Jun '17

22 Jun '17

Max Qian <public(a)maxqia.com> writes: > Helps fix https://bugs.winehq.org/show_bug.cgi?id=38960 > I'm 99% sure that all of them redirect to the non _o_ functions, > and this is required to get Steam working with Windows <=7 mode. I expect that there's a reason behind the _o_ functions, and it's probably worth figuring out. In any case, you don't want to have a dll forward to itself, you should link to the same target function instead (assuming that's really what the _o_ functions are supposed to do). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2] api-ms-win-core-crt-l1-1-0: Add dll.
by Alexandre Julliard 22 Jun '17

22 Jun '17

Andrey Gusev <andrey.goosev(a)gmail.com> writes: > +@ cdecl -arch=i386 -ret64 _ftol2() MSVCRT__ftol > +@ cdecl -arch=i386 -ret64 _ftol2_sse() MSVCRT__ftol This can't work, the function isn't in this dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] oleaut32: check return code of Currency2Integer (Coverity)
by Dmitry Timoshkov 22 Jun '17

22 Jun '17

Marcus Meissner <marcus(a)jet.franken.de> wrote: > HRESULT WINAPI VarI1FromCy(CY cyIn, signed char* pcOut) > { > LONG i = I1_MAX + 1; > + HRESUTL hr; > > - VarI4FromCy(cyIn, &i); > - return _VarI1FromI4(i, pcOut); > + hr = VarI4FromCy(cyIn, &i); > + > + if (SUCCEEDED(hr)) > + hr = _VarI1FromI4(i, pcOut); > + return hr; > } I guess that this change makes initialization of 'i' redundant. Here and in remaining cases. Probably needs a test case though to make sure which behaviour is more correct. -- Dmitry.

1 0

Re: rsaenh: Avoid double 'va_end(args)' in case of a premature loop termination.
by Sebastian Lackner 22 Jun '17

22 Jun '17

On 21.06.2017 10:24, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/rsaenh/mpi.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/rsaenh/mpi.c b/dlls/rsaenh/mpi.c > index 03e31023e6..dcf6ddf112 100644 > --- a/dlls/rsaenh/mpi.c > +++ b/dlls/rsaenh/mpi.c > @@ -2365,10 +2365,7 @@ int mp_init_multi(mp_int *mp, ...) > succeeded in init-ing, then return error. > */ > va_list clean_args; > - > - /* end the current list */ > - va_end(args); > - > + > /* now start cleaning up */ > cur_arg = mp; > va_start(clean_args, mp); > @@ -2381,6 +2378,7 @@ int mp_init_multi(mp_int *mp, ...) > break; > } > n++; > + va_end(args); Doesn't this change make it even worse? Whats the purpose of calling va_end() when the enumeration isn't finished yet? > cur_arg = va_arg(args, mp_int*); > } > va_end(args); >

2 3

Re: [11/17] windowscodecs: Simplify a bit comparison of two PROPVARIANTs.
by Vincent Povirk 22 Jun '17

22 Jun '17

I'm not sure the point of changing this when we're just going to replace it with PropVariantCompareEx.

2 1

Re: [13/17] windowscodecs: Use PropVariantCompareEx to compare metadata items.
by Vincent Povirk 22 Jun '17

22 Jun '17

This breaks the windowscodecs/metadata test here. fixme:propsys:PropVariantCompareEx vartype 30 not handled metadata.c:382: Test failed: GetValue failed, hr=88982f40 fixme:propsys:PropVariantCompareEx vartype 30 not handled metadata.c:388: Test failed: GetValue failed, hr=88982f40 metadata.c:389: Test failed: unexpected vt: 30 wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed13c05 (thread 0009), starting debugger...

2 1

Re: [v4 1/4] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni 21 Jun '17

21 Jun '17

2017-06-19 11:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v4: > - added assert() for parameter size. > --- > dlls/d3dx9_36/preshader.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2785ca3..76d6de9 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1178,11 +1178,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > param_offset = i + j * info.major; > else > param_offset = i * info.minor + j; > - if (param_offset * sizeof(unsigned int) >= param->bytes) > - { > - WARN("Parameter data is too short, name %s, component %u.\n", debugstr_a(param->name), i); > - break; > - } > out[offset] = data[param_offset]; > } > } > @@ -1303,6 +1298,11 @@ static HRESULT merge_const_set_entries(struct d3dx_const_tab *const_tab, > memmove(&const_tab->const_set[index + 1], &const_tab->const_set[i], > sizeof(*const_tab->const_set) * (const_tab->const_set_count - i)); > const_tab->const_set_count -= i - index - 1; > + assert(param->bytes >= table_info[first_const->table].component_size > + * first_const->element_count > + * (first_const->direct_copy ? get_reg_components(first_const->table) > + * first_const->register_count > + : first_const->param->rows * first_const->param->columns)); I don't think an assert() is correct here. You are comparing parameter size, which eventually depends on the effect data, with the constant size, which comes from the constant table and thus again the effect data. In general we shouldn't assert on invalid input data. Also by putting the assert() in merge_const_set_entries() you're not checking the non-array, non-struct constants. Am I missing something? Is there something else that would trigger if e.g. a 4x4 matrix constants gets matched with a 3x4 parameter?

2 4

Re: [PATCH 1/2] quartz: Restore a comment explaining mediatime.
by Matteo Bruni 21 Jun '17

21 Jun '17

2017-06-19 21:15 GMT+02:00 Zebediah Figura <z.figura12(a)gmail.com>: > This comment was removed by 0a6f11c8, possibly by accident. > The usage of the term "media time" here is confusing, both > because it does not describe time (or any meaningful unit) > and also because it conflicts with the normal definition of > "media time", viz. length in number of samples. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/quartz/quartz_private.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h > index 7cad3a75640..a9855e95acd 100644 > --- a/dlls/quartz/quartz_private.h > +++ b/dlls/quartz/quartz_private.h > @@ -33,6 +33,7 @@ > #include "wine/strmbase.h" > #include "wine/list.h" > > +/* see IAsyncReader::Request on MSDN for the explanation of this */ > #define MEDIATIME_FROM_BYTES(x) ((LONGLONG)(x) * 10000000) > #define SEC_FROM_MEDIATIME(time) ((time) / 10000000) > #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) Is it reasonable to put some short explanation right here (i.e. removing the middle man) instead?

2 1

Re: [v4 4/4] d3dx9: Move transpose 'if' outside of the inner loop in set_constants().
by Matteo Bruni 21 Jun '17

21 Jun '17

2017-06-19 11:24 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v4: > - updated to handle incomplete row of transposed matrix accordingly. > --- > dlls/d3dx9_36/preshader.c | 26 ++++++++++---------------- > 1 file changed, 10 insertions(+), 16 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 9a2ecfa..39bd483 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1138,7 +1138,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > unsigned int table = const_set->table; > struct d3dx_parameter *param = const_set->param; > unsigned int element, i, j, start_offset; > - unsigned int param_offset; > struct const_upload_info info; > unsigned int *data = param->data; > enum pres_value_type param_type; > @@ -1178,24 +1177,19 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > > /* Store reshaped but (possibly) not converted yet data temporarily in the same constants buffer. > * All the supported types of parameters and table values have the same size. */ > - for (i = 0; i < info.major_count; ++i) > - { > - for (j = 0; j < info.minor; ++j) > - { > - if (info.transpose) > - param_offset = i + j * info.major; > - else > - param_offset = i * info.minor + j; > - out[i * info.major_stride + j] = data[param_offset]; > - } > - } > if (info.transpose) > { > + for (i = 0; i < info.major_count; ++i) > + for (j = 0; j < info.minor; ++j) > + out[i * info.major_stride + j] = data[i + j * info.major]; > + > for (j = 0; j < info.minor_remainder; ++j) > - { > - param_offset = i + j * info.major; > - out[i * info.major_stride + j] = data[param_offset]; > - } > + out[i * info.major_stride + j] = data[i + j * info.major]; } Accidental backspace? ;)

1 0

Re: [PATCH v2 2/4] winemp3.acm: Disallow operations encoding to MPEG.
by Andrew Eikum 21 Jun '17

21 Jun '17

I'd like this more with tests, showing what the application was doing and how Wine failed its expectations but now meets them. Andrew On Fri, Jun 09, 2017 at 06:08:28PM -0500, Zebediah Figura wrote: > Since the winemp3 driver is currently decode-only, and most Windows > versions do not ship by default with a driver capable of encoding > to mpeg3, we should report the driver's capabilities accordingly. > > v2: remove failing tests > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/winemp3.acm/mpegl3.c | 80 ++++++++++------------------------------------- > 1 file changed, 17 insertions(+), 63 deletions(-) > > diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c > index cc6008da59e..c5d71bba524 100644 > --- a/dlls/winemp3.acm/mpegl3.c > +++ b/dlls/winemp3.acm/mpegl3.c > @@ -258,10 +258,13 @@ static LRESULT MPEG3_StreamOpen(PACMDRVSTREAMINSTANCE adsi) > mpg123_param(aad->mh, MPG123_ADD_FLAGS, MPG123_IGNORE_INFOFRAME, 0); > #endif > } > - /* no encoding yet > else if (adsi->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM && > - adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEGLAYER3) > - */ > + (adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEGLAYER3 || > + adsi->pwfxDst->wFormatTag == WAVE_FORMAT_MPEG)) > + { > + WARN("Encoding to MPEG is not supported\n"); > + goto theEnd; > + } > else goto theEnd; > MPEG3_Reset(adsi, aad); > > @@ -736,54 +739,19 @@ static LRESULT MPEG3_FormatTagDetails(PACMFORMATTAGDETAILSW aftd, DWORD dwQuery) > case 1: > aftd->dwFormatTag = WAVE_FORMAT_MPEGLAYER3; > aftd->cbFormatSize = sizeof(MPEGLAYER3WAVEFORMAT); > - aftd->cStandardFormats = NUM_MPEG3_FORMATS; > + aftd->cStandardFormats = 0; > lstrcpyW(aftd->szFormatTag, szMpeg3); > break; > case 2: > aftd->dwFormatTag = WAVE_FORMAT_MPEG; > aftd->cbFormatSize = sizeof(MPEG1WAVEFORMAT); > - aftd->cStandardFormats = NUM_MPEG3_FORMATS; > + aftd->cStandardFormats = 0; > lstrcpyW(aftd->szFormatTag, szMpeg); > break; > } > return MMSYSERR_NOERROR; > } > > -static void fill_in_mp3(unsigned cbwfx, WAVEFORMATEX* wfx, unsigned bit_rate) > -{ > - MPEGLAYER3WAVEFORMAT* mp3wfx = (MPEGLAYER3WAVEFORMAT*)wfx; > - > - wfx->nAvgBytesPerSec = bit_rate / 8; > - if (cbwfx >= sizeof(WAVEFORMATEX)) > - wfx->cbSize = sizeof(MPEGLAYER3WAVEFORMAT) - sizeof(WAVEFORMATEX); > - if (cbwfx >= sizeof(MPEGLAYER3WAVEFORMAT)) > - { > - mp3wfx->wID = MPEGLAYER3_ID_MPEG; > - mp3wfx->fdwFlags = MPEGLAYER3_FLAG_PADDING_OFF; > - mp3wfx->nBlockSize = (bit_rate * 144) / wfx->nSamplesPerSec; > - mp3wfx->nFramesPerBlock = 1; > - mp3wfx->nCodecDelay = 0x0571; > - } > -} > - > -static void fill_in_mpeg(unsigned cbwfx, WAVEFORMATEX* wfx, unsigned bit_rate) > -{ > - MPEG1WAVEFORMAT* mp3wfx = (MPEG1WAVEFORMAT*)wfx; > - > - wfx->nAvgBytesPerSec = bit_rate / 8; > - if (cbwfx >= sizeof(WAVEFORMATEX)) > - wfx->cbSize = sizeof(MPEG1WAVEFORMAT) - sizeof(WAVEFORMATEX); > - if (cbwfx >= sizeof(MPEG1WAVEFORMAT)) > - { > - mp3wfx->fwHeadLayer = ACM_MPEG_LAYER3; > - mp3wfx->dwHeadBitrate = wfx->nAvgBytesPerSec * 8; > - mp3wfx->fwHeadMode = ACM_MPEG_JOINTSTEREO; > - mp3wfx->fwHeadModeExt = 0xf; > - mp3wfx->wHeadEmphasis = 1; > - mp3wfx->fwHeadFlags = ACM_MPEG_ID_MPEG1; > - } > -} > - > /*********************************************************************** > * MPEG3_FormatDetails > * > @@ -814,16 +782,8 @@ static LRESULT MPEG3_FormatDetails(PACMFORMATDETAILSW afd, DWORD dwQuery) > break; > case WAVE_FORMAT_MPEGLAYER3: > case WAVE_FORMAT_MPEG: > - if (afd->dwFormatIndex >= NUM_MPEG3_FORMATS) return ACMERR_NOTPOSSIBLE; > - afd->pwfx->nChannels = MPEG3_Formats[afd->dwFormatIndex].nChannels; > - afd->pwfx->nSamplesPerSec = MPEG3_Formats[afd->dwFormatIndex].rate; > - afd->pwfx->wBitsPerSample = MPEG3_Formats[afd->dwFormatIndex].nBits; > - afd->pwfx->nBlockAlign = 1; > - if (afd->dwFormatTag == WAVE_FORMAT_MPEGLAYER3) > - fill_in_mp3(afd->cbwfx, afd->pwfx, 192000); > - else > - fill_in_mpeg(afd->cbwfx, afd->pwfx, 192000); > - break; > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > default: > WARN("Unsupported tag %08x\n", afd->dwFormatTag); > return MMSYSERR_INVALPARAM; > @@ -856,18 +816,15 @@ static LRESULT MPEG3_FormatSuggest(PACMDRVFORMATSUGGEST adfs) > adfs->pwfxDst->nChannels = adfs->pwfxSrc->nChannels; > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_NSAMPLESPERSEC)) > adfs->pwfxDst->nSamplesPerSec = adfs->pwfxSrc->nSamplesPerSec; > - > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WBITSPERSAMPLE)) > - { > - if (adfs->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM) > - adfs->pwfxDst->wBitsPerSample = 4; > - else > - adfs->pwfxDst->wBitsPerSample = 16; > - } > + adfs->pwfxDst->wBitsPerSample = 16; > if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WFORMATTAG)) > { > if (adfs->pwfxSrc->wFormatTag == WAVE_FORMAT_PCM) > - adfs->pwfxDst->wFormatTag = WAVE_FORMAT_MPEGLAYER3; > + { > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > + } > else > adfs->pwfxDst->wFormatTag = WAVE_FORMAT_PCM; > } > @@ -883,12 +840,9 @@ static LRESULT MPEG3_FormatSuggest(PACMDRVFORMATSUGGEST adfs) > adfs->pwfxDst->nAvgBytesPerSec = adfs->pwfxDst->nSamplesPerSec * adfs->pwfxDst->nBlockAlign; > break; > case WAVE_FORMAT_MPEG: > - adfs->pwfxDst->nBlockAlign = 1; > - fill_in_mpeg(adfs->cbwfxDst, adfs->pwfxDst, 192000); > - break; > case WAVE_FORMAT_MPEGLAYER3: > - adfs->pwfxDst->nBlockAlign = 1; > - fill_in_mp3(adfs->cbwfxDst, adfs->pwfxDst, 192000); > + WARN("Encoding to MPEG is not supported\n"); > + return ACMERR_NOTPOSSIBLE; > break; > default: > FIXME("\n"); > -- > 2.13.0 > > >

2 4

Re: user.exe16: Fix memory leaks in cases when HeapReAlloc fails.
by Alexandre Julliard 21 Jun '17

21 Jun '17

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -3286,7 +3289,8 @@ DWORD WINAPI FormatMessage16( > } > talloced = strlen(target)+1; > if (nSize && talloced<nSize) { > - target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,nSize); > + LPSTR new_target = HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,target,nSize); > + if (new_target) target = new_target; You could probably remove it entirely. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] gdi32: Don't write EMR_EXTSELECTCLIPRGN to emf file on SelectClipPath call
by Dmitry Timoshkov 21 Jun '17

21 Jun '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdi32/enhmfdrv/dc.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) It shouldn't be too hard to add an appropriate test case. -- Dmitry.

1 0

Re: [PATCH 1/5] cryptnet: label ordinals
by Alexandre Julliard 21 Jun '17

21 Jun '17

Austin English <austinenglish(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > -@ stub CertDllVerifyCTLUsage > -@ stdcall CertDllVerifyRevocation(long long long ptr long ptr ptr) > -@ stub CryptnetWlxLogoffEvent > -@ stub LdapProvOpenStore > +1 stub CertDllVerifyCTLUsage > +2 stdcall CertDllVerifyRevocation(long long long ptr long ptr ptr) > +3 stub CryptnetWlxLogoffEvent > +4 stub LdapProvOpenStore I see no evidence that these should have ordinals, they differ across versions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] api-ms-win-core-crt-l1-1-0: Add dll.
by Alexandre Julliard 21 Jun '17

21 Jun '17

Andrey Gusev <andrey.goosev(a)gmail.com> writes: > @@ -53,6 +53,13 @@ my @dll_groups = > ], > [ > "ucrtbase", > + "msvcr120", > + "msvcrt", > + "ntdll", > + "api-ms-win-core-crt-l1-1-0", You can't have all these dlls forward to ucrtbase. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ole32: Add stub for OleGetIconOfFile.
by Dmitry Timoshkov 21 Jun '17

21 Jun '17

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > +HGLOBAL WINAPI OleGetIconOfFile(LPOLESTR path, BOOL use_file_as_label) > +{ > + FIXME("(%p, %d), stub!\n", path, use_file_as_label); > + return NULL; > +} Probably 'path' should be printed with debugstr_w(), > +@ stdcall OleGetIconOfFile(ptr long) ... and argument type should be 'wstr' instead of 'ptr'. -- Dmitry.

2 1

Re: [06/17] propsys: Add support for VT_LPSTR and VT_LPWSTR to PropVariantCompareEx. (v2)
by Alexandre Julliard 20 Jun '17

20 Jun '17

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -112,6 +116,15 @@ static HRESULT PROPVAR_ConvertNumber(REFPROPVARIANT pv, int dest_bits, > src_signed = FALSE; > *res = 0; > break; > + case VT_LPSTR: > + *res = strtoll(pv->u.pszVal, NULL, 0); > + src_signed = *res < 0; > + break; > + case VT_LPWSTR: > + case VT_BSTR: > + *res = strtolW(pv->u.pwszVal, NULL, 0); > + src_signed = *res < 0; > + break; This could probably use a little error checking. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 07/12] server: Introduce default async queue that's used if async is not explicitly queued in fd op.
by Alexandre Julliard 20 Jun '17

20 Jun '17

Jacek Caban <jacek(a)codeweavers.com> writes: > Although (at least now) all read and write implementations always queue > async on success, it's not the case for ioctl. I think we should allow > simple ioctls without pending results to not care about explicitly > handling async objects, but those still need a queued async for proper > result reporting. We currently don't set events, queue APCs nor send > completion for them. > > My initial thought was to make async object work better without > associated queue, but that leads to problems with references from an > async to fd. I think that would be better than creating a dummy queue. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [17/17] windowscodecs: Add some tests for IWICMetadataQueryReader.
by Marvin 20 Jun '17

20 Jun '17

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=31731 Your paranoid android. === w8 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w864 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w1064 (32 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w864 (64 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} === w1064 (64 bit metadata) === metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36} metadata.c:2531: Test failed: unknown iid {00240e6f-3f23-4432-b0cc-48d5bbff6c36}

2 1

Re: [PATCH] gdiplus: Implement triangular line caps in widened paths.
by Clemens Tamme 19 Jun '17

19 Jun '17

Great, thanks for letting me know! Am 19.06.2017 22:20 schrieb "Marvin" <testbot(a)winehq.org>: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Committed". > > This means that your patch has been approved, and committed to the > main git tree. Congratulations! >

1 0

Re: [PATCH] shell32: Initialize members in SHGetFileInfo.
by Alexandre Julliard 19 Jun '17

19 Jun '17

"katahiromz ." <katayama.hirofumi.mz(a)gmail.com> writes: > From ca0631aa8766b91cc0183adc9f9f1fe99e058af0 Mon Sep 17 00:00:00 2001 > From: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > Date: Mon, 19 Jun 2017 13:02:33 +0900 > Subject: [PATCH] shell32: Initialize members in SHGetFileInfo. > > This patch kills some failures in shell32_winetest:shlfileop by > initializing some members of SHFILEINFO in SHGetFileInfoA/W. > > Tested on ReactOS r75083. > > before: shlfileop: 790 tests executed (0 marked as todo, 31 failures), 0 > skipped. > after: shlfileop: 790 tests executed (0 marked as todo, 22 failures), 0 > skipped. > > Signed-off-by: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > --- > dlls/shell32/shell32_main.c | 5 +++++ > 1 file changed, 5 insertions(+) You'd need to update the corresponding todos, but the patch is also causing failures: ../../../tools/runtest -q -P wine -T ../../.. -M shell32.dll -p shell32_test.exe.so shlfileop && touch shlfileop.ok shlfileop.c:200: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear hIcon shlfileop.c:201: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear szDisplayName[0] shlfileop.c:202: Test succeeded inside todo block: SHGetFileInfoA('' | 0) did not clear szTypeName[0] shlfileop.c:203: Test failed: SHGetFileInfoA('' | 0) should not clear iIcon shlfileop.c:238: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear hIcon shlfileop.c:239: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear szDisplayName[0] shlfileop.c:240: Test succeeded inside todo block: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) did not clear szTypeName[0] shlfileop.c:241: Test failed: SHGetFileInfoA(c:\nonexistent | SHGFI_ATTRIBUTES) should not clear iIcon shlfileop.c:386: Test succeeded inside todo block: SHGetFileInfoA(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear hIcon shlfileop.c:387: Test succeeded inside todo block: SHGetFileInfoA(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear szTypeName[0] shlfileop.c:412: Test succeeded inside todo block: SHGetFileInfoW(CSIDL_DESKTOP, SHGFI_SYSICONINDEX|SHGFI_SMALLICON|SHGFI_PIDL) did not clear hIcon shlfileop.c:713: Tests skipped: Test would show a dialog box Makefile:739: recipe for target 'shlfileop.ok' failed make: *** [shlfileop.ok] Error 11 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH v2 4/5] msi: Don't reimplement record formatting.
by Hans Leidekker 19 Jun '17

19 Jun '17

On Sun, 2017-06-18 at 21:53 -0500, Zebediah Figura wrote: > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index eae01e0..f16b1dc 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1709,8 +1709,8 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > static const WCHAR szSetProgress[] = {'S','e','t','P','r','o','g','r','e','s','s',0}; > static const WCHAR szActionText[] = {'A','c','t','i','o','n','T','e','x','t',0}; > MSIRECORD *uirow; > - LPWSTR deformated, message; > - DWORD i, len, total_len, log_type = 0; > + LPWSTR deformated, message = {0}; > + DWORD len, log_type = 0; > INT rc = 0; > char *msg; > > @@ -1776,39 +1776,10 @@ INT MSI_ProcessMessage( MSIPACKAGE *package, INSTALLMESSAGE eMessageType, MSIREC > } > else > { > - static const WCHAR format[] = {'%','u',':',' ',0}; > - UINT count = MSI_RecordGetFieldCount( record ); > - WCHAR *p; > - > - total_len = 1; > - for (i = 1; i <= count; i++) > - { > - len = 0; > - MSI_RecordGetStringW( record, i, NULL, &len ); > - total_len += len + 13; > - } > - p = message = msi_alloc( total_len * sizeof(WCHAR) ); > - if (!p) return ERROR_OUTOFMEMORY; > - > - for (i = 1; i <= count; i++) > - { > - if (count > 1) > - { > - len = sprintfW( p, format, i ); > - total_len -= len; > - p += len; > - } > - len = total_len; > - MSI_RecordGetStringW( record, i, p, &len ); > - total_len -= len; > - p += len; > - if (count > 1 && total_len) > - { > - *p++ = ' '; > - total_len--; > - } > - } > - p[0] = 0; > + MSI_FormatRecordW(package, record, message, &len); > + len++; > + message = msi_alloc(len * sizeof(WCHAR)); > + MSI_FormatRecordW(package, record, message, &len); You can pass a NULL buffer in the size query. Please keep the check for allocation failure. I would check the first call to MSI_FormatRecordW too since the record is passed by the caller.

2 1

Re: [v3 3/3] d3dx9: Remove redundant parameter size check in set_constants().
by Matteo Bruni 19 Jun '17

19 Jun '17

2017-06-15 0:00 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > v3: > no changes. > --- > dlls/d3dx9_36/preshader.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2785ca3..0bc31cb 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1178,11 +1178,6 @@ static void set_constants(struct d3dx_regstore *rs, struct d3dx_const_tab *const > param_offset = i + j * info.major; > else > param_offset = i * info.minor + j; > - if (param_offset * sizeof(unsigned int) >= param->bytes) > - { > - WARN("Parameter data is too short, name %s, component %u.\n", debugstr_a(param->name), i); > - break; > - } > out[offset] = data[param_offset]; Is there anything else covering this case though? If I'm not mistaken such a parameter / constant would be accepted currently so just dropping the check would potentially allow broken preshaders to read outside of the parameter data. Now I certainly agree that the check shouldn't be there, it should probably be in init_set_constants_param() instead. If this is already checked somewhere in the code then I'm okay with the patch as is.

2 1

Re: [PATCH 2/5] msi: Use an external UI record handler before a string handler.
by Marvin 18 Jun '17

18 Jun '17

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=31710 Your paranoid android. === wvistau64 (32 bit package) === package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 20 package.c:9107: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 22 package.c:9107: Test failed: message didn't match package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 24 package.c:9107: Test failed: message didn't match === wvistau64 (64 bit package) === package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 20 package.c:9107: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 22 package.c:9107: Test failed: message didn't match package.c:9086: Test failed: message didn't match package.c:9105: Test failed: expected 16, got 24 package.c:9107: Test failed: message didn't match

1 0

Re: [4/4] wined3d: Trigger frontbuffer update in surface_cpu_blt.
by Henri Verbeet 18 Jun '17

18 Jun '17

On 16 June 2017 at 16:03, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > In this case I'm not sure about the best way to fix it. Feel free to use > a different approach if preferred (for example calling > swapchain_frontbuffer_updated from context_unmap_bo_address). > Explicitly calling from surface_cpu_blt() is probably the right way to go. > @@ -3343,6 +3343,9 @@ release: > context_unmap_bo_address(context, &dst_data, GL_PIXEL_UNPACK_BUFFER); > if (!same_sub_resource) > context_unmap_bo_address(context, &src_data, GL_PIXEL_UNPACK_BUFFER); > + > + swapchain_frontbuffer_updated(dst_texture, dst_sub_resource_idx, dst_box); Strictly speaking this is only necessary on success, but doing it unconditionally shouldn't hurt. > @@ -1979,6 +1979,22 @@ static HRESULT texture_resource_sub_resource_map(struct wined3d_resource *resour > return WINED3D_OK; > } > > +void swapchain_frontbuffer_updated(struct wined3d_texture *texture, unsigned int sub_resource_idx, > + const struct wined3d_box *box) > +{ > + struct wined3d_texture_sub_resource *sub_resource; > + > + if (!texture->swapchain || texture->swapchain->front_buffer != texture) > + return; > + if (!(sub_resource = wined3d_texture_get_sub_resource(texture, sub_resource_idx))) > + return; The sub-resource index should always be valid here. We validate it on entry into wined3d, and internally we should always pass valid indices. > + if (sub_resource->locations & (WINED3D_LOCATION_DRAWABLE | WINED3D_LOCATION_TEXTURE_RGB)) > + return; Perhaps more importantly, this check should be unnecessary for surface_cpu_blt(), since we always invalidate ~map_binding. > + if (box) SetRect(&texture->swapchain->front_buffer_update, box->left, box->top, box->right, box->bottom); And with this line effectively being only used for surface_cpu_blt(), I'm not sure the swapchain_frontbuffer_updated() helper is really worth it.

1 0

Detect whether wineserver is fully started? Signal? File?
by Sebastian M. Ernst 18 Jun '17

18 Jun '17

Dear Wine developers, I am working on a little Python module which is supposed to make use of Wine. The module has a dedicated class for managing its own wineserver-session with its own prefix. It allows me to control wineserver independently of the lifetime of any Windows executable I run on top of it and to quit it when my work is done. Starting and stopping wineserver is no problem. However, what I can not figure out is how to determine when my wineserver is actually completely loaded, up and running. After all, the loading process requires quite a bit of time. Mainly due to my intention of preventing any (hard to debug) crashes and delays when running Windows executables, I want wineserver to be fully up & loaded before I run anything on top of it. The following code snipped illustrates the problem: os.environ['WINEPREFIX'] = '/some/path' proc_wineserver = subprocess.Popen( ['wineserver', '-f', '-p'], # run persistent in foreground stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE, shell = False ) time.sleep(1) # Placeholder *HACK*. BETTER SOLUTION? proc_somewinexe = subprocess.Popen(['wine some.exe'], shell = False) As a temporary hack, for which I am seeking a replacement, I simply sleep for one second. This is odd on faster PCs and really not enough on somewhat older hardware (or with slow harddrives instead of SSDs) ... Is there a signal I can catch or a file I can check (and wait for in a loop to appear) or anything else which would allow me a clean(er) solution? Or, alternatively, where in the Wine source code do I have to look for how the "wine" command does it (?) - looking for wineserver and firing one up if there is not one before any exe file is executed? I recently posted a question in the Wine forum with similar content: https://forum.winehq.org/viewtopic.php?f=2&t=28967 Thanks for any advise, Sebastian

3 6

[PATCH] gdiplus: Implement triangular line caps in widened paths.
by Clemens Tamme 17 Jun '17

17 Jun '17

Pens in GDI+ have a startcap an an endcap property. Previously, values LineCapFlat, LineCapSquare and LineCapRound were supported, now LineCapTriangle is added. This solves two FIXMEs in GdipWidenPath: unimplemented end cap 3 and unimplemented start cap 3 (3 being the value of LineCapTriangle). Test dlls/gdiplus/test/graphicspath.c runs on Ubuntu 16.04. Signed-off-by: Clemens Tamme <clemens.tamme(a)gmail.com> --- dlls/gdiplus/graphicspath.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/dlls/gdiplus/graphicspath.c b/dlls/gdiplus/graphicspath.c index 3d33c29..e34f4ed 100644 --- a/dlls/gdiplus/graphicspath.c +++ b/dlls/gdiplus/graphicspath.c @@ -1883,6 +1883,27 @@ static void widen_cap(const GpPointF *endpoint, const GpPointF *nextpoint, } break; } + case LineCapTriangle: + { + REAL segment_dy = nextpoint->Y-endpoint->Y; + REAL segment_dx = nextpoint->X-endpoint->X; + REAL segment_length = sqrtf(segment_dy*segment_dy + segment_dx*segment_dx); + REAL distance = pen->width/2.0; + REAL dx, dy; + + dx = distance * segment_dx / segment_length; + dy = distance * segment_dy / segment_length; + + if (add_first_points) { + add_bevel_point(endpoint, nextpoint, pen, 1, last_point); + + *last_point = add_path_list_node(*last_point, endpoint->X - dx, + endpoint->Y - dy, PathPointTypeLine); + } + if (add_last_point) + add_bevel_point(endpoint, nextpoint, pen, 0, last_point); + break; + } } } @@ -2118,10 +2139,10 @@ GpStatus WINGDIPAPI GdipWidenPath(GpPath *path, GpPen *pen, GpMatrix *matrix, { last_point = points; - if (pen->endcap > LineCapRound) + if (pen->endcap > LineCapTriangle) FIXME("unimplemented end cap %x\n", pen->endcap); - if (pen->startcap > LineCapRound) + if (pen->startcap > LineCapTriangle) FIXME("unimplemented start cap %x\n", pen->startcap); if (pen->dashcap != DashCapFlat) -- 2.7.4

1 0

Installation of up-to-date wine-staging
by Alan W. Irwin 17 Jun '17

17 Jun '17

I followed the directions at <https://wine-staging.com/installation.html> to install wine-staging on my Debian Jessie platform. However, the result is considerably out of date (version 2.4 rather than 2.9 (or 2.10)), and there appears to be no method of determining what version of wine-staging is available for each of the other Linux platforms mentioned on that web page such as Debian testing = stretch. Is this lack of an up-to-date version some idiosyncrasy for the Debian Jessie platform or is this a problem for all the Linux distributions covered in the above web page? Are there plans to start keeping wine-staging installs more up to date for Debian Jessie or is there some other set of directions I should be following to gain access to the latest version of wine-staging? It's been a number of years since I have built wine, and in that era I only bothered with the 32-bit version. So if it turns out the answer is there are no plans to keep the various distro versions of wine-staging up to date so the only way to get an up-to-date version is to build a WoW64 version of the latest wine that has been patched with the wine-staging patches, it would be good to state that in the above page. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

2 3

Approach to debugging wine issues
by Fabian Maurer 16 Jun '17

16 Jun '17

Hello Wine Devs, I'm currently trying to investigate an crash with an old game called KnightOfKnights (See Bug 43180). I already know which dll is responsible for the crash, and the native dll fixes it. The crash appears in native code of the game though. Now my approach would be to open the program with a debugger (x64dbg works nice under wine) and then step through the program, finding where the null- pointer comes from until I reach the wine function that returned something wrong. After all, I can compare the control flow using the native d3dxof dll and the builtin d3dxof dll to see where the game gets the value(s) that lead to crash, the goal here would be to find one or more functions from d3dxof that return a different value, like a nullpointer. Then I could begin hacking wine code to find out why it returns something wrong and try to fix that, without looking at the native code of course. Now my question, is this an accepted solution to fixing bugs? I read in the wiki that disassembling a program to diagnose bugs is discouraged due to legal issues and difficulty, though I don't really see another way to track it down. Any insights from you guys and girls who are used to fixing bugs? Just figured I should ask, before I try to create a solution by ways you won't accept. Regards, Fabian Maurer

3 3

Re: widl: Try to append .tlb extension to importib file name if it can't be found without it.
by Alexandre Julliard 16 Jun '17

16 Jun '17

Jacek Caban <jacek(a)codeweavers.com> writes: > That's for cases like importlib("oleacc.dll"). MIDL can import them from > system DLLs, but for widl, we currently need oleacc.dll file in include > directory. Since it is at least confusing to have a file named > oleacc.dll between includes, this patch allows providing oleacc.dll.tlb > file instead. I'm not sure what you want to do here. Do you want to put a plain typelib file in includes, but name it .dll.tlb? Or do you need an actual dll? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [v2 PATCH] include/wincodec.idl: Stop redefinition of ID2D1Image
by Vincent Povirk 16 Jun '17

16 Jun '17

Why can't we handle this the way that d2d1.idl does? It doesn't include wincodec.idl, but it declares the interfaces it uses from there. I know the Windows SDK doesn't do that, but that's probably because the SDK headers are weird and don't declare the d2d1 interfaces in an idl.

3 2

Re: [PATCH] oledb32: Support DBTYPE_I4->DBTYPE_WSTR in GetConversionSize
by Huw Davies 16 Jun '17

16 Jun '17

On Tue, Jun 13, 2017 at 04:09:54AM +0000, Alistair Leslie-Hughes wrote: > dst_len cannot be set to 110 beacuse we don't have any idea of how this > value is set. In this case we really do want to set something, and if it's 110 on Windows then we may as well use that. The previous case was to do with a NULL-variant, where DataConvert() didn't actually return any data. This time it will, so we should give the app a chance to allocate a big enough buffer. It would also be worth handling and testing more cases than the conversion to DBTYPE_I4. Perhaps we should set *dst_len to 110 if get_length() returns 0 and then let the special cases overrride it. Huw. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 5 +++++ > dlls/oledb32/tests/convert.c | 12 ++++++++++++ > 2 files changed, 17 insertions(+) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index 0d45ef0..bf01101 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -1401,6 +1401,11 @@ static HRESULT WINAPI convert_GetConversionSize(IDataConvert* iface, > case DBTYPE_WSTR: > switch (src_type) > { > + case DBTYPE_I4: > + { > + /* Return S_OK to signal we can convert from this type. On windows, dst_len is set to 110. */ > + break; > + } > case DBTYPE_VARIANT: > { > VARIANT v; > diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c > index 116ca16..d07ebf1 100644 > --- a/dlls/oledb32/tests/convert.c > +++ b/dlls/oledb32/tests/convert.c > @@ -2715,6 +2715,7 @@ static void test_getconversionsize(void) > VARIANT var; > SAFEARRAY *psa = NULL; > SAFEARRAYBOUND rgsabound[1]; > + int i4; > > /* same way as CanConvert fails here */ > dst_len = 0; > @@ -2834,6 +2835,17 @@ static void test_getconversionsize(void) > ok(dst_len == 1802, "%ld\n", dst_len); > VariantClear(&var); > > + /* A value of 110 is returned in dst_len */ > + dst_len = 0; > + src_len = sizeof(i4); > + i4 = 200; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_I4, DBTYPE_WSTR, &src_len, &dst_len, &i4); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + dst_len = 0; > + hr = IDataConvert_GetConversionSize(convert, DBTYPE_I4, DBTYPE_WSTR, NULL, &dst_len, NULL); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > /* On Windows, NULL variants being convert to a non-fixed sized type will return a dst_len of > * 110 but we aren't testing for this value. > */ > -- > 1.9.1 > > >

1 0

Re: [PATCH 7/7] mshtml/tests: Added IHTMLInputTextElement2 tests.
by Marvin 15 Jun '17

15 Jun '17

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=31658 Your paranoid android. === wxppro (32 bit dom) === dom.c:8303: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002 dom.c:8358: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002 dom.c:9143: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002 === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5092: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 2/7] mshtml: Added IHTMLInputTextElement2 stub implementation.
by Marvin 15 Jun '17

15 Jun '17

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=31657 Your paranoid android. === wxppro (32 bit dom) === dom.c:8303: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002 dom.c:8358: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002 dom.c:9143: Test failed: Could not get {3050f2d2-98b5-11cf-bb82-00aa00bdce0b} interface: 80004002

1 0

Re: [v2 4/7] d3dx9: Add scalar and vector setting path to set_constants().
by Matteo Bruni 14 Jun '17

14 Jun '17

2017-06-12 13:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/preshader.c | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c > index 2f9648d..1ca02c4 100644 > --- a/dlls/d3dx9_36/preshader.c > +++ b/dlls/d3dx9_36/preshader.c > @@ -1101,6 +1101,12 @@ static void regstore_set_data(struct d3dx_regstore *rs, unsigned int table, > }; > enum pres_value_type table_type = table_info[table].type; > > + if (param_type == table_type) > + { > + regstore_set_values(rs, table, in, offset, count); > + return; > + } Maybe it's a bit paranoid but I'd like an assert in regstore_set_values() ensuring that there is no overlap between destination and source of the memcpy(). That's clearly the case at the moment but it might become less obvious in the future.

2 2

Re: [PATCH v2] msacm32: Rewrite PCM conversion functions.
by Andrew Eikum 14 Jun '17

14 Jun '17

On Tue, Jun 13, 2017 at 04:35:52PM -0500, Zebediah Figura wrote: > +#define PCM_CVT_CHANGE_FUNC(name) static void name(DWORD srcRate, const unsigned char *src, DWORD *nsrc, \ > + DWORD dstRate, unsigned char *dst, DWORD *ndst) \ > + { \ > + DWORD error = srcRate / 2; \ > + DWORD srcUsed = 0, dstUsed = 0; \ > + for (srcUsed = 0; srcUsed < *nsrc; srcUsed++) { \ > + error += dstRate; \ > + while (error > srcRate) { \ > + if (dstUsed == *ndst) { \ > + *nsrc = srcUsed; \ > + *ndst = dstUsed; \ > + return; \ > + } > + > + /* conversion is done here */ > + > +#define PCM_CVT_CHANGE_FUNC_END(offset) \ > + dstUsed++; \ > + error -= srcRate; \ > + } \ > + src += offset; \ > + } \ > + *nsrc = srcUsed; \ > + *ndst = dstUsed; \ > +} > + > +PCM_CVT_CHANGE_FUNC(cvtSS88C) > + *dst++ = src[0]; > + *dst++ = src[1]; > +PCM_CVT_CHANGE_FUNC_END(2) > + I really dislike complicated preprocessor tricks. Can't this be done in a similar way with real functions? If not, I'd rather have the copy-pasted code than these difficult macros. Andrew

4 6

Re: [PATCH] include/wincodec.idl: Stop redefinition of ID2D1Image
by Sebastian Lackner 14 Jun '17

14 Jun '17

On 14.06.2017 13:54, Alistair Leslie-Hughes wrote: > Fixes: https://bugs.winehq.org/show_bug.cgi?id=43175 > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > include/wincodec.idl | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/wincodec.idl b/include/wincodec.idl > index 1ea6e0e203..bdc2031ac3 100644 > --- a/include/wincodec.idl > +++ b/include/wincodec.idl > @@ -224,7 +224,9 @@ typedef DWORD *D2D1_PIXEL_FORMAT; > cpp_quote ("#endif") > > cpp_quote ("typedef interface ID2D1Device ID2D1Device;") > +cpp_quote ("#ifndef __ID2D1Image_FWD_DEFINED__") > cpp_quote ("typedef interface ID2D1Image ID2D1Image;") > +cpp_quote ("#endif") > > typedef struct WICRect { > INT X; > And what if the include files are used in the opposite order? You don't define __ID2D1Image_FWD_DEFINED__, so the bug will reappear. Best regards, Sebastian

2 1

Re: [5/6] webservices: Implement WsReadXmlBuffer.
by Marvin 14 Jun '17

14 Jun '17

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=31634 Your paranoid android. === w7u (32 bit reader) === reader.c:5208: Test failed: got 487 === w7pro64 (32 bit reader) === reader.c:5208: Test failed: got 487 === w8 (32 bit reader) === reader.c:5208: Test failed: got 487 === w864 (32 bit reader) === reader.c:5208: Test failed: got 487 === w7pro64 (64 bit reader) === reader.c:5208: Test failed: got 487 === w864 (64 bit reader) === reader.c:5208: Test failed: got 487

1 0

Re: [1/6] webservices: Add a static builtin dictionary.
by Marvin 14 Jun '17

14 Jun '17

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=31632 Your paranoid android. === w7u (32 bit reader) === reader.c:5208: Test failed: got 487 === w7pro64 (32 bit reader) === reader.c:5208: Test failed: got 487 === w8 (32 bit reader) === reader.c:5208: Test failed: got 487 === w864 (32 bit reader) === reader.c:5208: Test failed: got 487 === w7pro64 (64 bit reader) === reader.c:5208: Test failed: got 487 === w864 (64 bit reader) === reader.c:5208: Test failed: got 487

1 0

Re: [v2 6/7] d3dx9: Get rid of constant's length checking for matrix in set_constants().
by Matteo Bruni 14 Jun '17

14 Jun '17

2017-06-12 13:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > When count in const_upload_info is calculated precisely (considering actual > constant set length), boolean matrix setting always fall in direct copy path. > The test has both row_major and column_major qualified boolean matrices, but > the qualifier is ignored by compiler. Is it? The effect parameter is always row major, but it looks like the constant is actually affected (and you're handling that correctly AFAICS). > If change the type of matrix to int, > the matrix goes to float constants and not to bool constants. So it looks like > the case of incomplete last row for matrix should now never happen. Right, and the FIXME you're adding in this patch should trigger if any of those assumptions turns out to be invalid. Looks good.

1 0

Re: [v2 3/7] d3dx9: Avoid casting each value separately in set_constants().
by Matteo Bruni 13 Jun '17

13 Jun '17

2017-06-12 13:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void pres_float_to_int(const void *in, void *out, unsigned int count) Something I forgot earlier and maybe it's bikeshedding, but anyway: could you flip those functions around like e.g. pres_int_from_float()? The "out" argument should also be swapped with "in". Patch looks good otherwise.

1 0

Re: [PATCH 3/6] server: Implement changing the label of a security descriptor.
by Alexandre Julliard 13 Jun '17

13 Jun '17

Matteo Bruni <mbruni(a)codeweavers.com> writes: > From: Michael Müller <michael(a)fds-team.de> > > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > dlls/advapi32/tests/security.c | 153 ++++++++++++++++++++++++++++++++++++++++- > dlls/ntdll/sec.c | 3 +- > server/handle.c | 130 +++++++++++++++++++++++++++++++++- > 3 files changed, 282 insertions(+), 4 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p advapi32_test.exe.so security && touch security.ok security.c:2065: Tests skipped: Well known SID 38 not implemented security.c:2065: Tests skipped: Well known SID 39 not implemented security.c:2065: Tests skipped: Well known SID 40 not implemented security.c:2065: Tests skipped: Well known SID 41 not implemented security.c:2065: Tests skipped: Well known SID 42 not implemented security.c:2065: Tests skipped: Well known SID 43 not implemented security.c:2065: Tests skipped: Well known SID 44 not implemented security.c:2065: Tests skipped: Well known SID 45 not implemented security.c:2065: Tests skipped: Well known SID 46 not implemented security.c:2065: Tests skipped: Well known SID 47 not implemented security.c:2065: Tests skipped: Well known SID 48 not implemented security.c:2065: Tests skipped: Well known SID 49 not implemented security.c:2065: Tests skipped: Well known SID 50 not implemented security.c:2065: Tests skipped: Well known SID 62 not implemented security.c:2065: Tests skipped: Well known SID 63 not implemented security.c:2065: Tests skipped: Well known SID 64 not implemented security.c:2065: Tests skipped: Well known SID 65 not implemented security.c:2065: Tests skipped: Well known SID 70 not implemented security.c:2065: Tests skipped: Well known SID 71 not implemented security.c:2065: Tests skipped: Well known SID 72 not implemented security.c:2065: Tests skipped: Well known SID 73 not implemented security.c:2065: Tests skipped: Well known SID 74 not implemented security.c:2065: Tests skipped: Well known SID 75 not implemented security.c:2065: Tests skipped: Well known SID 76 not implemented security.c:2065: Tests skipped: Well known SID 77 not implemented security.c:2065: Tests skipped: Well known SID 78 not implemented security.c:2065: Tests skipped: Well known SID 79 not implemented security.c:2065: Tests skipped: Well known SID 81 not implemented security.c:2065: Tests skipped: Well known SID 82 not implemented wine: Unhandled page fault on read access to 0x00000004 at address 0x7ed5a0bf (thread 0047), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x7ed5a0bf). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ed5a0bf ESP:0033f9ac EBP:0033fb88 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:7ed83000 ECX:0000001f EDX:00000400 ESI:00133838 EDI:7ed73e9f Stack dump: 0x0033f9ac: 0000007a 00000000 00000000 7ed79a04 0x0033f9bc: 7ed74d52 7ed7996c 7ed79918 0033fa44 0x0033f9cc: 00000001 7ed79940 00000001 7ed84b58 0x0033f9dc: 7ed79994 7ed798e8 001336e0 7ed74cc0 0x0033f9ec: 7ed74cb2 7ed74ca0 0033fa40 0033fa30 0x0033f9fc: 0033fa2c 7ed7980c 7ed797dc 7ed79a90 Backtrace: =>0 0x7ed5a0bf test_AddMandatoryAce+0xf9f() [/home/julliard/wine/wine/dlls/advapi32/tests/security.c:6348] in advapi32_test (0x0033fb88) 1 0x7ed625fa func_security+0x24a9() [/home/julliard/wine/wine/dlls/advapi32/tests/security.c:6764] in advapi32_test (0x0033fd48) 2 0x7ed2596d main+0x25c(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/advapi32/tests/../../../include/wine/test.h:589] in advapi32_test (0x0033fdf8) 3 0x7ed6df9b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in advapi32_test (0x0033fe38) 4 0x7b45e79c call_process_entry+0xb() in kernel32 (0x0033fe58) 5 0x7b45f6d9 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fe98) 6 0x7bc7f23c call_thread_func_wrapper+0xb() in ntdll (0x0033feb8) 7 0x7bc81ff9 call_thread_func+0xa8(entry=0x7b45f670, arg=0x7ed6df50, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0033ffa8) 8 0x7bc7f21a call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 9 0x7bc54023 start_process+0x12(arg=0xff871728) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3083] in ntdll (0x0033ffe8) 10 0xf75938cd __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 11 0xf7593a30 wine_switch_to_stack+0x1f(func=0x7bc54010, arg=0xff871728, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xff8716f8) 12 0x7bc59cde LdrInitializeThunk+0x22d(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3144] in ntdll (0xff871748) 13 0x7b46563f __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xff872638) 14 0x7bc5ab33 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3353] in ntdll (0xff8726a8) 15 0xf7591b33 wine_init+0x2a2(argc=0x3, argv=0xff872bf4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:974] in libwine.so.1 (0xff8726f8) 16 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:258] in <wine-loader> (0xff872b48) 17 0xf739b276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7ed5a0bf test_AddMandatoryAce+0xf9f [/home/julliard/wine/wine/dlls/advapi32/tests/security.c:6348] in advapi32_test: movzwl 0x4(%eax),%edx 6348 ok(!sacl->AceCount, "SACL contains an unexpected ACE count %u\n", sacl->AceCount); -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH v2] msacm32: Rewrite PCM conversion functions.
by Marvin 13 Jun '17

13 Jun '17

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=31625 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [2/2] ntdll: Add support for relay debugging on ARM64
by Alexandre Julliard 13 Jun '17

13 Jun '17

André Hentschel <nerv(a)dawncrow.de> writes: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/ntdll/relay.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 62 insertions(+), 3 deletions(-) It doesn't build with clang: aarch64-linux-android-clang -c -o relay.o ../../../wine/dlls/ntdll/relay.c -I. -I../../../wine/dlls/ntdll -I../../include -I../../../wine/include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -g -O2 <inline asm>:35:2: error: too few operands for instruction Makefile:561: recipe for target 'relay.o' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel