November 2014 - Wine-Devel - list.winehq.org

Re: [2/2] wined3d: wined3d: Take abs() of vertex z coordinate as FFP fog coordinate (try 2)

by Henri Verbeet

On 29 October 2014 23:35, Joachim Priesner <joachim.priesner(a)web.de> wrote: > + /* Basic vertex shader without fog computation ("non foggy") */ > + static const DWORD vertex_shader_code1[] = > + { > + 0xfffe0100, /* vs_1_0 */ > + /* output.Pos = mul(input.Pos, Projection) */ > + 0x00000009, 0xc0010000, 0x90e40000, 0xa0e40000, /* dp4 oPos.x, v0, c0 */ > + 0x00000009, 0xc0020000, 0x90e40000, 0xa0e40001, /* dp4 oPos.y, v0, c1 */ > + 0x00000009, 0xc0040000, 0x90e40000, 0xa0e40002, /* dp4 oPos.z, v0, c2 */ > + 0x00000009, 0xc0080000, 0x90e40000, 0xa0e40003, /* dp4 oPos.w, v0, c3 */ > + /* output.Color = input.Color */ > + 0x00000001, 0xd00f0000, 0x90e40001, /* mov oD0, v1 */ > + 0x0000ffff, /* END */ > + }; ... > + static const D3DMATRIX proj_mat = > + {{{ > + 1.0f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.0f, 0.0f, 0.0f, > + 0.0f, 0.0f, 0.5f, 0.0f, > + 0.0f, 0.0f, 0.5f, 1.0f > + }}}; > + /* Transposed version of proj_mat to pass to the vertex shaders. */ > + static const D3DMATRIX proj_mat_transposed = > + {{{ > + 1.0f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.0f, 0.0f, 0.0f, > + 0.0f, 0.0f, 0.5f, 0.5f, > + 0.0f, 0.0f, 0.0f, 1.0f > + }}}; Instead of transposing the matrix, you can just change the multiplication in the shader. I.e., using "mul(Projection, input.Pos)" instead of "mul(input.Pos, Projection)". That would then give you a mul/mad/mad/mad sequence instead of 4 dp4's. But of course that's all just a complicated way to do "output.Pos = input.Pos * 0.5 + 0.5;". > + /* start=0.0f, end=1.0f should be the default values, set them anyway to be sure. > + * These values do not affect the tests with foggy vertex shader, as the fog > + * intensity is computed directly by the shader. */ > + start.f = 0.0f; > + end.f = 1.0f; > + > + hr = IDirect3DDevice8_SetRenderState(device, D3DRS_FOGSTART, start.i); > + ok(SUCCEEDED(hr), "Setting fog start failed (%#x)\n", hr); > + hr = IDirect3DDevice8_SetRenderState(device, D3DRS_FOGEND, end.i); > + ok(SUCCEEDED(hr), "Setting fog end failed (%#x)\n", hr); > + You don't need this. > + static const struct test_data_t > + { > + int vshader; > + D3DFOGMODE vfog; > + D3DFOGMODE tfog; > + DWORD color_left; > + DWORD color_middle_top; > + DWORD color_middle_bottom; > + DWORD color_right; > + } The _t suffix is reserved by POSIX, so you shouldn't use it for your own type names. In this specific case, you don't need the structure to be named at all, and you can just use an anonymous structure instead.

Nov. 3, 2014

Re: [PATCH 2/2] user32/tests: Test exception handling for timer callbacks.

by Qian Hong

On Mon, Nov 3, 2014 at 7:38 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > You should find a way to test this without all these sleeps, the user32 > tests already take a long time as it is. Thanks for feedback! I have a plan to do that, will try later. -- Regards, Qian Hong - http://www.codeweavers.com

Nov. 3, 2014

