November 2015 - Wine-devel - list.winehq.org

Re: [3/7] widl: Ignore assignment of a duplicate uuid. Resend.
by Huw Davies 02 Nov '15

02 Nov '15

On Sat, Oct 31, 2015 at 02:31:38PM +0800, Dmitry Timoshkov wrote: > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index daa0366..dc8b124 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -494,10 +494,22 @@ static int ctl2_alloc_guid( > MSFT_GuidEntry *guid_space; > int hash_key; > > + chat("adding uuid {%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n", > + guid->guid.Data1, guid->guid.Data2, guid->guid.Data3, > + guid->guid.Data4[0], guid->guid.Data4[1], guid->guid.Data4[2], guid->guid.Data4[3], > + guid->guid.Data4[4], guid->guid.Data4[5], guid->guid.Data4[6], guid->guid.Data4[7]); > + > hash_key = ctl2_hash_guid(&guid->guid); > > offset = ctl2_find_guid(typelib, hash_key, &guid->guid); > - if (offset != -1) return offset; > + if (offset != -1) > + { > + warning("duplicate uuid {%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n", > + guid->guid.Data1, guid->guid.Data2, guid->guid.Data3, > + guid->guid.Data4[0], guid->guid.Data4[1], guid->guid.Data4[2], guid->guid.Data4[3], > + guid->guid.Data4[4], guid->guid.Data4[5], guid->guid.Data4[6], guid->guid.Data4[7]); > + return -1; > + } > > offset = ctl2_alloc_segment(typelib, MSFT_SEG_GUID, sizeof(MSFT_GuidEntry), 0); This still has problems. For example see the idl below. Also note that this is the cause of the warnings in httpresquest.idl . Huw. import "objidl.idl"; [uuid(12345678-0000-0000-0000-000000000000)] library foo { typedef [uuid(12345678-9ab0-0000-0000-000000000000)] struct f {int x;} f; [uuid(12345678-9abc-0000-0000-000000000000)] interface IMy : IUnknown { HRESULT foo([in]f *ptr); } }

2 1

Re: [PATCH 1/7] wined3d: Introduce wined3d_device_map_sub_resource().
by Stefan Dösinger 02 Nov '15

02 Nov '15

> Am 02.11.2015 um 04:17 schrieb Józef Kucia <jkucia(a)codeweavers.com>: > > +HRESULT CDECL wined3d_device_map_sub_resource(struct wined3d_device *device, > + struct wined3d_resource *resource, unsigned int sub_resource_idx, > + struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags) > +{ > + struct wined3d_resource *sub_resource; > + > + TRACE("device %p, resource %p, sub_resource_idx %u, map_desc %p, box %p, flags %#x.\n", > + device, resource, sub_resource_idx, map_desc, box, flags); > + > + if (!(sub_resource = sub_resource_from_resource(resource, sub_resource_idx))) > + { > + WARN("Invalid sub_resource_idx %u.\n", sub_resource_idx); > + return E_INVALIDARG; > + } > + > + return sub_resource->resource_ops->resource_map(sub_resource, map_desc, box, flags); I don't like the idea of calling the sub resource here. I think this should forward to wined3d_texture_map for textures for now and pass the sub resource index to the resource_map callback. In the long run we obviously want wined3d_texture_map and wined3d_buffer_map to be merged together, but for now (surface,volume)->(texture) is tricky enough. I have some patches in the works for that.

1 0

Re: [PATCH 2/6] wined3d: Keep track of FBOs through the GL names (v2).
by Henri Verbeet 02 Nov '15

02 Nov '15

On 28 October 2015 at 15:29, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 2: Don't use fbo_entry->d3d_* for logging, plan for it to go > away. The disadvantage is now that we don't know the d3d properties once > we find out that an FBO doesn't work and need a full TRACE log for this > information, but I think that's something we can live with. > > If there is a prettier way to find the texture target of a GL texture > name please advise. I couldn't find any. > I think I'll hold off on this until the regression from 1ca9dfc8ee25f4ae188fdacd4d3d56046cef8003 is resolved, but you can probably split the logging changes into their own patch. > + char name[32]; > + sprintf(name, "Color attachment %u", i); > + context_dump_fbo_attachment(gl_info, target, GL_COLOR_ATTACHMENT0 + i, name); sprintf() is one of those things that's usually best avoided. In this case the string is mostly redundant as well, since you have the attachment enum. > +static inline void context_create_fbo_key(struct wined3d_fbo_entry_key *key, > + struct wined3d_surface **render_targets, struct wined3d_surface *depth_stencil, > + DWORD color_location, DWORD ds_location, UINT color_buffers) The naming is a bit odd. "create" is usually for things that allocate something, "color_buffers" would normally be called e.g. "rt_count". The "inline" seems speculative. I think modern compilers mostly ignore it, but it does make it harder to notice when a function becomes unused. > - entry = HeapAlloc(GetProcessHeap(), 0, sizeof(*entry)); > - entry->render_targets = HeapAlloc(GetProcessHeap(), 0, gl_info->limits.buffers * sizeof(*entry->render_targets)); > - memcpy(entry->render_targets, render_targets, gl_info->limits.buffers * sizeof(*entry->render_targets)); > - entry->depth_stencil = depth_stencil; > - entry->color_location = color_location; > - entry->ds_location = ds_location; > + UINT object_count = gl_info->limits.buffers + 1; > + > + entry = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + FIELD_OFFSET(struct fbo_entry, key.objects[object_count])); > + entry->d3d_render_targets = HeapAlloc(GetProcessHeap(), 0, > + gl_info->limits.buffers * sizeof(*entry->d3d_render_targets)); > + context_create_fbo_key(&entry->key, render_targets, depth_stencil, color_location, ds_location, > + gl_info->limits.buffers); > + memcpy(entry->d3d_render_targets, render_targets, sizeof(*entry->d3d_render_targets) * gl_info->limits.buffers); > + entry->d3d_depth_stencil = depth_stencil; Why HEAP_ZERO_MEMORY? Do we no longer initialize all fields? > + { > + struct wined3d_fbo_resource resource = {0}; > + context_attach_depth_stencil_fbo(context, target, &resource, FALSE, 0, 0); "resource" should probably be static const. > - if (surface == entry->render_targets[i]) > + if (surface->container->texture_rgb.name == entry->key.objects[i].object || > + surface->container->texture_srgb.name == entry->key.objects[i].object) This is different from the usual style.

2 2

Re: [PATCH 02/4 resend] msvcp110: Add tr2_sys__Read_dir implementation.(try 2)
by Piotr Caban 02 Nov '15

02 Nov '15

On 10/31/15 10:29, YongHao Hu wrote: > + TRACE("(%s %p %p)\n", debugstr_a(target), handle, type); Please print the target argument correctly in trace message. Thanks, Piotr

1 0

Re: [v3] d3d9: call wined3d_device_copy_sub_resource_region instead of wined3d_device_update_surface in d3d9_device_UpdateSu
by Marvin 02 Nov '15

02 Nov '15

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

1 0

loader manpages get installed in wrong build step
by Sebastian Lackner 02 Nov '15

02 Nov '15

Hiho, I've noticed another side effect introduced by http://source.winehq.org/git/wine.git/commit/da340169d6518cf42f1cbe169fbf12…, and I'm not sure if its intentional, or if its a bug. For WOW64 builds all manpages were installed in the 64-bit build step before. After the commit, some manpages (those in loader/) also get installed in the 32-bit build step. Here are some logs for comparison: - before: http://repos.wine-staging.com/all/20151021-0141-arch-x64/build.log - after: http://repos.wine-staging.com/all/20151101-0726-arch-x64/build.log (search for "wine.1" for example) When both builds end in the same package (like on Archlinux) this doesn't matter, however there are plenty of distributions which ship the 32-bit and 64-bit parts in different packages. Having a few manpages in one and the rest in the other is at least a bit unusual, but could also lead to package conflicts. Should this be considered a bug, or is it up to package maintainers to workaround this issue? And what would be the preferred solution to fix this? I don't really want to reintroduce install-man-pages just after it was removed... Best regards, Sebastian

3 3

Microsoft shared PDB fileformat
by Marcus Meissner 01 Nov '15

01 Nov '15

Hi, just in from the hell-freezes-over department: https://github.com/Microsoft/microsoft-pdb Ciao, Marcus

3 2

Fwd: steam web browsing on OS X
by Theodore Dubois 01 Nov '15

01 Nov '15

How exactly does Chromium replace the system calls with its own versions? Not quite sure how that works. ~Theodore On Nov 01, 2015, at 07:18 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: On 02.11.2015 04:09, Theodore Dubois wrote: Darn! Forgot to cc the list. Can someone explain exactly why absolute addresses are needed here? I'm new to wine, but eager to learn. The main reasons are: - The code still has to work after Chromium has moved it to a different memory location. A relative jump would not be suitable for that. Also, in our proof of concept patch, we want to avoid huge syscall tables, and instead pass a pointer in %eax. - DRM applications might complain when a function entry point looks too unusual. - In "non-relaxed" mode Chromium refuses to accept the entry point, if it doesn't match exactly the function signature on Windows. I don't think this is used for Steam yet, but its just a matter of time. Regards, Sebastian

1 0

Fwd: steam web browsing on OS X
by Theodore Dubois 01 Nov '15

01 Nov '15

Darn! Forgot to cc the list. Can someone explain exactly why absolute addresses are needed here? I'm new to wine, but eager to learn. ~Theodore On Nov 01, 2015, at 04:29 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: Hi Sebastian, On 10/30/15 5:57 PM, Sebastian Lackner wrote: On 30.10.2015 17:42, Theodore Dubois wrote: Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? ~Theodore The staged patchset adds thunk wrappers for ntdll functions, but to be compatible with Windows, they have to contain absolute addresses. This requires text relocations, which are not allowed by default on OSX. Since this issue was discovered shortly before the last release, disabling the patchset on OSX was easier than the necessary configure.ac changes, but I'm working on a solution. Unless we hit some impossible to solve problems Wine Staging 1.7.54 will make the Steam fix also available on OSX. ;) I took a look at this problem and the patchset and I think we should be able to avoid text relocation in this case. I should have a proof of concept patch soon. Thanks, Jacek

2 1

Re: [4/4] dlls/ole32: Add more traces to the storage methods.
by Vincent Povirk 01 Nov '15

01 Nov '15

Whoops, accidentally dropped wine-devel from my reply. On Sun, Nov 1, 2015 at 6:49 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > There's no test that calls these directly because they are internal methods. > I could have used any code to signal that the operation does not make sense > for this object. > > We should have tests that open and commit to a non-toplevel storage object, > which would call them. Sorry, that wasn't quite right. It's not enough to commit to a non-toplevel storage object. What you'd have to do is nest transacted storages and commit to the inner one.

1 0