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

AUTHORS: Revert commit 5da31c8817293ff98b4defceb962f7d0fbc25829 (Was: How to undo authors list generated automatically.)
by Tae Wong 19 Nov '13

19 Nov '13

You want to revert the commit 5da31c8817293ff98b4defceb962f7d0fbc25829. Quintana said that it's a suggestion for it. Some Portuguese last names sorted under first instead of second element! See blob e69040d889c1748d538f1198f6c85b97f55418b5. Araujo Chaves, Pedro, Jr Arcoverde da Rocha, Augusto Castro Lopo, Erik de Example of Portuguese last names sorted by the second element: Chaves, Pedro Araujo, Jr Lopo, Erik de Castro Rocha, Augusto Arcoverde da

1 1

Re: shell32/tests: Change Dec to Hex
by Lauri Kenttä 19 Nov '13

19 Nov '13

On 2013-11-19 18:03, Zhenbo Li wrote: > + "Expected 0x402 or ERROR_FILE_NOT_FOUND, got %d\n", retval); You should probably change the %d to %x, too. On the other hand, I don't see any need for your patch whatsoever. Maybe you should explain yourself. -- Lauri Kenttä

4 3

Re: [2/2] quartz/tests: Add tests for IVMRMonitorConfig and IVMRMonitorConfig9 interface
by Alexandre Julliard 19 Nov '13

19 Nov '13

Sebastian Lackner <sebastian(a)fds-team.de> writes: > diff --git a/dlls/quartz/tests/Makefile.in b/dlls/quartz/tests/Makefile.in > index ae5fbac..94b2f44 100644 > --- a/dlls/quartz/tests/Makefile.in > +++ b/dlls/quartz/tests/Makefile.in > @@ -8,6 +8,7 @@ C_SRCS = \ > filtermapper.c \ > memallocator.c \ > misc.c \ > + monitorconfig.c \ > referenceclock.c \ > videorenderer.c Please merge it into one of the existing files. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: shell32/tests: Change Dec to Hex
by Zhenbo Li 19 Nov '13

19 Nov '13

Sorry, something was wrong with my network, so I had send my patch twice. 2013/11/20 Zhenbo Li <litimetal(a)gmail.com>: > --- > dlls/shell32/tests/shlfileop.c | 22 +++++++++++----------- > 1 file changed, 11 insertions(+), 11 deletions(-) > > -- Have a nice day! Zhenbo Li

1 0

Re: [PATCH] ddraw: add dsurface dimension tests, try 2
by Patrick Rudolph 19 Nov '13

19 Nov '13

Am 2013-11-18 16:44, schrieb Stefan Dösinger: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Overall, did you check if there is a capability reporting problem? The > game may have the bad size from our DDSCAPS structure. > I'm not sure. It successfully creates a primary surface with dimension 320x240 and it creates offscreen surfaces with dimension 320x240 and DDSCAPS_SYSTEMMEMORY flag set. Only offscreen surfaces with DDSCAPS_VIDEOMEMORY flag set are out of range. I was wondering: 15728640 = 320 << 16 and 20971520 = 240 << 16. Where does the two byte offset come from ? > Even if this is a capability problem I think this test is relevant. > > Am 2013-11-17 20:19, schrieb Patrick Rudolph: >> dlls/ddraw/tests/dsurface.c | 88 > +++++++++++++++++++++++++++++++++++++++++++++ > > Please add new tests to ddraw{1, 2, 4, 7}.c, and if possible implement > them for all ddraw versions. I can do that as well. > >> + ZeroMemory(&desc, sizeof(desc)); > memset(desc, 0, sizeof(desc)); is preferred. > >> + if(!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) + { + >> todo_wine ok(ret == DDERR_INVALIDPARAMS, "Creating an > offscreen plain surface with width 0xffff and height 1 returned > %08x\n", ret); >> + } > Is there any situation in which wine enters this codepath? I think the > todo_wine is not needed here. You are right, wine always presents a direct draw device with DDSCAPS_VIDEOMEMORY. I removed ligGL, ddraw still "works", but doesn't render anything. > >> + /* Test out of memory surface size */ + ZeroMemory(&desc, >> sizeof(desc)); + desc.dwSize = sizeof(desc); + desc.dwFlags = >> DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH; + desc.ddsCaps.dwCaps |= >> DDSCAPS_OFFSCREENPLAIN | > DDSCAPS_VIDEOMEMORY; >> + desc.dwHeight = 0xffff; + desc.dwWidth = 0xffff; + /* >> this should allocate 4.29 Gbyte of video memory */ > Testing DDSCAPS_SYSTEMMEMORY might show some interesting results as > well, especially in a Win64 executable. > I can add tests for this. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSijXyAAoJEN0/YqbEcdMwolYP+wWH7o7Dn9LjmjJq0dca5ZD9 > EKfyGNxrtg/Th1o2qKdP4rmsl1G8UC96Xo2BP9Fi5tH9BZTzAXTiq2pfSiKGf0Z7 > l48UbVGVuVd/nxBG8ULZDS7e8b9h+NwcprM3flWW6frbqsDMxf1LPhtNsEQU8gnE > 0/hFXW/T33FkPP3XiBK6vCgWjP1umK9clcQHvit7DitFpFBmwOj5SxktoIsoPVpL > TcOiaaXKcABTbKCz4xclOaAMM7k94cH0ByJBVu+8OXNTOHzd0xbtrnFl6UZi74jH > dQyqLIyQ4uDs1760He7WtwgMEeF4NhV+u3A6qRP3eLceSf59OhEhSUNGKu5yduVb > F16yGgQiTIKHpqtD1sT1RPEDAZgUYL9Uq8BnUrPbNZ+FJI5ZwIbY7KghozAhUweA > /TC9VMLwUnJKk8v/8xHPY1WI3474Pht4joahUNWkTQ8QuN7ms44IyyyALBsWM3gF > eOSTBNEcWZz+3uRaS68/ZDeqzo+R+dwmwU8XTeWEMTxuy30x1OdCTp3BgR8YNXMa > 2uLWa5mL4pkOAVJ6gI6HHPpX8T582lB3PcZgRMd5QirwIg76dwvnk6zpiv4RqFS5 > 3HCCey4c3FO4aFhDcelkNsdcpCMbaGyv4lqtLDzBe7bR5xOrtWvmdl5r3vvlCbO2 > uERNPhePZ8ogI6buwboM > =v8j0 > -----END PGP SIGNATURE-----

