July 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2 v2] reg: Account for sizeof(WCHAR) when resizing the value name buffer during the query operation
by Alexandre Julliard July 21, 2017

July 21, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Changes since v1: > - Handle HeapReAlloc() failure This is a stand-alone app, so adding a couple of helpers that die on allocation failure would probably be a better choice than checking everywhere. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] mshtml: Added IHTMLDOMNode3::put_textContent implementation.
by Marvin July 21, 2017

July 21, 2017

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=32419 Your paranoid android. === 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 1/2] xmllite/reader: Implement MoveToAttributeByName()
by Marvin July 21, 2017

July 21, 2017

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=32415 Your paranoid android. === wxppro (32 bit reader) === reader.c:2597: Test failed: Unexpected hr 0x1. === w2003std (32 bit reader) === reader.c:2597: Test failed: Unexpected hr 0x1.

1 0

Re: [PATCH 2/8] d3d11: Fix race condition in d3d_blend_state_create().
by Henri Verbeet July 21, 2017

July 21, 2017

On 20 July 2017 at 14:10, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Arguably we could use a different mutex for "device->blend_states". > Yeah. Generally speaking we'd like wined3d locking to be more fine-grained, but there are probably a bunch of issues with that.

1 0

Re: [PATCH] reg: Account for sizeof(WCHAR) when resizing the value name buffer during the query operation
by Henri Verbeet July 21, 2017

July 21, 2017

On 21 July 2017 at 10:47, Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > - value_name = HeapReAlloc(GetProcessHeap(), 0, value_name, max_value_len); > + value_name = HeapReAlloc(GetProcessHeap(), 0, value_name, max_value_len * sizeof(WCHAR)); Note that this leaks the existing "value_name" allocation if the HeapReAlloc() call should fail.

1 0

Re: [PATCH 3/6] msi: Don't set _BrowseProperty.
by Zebediah Figura July 20, 2017

July 20, 2017

On 07/20/2017 11:43 PM, Zebediah Figura wrote: > This is a revert of 166a7e993cb0033fac7ec2712c346558fb7bd100, > which was introduced to fix bug #28219. _BrowseProperty is not set > by Windows, but should rather be set by the program in question, and > was not being set due to a bug in Wine, fixed by the previous patch. Sorry, typo—meant to say next patch (4/6).

1 0

Re: [PATCH 2/2] mshtml: Added IHTMLDOMNode3::get_textContent implementation.
by Marvin July 20, 2017

July 20, 2017

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=32404 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath === w864 (64 bit events) === events.c:987: Test failed: unexpected call img_onerror

1 0

Re: [v3] gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 20, 2017

July 20, 2017