Re: [PATCH 2/2] user32/tests: Test exception handling for timer callbacks.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > +static void test_timers_exception(DWORD code) > +{ > + UINT_PTR id; > + MSG msg; > + > + exception = code; > + count = 0; > + id = SetTimer(NULL, 0, 300, callback_exception); > + ok(id != 0, "did not get id from SetTimer.\n"); > + > + Sleep(150); > + while (PeekMessageA(&msg, NULL, 0, 0, PM_REMOVE)) DispatchMessageA(&msg); > + ok(count == 0, "did not get zero count as expected (%i).\n", count); > + Sleep(200); > + while (PeekMessageA(&msg, NULL, 0, 0, PM_REMOVE)) DispatchMessageA(&msg); > + ok(count == 1, "did not get one count as expected (%i).\n", count); > + KillTimer(NULL, id); > + Sleep(350); > + while (PeekMessageA(&msg, NULL, 0, 0, PM_REMOVE)) DispatchMessageA(&msg); > + ok(count == 1, "killing timer did not work (%i).\n", count); > +} You should find a way to test this without all these sleeps, the user32 tests already take a long time as it is. -- Alexandre Julliard julliard(a)winehq.org

Nov. 3, 2014

Re: [PATCH] iphlpapi: call WSASetLastError in NotifyAddrChange/NotifyRouteChange

by Sebastian Lackner