2 1

Re: gdiplus: Implement GdipCreateRegionRgnData. Take 2.
by Vincent Povirk 18 Nov '13

18 Nov '13

Please note that most of this format (everything except the first 8 bytes of region_header) is documented in MS-EMFPLUS section 2.2.1.8: http://msdn.microsoft.com/en-us/library/cc230724.aspx + switch (path_header->flags & FLAGS_INTPATH) You should check for other flags here, namely 0x1000 which indicates RLE compression of point types and 0x0400 which indicates that points are relative to the previous point. (Not saying we need to support them initially, but please check so we know if they appear. Also, the lower 16 bits other than those flags are supposed to always be 0, so maybe we should check them for unknown values as well.) + if (!region_header || region_header->magic != VERSION_MAGIC) + return InvalidParameter; This should also accept 0xdbc01002, for GDI+ version 1.1. + if (i == 1) continue; /* data[1] never matches */ If that's the case, shouldn't you have a test that it doesn't match?

2 5

Re: Assorted spelling fixes.
by Jonas Maebe 18 Nov '13

18 Nov '13

On 18 Nov 2013, at 20:34, Frédéric Delanoy wrote: > --- a/dlls/ole32/itemmoniker.c > +++ b/dlls/ole32/itemmoniker.c > @@ -123,7 +123,7 @@ static ULONG WINAPI ItemMonikerImpl_Release(IMoniker* iface) > > ref = InterlockedDecrement(&This->ref); > > - /* destroy the object if there's no more reference on it */ > + /* destroy the object if there are no moee references on it */ "no more" instead of "moee". I would also say "no more references to it" instead of "on it". Jonas

2 1

Re: shell32/tests: delete a nonexistent file in an existent dir or a nonexistent dir
by Nikolay Sivov 18 Nov '13

18 Nov '13

On 11/18/2013 20:12, Zhenbo Li wrote: > I found that shell32 test hasn't covered DE_INVALIDFILES > --- > dlls/shell32/tests/shlfileop.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > + ret = SHFileOperationA(&shfo); > + todo_wine > + ok(ret == 1026 || > + ret == ERROR_FILE_NOT_FOUND || /* Vista */ > + broken(ret == ERROR_SUCCESS), /* NT4 */ > + "Expected 1026 or ERROR_FILE_NOT_FOUND, got %d\n", ret); I think it's safe to mark XP result broken() as well. Also please use 0x402 value here for it, it's easier to find this way.

1 0

Re: [PATCH] ddraw: add dsurface dimension tests, try 2
by Stefan Dösinger 18 Nov '13

