- wine-devel - winehq.org

Ignored WineTest report
by Francois Gouget 05 Oct '15

05 Oct '15

My FreeBSD 7.0 VM sent the following report: http://fgouget.free.fr/tmp/winebot-fg-freebsd70-vm.report However that report was ignored and I have no idea why. The report is under 1.5MB and has only 44 failures. So why is it being ignored? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

2 5

Re: [PATCH 6/7] wined3d: Avoid reading uninitialized texcoord varyings in FFP replacement fragment shaders.
by Henri Verbeet 05 Oct '15

05 Oct '15

On 2 October 2015 at 14:54, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - unsigned char padding; > + unsigned char pointsprite : 1; > + unsigned char padding : 7; > + unsigned int inited_texcoords; > }; Did you perhaps mean something like "initialized_texcoords" or "texcoords_initialized"?

2 2

Re: [PATCH 1/7] wined3d: Avoid the deprecated syntax for SM3 varyings on core profile.
by Henri Verbeet 05 Oct '15

05 Oct '15

On 2 October 2015 at 14:54, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void PRINTF_ATTR(4, 5) declare_in_varying(const struct wined3d_gl_info *gl_info, > + struct wined3d_string_buffer *buffer, BOOL flat, const char *format, ...) It's not a huge issue, but generally speaking things are more readable on the caller side when you use a flag or enum instead of a BOOL. I.e., "declare_in_varying(..., TRUE, ...);" vs. e.g. "declare_in_varying(..., WINED3D_GLSL_INTERPOLATE_FLAT, ...);".

1 0

Re: [PATCH 5/9] d3d11: Implement {d3d10, d3d11}_geometry_shader_GetDevice().
by Henri Verbeet 05 Oct '15

05 Oct '15

For what it's worth, the original reason geometry shaders and input layouts don't have a GetDevice() implementation was that it was a bit harder to add test coverage for them than for the rest of the interfaces. It's probably easy enough now, so please add some geometry shader coverage to test_create_shader(). You can probably use the shader from test_clear_state().

1 0

Re: crypt32/tests: Delete WineTest registry key when tests are complete
by Marvin 05 Oct '15

05 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=17004 Your paranoid android. === w864 (64 bit store) === store.c:2603: Test failed: CertAddCertificateContextToStore failed store.c:2604: Test failed: Unexpected cert3 store: unhandled exception c0000005 at 000000000044DAD6

2 1

Re: [PATCH 1/5] ddraw/tests: Don't skip d3d1-2 tests if DirectDrawCreateEx isn't present
by Marvin 05 Oct '15

05 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=17003 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2334: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2518: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2665: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [2/2] widl: Fix generation of a typelib for winhttp.
by Huw Davies 05 Oct '15

05 Oct '15

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.

3 8

Re: [PATCH 5/5] ddraw: Enumerate the correct Direct3D devices in the correct order
by Marvin 04 Oct '15

04 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=16988 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2428: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2428: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2612: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2759: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2759: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 4/5] ddraw: Accept all 3 versions of D3DFINDDEVICERESULT
by Marvin 04 Oct '15

04 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=16987 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2367: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2367: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2551: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2698: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2698: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 3/5] ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest
by Marvin 04 Oct '15

04 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=16986 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2360: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2544: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2691: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 3/5] ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest
by Marvin 04 Oct '15

04 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=16985 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2360: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2544: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2691: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 2/5] ddraw/tests: Add Direct3D3 test section
by Marvin 04 Oct '15

04 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=16984 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2353: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2537: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2684: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: ntdll: Work around a conflict between Wine and Solaris list.h.
by André Hentschel 04 Oct '15

04 Oct '15

Am 04.10.2015 um 16:32 schrieb Francois Gouget: > + * This need to be workaround it here. Hi Francois, I'm not a native speaker, but this sounds strange. Same for the original commit from 2008

2 1

Re: [PATCH 3/5] ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest
by Marvin 04 Oct '15

04 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=16983 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2360: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2360: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2544: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2691: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2691: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 2/5] ddraw/tests: Add Direct3D3 test section
by Marvin 04 Oct '15

04 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=16982 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2353: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2353: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2537: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2684: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2684: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [PATCH 1/5] ddraw/tests: Don't skip d3d1-2 tests if DirectDrawCreateEx isn't present
by Marvin 04 Oct '15

04 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=16981 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2334: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2334: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2518: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2665: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2665: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: [2/2 v4 resend] winex11.drv: Implement FlashWindowEx.
by André Hentschel 04 Oct '15

04 Oct '15

Am 03.10.2015 um 05:39 schrieb Jactry Zeng: > Superseded patch 114739. > > ChangeLog: > v4: > - Rename driver entry to FlashWindowEx; > - Put FlashWindowEx/pFlashWindowEx in right place; > - Add CDECL for X11DRV_FlashWindowEx. > v3: > - Use x11drv_atom instead of XInternAtom; > - Only do XSendEvent() when data->mapped is true. > v2: > - Use _NET_WM_STATE_DEMANDS_ATTENTION instead of Urgency. > Hi, I haven't looked closer, but normally the implementation should be in the Ex-function and the non-Ex-function should call the Ex-function. In this patch you do Ex->non-Ex->Ex which looks strange.

2 1

Re: [PATCH 4/5] ws2_32: Add support for TransmitFile headers and footers.
by Marvin 03 Oct '15

03 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=16975 Your paranoid android. === w7pro64 (32 bit sock) === sock.c:7324: Test failed: bytesReturned isn't supposed to be 1 sock.c:7370: Test failed: Waiting for timeout failed with 0 + errno 997

2 1

Re: [3/4] psapi/tests: Adjust margin for win10
by Marvin 03 Oct '15

03 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=16971 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:627: Test failed: wrong length 3 psapi_main.c:643: Test failed: wrong length 3 === w1064 (64 bit psapi_main) === psapi_main.c:627: Test failed: wrong length 3 psapi_main.c:643: Test failed: wrong length 3

1 0

Re: [2/4] psapi/tests: Remove bad test
by Marvin 03 Oct '15

03 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=16970 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:627: Test failed: wrong length 3 psapi_main.c:643: Test failed: wrong length 3 === w1064 (64 bit psapi_main) === psapi_main.c:627: Test failed: wrong length 3 psapi_main.c:643: Test failed: wrong length 3

1 0

Re: [1/4] psapi/tests: Disable tests which crash on win10
by Marvin 03 Oct '15

03 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=16969 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 psapi_main.c:660: Test failed: wrong length 3 === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 psapi_main.c:660: Test failed: wrong length 3

1 0

Re: [PATCH 1/2] reg: simplify root key search
by Stefan Dösinger 03 Oct '15

03 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks, this time the patches apply OK for me. I've told Alexandre that the patches look OK to me, let's see what he says. Cheers, Stefan Am 2015-09-03 um 21:51 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > --- > programs/reg/reg.c | 85 +++++++++++++++++++++++++++--------------------------- > 1 file changed, 43 insertions(+), 42 deletions(-) > > diff --git a/programs/reg/reg.c b/programs/reg/reg.c > index 4ec25bc..0f28b63 100644 > --- a/programs/reg/reg.c > +++ b/programs/reg/reg.c > @@ -22,6 +22,32 @@ > > #define ARRAY_SIZE(A) (sizeof(A)/sizeof(*A)) > > +static const WCHAR short_hklm[] = {'H','K','L','M',0}; > +static const WCHAR short_hkcu[] = {'H','K','C','U',0}; > +static const WCHAR short_hkcr[] = {'H','K','C','R',0}; > +static const WCHAR short_hku[] = {'H','K','U',0}; > +static const WCHAR short_hkcc[] = {'H','K','C','C',0}; > +static const WCHAR long_hklm[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > +static const WCHAR long_hkcu[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > +static const WCHAR long_hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > +static const WCHAR long_hku[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > +static const WCHAR long_hkcc[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > + > +static const struct > +{ > + HKEY key; > + const WCHAR *short_name; > + const WCHAR *long_name; > +} > +root_rels[] = > +{ > + {HKEY_LOCAL_MACHINE, short_hklm, long_hklm}, > + {HKEY_CURRENT_USER, short_hkcu, long_hkcu}, > + {HKEY_CLASSES_ROOT, short_hkcr, long_hkcr}, > + {HKEY_USERS, short_hku, long_hku}, > + {HKEY_CURRENT_CONFIG, short_hkcc, long_hkcc}, > +}; > + > static const WCHAR type_none[] = {'R','E','G','_','N','O','N','E',0}; > static const WCHAR type_sz[] = {'R','E','G','_','S','Z',0}; > static const WCHAR type_expand_sz[] = {'R','E','G','_','E','X','P','A','N','D','_','S','Z',0}; > @@ -95,51 +121,26 @@ static int reg_message(int msg) > return reg_printfW(formatW, msg_buffer); > } > > -static int reg_StrCmpNIW(LPCWSTR str, LPCWSTR comp, int len) > +static inline BOOL path_rootname_cmp(const WCHAR *input_path, const WCHAR *rootkey_name) > { > - int i; > + DWORD length = strlenW(rootkey_name); > > - for (i = 0; i < len; i++) > - { > - if (!str[i]) > - { > - len = i + 1; > - break; > - } > - } > - > - return CompareStringW(CP_ACP, NORM_IGNORECASE, str, len, comp, len) - CSTR_EQUAL; > + return (!strncmpiW(input_path, rootkey_name, length) && > + (input_path[length] == 0 || input_path[length] == '\\')); > } > > -static HKEY get_rootkey(LPWSTR key) > +static HKEY path_get_rootkey(const WCHAR *path) > { > - static const WCHAR szHKLM[] = {'H','K','L','M',0}; > - static const WCHAR szHKEY_LOCAL_MACHINE[] = {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N','E',0}; > - static const WCHAR szHKCU[] = {'H','K','C','U',0}; > - static const WCHAR szHKEY_CURRENT_USER[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > - static const WCHAR szHKCR[] = {'H','K','C','R',0}; > - static const WCHAR szHKEY_CLASSES_ROOT[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > - static const WCHAR szHKU[] = {'H','K','U',0}; > - static const WCHAR szHKEY_USERS[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > - static const WCHAR szHKCC[] = {'H','K','C','C',0}; > - static const WCHAR szHKEY_CURRENT_CONFIG[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F','I','G',0}; > - > - if (!reg_StrCmpNIW(key, szHKLM, 4) || > - !reg_StrCmpNIW(key, szHKEY_LOCAL_MACHINE, 18)) > - return HKEY_LOCAL_MACHINE; > - else if (!reg_StrCmpNIW(key, szHKCU, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_USER, 17)) > - return HKEY_CURRENT_USER; > - else if (!reg_StrCmpNIW(key, szHKCR, 4) || > - !reg_StrCmpNIW(key, szHKEY_CLASSES_ROOT, 17)) > - return HKEY_CLASSES_ROOT; > - else if (!reg_StrCmpNIW(key, szHKU, 3) || > - !reg_StrCmpNIW(key, szHKEY_USERS, 10)) > - return HKEY_USERS; > - else if (!reg_StrCmpNIW(key, szHKCC, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_CONFIG, 19)) > - return HKEY_CURRENT_CONFIG; > - else return NULL; > + DWORD i; > + > + for (i = 0; i < ARRAY_SIZE(root_rels); i++) > + { > + if (path_rootname_cmp(path, root_rels[i].short_name) || > + path_rootname_cmp(path, root_rels[i].long_name)) > + return root_rels[i].key; > + } > + > + return NULL; > } > > static DWORD wchar_get_type(const WCHAR *type_name) > @@ -237,7 +238,7 @@ static int reg_add(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > @@ -307,7 +308,7 @@ static int reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > } > p++; > > - root = get_rootkey(key_name); > + root = path_get_rootkey(key_name); > if (!root) > { > reg_message(STRING_INVALID_KEY); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6XG1AAoJEN0/YqbEcdMwWysP/0BvR0rXG67sd/NC5pPItrVv R2bGZceGH8yJpBuYOxpp2W5p9sCRMfoc2giTXrhmvUwVrutXrUbI9c/SqOlLZL6I YLOObNIo/DI6MxBwGaZ2jKGJKWEW3kzg5qKkJWzPIMg92zfbgtQxiTxhvAvd1xaR MxXLzKt+mhMWjPwyFR3omSFCTkvTguWxnXIVEf2S6TRshJnI0A10vJQUj1AC4dsX ZnHZkuXOAgwzgzmvkEnxbNsgkRzqmXCZaUbapcgJ5TXwwuiLMr4AuPbEcYmdf2g+ CqIYeIUYVtbg3pga/9WFdSki0YaAcJJ7kYTt5lEYRN3/V93W6QsPp/SaUXyx1J1B UOCbuj1UNx8OvRRvmABLrTvgbUQMrjlDXPP9QeNBHe8xQCQ1iV/AJ02DdbLrRleJ a/+CgisljGNzuH6Mu+5bKoKAEyEV3KAF3CIz6dJyBB5KQRY6Rk5AZMhWSQAhkJke ICBh+ITIBWYCsm+NDF+RuYutXhtstxvbewRHmwg4KnF2ouOTtQ2ypV+N2Z9JLNQ8 I25+6YB+1WDuDKYa87MPzbac6DX5IyzIPKiGsvLBngMiUcpfSDj6mgJTS4DkTwSM O+JYL5v8x7TIOmxKLGUfXXnvA+aiZ29/nrlLrZY8QoKLvHvpAxOz/SjUhDZa02IC twXso6DreRFxb4DyflTj =BizJ -----END PGP SIGNATURE-----

2 4

Re: [1/2 v2 resend] user32: Implement semi-stub for FlashWindowEx.
by Marvin 03 Oct '15

03 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=16960 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 0003014E message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: [1/2 v2] user32: Implement semi-stub for FlashWindowEx.
by Ken Thomases 03 Oct '15

03 Oct '15

On Oct 2, 2015, at 2:59 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > + return FlashWindow( pfwi->hwnd, pwfi->dwFlags ); This has a typo. "pwfi" should be "pfwi". You've fixed it in the next patch, which is why it compiles for you, but you have to not introduce it in the first place. :) -Ken

3 2

What is the monetary value of Wine ?
by Tom Wickline 02 Oct '15

02 Oct '15

I just wrote a little article on the monetary value of WineHQ, if any of you guys and gals are interested to read it it's located here : http://www.wine-reviews.net/2015/10/the-glass-of-wine-thats-worth-350.html Cheers, Tom

1 0

Re: [7/9] msvcirt: Implement stdiobuf::setrwbuf
by Piotr Caban 02 Oct '15

02 Oct '15

On 10/02/15 15:03, Iván Matellanes wrote: > + if (buffer_size < 0) > + return 0; > + if (read_size == 0 && write_size == 0) { > + this->base.unbuffered = 1; > + return 0; > + } Something like this makes more sense (and matches Windows 7 behavior): if (read_size < 0 || write_size < 0) return 0; if (!buffer_size) { this->base.unbuffered = 1; return 0; } Thanks, Piotr

1 0

Re: wininet: Set Content-Length header to zero if the verb is CONNECT.
by Marvin 02 Oct '15

02 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=16948 Your paranoid android. === w7u (32 bit http) === http.c:5841: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5847: Test failed: HttpQueryInfoA failed 12019 http.c:5848: Test failed: header missing === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2408: Test failed: count was wrong http.c:2409: Test failed: http data wrong, got: Garbage: Header http.c:3072: Test failed: HttpAddRequestHeaders succeeded http.c:3073: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2408: Test failed: count was wrong http.c:2409: Test failed: http data wrong, got: Garbage: Header http.c:3072: Test failed: HttpAddRequestHeaders succeeded http.c:3073: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Wine tests not checking permissions
by Francois Gouget 02 Oct '15

02 Oct '15

A number of tests fail if they are not running as an administrator with elevated privileges. These tests should really check they have the needed permissions/privileges and skip if they don't. With Windows 2000 being decomissioned I repurposed it to allow testing running the tests in a regular user account (*) for developers interested in fixing these relatively easy test failures. Bug 39232 - setupapi:install fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39232 Bug 39231 - setupapi:devinst fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39231 Bug 39230 - odbccp32:misc fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39230 Bug 39222 - mstask:task_scheduler fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39222 Bug 39221 - msi:install fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39221 Bug 39218 - advpack:advpack fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39218 Bug 39213 - advapi32:security fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39213 Bug 39212 - cmd:batch fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39212 There's also these issues but they cannot be reproduced on that Windows 2000 VM: Bug 39237 - urlmon:sec_mgr fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39237 Bug 39238 - mscft:inputprocessor fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39238 Bug 39239 - ole32:compobj fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39239 Finally the issues below seem to only happen on Windows 2000 though I'm not really convinced that means the tests are right though. Bug 39233 - setupapi:misc crashes if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39233 Bug 39234 - setupapi:query fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39234 Bug 39235 - wintrust:crypt fails on Windows 2000 if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39235 Bug 39236 - shell32:shlfileop fails if privileges not high enough https://bugs.winehq.org/show_bug.cgi?id=39236 (*) More precisely Windows 2000 calls that a 'Restricted User Account'. It's an account where the user is not allowed to install applications. This is the sort of accounts that corporate desktops would be configured with. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.

1 1

Re: [PATCH v3] ucrtbase: Make the strtod implementation C99 compatible
by Martin Storsjö 02 Oct '15

02 Oct '15

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

2 1

Re: [1/2 v2] user32: Implement semi-stub for FlashWindowEx.
by Marvin 02 Oct '15

02 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=16936 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 00030114 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0006012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 win.c:8119: Test failed: msg.message = 31f win.c:8121: Test failed: pos = 008c0078 win.c:8138: Test failed: pos = 01400154 win.c:8140: Test failed: msg.message = 8000 win.c:8142: Test failed: pos = 014a015e win.c:8152: Test failed: msg.message = 8001 win.c:8154: Test failed: pos = 01540140 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 0000000000060100 message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: ntdll: Return STATUS_INVALID_DEVICE_REQUEST when calling NtReadFile on directory.
by Alexandre Julliard 02 Oct '15

02 Oct '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/ntdll/file.c | 2 +- > dlls/ntdll/tests/file.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index be6b591..e4370dc 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -444,7 +444,7 @@ NTSTATUS FILE_GetNtStatus(void) > case EACCES: return STATUS_ACCESS_DENIED; > case ENOTDIR: return STATUS_OBJECT_PATH_NOT_FOUND; > case ENOENT: return STATUS_OBJECT_NAME_NOT_FOUND; > - case EISDIR: return STATUS_FILE_IS_A_DIRECTORY; > + case EISDIR: return STATUS_INVALID_DEVICE_REQUEST; That's going to affect all file functions, not only NtReadFile. It would need more test cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes
by Stefan Dösinger 01 Oct '15

01 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. 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. For surfaces in d3d8 and d3d9 you have to make sure you're always creating a d3d8/9_texture struct for plain surfaces, but this is something you can change internally in d3d8/9. It doesn't matter too much for this patch because the volume API is pretty simple, but the next patch is pretty complicated because it changes all the stuff at once. It'll be terrible to bisect / fix if there are regressions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr 1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2 nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO 2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki otAB34aWZl2+f/socndA =6ndo -----END PGP SIGNATURE-----

3 4

Re: [PATCH 1/2 v2] msvcp: Add _Dscale implementation
by Marvin 01 Oct '15

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

2 1

opengl32: it does not compile well in CYGWIN and MINGW
by carlo.bramix＠libero.it 01 Oct '15

01 Oct '15

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 I hope that it could be committed because perhaps it does not make difference on platforms without dllexport/dllimport attribute support, but it does on real Windows. Thank you. Sincerely, Carlo

2 1

Wined3d wireframe rendering
by Bruno Jesus 01 Oct '15

01 Oct '15

Hi all, I know it may sound idiot as I have zero knowledge on 3d graphics but is it possible to make wined3d to not add textures to things resulting in a sort of wireframe renderer? The long and uninteresting background: I used to play a game called X-moto in 300Mhz Celeron Linux computer, in its standard rendering mode it was impossible to play the game due to low fps, but it had an awesome wireframe mode that played smoothly. So if this could be achieved globally by wined3d we could play new games on old computers (my overly noob conclusion about all this). Thanks in advance for any reply, Bruno

5 9

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2) (resend)
by Marvin 30 Sep '15

30 Sep '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=16918 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

libosmesa bitness
by André Hentschel 30 Sep '15

30 Sep '15

Hi, Does someone can tell which version of libosmesa Wine needs? You can build libosmesa for 8, 16 or 32 channel bits puk suspects we need the 42 bits version ;) 8 is the default and it seems to me we want that, so can someone confirm that?

1 0

Re: [PATCH] usp10/tests: fix some tests on Hebrew and Arabic locales
by Marvin 30 Sep '15

30 Sep '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=16916 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly
by Nikolay Sivov 30 Sep '15

30 Sep '15

On 30.09.2015 19:04, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > - status_c = pDeleteSecurityContext( &client.ctxt ); > - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + if (client.ctxt.dwLower || client.ctxt.dwUpper) > + { > + status_c = pDeleteSecurityContext( &client.ctxt ); > + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + } Why is this a problem only on macos?

2 1

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder
by Nikolay Sivov 30 Sep '15

30 Sep '15

On 30.09.2015 18:54, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/windowscodecs/tests/pngformat.c | 4 ++++ > 1 file changed, 4 insertions(+) > If this is about fixing macos failures, Vincent pointed out that there was a decision at some point to fix broken builds and not to workaround that in test code.

3 2

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.
by Ken Thomases 30 Sep '15

30 Sep '15

On Sep 30, 2015, at 2:53 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > dlls/user32/driver.c | 16 ++++++++++++++-- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 1 + > dlls/winex11.drv/window.c | 29 +++++++++++++++++++++++++++++ > dlls/winex11.drv/winex11.drv.spec | 1 + > dlls/winex11.drv/x11drv.h | 1 + > dlls/winex11.drv/x11drv_main.c | 1 + > 7 files changed, 48 insertions(+), 2 deletions(-) Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? -Ken

2 2

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)
by Piotr Caban 30 Sep '15

30 Sep '15