On Thu, Jul 20, 2017 at 10:56:40PM +0900, Akihiro Sagawa wrote: > > To avoid division by zero (Bug 43369). > > In version 3, refine a testcase. > The refresh rate value is neither zero nor negative, thus we should test both. > Thanks for reviewing. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/gdi32/driver.c | 2 +- > dlls/gdi32/tests/dc.c | 8 ++++++++ > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index fe7812c..6a3975a 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -344,7 +344,7 @@ static INT nulldrv_GetDeviceCaps( PHYSDEV dev, INT cap ) > case PHYSICALOFFSETY: return 0; > case SCALINGFACTORX: return 0; > case SCALINGFACTORY: return 0; > - case VREFRESH: return 0; > + case VREFRESH: return GetDeviceCaps( dev->hdc, TECHNOLOGY ) == DT_RASDISPLAY ? 1 : 0; > case DESKTOPVERTRES: return GetDeviceCaps( dev->hdc, VERTRES ); > case DESKTOPHORZRES: return GetDeviceCaps( dev->hdc, HORZRES ); > case BLTALIGNMENT: return 0; > diff --git a/dlls/gdi32/tests/dc.c b/dlls/gdi32/tests/dc.c > index add2c04..d316f3f 100644 > --- a/dlls/gdi32/tests/dc.c > +++ b/dlls/gdi32/tests/dc.c > @@ -388,6 +388,7 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > { > INT precision = 0; > INT hdc_caps = GetDeviceCaps( hdc, caps[i] ); > + INT ref_caps; > > switch (caps[i]) > { > @@ -400,6 +401,13 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > case LOGPIXELSY: > hdc_caps *= scale; > break; > + case VREFRESH: > + ref_caps = GetDeviceCaps( ref_dc, caps[i] ); > + if (GetDeviceCaps( ref_dc, TECHNOLOGY ) == DT_RASDISPLAY) > + ok( ref_caps > 0, "expected a positive value on %s, got %d\n", descr, ref_caps ); > + else > + ok( ref_caps == 0, "expected 0 on %s, got %d\n", descr, ref_caps ); > + break; > } You don't want to use 'ref_dc' here, use 'hdc' instead. Also, note that 'hdc_caps' already contains the thing you want to test, so you don't need the first call to GetDeviceCaps(). Huw.

1 0

Re: [PATCH] widl: Handle C++ aggregate returns in a MSVC compatible way.
by Jacek Caban July 20, 2017

July 20, 2017

Hi Henri, On 20.07.2017 14:18, Henri Verbeet wrote: > This mainly affects 64-bit winelib applications, and potentially mingw-w64 > usage of the Wine headers. As explained in commit > fabfa59aea5c5b3201142382038beb3e76cb7567, MSVC returns aggregates through an > implicit parameter immediately after the this/interface pointer. GCC's > "ms_abi" attribute is supposed to match this, but unfortunately current > versions of g++ (confirmed up to at least g++ 6.3) place the implicit return > pointer before the this/interface pointer. See also > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792. FWIW, here is a bug about 32-bit problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 > This commit takes an approach similar to the earlier commit > fabfa59aea5c5b3201142382038beb3e76cb7567: For ABI compatibility the return > pointer is listed as an explicit parameter in the vtbl entry, while an inline > helper is provided for source code compatibility. While it fixes the problem for C++ callers, it breaks building classes implementing those interfaces. Implementation will try to override inline function instead of virtual one. Given that the workaround has bad side effects, I'd say that we should at least try harder to not use it. For example it could be #ifdefed to not be used by compilers doing the right thing. With that, using our headers would require modifications in compiled code compatible with MSVC, so there would be a point in having a nice to use macro that interface implementations could use to decide if they should apply needed changes. Obviously fixing compilers sounds much better. Jacek

2 3

Re: [PATCH] gdi32: Update enhanced metafile world transform immediately in winnt mode
by Huw Davies July 20, 2017

July 20, 2017

On Wed, Jul 19, 2017 at 02:06:29PM -0500, Andrew Eikum wrote: > /***************************************************************************** > * PlayEnhMetaFileRecord (GDI32.@) > @@ -1443,14 +1458,20 @@ BOOL WINAPI PlayEnhMetaFileRecord( > info->state.world_transform.eM11 = info->state.world_transform.eM22 = 1; > info->state.world_transform.eM12 = info->state.world_transform.eM21 = 0; > info->state.world_transform.eDx = info->state.world_transform.eDy = 0; > + if (!IS_WIN9X()) > + EMF_Update_MF_Xform(hdc, info); > break; > case MWT_LEFTMULTIPLY: > CombineTransform(&info->state.world_transform, &lpModifyWorldTrans->xform, > &info->state.world_transform); > + if (!IS_WIN9X()) > + ModifyWorldTransform(hdc, &lpModifyWorldTrans->xform, MWT_LEFTMULTIPLY); > break; > case MWT_RIGHTMULTIPLY: > CombineTransform(&info->state.world_transform, &info->state.world_transform, > &lpModifyWorldTrans->xform); > + if (!IS_WIN9X()) > + EMF_Update_MF_Xform(hdc, info); > break; > default: > FIXME("Unknown imode %d\n", lpModifyWorldTrans->iMode); > @@ -2216,6 +2237,13 @@ BOOL WINAPI PlayEnhMetaFileRecord( > LPtoDP(hdc, (POINT*)&tmprc, 2); > TRACE("L:0,0 - 1000,1000 -> D:%s\n", wine_dbgstr_rect(&tmprc)); > > + if (emr_modifies_transform( mr->iType ) && !IS_WIN9X()) > + { > + /* WinNT - update the transform (win9x updates when the next graphics > + output record is played). */ > + EMF_Update_MF_Xform(hdc, info); > + } > + > return TRUE; > } > I think it would be better to call EMF_Update_MF_Xform() in each 'case' block that needs it, just like you are doing for EMR_MODIFYWORLDTRANSFORM. Also, what about EMR_SETMAPMODE? > diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c > index eeec79c800..eaad666361 100644 > --- a/dlls/gdi32/tests/metafile.c > +++ b/dlls/gdi32/tests/metafile.c [snip] > START_TEST(metafile) > { > init_function_pointers(); > @@ -3928,6 +4430,9 @@ START_TEST(metafile) > test_emf_paths(); > test_emf_PolyPolyline(); > test_emf_GradientFill(); > + test_emf_WorldTransform_simple(); > + test_emf_WorldTransform_modify(); > + test_emf_WorldTransform_modified_playback(); > You have a lot of duplicated code here. It should be possible to have a single test_emf_WorldTransform() that uses a table to drive these three tests. Could you also make the matrices a little more interesting? Adding a translation would make them non-commuting which would be good to test. Huw.

1 0

Re: [PATCH 3/3] mshtml: Expose IHTMLDOMNode3 interface to scripts.
by Marvin July 19, 2017

July 19, 2017

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=32387 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [v2] gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 19, 2017

July 19, 2017

On Wed, Jul 19, 2017 at 11:28:58PM +0900, Akihiro Sagawa wrote: > diff --git a/dlls/gdi32/tests/dc.c b/dlls/gdi32/tests/dc.c > index add2c04..2b48542 100644 > --- a/dlls/gdi32/tests/dc.c > +++ b/dlls/gdi32/tests/dc.c > @@ -445,6 +445,7 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > if (type != COMPLEXREGION && type != ERROR) /* region can be complex on multi-monitor setups */ > { > RECT ref_rect; > + int rate = GetDeviceCaps( ref_dc, VREFRESH ); > > ok( type == SIMPLEREGION, "GetClipBox returned %d on %s\n", type, descr ); > if (GetDeviceCaps( ref_dc, TECHNOLOGY ) == DT_RASDISPLAY) > @@ -462,11 +463,15 @@ static void test_device_caps( HDC hdc, HDC ref_dc, const char *descr, int scale > SetRect( &ref_rect, GetSystemMetrics( SM_XVIRTUALSCREEN ), GetSystemMetrics( SM_YVIRTUALSCREEN ), > GetSystemMetrics( SM_XVIRTUALSCREEN ) + GetSystemMetrics( SM_CXVIRTUALSCREEN ), > GetSystemMetrics( SM_YVIRTUALSCREEN ) + GetSystemMetrics( SM_CYVIRTUALSCREEN ) ); > + > + ok( rate >= 1 && rate <= 85, "returned rate is out of range (1 -- 85), got %d\n", rate); Don't check the range, just that it's != 0. Also, please move this to a new VREFRESH case in the switch block higher up in this function. Huw.

1 0

Re: winhttp: Rename host_t to hostdata_t.
by Henri Verbeet July 19, 2017

July 19, 2017

On 19 July 2017 at 17:22, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Commit fa2cc9868b7db7a4cbf7d01a48500cb3f31e109a broke the compilation macOS > because host_t conflicts with a system header file: > > [19:31:41] In file included from ../../../wine/dlls/winhttp/session.c:50: > [19:31:41] ../../../wine/dlls/winhttp/winhttp_private.h:106:3: error: typedef redefinition with different types ('struct host_t' vs 'mach_port_t' (aka 'unsigned int')) > [19:31:41] } host_t; > [19:31:41] ^ > [19:31:41] /build/macos-rootfs/usr/include/mach/mach_types.h:120:22: note: previous definition is here > [19:31:41] typedef mach_port_t host_t; > [19:31:41] ^ > It may be too late for winhttp or Wine in general (although Michael does love these kinds of things), but note that the _t suffix is reserved by POSIX and should in principle be avoided on POSIX systems.

1 0

Re: gdi32: return non-zero v-refresh value for display devices.
by Huw Davies July 19, 2017

July 19, 2017

On Wed, Jul 19, 2017 at 12:11:28AM +0900, Akihiro Sagawa wrote: > > To avoid division by zero (Bug 43369). > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/gdi32/driver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index fe7812c..6a3975a 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -344,7 +344,7 @@ static INT nulldrv_GetDeviceCaps( PHYSDEV dev, INT cap ) > case PHYSICALOFFSETY: return 0; > case SCALINGFACTORX: return 0; > case SCALINGFACTORY: return 0; > - case VREFRESH: return 0; > + case VREFRESH: return GetDeviceCaps( dev->hdc, TECHNOLOGY ) == DT_RASDISPLAY ? 1 : 0; > case DESKTOPVERTRES: return GetDeviceCaps( dev->hdc, VERTRES ); > case DESKTOPHORZRES: return GetDeviceCaps( dev->hdc, HORZRES ); > case BLTALIGNMENT: return 0; Could you add a test (probably in dc.c:test_device_caps())? The values returned by the testbot range from 1 -- 85, so 1 is as good a choice as any. Huw.

2 2

Re: [v2 3/5] d3dx9: Support skip_constants parameter for effect.
by Matteo Bruni July 18, 2017

July 18, 2017

2017-07-11 13:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -6397,24 +6464,75 @@ static HRESULT d3dx9_base_effect_init(struct d3dx9_base_effect *base, > TRACE("Tag: %x\n", tag); > } > > + if (skip_constants_string) > + { > + skip_constants_buffer = HeapAlloc(GetProcessHeap(), 0, > + sizeof(*skip_constants_buffer) * (strlen(skip_constants_string) + 1)); I think you can get rid of the sizeof() in this case. If sizeof(*skip_constants_buffer) is not 1 we have bigger problems anyway... > + if (!skip_constants_buffer) > + { > + if (bytecode) > + ID3D10Blob_Release(bytecode); > + return E_OUTOFMEMORY; > + } > + strcpy(skip_constants_buffer, skip_constants_string); Ideally this one should be a memcpy(), reusing the string length computed above. > @@ -588,7 +588,8 @@ static unsigned int *parse_pres_ins(unsigned int *ptr, unsigned int count, struc > return ptr; > } > > -static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D3DXCONSTANT_DESC *desc) > +static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D3DXCONSTANT_DESC *desc, > + WORD *constantinfo_reserved) > { > const struct ctab_constant *constant = d3dx_shader_get_ctab_constant(ctab, hc); > > @@ -598,10 +599,13 @@ static HRESULT get_ctab_constant_desc(ID3DXConstantTable *ctab, D3DXHANDLE hc, D > return D3DERR_INVALIDCALL; > } > *desc = constant->desc; > + if (constantinfo_reserved) > + *constantinfo_reserved = constant->constantinfo_reserved; > return D3D_OK; > } For future reference: these (and related) changes should probably have been in a separate patch, or even part of the previous patch in the series. Also, as it becomes more obvious here, one could go one step further with this and directly return struct ctab_constant to the caller. That would essentially make the get_ctab_constant_desc() helper redundant so it could be merged into the callers and removed entirely. > + for (j = 0; j < skip_constants_count; ++j) > + { > + if (!strcmp(cdesc[index].Name, skip_constants[j])) > + { > + if (!constantinfo_reserved) > + { > + WARN("skip_constants parameter %s is not register bound.\n", > + cdesc[index].Name); > + hr = D3DERR_INVALIDCALL; > + goto cleanup; > + } > + TRACE("Skipping constant %s.\n", cdesc[index].Name); > + break; > + } > + } > + if (j < skip_constants_count) > + continue; > + ++out->input_count; > + if (inputs_param[index]->class == D3DXPC_OBJECT) > + continue; > + if (FAILED(hr = init_set_constants_param(out, ctab, hc, inputs_param[index]))) > + goto cleanup; > } > - out->input_count = desc.Constants; > if (out->const_set_count) > { > out->const_set = HeapReAlloc(GetProcessHeap(), 0, out->const_set, Not particularly important but we could shrink out->inputs and out->inputs_param to out->input_count if any parameter was skipped.

1 0

Re: [PATCH 7/7] d3dx9: Support skip_constants parameter for effect.
by Matteo Bruni July 18, 2017

July 18, 2017

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 July 18, 2017

July 18, 2017

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 July 18, 2017

July 18, 2017

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 July 18, 2017

July 18, 2017

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 July 18, 2017

July 18, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 17, 2017

July 17, 2017

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 July 15, 2017

July 15, 2017

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 July 14, 2017

July 14, 2017

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 July 14, 2017

July 14, 2017

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 July 14, 2017

July 14, 2017

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 July 14, 2017

July 14, 2017

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 July 14, 2017

July 14, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 13, 2017

July 13, 2017

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 July 12, 2017

July 12, 2017

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 July 12, 2017

July 12, 2017

/********************************************************************* + * 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 July 12, 2017

July 12, 2017

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 July 12, 2017

July 12, 2017

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 July 11, 2017

July 11, 2017

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 July 11, 2017

July 11, 2017

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 July 11, 2017

July 11, 2017

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 July 11, 2017

July 11, 2017

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 July 11, 2017

July 11, 2017

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