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

Re: [PATCH 1/4] riched20: Support ITextFont instances detached from a range

by Marvin

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=13589 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wxppro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2003std (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w8 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700

May 26, 2015

Re: msvcirt: Share exceptions implementation with msvcp

by Alexandre Julliard

Iván Matellanes <matellanesivan(a)gmail.com> writes: > This is the first patch of my GSoC project :) > It implements the exceptions in msvcirt by using the code in msvcp90. > @@ -304,13 +304,15 @@ typedef enum __exception_type { > EXCEPTION_RERAISE, > EXCEPTION, > EXCEPTION_BAD_ALLOC, > - EXCEPTION_BAD_CAST, > EXCEPTION_LOGIC_ERROR, > +#ifndef _MSVCIRT > EXCEPTION_LENGTH_ERROR, > EXCEPTION_OUT_OF_RANGE, > EXCEPTION_INVALID_ARGUMENT, > EXCEPTION_RUNTIME_ERROR, > EXCEPTION_FAILURE, > + EXCEPTION_BAD_CAST, > +#endif Please avoid as many ifdefs as possible. For instance, having extra enums or unexported functions doesn't do any harm, so there's no reason to make a special case for them. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2015

Re: [2/3] widl: Fix handling of circular imports that involve the file passed on the command line.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > --- > tools/widl/parser.l | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/widl/parser.l b/tools/widl/parser.l > index b911186..2333687 100644 > --- a/tools/widl/parser.l > +++ b/tools/widl/parser.l > @@ -488,6 +488,9 @@ int do_import(char *fname) > int ptr = import_stack_ptr; > int ret, fd; > > + if (strcmp(import_stack_ptr ? import_stack[0].input_name : input_name, > + fname) == 0) > + return 0; /* initial source file */ This won't work for out-of-tree builds. -- Alexandre Julliard julliard(a)winehq.org

May 25, 2015

Re: GSoC 2015 projects

by Iván Matellanes

Hi all! I'm looking forward to contributing to Wine. My project consists on implementing part of the legacy Visual C++ iostream runtime, which was shipped with Visual Studio versions up to 6.0 and is currently a stub. I'll work on as many functions as time permits, and one of the key points is to reuse code from the modern Visual C++ runtime library that is already implemented. Some old applications and games (like MS Reader and Tron 2.0) would benefit from this, as they would run with the built-in library. A quick search on Bugzilla for 'msvcirt' shows several bugs related to unimplemented functions. Cheers, Iván. El 24/05/15 a las 19:21, Matteo Bruni escribió: > Hey all, > > tomorrow the coding period of the Summer of Code begins and I though > it might be a nice idea to let the community know about the projects > we've got this year. Actually, I though it would be even better if the > student themselves wrote a short summary of their own project for the > mailing list. > > So, with no authority backing me, I'm kindly asking that. No need to > write anything too fancy, just a few lines explaining what are you > going to work on over the summer and maybe what are the expected > benefits for Wine. > > Thank you! > Matteo. >

May 25, 2015

Re: dlls/ole32: Silence a FIXME

by Nikolay Sivov

On 25.05.2015 12:44, Hugh McMaster wrote: > On Mon, 25 May 2015 10:21:53 +0200, Stefan Dösinger wrote: >> Am 2015-05-25 um 07:56 schrieb Hugh McMaster: >>> This fixme appears on wine init either before console output or >>> after it. The fixme text is interrupting the output for Wine's >>> CLI-based programs, making the output difficult to read. >> WINEDEBUG=-all is the best way to deal with disturbing debug output. >> Or if you want other fixmes WINEDEBUG=-ole helps for this specific one. > > Thanks for the tip. > >> Though in many other places trying to QI an unknown interface is a >> WARN, not a FIXME. Which interface(s) are the application(s) / other >> libs trying to QI? > > The fixme appears every time wine launches an app, so WARN wouldn't help with this issue, although it may be more in keeping with the rest of the codebase. > > Searching on iid {00000019-0000-0000-c000-000000000046} brings up an MSDN page an OLE interop, the IExternalConnection Interface. > > It probably comes from explorer, we should silence it there.

May 25, 2015

RE: dlls/ole32: Silence a FIXME

by Hugh McMaster

On Mon, 25 May 2015 10:21:53 +0200, Stefan Dösinger wrote: > Am 2015-05-25 um 07:56 schrieb Hugh McMaster: >> This fixme appears on wine init either before console output or >> after it. The fixme text is interrupting the output for Wine's >> CLI-based programs, making the output difficult to read. > WINEDEBUG=-all is the best way to deal with disturbing debug output. > Or if you want other fixmes WINEDEBUG=-ole helps for this specific one. Thanks for the tip. > Though in many other places trying to QI an unknown interface is a > WARN, not a FIXME. Which interface(s) are the application(s) / other > libs trying to QI? The fixme appears every time wine launches an app, so WARN wouldn't help with this issue, although it may be more in keeping with the rest of the codebase. Searching on iid {00000019-0000-0000-c000-000000000046} brings up an MSDN page an OLE interop, the IExternalConnection Interface.

May 25, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 25 May 2015 at 10:43, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-05-25 um 10:27 schrieb Henri Verbeet: >> This is kind of ok because the existing code is like this, but notice >> the similarity to some of the code in resource_init(). In fact, is >> there any reason the caller needs to pass "gl_type" to resource_init() >> instead of letting it figure it out on its own? > The idea is to keep the switch between the different 2D types in the 2D > texture init parts of the code instead of the generic code. > I guess, but it doesn't really seem worth it if that means duplicating much of the generic usage/format validation code.

May 25, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-25 um 10:27 schrieb Henri Verbeet: > This is kind of ok because the existing code is like this, but notice > the similarity to some of the code in resource_init(). In fact, is > there any reason the caller needs to pass "gl_type" to resource_init() > instead of letting it figure it out on its own? The idea is to keep the switch between the different 2D types in the 2D texture init parts of the code instead of the generic code. >> -static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info) >> +static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info, > Why is "object" a pointer? Symmetry with create_and_bind_fbo_attachment(). But yeah, it's not really necessary, I'll change this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVYuDJAAoJEN0/YqbEcdMwJO4QAJS9Kb6d/0Wq5ioRpOeK0DI/ pLD7J9/jzRkH1DYNQzdhyH9LtAj4ugIx5XjjzR1tIsVXz8spjSDDMGDVF0QCEa5a wK0fckdV31QdFG81fdLgKsR+U/+ZehFgy4s/lBZugDq+foGpfsbQwLMb/nDzG9AS SEoWVOQYKEfOY3bdpsJxTx/vjK9d6Dt/KVGAlJFEPT5Xm64k74BkBW8MDfmN//Oe +HDdHnaxTi4seDbtcK2NLyHGU+YPaHt1YgK0HtLZW1uJ0IlvrV2O2XrSEmbGQUpu 7EkyNaYvZFJKzB+0EjGZrBIN2M38C0mLn8b9stE/FBAkt42e0YTGbXyo8/DENci6 xkn+ZMH4mtg2IaW9wxO2Xu92YOId3X5tyIYSE2zA+5/hXtCGCxOPdRzjVCO5TvV3 RHUg28pt8RPikHTnglV5NzsL8wuA/yaPgLPj0uGbLCz4t/1OApWnGWX7L5P9v5BT SuW6H9iJHWmXarbobgpHqmmqKA2+sPhmUjHCVJW4OM/WmLUGgRSZ6a0sRrbcXY8P 8bbtWNkhNq2JhaAcVMNJ0PgAvQfEvxSrRQyxAJQgj9Sf87/+KXYy0eV8pwYs8i2A IdBDW0wGW5y+40+08WHAa+k+IC43nMaGT77NhHm+OHLJecEkm671cDi5cQRLX20z RqDmOWRybXghDocnS8WH =70T8 -----END PGP SIGNATURE-----