Hi, On 09/07/15 16:21, YongHao Hu wrote: > +/* ?_Open_dir@sys@tr2@std@@YAPAXAAY0BAE@DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir@sys@tr2@std@@YAPEAXAEAY0BAE@DPEBDAEAHAEAW4file_type@123@@Z */ > +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* err_code, enum file_type* type) > +{ > + HANDLE handle; > + WIN32_FIND_DATAA data; > + char temppath[MAX_PATH]; > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); > + strcpy(temppath, dest); > + strcat(temppath, "\\*.*"); Is native limiting the path to MAX_PATH characters? What happens if longer path is passed? > + handle = FindFirstFileA(temppath, &data); > + if(handle == INVALID_HANDLE_VALUE) { > + if(GetLastError() == ERROR_PATH_NOT_FOUND) > + *err_code = ERROR_BAD_PATHNAME; > + else > + *err_code = GetLastError(); This doesn't look right. Probably some other function is returning different error on windows and on wine (or different function is used internally). Anyway I don't think we need to be compatible here (at least as long as there's no application that depends on it). > + while(!strcmp(data.cFileName, ".") || !strcmp(data.cFileName, "..")) { > + if(!FindNextFileA(handle, &data)) { > + *err_code = ERROR_SUCCESS; > + *type = status_unknown; > + return NULL; You're leaking handle here. Thanks, Piotr

2 2

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.
by Marvin 30 Sep '15

30 Sep '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=16898 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban 29 Sep '15

29 Sep '15

On 09/21/15 15:08, Martin Storsjo wrote: > if(d>MSVCRT_UI64_MAX/10 || hlp<d) { Please also update overflow checking rules (use base instead of 10). > +static void test_strtod(void) > +{ > + test_strtod_str("infinity", INFINITY, 8); > + test_strtod_str("INFINITY", INFINITY, 8); > + test_strtod_str("InFiNiTy", INFINITY, 8); > + test_strtod_str("INF", INFINITY, 3); > + test_strtod_str("-inf", -INFINITY, 4); > + test_strtod_str("inf42", INFINITY, 3); > + test_strtod_str("inffoo", INFINITY, 3); > + test_strtod_str("infini", INFINITY, 3); > + > + test_strtod_str("NAN", NAN, 3); > + test_strtod_str("nan", NAN, 3); > + test_strtod_str("NaN", NAN, 3); > + > + test_strtod_str("0x42", 66, 4); > + test_strtod_str("0X42", 66, 4); > + test_strtod_str("-0x42", -66, 5); > + test_strtod_str("0x1p1", 2, 5); > + test_strtod_str("0x1P1", 2, 5); > + test_strtod_str("0x1p+1", 2, 6); > + test_strtod_str("0x2p-1", 1, 6); > + test_strtod_str("0xA", 10, 3); > + test_strtod_str("0xa", 10, 3); > + test_strtod_str("0xABCDEF", 11259375, 8); > + test_strtod_str("0Xabcdef", 11259375, 8); > + > + test_strtod_str("0x1.1", 1.0625, 5); > + test_strtod_str("0x1.1p1", 2.125, 7); Could you please also add few more tests, like: test_strtod_str("0x1.A", ...); /*to show that part after decimal point is correctly handling hexadecimal digits */ test_strtod_str("0x1p1a", ...); /* to show that exponential part is not handling hexadecimal digits */ Thanks, Piotr

2 1

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.
by Nikolay Sivov 29 Sep '15

29 Sep '15

On 29.09.2015 10:27, Ken Thomases wrote: > If the client requests a bold typeface of a font which doesn't actually provide > a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes > italic by apply a shear transform. > > These techniques work passably when antialiasing is in effect. However, when > antialiasing is disabled at small sizes by the font's GASP table, the results > are horrible. The glyphs have many spurs or appear furry. > > On the theory that fonts disable antialiasing via the GASP table at small sizes > because hinting should produce pixel-perfect results and that that rationale is > voided by the application of procedural bolding or italicizing, we ignore the > GASP table and always antialias for fake bold or italic fonts. Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself. > > There is a new registry setting to disable this and revert to the previous > behavior: > > [HKEY_CURRENT_USER\Software\Wine\Fonts] > "AntialiasFakeBoldOrItalic"="n" What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com>

2 2

Migrating away from Sourceforge
by Austin English 29 Sep '15

29 Sep '15

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.
by Marvin 28 Sep '15

28 Sep '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=16895 Your paranoid android. === w1064 (32 bit device) === device.c:2612: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2617: Test failed: The focus window is active. device.c:2625: Test failed: Got unexpected hr 0x88760869. device.c:2631: Test failed: Got unexpect screen size 1152x870. device.c:2646: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=2. device.c:2655: Test failed: Got unexpect screen size 1152x870. device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2676: Test failed: Got unexpect width 1152. device.c:2677: Test failed: Got unexpect height 864.

1 0

Re: ieframe: add a better toolbar bitmap
by Jacek Caban 28 Sep '15

28 Sep '15

Hi Jared, On 09/26/15 20:02, Jared Smudde wrote: > --- > dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes > 1 files changed, 0 insertions(+), 0 deletions(-) That file is generated from ietoolbar.svg, so it's the SVG file that should be changed. You may enable generating those file in your build with --enable-maintainer-mode configure option. Thanks, Jacek

2 1

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.
by Michael Müller 28 Sep '15

28 Sep '15

Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: > From: Michael Müller <michael(a)fds-team.de> > > For https://bugs.winehq.org/show_bug.cgi?id=34558 > > Depending on the compiler optimization flags there is still no guarantee that > everything will fit into the available stack space, no matter if its declared > as static or not. As suspected the idea does not work for all optimization levels. At least GCC merges the content of the functions when using -O2 and therefore reintroduces the problem - even __attribute__ ((noinline)) is not sufficient. As most distributions compile Wine with -02, I would suggest to ignore the patch for now. Maybe we can come up with a more general solution.

2 1

Re: msadpcm32.acm: Stop converting data instead of crashing
by Andrew Eikum 28 Sep '15

28 Sep '15

On Sun, Sep 27, 2015 at 12:42:42AM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > Tomb Raider 3 uses a single archive with all wav files inside, when > playing some specific sounds it passes incorrect lengths of data that > reach the next wav file header. This causes an assert in the code that > is now gracefully handled. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=21000 > diff --git a/dlls/msadp32.acm/msadp32.c b/dlls/msadp32.acm/msadp32.c > index 2c61575..0924163 100644 > --- a/dlls/msadp32.acm/msadp32.c > +++ b/dlls/msadp32.acm/msadp32.c > @@ -249,9 +249,17 @@ static void cvtSSms16K(const ACMDRVSTREAMINSTANCE *adsi, > { > const unsigned char* in_src = src; > > - assert(*src <= 6); > + /* Catch a problem from Tomb Raider III (bug 21000) where it passes > + * invalid data after a valid sequence of blocks */ > + if (*src > 6 || *(src + 1) > 6) > + { > + /* Recalculate the amount of used output buffer. We are not changing > + * nsrc, let's assume the bad data was parsed */ > + *ndst -= nblock * nsamp_blk * adsi->pwfxDst->nBlockAlign; > + ERR("Invalid ADPCM data, stopping conversion\n"); Looks reasonable, thanks. I think you should change that message to a WARN. Audio methods are often called thousands of times per second, so spamming an ERR can be very obnoxious. Andrew

3 3

Re: [PATCH] opengl32: use thunks for glDebugMessageCallback
by Matteo Bruni 28 Sep '15

28 Sep '15

2015-09-27 21:00 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > Also regenerated opengl files, to exclude the glDebugMessageCallback functions. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/opengl32/make_opengl | 6 + > dlls/opengl32/opengl_ext.c | 343 +++++++++++++++++++++++++++++++++++++++---- > dlls/opengl32/opengl_ext.h | 5 + > dlls/opengl32/opengl_norm.c | 90 +++++++++++- > dlls/opengl32/tests/opengl.c | 96 +++++++++++- > dlls/opengl32/wgl.c | 52 +++++++ > include/wine/wgl.h | 100 +++++++++++++ > include/wine/wgl_driver.h | 47 +++++- > include/winternl.h | 5 +- > 9 files changed, 708 insertions(+), 36 deletions(-) > diff --git a/include/winternl.h b/include/winternl.h > index 2fe2a2d..8e85eb4 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -341,7 +341,10 @@ typedef struct _TEB > PVOID GdiThreadLocaleInfo; /* 6fc/0870 */ > ULONG UserReserved[5]; /* 700/0878 */ > PVOID glDispachTable[280]; /* 714/0890 */ > - PVOID glReserved1[26]; /* b74/1150 */ > + PVOID glDebugCallback; /* b74/1150 */ > + PVOID glDebugCallbackAMD; /* b78/1158 */ > + PVOID glDebugCallbackARB; /* b7c/1160 */ > + PVOID glReserved1[23]; /* b80/1164 */ > PVOID glReserved2; /* bdc/1220 */ > PVOID glSectionInfo; /* be0/1228 */ > PVOID glSection; /* be4/1230 */ The callbacks should be per-GL context, that's why I mentioned the struct opengl_context as a possibly suitable place to store the application-provided callbacks. The test should actually test something. You probably need to create a debug context (the extension specifies that "For performance reasons it is recommended, but not required, that implementations restrict supporting this extension only to contexts created using the debug flag as provided by WGL_create_context or GLX_create_context") and enable the DEBUG_OUTPUT_SYNCHRONOUS_ARB flag. Also it would be definitely nicer if the test is implemented in a separate function, instead of stuffing it into START_TEST(opengl). For the records, you can find the relevant extension spec at https://www.opengl.org/registry/specs/ARB/debug_output.txt. GL_KHR_debug specifies some further related bits but I think you can mostly ignore that for this patch.

1 0

How to add the Signed-off-by field in the git patch
by Dmitry Timoshkov 28 Sep '15

28 Sep '15

Hi all, since I personally asked that question and investigated a bit the subject, here is some information that could be probably useful to someone else: http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… http://git-scm.com/docs/git-format-patch (CONFIGURATION section) Personally I've chosen to add [format] signOff = true to git.config file. -- Dmitry.

5 4

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values
by Marvin 28 Sep '15

28 Sep '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=16891 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

2 1

Help building a DLL at run-time
by Hugh McMaster 28 Sep '15

28 Sep '15

Does anyone know a way to build DLLs at runtime? Testing regsvr32.exe requires one or more DLLs, so I compiled a test DLL for use with the tests. Apparently, the tests should be self-contained, meaning the DLL is produced at run-time. I'm assuming this is done for anyone using the winetest program. I thought I could write the DLL manually, using IMAGE_NT_HEADERS and other structures. Unfortunately, I'm unable to write the required functions to the file. For one thing, functions have no size. Another method would be to build the DLL and use the linker to convert the DLL to an object file, link the binary in, and then output it at run-time. Alternatively, I can leave the tests out of the source tree. Opinions?

1 0

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view
by Nikolay Sivov 27 Sep '15

27 Sep '15

On 26.09.2015 22:11, Barrett Karish wrote: > Test Program: https://bugs.winehq.org/attachment.cgi?id=35473 > --- By test I meant a test integrated into wine tests, in this case it should go to comctl32/tests/listview.c. Test should basically create Listview of particular style, enable item text edit control and check its style. I think I tried that long time ago and test didn't confirm what appeared to be obvious fix, but I might be wrong.

1 0

Re: user32/tests: Allow tracing in menu test
by Dmitry Timoshkov 26 Sep '15

26 Sep '15

André Hentschel <nerv(a)dawncrow.de> wrote: > + if (winetest_debug > 1) > + trace("item #%u: fType %04x, fState %04x, wID %u, hSubMenu %p\n", > + i, mii.fType, mii.fState, mii.wID, mii.hSubMenu); Please use 4 spaces for indentation after 'if ()', not 8. Also, what's the reason of this patch? There are several other similar disabled debug traces in that file, anything special about this one? And I'd suggest to simply replace if (0) by if (1) in the personal build if you really need to see the traces. -- Dmitry.

4 4

prelink (needed to compile wine) missing on Fedora 23
by Zhenbo Li 26 Sep '15

26 Sep '15

Hello, I installed Fedora 23 Alpha to my computer, and tried to compile wine today. After running "./configure", I got this in my terminal configure: WARNING: prelink not found, base address of core dlls won't be set correctly. The reason is that prelink has been obsoleted since Fedora 23[1] There is a successful build for wine on Fedora23[2], and it seems that that package has been affected by missing prelink too.[3] Is this a critical problem? Should I ignore this WARNING, or try to fix it? Thank you [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… -- Have a nice day! Zhenbo Li

3 4

Re: ntdll: Fix for 64-bit builds (at least on OSX)
by Charles Davis 25 Sep '15

25 Sep '15

Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) Chip

2 2

Re: [PATCH] usp10/tests: Catch case where enumerated font name is too long
by Marvin 25 Sep '15

25 Sep '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=16855 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Dropping support for win2k in tests
by Jacek Caban 25 Sep '15

25 Sep '15

Hi all, I mentioned the concern on WineConf already and we quickly decided to not care about win2k during WineConf test session. But there is more to that: do we want to drop win2k support in our tests. I think we do. We have extra code to handle it all over tests codebase. Those are mostly skip()s + broken()s because, well, we don't care about win2k results. And if we don't care, then what's the point to bother and do the extra work. Stefan mentioned that ddraw has differences between win2k and newer version. That's true for other libraries as well. I don't think that's enough for the reason to keep win2k supported. A real case where test results on win2k was useful lately would be. Do we have an example of a real (not theoretical) use of win2k tests in recent Wine development? Thanks, Jacek

1 0

Wine and Buildroot
by André Hentschel 25 Sep '15

25 Sep '15

Hi, For those interested, I just add an introduction of Buildroot to our Wine-Wiki: http://wiki.winehq.org/Buildroot See also my slides from WineConf2015: http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=otherar… And a short WWN article from March 2015: https://www.winehq.org/wwn/387#Wine%20in%20Buildroot

2 1

Wine Stable/Release Changes
by Michael Stefaniuc 25 Sep '15

25 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon. Release Process Changes - ----------------------- - - Switch to time based releases. - - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September. - - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze. - - The stable release will be supported in bugzilla. - - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks. - - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. Discussion - ---------- The discussion was done based on slide 9 of Alexandre's keynote http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks. The discussion quickly geared to the changes accepted from above with the focus on implementation details: - - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise. - - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC. - - Nobody else volunteered during the discussion for the stable maintainer role. For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal. (*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+ Z9VxsMM7J1/wdpAyC8DPJaE= =zhZ8 -----END PGP SIGNATURE-----

6 6

Re: [PATCH] [comctl32] Fix sizing of edit window for listview icon view
by Nikolay Sivov 25 Sep '15

25 Sep '15

On 25.09.2015 4:33, Barrett Karish wrote: > --- > dlls/comctl32/listview.c | 42 +++++++++++++++++++++++++----------------- > 1 file changed, 25 insertions(+), 17 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index e3fad51..ba227a7 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -6048,12 +6048,15 @@ static LRESULT CALLBACK EditLblWndProcA(HWND hwnd, UINT uMsg, WPARAM wParam, LPA > */ > static HWND CreateEditLabelT(LISTVIEW_INFO *infoPtr, LPCWSTR text, BOOL isW) > { > - static const DWORD style = WS_CHILDWINDOW|WS_CLIPSIBLINGS|ES_LEFT|ES_AUTOHSCROLL|WS_BORDER|WS_VISIBLE; > - HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); > + DWORD style = WS_CHILDWINDOW | WS_CLIPSIBLINGS | ES_LEFT | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE | ES_MULTILINE; > + HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); Hi, Barrett. Please use existing 4 space formatting and avoid unnecessary changes. > HWND hedit; > > TRACE("(%p, text=%s, isW=%d)\n", infoPtr, debugtext_t(text, isW), isW); > > + if (infoPtr->uView == LV_VIEW_ICON) > + style |= ES_CENTER; We need a test that proves that Edit gets centered style on icon view. > + > /* window will be resized and positioned after LVN_BEGINLABELEDIT */ > if (isW) > hedit = CreateWindowW(WC_EDITW, text, style, 0, 0, 0, 0, infoPtr->hwndSelf, 0, hinst, 0); > @@ -6093,7 +6096,6 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > HFONT hOldFont = NULL; > TEXTMETRICW tm; > RECT rect; > - SIZE sz; > HDC hdc; > > TRACE("(nItem=%d, isW=%d)\n", nItem, isW); > @@ -6152,24 +6154,30 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > GetWindowTextW(infoPtr->hwndEdit, disptextW, DISP_TEXT_SIZE); > TRACE("edit box text=%s\n", debugstr_w(disptextW)); > > - /* get string length in pixels */ > - GetTextExtentPoint32W(hdc, disptextW, lstrlenW(disptextW), &sz); > + DrawTextW(hdc, disptextW, -1, &rect, infoPtr->uView == LV_VIEW_ICON ? LV_FL_DT_FLAGS : LV_SL_DT_FLAGS | DT_CALCRECT); > > - /* add extra spacing for the next character */ > - GetTextMetricsW(hdc, &tm); > - sz.cx += tm.tmMaxCharWidth * 2; > + if (infoPtr->uView != LV_VIEW_ICON) > + { > + /* add extra spacing for the next character */ > + GetTextMetricsW(hdc, &tm); > + rect.right += tm.tmMaxCharWidth; > + rect.left -= 2; > + rect.top -= 1; > + rect.bottom += 2; > + } > + else > + { > + rect.bottom += 3; > + } > This should ideally use some font metrics instead of hardcoded magic, but I know we do it this way already. > - if (infoPtr->hFont) > - SelectObject(hdc, hOldFont); > + if (infoPtr->hFont) > + SelectObject(hdc, hOldFont); > > - ReleaseDC(infoPtr->hwndSelf, hdc); > + ReleaseDC(infoPtr->hwndSelf, hdc); > > - sz.cy = rect.bottom - rect.top + 2; > - rect.left -= 2; > - rect.top -= 1; > - TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, sz.cx, sz.cy); > - MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, sz.cx, sz.cy, FALSE); > - ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > + TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top); > + MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, FALSE); > + ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > SetFocus(infoPtr->hwndEdit); > SendMessageW(infoPtr->hwndEdit, EM_SETSEL, 0, -1); > return infoPtr->hwndEdit; >

1 0

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add tests.
by Marvin 23 Sep '15

23 Sep '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=16838 Your paranoid android. === w1064 (32 bit thread) === thread.c:1087: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

2 1

Inconsistent argument type declaration in dinput.h: WriteEffectToFile()
by Elias Vanderstuyft 23 Sep '15

23 Sep '15

Hi everyone, The docs of IDirectInputDevice8::WriteEffectToFile() declare the third argument as LPCDIFILEEFFECT rgDiFileEft: https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… This is inconsistent with Microsoft's "dinput.h" file, they declare it as LPDIFILEEFFECT (thus, no "const"): ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… Wine's "dinput.h" follows the same mistake as Microsoft's: https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 Is there a particular reason for this? Best regards, Elias

3 4

Re: [PATCH 11/12] ddraw: cache active DCs
by Stefan Dösinger 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > + sub_resource = wined3d_texture_get_sub_resource(surface_impl->wined3d_texture, surface_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > + if (FAILED(hr = wined3d_surface_getdc(wined3d_surface, &surface_dc))) I expect the getdc call to fail because the application already called GetDC. I think you can just add a HDC dc field to struct wined3d_surface and compare it to the dc passed to GetSurfaceFromDC. > + if (!hdc) > { > - TRACE("No surface found for dc %p.\n", hdc); > *Surface = NULL; > return DDERR_NOTFOUND; > } Personally I prefer to write a WARN if we return failure to the application. Note that this is just my personal choice though, the existing code is not consistent here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAnJqAAoJEN0/YqbEcdMwGTwP/3zCYpjVZYY0M3Mafxs7j3Dq WPDkiiRzshspPTLIx3kurk7lRd2JXa8GbXZ8bOjx6bOz9wZC1wtejQEwLGhENOgz bzX9tyYT2FdRXVXM0V0bEOAvd0rivgIeE0xcPWYZg289bHTx4bw/3Ql+uSsUY/8L lamfMT5xOKhZmr6T5mI3MpHjUnbIUtBrOHvAggNexfl+RcvlFgmsl1MqajBHO+O7 W1ws4F35MzbXiEKUNEX3yH1cr3WRW+9xcAi89YYTnOTIpYsJHGOOOXoAeF1G2W2c dvj131zQRdlIknLxxZPZXSQJJffdiDdnuJ6xeMfJ1f9SdH0PNPKhX08wH2Wz+Zr8 77zY0vK2iqnAl0HUcq4WrL4TLh60VU2UeyhAy8vqYjso60OvANAmYBljgO5Z4oI/ mypsa1sq11Vrp+DAIaxFyj15whgdV2tE/NvC4Kapx4OK8DTQ+9xHGJoED9AX/E+/ OvynPYd/r/WPYyIYJpSv/YOAN4OAusNpY7i4nlXu8RbphTFcNZTrtLU/EUJCfI6T LaEx3TX9/Dg4BNrwY72cPleLKSZbGK1/59q0XWbH5Oft8HS48jL7IEJkNsNtJpqf GOJr/EotzHpJC2QGKOZ19NhgcCb22GbF8jCniLMVUSj/DelDzKOJs+5VaRiFcNqo AVr5Gv4UMzGlq7CjMo4v =UoFu -----END PGP SIGNATURE-----

1 0

Re: [PATCH 11/12] ddraw: cache active DCs
by Jonas Maebe 23 Sep '15

23 Sep '15

Riccardo Bortolato wrote on Wed, 23 Sep 2015: Disclaimer: I'm everything but an expert on Wine internals, so I'm just asking in case I'm not missing something obvious. > - surface_impl = wined3d_surface_get_parent(wined3d_surface); > - *Surface = &surface_impl->IDirectDrawSurface7_iface; > - IDirectDrawSurface7_AddRef(*Surface); > - TRACE("Returning surface %p.\n", Surface); > - return DD_OK; > + wined3d_mutex_lock(); > + LIST_FOR_EACH_ENTRY(surface_impl, &ddraw->active_dcs, struct > ddraw_surface, active_dcs_entry) Here you get a mutex lock before iterating over the active_dcs. > + if (surface_dc == hdc) > + { > + wined3d_mutex_unlock(); > + *Surface = &surface_impl->IDirectDrawSurface7_iface; > + IDirectDrawSurface7_AddRef(*Surface); > + TRACE("Returning surface %p.\n", Surface); > + return DD_OK; > + } Here you free the lock before increasing the reference count. At first sight, it would seem that you either don't need the lock while iterating, or that you should increase the reference count before releasing the lock in order to avoid races (unless the lock is for a completely unrelated reason) > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -2176,7 +2176,9 @@ static HRESULT WINAPI > ddraw_surface7_GetDC(IDirectDrawSurface7 *iface, HDC *hdc) > if(hdc) *hdc = NULL; > return DDERR_INVALIDPARAMS; > > - default: return hr; > + default: > + list_add_head(&surface->ddraw->active_dcs, > &surface->active_dcs_entry); Here you add something to the actives_dcs list without locking, so this can race with the iterating (unless this is implicitly synchronised in another way I'm not aware of). > @@ -2246,6 +2248,8 @@ static HRESULT WINAPI > ddraw_surface7_ReleaseDC(IDirectDrawSurface7 *iface, HDC h > hr = ddraw_surface_update_frontbuffer(surface, NULL, FALSE); > wined3d_mutex_unlock(); > > + list_remove(&surface->active_dcs_entry); > + > return hr; > } Similarly, here you remove an item after releasing the lock, so it can race with both adding and iterating (same caveat). Jonas

2 1

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces
by Stefan Dösinger 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > wined3d_mutex_lock(); > + sub_resource = wined3d_texture_get_sub_resource(bitmap_impl->wined3d_texture, bitmap_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > hr = wined3d_device_set_cursor_properties(device->wined3d_device, > - hotspot_x, hotspot_y, bitmap_impl->wined3d_surface); > + hotspot_x, hotspot_y, wined3d_surface); > wined3d_mutex_unlock(); You may want to consider changing wined3d_device_set_cursor_properties to accept a wined3d_texture instead. Keep in mind though that this would be a bit of a side quest, as you'll have to find out if native accepts surfaces that are part of textures or just stand-alone surfaces created by CreateImageSurface. If it is the latter (which I suspect it is) then wined3d_texture alone is OK. Otherwise you need texture + idx. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmlwAAoJEN0/YqbEcdMwGlkP/RfRVsceuPRGgVE0yJvhV26U ci6CDlrj4Lb2mFcH3IVlJKuJEOcT2TLrcx2hT3H2+0OjDBvAIJyLhzjxABaZsg0N OU4TJCvLfPiieF0npy7EBpUoe+E8a4046DRnLJsooco1Cp+Fk2LZO4B1OjMoaexl FaO9zoAO+3KlTNVwRKX65KnOsZB7PtP0soCS9Gsmvx1gwwVe42uQ8B5pSgQQzcgW UablqGdE0NnUGN2Bcj6vxPdW14FEaWC7Mp8fBl8olLO/FdlEoehzUMO7bPJNgGr2 wePB12qwmTfizcQ+Nmd5/HAGZMsn4vgfxu+kQSb0iaWxdgRtqKztlkLzAOFvGDTS x+yZ2pWTcNp41MzZI9yxRStI5eLq5ZBQ9vY64A85W3Zwj/wTb7eR6A/qWveOUYsG 6EtQ9F0pQ43hotiE9a/8AdvTlrwQ+lcK6W01Ngg2mh9xnZ8pcD1Zqugy7RYDoHiQ u+yd0BxvV3SjmjA0h4qZRVUh/ct5UMPCp6gJdHJFtSsKfoRAq96BzI3g3AFGH+Xv u0Tkjq7QbhtLPxdjdc8A61SbwRFqygrj3XsZi0ji6qar5tjW58u0PdRskb4NTUhu lEYUETpysaj29ktGURJ3s5/G1TKauDM9G4jx9puM8Kh0LilKshRwIsJaZf+4uHeW BBmwwFk8QMQpKffLOCie =W7On -----END PGP SIGNATURE-----

2 1

Re: kernel32: Create registry keys for available COM ports
by Austin English 22 Sep '15

22 Sep '15

On Tue, Sep 22, 2015 at 3:14 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > dlls/kernel32/kernel_private.h | 3 +++ > dlls/kernel32/oldconfig.c | 42 +++++++++++++++++++++++++++++++++++++++--- > dlls/kernel32/volume.c | 2 +- > 3 files changed, 43 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/kernel_private.h b/dlls/kernel32/kernel_private.h > index 76611d7..9f2db22 100644 > --- a/dlls/kernel32/kernel_private.h > +++ b/dlls/kernel32/kernel_private.h > @@ -107,6 +107,9 @@ extern void LOCALE_InitRegistry(void) DECLSPEC_HIDDEN; > /* oldconfig.c */ > extern void convert_old_config(void) DECLSPEC_HIDDEN; > > +/* volume.c */ > +extern char *get_dos_device_path(LPCWSTR) DECLSPEC_HIDDEN; > + > /* returns directory handle for named objects */ > extern HANDLE get_BaseNamedObjects_handle(void) DECLSPEC_HIDDEN; > > diff --git a/dlls/kernel32/oldconfig.c b/dlls/kernel32/oldconfig.c > index 2c8bc18..b7f6b97 100644 > --- a/dlls/kernel32/oldconfig.c > +++ b/dlls/kernel32/oldconfig.c > @@ -264,8 +264,8 @@ static int SCSI_getprocentry( FILE * procfile, struct LinuxProcScsiDevice * dev > } > > > -/* create the hardware registry branch */ > -static void create_hardware_branch(void) > +/* create the scsi registry branch */ > +static void create_scsi_branch(void) > { > /* The following mostly will work on Linux, but should not cause > * problems on other systems. */ > @@ -389,6 +389,41 @@ static void create_hardware_branch(void) > } > > > +/* create SERIALCOMM branch */ > +void create_serialcomm_branch(void) > +{ > + static WCHAR comW[] = {'C','O','M','1',0}; > + UNICODE_STRING nameU; > + DWORD disp; > + HANDLE key; > + int i; > + > + /* Ensure there is a SERIALCOMM key */ > + if (create_key( 0, "Machine\\HARDWARE\\DEVICEMAP\\SERIALCOMM", &key, &disp )) return; > + > + for (i = 1; i <= 9; i++) > + { > + char *link; > + int ret; > + > + comW[3] = 0x30 + i; > + link = get_dos_device_path( comW ); > + ret = access( link, R_OK | W_OK ); > + > + RtlCreateUnicodeString( &nameU, comW ); > + if (ret) > + NtDeleteValueKey( key, &nameU ); > + else > + NtSetValueKey( key, &nameU, 0, REG_SZ, (BYTE*)comW, sizeof(comW) ); > + RtlFreeUnicodeString( &nameU ); > + > + HeapFree(GetProcessHeap(), 0, link); > + } > + > + NtClose(key); > +} > + > + > /*********************************************************************** > * convert_old_config > */ > @@ -400,5 +435,6 @@ void convert_old_config(void) > /* create some hardware keys (FIXME: should not be done here) */ > if (create_key( 0, "Machine\\HARDWARE", &key, &disp )) return; > NtClose( key ); > - if (disp != REG_OPENED_EXISTING_KEY) create_hardware_branch(); > + if (disp != REG_OPENED_EXISTING_KEY) create_scsi_branch(); > + create_serialcomm_branch(); > } > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 7a1dc11..43fbb7e 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -99,7 +99,7 @@ static char *read_symlink( const char *path ) > } > > /* get the path of a dos device symlink in the $WINEPREFIX/dosdevices directory */ > -static char *get_dos_device_path( LPCWSTR name ) > +char *get_dos_device_path( LPCWSTR name ) > { > const char *config_dir = wine_get_config_dir(); > char *buffer, *dev; > -- > 1.9.1 Hi Andre, You forgot to sign off on this patch ;) -- -Austin

1 0

Re: msi: Set the PrimaryVolumeSpaceRequired and PrimaryVolumeSpaceRemaining properties.
by Marvin 22 Sep '15

22 Sep '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=16820 Your paranoid android. === w7u (32 bit install) === The test timed out === wvistau64 (64 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [2/2] wininet/tests: Fix a couple of test failures.
by Marvin 22 Sep '15

22 Sep '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=16819 Your paranoid android. === w2000pro (32 bit http) === http.c:2400: Test failed: InternetReadFile failed 12030 http.c:2401: Test failed: count was wrong === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [1/2] wininet/tests: Never use a proxy for connections to localhost.
by Marvin 22 Sep '15

22 Sep '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=16818 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: How to add the Signed-off-by field in the git patch
by Hin-Tak Leung 22 Sep '15

22 Sep '15

You don't need to edit git's config by hand - 'git config --global ... ' can do that for you. read the documentation for git-config, and particularly the --global option. I also have colorised diff and a few other useful thing configured. ------------------------------ On Tue, Sep 22, 2015 3:21 PM BST Aaryaman Vasishta wrote: >Hi Dimitry, > >Thanks! this will definitely help if this info is added to the wiki too. >Though it seems to be down right now. There's a discussion going on about >it on IRC right now. > >Cheers, >Aaryaman > >On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Hi all, >> >> since I personally asked that question and investigated a bit the subject, >> here is some information that could be probably useful to someone else: >> >> >> http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… >> >> http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… >> >> http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… >> http://git-scm.com/docs/git-format-patch (CONFIGURATION section) >> >> Personally I've chosen to add >> [format] >> signOff = true >> to git.config file. >> >> -- >> Dmitry. >> >> >>

1 0

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const
by Nikolay Sivov 22 Sep '15

22 Sep '15

On 22.09.2015 0:06, Marcus Meissner wrote: > Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dinput/device.c | 4 ++-- > dlls/dinput/device_private.h | 4 ++-- > include/dinput.h | 8 ++++---- > 3 files changed, 8 insertions(+), 8 deletions(-) > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case?

4 3

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Marvin 21 Sep '15

21 Sep '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=16808 Your paranoid android. === w2003std (32 bit string) === Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 === w7u (32 bit string) === Failure running script in VM: timed out waiting for the child process

2 1

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban 21 Sep '15

21 Sep '15

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

2 1

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer 20 Sep '15

20 Sep '15

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer 20 Sep '15

20 Sep '15

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: psapi/tests: Don't check for exact value (try 7)
by Marvin 20 Sep '15

20 Sep '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=16805 Your paranoid android. === w1064 (32 bit psapi_main) === psapi_main.c:157: Test failed: cbNeeded=136 psapi_main.c:644: Test failed: wrong length 3 No test summary line found === w1064 (64 bit psapi_main) === psapi_main.c:644: Test failed: wrong length 3 No test summary line found

2 1

Wine test update
by Jeremy White 20 Sep '15

20 Sep '15

We reviewed my list of interesting test bot vm failures: https://www.winehq.org/~jwhite/latest.html and have assigned blame to most of them. A few we think we can ignore, and we've dropped 2000 from the definition of 'interesting'. The following glorious people volunteered to work on one or more of these issues: Andrew, Alexandre, Aric, Francois, Huw, Stefan, Piotr, Jacek, Qian, Hans, and Sebastian, and I've emailed Bruno to ask him to look into one. Cheers, Jeremy

2 1

Winsock 2
by Christopher Harrington 20 Sep '15

20 Sep '15

I'm looking at trying to implement some of the Winsock 2 stubs, namely WSALookupServiceBegin/Next/End. I'm probably only going to implement enough of it that my target binary will stop bailing out with "out of memory". I suspect the app is using it to resolve DNS... Am I stepping on anyone's toes? If not, can someone point me at the right place to look for where wine is currently doing DNS lookups so I can reuse that non-broken code? Thank you in advance. -Chris Harrington

3 4

Changes for Wine on Debian
by Kyle Auble 20 Sep '15

20 Sep '15

Hi everyone, I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now. Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons. When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself. - Kyle

4 8

RFC - oleaut32: Cope with invalid icon data
by Bruno Jesus 19 Sep '15

19 Sep '15

While testing bug [1] I noticed that invalid data is sent to OLEPictureImpl_LoadIcon. This patch is meant to resist these kind of issues and makes the game goes on a little further until other crash. I'm sending this as RFC because I don't know then icon structure but my tests seem very straight forward from what I can guess from the function. [1] https://bugs.winehq.org/show_bug.cgi?id=21012 Thanks in advance and best regards, Bruno

1 0

No release this week
by Alexandre Julliard 18 Sep '15

18 Sep '15

Hey guys, Because of WineConf, it looks like I won't be able to make a release today. And since I'll be taking some vacation next week, I plan to release 1.7.52 on Friday two weeks from now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: TRACE fixes. (try 2)
by Henri Verbeet 18 Sep '15

18 Sep '15

On 16 September 2015 at 14:39, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > @@ -1243,7 +1243,7 @@ static int context_choose_pixel_format(const struct wined3d_device *device, HDC > unsigned int cfg_count = device->adapter->cfg_count; > unsigned int i; > > - TRACE("device %p, dc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > + TRACE("device %p, hdc %p, color_format %s, ds_format %s, aux_buffers %#x, find_compatible %#x.\n", > device, hdc, debug_d3dformat(color_format->id), debug_d3dformat(ds_format->id), > auxBuffers, findCompatible); This isn't wrong, but I'd be more inclined to change the parameter to match the trace than the other way around. > @@ -157,8 +157,8 @@ HRESULT CDECL wined3d_palette_create(struct wined3d_device *device, DWORD flags, > struct wined3d_palette *object; > HRESULT hr; > > - TRACE("device %p, flags %#x, entries %p, palette %p.\n", > - device, flags, entries, palette); > + TRACE("device %p, flags %#x, entry_count %d, entries %p, palette %p.\n", > + device, flags, entry_count, entries, palette); Unsigned values should use %u instead of %d. > @@ -114,7 +114,7 @@ enum wined3d_event_query_result wined3d_event_query_finish(const struct wined3d_ > const struct wined3d_gl_info *gl_info; > enum wined3d_event_query_result ret; > > - TRACE("(%p)\n", query); > + TRACE("(%p, %p)\n", query, device); This isn't wrong per se either, but I'd prefer that as "query %p, device %p.\n" like the rest of wined3d. > @@ -1275,7 +1275,7 @@ static void shader_dump_decl_usage(const struct wined3d_shader_semantic *semanti > break; > > case WINED3D_DECL_USAGE_BLEND_INDICES: > - TRACE("blend"); > + TRACE("indices"); I'd either just leave that the way it is, or change it to "blendindices". In the latter case you'd have to change the one for WINED3D_DECL_USAGE_BLEND_WEIGHT to "blendweight", and the one for WINED3D_DECL_USAGE_TEXCOORD to "texcoord%u" as well. > @@ -2037,8 +2037,8 @@ static HRESULT shader_set_function(struct wined3d_shader *shader, const DWORD *b > unsigned int backend_version; > const struct wined3d_d3d_info *d3d_info = &shader->device->adapter->d3d_info; > > - TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u.\n", > - shader, byte_code, output_signature, float_const_count); > + TRACE("shader %p, byte_code %p, output_signature %p, float_const_count %u, type %#x, max_version %d.\n", > + shader, byte_code, output_signature, float_const_count, type, max_version); %d -> %u

1 0

Optimizing synchronization objects
by Daniel Santos 17 Sep '15

17 Sep '15

Alexandre, First off I apologize for the size of this email, I'm trying to keep it as concise as possible. I've been experimenting with ways to optimize synchronization objects and have implemented a promising proof of concept for semaphores using glibc's nptl (posix) semaphore implementation. I posted revision 3 of this today, although I appear to have used the wrong msg id in the --in-reply-to header. :( So my goal is to eventually make similar optimizations for all synchronization objects, or at least those that have demonstrable performance problems. The basic theory of operation is that when a client sends a create_semaphore, the server creates a posix semaphore with a unique name which is passes to the client process so that it can open it locally. This allows the client to perform ReleaseSemaphore without a server call as well as WaitFor(Multiple|Single)Object(s) for cases where the wait condition can be determined to be satisfied without a server call (i.e., either bWaitAll = FALSE and a signalled semaphore is found in the handle list prior to a non-semaphore objects or bWaitAll = TRUE and all handles are signalled semaphores). For all other conditions, it uses a traditional server call. However, it has two problems: 1. It uses glibc's implementation of POSIX semaphores which uses shared memory to share them with other processes, and 2. It uses glibc's implementation of POSIX semaphores which are incompatible across 32- and 64-bit ABI processes. I have not been able to find any more flaws in a case where both program and wineserver are the same ABI. All tests pass and I've added one more (although more tests are clearly needed). Since this implementation only uses sem_trywait (and never sem_wait or sem_timedwait), we don't really even need a full-featured semaphore -- a simple 32- or 16-bit number that's accessed atomically would suffice as a replacement. Although I did plan to eventually explore having a client program block w/o calling the server, the benefit of that is minimal compared to the benefit of being able to avoid the server call for releasing a semaphore and "wait"ing when the semaphore is already available. So now I want to understand the minimum threshold of acceptability in wine for such a mechanism. We discussed this in chat and quite a bit and can I see many possibilities, each with its own particular issues. I'm listing them in order of my personal preference (most preferred first). Option 1: Simple shared memory & roll our own semaphore Similar to what glibc's NPTL semaphores are doing, except that we would only need a single integral value and not even a futex. The obvious downside is that a process can corrupt this memory and cause dysfunction of other processes who also have semaphores in that page. This could be minimized by giving every process their own page that is only shared between the server and the process unless a semaphore in that process is shared with another program, at which time the memory page could be shared with that process as well. Thus, the scope of possible corruption is limited to how far you share the object. In the worse case of memory corruption, the wineserver would either leave a thread of one of these processes hung, release one when it shouldn't be released or determine that the memory is corrupted, issue an error message, set the last error to something appropriate and return WAIT_FAILED. Option 2: System V semaphores On Linux, these are hosted in the kernel, so you can't just accidentally overwrite them. They will be slightly slower than shared memory due to the system call overhead. You probably know them better than I, but at the risk or stating the obvious, the following are their limitations. Their max value on Linux is SHRT_MAX so any request for a higher lMaximumCount would have to be clipped. There are also limits on Linux that can be adjusted by root if needed for some application, but the default is a maximum of 32000 (SEMVMX) total semaphores on the system, 128 (SEMMNI) semaphore sets and a max size of 250 (SEMMSL) semaphores per set. They are also persistent, so if the wine server crashes, they can leave behind clutter. Option 3: Move semaphores completely into the client In this scenario, the wine server can never be exposed to corrupted data. It is very fast when locking can be performed in the client, but very complicated and potentially slower for mixed locks. Calls to WaitForMultipleObjectsEx containing both semaphores and other objects (especially with bWaitAll = TRUE) may require multiple request/reply cycles to complete. The client must successfully lock the semaphores prior to the server calling satisfied on the server-side objects. Here is an optimistic use case that only requires a single request/reply cycle 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which succeeds. 3. Client passes request to server (with semaphore states) and blocks on pipe 4. Server gets value of all server-side objects and determines that the condition can be satisfied, so calls satisfied on all objects 5. Server sends response to client 6. Client wakes up and completes the wait call. Here is a slightly less optimistic case 1. WaitForMultipleObjectsEx is called with bWaitAll = TRUE and a mix of semaphores and other objects 2. Client calls trywait on all semaphores, which fails on one semaphore. 3. Client rolls back locks on all which had succeeded. 4. Client passes request to server (with semaphore states) 5. Client blocks on the semaphore that was locked and the server pipe 6. Server updates thread status (blocking on native object) 7. Semaphore is signaled and client wakes up 8. Lock is obtained on semaphore that was previously locked 9. Client now calls trywait on remaining semaphores which again succeeds. 10. Client sends update to server and blocks on pipe 11. Server checks all server-side objects, which are all signaled, so calls satisfied on all objects 12. Server updates thread status and notifies client 13. Client wakes up and completes wait call. As you can see this can get more complicated. If the server discovers that an server object isn't signaled it will have to notify the client to rollback the locks and wait for server objects to be ready. So which of these solution is most appealing to you?

4 10

Re: [PATCH 1/3] wineps.drv: Make the Unicode name-sorted glyph table fully const.
by Henri Verbeet 17 Sep '15

17 Sep '15

On 16 September 2015 at 00:02, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > This patch series fixes several places where glyph table values are > not const, preventing the compiler from placing the table in read-only > memory. > Did you verify this does what you think it does? I suspect you don't really understand const and relocations.

2 5

Prep for Wineconf - testing
by Jeremy White 17 Sep '15

17 Sep '15

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [10/10] msvcirt: Implement strstreambuf::seekoff (resend)
by Piotr Caban 17 Sep '15

17 Sep '15

Hi, On 09/17/15 11:06, Iván Matellanes wrote: > DEFINE_THISCALL_WRAPPER(strstreambuf_seekoff, 16) > streampos __thiscall strstreambuf_seekoff(strstreambuf *this, streamoff offset, ios_seek_dir dir, int mode) > { > - FIXME("(%p %d %d %d) stub\n", this, offset, dir, mode); > - return EOF; > + char *base[3]; > + > + TRACE("(%p %d %d %d)\n", this, offset, dir, mode); > + > + if (dir < 0 || dir > 2 || !(mode & (OPENMODE_in|OPENMODE_out))) > + return EOF; > + /* read buffer */ > + if (mode & OPENMODE_in) { > + base[0] = this->base.eback; > + base[1] = this->base.gptr; > + base[2] = this->base.egptr; The code will be easier to read if you use SEEKDIR_beg, SEEKDIR_cur and SEEKDIR_end instead of its values. > + if (this->base.gptr >= this->base.egptr) > + call_streambuf_underflow(&this->base); According to my testing call_streambuf_underflow should be called always, even so default implementation will just return in this case. I was not really checking it but it looks wrong that you store base table values before underflow is called. Patches 1-9 looks good for me. Thanks, Piotr

1 0

Re: dxgi: upgrade Direct3D 10 WARN to a FIXME
by Henri Verbeet 17 Sep '15

17 Sep '15

On 15 September 2015 at 21:36, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=39277 > > Side note: I'm pretty sure I've seen this or a similar issue on my > Intel/Nvidia desktop with Dragon Age 2, but didn't investigate it > further at the time, so I'd really like to see this committed :). > This should probably go to winediag then.

2 2

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2)
by Marvin 16 Sep '15

16 Sep '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=16776 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

Re: rsaenh/tests: Adjust length value to pass on Win 10
by Marvin 16 Sep '15

16 Sep '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=16775 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

1 0

The fg-xxx VMs now accessible on demand
by Francois Gouget 16 Sep '15

16 Sep '15

So as you may know I run WineTest in a variety of Windows configurations daily (28). The results can be seen on test.winehq.org but the problem is investigating the test failures because most of these configurations cannot be found on the Wine TestBot. I have three options to work around this: * As I mentionned before (1), if you're interested in a specific configuration I may be able to temporarily switch a WineTestBot VM to that configuration. * Another option is to send me an executable to run in the VM and I'll send back the results. * And the new option is that I can now give you VNC access to the VM. Access is open to any Wine developer (i.e. you got a patch accepted in Wine). To get access to the VM contact me on IRC or send me an email and give me the tag of the VM configuration you're interested in (e.g. fg-winxp-lusr). Then I'll start up the VM in the right configuration and send you the address to use to connect to the VM. Of course if I'm asleep or out you may have to wait a bit to get access. Also my uplink is not very fast so expect slow refreshes and some lag. But in the short test I've done it seems to be usable (at least to someone who's used to transatlantic VNC links with an elastic mouse pointer). And for reference here is a list of the available VM configurations. We may not care about some of them, for instance those running the earlier service pack revisions. Let me know if that's the case. Windows 2000 ------------ The French Windows 2000 Professional SP4 installed from an official Microsoft CD. Unless otherwise noted the tests are run in an administrator account. fg-win2000-4sp IE 5.00 SP2 fg-win2000-ie55 = 4sp + IE 5.5 SP2, MSXML3 fg-win2000-ie6 = ie55 + IE 6.0 SP1 fg-win2000-up1 = ie6 + all updates up to 2011/03/21 fg-win2000-uplast = up1 + DirectX 9.0c, WMP 9, .Net 1.1 & 2.0 fg-win2000-rusr = uplast but in a 'Restricted User' account fg-win2000-susr = uplast but in a 'Power User' account Windows XP ---------- I created this VM from the Compaq Windows XP partition of my (former) computer. So this started with a number of extra non-Microsoft applications (blasts from the past: Netscape 7, RealOne Player, etc.). On the one hand this is more representative of what Windows users normally have and on the other the configuration is not as 'straight out of the box' as the other VMs. That may not matter though. fg-winxp-1sp XP SP 1, IE 6.0 SP1, DirectX 8.1 fg-winxp-2sp = 1sp + XP SP2, IE 6.0, DirectX 9.0c, .Net 1.0 SP3 fg-winxp-2spie7 = 2sp + IE 7.0, WMP 10, .Net 1.1 fg-winxp-3sp = 2spie7 + XP SP3, WMP 11, .Net 2.0 SP2 & 3.0 SP2 & 3.5 SP1 fg-winxp-3spie8 = 3sp + IE 8 fg-winxp-last = 3spie8 + all updates up to 2011/09/08 fg-winxp-lusr = last but in a 'Limited User' account Windows 7 --------- Installed from an official English Windows 7 Ultimate CD. Unless otherwise noted the tests are run in an administrator account with Elevated Privileges. fg-win7u64-0sp Base install + French language pack (but still configured for English) fg-win7u64-1sp = 0sp + SP1 fg-win7u64-1spie9(64) = 1sp + IE 9.0, all language packs fg-win7u64-1spie9adm = 1spie9 but no 'Elevated Privileges' fg-win7u64-1spie9usr = 1spie9 but in a 'Standard user' account fg-win7u64-1spie9-ar = 1spie9 but in an Arabic locale fg-win7u64-1spie9-de = 1spie9 but in a German locale fg-win7u64-1spie9-es = 1spie9 but in a Spanish locale fg-win7u64-1spie9-fr = 1spie9 but in a French locale fg-win7u64-1spie9-he = 1spie9 but in a Hebrew locale fg-win7u64-1spie9-ja = 1spie9 but in a Japanese locale fg-win7u64-1spie9-ko = 1spie9 but in a Korean locale fg-win7u64-1spie9-mx = 1spie9 but in a mixed locale (1) https://www.winehq.org/pipermail/wine-devel/2015-September/109252.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

1 0

Re: [PATCH 1/4] xaudio2: Implement IXAudio2SourceVoice frequency functions
by Chris Robinson 16 Sep '15

16 Sep '15

On 09/15/2015 10:25 AM, Andrew Eikum wrote: > @@ -801,14 +802,26 @@ static HRESULT WINAPI XA2SRC_SetFrequencyRatio(IXAudio2SourceVoice *iface, > float Ratio, UINT32 OperationSet) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %f, 0x%x\n", This, Ratio, OperationSet); > + > + EnterCriticalSection(&This->lock); > + > + This->freq_ratio = Ratio; > + This->freq = This->fmt->nSamplesPerSec * Ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; ... > @@ -816,7 +829,16 @@ static HRESULT WINAPI XA2SRC_SetSourceSampleRate( > UINT32 NewSourceSampleRate) > { > XA2SourceImpl *This = impl_from_IXAudio2SourceVoice(iface); > + > TRACE("%p, %u\n", This, NewSourceSampleRate); > + > + EnterCriticalSection(&This->lock); > + > + This->fmt->nSamplesPerSec = NewSourceSampleRate; > + This->freq = NewSourceSampleRate * This->freq_ratio; > + > + LeaveCriticalSection(&This->lock); > + > return S_OK; > } ... > @@ -2989,7 +3012,7 @@ static BOOL xa2buffer_queue_period(XA2SourceImpl *src, XA2Buffer *buf, ALuint al > buf->offs_bytes += submit_bytes; > > alBufferData(al_buf, src->al_fmt, submit_buf, submit_bytes, > - src->fmt->nSamplesPerSec); > + src->freq); > > alSourceQueueBuffers(src->al_src, 1, &al_buf); > This doesn't strike me as correct. Assuming the SampleRate or FrequencyRatio can be altered in real-time, this will break the OpenAL buffer queue which needs to have the same sample rate on each buffer. SetFrequencyRatio looks like it'd map directly to the AL source's pitch property, while SetSourceSampleRate may be a bit trickier depending on when it's allowed to be called (it'd require stopping the source and clearing the queue, then rebuffering and requeueing the buffers to start where it left off). Also, I notice the OperationSet parameter isn't used. What is that for?

2 1

RFC: Hybrid (wineserver / process-local) native semaphores
by Daniel Santos 16 Sep '15

16 Sep '15

This patch set fixes most performance problems caused by ReleaseSemaphore() and WaitForSingle/MultipleObject(s) making server calls. One victim of this is Star Wars Battlefront (https://bugs.winehq.org/show_bug.cgi?id=29582), where the majority of the CPU time is spent on context switching while the program spams ReleaseSemaphore, WaitForSingle/MultipleObject(s) and GetForgroundWindow, the later of which I made a work-around hack for and that some players have been using. This patch set doubles performance of bug #29582. (When combined with GetForgroundWindow hack the problem is completely resolved.) The patch set works by having the server create a POSIX semaphore object and sharing the key to that object with the client process, enabling the client process to be able to implement ReleaseSemaphore and optimistic-case wait calls (where no blocking is reburied) without a server call. Blocking waits and any wait-multiple that cannot be resolved in the client process (e.g., bWaitAll=TRUE and objects include non-semaphores) is still handled by the server. (Implementing blocking wait calls on the client can yield some performance improvements because a context switch to another thread in the same program won't require swapping out the memory map & such, but I would expect this to be less significant.) However, upon further experimentation, I discovered that POSIX semaphores in glibc are actually implemented using a shared memory page, which may not be acceptable since a bad process can corrupt that page and potentially cause sem_* function calls in the server to fail as well as other client programs fail and/or deadlock. I am working on a System V adaptation, but I thought it would be a good idea to see feedback & comments now. Another problem is that this causes the threadpool test fails at line 1299, where the previous "release all semaphores and wait for callback" test is done in reverse order. I presume this is due to the nature of the linux scheduler being inconsistent with how Windows *happens* to schedule its threads. I have an idea for a fix for this already, but I will still have to dig deeper into it. The code is still in experimental quality (assert(0)s and such) and I've already re-worked the configure.ac stuff, I'm mostly concerned with feedback on the general scheme. Thanks! Daniel

5 46

Re: [PATCH 1/3] oledb32: Add DataConvert support of DBTYPE_VARIANT(NULL) to DBTYPE_DBDATE
by Nikolay Sivov 16 Sep '15

16 Sep '15

If it acts the same for all source variant types it looks like it'd be better to test them all and have this case handled once.

2 1

Re: [3/3] Add period to status bar, dialog box messages (try 2)
by Nikolay Sivov 16 Sep '15

16 Sep '15

On 15.09.2015 11:28, Florian Pelz wrote: > STRINGTABLE > { > - IDS_STATUS_DONE "Done" > + IDS_STATUS_DONE "Done." > IDS_STATUS_DOWNLOADINGFROM "Downloading from %s..." > } I don't think it's better really to have punctuation in status bars. Probably messages can live without it, unless they consist of multiple sentences, then last one needs termination too.

2 2

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin 16 Sep '15

16 Sep '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=16750 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0003012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Re: disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung 16 Sep '15

16 Sep '15

------------------------------ On Wed, Sep 16, 2015 3:45 AM BST Vincent Povirk wrote: >> Is there any way of doing this with 64-bit wine and 64-bit wine-mono? > >Currently, Wine does not have the ability to load pure .NET PE images >in a 64-bit process. > >Ntdll needs to call _CorValidateImage during the loading process. >_CorValidateImage needs to convert the image, in memory, to the >correct architecture. > >It's complicated, and I don't have a solution. Actually you do :-). Using http://madewokherd.nfshost.com/omgsecret/mono-64bit-exe.tar.gz from https://bugs.winehq.org/show_bug.cgi?id=30518 It is a bit dated, but does the job. I was very confused by both of libmono-2.0-x86_64.dll libmono-2.0-x86.dll MonoPosixHelper-x86_64.dll MonoPosixHelper-x86.dll in c:/windows/mono/mono-2.0/bin/ In fact libmono-2.0-x86_64.dll MonoPosixHelper-x86_64.dll are never used, at the moment. When 64-bit mono loads a .NET PE image which then P/Invoke, it does so P/Invoke to 64-bit dlls.

2 1

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION. (try 2)
by Dmitry Timoshkov 16 Sep '15

16 Sep '15

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > +void X11DRV_FlashWindow( HWND hwnd, BOOL bInvert ) > +{ > + struct x11drv_win_data *data = get_win_data( hwnd ); > + XEvent xev; > + > + if (!data) > + return; > + > + memset( &xev, 0, sizeof(xev) ); > + xev.type = ClientMessage; > + xev.xclient.window = data->whole_window; > + xev.xclient.message_type = x11drv_atom( _NET_WM_STATE ); > + xev.xclient.format = 32; > + xev.xclient.data.l[0] = 1; > + xev.xclient.data.l[1] = XInternAtom( data->display, "_NET_WM_STATE_DEMANDS_ATTENTION", > + False ); > + > + XSendEvent( data->display, DefaultRootWindow( data->display ), False, > + SubstructureNotifyMask, &xev ); > + release_win_data( data ); > +} This can't work, please have a look how XSendEvent is used in other parts of x11drv. -- Dmitry.

1 0

Re: [PATCH 2/2] winex11.drv: Implement FlashWindow with UrgencyHint flag.
by Dmitry Timoshkov 16 Sep '15

16 Sep '15

Jactry Zeng <jzeng(a)codeweavers.com> wrote: > This patch only set UrgencyHint flag when the window is minimized. > Because X11 only define UrgencyHint, the specific UI effect is > implemented by WM/DE. Different WM/DE may have different UI effect > which is quite different from Windows. Probably FlashWindow should be implemented with _NET_WM_STATE_DEMANDS_ATTENTION instead. -- Dmitry.

2 1

disabling wow64, testing 64-bit wine-mono P/invoke
by Hin-Tak Leung 16 Sep '15

16 Sep '15

Hi, I am not having any luck trying to disable wow64 temporarily to test 64-bit wine-mono P/invoke . I tried moving syswow64, removing 32-bit wine, moving wow32.dll, etc. It either insists on p/invoking 32-bit dlls, or not recognizing the .net assembly at all. What I like to do is to test a pure 64-bit code-path - starting with neutral .net assembly, p/invoke to 64-bit dll's. This is possible on windows - in fact cmd.exe on win 8 64-bit will refuse to p/invoke to 32-bit dll's. Is there any way of doing this with 64-bit wine and 64-bit wine-mono? Hin-Tak

2 1

Re: [PATCH 3/4] xaudio2: Call OnStreamEnd callback
by Marvin 16 Sep '15

16 Sep '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=16733 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB6EDD4B7D === w1064 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFC549A4B7D

1 0

Re: [PATCH] mshtml: Fixed tests on some Windows versions.
by Marvin 16 Sep '15

16 Sep '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=16726 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 === w1064 (64 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132

1 0

Re: ieframe: Fixed tests on some VMs.
by Marvin 16 Sep '15

16 Sep '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=16725 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2975: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2980: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE === w1064 (32 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 === w1064 (64 bit webbrowser) === webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 137 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 132 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182 webbrowser.c:469: Test failed: unexpected nCmdID 63 webbrowser.c:469: Test failed: unexpected nCmdID 182

1 0

Re: [PATCH 7/7] wined3d: remove wined3d_surface_preload
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; You don't need this anymore.

1 0

Re: [PATCH 5/7] wined3d: remove wined3d_volume_from_resource from the public api
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 7fb136d..49ed8db 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2332,6 +2332,7 @@ BOOL volume_prepare_system_memory(struct wined3d_volume *volume) DECLSPEC_HIDDEN > HRESULT wined3d_volume_create(struct wined3d_texture *container, const struct wined3d_resource_desc *desc, > unsigned int level, struct wined3d_volume **volume) DECLSPEC_HIDDEN; > void wined3d_volume_destroy(struct wined3d_volume *volume) DECLSPEC_HIDDEN; > +struct wined3d_volume *wined3d_volume_from_resource(struct wined3d_resource *resource) DECLSPEC_HIDDEN; You never want to use this from inside wined3d. If there are any callers they should use volume_from_resource() instead.

1 0

Re: [PATCH 3/7] wined3d: introduce new wined3d_texture_(un)map functions
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:14, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static const struct wined3d_texture_ops texture2d_ops = > { > texture2d_sub_resource_load, > @@ -924,6 +935,8 @@ static const struct wined3d_texture_ops texture2d_ops = > texture2d_sub_resource_validate_location, > texture2d_sub_resource_upload_data, > texture2d_prepare_texture, > + texture2d_sub_resource_map, > + texture2d_sub_resource_unmap, > }; > Please keep the various sub_resource operations together. (I.e., keep texture_prepare_texture last.) You're probably also missing some wined3d_private.h changes here that ended up in the next patch. It doesn't make sense to introduce these without users, so what you'd want to do is e.g. first make the change for d3d10_texture2d_Map(), then for d3d10_texture2d_Unmap(), etc.

1 0

Re: [PATCH 2/7] wined3d: pass a wined3d_box to wined3d_surface_map
by Stefan Dösinger 15 Sep '15

15 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:13 schrieb Riccardo Bortolato: > + hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect ? (const struct wined3d_box *)&box : NULL, flags); Why do you need the cast? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9x41AAoJEN0/YqbEcdMw5H4P/i9IrXL1PHd3pzoSmu2ObeSg rYWjMykbp0rh39JwXioBnMqbOCfneEjCSESHGqChNYQ4ZUHyMa6v8M0SOelvxlsA s9sQDs1YBRreXHTMlJSze4/jkHuOSFPCCiVueYLXsyoPunjER+KielzvICZ7lFYQ MQtHi6VwvUDiZJb7UaU3EeiUz2Drxq/Tki5OOgl+NS0rVQXRrecaA3qimPKEpbpI SkXChNulMWHM5q1cboxfP585R7SX12RnirNH0Wwx5kgv21gnvJGVB4eLirPNeKvA FnYAeGqo0ct3ruY9O77UMQFZTbAfn20Jv1EP4ZD0dAhUaUeSzPKQ9I68f+LYC5tG jiwZ7+8E/ReGWXRWcmHF3gnp3SumFl4RtQl8oz4jcqwoH42+xaaSMn5NDam4Hx0s sImgiqEG1ga7sCTOFUIL3q+0XkCpmXMwsjuBxxdZO1qRzSw9MlSgf1BpGsl3rJUb gHI4E+CsgHgUtP8ANyAPJBEbX87JEZ4SDycPwvgNIPQL84hRi0j+FvTJuJe26SN3 47qorsnjy9i/HrtTZXu613qhB07oMedyowWFRqI4EhRv8aKBUB6efzo8/LVHNU2v Sdfy3iI6d6Z+01sZa7nkdbAxeeASfEJ0tSKYN8ikRe0ahPhbRSFU0aD3/4+smQT6 EHW5Os4oDmiycqCxwogK =PePB -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/7] wined3d: store wined3d_texture and sub_resource_idx in d3d8, d3d9 and ddraw surfaces and volumes
by Henri Verbeet 15 Sep '15

15 Sep '15

On 14 September 2015 at 13:13, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index d12805f..d1eebbb 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -193,10 +193,13 @@ struct d3d9_volume > struct d3d9_resource resource; > struct wined3d_volume *wined3d_volume; > struct d3d9_texture *texture; > + struct wined3d_texture *wined3d_texture; > + UINT sub_resource_idx; I'd prefer "unsigned int", but it's not that important. We'll probably want "wined3d_texture" and "sub_resource_idx" before "wined3d_volume". > -void volume_init(struct d3d9_volume *volume, struct d3d9_texture *texture, > - struct wined3d_volume *wined3d_volume, const struct wined3d_parent_ops **parent_ops) DECLSPEC_HIDDEN; > +void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > + const struct wined3d_parent_ops **parent_ops, > + struct wined3d_texture *wined3d_texture, unsigned int sub_resource_idx) DECLSPEC_HIDDEN; Please keep "parent_ops" the last parameter. You don't need the wined3d_volume parameter here. Affects the device_parent calls as well. > @@ -5395,6 +5395,7 @@ HRESULT wined3d_surface_create(struct wined3d_texture *container, const struct w > struct wined3d_surface *object; > void *parent; > HRESULT hr; > + UINT sub_resource_idx = layer * container->level_count + level; This probably doesn't need its own variable. I think it makes sense to split this patch in two, one making the change for volumes, and one making the change for surfaces.

1 0

Re: [PATCH 8/8] d3d11/tests: Add basic test for ID3D11InputLayout.
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1277,4 +1334,5 @@ START_TEST(d3d11) > test_depthstencil_view_interfaces(); > test_create_rendertarget_view(); > test_create_shader_resource_view(); > + test_create_input_layout(); > } I don't think this needs its own test. There will be plenty of places that create input layouts once we start drawing things. If nothing else, d3d10core has the test_il_append_aligned() test that tests some more specific input layout things.

1 0

Re: [PATCH 3/8] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 01:37, Józef Kucia <jkucia(a)codeweavers.com> wrote: > There's an ugly check if *immediate_context is NULL. It will go away > when we have a stub interface for the immediate context. > --- That usually means the ordering of the patches isn't quite right. :) Although I suppose it's not too bad in this case, but you should at least add some kind of FIXME comment. > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Looking at the associated test, you may have misunderstood what I meant yesterday. If "swapchain_out" is NULL, you're creating a swapchain only to release it right away again. It may be the case that that's correct because of the side effects like the validation of swapchain_desc and potential window messages that end up being sent, but I suspect we should simply skip creating the swapchain.

1 0

regsvr32.exe tests
by Hugh McMaster 15 Sep '15

15 Sep '15

Over the past few weeks I've been sending a number of patches for regsvr32.exe to the wine-patches mailing list. Those patches are the product of a new test suite written for regsvr32.exe. The good news is that all of the tests now pass on Wine. The bad news is that the test suite is not suitable for wine-patches because I haven't been able to produce the test DLLs at runtime. The PE header format is complicated and I'm not too sure what I'm doing. In the meantime, anyone who is interested in the regsvr32.exe tests can download the source and test DLLs from the link below. https://www.dropbox.com/sh/39sytyithd76x97/AAD-FntoMfEvhvrqAnWyW6QJa?dl=0 Any comments on the tests and/or help with the PE header issue etc. are welcome.

1 0

Re: [2/2] winhttp: Add custom implementation of IWinHttpRequest::Invoke(DISPID_HTTPREQUEST_OPTION).
by Jacek Caban 15 Sep '15

15 Sep '15

Hi Dmitry, On 09/02/15 07:44, Dmitry Timoshkov wrote: > + if (member == DISPID_HTTPREQUEST_OPTION) Why can't we use standard, ITypeInfo-based implementation here? > + { > + VARIANT ret_value, option; > + UINT err_pos; > + > + if (!result) result = &ret_value; > + if (!arg_err) arg_err = &err_pos; > + > + VariantInit( &option ); > + VariantInit( result ); > + > + if (flags == DISPATCH_PROPERTYPUT) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_put_Option( &request->IWinHttpRequest_iface, V_I4( &option ), params->rgvarg[0] ); > + if (FAILED(hr)) > + WARN("put_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + else if (flags & (DISPATCH_PROPERTYGET | DISPATCH_METHOD)) > + { > + hr = DispGetParam( params, 0, VT_I4, &option, arg_err ); > + if (FAILED(hr)) return hr; > + > + hr = IWinHttpRequest_get_Option( &request->IWinHttpRequest_iface, V_I4( &option ), result ); > + if (FAILED(hr)) > + WARN("get_Option(%d) failed: %x\n", V_I4( &option ), hr); > + return hr; > + } > + > + return S_OK; I don't think silently returning S_OK is right for not handled flags. Thanks, Jacek

2 9

Re: wined3d: Fix TRACE in shader_dump_decl_usage().
by Henri Verbeet 15 Sep '15

15 Sep '15

On 15 September 2015 at 11:11, Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > case WINED3D_SHADER_RESOURCE_TEXTURE_3D: > - TRACE("_volume"); > + TRACE("_3d"); I think the change makes sense, but it's not really a fix. We can essentially call this whatever we like. Originally this was based on the d3d9 naming where you have "dcl_volume". OpenGL and d3d10+ call these 3D textures.

1 0

Re: [PATCH] ntdll/tests: Skip RtlRandom tests on Windows 10.
by Austin English 15 Sep '15

15 Sep '15

On Mon, Sep 14, 2015 at 12:24 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Windows 10 uses a different algorithm for RtlRandom. > All the tests currently fail and produce tons of spam. > (There's already a similar case for Windows Vista.) > --- > dlls/ntdll/tests/rtl.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index 9a4ec48..f42e313 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -739,6 +739,16 @@ static void test_RtlRandom(void) > return; > } > > +/* > + * Windows 10 uses different algorithms, so skip the rest of the tests > + * until that is figured out. Trace output for the failures is about 23 MB! > + */ > + > + if (seed == 0x7fffffc3) { > + skip("Most likely running on Windows 10 which uses a different algorithm\n"); > + return; > + } > + > ok(result == result_expected, > "pRtlRandom(&seed (seed == 0)) returns %x, expected %x\n", > result, result_expected); > -- > 2.5.1 This should probably be win_skip() rather than skip(). -- -Austin

3 2

Re: [2/3] Use quotes around service names in net program.
by Nikolay Sivov 15 Sep '15

15 Sep '15

On 13.09.2015 18:51, pelzflorian(a)pelzflorian.de wrote: Please update resource file only, the rest will be regenerated with appropriate fuzziness (e.g. Russian strings are done wrong, regarding quotation marks).

2 3

Re: [PATCH 4/7] wined3d: replace wined3d_{surface, volume}_(un)map with wined3d_texture_(un)map
by Stefan Dösinger 14 Sep '15

14 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-14 um 13:14 schrieb Riccardo Bortolato: > -HRESULT __cdecl wined3d_surface_map(struct wined3d_surface *surface, > - struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > -void __cdecl wined3d_surface_preload(struct wined3d_surface *surface); The wined3d_surface_preload removal seems premature and should be in patch 7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV9yCsAAoJEN0/YqbEcdMwSh0P/1OCyBpwswYeaCD40J6YfpQb 8eXAgQlsbbqWQen6Zw+d0W3ixqJsrUJfnZM6gQu2vBp80RQxSNjuifizy3pJgXzy eHAuEWATtFrkGiyPF6EWjheGW7uM7FRyYt4DRXHCu+W3QnYkbpT0YXw7FhtGsPo2 GP/NzctDeGLwe0qrGyFtrg5WxhOA7RqdGaWIsAeMrcTiUzcS9Hbc0leTfYIJOprL bu5scnmKKobtadAOgB5um9hBSXynQzKLg8zzd5NzQMdqnRFJ3QTdZfw7YBtRpX63 0V6yVFztJgErsibvvyIUpTvGQIqq2KmAMpoDMR3p9NYzPEeyvLStnmqmHn5vZ8ZH KyP35umA552xYFQvxy/aAjttSovkrul7dv9X+W6HYW/HqwwU+XrEgCFHPpEwfM4Z 35i6onuZtrm0tSYdloCkf1hFmzn5R6izUrNvduxf64J7aSNJ3sZ2hYh56gGgSgCC uyJU9kp7SRXy7gBjEnwY95DN1V27v6+LR/VPoi2u5yaM9zAc2mOjzUBErsJSviNq phGCtnDKP6i25ajkIjEcmB9nGq7KIUV7EvgjuGz4hv4jrYtES3WsZYbPfJQs/hai pmPtOeCft7vZLkH/ZfzCx00Wggs0JwloJb5fPxDw1WYKiaq2zjXvL6yHivVqaiGN GqngsuTeKGkated3sg4H =gUhb -----END PGP SIGNATURE-----

1 0

Re: [PATCH 05/10] d3d11: Implement D3D11CreateDeviceAndSwapChain().
by Henri Verbeet 14 Sep '15

14 Sep '15

On 14 September 2015 at 00:13, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (swapchain_out) > + *swapchain_out = swapchain; > + else > + IDXGISwapChain_Release(swapchain); Is "desc" validated or modified in this case? Otherwise you could return a lot earlier. The test doesn't really cover that. > + hr = D3D11CreateDevice(adapter, driver_type, swrast, flags, feature_levels, levels, sdk_version, > + &device, NULL, NULL); > + if (FAILED(hr)) > + { > + WARN("Failed to create a device, returning %#x.\n", hr); > + *device_out = NULL; > + return hr; > + } ... > + > + if (obtained_feature_level) > + *obtained_feature_level = ID3D11Device_GetFeatureLevel(device); > + > + if (immediate_context) > + ID3D11Device_GetImmediateContext(device, immediate_context); This seems odd. Why not just pass these to D3D11CreateDevice()? If you like you can do things like the D3D11CreateDevice() call inside the if. I.e., "if (FAILED(hr = D3D11CreateDevice(...)))". I tend to do that for newer code, older code usually has it on separate lines.

2 2

WineTestBot test coverage
by Francois Gouget 14 Sep '15

14 Sep '15

When setting up the WineTestBot VMs I have tried to make it so we can compare their results across Windows versions so we know if a specific behavior is specific to a given Windows version or was introduced in a specific Windows version. At the same time I tried to diversify the Windows configurations to get better coverage of various locales, particularly when they involve right-to-left text or asian characters, but also to test other aspects like having multiple network cards, two disks, etc. While ideally the WineTestBot would be able to switch each VM between multiple configurations (through the use of snapshots), currently this is not supported. Thus we can only test as many configurations as we have VMs (and Windows licenses). As a result choices have to be made, the coverage is not complete and there may be room for improvement. For instance w7u is configured for Japanese because it's an asian language and I know we have developers who know Japanese. But it turns out a number of test failures are specific to Korean. Ideally we'd have both but there are only two VMs(*) that can be configured for non-English locales and the other one is configured to check for right-to-left issues (previously Arabic and now through Hebrew). Similarly all VMs run the tests with elevated privileges because that's what allows running the maximum number of tests. But this means tests are never tested in unprivileged accounts leading to a bunch of failures when that happens. So should we change the configuration of some of the WineTestBot VMs? Which aspects are the most important? An additional note is that I can relatively easily reconfigure a VM and then switch between that configuration and what we have now. So for instance I could switch the Japanese VM to Korean if a developer needs it to debug things, and then switch it back to Japanese when he's done. Between the timezone delays and WineTestBot's own, the latency would be around a day. So here is a summary of the available configurations. Let me know if there are changes to do: w2000pro IE 6 sp1, DirectX 9.0c, MSXML 4&6, VC 2005/8/10, IPX, AppleTalk, data CD wxppro IE 8, DirectX extras, MSXML 4, VC 2005/8/10, winpcap w2003std IE 8, .Net 2.0 SP2, 3.0 SP2, 3.5 SP2, 4, MSXML 4, VC 2005/8/10. wvista IE 9, .Net 3.5 SP1 & 4.5.1, RMP wvistau64 IE 8, Hebrew, tests on e:, DirectX extras, MSXML 4, VC 2005/10. winpcap w2008s64 IE 9, .Net 4.0, no sound, two network cards w7u IE 11, Japanese, .Net 3.5 & 4.5, VC 2012/13, data CD w7pro64 IE 11, .Net 4.5.1 w8 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w864 Win 8.1, IE 11, DirectX extras, MSXML 4, VC 2005/10. w1064 Edge, DirectX extras Legend: - DirectX extras: This installs some dlls that are not installed by default, for DirectMusic and DirectPlay for instance. - AppleTalk: The AppleTalk network protocol. - IPX: The IPX network protocol. - RMP: The Reliable Multicast Protocol network protocol. Known holes: * No Windows 8 (only Windows 8.1). * No IE 7 configuration. * No IE 10 configuration. * No non-elevated or regular user tests. * Korean locale. Other locales? * No mixed locale (to ensure the tests check the right locale API). (*) Though the locale of the new Windows 10 VM is probably configurable too. So that would be 3 VMs. But do we want to add failures to a VM that already has a lot? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 06/10] dxgi: Set BufferUsage in dxgi_swapchain_GetDesc().
by Henri Verbeet 14 Sep '15

14 Sep '15

Not that DXGI_USAGE_RENDER_TARGET_OUTPUT would necessarily be a bad default, but it's probably better to either just store a copy of the original DXGI_SWAP_CHAIN_DESC structure in the swapchain, and read it again here, or to pass the additional fields to wined3d somehow.

1 0

Re: [PATCH 1/2] user32: Implement semi-stub for FlashWindowEx. (resend)
by Marvin 14 Sep '15

14 Sep '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=16701 Your paranoid android. === w8 (32 bit win) === win.c:3278: Test failed: message 0118 available === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0006012C message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === wvistau64 (64 bit win) === win.c:7539: Test failed: transparent window didn't get WM_NCHITTEST message win.c:7540: Test failed: button under static window didn't get WM_LBUTTONUP === w864 (64 bit win) === win.c:1210: Test failed: first call to SetShellWindow(hwnd1) win.c:1212: Test failed: wrong shell window: 0000000000020118 win.c:1249: Test failed: SetShellWindow(hwnd4) win.c:1251: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1254: Test failed: wrong next window for hwnd4: 000000000002010C - expected 0 win.c:1265: Test failed: wrong shell window: 0000000000020118 - expected hwnd4 win.c:1275: Test failed: wrong next window for hwnd4 after SetWindowPos(): 000000000002010C - expected 0 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

1 0

Windows 10 available for testing on the WineTestBot
by Francois Gouget 14 Sep '15

14 Sep '15

The WineTestBot now has two new VM hosts to compensate for running fewer tasks per host. More importantly it now has a Windows 10 Home 64 bit VM (w1064). You can submit jobs to it at any time and I made it a base VM so Wine patches that fail on Windows 10 are detected. However you will not find a Windows 10 column on test.winehq.org because about 68 failures and a 24MB report Windows 10 reports are getting thrown away. With over 200 000 lines, the ntdll:rtl failure below is responsible for most of the spam: rtl.c:879: Test failed: test: 0x000000231 RtlUniform(&seed (seed == 79ddd72)) returns b60129c, expected 62bb10ce So some effort will be needed to remedy the situation. As a starting point here is a full WineTest report I collected on a Windows 10 install running on real hardware and a list of the failing tests. http://fgouget.free.fr/tmp/winetest32.report 2 advapi32:security 2 failures 1 cmd:batch 3 crypt32:base64 1 crypt32:chain 1 d2d1:d2d1 8 d3d8:device 4 d3d9:d3d9ex 2 ddraw:ddraw2 2 ddraw:dsurface 8 ddraw:overlay 12 dssenh:dssenh 9 dxgi:device 4 hlink:hlink 28 ieframe:webbrowser 18 kernel32:console 12 kernel32:loader 7 kernel32:locale 1 kernel32:process 1 kernel32:thread 4 kernel32:toolhelp 2 kernel32:volume 5 mmdevapi:capture 6 mmdevapi:render 1 msctf:inputprocessor 30 mshtml:htmldoc 1 mshtml:htmllocation 1 urlmon:protocol 2 msvcrt:locale (English locale) 1 msxml3:httpreq 10 ntdll:pipe 200010 ntdll:rtl 39 ntdll:threadpool 39 ole32:marshal 2 oleaut32:olepicture 3 rpcrt4:server 65 rsaenh:rsaenh 2 secur32:schannel 1 setupapi:devinst 30 shell32:ebrowser 3 shell32:shelllink 7 shell32:shlexec 1 shell32:shlfolder 2 shlwapi:assoc 6 taskschd:scheduler 1 urlmon:misc 12 urlmon:protocol 19 urlmon:uri 27 user32:broadcast 1 user32:class 55 user32:cursoricon 2 user32:monitor 1 user32:dde 6 user32:msg 10 user32:win 15 usp10:usp10 16 wininet:http 4 wininet:internet 4 winmm:midi 2 wintrust:crypt 1 ws2_32:sock 2 wscript.exe:run -- Francois Gouget <fgouget(a)free.fr>

1 0

wined3d public api cleanup
by Riccardo Bortolato 14 Sep '15

14 Sep '15

Here is a follow up on the small fixes I sent the other day. I'm storing the wined3d texture and sub level in the d3dX surfaces/volumes and this allows to go further with the removal of surfaces/volumes from the public api. With these commits I also introduce a temporary function to handle mapping for surfaces and volumes which I hope it will gradually handle more of that eventually delegating only bound checks (and maybe other minor things) to helper functions. Finally the remaining volume-related exported functions are removed. What to do with buffers is still unclear to me. Ciao, Riccardo

3 14

Re: [PATCH] riched20: Implement set all caps(Ctrl+Shift+A) shortcut key.
by Nikolay Sivov 14 Sep '15

14 Sep '15

On 14.09.2015 12:25, Jactry Zeng wrote: > + for (i = 0; i < len; i++) > + { > + WCHAR tmp = bufferW[i]; > + > + if (isalphaW(tmp)) > + { > + if (editor->bCaps) > + bufferW[i] = toupperW(tmp); > + else > + bufferW[i] = tolowerW(tmp); > + } > + } Hi, won't struprW/strlwrW work here? I don't see why isalphaW check is important.

1 0

Re: [2/5](resend/rebased)hidclass.sys: Add USB Descriptor parsing
by Alexandre Julliard 14 Sep '15

14 Sep '15

Aric Stewart <aric(a)codeweavers.com> writes: > + if (!caps->IsRange) > + { > + static char out[30]; > + unsigned int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("0x%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; Having a static buffer defeats the purpose of using wine_dbg_sprintf. > +static void debug_feature(struct feature *feature) > +{ > + if (!feature) > + return; > + TRACE("[\n\t type %s [%i]; %s; %s; %s; %s; %s; %s; %s; %s; %s\n\t %s\n]\n", Please don't put \n in traces, that messes up the output. If you truly need multiple lines, use separate TRACE statements. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 10/10] dxgi/tests: Remove leftover debug comment.
by Marvin 14 Sep '15

14 Sep '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=16696 Your paranoid android. === w1064 (32 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1134: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1188: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1134: Test failed: Got unexpected hr 0, test 39. device.c:1188: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1188: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [PATCH 09/10] dxgi/tests: Add missing DestroyWindow() call in test_createswapchain().
by Marvin 14 Sep '15

14 Sep '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=16695 Your paranoid android. === w1064 (32 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1134: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1134: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1188: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1188: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1134: Test failed: Got unexpected hr 0, test 39. device.c:1188: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1188: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [PATCH 08/10] dxgi/tests: Check that DXGI surface implements ID3D11Texture2D.
by Marvin 14 Sep '15

14 Sep '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=16694 Your paranoid android. === w1064 (32 bit device) === device.c:1133: Test failed: Got unexpected hr 0, test 16. device.c:1133: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1133: Test failed: Got unexpected hr 0, test 16. device.c:1187: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1187: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1187: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1187: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1133: Test failed: Got unexpected hr 0, test 39. device.c:1187: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1187: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: [06/10] msvcirt: Implement strstreambuf::setbuf
by Marvin 13 Sep '15

13 Sep '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=16671 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1521: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1527: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [05/10] msvcirt: Implement strstreambuf::doallocate
by Marvin 13 Sep '15

13 Sep '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=16670 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1517: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1523: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [03/10] msvcirt: Implement strstreambuf::freeze
by Marvin 13 Sep '15

13 Sep '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=16669 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1513: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1519: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: [02/10] msvcirt: Implement strstreambuf constructors and destructor
by Marvin 13 Sep '15

13 Sep '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=16668 Your paranoid android. === w2000pro (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === wxppro (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF === w2003std (32 bit msvcirt) === msvcirt.c:1510: Test failed: wrong buffer end, expected 0022FC70 + 0x7fffffff got FFFFFFFF msvcirt.c:1516: Test failed: wrong put end, expected 0022FC70 + 0x7fffffff got FFFFFFFF

1 0

Re: po: German translation: Fix hyphenation
by Julian Rüger 13 Sep '15

13 Sep '15

Sorry for being late, had a busy week. I realize they are already in, but I have some remarks anyway. I fully agree with most of these. There are some examples of ugly translations in there, though. (Not your fault of course) It would be great if you/we could fix some of these, while we're at it. > #: crypt32.rc:105 > msgid "Unsigned CMC Request" > -msgstr "Unsignierte CMC Antwort" > +msgstr "Unsignierte-CMC-Antwort" First hyphen is wrong, that's an adjective and a noun. #: crypt32.rc:110 msgid "PKCS 7 Signed" -msgstr "PKCS 7 signiert" +msgstr "PKCS-7-signiert" #: crypt32.rc:111 msgid "PKCS 7 Enveloped" -msgstr "PKCS 7 umhüllt" +msgstr "PKCS-7-umhüllt" [... and similar] These feel wrong. I'm not sure what would be correct, but I suspect "PKCS-7, signiert" or "[Umhülltes/Signiertes] PKCS-7" would be correct. (These are descriptions of file types to open, right?) #: crypt32.rc:150 cryptui.rc:134 msgid "Windows System Component Verification" -msgstr "Windows System Komponenten Verifizierung" +msgstr "Windows-System-Komponenten-Verifizierung" [... and 2 similar] "Windows-Systemkomponentenverifizierung" would be grammatically correct, I think. It's a freaking long word though... #: crypt32.rc:160 msgid "IP security IKE intermediate" -msgstr "Dazwischenliegende IP Sicherheits-IKE" +msgstr "Dazwischenliegende IP-Sicherheits-IKE" Something like "temporäre" or "Übergangs-..." would better reflect the meaning. Dazwischenliegend is just wrong. I remember not having anything better, so I left these alone. Ideas? #: winerror.mc:3536 msgid "Security package error.\n" -msgstr "Sicherheitspaket Fehler.\n" +msgstr "Sicherheitspaket-Fehler.\n" "Sicherheitspakets-Fehler"? "Fehler im Sicherheitspaket"? #: winerror.mc:3701 msgid "Not all objects could be exported.\n" @@ -6844,9 +6844,9 @@ msgstr "" "Protokollierung und Benutzeroberfläche für die oberen Befehle anpassen:\n" "\t/l[*][i|w|e|a|r|u|c|m|o|p|v|][+|!] Protokolldatei\n" "\t/q{|n|b|r|f|n+|b+|b-}\n" -"MSI Service registrieren:\n" +"MSI-Service registrieren:\n" "\t/y\n" -"Registrierung des MSI Service aufheben:\n" +"Registrierung des MSI-Service aufheben:\n" While we're at it, this should be "MSI-Dienst", imho. #: msvidc32.rc:29 msgid "Wine Video 1 video codec" -msgstr "Wine Video 1 Video Codec" +msgstr "Wine-Video-1-Video-Codec" "Videocodec" seems to be a word (https://de.wikipedia.org/wiki/Videocodec ), but I would just say "Wine-Video-1-Codec". Still feels clumsy somehow... #: shdoclc.rc:28 msgid "Wine Internet Explorer" -msgstr "Wine Internet Explorer" +msgstr "Wine-Internet-Explorer" While technically right, this looks "wrong" somehow. Stichwort: Eigenname? -"$d aktuelles Datum $e Escape $g > Zeichen\n" -"$l < Zeichen $n aktuelles Laufwerk $p aktueller Pfad\n" +"$d aktuelles Datum $e Escape $g Größerzeichen (>)\n" +"$l Kleinerzeichen (<) $n aktuelles Laufwerk $p aktueller Pfad\n" Nice one! #: ipconfig.rc:49 msgid "Default gateway" -msgstr "Standard Gateway" +msgstr "Standard-Gateway" "Standardgateway"? #: net.rc:37 msgid "The %1 service is starting.\n" -msgstr "Der %1 Dienst startet.\n" +msgstr "Der Dienst %1 startet.\n" Why go half-way? ;) "Der Dienst '%1' startet.\n" #: taskmgr.rc:322 msgid "System Idle Process" -msgstr "Leerlauf Prozess" +msgstr "Leerlauf-Prozess" "Leerlaufprozess" (I think it's OK to copy Windows here) #: winecfg.rc:143 msgid "Windows registration information" -msgstr "Windows Registrierungs-Informationen" +msgstr "Windows-Registrierungs-Informationen" "Registrierungsinformationen"

3 7

Re: [website] Update Debian downloads info
by Jeremy Newman 12 Sep '15

12 Sep '15

Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page. -N On 07/22/2015 01:43 PM, Rosanne DiMesio wrote: > Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page. > > > >

8 18

Re: [3/5] comdlg32: Return success from IFileDialog2::AddPlace.
by Marvin 11 Sep '15

11 Sep '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=16659 Your paranoid android. === w7u (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 76A81EA3

1 0

Re: TestBot job 16658 results: [PATCH 3/3] xaudio2: Support looping buffers
by Andrew Eikum 11 Sep '15

11 Sep '15

On Fri, Sep 11, 2015 at 11:48:29AM -0500, Marvin wrote: > xaudio2_7:xaudio2 start - - > xaudio2.c:244: this is the last test seen before the exception > xaudio2: unhandled exception c0000005 at 00007FFB69944B7D > xaudio2_7:xaudio2 done (3221225477) This isn't caused by this patch. It's a crash only on the 64-bit tests. I'm looking into it. Andrew

1 0

Re: [PATCH 3/3] xaudio2: Support looping buffers
by Marvin 11 Sep '15

11 Sep '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=16658 Your paranoid android. === w864 (64 bit xaudio2) === xaudio2: unhandled exception c0000005 at 00007FFB69944B7D

1 0

Re: msi: Fix MsiProvideQualifiedComponent test failure
by Marvin 11 Sep '15

11 Sep '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=16657 Your paranoid android. === w7u (32 bit action) === The test timed out

1 0

Re: [PATCH] ddraw/tests: add test for surface preload (v4)
by Marvin 11 Sep '15

11 Sep '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=16651 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 2/2] ddraw/tests: add test for surface preload (v3)
by Stefan Dösinger 11 Sep '15

11 Sep '15

> Am 10.09.2015 um 13:48 schrieb Riccardo Bortolato <rikyz619(a)gmail.com>: > > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE; > + hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); > + > + hr = IDirect3DDevice7_GetCaps(device, &device_desc); > + ok(SUCCEEDED(hr), "Failed to get device caps, hr %#x.\n", hr); > + cubemap_supported = !!(device_desc.dpcTriCaps.dwTextureCaps & D3DPTEXTURECAPS_CUBEMAP); > + > + IDirectDrawSurface7_Release(surface); This surface isn't used anywhere. I'd prefer if you add a comment that says that surfaces other than textures cause a segfault if they're passed to PreLoad. I think the best place is to put this somewhere near the test table.

1 0

Re: [1/2] d3dx9_36: Implement D3DXGetShaderInputSemantics (try 2)
by Matteo Bruni 11 Sep '15

11 Sep '15

2015-09-10 10:53 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > patch by Christian Costa > > Change to use 1u << 31 > > > Changelog: > d3dx9_36: Implement D3DXGetShaderInputSemantics > > > Best Regards > Alistair Leslie-Hughes Petty bickering aside, in general sending patches with git send-email makes so that I can easily inline my comments in the code. Sending your own patches yourself makes so that I'm replying to the actual patch author, which usually is the one who should update the patch according to my review. You're free to ignore those points but that doesn't help with my will to put the effort required to review the patches. Anyway, this patch requires some cleanup (most obviously, using the appropriate defines like D3DSP_REGTYPE_SHIFT instead of all those magic numbers). Also I'm interested in seeing tests with pixel shaders, especially shader model 1 and 2 pixel shaders.

3 3

Re: [PATCH 1/2] oledlg: Improve menu items localization for OleUIAddVerbMenuW()
by Akihiro Sagawa 11 Sep '15

11 Sep '15

On Tue, 08 Sep 2015 16:45:18 +0300, Nikolay Sivov wrote: > --- a/dlls/oledlg/oledlg.rc > +++ b/dlls/oledlg/oledlg.rc > @@ -30,7 +30,9 @@ STRINGTABLE > IDS_NOTOLEMOD "File does not appear to be a valid OLE module. Unable to register OLE control." > IDS_NOTOLEMODCAPTION "Add Control" > IDS_VERBMENU_OBJECT "&Object" > + IDS_VERBMENU_OBJECT_WITH_NAME "%s &Object" > IDS_VERBMENU_CONVERT "&Convert..." > + IDS_VERBMENU_SINGLEVERB_OBJECT "%1 %2 &Object" This patch has been commited, but you may want to use %1, instead of %s, for IDS_VERBMENU_OBJECT_WITH_NAME. Akihiro Sagawa

2 3

Re: [PATCH 2/2] ddraw/tests: add test for surface preload (v3)
by Marvin 11 Sep '15

11 Sep '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=16632 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [PATCH 1/2] ddraw/tests: add test for surface preload (v2)
by Marvin 11 Sep '15

11 Sep '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=16628 Your paranoid android. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [2/2] d3dx9_36: Implement D3DXGetShaderOutputSemantics (try 2)
by Matteo Bruni 10 Sep '15

10 Sep '15

2015-09-10 10:53 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > d3dx9_36: Implement D3DXGetShaderInputSemantics > > > Best Regards > Alistair Leslie-Hughes Is it correct that this is your patch and not Christian's? Just doublechecking.

2 1

Re: [4/4] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 10 Sep '15

10 Sep '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=16613 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [3/4] oleaut32: Add support for handling VT_VARIANT|VT_ARRAY|VT_BYREF argument type. Resend.
by Marvin 10 Sep '15

10 Sep '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=16612 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [2/4] oleaut32/tests: Add another test for calling a varargs method. Resend.
by Marvin 10 Sep '15

10 Sep '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=16611 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [1/2] d3dx9_36: Implement D3DXGetShaderInputSemantics (try 2)
by Nikolay Sivov 10 Sep '15

10 Sep '15

It's preferred to have original author submitting his own work. Christian, ping?

5 7

Re: gdi32/tests: Avoid excessive traces for fonts with OS/2 version 4 tables
by Marvin 10 Sep '15

10 Sep '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=16629 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 6/8] wined3d: replace wined3d_surface_preload with wined3d_texture_preload
by Henri Verbeet 10 Sep '15

10 Sep '15

On 9 September 2015 at 12:23, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > static void WINAPI d3d9_surface_PreLoad(IDirect3DSurface9 *iface) > { > struct d3d9_surface *surface = impl_from_IDirect3DSurface9(iface); > + struct d3d9_texture *texture = surface->texture; > > TRACE("iface %p.\n", iface); > > + /* Standalone surfaces can't be in D3DPOOL_MANAGED */ > + if (!texture) > + return; > + > wined3d_mutex_lock(); > - wined3d_surface_preload(surface->wined3d_surface); > + wined3d_texture_preload(texture->wined3d_texture); > wined3d_mutex_unlock(); > } > This isn't necessarily wrong, but it may be too complicated. In particular, at some point we'll have to do maps for e.g. off-screen plain surfaces as well, and then you can't avoid getting the wined3d texture from somewhere. That probably means either creating an implicit d3d9 texture for those surfaces, or just storing a pointer to the wined3d texture in the d3d9 surface. So I'd like to see map()/unmap() before preload().

2 1

Re: po: Update Lithuanian translation
by Nikolay Sivov 10 Sep '15

10 Sep '15

Not specific to Lithuanian, I just want to mention context this new translatable string is in, that could help translators: > #: oledlg.rc:36 > -#, fuzzy > -#| msgid "&Object" > msgid "%1 %2 &Object" > -msgstr "&Objektas" > +msgstr "%1 %2 &objektas" %1 here is a verb that application provides - an action performed on Object (e.g. Open), %2 is for application provided object name/type action is performed on. So for English it could be something like "Open Bitmap Object". Some locales use different word order, that's why I used indexed argument format, see for example Korean https://bugs.winehq.org/show_bug.cgi?id=39243: > "test \ac1c\ccb4 verb(&O)" 'test' is object type, and 'verb' is a string for verb.

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '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=16604 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7: unhandled exception c0000005 at 68084F1E

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Marvin 10 Sep '15

10 Sep '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=16603 Your paranoid android. === w2000pro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wxppro (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2003std (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w2008s64 (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === w7u (32 bit device) === device: unhandled exception c0000005 at 0041DAE4 === wvistau64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8 === w2008s64 (64 bit device) === device: unhandled exception c0000005 at 0000000000419CD8

1 0

Re: msi: Check HKLM/Software/Classes/Installer/Components path while looking for components
by Marvin 09 Sep '15

09 Sep '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=16596 Your paranoid android. === w2008s64 (32 bit action) === action.c:5915: Test failed: MsiProvideQualifiedCompontent returned 1607

1 0

Re: [PATCH 4/8] d3d9/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have some nitpicky style comments. I don't demand that they are addressed, I'm ok with the patch as it is if Henri accepts it. > + IDirect3DSurface9 *backbuffer, *stencilsurface, *offscreensurface, *rendertarget, *rendertarget2; You shouldn't need the two rendertarget variables. In fact, one common surface variable should do, and I don't think it would make the test more difficult to read. > + hr = IDirect3DDevice9_GetRenderTarget(device, 0, &rendertarget); > + ok(SUCCEEDED(hr), "GetRenderTarget failed, hr %#x.\n", hr); > + IDirect3DSurface9_PreLoad(rendertarget); > + IDirect3DSurface9_Release(rendertarget); We already know from other tests that on device creation backbuffer 0 is the render target. I don't think it's necessary to explicitly test render target 0. > + hr = IDirect3DDevice9_GetBackBuffer(device, 0, 0, 0, &backbuffer); "D3DBACKBUFFER_TYPE_MONO" would be better than "0". Yeah, I know many other tests use 0, and I just sent a patch that shows that this parameter is just ignored... Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JlBAAoJEN0/YqbEcdMwNCkP/2aqOA8gTfOb1kE4GkaiKRYk L6sks0mVbtu0nDG/futVUEFniYzQEJNNOabBi/2vcIWFKIOpGALlKGFxbXc3MRC/ +TEIMYq9p1iOsDL1T3tMx+tR39vfG3nFh+FNcZe0nDzT1PmWU5egAdp+IXzY/rR1 qPMQiyFF3ppbvgPi16WAWvnDqHao4+YGoAUFtiiZEBKF8+xA3LiUimuyJnaHYUWj 6caXL1e/DLE/6o7dlJr1YbDmA6IDUYAi029ANv45Upyhf8VCBknpQ1YShRJ+Wt6m g96I/lRtLCpYq8Y8lLTrE6ZD9/8eRkUIxt8jzw8s+gpGtg1wwaR4Y+pzUkrqSRfR OyTzXAFDTI7hNbHfeUHw1EkrT/Ef2H66g9eoMZYVgDJM9ZmfHvgwENPjClTRO2nZ 5jCt14lhZD3Cpdw8+K6AqgPZVtZGyVs4Z0pkO9w7pcfLHTtuWAKh7NfikzXqzyAE zBJ/PtOxdY5BooCZ7ZPuQ0Dblz7wt11m+t6Y7+Jkni0qeH+EetDXDaL4G+ZbmV4V 1gZu5QOaFwNDTIrOU8W94R66oCeAx2YryQgejk4PmHN3UHO3GuQ5irUQlfOGZi/z WO2YZcU3+wCAdZXopgE7kIkaBE+Y2VWKtBUgLGPeiglApaq5SfKncALa5iPACpzN bmSeigvhzA2FKICkLYil =9uRC -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/8] ddraw/tests: add test for surface preload
by Stefan Dösinger 09 Sep '15

09 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-09 um 19:02 schrieb Riccardo Bortolato: > + hr = IDirectDraw7_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + if (FAILED(IDirectDraw7_QueryInterface(ddraw, &IID_IDirect3D7, (void **)&d3d))) > + { > + skip("D3D interface is not available, skipping test.\n"); > + goto done; > + } > + > + hr = IDirect3D7_EnumDevices(d3d, enum_devtype_cb, &hal_ok); > + ok(SUCCEEDED(hr), "Failed to enumerate devices, hr %#x.\n", hr); > + if (hal_ok) > + devtype = &IID_IDirect3DTnLHalDevice; > + > + memset(&z_fmt, 0, sizeof(z_fmt)); > + hr = IDirect3D7_EnumZBufferFormats(d3d, devtype, enum_z_fmt, &z_fmt); > + if (FAILED(hr) || !z_fmt.dwSize) > + { > + skip("No depth buffer formats available, skipping test.\n"); > + goto done; > + } > ... There is a helper function called create_device for this. > + IDirect3DDevice7_PreLoad(device, surface); This incarnation of PreLoad returns a value. It's probably always D3D_OK, but please test it for success / failure. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8JT4AAoJEN0/YqbEcdMw4zQP/23zlgm39IW26Wga1gKx4gmJ 2nCC01cpnjsr6TxOH/TYdWNxbXncmG45UlPbCe3H2TU57Aro/dcDAAG4epswuhNU 0rd7TMgkwhUJ+6PDgiYUGdhab30Oem0IvWdS+Z8RNZAdwarpcsbQgIvvpMDMiRgF sNkpCdr2aFVJbjUU9c0sgswumQxOCgok1Z4s6cSOHDK8UmRMRDob1E9U/3QQ77d2 JdsZYeAsTjxWzznX4S77+SklIUaF+ga2noTqOzUf4IHZhJc/2KgMW/r2ZmRYAHxH FyP6E02aVhnhD+PjH3lCBQXGvdQ+oE40Bvtt8ZMMvWP9JkS4ZtkLOC24UYD4jt03 4zPVt1WvqZ7LQFEKjKSfEZMG9wRkMYu/69YVxy5A+QgBiVPLyW2cNTk8FbKRG9mU C5ctjIwhgWVzldSv2kLNeuSDgFr+ybo9BuvBySjzHSabvXaJ8jAsj30zG5UwPOmV e/FjZUzhrK+oAFGPSeZvHauoE14gskPR2V0jNV7h3gXfwvy2thwYWOksS6QihpA1 Rx67RgS8uxre7VfxsqCQsFl8irE/wmKYsGIpqMGYiAFNETCigFuz8nmDBx0I4Oqo ZGmOYATtU09Ap8WVEtcwSLdHbVRy9UF/aStRI1dAeWcFcXxXdEZvop7jWaNMaEmZ V90SEh1KkRgOew5ZkDXp =RHsN -----END PGP SIGNATURE-----

1 0

Re: [PATCH] xaudio2: Use ffmpeg to convert non-PCM formats
by Henri Verbeet 09 Sep '15

09 Sep '15

On 9 September 2015 at 17:26, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > I've discussed other options with people on IRC, including: > > Build and distribute our own Windows FFmpeg package, or ask the user to > install a Windows FFmpeg package in their wineprefix, instead of relying > on the system FFmpeg. Maybe a workable solution, but we'd have to build > and distribute yet another package, or rely on a 3rd party to do so. > There may also be optimization concerns with a package built for Windows > instead of natively on Linux/OSX. > > Find a different WMA decoding library. While one exists (libwmapro), it > is simply pulled out of FFmpeg and converted for use on iPods. It's > several years of out date with FFmpeg's WMA decoder. No other open > source WMA decoder exists that I'm aware of. > > Pull FFmpeg's WMA code out and use it in Wine directly. This would > require a significant amount of effort and ongoing work to pull in > updates. I'm not convinced this is worth the effort. > Mostly for completeness, I think "fix gstreamer" was also mentioned as an option at some point.

1 0

Re: dwrite/tests: Some tests for TranslateColorGlyphRun()
by Marvin 09 Sep '15

09 Sep '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=16598 Your paranoid android. === build (build) === Could not copy the patch to the VM: Timed out in create_socket while connecting to testnet.winehq.org:22001:10.42.42.130:4242

1 0

Re: [PATCH 2/3] wineps.drv: Add support for PostScript Format 2 standard glyph names (try 3).
by Huw Davies 09 Sep '15

09 Sep '15

On 8 Sep 2015, at 18:30, Erich E. Hoover wrote: > +WORD get_post2_name_index(BYTE *post2header, DWORD size, WORD index) > +{ > + USHORT numberOfGlyphs = GET_BE_WORD(post2header); > + DWORD offset = (1 + index) * sizeof(USHORT); > + > + if((1 + numberOfGlyphs) * sizeof(USHORT) > size) > + { > + FIXME("Total number of glyphs (%d) exceeds PostScript Format 2 table size (%d)\n", > + numberOfGlyphs, size); > + return 0; /* .notdef */ > + } Personally, I'd remove this check, you only added it because you misunderstood something I suggested. What we actually care about is covered by the check below. > + if(offset + sizeof(USHORT) > size || index >= numberOfGlyphs) > + { > + FIXME("Index '%d' exceeds PostScript Format 2 table size (%d)\n", index, numberOfGlyphs); > + return 0; /* .notdef */ > + } In the failure case we need to not return 0 (.notdef), but should end up using the existing "gxxxx" glyph name. This is because glyphs are shown using the glyphshow PostScript operator, so we need unique names for every glyph. Note though that zero should be returned if the glyph's name really is .notdef. I guess returning 0xffff on failure would work, or something like that. Otherwise, the rest of the series looks good to me. Huw.

1 0

Re: d3dx9_36: Implement D3DXGetShaderOutputSemantics
by Marvin 09 Sep '15

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

1 0

Re: [2/2] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 08 Sep '15

08 Sep '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=16571 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1522: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008

1 0

Re: [PATCH 2/3] wineps.drv: Add support for PostScript Format 2 standard glyph names.
by Huw Davies 08 Sep '15

08 Sep '15

On 8 Sep 2015, at 17:09, Erich E. Hoover wrote: > This version adds an additional check that the number of glyphs > reported to be in the table fits within the size of the table data. By checking size is big enough for numberOfGlyphs, I meant that you need to check whether size is big enough to read the first two bytes of the extended (version 2) table. Huw.

1 0

FW: [PATCH] msxml3: treat namespace as attribute in IXMLDOMElement::getAttribute (try 2)
by Daniel Lehman 08 Sep '15

08 Sep '15

Anything I need to add or change on this? https://source.winehq.org/patches/data/114075 thanks Daniel -----Original Message----- From: wine-patches [mailto:wine-patches-bounces@winehq.org] On Behalf Of Daniel Lehman Sent: Friday, August 28, 2015 2:49 PM To: 'wine-patches(a)winehq.org' Subject: [PATCH] msxml3: treat namespace as attribute in IXMLDOMElement::getAttribute (try 2) Try 2: add tests for failures

1 0

RFC - msacm32: Quit on unsupported destination format in PCM_FormatSuggest
by Bruno Jesus 08 Sep '15

08 Sep '15

Since this DLL is far away from my comprehension I'm first sending this to wine-devel. Current code [1] suggest that only WAVE_FORMAT_PCM is supported so do not allow the function to succeed if the destination format is not PCM. Fixes bug https://bugs.winehq.org/show_bug.cgi?id=14193 [1] 858 if (!(adfs->fdwSuggest & ACM_FORMATSUGGESTF_WFORMATTAG)) { 859 if (adfs->pwfxSrc->wFormatTag != WAVE_FORMAT_PCM) { 860 WARN("not possible\n"); 861 return ACMERR_NOTPOSSIBLE; 862 } 863 adfs->pwfxDst->wFormatTag = adfs->pwfxSrc->wFormatTag; 864 }

2 1

Re: [3/3] oleaut32/tests: Add a test to show that support for coercion to arrays of variants is specific to vararg methods.
by Marvin 08 Sep '15

08 Sep '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=16567 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1558: Test failed: expected DISP_E_TYPEMISMATCH, got 0x80020008 tmarshal.c:1629: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [2/3] oleaut32: Add support for handling VT_VARIANT|VT_ARRAY|VT_BYREF argument type.
by Marvin 08 Sep '15

08 Sep '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=16566 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1605: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: [1/3] oleaut32/tests: Add another test for calling a varargs method.
by Marvin 08 Sep '15

08 Sep '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=16565 Your paranoid android. === w2000pro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wxppro (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2003std (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w7u (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w8 (32 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === wvistau64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008 === w2008s64 (64 bit tmarshal) === tmarshal.c:1606: Test failed: IDispatch_Invoke failed with error 0x80020008

1 0

Re: PATCH: widl: implement move-if-changed logic
by Jacek Caban 08 Sep '15

08 Sep '15

Hi Marcus, On 09/03/15 13:07, Marcus Meissner wrote: > From d8df64a7261bc0febcdd48d4ed818dc1f36f3471 Mon Sep 17 00:00:00 2001 > From: Marcus Meissner <meissner(a)suse.de> > Date: Thu, 3 Sep 2015 12:11:13 +0200 > Subject: [PATCH] widl: implement a move-if-changed logic > > This avoids unnecessary rebuilds if the generated code by widl > does not change. While I like the idea and it would often save a bug chunk of build time, I don't think it would work well with make. If you don't touch output file, then following make invocation will execute widl again, which is undesired. Thanks, Jacek

2 1

Re: configure.ac: Fix breakage caused by -Werror=unused-variable
by Alexandre Julliard 08 Sep '15

08 Sep '15

Daniel Santos <daniel.santos(a)pobox.com> writes: > When configuring with CFLAGS="-Wunused-variable -Werror", the configure > test for HAVE_PNG_SET_EXPAND_GRAY_1_2_4_TO_8 fails with unused variable. Running configure with -Werror is not a good idea. Is there a particular reason why you need this? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: ntdll: wrap getdirentries around getdents on NetBSD
by Ken Thomases 07 Sep '15

07 Sep '15

On Sep 7, 2015, at 2:40 AM, Austin English <austinenglish(a)gmail.com> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=18166 getdirentries() is only used if USE_GETDENTS is not defined. USE_GETDENTS is defined at the top of the file in the #ifdef linux block that your patch is right after. So, why not just #define USE_GETDENTS for NetBSD, too? No need for a wrapper. -Ken

1 0

Re: [PATCH 1/3] wineps.drv: Add support for PostScript Format 1 glyph names.
by Huw Davies 07 Sep '15

07 Sep '15

On Fri, Sep 04, 2015 at 10:28:50PM -0600, Erich E. Hoover wrote: > + size = GetFontData(hdc, MS_MAKE_TAG('p','o','s','t'), 0, NULL, 0); > + if(size == 0 || size == GDI_ERROR) > + return; Here you'll want to check that size >= sizeof(*post_header). In the 2nd patch you don't check that this size includes numberOfGlyphs. In the 3rd patch the size checks are repeated three times, it should be possible to simplify that. Huw.

1 0

Re: WS2_32: Proper WSACleanup implementation using wineserver help (try 2)
by Bruno Jesus 06 Sep '15

06 Sep '15

On Sun, Aug 30, 2015 at 11:04 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > Fixes some tests and also bug 32910 > > From 6b34d1b9f6cfa491a26b9c36e395c3b180b5ceea Mon Sep 17 00:00:00 2001 > From: Matt <matt(a)wymzee.com> > Date: Thu, 27 Aug 2015 23:43:59 -0400 > Subject: [PATCH] WS2_32: Proper WSACleanup implementation using wineserver > help I see the patch is pending and I can think of a few new issues. First two minor issues that are not related which are the DLL name in uppercase in the email subject and the patch has 5 whitespace issues (whitespace after the end of a line). The main issue is that it does not seem to work as we expect it does. And that is proved by the need of adding those new todo lines in the send() and closesocket() calls. For example in the closesocket call: 2977 fd = get_sock_fd(s, FILE_READ_DATA, NULL); 2978 if (fd >= 0) 2979 { ... Despite being closed in the server the get_sock_fd still succeeds in the DLL returning a no longer valid handle. It looks like some out of sync problem with the ntdll cache. Need someone else to help with that because I have no idea how to improve the patch. Best wishes, Bruno

1 0

Re: Who decides what are good translations war: Update German translation.
by Hin-Tak Leung 06 Sep '15

06 Sep '15

------------------------------ On Sat, Sep 5, 2015 7:10 AM BST Alex Henrie wrote: >2015-09-02 7:47 GMT-06:00 Thomas Kaltenbrunner <tkaltenbrunner(a)opc.de>: >> BTW. Who decides what are good translations? > >My German is terrible, so I will not attempt to comment on specific >German translations. However, I'd like to point out that I used >Windows as a reference to translate Wine into Catalan. I did not copy >translations word-for-word, but I noticed that Windows consistently >used some very specific terminology that is less common in Linux. The >list I came up with was: > >byte -> byte >default -> per defecte >font size -> cos de lletra >front (of window stack) -> primer terme >graph -> gràfic >handle -> identificador >item -> element >move -> desplaçar >pool -> agrupació >prompt -> indicador >set -> definir >settings -> opcions, configuració >suppress -> reprimir >use -> utilitzar > >Windows also had some grossly horrible translations, like "tancar" for >"shut down". I ignored those. My point though is that if you are >having a hard time deciding which German word is appropriate for Wine, >I would give a lot of consideration to which German word Windows uses. > >-Alex > > That's perhaps the most relevant response in this thread - remember, the stated aim of wine is to be bug-for-bug compatible with windows. Wine does not try to be a 'better' windows. There is no 'good' translations, but just what localised windows does. Different from localised windows is a flaw, even if it is arguably 'better'. one might choose to have a flaw occasionally, but a flaw it is, if it is different from localised windows.

5 5

Re: [PATCH] shell32: Fix SHFileOperation(FO_MOVE) on non-exist files.
by Marvin 06 Sep '15

06 Sep '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=16527 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: po: Update German translation.
by Florian Pelz 05 Sep '15

05 Sep '15

Sorry for sending to the wrong list. On 08/28/2015 03:03 PM, Florian Pelz wrote: > On 08/28/2015 02:35 PM, Julian Rüger wrote: >> +"Wine Anwendungsentferner\n" > > This needs a hyphen ("Wine-Anwendungsentferner\n"). >

4 10

Re: po: German translation: Fix grammar errors
by Julian Rüger 04 Sep '15

04 Sep '15

> #: oleview.rc:110 > msgid "Quit the application. Prompts to save changes" > -msgstr "Anwendung beenden. Frag ob Änderungen zu speichern sind" > +msgstr "Anwendung beenden. Fragt ob Änderungen zu speichern sind" "Fragt, ob ..." There should really be a full stop at the as well. Generally, you're right in not adding it when it's not there in the original, but I wonder why it was left out. Maybe we should add it to both. #: wineconsole.rc:44 msgid "wineconsole: Couldn't parse event id\n" -msgstr "wineconsole: Ereignis-ID konnte nicht geparsed werden\n" +msgstr "wineconsole: Ereignis-ID konnte nicht geparset werden\n" I'm never sure what to do in these cases. Correct German grammar would be "geparst", but that looks just awful... My personal preference is the pretty, but grammatically wrong English ending. I guess my OCD has to live with the pain ;) Let's use the correct case. Agreed?

2 2

d3d8/9 swapchain flip
by Stefan Dösinger 04 Sep '15

04 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, I'm sending my current swapchain flipping patches for you to look at in case you have any comments. A few notes: *) It doesn't involve the front buffer yet, it only cycles through the back buffers. Patch 8 has a few comments about that. *) The first interesting patch is patch 4. I am updating the wined3d_surface pointers in each d3d9_surface in the swapchain and adjust the d3d9 surface's parents. *) The other interesting parts are patch 7 and 8. If a view is created for a swapchain texture I'm storing the swapchain + buffer index in the view. When the view is used the texture is fetched from the swapchain. Alternatively I could maintain a list of views that are created for each texture and modify the views in present. With the current way we don't have to worry about how many views there are, but it makes looking up the actual texture slightly more expensive. So far this is only implemented for render target views, but the same approach should work for shader resource views. Before sending this I'm going to remove the back buffer type from the wined3d interface. It's not used anywhere according to MSDN, and none of the stereo hacks out there (occulus rift, ati quad buffer, nvidia 3d vision) use it. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6dE/AAoJEN0/YqbEcdMwZQ4P+weZy8ymZAp8pHgMztjuQRIC dUXaVO3hhoj6l6q/a2l27VDPnON81FBUADHG/Mk00MNOi0K/7IlHvKW5cEx54hV6 HsmRdtq1Kp9HLhgDTGJqy2yMhg9K9ugg5+u0ouQUxxxFdhDxhwlwDlfOGQvUkXL8 +SqAM5lB6wnDxVQ5OOlip2yJDEXYimL2e6QQOXaRpyWnciKUqd9Rs1RrFObLCnBK OC7rGpkCg0jmI6cKCsNEUrA+3ihz+zl+E7XU+W/g454oGTO3dKRI68iqrfN1wNB5 JfOzwIyHIdHTZOuuXZ+66Z8qqSxx8XcvyjEiKuN/bnvVCjGB+zLnqi10sKHD8yJv 2FE9AKFb6Kwyty9zLw2AMC/8Ch/Fh0s75TzhDm0cywORDwx94ApSDCF0R+ryQ+h8 QYhTpj187lQum1Egmti7PlHQRVCDv+sblyssdGvwDIYqmyfSoBARCILO08bKSGsd 9teITH2yfYYiChbf05n1aDzYyTwNRf52/p7xSHtfzaSR/U7G/tO7nvpXUuQjoPso je87AM2WJk0JSlfifCUn6qQ4j+aXLftUzzvqPSNRTmhw4uuO7Y1cxg7kp0ORwpC7 nEFrR/AaPJyGg/Hcy69LsNwokv/qlT1FgFrhnZrI2Rauop3dt4rZQSou2id2fo+J OQG8vE6dUux/GGHPIPIk =W1o8 -----END PGP SIGNATURE-----

1 0

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).
by Nikolay Sivov 04 Sep '15

04 Sep '15

> +void get_glyph_name(HDC hdc, UINT flags, WORD index, char *name) > { > - /* FIXME */ > + BOOL bIsGlyphIndex = ((flags & ETO_GLYPH_INDEX) == 0); > + > + if (bIsGlyphIndex && index < 258) This is essentially the same as it was on try 1. I still think we shouldn't rely on glyph indices mapped to some specific code range, I don't see any documentation that says it should be mapped like that. I think what we want is to map from WCHAR string to such glyph names directly, and that's why ETO_GLYPH_INDEX case is important - if you get index array initially you fallback to generic glyph names, if you got string then for codepoints that have defined glyphs in your names array you use those, for the rest of codepoints fallback again to generic name. This way we could also extend this lookup when it's decided how to deal with licensed glyph list data.

3 8

Re: reg: Implement binary data add operation
by Alexandre Julliard 04 Sep '15

04 Sep '15

Thomas Faller <tfaller1(a)gmx.de> writes: > +static inline BOOL is_xp_or_older(void) > +{ > + DWORD version = GetVersion(); > + if(version < 0x80000000){ > + /* compare major */ > + return (DWORD)(LOBYTE(LOWORD(version))) < 6; > + } > + return TRUE; > +} Do you actually have an app that depends on such a version check? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2] reg: simplify root key search
by Stefan Dösinger 03 Sep '15

03 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch still fails to apply with the same error: stefan@retina ~/src/wine $ git am /dev/shm/\[PATCH\ 1_2\]\ reg\:\ simplify\ root\ key\ search.eml Applying: reg: simplify root key search /home/stefan/src/wine/.git/rebase-apply/patch:14: trailing whitespace. static const WCHAR short_hklm[] = {'H','K','L','M',0}; /home/stefan/src/wine/.git/rebase-apply/patch:15: trailing whitespace. static const WCHAR short_hkcu[] = {'H','K','C','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:16: trailing whitespace. static const WCHAR short_hkcr[] = {'H','K','C','R',0}; /home/stefan/src/wine/.git/rebase-apply/patch:17: trailing whitespace. static const WCHAR short_hku[] = {'H','K','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:18: trailing whitespace. static const WCHAR short_hkcc[] = {'H','K','C','C',0}; error: patch failed: programs/reg/reg.c:22 error: programs/reg/reg.c: patch does not apply Patch failed at 0001 reg: simplify root key search The copy of the patch that failed is found in: /home/stefan/src/wine/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Stefan Am 2015-08-31 um 22:09 schrieb Michel Zou: > Split patch from Jonathan Vollebregt: > https://github.com/jnvsor/wine/commit/ea0e2fc70db6ce4904655ea4a27ee34531d96… > > - --- > programs/reg/reg.c | 85 > +++++++++++++++++++++++++++--------------------------- 1 file > changed, 43 insertions(+), 42 deletions(-) > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV6Bl1AAoJEN0/YqbEcdMwf+sQAI7u19WiDrPOtniTS00sJZeS mrBSZHvhKlDujZ4iCr4VHyycBzhCmg8peflfgEHRyF9xGx6duy/mzh0JHN3qJFlM r7zbm9wbhFCaH7i4d1JD2a7l9hthow+N3PuPKWk5ox+T+Pe9HaXTQwxUmgB/6YjR xXjkHDEc5GtyBeqxpiskw2W92GWubrMrEJmfmlQQSWfcIZjkUM0MmKCEUCibMu3O bLPOsx1AjD3aQ+S0R50D3s1W1u/yO0tfKa0pGki2pqZRL/72UcbBWNow6F9tZIeD qXaAgNhvn0rc66nMVb7yc//9nN4oN2prBNtrpCtSCCfSgd/Xh47xoq8g3HQUXjHd nNbfSuePuNLvNzu5XhNb0yP5cGCZedU8q7cYcPURn376t25xw22daigpdId3kaS0 KN+gwb2M1PSazPwkjRy94qIX9Kl0NIsJT8dLHZgV0TM7ZrRBy0sa2baqH5jvL+4h pCn9+Kcuyv5jC7Oj/ewNx+9EIRmUf7wOJvgdNocUqwSyHPf7bJwZOysAm4ltk8pq A7RA2qiyicANi34Yf1e8zKG1Fv1M/uYwvjc3Sd8jrTpkn0z9mzijll4R+bcThAXA jdZjA3HTyvoaaENxmKJngb7Xz2o0WBV1WUEjIIUos+md8IV7bCnH0dbCDtE3AQKl u/eABCeasbpTQJ61px7N =V5u2 -----END PGP SIGNATURE-----

2 1

Re: [4/13](try 3)hidclass.sys: Add USB Descriptor parsing
by Andrew Eikum 03 Sep '15

03 Sep '15

Sorry for not noticing this before you resent, but you've got some C++ style comments in parse_io_feature. Andrew On Thu, Sep 03, 2015 at 11:19:31AM -0500, Aric Stewart wrote: > More good comments and changes from Henri Verbeet > > --- > dlls/hidclass.sys/Makefile.in | 1 + > dlls/hidclass.sys/descriptor.c | 1163 ++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 3 + > dlls/hidclass.sys/pnp.c | 37 ++ > 4 files changed, 1204 insertions(+) > create mode 100644 dlls/hidclass.sys/descriptor.c

2 1

Idea of fixing SHFileOperation(FO_MOVE)
by Zhenbo Li 03 Sep '15

03 Sep '15

Hello, As I'm working on bug 25207, I found that previous test code (test_move() in shlfileop.c) had some disadvantages 1. Duplicate tests 2. Legacy test code (for Win98 or NT4) 3. Lack of test for Vista or later Windows Versions As more applications are depending on the new behaviours introduced in Vista, IMHO, we should focus on Vista's new behaviour. So I rewrote test_move() to remove code for win98, mark xp behaviour as broken, and expect Vista's behaviour. My next step is to re-implement FO_MOVE operation of SHFileOperation to fix bug 25207. Any suggestion for this? Thank you. -- Have a nice day! Zhenbo Li

2 3

Re: quartz: Simplify a loop and make the code more robust
by Bruno Jesus 03 Sep '15

03 Sep '15

On Thu, Sep 3, 2015 at 9:06 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Sorry, ignore this patch. Current quartz behavior is wrong and should be fixed instead of reinforced.

1 0

Re: [4/13](resend)hidclass.sys: Add USB Descriptor parsing
by Andrew Eikum 03 Sep '15

03 Sep '15

A couple small notes inline below. On Wed, Sep 02, 2015 at 07:01:51AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/Makefile.in b/dlls/hidclass.sys/Makefile.in > index 8ed51e6..6e79486 100644 > --- a/dlls/hidclass.sys/Makefile.in > +++ b/dlls/hidclass.sys/Makefile.in > @@ -5,6 +5,7 @@ DELAYIMPORTS = setupapi hid > > C_SRCS = \ > buffer.c \ > + descriptor.c \ > device.c \ > main.c \ > pnp.c > diff --git a/dlls/hidclass.sys/descriptor.c b/dlls/hidclass.sys/descriptor.c > new file mode 100644 > index 0000000..c277dec > --- /dev/null > +++ b/dlls/hidclass.sys/descriptor.c > @@ -0,0 +1,1106 @@ > +/* > + * HID descriptor parsing > + * > + * Copyright (C) 2015 Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "config.h" > + > +#include <stdarg.h> > +#include <stdlib.h> > +#define NONAMELESSUNION > +#include "hid.h" > + > +#include "wine/debug.h" > +#include "wine/list.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(hid); > + > +#define USAGE_MAX 10 > + > +static const char* feature_string[] = > + { "Input", "Output", "Feature" }; > + > +struct caps { > + USAGE UsagePage; > + LONG LogicalMin; > + LONG LogicalMax; > + LONG PhysicalMin; > + LONG PhysicalMax; > + ULONG UnitsExp; > + ULONG Units; > + USHORT BitSize; > + UCHAR ReportID; > + USHORT ReportCount; > + > + BOOLEAN IsRange; > + BOOLEAN IsStringRange; > + BOOLEAN IsDesignatorRange; > + int usage_count; > + union { > + struct { > + USAGE UsageMin; > + USAGE UsageMax; > + USHORT StringMin; > + USHORT StringMax; > + USHORT DesignatorMin; > + USHORT DesignatorMax; > + } Range; > + struct { > + USAGE Usage[USAGE_MAX]; > + USAGE Reserved1; > + USHORT StringIndex; > + USHORT Reserved2; > + USHORT DesignatorIndex; > + USHORT Reserved3; > + } NotRange; > + } DUMMYUNIONNAME; > + > + int Delim; > +}; > + > +struct feature { > + struct list entry; > + struct list col_entry; > + struct caps caps; > + > + HIDP_REPORT_TYPE type; > + BOOLEAN isData; > + BOOLEAN isArray; > + BOOLEAN IsAbsolute; > + BOOLEAN Wrap; > + BOOLEAN Linear; > + BOOLEAN prefState; > + BOOLEAN HasNull; > + BOOLEAN Volatile; > + BOOLEAN BitField; > + > + int index; > + struct collection *collection; > +}; > + > +static const char* collection_string[] = { > + "Physical", > + "Application", > + "Logical", > + "Report", > + "Named Array", > + "Usage Switch", > + "Usage Modifier", > +}; > + > +struct collection { > + struct list entry; > + struct caps caps; > + int index; > + int type; > + struct collection *parent; > + struct list features; > + struct list collections; > +}; > + > +static const char* debugstr_usages(struct caps *caps) > +{ > + if (!caps->IsRange) > + { > + static char out[30]; > + int i; > + strcpy(out, "[ "); > + for (i = 0; i < caps->usage_count; i++) > + strcat(out, wine_dbg_sprintf("%x ", caps->u.NotRange.Usage[i])); > + strcat(out,"]"); > + return out; > + } > + else > + return wine_dbg_sprintf("[%x - %x]", caps->u.Range.UsageMin, caps->u.Range.UsageMax); > +} > + > +static const char* debugstr_stringindex(struct caps *caps) > +{ > + if (!caps->IsStringRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.StringIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.StringMin, caps->u.Range.StringMax); > +} > + > +static const char* debugstr_designatorindex(struct caps *caps) > +{ > + if (!caps->IsDesignatorRange) > + return wine_dbg_sprintf("%i", caps->u.NotRange.DesignatorIndex); > + else > + return wine_dbg_sprintf("[%i - %i]", caps->u.Range.DesignatorMin, caps->u.Range.DesignatorMax); > +} > + > +static const char* debugstr_caps(struct caps *caps) > +{ > + if (!caps) > + return ""; > + return wine_dbg_sprintf("(UsagePage %x; LogicalMin %i; LogicalMax %i; PhysicalMin %i; PhysicalMax %i; UnitsExp %i; Units %i; BitSize %i; ReportID %i; ReportCount %i; Usage %s; StringIndex %s; DesignatorIndex %s; Delim %i;)", > + caps->UsagePage, > + caps->LogicalMin, > + caps->LogicalMax, > + caps->PhysicalMin, > + caps->PhysicalMax, > + caps->UnitsExp, > + caps->Units, > + caps->BitSize, > + caps->ReportID, > + caps->ReportCount, > + debugstr_usages(caps), > + debugstr_stringindex(caps), > + debugstr_designatorindex(caps), > + caps->Delim); > +} > + > +static void debug_feature(struct feature *feature) > +{ > + if (!feature) > + return; > + TRACE("[\n\t type %s [%i]; %s; %s; %s; %s; %s; %s; %s; %s; %s\n\t %s\n]\n", > + feature_string[feature->type], > + feature->index, > + (feature->isData)?"Data":"Const", > + (feature->isArray)?"Array":"Var", > + (feature->IsAbsolute)?"Abs":"Rel", > + (feature->Wrap)?"Wrap":"NoWrap", > + (feature->Linear)?"Linear":"NonLinear", > + (feature->prefState)?"PrefStat":"NoPrefState", > + (feature->HasNull)?"HasNull":"NoNull", > + (feature->Volatile)?"Volatile":"NonVolatile", > + (feature->BitField)?"BitField":"Buffered", > + debugstr_caps(&feature->caps)); > +} > + > +static void debug_collection(struct collection *collection) > +{ > + struct feature *fentry; > + struct collection *centry; > + if (TRACE_ON(hid)) > + { > + TRACE("{ %s[%i], %p, %i features, %i collections\n\t %s\n", collection_string[collection->type], collection->index, collection->parent, list_count(&collection->features), list_count(&collection->collections), debugstr_caps(&collection->caps)); > + LIST_FOR_EACH_ENTRY(fentry, &collection->features, struct feature, col_entry) > + debug_feature(fentry); > + LIST_FOR_EACH_ENTRY(centry, &collection->collections, struct collection, entry) > + debug_collection(centry); > + TRACE("}\n"); > + } > +} > + > +static void debug_print_button_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + if (!wine_element->caps.button.IsRange) > + TRACE("%s Button: %x/%04x: ReportId %i, startBit %i/1\n" , type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit); > + else > + TRACE("%s Button: %x/[%04x-%04x]: ReportId %i, startBit %i/%i\n" ,type, > + wine_element->caps.button.UsagePage, > + wine_element->caps.button.u.Range.UsageMin, > + wine_element->caps.button.u.Range.UsageMax, > + wine_element->caps.value.ReportID, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_value_cap(const CHAR * type, WINE_HID_ELEMENT *wine_element) > +{ > + TRACE("%s Value: %x/%x: ReportId %i, IsAbsolute %i, HasNull %i, " > + "Bit Size %i, ReportCount %i, UnitsExp %i, Units %i, " > + "LogicalMin %i, Logical Max %i, PhysicalMin %i, " > + "PhysicalMax %i -- StartBit %i/%i\n", type, > + wine_element->caps.value.UsagePage, > + wine_element->caps.value.u.NotRange.Usage, > + wine_element->caps.value.ReportID, > + wine_element->caps.value.IsAbsolute, > + wine_element->caps.value.HasNull, > + wine_element->caps.value.BitSize, > + wine_element->caps.value.ReportCount, > + wine_element->caps.value.UnitsExp, > + wine_element->caps.value.Units, > + wine_element->caps.value.LogicalMin, > + wine_element->caps.value.LogicalMax, > + wine_element->caps.value.PhysicalMin, > + wine_element->caps.value.PhysicalMax, > + wine_element->valueStartBit, > + wine_element->bitCount); > +} > + > +static void debug_print_element(const CHAR* type, WINE_HID_ELEMENT *wine_element) > +{ > + if (wine_element->ElementType == ButtonElement) > + debug_print_button_cap(type, wine_element); > + else if (wine_element->ElementType == ValueElement) > + debug_print_value_cap(type, wine_element); > + else > + TRACE("%s: UNKNOWN\n", type); > +} > + > +static void debug_print_report(const char* type, WINE_HID_REPORT *report) > +{ > + int i; > + TRACE("%s REPORT:\n" > + "\tReportID: %i\n" > + "\tdwSize: %i\n" > + "\telementCount: %i\n", > + type, > + report->reportID, > + report->dwSize, > + report->elementCount); > + for (i = 0; i < report->elementCount; i++) > + debug_print_element(type, &report->Elements[i]); > +} > + > +static void debug_print_preparsed(WINE_HIDP_PREPARSED_DATA *data) > +{ > + int i; > + WINE_HID_REPORT *r; > + if (TRACE_ON(hid)) > + { > + TRACE("PREPARSED Data:\n" > + "\tdwSize: %i\n" > + "\tCaps:\n" > + "\t\tUsage: %i\n" > + "\t\tUsagePage: %i\n" > + "\t\tInputReportByteLength: %i\n" > + "\t\tOutputReportByteLength: %i\n" > + "\t\tFeatureReportByteLength: %i\n" > + "\t\tNumberLinkCollectionNodes: %i\n" > + "\t\tNumberInputButtonCaps: %i\n" > + "\t\tNumberInputValueCaps: %i\n" > + "\t\tNumberInputDataIndices: %i\n" > + "\t\tNumberOutputButtonCaps: %i\n" > + "\t\tNumberOutputValueCaps: %i\n" > + "\t\tNumberOutputDataIndices: %i\n" > + "\t\tNumberFeatureButtonCaps: %i\n" > + "\t\tNumberFeatureValueCaps: %i\n" > + "\t\tNumberFeatureDataIndices: %i\n" > + "\tdwInputReportCount: %i\n" > + "\tdwOutputReportCount: %i\n" > + "\tdwFeatureReportCount: %i\n" > + "\tdwOutputReportOffset: %i\n" > + "\tdwFeatureReportOffset: %i\n", > + data->dwSize, > + data->caps.Usage, > + data->caps.UsagePage, > + data->caps.InputReportByteLength, > + data->caps.OutputReportByteLength, > + data->caps.FeatureReportByteLength, > + data->caps.NumberLinkCollectionNodes, > + data->caps.NumberInputButtonCaps, > + data->caps.NumberInputValueCaps, > + data->caps.NumberInputDataIndices, > + data->caps.NumberOutputButtonCaps, > + data->caps.NumberOutputValueCaps, > + data->caps.NumberOutputDataIndices, > + data->caps.NumberFeatureButtonCaps, > + data->caps.NumberFeatureValueCaps, > + data->caps.NumberFeatureDataIndices, > + data->dwInputReportCount, > + data->dwOutputReportCount, > + data->dwFeatureReportCount, > + data->dwOutputReportOffset, > + data->dwFeatureReportOffset); > + > + r = HID_INPUT_REPORTS(data); > + for (i = 0; i < data->dwInputReportCount; i++) > + { > + debug_print_report("INPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_OUTPUT_REPORTS(data); > + for (i = 0; i < data->dwOutputReportCount; i++) > + { > + debug_print_report("OUTPUT", r); > + r = HID_NEXT_REPORT(data, r); > + } > + r = HID_FEATURE_REPORTS(data); > + for (i = 0; i < data->dwFeatureReportCount; i++) > + { > + debug_print_report("FEATURE", r); > + r = HID_NEXT_REPORT(data, r); > + } > + } > +} > + > +static int getValue(int bsize, int source) > +{ > + int mask = 0xff; > + int negative = 0x80; > + int outofrange = 0x100; > + int value; > + int i; > + > + if (bsize == 4) > + return source; > + > + for (i = 1; i < bsize; i++) > + { > + mask = (mask<<8) + 0xff; > + negative = (negative<<8); > + outofrange = (outofrange<<8); > + } > + value = (source&mask); > + if (value&negative) > + value = -1 * (outofrange - value); > + return value; > +} > + > +void parse_io_feature(int bSize, int itemVal, int bTag, int *feature_index, struct feature *feature) > +{ > + if (bSize <= 0) > + { > + return; > + } > + else > + { > + if ((itemVal & 0x01) == 0) > + feature->isData = TRUE; > + else > + feature->isData = FALSE; //Const > + if ((itemVal & 0x02) == 0) > + feature->isArray= TRUE; > + else > + feature->isArray= TRUE; //Var > + if ((itemVal & 0x04) == 0) > + feature->IsAbsolute = TRUE; > + else > + feature->IsAbsolute = FALSE; //Rel > + if ((itemVal & 0x08) == 0) > + feature->Wrap = FALSE; > + else > + feature->Wrap = TRUE; > + if ((itemVal & 0x10) == 0) > + feature->Linear = TRUE; > + else > + feature->Linear = FALSE; > + if ((itemVal & 0x20) == 0) > + feature->prefState = TRUE; > + else > + feature->prefState = FALSE; > + if ((itemVal & 0x40) == 0) > + feature->HasNull = FALSE; > + else > + feature->HasNull = TRUE; > + > + if (bTag != 0x08) > + { > + if ((itemVal & 0x80) == 0) > + feature->Volatile = FALSE; > + else > + feature->Volatile = TRUE; > + } > + if (bSize > 1) > + { > + if ((itemVal & 0x100) == 0) > + feature->BitField = TRUE; > + else > + feature->BitField = FALSE; //Buffered Bytes > + } > + feature->index = *feature_index; > + *feature_index = *feature_index + 1; > + } > +} > + > +void parse_collection(int bSize, int itemVal, struct collection *collection) > +{ > + if (bSize <= 0) > + return; > + else > + { > + collection->type = itemVal; > + > + if (itemVal >= 0x07 && itemVal <= 0x7F) { > + ERR(" (Reserved %x )\n", itemVal); > + } > + else if (itemVal >= 0x80 && itemVal <= 0xFF) { > + ERR(" (Vendor Defined %x )\n", itemVal); > + } > + } > +} > + > +static void new_caps(struct caps *caps) > +{ > + caps->IsRange = 0; > + caps->IsStringRange = 0; > + caps->IsDesignatorRange = 0; > + caps->usage_count = 0; > +} > + > +int parse_descriptor(BYTE *descriptor, INT index, INT length, INT *feature_index, INT *collection_index, struct collection *collection, struct caps *caps, struct list *features) > +{ > + int i; > + for (i = index; i < length;) > + { > + BYTE b0 = descriptor[i++]; > + int bSize = b0 & 0x03; > + int bType = (b0 >> 2) & 0x03; > + int bTag = (b0 >> 4) & 0x0F; > + > + bSize = (bSize == 3) ? 4 : bSize; > + if (bType == 0x03 && bTag == 0x0F && bSize == 2 && i + 2 < length) > + { > + /* Long data items: Should be unused */ > + ERR("Long Data Item, should be unused\n"); This confused me. Is this a malformed report from the HID or something Wine doesn't yet support? > + } > + else > + { > + int bSizeActual = 0; > + int itemVal = 0; > + int j; > + > + for (j = 0; j < bSize; j++) > + { > + if (i + j < length) > + { > + itemVal += descriptor[i + j] << (8 * j); > + bSizeActual++; > + } > + } > + TRACE(" %x[%i], type %i , tag %i, size %i, val %i\n",b0,i-1,bType, bTag, bSize, itemVal ); > + > + if (bType == 0x00) > + { > + struct feature *feature; > + switch(bTag) > + { > + case 0x08: Here and elsewhere, there's a lot of magic numbers. Do these have names in the standard? Could you make up names for them? TAG_INPUT or something. Or is it more useful to have the raw numbers? > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Input; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x09: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Output; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0B: > + feature = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*feature)); > + list_add_tail(&collection->features, &feature->col_entry); > + list_add_tail(features, &feature->entry); > + feature->type = HidP_Feature; > + parse_io_feature(bSize, itemVal, bTag, feature_index, feature); > + feature->caps = *caps; > + feature->collection = collection; > + new_caps(caps); > + break; > + case 0x0A: Here, the cases are in a different order. That wouldn't matter with symbols, but it struck me with the raw numbers. > + { > + struct collection *subcollection = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct collection)); > + list_add_tail(&collection->collections, &subcollection->entry); > + subcollection->parent = collection; > + /* Only set our collection once... > + We do not properly handle composite devices yet. */ > + if (*collection_index == 0) > + collection->caps = *caps; > + subcollection->caps = *caps; > + subcollection->index = *collection_index; > + *collection_index = *collection_index + 1; > + list_init(&subcollection->features); > + list_init(&subcollection->collections); > + new_caps(caps); > + > + parse_collection(bSize, itemVal, subcollection); > + > + i = parse_descriptor(descriptor, i+1, length, feature_index, collection_index, subcollection, caps, features); > + continue; > + } > + case 0x0C: > + return i; > + default: > + ERR("Unknown Tag\n"); Would it be useful to print the tag value here? > + } > + } > + else if (bType == 0x01) > + { > + switch(bTag) > + { > + case 0x00: > + caps->UsagePage = getValue(bSize, itemVal); > + break; > + case 0x01: > + caps->LogicalMin = getValue(bSize, itemVal); > + break; > + case 0x02: > + caps->LogicalMax = getValue(bSize, itemVal); > + break; > + case 0x03: > + caps->PhysicalMin = getValue(bSize, itemVal); > + break; > + case 0x04: > + caps->PhysicalMax = getValue(bSize, itemVal); > + break; > + case 0x05: > + caps->UnitsExp = getValue(bSize, itemVal); > + break; > + case 0x06: > + caps->Units = getValue(bSize, itemVal); > + break; > + case 0x07: > + caps->BitSize = getValue(bSize, itemVal); > + break; > + case 0x08: > + caps->ReportID = getValue(bSize, itemVal); > + break; > + case 0x09: > + caps->ReportCount = getValue(bSize, itemVal); > + break; > + case 0x0A: > + ERR("Push\n"); > + break; > + case 0x0B: > + ERR("Pop\n"); > + break; Are these invalid messages from the HID device, or things wine doesn't yet support? Should they be FIXMEs? > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else if (bType == 0x02) > + { > + switch(bTag) > + { > + case 0x00: > + if (caps->usage_count >= USAGE_MAX) > + FIXME("More than %i individual usages defined\n",USAGE_MAX); > + else > + { > + caps->u.NotRange.Usage[caps->usage_count++] = getValue(bSize, itemVal); > + caps->IsRange = FALSE; > + } > + break; > + case 0x01: > + caps->usage_count = 1; > + caps->u.Range.UsageMin = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x02: > + caps->usage_count = 1; > + caps->u.Range.UsageMax = getValue(bSize, itemVal); > + caps->IsRange = TRUE; > + break; > + case 0x03: > + caps->u.NotRange.DesignatorIndex = getValue(bSize, itemVal); > + caps->IsDesignatorRange = FALSE; > + break; > + case 0x04: > + caps->u.Range.DesignatorMin = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x05: > + caps->u.Range.DesignatorMax = getValue(bSize, itemVal); > + caps->IsDesignatorRange = TRUE; > + break; > + case 0x07: > + caps->u.NotRange.StringIndex = getValue(bSize, itemVal); > + caps->IsStringRange = FALSE; > + break; > + case 0x08: > + caps->u.Range.StringMin = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x09: > + caps->u.Range.StringMax = getValue(bSize, itemVal); > + caps->IsStringRange = TRUE; > + break; > + case 0x0A: > + caps->Delim = getValue(bSize, itemVal); > + break; > + default: > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + } > + } > + else > + ERR("Unknown (bTag: %x, bType: %x)\n", bTag, bType); > + > + i += bSize; > + } > + } > + return i; > +} > + > +static inline void new_report(WINE_HID_REPORT *wine_report, struct feature* feature) > +{ > + wine_report->reportID = feature->caps.ReportID; > + wine_report->dwSize = sizeof(*wine_report) - sizeof(WINE_HID_ELEMENT); > + wine_report->elementCount = 0; > +} > + > +static void build_elements(WINE_HID_REPORT *wine_report, struct feature* feature, DWORD *bitOffset) > +{ > + int i; > + > + if (!feature->isData) > + { > + *bitOffset = *bitOffset + (feature->caps.BitSize * feature->caps.ReportCount); > + return; > + } > + > + for (i = 0; i < feature->caps.usage_count; i++) > + { > + WINE_HID_ELEMENT *wine_element = &wine_report->Elements[wine_report->elementCount]; > + > + wine_element->valueStartBit = *bitOffset; > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + wine_element->ElementType = ButtonElement; > + wine_element->caps.button.UsagePage = feature->caps.UsagePage; > + wine_element->caps.button.ReportID = feature->caps.ReportID; > + wine_element->caps.button.BitField = feature->BitField; > + wine_element->caps.button.IsRange = feature->caps.IsRange; > + wine_element->caps.button.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.button.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.button.IsAbsolute = feature->IsAbsolute; > + if (wine_element->caps.button.IsRange) > + { > + wine_element->bitCount = (feature->caps.u.Range.UsageMax - feature->caps.u.Range.UsageMin) + 1; > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.button.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.button.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.button.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.button.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.button.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.button.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + *bitOffset = *bitOffset + 1; > + wine_element->bitCount = 1; > + wine_element->caps.button.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.button.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.button.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + else > + { > + wine_element->ElementType = ValueElement; > + wine_element->caps.value.UsagePage = feature->caps.UsagePage; > + wine_element->caps.value.ReportID = feature->caps.ReportID; > + wine_element->caps.value.BitField = feature->BitField; > + wine_element->caps.value.IsRange = feature->caps.IsRange; > + wine_element->caps.value.IsStringRange = feature->caps.IsStringRange; > + wine_element->caps.value.IsDesignatorRange = feature->caps.IsDesignatorRange; > + wine_element->caps.value.IsAbsolute = feature->IsAbsolute; > + wine_element->caps.value.HasNull = feature->HasNull; > + wine_element->caps.value.BitSize = feature->caps.BitSize; > + if (feature->caps.usage_count > 1) > + wine_element->caps.value.ReportCount = 1; > + else > + wine_element->caps.value.ReportCount = feature->caps.ReportCount; > + wine_element->bitCount = (feature->caps.BitSize * wine_element->caps.value.ReportCount); > + *bitOffset = *bitOffset + wine_element->bitCount; > + wine_element->caps.value.UnitsExp = feature->caps.UnitsExp; > + wine_element->caps.value.Units = feature->caps.Units; > + wine_element->caps.value.LogicalMin = feature->caps.LogicalMin; > + wine_element->caps.value.LogicalMax = feature->caps.LogicalMax; > + wine_element->caps.value.PhysicalMin = feature->caps.PhysicalMin; > + wine_element->caps.value.PhysicalMax = feature->caps.PhysicalMax; > + if (wine_element->caps.value.IsRange) > + { > + wine_element->caps.value.u.Range.UsageMin = feature->caps.u.Range.UsageMin; > + wine_element->caps.value.u.Range.UsageMax = feature->caps.u.Range.UsageMax; > + wine_element->caps.value.u.Range.StringMin = feature->caps.u.Range.StringMin; > + wine_element->caps.value.u.Range.StringMax = feature->caps.u.Range.StringMax; > + wine_element->caps.value.u.Range.DesignatorMin = feature->caps.u.Range.DesignatorMin; > + wine_element->caps.value.u.Range.DesignatorMax = feature->caps.u.Range.DesignatorMax; > + } > + else > + { > + wine_element->caps.value.u.NotRange.Usage = feature->caps.u.NotRange.Usage[i]; > + wine_element->caps.value.u.NotRange.StringIndex = feature->caps.u.NotRange.StringIndex; > + wine_element->caps.value.u.NotRange.DesignatorIndex = feature->caps.u.NotRange.DesignatorIndex; > + } > + } > + > + wine_report->elementCount++; > + } > +} > + > +static void count_elements(struct feature* feature, USHORT *buttons, USHORT *values) > +{ > + if (feature->caps.UsagePage == HID_USAGE_PAGE_BUTTON) > + { > + if (feature->caps.IsRange) > + *buttons = *buttons + 1; > + else > + *buttons = *buttons + feature->caps.usage_count; > + } > + else > + { > + if (feature->caps.IsRange) > + *values = *values + 1; > + else > + *values = *values + feature->caps.usage_count; > + } > +} > + > +WINE_HIDP_PREPARSED_DATA* build_PreparseData( > + struct feature **features, int feature_count, > + struct feature **input_features, int i_count, > + struct feature **output_features, int o_count, > + struct feature **feature_features, int f_count, > + struct collection *base_collection) > +{ > + WINE_HIDP_PREPARSED_DATA *data; > + WINE_HID_REPORT *wine_report = NULL; > + DWORD bitOffset, bitLength; > + int report_count = 1; > + int i; > + int element_count; > + int size = 0; > + > + if (features[0]->caps.ReportID != 0) > + { > + int *report_ids; > + int cnt = max(i_count, o_count); > + cnt = max(cnt, f_count); > + report_ids = HeapAlloc(GetProcessHeap(), 0 , sizeof(*report_ids) * cnt); > + > + if (i_count) > + { > + report_ids[0] = input_features[0]->caps.ReportID; > + for (i = 1; i < i_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < i_count; j++) > + { > + if (report_ids[j] == input_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = input_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (o_count) > + { > + report_count++; > + report_ids[0] = output_features[0]->caps.ReportID; > + for (i = 1; i < o_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < o_count; j++) > + { > + if (report_ids[j] == output_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = output_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + if (f_count) > + { > + report_count++; > + report_ids[0] = feature_features[0]->caps.ReportID; > + for (i = 1; i < f_count; i++) > + { > + int j; > + int found = FALSE; > + for (j = 0; !found && j < f_count; j++) > + { > + if (report_ids[j] == feature_features[i]->caps.ReportID) > + found = TRUE; > + } > + if (!found) > + { > + report_ids[report_count] = feature_features[i]->caps.ReportID; > + report_count++; > + } > + } > + } > + HeapFree(GetProcessHeap(), 0, report_ids); > + } > + else > + { > + if (o_count) report_count++; > + if (f_count) report_count++; > + } > + > + element_count = 0; > + for (i = 0; i < feature_count; i++) > + element_count += features[i]->caps.usage_count; > + > + size = sizeof(WINE_HIDP_PREPARSED_DATA) + > + (element_count * sizeof(WINE_HID_ELEMENT)) + > + (report_count * sizeof(WINE_HID_REPORT)); > + > + TRACE("%i reports %i elements -> size %i\n",report_count, element_count, size); > + > + data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); > + data->magic = HID_MAGIC; > + data->dwSize = size; > + data->caps.Usage = base_collection->caps.u.NotRange.Usage[0]; > + data->caps.UsagePage = base_collection->caps.UsagePage; > + > + wine_report = data->InputReports; > + if (i_count) > + { > + bitLength = 0; > + new_report(wine_report, input_features[0]); > + data->dwInputReportCount ++; > + > + if (input_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < i_count; i++) > + { > + if (input_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, input_features[i]); > + data->dwInputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (input_features[i]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, input_features[i], &bitOffset); > + count_elements(input_features[i], &data->caps.NumberInputButtonCaps, > + &data->caps.NumberInputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.InputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (o_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwOutputReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, output_features[0]); > + data->dwOutputReportCount ++; > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < o_count; i++) > + { > + if (output_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + new_report(wine_report, output_features[i]); > + data->dwOutputReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (output_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, output_features[i], &bitOffset); > + count_elements(output_features[i], &data->caps.NumberOutputButtonCaps, > + &data->caps.NumberOutputValueCaps); > + } > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + bitLength = max(bitOffset, bitLength); > + data->caps.OutputReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + if (f_count) > + { > + bitLength = 0; > + wine_report = (WINE_HID_REPORT*)(((BYTE*)wine_report)+wine_report->dwSize); > + data->dwFeatureReportOffset = (BYTE*)wine_report - (BYTE*)data->InputReports; > + new_report(wine_report, feature_features[0]); > + data->dwFeatureReportCount ++; > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + > + for (i = 0; i < f_count; i++) > + { > + if (feature_features[i]->caps.ReportID != wine_report->reportID) > + { > + wine_report->dwSize += (sizeof(WINE_HID_ELEMENT) * wine_report->elementCount); > + wine_report = (WINE_HID_REPORT*)((BYTE*)wine_report)+wine_report->dwSize; > + new_report(wine_report, feature_features[i]); > + data->dwFeatureReportCount ++; > + bitLength = max(bitOffset, bitLength); > + if (feature_features[0]->caps.ReportID != 0) > + bitOffset = 8; > + else > + bitOffset = 0; > + } > + build_elements(wine_report, feature_features[i], &bitOffset); > + count_elements(feature_features[i], &data->caps.NumberFeatureButtonCaps, > + &data->caps.NumberFeatureValueCaps); > + } > + bitLength = max(bitOffset, bitLength); > + data->caps.FeatureReportByteLength = ((bitLength + 7) & ~7)/8; > + } > + > + return data; > +} > + > +static void free_collection(struct collection *collection) > +{ > + struct feature *fentry, *fnext; > + struct collection *centry, *cnext; > + LIST_FOR_EACH_ENTRY_SAFE(centry, cnext, &collection->collections, struct collection, entry) > + { > + list_remove(&centry->entry); > + free_collection(centry); > + } > + LIST_FOR_EACH_ENTRY_SAFE(fentry, fnext, &collection->features, struct feature, col_entry) > + { > + list_remove(&fentry->col_entry); > + HeapFree(GetProcessHeap(), 0, fentry); > + } > + HeapFree(GetProcessHeap(), 0, collection); > +} > + > +static int compare_reports(const void *a, const void* b) > +{ > + struct feature *f1 = *(struct feature **)a; > + struct feature *f2 = *(struct feature **)b; > + int c = (f1->caps.ReportID - f2->caps.ReportID); > + if (c) return c; > + return (f1->index - f2->index); > +} > + > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) > +{ > + WINE_HIDP_PREPARSED_DATA *data = NULL; > + struct collection *base; > + struct caps caps; > + > + struct list features; > + > + int feature_count = 0; > + int cidx; > + > + if (TRACE_ON(hid)) > + { > + TRACE("Descriptor[%i]: ", length); > + for (cidx = 0; cidx < length; cidx++) > + TRACE("%x ",descriptor[cidx]); > + TRACE("\n"); > + } > + > + list_init(&features); > + > + base = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*base)); > + base->index = 1; > + list_init(&base->features); > + list_init(&base->collections); > + memset(&caps, 0, sizeof(caps)); > + > + cidx = 0; > + parse_descriptor(descriptor, 0, length, &feature_count, &cidx, base, &caps, &features); > + > + debug_collection(base); > + > + cidx = 2; > + if (feature_count) > + { > + struct feature *entry; > + struct feature** sorted_features; > + struct feature** input_features; > + struct feature** output_features; > + struct feature** feature_features; > + int i_count, o_count, f_count; > + int i; > + > + i_count = o_count = f_count = 0; > + > + sorted_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*sorted_features) * feature_count); > + input_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*input_features) * feature_count); > + output_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*output_features) * feature_count); > + feature_features = HeapAlloc(GetProcessHeap(), 0, sizeof(*feature_features) * feature_count); > + > + i = 0; > + LIST_FOR_EACH_ENTRY(entry, &features, struct feature, entry) > + sorted_features[i++] = entry; > + > + /* Sort features base on report if there are multiple reports */ > + if (sorted_features[0]->caps.ReportID != 0) > + qsort(sorted_features, feature_count, sizeof(struct feature*), compare_reports); > + > + for (i = 0; i < feature_count; i++) > + { > + switch (sorted_features[i]->type) > + { > + case HidP_Input: > + input_features[i_count] = sorted_features[i]; > + i_count++; > + break; > + case HidP_Output: > + output_features[o_count] = sorted_features[i]; > + o_count++; > + break; > + case HidP_Feature: > + feature_features[f_count] = sorted_features[i]; > + f_count++; > + break; > + default: > + ERR("Unknown type %i\n",sorted_features[i]->type); > + } > + } > + > + if (TRACE_ON(hid)) > + { > + TRACE("DUMP FEATURES:\n"); > + TRACE("----INPUT----\n"); > + for (cidx = 0; cidx < i_count; cidx++) > + debug_feature(input_features[cidx]); > + TRACE("----OUTPUT----\n"); > + for (cidx = 0; cidx < o_count; cidx++) > + debug_feature(output_features[cidx]); > + TRACE("----FEATURE----\n"); > + for (cidx = 0; cidx < f_count; cidx++) > + debug_feature(feature_features[cidx]); > + } > + > + data = build_PreparseData(sorted_features, feature_count, input_features, i_count, output_features, o_count, feature_features, f_count, base); > + > + debug_print_preparsed(data); > + > + HeapFree(GetProcessHeap(), 0, sorted_features); > + HeapFree(GetProcessHeap(), 0, input_features); > + HeapFree(GetProcessHeap(), 0, output_features); > + HeapFree(GetProcessHeap(), 0, feature_features); > + } > + > + free_collection(base); > + /* We do not have to free the list as free_collection does all the work */ > + > + return data; > +} > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index 8f9e56f..c8cee69 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -81,3 +81,6 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > /* Pseudo-Plug and Play support*/ > NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void* native) DECLSPEC_HIDDEN; > void PNP_CleanupPNP() DECLSPEC_HIDDEN; > + > +/* Parsing HID Report Descriptors into preparsed data */ > +WINE_HIDP_PREPARSED_DATA* ParseDescriptor(BYTE *descriptor, INT length) DECLSPEC_HIDDEN; > diff --git a/dlls/hidclass.sys/pnp.c b/dlls/hidclass.sys/pnp.c > index ca85cb7..5694b8a 100644 > --- a/dlls/hidclass.sys/pnp.c > +++ b/dlls/hidclass.sys/pnp.c > @@ -53,6 +53,9 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > DWORD index = HID_STRING_ID_ISERIALNUMBER; > NATIVE_DEVICE *tracked_device, *ptr; > INT interface_index = 1; > + HID_DESCRIPTOR descriptor; > + BYTE *reportDescriptor; > + INT i; > > static const WCHAR ig_fmtW[] = {'I','G','_','%','i',0}; > static const WCHAR im_fmtW[] = {'I','M','_','%','i',0}; > @@ -104,6 +107,40 @@ NTSTATUS WINAPI PNP_AddDevice(DRIVER_OBJECT *driver, void *native) > > list_add_tail(&tracked_devices, &tracked_device->entry); > > + status = call_minidriver(IOCTL_HID_GET_DEVICE_DESCRIPTOR, device, NULL, 0, > + &descriptor, sizeof(descriptor)); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Device Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + for (i = 0; i < descriptor.bNumDescriptors; i++) > + if (descriptor.DescriptorList[i].bReportType == HID_REPORT_DESCRIPTOR_TYPE) > + break; > + > + if (i >= descriptor.bNumDescriptors) > + { > + ERR("No Report Descriptor found in reply\n"); > + HID_DeleteDevice(&minidriver->minidriver, device); > + return status; > + } > + > + reportDescriptor = HeapAlloc(GetProcessHeap(), 0, descriptor.DescriptorList[i].wReportLength); > + status = call_minidriver(IOCTL_HID_GET_REPORT_DESCRIPTOR, device, NULL, 0, > + reportDescriptor, descriptor.DescriptorList[i].wReportLength); > + if (status != STATUS_SUCCESS) > + { > + ERR("Cannot get Report Descriptor(%x)\n",status); > + HID_DeleteDevice(&minidriver->minidriver, device); > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + return status; > + } > + > + ext->preparseData = ParseDescriptor(reportDescriptor, descriptor.DescriptorList[0].wReportLength); > + ext->information.DescriptorSize = ext->preparseData->dwSize; > + HeapFree(GetProcessHeap(), 0, reportDescriptor); > + > status = call_minidriver(IOCTL_HID_GET_STRING, device, > (void*)index, sizeof(DWORD), serial, sizeof(serial)); > > >