18 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Overall, did you check if there is a capability reporting problem? The game may have the bad size from our DDSCAPS structure. Even if this is a capability problem I think this test is relevant. Am 2013-11-17 20:19, schrieb Patrick Rudolph: > dlls/ddraw/tests/dsurface.c | 88 +++++++++++++++++++++++++++++++++++++++++++++ Please add new tests to ddraw{1, 2, 4, 7}.c, and if possible implement them for all ddraw versions. > + ZeroMemory(&desc, sizeof(desc)); memset(desc, 0, sizeof(desc)); is preferred. > + if(!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) + { + > todo_wine ok(ret == DDERR_INVALIDPARAMS, "Creating an offscreen plain surface with width 0xffff and height 1 returned %08x\n", ret); > + } Is there any situation in which wine enters this codepath? I think the todo_wine is not needed here. > + /* Test out of memory surface size */ + ZeroMemory(&desc, > sizeof(desc)); + desc.dwSize = sizeof(desc); + desc.dwFlags = > DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH; + desc.ddsCaps.dwCaps |= > DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY; > + desc.dwHeight = 0xffff; + desc.dwWidth = 0xffff; + /* > this should allocate 4.29 Gbyte of video memory */ Testing DDSCAPS_SYSTEMMEMORY might show some interesting results as well, especially in a Win64 executable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSijXyAAoJEN0/YqbEcdMwolYP+wWH7o7Dn9LjmjJq0dca5ZD9 EKfyGNxrtg/Th1o2qKdP4rmsl1G8UC96Xo2BP9Fi5tH9BZTzAXTiq2pfSiKGf0Z7 l48UbVGVuVd/nxBG8ULZDS7e8b9h+NwcprM3flWW6frbqsDMxf1LPhtNsEQU8gnE 0/hFXW/T33FkPP3XiBK6vCgWjP1umK9clcQHvit7DitFpFBmwOj5SxktoIsoPVpL TcOiaaXKcABTbKCz4xclOaAMM7k94cH0ByJBVu+8OXNTOHzd0xbtrnFl6UZi74jH dQyqLIyQ4uDs1760He7WtwgMEeF4NhV+u3A6qRP3eLceSf59OhEhSUNGKu5yduVb F16yGgQiTIKHpqtD1sT1RPEDAZgUYL9Uq8BnUrPbNZ+FJI5ZwIbY7KghozAhUweA /TC9VMLwUnJKk8v/8xHPY1WI3474Pht4joahUNWkTQ8QuN7ms44IyyyALBsWM3gF eOSTBNEcWZz+3uRaS68/ZDeqzo+R+dwmwU8XTeWEMTxuy30x1OdCTp3BgR8YNXMa 2uLWa5mL4pkOAVJ6gI6HHPpX8T582lB3PcZgRMd5QirwIg76dwvnk6zpiv4RqFS5 3HCCey4c3FO4aFhDcelkNsdcpCMbaGyv4lqtLDzBe7bR5xOrtWvmdl5r3vvlCbO2 uERNPhePZ8ogI6buwboM =v8j0 -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/5] wined3d: Create a proper texture for the software cursor.
by Stefan Dösinger 18 Nov '13

18 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-11-18 10:46, schrieb Henri Verbeet: > + desc.pool = WINED3D_POOL_SYSTEM_MEM; Why did you use this pool instead of managed or dynamic default to allow a GL blit? I haven't tested this, but I suspect the WINEDDBLT_KEYSRC hack won't work in a software blit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSihI1AAoJEN0/YqbEcdMwAN4P/iRR8C1ctmY2Eu/FUORAIcmr IFDOyZnxecPmM+0pEOX+W2RVrJmwPlnI8PDBwmKnqJNx80FxEWHIq4gTzS/InhGJ BykTeNTyb7YdHr76V6lZKr8TJTl0CaP8QWEtnl342lGBFaLjXbGbjN5Uf8v3Nv6O 3mBI0hHKvPB2gNtNfnQA2y+xhE/an0s1P0hAP6SE/BcdB9xZORCyBA5Iq1ajTBqz f9lpiIW8+9vApEEGF9wncikgvJR/snGY+JhzcxCPKg5sslDyhVBY3AgfGOR9y9IU xHgF+nN8G99MJKl/+xuvbAmcAKrltH9iR2VYBH0RtJRF0GvT9mVdbASybR6gak55 j39B+X4VpZor+6bZtaV/0+oGShxEqz4mIu6RwPQHCLL7c5IpRM3SnVmu2BQlTEhB j2SJ61P+uQdAEHAjfcl5blVuhbkPwsGA5m0oNRCRopxylbnYNbM00V8P37kkEg7D bMrs/LkP8QWN4lZoj9kZ4eR9TyvjSkSFL+5eKuULtZNlhUKfKrntBzwKfpuNJYxs 9icHe30boy4aHe0xfrVTcN9K6ALIzV4xmUgItWckjpmRTwOwEnen13tTXcKLmJWG 2CXZEz59sa7eEwc1A7NeIjKpf8EUGG34TIUJtcCT326dWRC32khXPzGKVvgqq94a 7G+ZaRaImayepVr0AKdn =ZJqZ -----END PGP SIGNATURE-----

2 3