May 25, 2015

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.

by Henri Verbeet

On 22 May 2015 at 10:11, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1145,18 +1151,21 @@ static HRESULT texture_init(struct wined3d_texture *texture, const struct wined3 > /* WINED3DUSAGE_DEPTHSTENCIL needs WINED3DFMT_FLAG_DEPTH or WINED3DFMT_FLAG_STENCIL, not both. */ > > if ((format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & required_flags) == required_flags > - && (!(desc->usage & WINED3DUSAGE_DEPTHSTENCIL) || (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & ds_flags)) > + && check_ds_support(format, WINED3D_GL_RES_TYPE_TEX_2D, desc->usage) > && (gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT] > || (desc->width == pow2_width && desc->height == pow2_height))) > gl_type = WINED3D_GL_RES_TYPE_TEX_2D; > else if ((format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] & required_flags) == required_flags > - && (!(desc->usage & WINED3DUSAGE_DEPTHSTENCIL) || (format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] & ds_flags))) > + && check_ds_support(format, WINED3D_GL_RES_TYPE_TEX_RECT, desc->usage)) > gl_type = WINED3D_GL_RES_TYPE_TEX_RECT; > + else if ((format->flags[WINED3D_GL_RES_TYPE_RB] & required_flags) == required_flags > + && check_ds_support(format, WINED3D_GL_RES_TYPE_RB, desc->usage)) > + gl_type = WINED3D_GL_RES_TYPE_RB; > else > gl_type = WINED3D_GL_RES_TYPE_TEX_2D; /* No error, may be SCRATCH pool or emulated conditional np2. */ > This is kind of ok because the existing code is like this, but notice the similarity to some of the code in resource_init(). In fact, is there any reason the caller needs to pass "gl_type" to resource_init() instead of letting it figure it out on its own? > -static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info) > +static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info, > + enum wined3d_gl_resource_type d3d_type, GLuint *object) > { > - gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, > - GL_TEXTURE_2D, 0, 0); > + switch (d3d_type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + case WINED3D_GL_RES_TYPE_TEX_2D: > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + case WINED3D_GL_RES_TYPE_TEX_3D: > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + gl_info->gl_ops.gl.p_glDeleteTextures(1, object); > + break; > + > + case WINED3D_GL_RES_TYPE_RB: > + gl_info->fbo_ops.glDeleteRenderbuffers(1, object); > + break; > + > + case WINED3D_GL_RES_TYPE_BUFFER: > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > } Why is "object" a pointer?

May 25, 2015

Re: dlls/ole32: Silence a FIXME

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-25 um 07:56 schrieb Hugh McMaster: > This fixme appears on wine init either before console output or > after it. The fixme text is interrupting the output for Wine's > CLI-based programs, making the output difficult to read. WINEDEBUG=-all is the best way to deal with disturbing debug output. Or if you want other fixmes WINEDEBUG=-ole helps for this specific one. Though in many other places trying to QI an unknown interface is a WARN, not a FIXME. Which interface(s) are the application(s) / other libs trying to QI? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVYtuhAAoJEN0/YqbEcdMwaLcP/iP/cWFNiqommeRRFXKpv1GN gCxfqO3H5H/dWlobvFahZ6caZvRg87tw940dO6l9ch3i29A3ooJR0QNmJefk4WBa RGCp+g9lDxqIp9KvsnHGeHN4gdNXdIkNDtTusuDi1HC31MW3Wcl9rL3eCwTLeK3O 6QNTmAgUK+ZJM5xvBcTPMEidqgw2+L8SyjRTS3I84NPa5tZhRWV5gwvglBIKlvlk j2ve5wu7MYMyCU0yadmDyCioLeVzMMvIK1vFTkMbLlWlQc+ni2wgAvjD51ODW9Mg LiJJow6CVnyIF2htAaqs1bVWgtRYiFkHecidliJzqlP3CS11dmys0izy4GCO5nCZ 8vQpvVjHnKjzyrTaHkJJnGXdCSFhcDdjj2VlxrhKZy0C5TUKhsu9HLux3ZZnh8rX 3LX/Di16PgALnx28oAGaA/tkjuutdToZioHVi6V4doRZu1gVQAVdVuqu+jyj8rnR GQfdUbBsMN0sfdm4wzG2Ls+BdPyymq4FtgvMoYjH7Ue3+4smQu0EilmTCHAnQdZU OjF4dUgOqSdenQOWbVJGuiQzabwfxfQVePVlUuse7sthnXf8xAk5CCEBl/ITvYxZ vbORohm8+Xr1yQ9qi7rgRB1ItU3ThrEUFm6DAruIHUtgfiK4zVXczFXh83GXoPur mY9cApML3tVu3Q0S+WtK =5NtD -----END PGP SIGNATURE-----

May 25, 2015