June 2017 - Wine-devel - list.winehq.org

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 17 Jun '17

17 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 16 Jun '17

16 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