- wine-devel - winehq.org

Re: [PATCH 1/7] wined3d: Introduce wined3d_device_map_sub_resource().
by Henri Verbeet 02 Nov '15

02 Nov '15

On 2 November 2015 at 04:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +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 suppose in d3d11 this is part of ID3D11DeviceContext because of deferred contexts maps. Perhaps once we have those in wined3d it will end up in the device (although I think it's more likely to become part of some interface on top of wined3d_cs), but right now the "device" parameter isn't even used. I think that for the time being the interface we want is just HRESULT CDECL wined3d_resource_map(struct wined3d_resource *resource, unsigned int sub_resource_idx, struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index fd7bbc8..fb296b1 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2156,6 +2156,8 @@ struct wined3d_resource_ops > ULONG (*resource_incref)(struct wined3d_resource *resource); > ULONG (*resource_decref)(struct wined3d_resource *resource); > void (*resource_unload)(struct wined3d_resource *resource); > + HRESULT (*resource_map)(struct wined3d_resource *resource, struct wined3d_map_desc *map_desc, > + const struct wined3d_box *box, DWORD flags); > }; > Here we'll probably want something like HRESULT (*resource_sub_resource_map)(struct wined3d_resource *resource, unsigned int sub_resource_idx, struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); That implies having different resource ops for 2D and 3D textures, but that's easy. It also implies returning an error when this is called on a surface or volume. I'm not sure how easy it would be at this point, but we'll probably just want resource ops on sub-resources to print an ERR(). E.g. ideally we'd never call resource_unload() on a surface, but only ever on a texture. But that then means not adding sub-resources to the device's resource list, etc.

2 1

Re: [PATCH 04/10] ucrtbase: Handle the swprintf style termination and return values
by Piotr Caban 02 Nov '15

02 Nov '15

Hi, On 11/02/15 11:08, Martin Storsjo wrote: > @@ -724,12 +724,13 @@ int CDECL MSVCRT__stdio_common_vsprintf( unsigned __int64 options, char *str, MS > struct _str_ctx_a ctx = {len, str}; > int ret; > > - if (options != UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION && > - options != UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR) > + if (options & ~UCRTBASE_PRINTF_TERMINATION_MASK) > FIXME("options %s not handled\n", wine_dbgstr_longlong(options)); > - ret = pf_printf_a(options & UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR ? puts_clbk_str_c99_a : puts_clbk_str_a, > + ret = pf_printf_a(options & UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION ? puts_clbk_str_a : puts_clbk_str_c99_a, > &ctx, format, locale, FALSE, FALSE, arg_clbk_valist, NULL, &valist); > puts_clbk_str_a(&ctx, 1, &nullbyte); > + if ((options & UCRTBASE_PRINTF_TERMINATION_MASK) == 0 && ret >= len) > + ret = -2; > return ret; > } This code looks like you're trying to make the things other way around. Shouldn't UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR flag impact the callback being used? On the other hand UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION flag should probably only affect terminating NULL related behavior. Maybe following code makes more sense: ret = pf_printf_a(options & UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR ? puts_clbk_str_c99_a : puts_clbk_str_a, &ctx, format, locale, FALSE, FALSE, arg_clbk_valist, NULL, &valist); if(puts_clbk_str_a(&ctx, 1, &nullbyte)==-1 && !(options & UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION)) { if(len) str[len-1] = 0; return -2; } return ret; What do you think about it? Thanks, Piotr

3 5

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 02 Nov '15

02 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 02 Nov '15

02 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 02 Nov '15

02 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

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

01 Nov '15

On Thu, Oct 29, 2015 at 2:41 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > static HRESULT TransactedSnapshotImpl_GetTransactionSig(StorageBaseImpl *base, > ULONG* result, BOOL refresh) > { > + FIXME("stub\n"); > return E_NOTIMPL; > } This is intentional. We don't need transaction signatures because nothing else can have our snapshot open to commit to it. Anything calling these methods should expect and handle E_NOTIMPL.

2 3

Re: [2/4] dlls/ole32: Zero out returned stats when IEnumSTATSTG::Next reaches end of enumeration.
by Vincent Povirk 01 Nov '15

01 Nov '15

Are you sure we shouldn't be zeroing the entire remaining buffer? And maybe we should put it after the loop, given there are multiple exits.

2 1

Re: [PATCH 4/4] winex11: Make color cubes as big as possible.
by Vincent Povirk 31 Oct '15

31 Oct '15

Sorry, I don't think I'm qualified to review this. There's too much context here that I don't understand.

1 0

Re: [PATCH 01/4] msvcp110: Add tr2_sys__Open_dir implementation.(try 4)
by Piotr Caban 31 Oct '15

31 Oct '15

On 10/29/15 16:28, YongHao Hu wrote: > + char temppath[MAX_PATH+1]; > + TRACE("(%p %s %p %p)\n", target, debugstr_a(dest), err_code, type); > + if(strlen(dest) >= MAX_PATH) { > + *err_code = ERROR_BAD_PATHNAME; > + return NULL; > + } > + strcpy(temppath, dest); > + strcat(temppath, "\\*"); There may still write outside of temppath array in this code. Thanks, Piotr

2 1

Re: [7/7] oleaut32/tests: Add a bunch of new tests for typelib generation.
by Marvin 31 Oct '15

31 Oct '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=17862 Your paranoid android. === wxppro (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w2003std (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === wvistau64 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w2008s64 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w7u (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w7pro64 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w8 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w864 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === w1064 (32 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 20 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 16 typelib: unhandled exception c0000005 at 00420ACA === wvistau64 (64 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4589: Test failed: typeattr->cbSizeInstance expected 4 got 8 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 40 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 32 typelib: unhandled exception c0000005 at 000000000041E933 === w2008s64 (64 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4589: Test failed: typeattr->cbSizeInstance expected 4 got 8 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 40 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 32 typelib: unhandled exception c0000005 at 000000000041E933 === w7pro64 (64 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4589: Test failed: typeattr->cbSizeInstance expected 4 got 8 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 40 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 32 typelib: unhandled exception c0000005 at 000000000041E933 === w864 (64 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4589: Test failed: typeattr->cbSizeInstance expected 4 got 8 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 40 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 32 typelib: unhandled exception c0000005 at 000000000041E933 === w1064 (64 bit typelib) === typelib.c:4570: Test failed: bstrIfName expected "_n" got "child_iface" typelib.c:4574: Test failed: typeattr->typekind expected 1 got 3 typelib.c:4589: Test failed: typeattr->cbSizeInstance expected 4 got 8 typelib.c:4591: Test failed: help_ctx expected 3 got 0 typelib.c:4592: Test failed: ((LONG)(((WORD)((DWORD_PTR)(typeattr->wMinorVerNum) & 0xFFFF)) | ((DWORD)((WORD)((DWORD_PTR)(typeattr->wMajorVerNum) & 0xFFFF))) << 16)) expected 65538 got 0 typelib.c:4593: Test failed: typeattr->cbSizeVft expected 0 got 40 typelib.c:4594: Test failed: typeattr->cFuncs expected 0 got 1 typelib.c:4606: Test failed: got wrong guid {b14b6bb5-904e-4ff9-b247-bd361f7aa002} typelib.c:4625: Test failed: desc->memid expected 0 got 1610743808 typelib.c:4626: Test failed: desc->funckind expected 0 got 1 typelib.c:4627: Test failed: desc->invkind expected 0 got 1 typelib.c:4628: Test failed: desc->callconv expected 0 got 4 typelib.c:4631: Test failed: desc->oVft got 32 typelib: unhandled exception c0000005 at 000000000041E933

1 0

Release plans
by Alexandre Julliard 31 Oct '15

31 Oct '15

Folks, We've decided at WineConf that there would be a code freeze and release every year in the fall. That means about right now... However, there are a few things I'd like to get in first (*cough* Pulse driver), so my thinking is to do one more development release cycle, and start code freeze after 1.7.55. This should enable us to release 1.8 before the end of the year. So if there are new features you'd like to get into 1.8, you have another two weeks... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] user32: Silently ignore temporary foreground loss (v2).
by Marvin 30 Oct '15

30 Oct '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=17854 Your paranoid android. === w1064 (32 bit win) === win.c:6708: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6730: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6708: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6708: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6708: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6708: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6708: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6730: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6708: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6730: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6708: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6730: Test failed: 0x80/0x1050000: window rect 0,0-1024,768

1 0

Re: [PATCH 2/3] msvcp120: implement _Thrd_current
by Piotr Caban 30 Oct '15

30 Oct '15

On 10/29/15 15:50, Daniel Lehman wrote: > +_Thrd_t __cdecl _Thrd_current(void) The __cdecl calling convention is not compatible in this case. You will need to do something similar as is done in _Getcoll implementation. Unless I'm missing something, quick look on _Getcoll shows that it's broken when _MSVCP_VER>=110 and 64-bit wine is compiled. I'll take a look on it. Thanks, Piotr

1 1

Re: [1/2] ole32: Accept TYMED_FILE as a possible source of CF_METAFILEPICT format.
by Huw Davies 30 Oct '15

30 Oct '15

B1;2cOn Fri, Oct 23, 2015 at 06:32:17PM +0800, Dmitry Timoshkov wrote: > diff --git a/dlls/ole32/datacache.c b/dlls/ole32/datacache.c > index caabd10..3db0edf 100644 > --- a/dlls/ole32/datacache.c > +++ b/dlls/ole32/datacache.c > @@ -285,7 +285,7 @@ static DataCacheEntry *DataCache_GetEntryForFormatEtc(DataCache *This, const FOR > static HRESULT check_valid_clipformat_and_tymed(CLIPFORMAT cfFormat, DWORD tymed) > { > if (!cfFormat || !tymed || > - (cfFormat == CF_METAFILEPICT && tymed == TYMED_MFPICT) || > + (cfFormat == CF_METAFILEPICT && (tymed == TYMED_MFPICT || tymed == TYMED_FILE)) || > (cfFormat == CF_BITMAP && tymed == TYMED_GDI) || > (cfFormat == CF_DIB && tymed == TYMED_HGLOBAL) || > (cfFormat == CF_ENHMETAFILE && tymed == TYMED_ENHMF)) This should be easy enough to test. Create a stand-alone data cache ( using CreateDataCache() ), then call IOleCache_Cache with the relevant fmtetc. Huw.

2 2

Re: [PATCH 1/3] msvcp120: implement _Thrd_sleep/yield (try 2)
by Piotr Caban 30 Oct '15

30 Oct '15

On 10/29/15 23:04, Daniel Lehman wrote: > + ok((diff > 2000 - TIMEDELTA) && (diff < 2000 + TIMEDELTA), "got %d", diff); This test is occasionally failing on my Windows 7 box (is most cases diff ~= 2165, biggest value I've seen is diff = 2771). I think that it should be enough to just test diff>2000-TIMEDELTA. New line character is also missing here. Thanks, Piotr

1 0

Re: wldap32: Remove superfluous const in ldap_init declarations.
by Hans Leidekker 30 Oct '15

30 Oct '15

On Sun, 2015-10-18 at 11:08 +0200, Thomas Faber wrote: > diff --git a/dlls/wldap32/winldap_private.h b/dlls/wldap32/winldap_private.h > index a19ceb1..8596d1d 100644 > --- a/dlls/wldap32/winldap_private.h > +++ b/dlls/wldap32/winldap_private.h > @@ -361,8 +361,8 @@ PCHAR * CDECL ldap_get_valuesA(WLDAP32_LDAP*,WLDAP32_LDAPMessage*,PCHAR); > PWCHAR * CDECL ldap_get_valuesW(WLDAP32_LDAP*,WLDAP32_LDAPMessage*,PWCHAR); > PBERVAL * CDECL ldap_get_values_lenA(WLDAP32_LDAP*,WLDAP32_LDAPMessage*,PCHAR); > PBERVAL * CDECL ldap_get_values_lenW(WLDAP32_LDAP*,WLDAP32_LDAPMessage*,PWCHAR); > -WLDAP32_LDAP * CDECL ldap_initA(const PCHAR,ULONG); > -WLDAP32_LDAP * CDECL ldap_initW(const PWCHAR,ULONG); > +WLDAP32_LDAP * CDECL ldap_initA(PCHAR,ULONG); > +WLDAP32_LDAP * CDECL ldap_initW(PWCHAR,ULONG); You should make the implementation match the prototype instead.

3 4

Re: d3d8types.h: Convert the D3DVSD_...SHIFT constants to unsigned.
by Gerald Pfeifer 30 Oct '15

30 Oct '15

On Sat, 24 Oct 2015, Gerald Pfeifer wrote: > This avoids potential shift overflows. I only should be necessary > for D3DVSD_TOKENTYPESHIFT, but it makes sense to have this consistent. Correction, this per se does not avoid shift overflows, I sent an older patch. It still may make sense to apply (please advise), but we'd need a different change in addition. I'll have a look. Gerald

2 2

Re: [PATCH] xmllite/tests: Fix memory leak (valgrind)
by Nikolay Sivov 30 Oct '15

30 Oct '15

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: [PATCH] msctf/tests: Fix memory leaks (valgrind)
by Marvin 30 Oct '15

30 Oct '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=17842 Your paranoid android. === w1064 (32 bit inputprocessor) === inputprocessor.c:791: Test failed: Deactivation came unexpectedly

1 0

Re: [PATCH 1/3] msctf: Add ITfThreadMgrEx stub.
by Alistair Leslie-Hughes 29 Oct '15

29 Oct '15

Hi Matteo, On 29/10/15 08:27, Matteo Bruni wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > This avoids a crash on exit with World of Warships when the OS version > is set to Windows 7. > > dlls/msctf/threadmgr.c | 145 ++++++++++++++++++++++++++++--------------------- > include/msctf.idl | 14 +++++ > 2 files changed, 96 insertions(+), 63 deletions(-) Can you please provide tests? Best Regards Alistair Leslie-Hughes

2 1

Re: [PATCH 2/5] winepulse: Add format and period probing
by Andrew Eikum 29 Oct '15

29 Oct '15

On Tue, Oct 20, 2015 at 12:15:22PM +0900, Alexandre Julliard wrote: > Andrew Eikum <aeikum(a)codeweavers.com> writes: > > > Hm, it works here whether PA is running or not. What's your setup? PA > > is obviously installed. Is it running? What version do you have > > installed? Can you give me a +devenum,+mmdevapi,+pulse,+alsa,+tid,+seh > > log? > > Version 7.0, it's running AFAICT. Log is attached. Note that this is > with only the first patch applied, it also crashes (but not always which > is why I missed it at first). Other sound tests crash as well. > This was seen in my patchset, and not in wine-staging, because we unload the pulse driver after it returns Low priority which is lower than winealsa's Preferred priority. Winepulse misbehaved when it was unloaded. In wine-staging, the Pulse driver is always Preferred and so would never be unloaded. I believe the crash happened because the DLL would be unloaded while the PA mainloop thread was still running. DllMain does call pa_mainloop_quit, but doesn't wait for the thread to actually exit. The mainloop thread would occasionally trigger a callback after the module has been unloaded, before acknowledging the quit status. This is why you didn't always see the crash. This has been remedied in the latest patchset. We now wait for the thread to quit in DllMain, see patch 3/5. Andrew

1 0

Re: [PATCH 3/3] msvcp120: implement _Thrd_create/join
by Piotr Caban 29 Oct '15

29 Oct '15

On 10/29/15 15:50, Daniel Lehman wrote: > +int __cdecl _Thrd_join(_Thrd_t thr, int *unk) > +{ > + DWORD ret; > + > + TRACE("(%p %u %p)\n", thr.hnd, thr.id, unk); > + ret = WaitForSingleObject(thr.hnd, INFINITE); > + if (unk) > + GetExitCodeThread(thr.hnd, (DWORD *)unk); Please rename the unk parameter. You already know that it's a thread exit code. You should probably also exit earlier if WaitForSingleObject fails. It doesn't really make sense call GetExitCodeThread in this case. Probably there's also no need to close the handle if WaitForSingleObject fails. Thanks, Piotr

1 0

Re: [PATCH 04/4] msvcp120/tests: Add tests of tr2_sys__Open_dir, tr2_sys__Read_dir and tr2_sys__Close_dir.(try4)
by Marvin 29 Oct '15

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

1 0

Re: [PATCH 3/3] msvcp120: implement _Thrd_create/join
by Marvin 29 Oct '15

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

1 0

Re: [PATCH 2/3] msvcp120: implement _Thrd_current
by Marvin 29 Oct '15

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

1 0

Re: [PATCH 1/3] msvcp120: implement _Thrd_sleep/yield
by Marvin 29 Oct '15

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

1 0

Re: [PATCH 3/3] wined3d: Cleanup extension check for shader model 4 support.
by Henri Verbeet 29 Oct '15

29 Oct '15

On 28 October 2015 at 22:27, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - if (gl_info->supported[EXT_GPU_SHADER4] && gl_info->supported[ARB_SHADER_BIT_ENCODING] > - && gl_info->supported[ARB_GEOMETRY_SHADER4] && gl_info->glsl_version >= MAKEDWORD_VERSION(1, 50) > - && gl_info->supported[ARB_DRAW_ELEMENTS_BASE_VERTEX] && gl_info->supported[ARB_DRAW_INSTANCED] > - && gl_info->supported[ARB_TEXTURE_RG] && gl_info->supported[ARB_SAMPLER_OBJECTS]) > + if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 50) && gl_info->supported[ARB_SHADER_BIT_ENCODING] > + && gl_info->supported[ARB_SAMPLER_OBJECTS]) Dropping EXT_gpu_shader4 is fine. Does GLSL 1.50 imply all the other extensions you're dropping here? They're not strictly required for compiling SM4 shaders, but they are for d3d10+ features like e.g. geometry shaders and instanced draws.

2 1

Re: [PATCH 6/6] kernel32/tests: Add tests for GetConsoleFontSize (v2, resend)
by Marvin 29 Oct '15

29 Oct '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=17811 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

1 0

Re: [PATCH 1/6] wineconsole: Add if check to determine whether a font attribute has changed (v2)
by Dmitry Timoshkov 29 Oct '15

29 Oct '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > + if (strcmpW(data->curcfg.face_name, cfg->face_name) || data->curcfg.cell_width != cfg->cell_width || > + data->curcfg.cell_height != cfg->cell_height || data->curcfg.font_weight != cfg->font_weight) > { > data->fnSetFont(data, cfg->face_name, cfg->cell_height, cfg->font_weight); > } Font names should be tested using a case insensitive check. -- Dmitry.

2 2

Re: [PATCH 6/6] kernel32/tests: Add tests for GetConsoleFontSize (v2, resend)
by Marvin 29 Oct '15

29 Oct '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=17809 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

2 1

Re: [PATCH] ucrtbase: Implement vsscanf
by Piotr Caban 29 Oct '15

29 Oct '15

On 10/28/15 09:54, Martin Storsjo wrote: > +/********************************************************************* > + * _snscanf_s_l (MSVCRT.@) > + */ > +int CDECL MSVCRT__stdio_common_vsscanf(unsigned __int64 options, const char *input, MSVCRT_size_t length, const char *format, MSVCRT__locale_t locale, __ms_va_list valist) > +{ > + return MSVCRT_vsnscanf_l(input, length, format, locale, valist); > +} Shouldn't this function also print some message about ignored options argument? Thanks, Piotr

2 3

Re: [PATCH] shell32: Stop memory leak (valgrind)
by Nikolay Sivov 29 Oct '15

29 Oct '15

On 29.10.2015 12:21, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/shell32/shellitem.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/shell32/shellitem.c b/dlls/shell32/shellitem.c > index f64c2d0..799c6c0 100644 > --- a/dlls/shell32/shellitem.c > +++ b/dlls/shell32/shellitem.c > @@ -1198,7 +1198,10 @@ HRESULT WINAPI SHCreateShellItemArray(PCIDLIST_ABSOLUTE pidlParent, > { > ret = create_shellitemarray(array, cidl, ppsiItemArray); > if(SUCCEEDED(ret)) > + { > + HeapFree(GetProcessHeap(), 0, array); > return ret; > + } > } > > /* Something failed, clean up. */ > There is another place with same problem, I just sent a complete fix.

1 0

Re: [PATCH 1/6] wineconsole: Add if check to determine whether a font attribute has changed
by Sebastian Lackner 29 Oct '15

29 Oct '15

On 28.10.2015 09:40, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/wineconsole/wineconsole.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/programs/wineconsole/wineconsole.c b/programs/wineconsole/wineconsole.c > index e1ee55b..c8e68c1 100644 > --- a/programs/wineconsole/wineconsole.c > +++ b/programs/wineconsole/wineconsole.c > @@ -421,7 +421,8 @@ void WINECON_SetConfig(struct inner_data* data, const struct config_data* cf > } > data->curcfg.menu_mask = cfg->menu_mask; > data->curcfg.quick_edit = cfg->quick_edit; > - if (1 /* FIXME: font info has changed */) > + if (data->curcfg.face_name != cfg->face_name || data->curcfg.cell_width != cfg->cell_width || > + data->curcfg.cell_height != cfg->cell_height || data->curcfg.font_weight != cfg->font_weight) > { > data->fnSetFont(data, cfg->face_name, cfg->cell_height, cfg->font_weight); > } > It doesn't make sense to compare face_name pointer, this condition will always be true.

2 1

Re: [3/4] gdiplus: Use helper function for HeapReAlloc calls.
by Alexandre Julliard 29 Oct '15

29 Oct '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -420,12 +420,10 @@ BOOL lengthen_path(GpPath *path, INT len) > while(path->datalen - path->pathdata.Count < len) > path->datalen *= 2; > > - path->pathdata.Points = HeapReAlloc(GetProcessHeap(), 0, > - path->pathdata.Points, path->datalen * sizeof(PointF)); > + path->pathdata.Points = heap_realloc(path->pathdata.Points, path->datalen * sizeof(PointF)); > if(!path->pathdata.Points) return FALSE; > > - path->pathdata.Types = HeapReAlloc(GetProcessHeap(), 0, > - path->pathdata.Types, path->datalen); > + path->pathdata.Types = heap_realloc(path->pathdata.Types, path->datalen); > if(!path->pathdata.Types) return FALSE; > } It's not directly related to your change, but as a follow-up patch, it would be nice to fix this to correctly handle allocation failures. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/2] wined3d: make wined3d_device_copy_sub_resource_region return an error code
by Stefan Dösinger 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-28 um 15:31 schrieb Riccardo Bortolato: > - if (src_resource->type != dst_resource->type) > - { > - WARN("Resource types (%s / %s) don't match.\n", > - debug_d3dresourcetype(dst_resource->type), > - debug_d3dresourcetype(src_resource->type)); > - return; > + return WINED3DERR_INVALIDCALL; > } This seems like something that should be its own patch. Did you check if a 2D texture -> cube texture copy works, both on Windows (are we required to support it) and in the current implementation? > - if (dst_resource->type != WINED3D_RTYPE_TEXTURE) > + if (dst_resource->type == WINED3D_RTYPE_VOLUME_TEXTURE > + || src_resource->type == WINED3D_RTYPE_VOLUME_TEXTURE) > { I guess your intention is to avoid having a type == TEXTURE || type == CUBE_TEXTURE kind of construct, but technically you'd also have to check for WINED3D_RTYPE_BUFFER. I'd prefer whitelisting known good resource types. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWMOWUAAoJEN0/YqbEcdMwwIsP/3MU73JRdCfxlLTwi7XANeoB w43lxvtcF1N/ZqCsTaGcXB0cln121cDeg5mlSeT4AQMIgc0glOTIKDRRKQ4RMpeE YtXtc9uWp+2oqJ1oXJchCnYEfbdAlNUqqWrgOO1o/4YmknHTjLI4lR5Xore/YFlG pVT9pzrQzK/FFNkJV7mJaW1Vya2jtHxzGt1v/PiDYPjOUo6hODj7L1razouvf5wS xrZAU3SfnlrRZ+SyEWnSQehniN6CH0Nn1Gp7YsThIvSS8KH5kuAtfTY0UGtda/DU 8cb2jJZ3EevrQFIr+kC7Y0EDvMSdjf2dYo1eOc10AYjeF+4cYOTbo+v+n/wkPdy+ 2leDdfggxl8ynb1NzvqoBuZArhyj2lvEG3LBloNOWczAwR1dc/RXpUO84zpLPVLS H9KGyFx5atJUJHvqA8AexRTPAHJ6I8hI8mXEatQwbfGNLd6Erq/tfcKJzAB9SQeE XTE9GkGMP+D8bAp88AwTPDznVva3KxLpHlEK4KS6XPJZRw5JxvaxOz1zLilXNwLu GdCwauQlYTtxg+fJFKWw85udF/tvXw6nF+MkK4xrs37D08kf98GPXnFln1NPCLvd aPQutjmZlLehLcbk3GmFFEuRy2D8vt48nfCltfMIXe03sql+GiNK8SqnQ151+as2 u1oVePmmJt89kdM+hQk/ =gsHT -----END PGP SIGNATURE-----

2 1

Re: msasn1: implement ASN1_CreateModule
by Nikolay Sivov 28 Oct '15

28 Oct '15

On 27.10.2015 23:10, Austin English wrote: > This is based on code from the FreeRDP project, used with permission > of the author, Marc-André Moreau <marcandre.moreau(a)gmail.com> Do you plan to reuse more from there? Is it clean license-wise? And more importantly, how did FreeRDP project came up with that implementation? > > For https://bugs.winehq.org/show_bug.cgi?id=38020 > > + > +ASN1module_t WINAPI ASN1_CreateModule(ASN1uint32_t version, ASN1encodingrule_e rule, ASN1uint32_t flags, ASN1uint32_t pdu, const ASN1GenericFun_t encoder[], const ASN1GenericFun_t decoder[], const ASN1FreeFun_t freememory[], const ASN1uint32_t size[], ASN1magic_t modulename) arg[] notation seems redundant, *arg is cleaner and more common for Wine. > + ASN1module_t module = NULL; No need to init this. > + if (!((encoder) && (decoder) && (freememory) && (size))) > + return NULL; ... > + module = (ASN1module_t) malloc(sizeof(struct tagASN1module_t)); > + ZeroMemory(module, sizeof(struct tagASN1module_t)); Heap* API please. And you don't need to zero-init it, or use tag* names. All structures seem to be documented well, what's a reason to reuse simple parts like such structure allocations? Can this be tested by directly calling ASN1_* functions? If yes, simple test would be nice to have.

3 2

Re: [v3 signed 1/6] d3d9: improved d3d9_device_UpdateSurface
by Henri Verbeet 28 Oct '15

28 Oct '15

On 22 October 2015 at 12:01, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > enabled previously failing test in device.c > removed wined3d_device_update_surface from wined3d and replaced its usage with surface_upload_from_surface. > This was mentioned in the discussion in the other thread, but just for the record, the options are either wined3d_device_update_sub_resource() or wined3d_device_copy_sub_resource_region().

2 5

Re: mshtml: Fixed more test failures on win10.
by Marvin 28 Oct '15

28 Oct '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=17770 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3569: Test failed: unexpected call IsErrorUrl

1 0

Re: [PATCH] vbscript/tests: Show IActiveScriptSite OnScriptError is called on error
by Jacek Caban 28 Oct '15

28 Oct '15

Hi Alistair, On 10/26/15 09:56, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/vbscript/tests/run.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 46 insertions(+), 1 deletion(-) > > diff --git a/dlls/vbscript/tests/run.c b/dlls/vbscript/tests/run.c > index a86711a..e625136 100644 > --- a/dlls/vbscript/tests/run.c > +++ b/dlls/vbscript/tests/run.c > @@ -100,6 +100,7 @@ DEFINE_EXPECT(Next); > DEFINE_EXPECT(GetWindow); > DEFINE_EXPECT(GetUIBehavior); > DEFINE_EXPECT(EnableModeless); > +DEFINE_EXPECT(on_script_error); Please use OnScriptError for consistency. > #define DISPID_GLOBAL_REPORTSUCCESS 1000 > #define DISPID_GLOBAL_TRACE 1001 > @@ -138,6 +139,7 @@ static const char *test_name = "(null)"; > static int test_counter; > static SCRIPTUICHANDLING uic_handling = SCRIPTUICHANDLING_NOUIERROR; > static IDispatchEx testObj; > +static BOOL overwrite_return = FALSE; How about using HRESULT here... > static BSTR a2bstr(const char *str) > { > @@ -1623,7 +1625,22 @@ static HRESULT WINAPI ActiveScriptSite_OnStateChange(IActiveScriptSite *iface, S > > static HRESULT WINAPI ActiveScriptSite_OnScriptError(IActiveScriptSite *iface, IActiveScriptError *pscripterror) > { > - return E_NOTIMPL; > + HRESULT hr; > + EXCEPINFO ei = {0}; > + > + CHECK_EXPECT(on_script_error); > + > + hr = IActiveScriptError_GetExceptionInfo(pscripterror, &ei); > + ok(hr == S_OK, "GetExceptionInfo %x\n", hr); > + > + if(overwrite_return) > + { > + overwrite_return = FALSE; > + return S_OK; > + } > + > + /* We return the EXCEPINFO error since returning S_OK means we have handled the error */ > + return ei.scode; ... and return it here for simplicity? Thanks, Jacek

2 3

Re: [PATCH 3/3] rpcrt4: Added RpcMgmtIsServerListening tests.
by Marvin 28 Oct '15

28 Oct '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=17748 Your paranoid android. === w8 (32 bit server) === server.c:984: Test failed: get_ranged_enum() returned 1997799427 instead of RE3 === w864 (32 bit server) === server.c:984: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:984: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 server.c:984: Test failed: get_ranged_enum() returned 2009071619 instead of RE3 === w864 (64 bit server) === server.c:984: Test failed: get_ranged_enum() returned 184549379 instead of RE3 === w1064 (64 bit server) === server.c:984: Test failed: get_ranged_enum() returned 2883587 instead of RE3 server.c:984: Test failed: get_ranged_enum() returned 5767171 instead of RE3

2 1

Re: [PATCH] comctl32/listview: Fix printf format (PVS-Studio)
by Alexandre Julliard 28 Oct '15

28 Oct '15

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -587,7 +587,7 @@ static const char* debugscrollinfo(const SCROLLINFO *pScrollInfo) > int len, size = DEBUG_BUFFER_SIZE; > > if (pScrollInfo == NULL) return "(null)"; > - len = snprintf(buf, size, "{cbSize=%d, ", pScrollInfo->cbSize); > + len = snprintf(buf, size, "{cbSize=%u, ", pScrollInfo->cbSize); That doesn't seem very necessary. I don't mind a few fixes like that, but I'm concerned that there would be a million of them. How many do you expect? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: dhcpcsvc: add a stub for DhcpRequestParams (try 3)
by Matteo Bruni 28 Oct '15

28 Oct '15

2015-10-27 17:28 GMT+01:00 Austin English <austinenglish(a)gmail.com>: +typedef struct _DHCPAPI_PARAMS_ARRAY That is typoed as "ARARAY" in the header from MS (the one from the 8.1 SDK at least), so this probably needs the same treatment. The "Params" field has additional stuff for the midl case, not sure we care about that though.

1 0

Re: kernel32/tests: Simplify an ok() condition (PVS-Studio)
by Marvin 28 Oct '15

28 Oct '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=17766 Your paranoid android. === wxppro (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1553: test_AbortWaitCts timeout 500 handle 00000770 comm.c:1520: Changing CommMask on the fly for handle 00000770 after timeout 500 === w2003std (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1553: test_AbortWaitCts timeout 500 handle 00000760 comm.c:1520: Changing CommMask on the fly for handle 00000760 after timeout 500 === w2008s64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1553: test_AbortWaitCts timeout 500 handle 000000BC comm.c:1520: Changing CommMask on the fly for handle 000000BC after timeout 500 === w7pro64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1514 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1514 ms for waiting comm.c:1553: test_AbortWaitCts timeout 500 handle 00000128 comm.c:1520: Changing CommMask on the fly for handle 00000128 after timeout 500 === wvistau64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1514 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1514 ms for waiting === w7pro64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1514 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1514 ms for waiting

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel