wine-devel November 2014

wine-devel@winehq.org

48 participants
175 discussions

WineHQ Downloads page needs a disclaimer
by Rosanne DiMesio 06 Nov '14

06 Nov '14

A good example of why: https://bugs.winehq.org/show_bug.cgi?id=36964#c15 Our Downloads page doesn't directly say that the binary packages listed are officially endorsed, but it does give that impression: only a few distros are listed, the very top of the page says "Supported Wine" in big letters, and while the 3rd Party Tools section explicitly says those aren't supported, the Binary Downloads section gives no such warning. Users who assume that the packages listed on that page have the "WineHQ seal of approval" aren't being unreasonable. This isn't just an issue with the Fedora packges. The Ubuntu packages with winepulse and changes to dsound have long been a problem (plus https://bugs.winehq.org/show_bug.cgi?id=34299), and the CentOS/RHEL 7 packages are 64 bit only. I have stickies on the forum about all these things, but not everyone comes through the forum. The Downloads page needs to make it much clearer to users that the distro packages listed are not "official" WineHQ packages. The wording could be something like "Binary packages are built and maintained by the distros, and may contain patches that are not supported here. The links below are provided solely as a convenience to users and do not represent an endorsement." (Posting here because that's what I've been told to do for such issues.) -- Rosanne DiMesio <dimesio(a)earthlink.net>

3 2

Re: [1/2] d3dx9_36: Implement D3DXCreatePolygon. (try 5)
by Matteo Bruni 05 Nov '14

05 Nov '14

2014-11-05 18:47 GMT+01:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Argh, head->wall - accidentially made the changes to v2 instead of v3. ;) > Again replace ~0 -> ~0U. Yeah, I noticed that but it wasn't a showstopper of course, no need to bang your head to the wall :D I confirm my approval (as much as it might matter), including patch 107477. > > Based on a patch by David Adam. > --- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/mesh.c | 88 +++++++++++++++++++++++++++++++++++++++++++++ > include/d3dx9shape.h | 2 ++ > 3 files changed, 91 insertions(+), 1 deletion(-) > > >

1 0

Re: [2/2] d3dx9_36/tests: Add tests for D3DXCreatePolygon. (try 4)
by Matteo Bruni 05 Nov '14

05 Nov '14

2014-11-05 18:25 GMT+01:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Changes in try 4: > * Use smaller buffer > * Fix typo > * Remove error checking & goto > > Changes in try 3: > * Replace ~0 -> ~0U. > > Changes in try 2: > * Lot of style cleanups - hopefully I didn't miss anything. > * Fix condition for 'sides' argument (should be >= 3, not just != 0) > * Added test to check if *mesh is cleared on error - tests show that this is not the case. > I only kept a single test for that to avoid making the test code too ugly. > > Based on a patch by David Adam. > --- > dlls/d3dx9_36/tests/mesh.c | 155 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 155 insertions(+) FWIW, series looks good to me.

1 0

Re: [2/2] d3dx9_36/tests: Add tests for D3DXCreatePolygon. (try 3)
by Matteo Bruni 05 Nov '14

05 Nov '14

2014-11-04 19:57 GMT+01:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Based on a patch by David Adam. > --- > dlls/d3dx9_36/tests/mesh.c | 163 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 163 insertions(+) Hi Sebastian, first of all, let me say I'm okay with these patches going in as they are. IMHO there is still room for improvement though: +static void test_polygon(IDirect3DDevice9 *device, float length, unsigned int sides) +{ + HRESULT hr; + ID3DXMesh *polygon; + struct mesh mesh; + char name[256]; No need to use such a big array there. + hr = D3DXCreatePolygon(device, length, sides, &polygon, NULL); + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK)\n", hr); + if (hr != D3D_OK) + { + skip("Couldn't create box\n"); Copy-paste typo. FWIW, we usually prefer a '.' at the end of trace messages. + adjacency = NULL; + hr = D3DXCreatePolygon(device, 3.0f, 11, &polygon, &adjacency); + ok(hr == D3D_OK, "Expected D3D_OK, received %#x\n", hr); + + if (FAILED(hr)) + { + skip("D3DXCreatePolygon failed\n"); + goto end; + } That D3DXCreatePolygon() call is not expected to ever fail, so no need for the "if". + if (adjacency) + ID3DXBuffer_Release(adjacency); If you remove the previous "if" you won't need the "end" label and this one becomes always true. Then I'd put this Release() right after the loop checking the adjacency. Again, I don't care about those details, this is still good enough for me. It's mostly about any future patch you'd want to send in.

2 2

Re: advapi32/tests: Avoid a crash on some linux hosts.
by Marvin 05 Nov '14

05 Nov '14

1 0

Re: msi: Simplify check for an empty string (PVS-Studio)
by Marvin 05 Nov '14

05 Nov '14

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=10031 Your paranoid android. === w2000pro (32 bit action) === The test timed out === wxppro (32 bit action) === The test timed out === wvistau64 (32 bit action) === The test timed out === w7u (32 bit action) === The test timed out === w8 (32 bit action) === The test timed out === wvistau64 (64 bit action) === Failure running script in VM: timed out waiting for the child process

2 1

Re: imm: Fix switching to Chinese IEM after typing some English will fail
by Aric Stewart 05 Nov '14

05 Nov '14

On 11/3/14, 8:52 PM, 黄巍 wrote: > Bug 35896 - Switching to Chinese input method after typing some English will fail. > https://bugs.winehq.org/show_bug.cgi?id=35896 > > --- > dlls/imm32/imm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 7ed1fe6..47c7ea8 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -2901,6 +2901,8 @@ BOOL WINAPI ImmProcessKey(HWND hwnd, HKL hKL, UINT vKey, LPARAM lKeyData, DWORD > else > return FALSE; > > + data->immKbd = IMM_GetImmHkl(hKL); > + > if (!data->immKbd->hIME || !data->immKbd->pImeProcessKey) > return FALSE; > > I recently made a fix to this area of a bug very similar to the one your reported. Have you tested with the most recent development build without your patch to see if it was already fixed? I feel like your change should be unnecessary after my modification. -aric

2 1

Re: [PATCH 7/7] reg: Clean up reg_delete
by Stefan Dösinger 04 Nov '14

04 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-04 21:15, schrieb Jonathan Vollebregt: > +#define MAX_VALUE_NAME 16384 This is ugly. Why not use lpcMaxValueNameLen from RegQueryInfoKey like the old code does? > +#define ERROR_NO_DELETE_ROOTKEY 20003 Ah, here we have the case I raised in patch 3 :-) . This seems like another error case that advapi32 should be able to handle for you. It needs tests in reg.exe and advapi32.dll. That's assuming the call is really supposed to fail - if it succeeds we obviously don't want to test it and destroy the Windows installation in the process. Before you test this on the testbot ask fgouget if it is safe to test. I believe it is since the VMs are restored from read-only snapshots after every test run. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJUWVxsAAoJEN0/YqbEcdMwQhQP92zeYVEhBb4RXRMhtNsrtU6R jHPf1hGDtMM484wNhpHv97C/2sQ5RUq4bEAanyNNxdLZEFUJ7vT3LVNcEOmPqVI+ jKR5G9h0tXtqaGlee6fHiMPN6ZfRZjxqCNrNICXcCO13f/eErT+uCRPqLAh5b8YY Tpo5CsOJgS9tGh2UHBFbRt+ZAa/M0Mu4N/6253140HxQfVVgJ2Q3j3fERJ5TacJI o26uQpWD0Olu+pv64Ej3eehnGJ5cmHld9wBdbIJjRwvQ8knukzPC6tdhAlZrVoTN KI3F8r+LIlNQm/VF/E3cQWo/vTXDJsQ5tArOMyQfWvLBzpHOZ3Lye4fF2wwvgVFG VOfcui1eFmGYR/4f+r/mxbespuyYYBBD+rR2kDnhXgrxqegDIpyfPFN3cQQDSHJD FVoEb8mb4nxkqckywWw4tDBp7TM0dOJsUKeLIyjmT4sl+LH8YWCuINL0eN7i9AlV XhK7wjF02vVmXrRiJDycJkAAoS4yxY5tyEPM0Ua/M68cLQ5SJNx1oOXWTJSu5W+b XNAgc4MCGhtNOsaNE7SQdyETYfoqeStv1BxEb0eTFb+z+uia0lDpxFuytbSkTqWH xEJJe+bmNnhDqkmOUOz8ShfWoGVmvwGg99t+2XBWmRaveFBHXvJkb2D4XXjfCK7D CxvCYItQ7xN6Ub9vKMc= =deiq -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/7] reg: Add wchar/raw data conversion functions
by Stefan Dösinger 04 Nov '14

04 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-04 21:15, schrieb Jonathan Vollebregt: > +static LSTATUS wchar_get_data( const WCHAR *input, const DWORD type, > + const WCHAR separator, DWORD *size_out, BYTE **out) > +{ > + DWORD i; > > - switch (reg_type) > + if (!input) > + return data_default(type, size_out, out); > + > + switch (type) > { > case REG_SZ: > + case REG_EXPAND_SZ: Another option to consider instead of the switch construct: Add conversion function pointers to struct type_rel. In this case you cannot use an anonymous structure. wchar_get_type would return a const struct type_rel *, and you can get the REG_* DWORD from it and call the data conversion function. The same can be done in the opposite direction. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUWVgQAAoJEN0/YqbEcdMwfBUP/1IEsXZU+GuDO/fyjUGeRcke TBPRvRdgWpDtGc9Bm35dimRPXX8nw/Sk/2KLRRpqnWKQp76LuwYCkB7exWaJLWDP jxb/MP3QdWKkxxmkJDwerviB2ouoW6TWgatksCO+MOmxzQcwrJj2l88LefgQeD0Y w3T/kv5oWsKpIuZVJjtg4Jw8FNo1Q7PQI1bJaoa16t+Hb1KPUwn0U5/bVqD30B8H OqCEdv1jlqSYEMXP4yD3QXpapyDu8R//gCqcIdFml1MO9XdOR5sSnkdUqQipSNjZ 0UyBDtUVp/3KsI+cz4Uk3HqgaHnXFhESyG0CBMySM/we3ofWGvya5lOmPBP4+Tzo pI0xlzI2eapf9Pr9ROrz5qELdUTFc2ahF1EqVOvltLJxpVgBgNhMe7PaG11gJTsE FvK0BgAbvUOfRyiWI6MiyQcU6cwznXM19i0rGHj3hO1IgwcMZazn5weus3qrm+jM /vS2Ul6eUoB7kdWZgrKG2ehBLMLrQZRe0G4ra3B3AcCl7Ol05Sxm0F6Wntm0sZZg 2CTbyX3SwXeGSax4DH+MzFG3u31h6dNArtKLlKU0NzW9t7pGxW8L8QIFxQaMAvBS pzNwB1icU0Vc49ETx1fK6SmMZTuDU6mPRrEqxpdBfn+YGW6acnZMFq4qKe1rxgyy aXvXsCnlBCn90b0wefPI =S2A4 -----END PGP SIGNATURE-----

1 0

Re: [PATCH 5/7] reg: Add wchar/raw data conversion functions
by Stefan Dösinger 04 Nov '14

04 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-04 21:15, schrieb Jonathan Vollebregt: > +#define ERROR_NAN 20002 ERROR_NEGATIVE_VALUE would be a better name since NAN is a floating point thing. > +static LSTATUS data_default(const DWORD type, DWORD *size_out, BYTE **out) I think the old behavior of passing NULL to RegSetValueExW if no data is specified with /d was nicer. That's assuming it does the right thing for all data types. This may need tests in advapi32/tests/registry.c The bottom line of this suggestion and things like passing a NULL HKEY to RegOpenKey in patch 3, or trailing backslashes in patch 2 is to leave as much error handling to the advapi32 functions as possible. I think reg.exe should be a fairly minimal string parsing program that blindly forwards everything to advapi32 and doesn't do much checking on its own. The exception are kinda of errors that are not possible in advapi32 by design, like a negative REG_DWORD. You're welcome to prove me wrong with tests that show advapi32 and reg.exe error handling differ :-) Another possibility is that native assumes a default value string of "" if /d is not specified, which then produces behavior like an empty REG_SZ and fails to convert into a DWORD. > { > - LPBYTE out_data = NULL; > - *reg_count = 0; > + switch (type) > + { > ... > + case REG_DWORD: > + case REG_DWORD_BIG_ENDIAN: > + { > + return ERROR_NAN; > + } It's odd that there isn't a default value for REG_DWORD, 0 would be a logical choice. But the tests confirm this... But I don't see why you haven't removed the todo_wine from the according test. > + default: > + return ERROR_UNSUPPORTED_TYPE; I think this is a bad place to catch unsupported data types. "type" comes from one of your own functions, namely wchar_get_type(). If reg.exe shouldn't support any of the data types not explicitly handled here then wchar_get_type should already return an error in this case. Otherwise you can make this a FIXME("Add support for type %u\n" type); -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUWVSuAAoJEN0/YqbEcdMwd9IP/A2J8L9/QJxCHc+g+rOFI/GB y+NA9dQJ2MXnCC7DeGU0myblOeRlTkFRqA3R/isM21IBSmOPLseLqSexzuvf8fwf y1cSEZ49z3yLI7rrVt0VEhX8p9dqkczU+W3GWE2M9jOkP88pxNSPsm5vIO+VtJRi 1GqGp3Snz4NQ6jCQGHn30M4vwgxRXS0gxkmGj1iEcA772vEWpNuAOptDQ9j0fGan aXzdmQMF8VDJMeGR6uI+8JuM2ERAjt9EE/2PGLjH0b9zpPR8V7Z+ECqPJh9kTJv6 wxM1wCHzsGXDQYlqQzQjaoWNIchrEybqgnaar0KS4H0+Hz8DKOz1StDB5bfQ2bHi lBiQ5a4T6AXOlNOH49RiLcPLrHUoUcmvFd+Cr4HngySeu0WkFvtsfdFjppJW+nrw aXMuKoZpje0+5EjTgI255Oi6vZnx+piy1hRn1zSTE5xq9lnyEPVaemtus77x4rOL 82/TChrSaeYg/uXrFNWFZG9fb38L2EIyeIQSLZwTYIHrE6p2IGp1AnMPkDcM4TcC rMQXEW3IPdmR2EXf2gZ0PuU3Sab4M9dWuMsJ/E4H6vOu/d9/BfnGle1TR6hP6Pqu XlZrjrm0Ifh/fnWec75Yc6rpj1Ueen4C1/dAxjDe3sn509qAvfREUtUH3psBLGXQ uCkQoWInlbV4UmVjl1Gg =hZLk -----END PGP SIGNATURE-----

1 0

Jump to page:

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 November 2014