Answering here to the mail that only was send to wine-devel. If the patch for wine-patches was updated, please ignore any feedback which isn't valid anymore. On 03.11.2014 08:27, Hao Peng wrote: > diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c > index 4d66810..84c58af 100644 > --- a/dlls/iphlpapi/iphlpapi_main.c > +++ b/dlls/iphlpapi/iphlpapi_main.c > @@ -64,6 +64,21 @@ WINE_DEFAULT_DEBUG_CHANNEL(iphlpapi); > #define INADDR_NONE ~0UL > #endif > > +typedef void (WINAPI *LPFN_WSASETLASTERROR)(int);// from winsock2.h You shouldn't use C++ style comments here. Moreover you should probably include the header file, instead of copying the definition. > +static LPFN_WSASETLASTERROR pWSASetLastError = NULL; > + > +BOOL LoadWinsock(void) Should be static, and named with lower-case letters, since this is just an internal helper function. > +{ > + HANDLE mod = NULL; > + if (pWSASetLastError != NULL) return TRUE; > + mod = LoadLibraryA("ws2_32.dll"); > + if (NULL != mod) > + { > + pWSASetLastError = (LPFN_WSASETLASTERROR)GetProcAddress(mod, "WSASetLastError"); > + } > + return (NULL != pWSASetLastError); > +} This is a bit ugly because you can't free the library anymore, and the refcount increases each time when ws2_32.dll is present but doesn't include WSASetLastError. > + > /****************************************************************** > * AddIPAddress (IPHLPAPI.@) > * > @@ -145,7 +160,7 @@ static int IpAddrTableSorter(const void *a, const void *b) > /****************************************************************** > * AllocateAndGetIpAddrTableFromStack (IPHLPAPI.@) > * > - * Get interface-to-IP address mapping table. > + * Get interface-to-IP address mapping table. You should avoid reformatting all the lines. Those are unrelated to the patch. Only change whitespace issues if they are close to other parts of the code you touch. Same also below. > * Like GetIpAddrTable(), but allocate the returned table from heap. > * > * PARAMS > @@ -251,7 +266,7 @@ DWORD WINAPI CreateIpNetEntry(PMIB_IPNETROW pArpEntry) > * Create a Proxy ARP (PARP) entry for an IP address. [...] > *pOutBufLen = size; > ret = ERROR_INSUFFICIENT_BUFFER; > @@ -1253,7 +1268,7 @@ ULONG WINAPI DECLSPEC_HOTPATCH GetAdaptersAddresses(ULONG family, ULONG flags, P > InterfaceIndexTable *table; > ULONG i, size, dns_server_size = 0, dns_suffix_size, total_size, ret = ERROR_NO_DATA; > > - TRACE("(%d, %08x, %p, %p, %p)\n", family, flags, reserved, aa, buflen); > + TRACE("(%d, %08x, %p, %p, %p, %d)\n", family, flags, reserved, aa, buflen, *buflen); That looks also a bit unrelated? > > if (!buflen) return ERROR_INVALID_PARAMETER; > > @@ -1687,7 +1702,7 @@ DWORD WINAPI GetInterfaceInfo(PIP_INTERFACE_INFO pIfTable, PULONG dwOutBufLen) > /****************************************************************** > * GetIpAddrTable (IPHLPAPI.@) > * [...] > * If bOrder is true, the returned table will be sorted, first by > @@ -2276,9 +2291,16 @@ DWORD WINAPI IpRenewAddress(PIP_ADAPTER_INDEX_MAP AdapterInfo) > */ > DWORD WINAPI NotifyAddrChange(PHANDLE Handle, LPOVERLAPPED overlapped) > { > + if (!overlapped) > + { > + FIXME("Synchronous method not supported\n"); > + return ERROR_NOT_SUPPORTED; > + } > FIXME("(Handle %p, overlapped %p): stub\n", Handle, overlapped); > if (Handle) *Handle = INVALID_HANDLE_VALUE; > - if (overlapped) ((IO_STATUS_BLOCK *) overlapped)->u.Status = STATUS_PENDING; > + ((IO_STATUS_BLOCK *) overlapped)->u.Status = STATUS_PENDING; > + if (LoadWinsock()) > + pWSASetLastError(WSA_IO_PENDING); This probably needs a test to ensure it matches the native version, if we don't have any yet. > return ERROR_IO_PENDING; > } > > @@ -2301,8 +2323,19 @@ DWORD WINAPI NotifyAddrChange(PHANDLE Handle, LPOVERLAPPED overlapped) > */ > DWORD WINAPI NotifyRouteChange(PHANDLE Handle, LPOVERLAPPED overlapped) > { > + if (!overlapped) > + { > + FIXME("Synchronous method not supported\n"); > + return ERROR_NOT_SUPPORTED; > + } > FIXME("(Handle %p, overlapped %p): stub\n", Handle, overlapped); > - return ERROR_NOT_SUPPORTED; > + if (Handle) *Handle = INVALID_HANDLE_VALUE; > + ((IO_STATUS_BLOCK *) overlapped)->u.Status = STATUS_PENDING; > + if (LoadWinsock()) > + { > + pWSASetLastError(WSA_IO_PENDING); > + } Same here. Why different coding style compared to above, although the code is the same? > + return ERROR_IO_PENDING; > } >

Nov. 3, 2014

[PATCH] iphlpapi: call WSASetLastError in NotifyAddrChange/NotifyRouteChange

by Hao Peng

call WSASetLastError in NotifyAddrChange/NotifyRouteChange to make following DEMO code working. void main() { OVERLAPPED overlap; DWORD ret; HANDLE hand = NULL; overlap.hEvent = WSACreateEvent(); ret = NotifyAddrChange(&hand, &overlap); if (ret != NO_ERROR) { if (WSAGetLastError() != WSA_IO_PENDING) { printf("NotifyAddrChange error...%d\n", WSAGetLastError()); return; } } if ( WaitForSingleObject(overlap.hEvent, INFINITE) == WAIT_OBJECT_0 ) printf("IP Address table changed..\n"); } --- dlls/iphlpapi/iphlpapi_main.c | 57 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 45 insertions(+), 12 deletions(-)

Nov. 3, 2014

Re: [4/6] msvcrt: Added _fread_nolock_s implementation

by Alexandre Julliard

"Iván Matellanes" <matellanesivan(a)gmail.com> writes: > On 31/10/14 07:46, Alexandre Julliard wrote: >> "Iván Matellanes" <matellanesivan(a)gmail.com> writes: >> >>> { >>> + MSVCRT_size_t ret; >>> + >>> + MSVCRT__lock_file(stream); >>> + ret = MSVCRT__fread_nolock_s(buf, buf_size, elem_size, count, stream); >>> + MSVCRT__unlock_file(stream); >> >> The parameter validation has to be done before locking the file. >> > > Hi, thanks for the comment. Should all parameters be validated, or just stream != NULL? > Validating the rest seems redundant to me. I suspect you don't want to call the _s function here at all, since you could then potentially call the invalid parameter handler with the file locked. A few more tests for the error cases would probably be useful. -- Alexandre Julliard julliard(a)winehq.org

Nov. 3, 2014

Re: [PATCH] Mystery hang reduction -- clear new allocations

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-30 07:09, schrieb mtewoodbury(a)gmail.com: > From: Max TenEyck Woodbury <max+git(a)mtew.isa-geek.net> > > I was getting mystery frozen processes that cleared when a total screen redraw was forced. > This has been reported numerous times over several years. It came and went with various releases. > I have been getting it consistantly recently. I had an idea that it might have something to do > with partially uninitialized drawing data structures, so I started adding HEAP_ZERO_MEMORY flags > in various places. This particular set cleared the problem, at least for now... I don't understand the description. What do you mean with forcing a total screen redraw? Which Windows applications were affected? What's the symptom of a freeze? A game being stuck for half a second? A game being stuck forever until you kill it? > - declaration->elements = HeapAlloc(GetProcessHeap(), 0, sizeof(*declaration->elements) * element_count); > + declaration->elements = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*declaration->elements) * element_count); I'd expect 1 byte padding at the end of the structure because the structure has only 19 bytes (23 in 64 bit). This may cause issues if we're doing a memcmp over a vertex declaration or one or more vertex declaration elements. I am not aware that we're doing such a thing though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUVnJFAAoJEN0/YqbEcdMwzOYP+QHBOqtPptgmlerJvRxXERcT 2PgmdiJH4T9jjqU7B1rVUypHP8IDNrZk8uKFsEAk0todD5TROznIv17LPwImrqfY 2lr6Y9zFlelxAicOYykXrqsvSDBY/VF+r/MdK+4YfIywVe0SHh52nnHGo7XdF9gj 7yqRJ3chU0UX0ANotSiyG4+d2yezrP+OI0kcKNvWH45QdB9QU/maUE6mCDoBS+g1 iYZuFC/V36PJVucsIrbztXG09jgAonrjYg2uqp4DpGnI3BFdo4pr6Pmel2DmLqw8 nw6rDyL/wGf5eBZ+/jLJFilk2nNz5C8b+Xqt0Vx+T3SG3A1AfOw56M/LxsQcrThC i34DRzNhg9ybiTcpBHlvm4QPPX84Uk0c7ryKj1r3ACQ79U+svpoyEHd37uyIert0 OlsqQGSSce+NNOnqVCaBNwJqlCGJfhD8gpS56snmbZ6UTTSHUWXokdc9K7uyp0WO mEegeE/iG78XOYerOkjmP3W64EI/xHqW5stZ3bHjg1STQkhWvNx2HxDuCMKP0192 pUzUMoGP911wOi+Q1QsS5B1sWZi3+oN4mYB+Ez7wE1eQRkTyU2oNkvrI0HmE81Dg htyV9u1DVpx4l+evqm47/LZTOWMqQGI6+HgT/4jnFRkLWVvPQqsbEU+fdVIEtPB6 6Mwj7Or/tE2W51ZQICms =XRF3 -----END PGP SIGNATURE-----