3 2

Re: [8/13](resend)hidclass.sys: Add a processing thread for HID devices
by Andrew Eikum 03 Sep '15

03 Sep '15

On Wed, Sep 02, 2015 at 07:02:18AM -0500, Aric Stewart wrote: > --- > dlls/hidclass.sys/buffer.c | 21 ++++++ > dlls/hidclass.sys/device.c | 175 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/hidclass.sys/hid.h | 2 + > dlls/hidclass.sys/pnp.c | 2 + > 4 files changed, 200 insertions(+) > > > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 6f09393..94e3372 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -140,3 +140,24 @@ void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) > ring->pointers[index] = 0xffffffff; > LeaveCriticalSection(&ring->lock); > } > + > +void RingBuffer_Write(struct ReportRingBuffer *ring, void *data) > +{ > + UINT i; > + > + EnterCriticalSection(&ring->lock); > + memcpy(&ring->buffer[ring->end * ring->buffer_size], data, ring->buffer_size); > + ring->end++; > + if (ring->end == ring->size) > + ring->end = 0; > + if (ring->start == ring->end) > + { > + ring->start++; > + if (ring->start == ring->size) > + ring->start = 0; > + } > + for (i = 0; i < ring->pointer_alloc; i++) > + if (ring->pointers[i] == ring->end) > + ring->pointers[i] = ring->start; > + LeaveCriticalSection(&ring->lock); > +} > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index 326c994..e09a96c 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -198,6 +198,181 @@ void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device > IoDeleteDevice(device); > } > > +static void HID_Device_processQueue(DEVICE_OBJECT *device) > +{ > + LIST_ENTRY *entry; > + IRP *irp; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + HID_XFER_PACKET *packet; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + int ptr; > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE_(hid_report)("Processing Request (%i)\n",ptr); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_UNSUCCESSFUL; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + HeapFree(GetProcessHeap(), 0, packet); > +} > + > +static NTSTATUS WINAPI read_Completion(DEVICE_OBJECT *deviceObject, IRP *irp, void *context ) > +{ > + SetEvent(irp->UserEvent); > + return STATUS_MORE_PROCESSING_REQUIRED; > +} > + > +static DWORD CALLBACK hid_device_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + > + IRP *irp; > + IO_STATUS_BLOCK irp_status; > + IO_STACK_LOCATION *irpsp; > + DWORD rc; > + HANDLE events[2]; > + NTSTATUS ntrc; > + > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + events[0] = CreateEventA(NULL, FALSE, FALSE, NULL); > + events[1] = ext->halt_event; > + > + if (ext->information.Polled) > + { > + while(1) > + { > + HID_XFER_PACKET *packet; > + ResetEvent(events[0]); > + > + packet = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*packet) + ext->preparseData->caps.InputReportByteLength); > + packet->reportBufferLen = ext->preparseData->caps.InputReportByteLength; > + packet->reportBuffer = ((BYTE*)packet) + sizeof(*packet); > + packet->reportId = 0; > + > + irp = IoBuildDeviceIoControlRequest(IOCTL_HID_GET_INPUT_REPORT, > + device, NULL, 0, packet, sizeof(packet), TRUE, events[0], > + &irp_status); > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->CompletionRoutine = read_Completion; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; > + > + ntrc = IoCallDriver(device, irp); > + > + if (ntrc == STATUS_PENDING) > + rc = WaitForMultipleObjects(2, events, FALSE, INFINITE); > + > + if (irp->IoStatus.u.Status == STATUS_SUCCESS) > + { > + RingBuffer_Write(ext->ring_buffer, packet); I'm not opposed to what you have here, but a get-buffer/commit-buffer model would avoid an allocation and a memcpy. Although this would complicate simultaneous writes, if that's a concern.

2 1

Re: [7/13](resend)hidclass.sys: Implement IRP_MJ_READ for HID Devices
by Andrew Eikum 03 Sep '15

03 Sep '15

On Wed, Sep 02, 2015 at 07:02:11AM -0500, Aric Stewart wrote: > diff --git a/dlls/hidclass.sys/buffer.c b/dlls/hidclass.sys/buffer.c > index 2561235..6f09393 100644 > --- a/dlls/hidclass.sys/buffer.c > +++ b/dlls/hidclass.sys/buffer.c > @@ -80,6 +80,39 @@ void RingBuffer_Destroy(struct ReportRingBuffer *ring) > HeapFree(GetProcessHeap(), 0, ring); > } > > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *ring) > +{ > + return ring->buffer_size; > +} > + > +void RingBuffer_Read(struct ReportRingBuffer *ring, UINT index, void *output, UINT *size) > +{ > + void *ret = NULL; > + > + EnterCriticalSection(&ring->lock); > + if (index >= ring->pointer_alloc || ring->pointers[index] == 0xffffffff) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + return; > + } > + if (ring->pointers[index] == ring->end) > + { > + LeaveCriticalSection(&ring->lock); > + *size = 0; > + } > + else > + { > + ret = &ring->buffer[ring->pointers[index] * ring->buffer_size]; > + memcpy(output, ret, ring->buffer_size); Is it necessary to make a copy of the data in the ring buffer? Seems like returning a raw pointer would be more efficient. I flipped through the rest of the patch sequence and all uses of RingBuffer_Read seemed to be read-only. > + ring->pointers[index]++; > + if (ring->pointers[index] == ring->size) > + ring->pointers[index] = 0; > + LeaveCriticalSection(&ring->lock); > + *size = ring->buffer_size; > + } > +} > + > UINT RingBuffer_AddPointer(struct ReportRingBuffer *ring) > { > UINT idx; > diff --git a/dlls/hidclass.sys/device.c b/dlls/hidclass.sys/device.c > index a6660db..326c994 100644 > --- a/dlls/hidclass.sys/device.c > +++ b/dlls/hidclass.sys/device.c > @@ -36,6 +36,7 @@ > #include "devguid.h" > > WINE_DEFAULT_DEBUG_CHANNEL(hid); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e', > '\\','H','I','D','#','%','p','&','%','p',0}; > @@ -353,6 +354,48 @@ NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) > return rc; > } > > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) > +{ > + HID_XFER_PACKET *packet; > + BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > + UINT buffer_size = RingBuffer_GetBufferSize(ext->ring_buffer); > + NTSTATUS rc = STATUS_SUCCESS; > + int ptr = -1; > + > + packet = HeapAlloc(GetProcessHeap(), 0, buffer_size); > + ptr = (int)irp->Tail.Overlay.OriginalFileObject->FsContext; > + > + irp->IoStatus.Information = 0; > + RingBuffer_Read(ext->ring_buffer, ptr, packet, &buffer_size); > + > + if (buffer_size) > + { > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation( irp ); > + TRACE_(hid_report)("Got Packet %p %i\n", packet->reportBuffer, packet->reportBufferLen); > + if (irpsp->Parameters.Read.Length >= packet->reportBufferLen) > + { > + memcpy(irp->AssociatedIrp.SystemBuffer, packet->reportBuffer, packet->reportBufferLen); > + irp->IoStatus.Information = packet->reportBufferLen; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + else > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_OVERFLOW; > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + } > + else > + { > + TRACE_(hid_report)("Queue irp\n"); > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + rc = STATUS_PENDING; > + } > + HeapFree(GetProcessHeap(), 0, packet); > + > + return rc; > +} > + > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) > { > BASE_DEVICE_EXTENSION *ext = device->DeviceExtension; > diff --git a/dlls/hidclass.sys/hid.h b/dlls/hidclass.sys/hid.h > index c9bc338..34ec241 100644 > --- a/dlls/hidclass.sys/hid.h > +++ b/dlls/hidclass.sys/hid.h > @@ -58,6 +58,8 @@ typedef struct _BASE_DEVICE_EXTENSTION { > > UINT RingBuffer_AddPointer(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_RemovePointer(struct ReportRingBuffer *ring, UINT index) DECLSPEC_HIDDEN; > +void RingBuffer_Read(struct ReportRingBuffer *buffer, UINT index, void *output, UINT *size) DECLSPEC_HIDDEN; > +UINT RingBuffer_GetBufferSize(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > void RingBuffer_Destroy(struct ReportRingBuffer *buffer) DECLSPEC_HIDDEN; > struct ReportRingBuffer* RingBuffer_Create(UINT buffer_size) DECLSPEC_HIDDEN; > > @@ -81,6 +83,7 @@ NTSTATUS HID_LinkDevice(DEVICE_OBJECT *device, LPCWSTR serial, LPCWSTR index) DE > void HID_DeleteDevice(HID_MINIDRIVER_REGISTRATION *driver, DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > > NTSTATUS WINAPI HID_Device_ioctl(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +NTSTATUS WINAPI HID_Device_read(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_create(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > NTSTATUS WINAPI HID_Device_close(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > > diff --git a/dlls/hidclass.sys/main.c b/dlls/hidclass.sys/main.c > index 1e0e802..4be4409 100644 > --- a/dlls/hidclass.sys/main.c > +++ b/dlls/hidclass.sys/main.c > @@ -69,6 +69,7 @@ NTSTATUS WINAPI HidRegisterMinidriver(HID_MINIDRIVER_REGISTRATION *registration) > registration->DriverObject->DriverUnload = UnloadDriver; > > registration->DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = HID_Device_ioctl; > + registration->DriverObject->MajorFunction[IRP_MJ_READ] = HID_Device_read; > registration->DriverObject->MajorFunction[IRP_MJ_CREATE] = HID_Device_create; > registration->DriverObject->MajorFunction[IRP_MJ_CLOSE] = HID_Device_close; > > >

3 2

Re: [PATCH 5/6] wined3d: Return a texture from the swapchain resource creation callback.
by Henri Verbeet 03 Sep '15

03 Sep '15

On 3 September 2015 at 12:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -3034,32 +3034,29 @@ static HRESULT CDECL device_parent_volume_created(struct wined3d_device_parent * > return D3D_OK; > } > > -static HRESULT CDECL device_parent_create_swapchain_surface(struct wined3d_device_parent *device_parent, > - void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_surface **surface) > +static HRESULT CDECL device_parent_create_swapchain_texture(struct wined3d_device_parent *device_parent, > + void *container_parent, const struct wined3d_resource_desc *desc, struct wined3d_texture **texture) > { > struct d3d8_device *device = device_from_device_parent(device_parent); > struct wined3d_resource_desc texture_desc; > + struct wined3d_surface *surface; > struct d3d8_surface *d3d_surface; > - struct wined3d_texture *texture; > HRESULT hr; > > - TRACE("device_parent %p, container_parent %p, desc %p, surface %p.\n", > - device_parent, container_parent, desc, surface); > + TRACE("device_parent %p, container_parent %p, desc %p, texture %p.\n", > + device_parent, container_parent, desc, texture); > > texture_desc = *desc; > texture_desc.resource_type = WINED3D_RTYPE_TEXTURE; Now that you're creating a texture, you don't need to change the resource type anymore. You should just be able to pass "desc" to wined3d_texture_create(). > - *surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(texture, 0)); > - wined3d_surface_incref(*surface); > - wined3d_texture_decref(texture); > - > - d3d_surface = wined3d_surface_get_parent(*surface); > + surface = wined3d_surface_from_resource(wined3d_texture_get_sub_resource(*texture, 0)); > + d3d_surface = wined3d_surface_get_parent(surface); wined3d_resource_get_parent(). > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 765af0d..d50cd84 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4685,32 +4685,37 @@ HRESULT CDECL wined3d_device_reset(struct wined3d_device *device, > } > if (swapchain->desc.enable_auto_depth_stencil) > { > - struct wined3d_resource_desc surface_desc; > - struct wined3d_surface *surface; > + struct wined3d_resource_desc texture_desc; > + struct wined3d_texture *texture; > + struct wined3d_rendertarget_view_desc view_desc; > > TRACE("Creating the depth stencil buffer\n"); > > - surface_desc.resource_type = WINED3D_RTYPE_SURFACE; > - surface_desc.format = swapchain->desc.auto_depth_stencil_format; > - surface_desc.multisample_type = swapchain->desc.multisample_type; > - surface_desc.multisample_quality = swapchain->desc.multisample_quality; > - surface_desc.usage = WINED3DUSAGE_DEPTHSTENCIL; > - surface_desc.pool = WINED3D_POOL_DEFAULT; > - surface_desc.width = swapchain->desc.backbuffer_width; > - surface_desc.height = swapchain->desc.backbuffer_height; > - surface_desc.depth = 1; > - surface_desc.size = 0; > - > - if (FAILED(hr = device->device_parent->ops->create_swapchain_surface(device->device_parent, > - device->device_parent, &surface_desc, &surface))) > + texture_desc.resource_type = WINED3D_RTYPE_SURFACE; This looks wrong. It probably works anyway because you overwrite the resource type in the create_swapchain_texture() implementations.

1 0

Re: [2/4] user32: Add test case for DeferWindowPos() with invalid HWND (try 2)
by Marvin 02 Sep '15

02 Sep '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=16475 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000300F6 message 0118

1 0

Re: [1/4] user32: Add test case for basic {Begin, , End}DeferWindowPos() (try 2)
by Marvin 02 Sep '15

02 Sep '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=16474 Your paranoid android. === w7u (32 bit win) === win.c:3297: Test failed: hwnd 00060134 message 0200 win.c:3299: Test failed: message 0100 available

1 0

Re: [PATCH 2/2] ole32: Catch crashes in stub object destructors when destroying stub manager.
by Marvin 02 Sep '15

02 Sep '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=16468 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3390: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3391: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3407: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3408: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3445: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3446: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3463: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3464: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4 marshal.c:3427: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3428: Test failed: info->dwServerPid was 0x5ac instead of 0xfc4

1 0

Re: [PATCH 1/2] ole32: Quote executable name in CreateProcess call.
by Marvin 02 Sep '15

02 Sep '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=16467 Your paranoid android. === w8 (32 bit marshal) === marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3315: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3316: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3332: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3333: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3370: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3371: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3388: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3389: Test failed: info->dwServerPid was 0x920 instead of 0xfd4 marshal.c:3352: Test failed: info->cbSize was 629240687 instead of 48 marshal.c:3353: Test failed: info->dwServerPid was 0x920 instead of 0xfd4

1 0

Re: wineps.drv: Add glyph names for PostScript Format 1 glyphs.
by Nikolay Sivov 02 Sep '15

02 Sep '15

On 01.09.2015 19:21, Erich E. Hoover wrote: > + /* These PostScript Format 1 glyph names are stored by glyph index, do not reorder them. */ > + const char *glyph_table[] = { > + ".notdef", > + ".null", > + "nonmarkingreturn", > + "space", I don't think it can work like that for anything except .notdef. If I understand it correctly one of wineps.drv tasks is to generate Type1/Type42 font description from currently selected font, including converting outline data and metrics to proper format, and that selected font could be anything scalable. get_glyph_name() operates on glyph index, and ttf/otf formats are free to map codepoints to any index, so mapping you implemented will only work in case when currently selected font has 'post' table in Format 1. So if you really need adobe glyph name you have to use unicode-value-to-name lookup based on [1] probably (comes under Apache 2.0 license, no idea if it's usable in Wine). But even that won't always work I think, because we have to support ETO_GLYPH_INDEX case too where you have indices as input. [1] https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt

3 3

Re: [2/13]hidclass.sys: Add Plug-and-play and AddDevice
by Alexandre Julliard 02 Sep '15

02 Sep '15

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -57,9 +57,18 @@ typedef struct _minidriver > HID_MINIDRIVER_REGISTRATION minidriver; > > PDRIVER_UNLOAD DriverUnload; > + > + void *AddDevice; Please use the correct callback type and remove the corresponding casts. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: Implement CreateTypeLib
by Nikolay Sivov 02 Sep '15

02 Sep '15

This is wrong as CreateTypeLib() is supposed to create SLTG typelib. For https://bugs.winehq.org/show_bug.cgi?id=8780 preferred way is to fix vbscript/jscript so you don't have to switch to native. In any case you don't need separate QI call.

1 0

Re: user32: Hide horizontal Listbox scroll bar if no horizontal extent is set. (try 2)
by Joachim Priesner 01 Sep '15

01 Sep '15

Hi, I was wondering about the status of this patch I sent over a month ago. Anything I can do to improve it and get it reviewed? Joachim Am Samstag, 25. Juli 2015 schrieb Joachim Priesner: > According to https://msdn.microsoft.com/en-us/library/ms997541.aspx , a > horizontal scroll bar is shown iff the WS_HSCROLL style is set and > > a) the LBS_MULTICOLUMN style is set and there are too many items or > b) the LBS_MULTICOLUMN style is not set and a horizontal extent is > specified. > > Before this patch, the default scroll info min=0, max=100 would be set > even if no horizontal extent was specified. This led to WS_HSCROLL > list boxes that were less than 100 pixels wide to erroneously have > a horizontal scroll bar. > > Try 2 because I noted a minor formatting error in the first iteration of the patch. > --- > dlls/user32/listbox.c | 20 ++++++++- > dlls/user32/tests/listbox.c | 103 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 122 insertions(+), 1 deletion(-) > > diff --git a/dlls/user32/listbox.c b/dlls/user32/listbox.c > index 2902ac9..f4d890b 100644 > --- a/dlls/user32/listbox.c > +++ b/dlls/user32/listbox.c > @@ -265,7 +265,7 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > if (descr->style & WS_VSCROLL) > SetScrollInfo( descr->self, SB_VERT, &info, TRUE ); > > - if (descr->style & WS_HSCROLL) > + if ((descr->style & WS_HSCROLL) && descr->horz_extent) > { > info.nPos = descr->horz_pos; > info.nPage = descr->width; > @@ -274,6 +274,20 @@ static void LISTBOX_UpdateScroll( LB_DESCR *descr ) > info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > + else > + { > + if (descr->style & LBS_DISABLENOSCROLL) > + { > + info.nMin = 0; > + info.nMax = 0; > + info.fMask = SIF_RANGE | SIF_DISABLENOSCROLL; > + SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > + } > + else > + { > + ShowScrollBar( descr->self, SB_HORZ, FALSE ); > + } > + } > } > } > > @@ -1248,6 +1262,8 @@ static LRESULT LISTBOX_SetHorizontalExtent( LB_DESCR *descr, INT extent ) > info.nMin = 0; > info.nMax = descr->horz_extent ? descr->horz_extent - 1 : 0; > info.fMask = SIF_RANGE; > + if (descr->style & LBS_DISABLENOSCROLL) > + info.fMask |= SIF_DISABLENOSCROLL; > SetScrollInfo( descr->self, SB_HORZ, &info, TRUE ); > } > if (descr->horz_pos > extent - descr->width) > @@ -2537,6 +2553,8 @@ static BOOL LISTBOX_Create( HWND hwnd, LPHEADCOMBO lphc ) > } > } > > + LISTBOX_UpdateScroll(descr); > + > TRACE("owner: %p, style: %08x, width: %d, height: %d\n", descr->owner, descr->style, descr->width, descr->height); > return TRUE; > } > diff --git a/dlls/user32/tests/listbox.c b/dlls/user32/tests/listbox.c > index 79d18e7..9380457 100644 > --- a/dlls/user32/tests/listbox.c > +++ b/dlls/user32/tests/listbox.c > @@ -1665,7 +1665,10 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1677,6 +1680,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > > @@ -1692,7 +1712,71 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 100, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 64, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) == 0, > + "List box should not have a horizontal scroll bar\n"); > + > + DestroyWindow(listbox); > + > + > + listbox = create_listbox(WS_CHILD | WS_VISIBLE | WS_HSCROLL | LBS_DISABLENOSCROLL, parent); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 0, "Got wrong initial horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent < width */ > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 64, 0); > > res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > @@ -1704,6 +1788,23 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 63, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > + > + /* horizontal extent > width */ > + SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 184, 0); > + > + res = SendMessageA(listbox, LB_GETHORIZONTALEXTENT, 0, 0); > + ok(res == 184, "Got wrong horizontal extent: %u\n", res); > + > + sinfo.cbSize = sizeof(sinfo); > + sinfo.fMask = SIF_RANGE; > + br = GetScrollInfo(listbox, SB_HORZ, &sinfo); > + ok(br == TRUE, "GetScrollInfo failed\n"); > + ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > + ok(sinfo.nMax == 183, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > SendMessageA(listbox, LB_SETHORIZONTALEXTENT, 0, 0); > > @@ -1716,6 +1817,8 @@ static void test_extents(void) > ok(br == TRUE, "GetScrollInfo failed\n"); > ok(sinfo.nMin == 0, "got wrong min: %u\n", sinfo.nMin); > ok(sinfo.nMax == 0, "got wrong max: %u\n", sinfo.nMax); > + ok((GetWindowLongA(listbox, GWL_STYLE) & WS_HSCROLL) != 0, > + "List box should have a horizontal scroll bar\n"); > > DestroyWindow(listbox); > >

1 0

Re: [PATCH] Fix performance problem in debug tracing
by Alexandre Julliard 01 Sep '15

01 Sep '15

Daniel Santos <daniel.santos(a)pobox.com> writes: > Currently, if any classes are passed to WINEDEBUG (nb_debug_options > 0) then > the initial lazy-init call to __wine_dbg_get_channel_flags() never sets the > flags in the struct __wine_debug_channel in the object file, resulting in all > 45k trace calls in wine making a function call, running bsearch on > debug_options with string compare, etc. Not really. Only the channel that is actually enabled will make repeated function calls. This is done on purpose so that you can toggle it on and off for a given process from the task manager. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/7] d3d11: Add ID3D11Texture3D interface stub.
by Henri Verbeet 01 Sep '15

01 Sep '15

On 1 September 2015 at 00:27, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + else if (IsEqualGUID(riid, &IID_ID3D10Texture3D) > + || IsEqualGUID(riid, &IID_ID3D10Resource) > + || IsEqualGUID(riid, &IID_ID3D10DeviceChild)) > + { > + IUnknown_AddRef(iface); > + *object = &texture->ID3D10Texture3D_iface; For what it's worth, this works here because the d3d10 and d3d11 interfaces share the reference count, but in general you should AddRef() the actual interface you're returning.

2 2

Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
by Alexandre Julliard 01 Sep '15

01 Sep '15

Martin Storsjo <martin(a)martin.st> writes: > Since MSVC 2015/Windows 10, the C runtime has now been split into two > parts, ucrtbase, which is the generic C runtime which is now considered > a system component, and vcruntimeX which is specific to the compiler > version. > > Even if this DLL only has a fraction of the functions of the full > msvcrt/ucrtbase, it still requires almost all the object files from > msvcrt. It would be better to isolate the corresponding code so that we don't need all the files. -- Alexandre Julliard julliard(a)winehq.org

2 2

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