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

Re: [2/2] widl: Fix generation of a typelib for winhttp.

by Huw Davies

On 2 Oct 2015, at 03:25, Dmitry Timoshkov wrote: > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index 26600e4..7973113 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -974,8 +974,7 @@ static int encode_type( > { > int typeinfo_offset; > > - /* typedef'd types without public attribute aren't included in the typelib */ > - while (type->typelib_idx < 0 && type_is_alias(type) && !is_attr(type->attrs, ATTR_PUBLIC)) > + while (type->typelib_idx < 0 && type_is_alias(type)) > type = type_alias_get_aliasee(type); > > chat("encode_type: VT_USERDEFINED - type %p name = %s real type %d idx %d\n", type, > @@ -1836,7 +1835,7 @@ static msft_typeinfo_t *create_msft_typeinfo(msft_typelib_t *typelib, enum type_ > MSFT_TypeInfoBase *typeinfo; > MSFT_GuidEntry guidentry; > > - chat("create_msft_typeinfo: name %s kind %d\n", name, kind); > + chat("create_msft_typeinfo: name %s kind %d, index %d\n", name, kind, typelib->typelib_header.nrtypeinfos); > > msft_typeinfo = xmalloc(sizeof(*msft_typeinfo)); > memset( msft_typeinfo, 0, sizeof(*msft_typeinfo) ); > @@ -2307,9 +2306,7 @@ static void add_entry(msft_typelib_t *typelib, const statement_t *stmt) > { > const type_list_t *type_entry = stmt->u.type_list; > for (; type_entry; type_entry = type_entry->next) { > - /* if the type is public then add the typedef, otherwise attempt > - * to add the aliased type */ > - if (is_attr(type_entry->type->attrs, ATTR_PUBLIC)) > + if (type_get_type(type_entry->type) == TYPE_BASIC) > add_typedef_typeinfo(typelib, type_entry->type); > else > add_type_typeinfo(typelib, type_alias_get_aliasee(type_entry->type)); Doesn't this essentially make [public] a nop? That seems wrong. The WinHttpRequestOption enum has a [uuid] attribute, so that probably has something to do with it. Huw.

Oct. 2, 2015

Re: [PATCH v3] ucrtbase: Make the strtod implementation C99 compatible

by Martin Storsjö

On Tue, 29 Sep 2015, Martin Storsjo wrote: > Add a test for ucrtbase that verifies these aspects of the C99 > behaviour of strtod. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > Changed the overflow checking to use base instead of 10, and added > more test cases, as suggested by Piotr. > --- > configure.ac | 1 + > dlls/msvcrt/string.c | 68 ++++++++++++++++++---- > dlls/ucrtbase/tests/Makefile.in | 5 ++ > dlls/ucrtbase/tests/string.c | 121 ++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 185 insertions(+), 10 deletions(-) > create mode 100644 dlls/ucrtbase/tests/Makefile.in > create mode 100644 dlls/ucrtbase/tests/string.c Any further comments on this? Afaik I've addressed all comments by Piotr so far. // Martin

Oct. 1, 2015

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

by Henri Verbeet

On 1 October 2015 at 17:50, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-10-01 um 17:42 schrieb Henri Verbeet: >> Not all d3d9 surfaces will necessarily have a corresponding d3d9 >> texture, and I'm not sure it's worth changing that. So in that >> regard this is fine. (But please fix the '*' placement.) Once you >> pass a wined3d_texture the container_parent parameter becomes >> redundant. > Just to make sure I understand this right, especially in combination > with > https://www.winehq.org/pipermail/wine-devel/2015-September/109145.html > : There may not always be a d3d9_texture for a d3d9_surface but > there's always a wined3d_texture, which we store in the d3d9_surface > instead of the d3d9_texture. If we need the d3d9_texture for some > reason we get the parent. I.e. pretty much what Riccardo has done in > this regard in this patch? > Yeah, although it's not necessarily wrong to just store the d3d9 texture pointer in the d3d9 surface as well.

Oct. 1, 2015

Re: [PATCH 1/2 v2] msvcp: Add _Dscale implementation

by Piotr Caban

On 10/01/15 18:57, Marvin wrote: > === w2000pro (32 bit msvcp120) === > The test timed out The dll is not installed on that vm.

Oct. 1, 2015

Re: [PATCH 1/2 v2] msvcp: Add _Dscale implementation

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=16924 Your paranoid android. === w2000pro (32 bit msvcp120) === The test timed out

Oct. 1, 2015

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-01 um 17:42 schrieb Henri Verbeet: > Not all d3d9 surfaces will necessarily have a corresponding d3d9 > texture, and I'm not sure it's worth changing that. So in that > regard this is fine. (But please fix the '*' placement.) Once you > pass a wined3d_texture the container_parent parameter becomes > redundant. Just to make sure I understand this right, especially in combination with https://www.winehq.org/pipermail/wine-devel/2015-September/109145.html : There may not always be a d3d9_texture for a d3d9_surface but there's always a wined3d_texture, which we store in the d3d9_surface instead of the d3d9_texture. If we need the d3d9_texture for some reason we get the parent. I.e. pretty much what Riccardo has done in this regard in this patch? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWDVZVAAoJEN0/YqbEcdMwb9kP/0UWhBxLewV5IYEDnWaQQzL6 llgVwVmkCF+TzX2IH8mnJOt8hpTDMS/CCwALz16pcJu/g12RTvZSbKcMBPWNlGfx N8q6yVFjCt+lsIwZIG9ybPqKqvKST1lCfc55NgPkg0q3IiLZsHVlXKx1PxsCfg/h CY1yrjEvHHpQep/ToO21f/rYSk1/yOWjCZBvIh1ncZlziRk6PyNu3jsaVr24hcSl 54/5zwS3W6sqBSoBDQCkTFGi3X7UXE5LiOfrsjHmxGFZwLiJgVfLFxa+QeAdH94q D+QNtz7ZG6EPKUCzH95lT60tqD/571cL7H5QAdWWZCdgy+cKzV5Cr5z4YEgcfzeB i0iE5XrQ/MRe8uehe2HVQP7f7twQeobrPYCCpBHYeA1iadd0xqzw9xDyBaedQWVG JFy2ZlR/hFtdspj8KuGWMt3Jr7lyuPVyY4l4BqLJtrXCJISRMinNlxRH3vxwxUeJ 102XzmMsYPSQpXmAkpn+H/xSkDdhpzZ2yuUYLIIdUWMaBI7MfBXo40vy6t7yv1SU kbTTWhxf65KGyHm70KUTBy9UF065iyPgD1jgNcmsyz07SWVyjc5Nspc6o6s2GuKe g9l9x+1boQcB/oUANaF1pZ4NrzA3FcU9GhOQdm8hs9ipD4iE/c/CHWS7x2QxCokF ud4uZP5Kt3tCLJ9KvRMD =mV9p -----END PGP SIGNATURE-----

Oct. 1, 2015

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes

by Henri Verbeet

On 23 September 2015 at 10:51, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: >> - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent >> *device_parent, void *container_parent, - struct >> wined3d_volume *volume, void **parent, const struct >> wined3d_parent_ops **parent_ops); + HRESULT (__cdecl >> *volume_created)(struct wined3d_device_parent *device_parent, + >> struct wined3d_texture *texture, unsigned int sub_resource_idx, + >> void **parent, const struct wined3d_parent_ops **parent_ops); > Is there a reason why you're passing the wined3d_texture container > instead of the container parent? It doesn't matter too much because > you can either do wined3d_resource_get_parent or > d3d*_texture->wined3d_texture, but I think it is a needless change. > Not all d3d9 surfaces will necessarily have a corresponding d3d9 texture, and I'm not sure it's worth changing that. So in that regard this is fine. (But please fix the '*' placement.) Once you pass a wined3d_texture the container_parent parameter becomes redundant. > It seems the patch is bigger than it needs to be. You could just add > unsigned int sub_resource_idx and keep the rest in place. Through > struct d3d8_texture *texture inside struct d3d8_volume you already > have access to the wined3d texture. With the addition of the sub > resource idx you can migrate the volume methods one by one, and in the > last patch that removes access to wined3d_volume drop struct > wined3d_volume *volume from the callback. > Yeah, this. Patches should only do a single thing as much as possibly/reasonable. It's a shame you can't drop the volume/surface parameter from the callback in the first patch, but not so much of an issue. In fact, you don't even necessarily need to store the texture/sub_resource_idx everywhere in the first patch. You should probably start with introducing something like wined3d_texture_map() and using it for d3d11. Then the second patch could e.g. be to use wined3d_texture_map() in d3d9 as well, with the callback interface change being a logical consequence of that.

Oct. 1, 2015

Re: opengl32: it does not compile well in CYGWIN and MINGW

by Alexandre Julliard

carlo.bramix(a)libero.it writes: > Hello, > I'm writing here for asking a suggestion about a patch that I have sent one month ago. > The fix attached in this email: > > https://www.winehq.org/pipermail/wine-patches/2015-August/141811.html > > is required because, when compiling opengl32 on Windows (CYGWIN or > MINGW), the compiler complains that the exported functions are > redeclared without dllimport attribute, while they should be declared > with dllexport from beginning. > This error can be fixed by adding the definition of _GDI32_ so that WINGDIAPI macro is declared correctly. > This fix already exists for example in /dlls/gdi32/Makefile.in as you can see here: > > http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/Makefile.in In gdi32 we don't want to import the gdi32 functions, but opengl32 is supposed to import them, so getting rid of the dllimport doesn't look right. -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2015

Re: Wined3d wireframe rendering

by Bruno Jesus

Thanks everyone, I really appreciate all the replies. On Wednesday, September 30, 2015, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Wed, Sep 30, 2015 at 2:47 AM, Stefan Dösinger < > stefandoesinger(a)gmail.com > <javascript:_e(%7B%7D,'cvml','stefandoesinger(a)gmail.com');>> wrote: > >> >> Am 29.09.2015 um 18:12 schrieb Aaryaman Vasishta < >> jem456.vasishta(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','jem456.vasishta(a)gmail.com');>>: >> > While you have a point, but (theoretically, judging from Bruno's >> experience in the game X-moto) texture mapping might be more exacting than >> rendering all vertices together without texture mapping in some cases. >> Though I'm not sure about it myself. >> Note that wireframe rendering doesn't disable texture mapping. It just >> assembles the vertices to geometry in a different way. Instead of filling >> the entire triangle defined by the vertices it just fills the lines between >> the vertices. The lines that are drawn still have the normal fragment >> processing (including shaders and textures) applied. >> > Right, my bad, I forgot to mention that. > >

Oct. 1, 2015