Nov. 2, 2014

Re: [PATCH] vbscript: Implemented String(try 2)

by Shuai Meng

Thanks very much for commenting, I'm trying to fix this. 2014-10-29 23:14 GMT+08:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>: > On Wed, 29 Oct 2014 17:57:15 +0800, Shuai Meng wrote: > > I have tested this for many times, but it is very strange that the > result > > of String(1, 564) varies with different platforms, running in cmd on xp, > > it equals to String(1, 564 / 256) while equals to String(1, 564 mod 256) > > running directly in vbs script(meaning save vbs code as test.vbs and > double > > click it). > > That confuses me a lot, according to MSDN documents, it should equal to > > String(1, 564 mod 256), I don't know how to handle it. > > Hello Shuai, > > Despite MSDN documents, VBScript String function accepts double-byte > character code in DBCS locale based on my tests. That means you can > specify like String(3, &HE0E0) where &HE0E0 is an ANSI codepage > character code not a Unicode codepoint. > I guess String(1, 564) is internally interpreted as "\x02\x34" in DBCS > locale. As you know, \x02 isn't a valid lead-byte character, so, you got > "\x02". On the other hand, in SBCS locale, VBScript engine did 564 mod > 256, thus, Piotr got "4". > > Regards, > Akihiro Sagawa > >

Nov. 2, 2014

Re: [1/2] ddraw: add dsurface dimension tests, try 12

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, First of all, thanks for your endurance with this. I know our pickiness can be exhausting. Am 2014-10-30 19:39, schrieb Patrick Rudolph: > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(ddraw, &ddcaps, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_GetCaps failed, hr %#x.\n", hr); You are never reading ddcaps. I suspect it is a leftover from the now-removed out of (video)memory tests. > + surfacedesc.dwFlags = tests[i].flags | DDSD_PIXELFORMAT; You are already setting DDSD_PIXELFORMAT in all of tests[i].flags, there's no need to set it twice. Remove one of them, preferably the one in tests[].flags. You can move DDSD_CAPS as well. Henri mentioned the same issue in his feedback. The rest are some minor style issues, but please fix them as well: > + DWORD i,j; I'd prefer unsigned int i, j, but that's not a strong opinion. > + todo_wine ok(hr == tests[i].hr || broken(hr == DDERR_INVALIDPARAMS), "Pixelformat %s, test %d returned %08x\n", formats[j].name, i, hr); i is unsigned, print it with %u. > + hr = IDirectDraw_CreateSurface(ddraw, &surfacedesc, &surface, NULL); > + ok(SUCCEEDED(hr), "CreateSurface returned %08x\n", hr); > + > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &surfacedesc); > + ok(SUCCEEDED(hr), "GetSurfaceDesc returned %x\n", hr); Please be consistent with the format you use. Tests added in recent years use %#x, I recommend to use this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUVkaEAAoJEN0/YqbEcdMwPVoQAJTppEl15dBZ6uVCBmOYEzbg W5GYcDfdjv9/j4S6cVyHh0wKQF7eoHBdVelF8IvE47rBGBoe63YZnOuozEN1JPNL 7buCVNBof+1WytRAZacIyu9O4Vbs2bLXgGlGqo4T0baQbQMKoH/gQnyEXcxmJR6s egElATCH1RvInllwuIPbtSr+RcmH+m8Tk9LRzHNU6gKcXNwdNv1iicQaD+wF3S2F +iG7va1Sy6ubeDHEX8CE3EMhHyFmcZZlsqk2G6AVJcj914+I8VNua69XVCujkdaH atkZQ1bS8HQ9nzfrc+X7G5CI6ZsGfO2UA8mtjl1rf8OzoCgCZ8lZmjdhgD40iQVX boFXmsFGMZAYDVxu/aUX2qD4NtBkE4TlF9JVy8UA0QMWd1DN1SyjO77lp6197VGV bAaDhjID8bUyaTc6m314eOiKMuM+2Nyt6aGwT87uyTffKCM2Eyt692tB3xWH6IqT nJpctMa724qOoAmRL5jca99uDTrn6iKkUa7m8hMXgRQEjyQvd9fm+wbNmRrxGfmA 59IwxFHF5IKTsQVbkDaLvXfU2n9ubvA0cyXRFAP1YLI9pDKq1/I3ORmToYIJ0D6O k7AqX0/7nrnu0uJEDhP3/AsTMs2Ldvh1MavNxUIWOcDK4PCc/Ga9PBc6ubX4FQGI i3iQC8eR0aQrlYAr5lvj =6YE6 -----END PGP SIGNATURE-----

Nov. 2, 2014

RE: [PATCH] cmd/tests: Add tests for 'del' (Fixes bug 35970)

by Hugh McMaster

On Sat, 1 Nov 2014 06:25:11 -0500, Marvin wrote: > > 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=9945 > > Your paranoid android. These are all existing failures and do not relate to my patch. -- Hugh McMaster

Nov. 2, 2014