September 2015 - Wine-devel

WineConf 2015 decisions
by Alexandre Julliard 10 Oct '15

10 Oct '15

Over the last few months there have been a lot of discussions about how to improve our development process. I've been gathering feedback, and last week at WineConf I summarized the suggestions in my keynote presentation; the slides can be viewed at http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are: - Wine-staging is now considered an integral part of the Wine development process, and will be used as a mechanism to enable more patches to meet the requirements for inclusion in the main tree. We will all be working together as a team. - Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla. - We will switch to a time-based stable release, on a yearly schedule. The code freeze will start every year in the fall. Michael Stefaniuc will be maintaining the stable branch starting with 1.8. - We will start enforcing a Signed-Off-By header on patches, to make it possible to better distribute reviewing responsibility, and to allow multiple authors to cooperate on a patch. - We will keep a list of maintainer contact information for the various submodules; developers will be encouraged to go through the respective maintainer before submitting to wine-patches. - There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches. - The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved. - We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements. These changes will be implemented over the next few weeks. I'm hoping that this will make the development process more pleasant for everybody, and enable us to better respond to users' needs. Once these changes are in place, I'll also encourage everybody who had given up in disgust to give us another chance; and if things are still not satisfactory, please send us feedback. This is a work in progress, and we will continue to listen and work on making things better. -- Alexandre Julliard julliard(a)winehq.org

9 17

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: [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

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