- wine-devel - winehq.org

Re: [PATCH 2/6] wined3d: Add support for converted volumes.
by Henri Verbeet 20 Sep '13

20 Sep '13

On 20 September 2013 13:04, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static BOOL wined3d_volume_can_evict(const struct wined3d_volume *volume) > +{ > + if (volume->resource.pool != WINED3D_POOL_MANAGED) > + return FALSE; > + if (volume->download_count < 10) > + return FALSE; That doesn't look quite right.

1 0

Re: [PATCH 6/6] wined3d: Use GL_APPLE_client_storage for volumes if available.
by Henri Verbeet 20 Sep '13

20 Sep '13

On 20 September 2013 13:04, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - volume->flags &= ~(WINED3D_VFLAG_ALLOCATED | WINED3D_VFLAG_SRGB_ALLOCATED); > + volume->flags &= ~(WINED3D_VFLAG_ALLOCATED | WINED3D_VFLAG_SRGB_ALLOCATED > + | WINED3D_VFLAG_CLIENT_STORAGE); > Indentation looks a bit off here.

1 0

Re: (resend)[3/4] imm32: use thread data from target HWND
by Alexandre Julliard 20 Sep '13

20 Sep '13

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -507,7 +524,7 @@ HIMC WINAPI ImmAssociateContext(HWND hWnd, HIMC hIMC) > LeaveCriticalSection(&threaddata_cs); > defaultContext = ImmCreateContext(); > ((InputContextData*)defaultContext)->threadDefault = TRUE; > - thread_data = IMM_GetThreadData(0); > + thread_data = IMM_GetThreadDataForWindow(hWnd); > thread_data->defaultContext = defaultContext; > } You have multiple race conditions here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] oledb32: Correct DataLinks interface for win64
by Alexandre Julliard 20 Sep '13

20 Sep '13

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -26,6 +26,20 @@ import "oledb.idl"; > #define vi_progid(str) > #endif > > +#ifdef _WIN64 > +cpp_quote("#ifdef _WIN64") > + typedef LONGLONG COMPATIBLE_LONG; > +cpp_quote("#else") > +cpp_quote(" typedef LONG COMPATIBLE_LONG;") > +cpp_quote("#endif") > +#else > +cpp_quote("#ifdef _WIN64") > +cpp_quote(" typedef LONGLONG COMPATIBLE_LONG;") > +cpp_quote("#else") > + typedef LONG COMPATIBLE_LONG; > +cpp_quote("#endif") > +#endif You can't do that, _WIN64 is not meaningful in idl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] winemac: Implement support for global hot keys.
by Vincent Povirk 20 Sep '13

20 Sep '13

I don't think this is going to work correctly when replacing hotkeys (by passing an already-registered hwnd and id to RegisterHotKey with a different key combination). Since the user driver's RegisterHotKey function will be called with the new id/vkey/flags before UnregisterHotKey is called for the existing hotkey's id/vkey/flags, the user driver has to distinguish them based on vkey/flags. I think you can still get away with a mapping with hwnd/id as keys, as long as you check for matching vkey/flags when you unregister a hotkey. (Of course, I'm not convinced the user driver should ever post WM_HOTKEY, since the input should go through low-level keyboard hooks first, which is why I did not include the id as an argument to these entry points. If we decided to pass the id through, there would technically be no need for RegisterHotKey to call the user driver's UnregisterHotKey in this case.)

1 0

Re: [PATCH 2/3] iphlpapi: Add interface enumeration for Android.
by Bruno Jesus 19 Sep '13

19 Sep '13

On Thu, Sep 19, 2013 at 10:06 AM, Huw Davies <huw(a)codeweavers.com> wrote: > --- > configure.ac | 3 +- > dlls/iphlpapi/ifenum.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 200 insertions(+), 2 deletions(-) Hi, Huw. I'm not sure this is an issue but in the android implementation of get_interface_indexes you are not setting + if (table) *table = NULL; in the begining like in the other 2 implementations. Or I didn't understand the code correctly. Best wishes, Bruno

2 1

Re: [PATCH 3/5] mshtml: Keep moniker reference after start_binding call.
by Alexandre Julliard 18 Sep '13

18 Sep '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/navigate.c | 3 --- > 1 file changed, 3 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:3397: Test failed: mon should be destroyed here url.c:3397: Test failed: mon should be destroyed here url.c:3397: Test failed: mon should be destroyed here url.c:3397: Test failed: mon should be destroyed here url.c:3397: Test failed: mon should be destroyed here url.c:3397: Test failed: mon should be destroyed here make: *** [url.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] user32: Add a SetMinMaxInfo driver entry point.
by Alexandre Julliard 18 Sep '13

18 Sep '13

Ken Thomases <ken(a)codeweavers.com> writes: > --- > dlls/user32/driver.c | 12 ++++++++++++ > dlls/user32/user_private.h | 1 + > dlls/user32/winpos.c | 2 ++ > 3 files changed, 15 insertions(+), 0 deletions(-) It's better to avoid adding entry points that don't correspond to Windows APIs. Instead you should request the info when you need it. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [4/4] ws2_32: Do not allow socket creation if WSAStartup was not called
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2238 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/4] ws2_32: Filter invalid socket parameters and return the appropriate error
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2237 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/4] ws2_32: Auto detect the socket type and family based on the protocol (try 2)
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2236 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/4] ws2_32: Use the struct information when the parameters are zero in WSASocket (try 2)
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2235 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 8/8] d3d9/tests: Test invalid volume lock boxes.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2234 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 7/8] d3d9/tests: Add tests for block-based volume formats.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2233 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/8] wined3d: Check for support before creating volume textures.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2232 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/8] d3dx9_36/tests: Create*TextureFromFileInMemory doesn't fail.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2231 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: wsnmp32: Add stub implementations for a couple of functions.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2230 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/4] ws2_32: Do not allow socket creation if WSAStartup was not called
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2229 Your paranoid android. === build (build) === Patch failed to apply

1 0

Asynchronous read/write tests in ntdll/tests/file.c
by Thomas Faber 18 Sep '13

18 Sep '13

Hey Dmitry, I noticed a couple of tests structured like this: status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents, sizeof(contents), &offset, NULL); ok(status == STATUS_PENDING || broken(status == STATUS_SUCCESS) /* see below */, "expected STATUS_PENDING, got %#x\n", status); ok(iob.Status == STATUS_SUCCESS, "expected STATUS_SUCCESS, got %#x\n", iob.Status); ok(iob.Information == sizeof(contents), "expected sizeof(contents), got %lu\n", iob.Information); ... ret = WaitForSingleObject(hfile, 3000); Technically, the IO_STATUS_BLOCK (hence also the OVERLAPPED) structure is only filled once the I/O Manager completes the read/write IRP -- meaning its contents should only be read _after_ the wait. So this aspect essentially tests the question of "are ntfs.sys and the cache manager faster to fill the IOSB than the test can read it". That test can be completely valid, especially if it's known that applications do this, however I'm not sure whether that's actually the intention here. (My preference would obviously -- hence this mail -- be to read the result after waiting unless there's a specific reason to do it otherwise. The specifics are kind of up to the FS driver.) Thanks! -Thomas

2 2

Re: [3/4] ws2_32: Filter invalid socket parameters and return the appropriate error
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2228 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/4] ws2_32: Auto detect the socket type and family based on the protocol
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2227 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/4] ws2_32: Use the struct information when the parameters are zero in WSASocket
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2226 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: msvcrt/tests: Load the correct function on ARM
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2222 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: kernel32/tests: Add initial CreateFile2 tests based on the CreateFileW tests (try 3)
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2221 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: msvcrt: Fix Inf and NaN handling in printf function
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2217 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/2] shlwapi: Write file access also assumes read access.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2215 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/2] shlwapi/tests: Add a read/write test for IStream on files.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2214 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [5/5] ws2_32: Fix the error returned for denied SOCK_RAW attempts
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2212 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/5] ws2_32: Fix WSASocket return code for invalid combination of socket type and protocol
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2211 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/5] ws2_32: Advertise protocol entries as default
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2210 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/8] wined3d: Introduce a format flag for volume texture support.
by Henri Verbeet 18 Sep '13

18 Sep '13

On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 4928f92..eabf890 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2927,6 +2927,7 @@ extern enum wined3d_format_id pixelformat_for_depth(DWORD depth) DECLSPEC_HIDDEN > #define WINED3DFMT_FLAG_HEIGHT_SCALE 0x00040000 > #define WINED3DFMT_FLAG_TEXTURE 0x00080000 > #define WINED3DFMT_FLAG_BLOCKS_NO_VERIFY 0x00100000 > +#define WINED3DFMT_FLAG_VOLUME 0x00200000 > I don't like this approach much. I think we should either do the right thing right away and have separate flags for each GL resource type (i.e., vertex/index buffers, renderbuffers, 1D/2D/3D/CUBE/RECT textures), or just keep assuming they're the always the same and handle the exceptions for volumes like a quirk flag like WINED3DFMT_FLAG_BROKEN_PITCH. In either case this should probably have corresponding support for ARB_internalformat_query2 as well, and I'd prefer "TEXTURE3D" over "VOLUME".

2 4

Re: patch:add ualapi directory
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2209 Your paranoid android. === build (build) === Unable to regenerate dlls/ualapi/Makefile Recreation of tests/Makefile failed

1 0

Re: [8/9] gdi32: Return GDI_ERROR when requested empty glyph bitmaps.
by Marvin 18 Sep '13

18 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2207 Your paranoid android. === wvista (32 bit font) === The test timed out

1 0

Re: [1/4] ntdll/tests: Add 0-length read tests for a disk file.
by Nikolay Sivov 18 Sep '13

18 Sep '13

On 09/18/2013 10:53 AM, Dmitry Timoshkov wrote: > --- > dlls/ntdll/tests/file.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index 120fdac..5ae605b 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -1985,6 +1985,22 @@ static void test_read_write(void) > > bytes = 0xdeadbeef; > SetLastError(0xdeadbeef); > + ret = ReadFile(INVALID_HANDLE_VALUE, buf, 0,&bytes, NULL); > +todo_wine > + ok(!ret, "ReadFile should fail\n"); > +todo_wine > + ok(GetLastError() == ERROR_INVALID_HANDLE, "expected ERROR_INVALID_HANDLE, got %d\n", GetLastError()); > + ok(bytes == 0, "bytes %u\n", bytes); > That's again a test for kernel32 calls, placed in a wrong file.

2 1

Re: oledb32: Implement IErrorRecord GetBasicErrorInfo
by Nikolay Sivov 18 Sep '13

18 Sep '13

On 09/18/2013 09:47 AM, Alistair Leslie-Hughes wrote: > + LIST_FOR_EACH_ENTRY(cursor,&This->errors, struct ErrorEntry, entry) > + { > + if(nCnt == ulRecordNum) > + { > + *pErrorInfo = cursor->info; > + break; > + } > + } > + This looks wrong, cause you never update nCnt. Also it doesn't look appropriate to use list to store these records - methods provide index-based access, so array fits better. > entry->lookupID = dwDynamicErrorID; Any idea how this field could be used later? I don't where it could be returned. And 'dwLookupID' parameter of 'AddErrorRecord' is never used, that looks suspicious.

1 0

Re: [PATCH] oleaut32: Implement VarDecRound
by Bruno Jesus 17 Sep '13

17 Sep '13

On Tue, Sep 17, 2013 at 3:01 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > This fixes a crash in PowerPoint when a shape is made > semi-transparent. May also fix bug http://bugs.winehq.org/show_bug.cgi?id=34463 and http://bugs.winehq.org/show_bug.cgi?id=30485

1 0

Re: [5/9] gdiplus: Fix empty glyph handling.
by Vincent Povirk 17 Sep '13

17 Sep '13

This seems suspicious to me. Why can't we use those values in glyphmetrics if GetGlyphOutlineW returns 0? Does Windows provide bad values in this case, or is our GetGlyphOutlineW broken? When does the call to GetGlyphOutlineW in the second loop fail, and why ignore those failures?

2 5

Re: [PATCH 5/8] wined3d: Implement locking of block-based volume textures.
by Henri Verbeet 17 Sep '13

17 Sep '13

On 17 September 2013 11:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/wined3d/volume.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 88 insertions(+), 7 deletions(-) > Can't most of this be done on the resource level instead?

2 3

Re: [1/4] ws2_32: Use the struct information when the parameters are zero in WSASocket
by Alexandre Julliard 17 Sep '13

17 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -5884,20 +5884,20 @@ SOCKET WINAPI WSASocketW(int af, int type, int protocol, > return ret; > } > > - /* convert the socket family and type */ > - af = convert_af_w2u(af); > - type = convert_socktype_w2u(type); > - > if (lpProtocolInfo) > { > - if (af == FROM_PROTOCOL_INFO) > + if (af <= 0) > af = lpProtocolInfo->iAddressFamily; > - if (type == FROM_PROTOCOL_INFO) > + if (type <= 0) > type = lpProtocolInfo->iSocketType; > - if (protocol == FROM_PROTOCOL_INFO) > + if (protocol <= 0) > protocol = lpProtocolInfo->iProtocol; I don't see anything in the tests that would justify checking for negative values here. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/5] ddraw: Don't set render target / depth stencil usage on sysmem surfaces.
by Stefan Dösinger 17 Sep '13

17 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-17 09:22, schrieb Henri Verbeet: > Setting render target usage on a P8 surface for example would fail > surface creation, while such surfaces can't be used for actual > rendering anyway. Tests confirm that surface creation is supposed > to succeed for P8 surfaces with both DDSCAPS_SYSTEMMEMORY and > DDSCAPS_3DDEVICE set. What happens when a DDSCAPS_SYSTEMMEMORY surface (P8 or otherwise) is passed to CreateDevice or SetRenderTarget? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOCViAAoJEN0/YqbEcdMwj6wP/AhSGoeqw0JU261iEled6W4C vIk1NEn7VB2MSDKE1i32fHiE9SnPW/kC/AimNl8PU51OzHym1gs+CIh4ZfvUvOnZ 0GNSO/HLf0aKssbxSx8z+OW0PaHXFST/6OsanKHwhq3CFJy4JPBVasFTSBnjDjv+ yQXp1ZRQOT3mI6Dy9EHVZkwdMQzC+NbFYfv3xd3a1h884ys359E97rcg/1pC/qrA oay/Oq3aAZVdWBbMjx4KbLcEDbwzVc9naQ4riKFGUY97AF+d4d8t1/kdYnSKwdtn PlpFA8SyS4/HpHVPN8+4/SoMKJetMMz9nzDPOiVjW+yWMHqLvtR08sPawDQza06g sIis0QZ0lC78eK0ibcIqvdv7u43vVtE2MJgQWnujv2L2S3pXDFr8AnK4tjPjaoUr BtuEdAyBBvo30i05f+u3+lNI4d2jsLBhFBXrWVUBqz/cb26epfz98H3Jrs09JEZ4 zypVmPE5MA5dEAgd5D5DD6AO4pymP7gpX5lrX7ynkz+kfe6xO7RtcuYKyfuwQnAu rikTZDZgv7+Dxnx1hlvP1P1o2nmFT2LhETTCev7JmzNhoS1/L0pjmNbP+JkeMYn5 mwrrCMEpK7kWL7OmRlkoWfu6q98+iR1O67+ptqf6yCRX1L4C+zYG0WKLivIX/XbF Aj4w0H043EWv3VYLPAVB =lgos -----END PGP SIGNATURE-----

2 2

Re: [PATCH 7/8] d3d9/tests: Add tests for block-based volume formats.
by Stefan Dösinger 17 Sep '13

17 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-17 11:39, schrieb Stefan Dösinger: > --- dlls/d3d9/tests/device.c | 340 > +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 340 > insertions(+) Fyi, I have equivalent tests for d3d8, the behavior is the same. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOCazAAoJEN0/YqbEcdMwCyEP/R8yohA3eKvpUv5rf8Laui6k aety5Hn56PlrVvJhEaVc6x+7C6f5fzrmtKVHQ9BgojYW7iQvz3yzuRlm8EXSGlyQ 9GXMYPlSUEqSk9Y8COZPhxqzATSuy7HKBFpCQ4vdd1qt3SNbG82QG8aWW6aLiPA0 A1MVN9ki5h4NHXNItXLbuS/Gw0w3QN6WIbwkGw9Oa19Mi9uqAlV9oQpUnH9ToELJ X7lCE1/tlXBsDKcxbx4ugfASZS6V6pTJrauHkPa0Fk5jcmF4K6mxVzT0PfUXMnsG BVtx6TBOdgtwpIoygsM8mCbGxOiaN+SlHH36fnieGXLQ2sXc4jDs8Hj6vBTcfgRu Cc5SLOIJ1Wot4Mr2Yz1+crTkHE/xp7n7TPNyPDflIqHaZ50xKSH+leRBkyqPQnud 6V63vFHYd1I2rnVTYrvsUOQZKii9QlFoknc8wBkTTM8ChV2ohmfdtl5+SVR05/Sg aanNkmZYCNmpzj5qUmcNojNH2T8DJe2KXQlwjgt0bYfXu8lEoDAYdjo07kYxNnLf /byXb4ZfjKAB8DHdB9x9MvYa/9wq9Zs+kDZE1WGt63nQVNsvmAFCLkv4il+2G2Mp rOCL9qxDMZizZaSQqfw75UO8Y7A/OxBV3gU1HLLY5gUIKyhhqcWrLIU8Mbqdbwrs 13WFu9UmCZ3NzlD2aZ5g =vJTW -----END PGP SIGNATURE-----

1 0

Re: [1/9] Fix expected values in various messages.
by Marvin 17 Sep '13

17 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2198 Your paranoid android. === wvista (32 bit winhttp) === winhttp.c:1900: Test failed: failed to receive response 12152 winhttp.c:1904: Test failed: failed to query status code 12019 winhttp.c:1905: Test failed: request failed unexpectedly 0 winhttp.c:1920: Test failed: failed to read data 12019 winhttp.c:1921: Test failed: count was wrong winhttp.c:1922: Test failed: http data wrong === w7pro64 (32 bit winhttp) === winhttp.c:860: Test failed: failed to send request 12175

1 0

server/protocol.def and array types
by Hugh McMaster 17 Sep '13

17 Sep '13

I'm testing support for GetConsoleScreenBufferInfoEx. At the moment, I've extended the screen_buffer struct in server/console.c to look like this: struct screen_buffer { struct object obj; /* object header */ struct list entry; /* entry in list of all screen buffers */ struct console_input *input; /* associated console input */ int mode; /* output mode */ int cursor_size; /* size of cursor (percentage filled) */ int cursor_visible;/* cursor visibility flag */ int cursor_x; /* position of cursor */ int cursor_y; /* position of cursor */ int width; /* size (w-h) of the screen buffer */ int height; int max_width; /* size (w-h) of the window given font size */ int max_height; char_info_t *data; /* the data for each cell - a width x height matrix */ unsigned short attr; /* default attribute for screen buffer */ rectangle_t win; /* current visible window on the screen buffer * * as seen in wineconsole */ struct fd *fd; /* for bare console, attached output fd */ unsigned short popup_attr; /* the console popup fill attribute */ BOOL fullscreen; /* indicates whether fullscreen mode is supported */ COLORREF colortable[16];/* an array of DWORD values */ }; In server/protocol.def I have: @REQ(get_console_output_info) obj_handle_t handle; /* handle to the console */ @REPLY short int cursor_size; /* size of cursor (percentage filled) */ short int cursor_visible;/* cursor visibility flag */ short int cursor_x; /* position of cursor (x, y) */ short int cursor_y; short int width; /* width of the screen buffer */ short int height; /* height of the screen buffer */ short int attr; /* default attribute */ short int win_left; /* window actually displayed by renderer */ short int win_top; /* the rect area is expressed within the */ short int win_right; /* boundaries of the screen buffer */ short int win_bottom; short int max_width; /* maximum size (width x height) for the window */ short int max_height; short int popup_attr; /* the console popup fill attribute */ short int fullscreen; /* indicates whether fullscreen mode is supported */ --> type??? colortable; /* a COLORREF array of DWORD values */ @END While colortable is a COLORREF array, protocol.def does not allow types such as DWORD, COLORREF, etc. What type should colortable be given to pass tools/make_requests?

1 0

Bad CPU autoscaling is making games unplayable for a lot of users
by Scott Ritchie 17 Sep '13

17 Sep '13

Over the past couple years I've been able to try out Wine games on many different environments -- laptops, desktops, even cloud servers. On many occasions, I've discovered that a game appears to run functionally but slowly, however upon further investigation I find that forcing the CPU to run at 100% "performance" mode can make the game playable. There are a few tools to do this (eg cpufreq-indicator for desktop users), however the long and short of it is that, for many users, I suspect they just assume Wine is slow and give up on that particular game. 1) Since Wine is truly CPU-bound here, why isn't it provoking the autoscaling to actually speed up the processor? I've seen this happen on systems running with AC power and 100% battery life. 2) Is this a kernel issue? A distribution power management configuration issue? Or is there something we can do in Wine itself to be less courteous? Mostly I've seen this on Ubuntu, however I'm sure it's affecting other distributions that have any sort of power managment whatsoever as it can be quite tricky to get this right. Thanks, Scott Ritchie

4 3

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack() (try 7)
by Ralf Habacker 17 Sep '13

17 Sep '13

Am 10.09.2013 11:44, schrieb Ralf Habacker: > > - remove misleading comment Just for the record: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365804%28v=vs.85%… do not mention any error code, which could be tested If the function succeeds, it returns ERROR_SUCCESS. If the function fails, it returns a function [should probably be 'error'] from winerror.h. > > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > dlls/iphlpapi/iphlpapi.spec | 1 + > dlls/iphlpapi/ipstats.c | 33 +++++++++++++++++++++++++++++++++ > dlls/iphlpapi/tests/iphlpapi.c | 29 +++++++++++++++++++++++++++++ > 3 Dateien geändert, 63 Zeilen hinzugefügt(+) > > > > >

1 0

Re: windowscodecs: Implement CreateBitmapFromHBITMAP.
by Vincent Povirk 17 Sep '13

17 Sep '13

Maybe the format for 32-bit bitmaps should be determined by the alpha channel options? On Monday, September 16, 2013, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Based on a gdiplus implementation. > --- > dlls/windowscodecs/imgfactory.c | 149 +++++++++++++++++++++++++++++++++++++- > dlls/windowscodecs/tests/bitmap.c | 14 ++-- > 2 files changed, 154 insertions(+), 9 deletions(-) > > diff --git a/dlls/windowscodecs/imgfactory.c b/dlls/windowscodecs/imgfactory.c > index e5f2125..bb4cf67 100644 > --- a/dlls/windowscodecs/imgfactory.c > +++ b/dlls/windowscodecs/imgfactory.c > @@ -603,12 +603,153 @@ static HRESULT WINAPI ComponentFactory_CreateBitmapFromMemory(IWICComponentFacto > return BitmapImpl_Create(width, height, stride, size, buffer, format, WICBitmapCacheOnLoad, bitmap); > } > > +static BOOL get_16bpp_format(HBITMAP hbm, WICPixelFormatGUID *format) > +{ > + BOOL ret = TRUE; > + BITMAPV4HEADER bmh; > + HDC hdc; > + > + hdc = CreateCompatibleDC(0); > + > + memset(&bmh, 0, sizeof(bmh)); > + bmh.bV4Size = sizeof(bmh); > + bmh.bV4Width = 1; > + bmh.bV4Height = 1; > + bmh.bV4V4Compression = BI_BITFIELDS; > + bmh.bV4BitCount = 16; > + > + GetDIBits(hdc, hbm, 0, 0, NULL, (BITMAPINFO *)&ji, DIB_RGB_COLORS); > + > + if (bmh.bV4RedMask == 0x7c00 && > + bmh.bV4GreenMask == 0x3e0 && > + bmh.bV4BlueMask == 0x1f) > + { > + *format = GUID_WICPixelFormat16bppBGR555; > + } > + else if (bmh.bV4RedMask == 0xf800 && > + bmh.bV4GreenMask == 0x7e0 && > + bmh.bV4BlueMask == 0x1f) > + { > + *format = GUID_WICPixelFormat16bppBGR565; > + } > + else > + { > + FIXME("unrecognized bitfields %x,%x,%x\n", bmh.bV4RedMask, > + bmh.bV4GreenMask, bmh.bV4BlueMask); > + ret = FALSE; > + } > + > + DeleteDC(hdc); > + return ret; > +} > + > static HRESULT WINAPI ComponentFactory_CreateBitmapFromHBITMAP(IWICComponentFactory *iface, > - HBITMAP hBitmap, HPALETTE hPalette, WICBitmapAlphaChannelOption options, > - IWICBitmap **ppIBitmap) > + HBITMAP hbm, HPALETTE hpal, WICBitmapAlphaChannelOption option, IWICBitmap **bitmap) > { > - FIXME("(%p,%p,%p,%u,%p): stub\n", iface, hBitmap, hPalette, options, ppIBitmap); > - return E_NOTIMPL; > + BITMAP bm; > + HRESULT hr; > + WICPixelFormatGUID format; > + IWICBitmapLock *lock; > + UINT size, num_palette_entries = 0; > + PALETTEENTRY entry[256]; > + > + TRACE("(%p,%p,%p,%u,%p)\n", iface, hbm, hpal, option, bitmap); > + > + if (!bitmap) return E_INVALIDARG; > + > + if (GetObjectW(hbm, sizeof(bm), &bm) != sizeof(bm)) > + return WINCODEC_ERR_WIN32ERROR; > + > + if (hpal) > + { > + num_palette_entries = GetPaletteEntries(hpal, 0, 256, entry); > + if (!num_palette_entries) > + return WINCODEC_ERR_WIN32ERROR; > + } > + > + /* TODO: Figure out the correct format for 16, 32, 64 bpp */ > + switch(bm.bmBitsPixel) > + { > + case 1: > + format = GUID_WICPixelFormat1bppIndexed; > + break; > + case 4: > + format = GUID_WICPixelFormat4bppIndexed; > + break; > + case 8: > + format = GUID_WICPixelFormat8bppIndexed; > + break; > + case 16: > + if (!get_16bpp_format(hbm, &format)) > + return E_INVALIDARG; > + break; > + case 24: > + format = GUID_WICPixelFormat24bppBGR; > + break; > + case 32: > + format = GUID_WICPixelFormat32bppBGR; > + break; > + case 48: > + format = GUID_WICPixelFormat48bppRGB; > + break; > + default: > + FIXME("unsupported %d bpp\n", bm.bmBitsPixel); > + return E_INVALIDARG; > + } > + > + hr = BitmapImpl_Create(bm.bmWidth, bm.bmHeight, bm.bmWidthBytes, 0, NULL, &format, option, bitmap); > + if (hr != S_OK) return hr; > + > + hr = IWICBitmap_Lock(*bitmap, NULL, WICBitmapLockWrite, &lock); > + if (hr == S_OK) > + { > + BYTE *buffer; > + HDC hdc; > + char bmibuf[FIELD_OFFSET(BITMAPINFO, bmiColors[256])]; > + BITMAPINFO *bmi = (BITMAPINFO *)bmibuf; > + > + IWICBitmapLock_GetDataPointer(lock, &size, &buffer); > + > + hdc = CreateCompatibleDC(0); > + > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biBitCount = 0; > + GetDIBits(hdc, hbm, 0, 0, NULL, bmi, DIB_RGB_COLORS); > + bmi->bmiHeader.biHeight = -bm.bmHeight; > + GetDIBits(hdc, hbm, 0, bm.bmHeight, buffer, bmi, DIB_RGB_COLORS); > + > + DeleteDC(hdc); > + IWICBitmapLock_Release(lock); > + > + if (num_palette_entries) > + { > + IWICPalette *palette; > + WICColor colors[256]; > + UINT i; > + > + hr = PaletteImpl_Create(&palette); > + if (hr == S_OK) > + { > + for (i = 0; i < num_palette_entries; i++) > + colors[i] = 0xff000000 | entry[i].peRed << 16 | > + entry[i].peGreen << 8 | entry[i].peBlue; > + > + hr = IWICPalette_InitializeCustom(palette, colors, num_palette_entries); > + if (hr == S_OK) > + hr = IWICBitmap_SetPalette(*bitmap, palette); > + > + IWICPalette_Release(palette); > + } > + } > + } > + > + if (hr != S_OK) > + { > + IWICBitmap_Release(*bitmap); > + *bitmap = NULL; > + } > + > + return hr; > } > > static HRESULT WINAPI ComponentFactory_CreateBitmapFromHICON(IWICComponentFactory *iface, > diff --git a/dlls/windowscodecs/tests/bitmap.c b/dlls/windowscodecs/tests/bitmap.c > index 8795048..3c79ce8 100644 > --- a/dlls/windowscodecs/tests/bitmap.c > +++ b/dlls/windowscodecs/tests/bitmap.c > @@ -727,17 +727,13 @@ static void test_CreateBitmapFromHBITMAP(void) > ok(hbmp != 0, "failed to create bitmap\n"); > > hr = IWICImagingFactory_CreateBitmapFromHBITMAP(factory, 0, 0, WICBitmapIgnoreAlpha, &bitmap); > -todo_wine > ok(hr == WINCODEC_ERR_WIN32ERROR || hr == 0x88980003 /*XP*/, "expected WINCODEC_ERR_WIN32ERROR, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromHBITMAP(factory, hbmp, 0, WICBitmapIgnoreAlpha, NULL); > -todo_wine > ok(hr == E_INVALIDARG, "expected E_INVALIDARG, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromHBITMAP(factory, hbmp, 0, WICBitmapIgnoreAlpha, &bitmap); > -todo_wine > ok(hr == S_OK, "CreateBitmapFromHBITMAP error %#x\n", hr); > - if (hr != S_OK) return; > > IWICBitmap_GetPixelFormat(bitmap, &format); > ok(IsEqualGUID(&format, &GUID_WICPixelFormat8bppIndexed), > @@ -770,6 +766,7 @@ todo_wine > ok(hr == S_OK, "CreateBitmapFromHBITMAP error %#x\n", hr); > > IWICBitmap_GetPixelFormat(bitmap, &format); > +todo_wine > ok(IsEqualGUID(&format, &GUID_WICPixelFormat4bppIndexed), > "unexpected pixel format %s\n", debugstr_guid(&format)); > > @@ -789,6 +786,7 @@ todo_wine > > hr = IWICPalette_GetColorCount(palette, &count); > ok(hr == S_OK, "GetColorCount error %#x\n", hr); > +todo_wine > ok(count == 16, "expected 16, got %u\n", count); > > IWICPalette_Release(palette); > @@ -837,7 +835,13 @@ todo_wine > hr = IWICBitmap_CopyPixels(bitmap, NULL, 4, sizeof(data), data); > ok(hr == S_OK, "IWICBitmap_CopyPixels error %#x\n", hr); > for (i = 0; i < sizeof(data); i++) > - ok(data[i] == data_8bpp_pal_wic[i], "%u: expected %#x, got %#x\n", i, data_8bpp_pal_wic[i], data[i]); > + { > + if (data[i] != data_8bpp_pal_wic[i]) > +todo_wine > + ok(data[i] == data_8bpp_pal_wic[i], "%u: expected %#x, got %#x\n", i, data_8bpp_pal_wic[i], data[i]); > + else > + ok(data[i] == data_8bpp_pal_wic[i], "%u: expected %#x, got %#x\n", i, data_8bpp_pal_wic[i], data[i]); > + } > > IWICBitmap_Release(bitmap); > DeleteObject(hbmp); > -- > 1.8.3.4 > > > >

2 2

Re: [1/9] Fix expected values in various messages.
by Marvin 16 Sep '13

16 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2196 Your paranoid android. === wxppro (32 bit htmldoc) === htmldoc.c:2861: Test failed: mon(002793C8) != exmon(00260D10) htmldoc.c:7326: Test failed: mon(002793C8) != exmon(00260D10) htmldoc.c:5715: Test failed: mon(002793C8) != exmon(00260D10) htmldoc.c:2861: Test failed: mon(0028B080) != exmon(002A2008) htmldoc.c:7326: Test failed: mon(0028B080) != exmon(002A2008) htmldoc.c:5715: Test failed: mon(0028B080) != exmon(002A2008)

1 0

Re: [1/9] Fix expected values in various messages.
by Marvin 16 Sep '13

16 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2195 Your paranoid android. === wxppro (32 bit mci) === mci.c:1209: Test failed: mci status "C:\Documents and Settings\winetest\My Documents\tempfile.wav" mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1274: Test failed: mci re-auto-open status mode returned MCIERR_INVALID_DEVICE_NAME mci.c:1290: Test failed: mci auto-open pause returned MCIERR_INVALID_DEVICE_NAME

1 0

Re: kernel32/tests: Add initial CreateFile2 tests based on the CreateFileW tests (try 2)
by Alexandre Julliard 16 Sep '13

16 Sep '13

André Hentschel <nerv(a)dawncrow.de> writes: > --- > dlls/kernel32/tests/file.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 84 insertions(+) It doesn't work here: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so file.c && touch file.ok file.c:810: Tests skipped: CopyFile2 is not available file.c:1173: Tests skipped: Either no authority to volume, or is todo_wine for C:\users\julliard\Temp\ err=5 should be 3 file.c:1173: Tests skipped: Either no authority to volume, or is todo_wine for C:\users\julliard\Temp\removeme\ err=5 should be 3 file.c:1173: Tests skipped: Either no authority to volume, or is todo_wine for C:\ err=5 should be 3 file.c:1173: Tests skipped: Either no authority to volume, or is todo_wine for \\?\C:\ err=5 should be 3 file.c:1567: Test failed: expected CreateFile2 to fail on existing directory, error: 183 make: *** [file.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/9] Fix expected values in various messages.
by Marvin 16 Sep '13

16 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2187 Your paranoid android. === wxppro (32 bit file) === file.c:1417: Test failed: bad position 0 expecting 8 file.c:1419: Test failed: Couldn't read back the data file.c:1987: Test failed: i 0, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:1987: Test failed: i 1, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:1987: Test failed: i 2, got 0 file.c:1990: Test failed: expected to read 'Hello world', got '' file.c:2024: Test failed: fread() returned 0: ferror=0 file.c:2027: Test failed: got '' expected 'Hello worldHello worldHello world'

1 0

Re: [1/9] Fix expected values in various messages.
by Marvin 16 Sep '13

16 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2185 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag

1 0

Re: [2/2] kernel32: implement callback and cancellation in CopyFileEx
by Nikolay Sivov 15 Sep '13

15 Sep '13

On 09/14/2013 03:25 AM, Daniel Jeliński wrote: > > Could you implement necessary part of CopyFile2 instead, and use it in CopyFileEx? I think CopyFile2 has everything to do that.

2 3

Re: [1/9] Fix expected values in various messages.
by Nikolay Sivov 15 Sep '13

15 Sep '13

On 09/15/2013 04:25 PM, Akihiro Sagawa wrote: > hr = IUnknown_QueryInterface(reader_input,&IID_IStream, (void**)&stream2); > - ok(hr == E_NOINTERFACE, "Expected S_OK, got %08x\n", hr); > + ok(hr == E_NOINTERFACE, "Expected E_NOINTERFACE, got %08x\n", hr); > As Henri said, it's not that useful to see expected value, this one is a copy-paste typo of course and should be fixed. Printing actual value is enough, so something like "got 0x%08x\n" is ok.

1 0

Re: patch:add ualapi directory
by Henri Verbeet 15 Sep '13

15 Sep '13

On 15 September 2013 17:50, matyapiro31 <matyapiro31(a)gmail.com> wrote: > + * wine 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. > + * > + * wine 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 wine. If not, see <http://www.gnu.org/licenses/>. > + */ That's not the standard copyright header. I'm not going to argue about whether it's still valid when you modify it like that, but at the very least we'd like the copyright headers to be consistent across Wine. > +static void test_ual( PUAL_DATA_BLOB Data ) > +{ > + > +} > + > +func_ualapi_test (ualapi) > +{ > + PUAL_DATA_BLOB ualdata; > + test_ual(ualdata); > + ok(0,"テストに失敗しました。\n");//第一引数:条件、第二引数:メッセージ > +} This looks very incomplete, did you intend to submit this?

1 0

Re: [1/9] Fix expected values in various messages.
by Henri Verbeet 15 Sep '13

15 Sep '13

On 15 September 2013 14:25, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c > index 83cdaf9..9f9e12a 100644 > --- a/dlls/d3d8/tests/device.c > +++ b/dlls/d3d8/tests/device.c > @@ -1308,7 +1308,7 @@ static void test_reset(void) > D3DFMT_R5G6B5, D3DPOOL_DEFAULT, &volume_texture); > ok(SUCCEEDED(hr), "CreateVolumeTexture failed, hr %#x.\n", hr); > hr = IDirect3DDevice8_Reset(device1, &d3dpp); > - ok(hr == D3DERR_DEVICELOST, "Reset returned %#x, expected %#x.\n", hr, D3DERR_INVALIDCALL); > + ok(hr == D3DERR_DEVICELOST, "Reset returned %#x, expected %#x.\n", hr, D3DERR_DEVICELOST); I think Alexandre has an opinion on when this kind of patch is appropriate and when it isn't. Regardless, purely for the parts that touch Direct3D, I'd say that if you're changing these messages anyway, you may as well change them to something along the lines of "Got unexpected hr %#x.\n", since the expected value isn't that useful anyway.

1 0

Re: kernel32/tests: Add initial CreateFile2 tests based on the CreateFileW tests (try 2)
by Nikolay Sivov 13 Sep '13

13 Sep '13

On 9/13/2013 22:26, André Hentschel wrote: Sorry, ignore my comment. I missed that we actually have this call already in wine.

1 0

Re: kernel32/tests: Add initial CreateFile2 tests based on the CreateFileW tests (try 2)
by Nikolay Sivov 13 Sep '13

13 Sep '13

On 9/13/2013 22:26, André Hentschel wrote: > + if (!pCreateFile2) > + { > + win_skip("CreateFile2 is missing\n"); > + return; > + } Should be skip() so it'll show up when running with wine. Not sure how important it is though.

1 0

Re: [PATCH 1/3] iphlpapi/tests: Increase buffer size to prevent overflow.
by Marvin 13 Sep '13

13 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2158 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/3] riched20/tests: Add UTF8 BOM tests for EM_SETTEXTEX. (try 5)
by Marvin 13 Sep '13

13 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2155 Your paranoid android. === w7pro64 (64 bit editor) === editor.c:5757: Test failed: wrong event mask (0x0) during WM_COMMAND

1 0

Re: [PATCH 3/3] riched20: Add UTF8 support for EM_SETTEXTEX. (try 6)
by Nikolay Sivov 13 Sep '13

13 Sep '13

On 9/13/2013 15:05, Jactry Zeng wrote: > bUnicode = !bRtf && pStruct->codepage == CP_UNICODE; > + bUTF8 = (lParam && (!strncmp((char *)lParam, utf8_bom, 3))); What will happen if both of these are true? This needs a test with BOM and 'codepage' set to 1200.

2 1

Re: [PATCH 3/3] riched20: Add UTF8 support for EM_SETTEXTEX. (try 5)
by Alexandre Julliard 13 Sep '13

13 Sep '13

Jactry Zeng <jactry92(a)gmail.com> writes: > @@ -3313,6 +3315,10 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > len = lParam ? strlen((char *)lParam) : 0; > } > } else { > + if(bUTF8) { > + lParam = lParam + 3; > + pStruct->codepage = CP_UTF8; > + } That struct belongs to the caller, you can't change it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: fonts: Add some box-type glyphs to wingdings.
by Huw Davies 13 Sep '13

13 Sep '13

On Fri, Sep 13, 2013 at 11:07:19AM +0100, Huw Davies wrote: > --- > fonts/wingding.sfd | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++ Please ignore this one and use 'try 2'. I had the points of one glyph selected in the outline editor which apparently gets saved to the .sfd . Huw.

1 0

Re: ntdll: Add a file access test.
by Nikolay Sivov 13 Sep '13

13 Sep '13

On 9/13/2013 11:20, Dmitry Timoshkov wrote: > This test passes under Wine and shows that ReadFile after CreateFile(GENERIC_WRITE) > is really supposed to fail. > --- > dlls/ntdll/tests/file.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 82 insertions(+) > It looks like it belongs to kernel32/tests.

3 4

Re: ntdll/tests: Fix compilation on systems that don't support nameless unions. (rediffed)
by Dmitry Timoshkov 13 Sep '13

13 Sep '13

Francois Gouget <fgouget(a)free.fr> wrote: > That tree was a bit out of date causing the patch to fail to apply. I > updated it and rediffed. I'd appreciate if you could postpone sending this sort of patches when they could conflict with other pending patches in that area. Thanks. -- Dmitry.

1 0

Re: [1/2] ntdll: Properly handle 0-length reads. Resend.
by Alexandre Julliard 13 Sep '13

13 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This matches what NtWriteFile does. > > I assume that this patch is in 'pending' state because of a test failure caused > by 2/2, if the reason is different - please let me know. It would need some test cases for other file types. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll/tests: Fix compilation on systems that don't support nameless unions.
by Marvin 13 Sep '13

13 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2144 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [try3] gdi32: abc values remain the same despite any changes in layout direction or Viewport
by Alexandre Julliard 12 Sep '13

12 Sep '13

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1262,6 +1290,70 @@ static void test_GetCharABCWidths(void) > } > > ReleaseDC(NULL, hdc); > + > + memset(&lf, 0, sizeof(lf)); > + strcpy(lf.lfFaceName, "Tahoma"); > + lf.lfHeight = 20; > + > +#define helper_ABC(a) (winetest_set_location(__FILE__,__LINE__), 0) ? 0 : helper_ABCWidths(hdc, glyphs, abc, abcw, abcf, a) Please avoid that sort of macro. You can pass a description string, or simply print the current extents in the helper function, so that we can figure out the failing code without relying on line numbers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d9/tests: D3DCMP_GREATER is broken on r500 (try 2).
by Marvin 12 Sep '13

12 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2136 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/6] user32: Export WINPOS_GetMinMaxInfo() as __wine_get_min_max_info() so it can be called by drivers.
by Dmitry Timoshkov 12 Sep '13

12 Sep '13

Ken Thomases <ken(a)codeweavers.com> wrote: > +@ cdecl __wine_get_min_max_info(long ptr ptr ptr ptr) WINPOS_GetMinMaxInfo What's wrong with calling SendMessage(WM_GETMINMAXINFO) from the driver? -- Dmitry.

2 3

Re: [PATCH 5/5] d3d9/tests: D3DCMP_GREATER is broken on r500.
by Henri Verbeet 12 Sep '13

12 Sep '13

On 12 September 2013 12:23, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * On the r500 driver on Windows D3DCMP_GREATER and D3DCMP_GREATEREQUAL are broken for depth > + * values > 0.5. The range appears to be distored, apparently an incoming value of ~0.875 is "distorted"?

2 3

Re: [2/2] kernel32: Remove a 0-length read optimization from ReadFile.
by Alexandre Julliard 12 Sep '13

12 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This matches WriteFile behaviour and ensures that invalid parameters are > properly handled and fields in the OVERLAPPED structure are initialized. This is again causing test failures. Please do a full test run before sending patches. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/2] ntdll: Properly handle 0-length reads.
by Marvin 12 Sep '13

12 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2127 Your paranoid android. === wxppro (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1000 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1000 ms for waiting === w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500

2 1

Re: ws2_32/tests: Add more WSASocket tests
by Marvin 12 Sep '13

12 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2126 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (7e4): unexpectedly at the OOB mark: 0

1 0

Re: [try3] gdi32: abc values remain the same despite any changes in layout direction or Viewport
by Aric Stewart 12 Sep '13

12 Sep '13

Alexandre, Do you want me to rewrite this patch with your new width_to_LP helper function or are you going to do that rewrite yourself? (assuming it is acceptable in other ways) thanks! -aric

1 0

Re: kernel32/tests: Add tests for ResolveDelayLoadedAPI (try3)
by Marvin 11 Sep '13

11 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2121 Your paranoid android. === wvista (32 bit loader) === loader.c:2056: Test failed: WaitForSingleObject failed: 102 loader.c:2058: Test failed: expected exit code 199, got 259 loader.c:2077: Test failed: expected 198, got 199

1 0

Re: [PATCH 4/5] ddraw: Avoid LPVOID.
by Marvin 11 Sep '13

11 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2112 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1260: Test failed: Homogeneous output was generated despite UNCLIPPED flag

2 1

Re: wininet: Don't assume that end of chunk means end of stream.
by Jacek Caban 11 Sep '13

11 Sep '13

Hi Hans, On 09/11/13 13:50, Hans Leidekker wrote: > static DWORD chunked_get_avail_data(data_stream_t *stream, http_request_t *req) > { > - /* Allow reading only from read buffer */ > + chunked_stream_t *chunked_stream = (chunked_stream_t*)stream; > + DWORD res; > + > + if(!chunked_stream->chunk_size || chunked_stream->chunk_size == ~0u) { > + res = start_next_chunk(chunked_stream, req); > + if(res != ERROR_SUCCESS) > + return 0; > + } start_next_chunk may block and we don't want chunked_get_avail_data to block. Jacek

2 4

Re: ws2_32: Fix WSADuplicateSocket implementation
by Marvin 11 Sep '13

11 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2119 Your paranoid android. === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (a8c): not at the OOB mark: 1

1 0

RFC: HKCR merge implementation
by George Stephanos 11 Sep '13

11 Sep '13

I'm proposing my HKEY_CLASSES_ROOT implementation patches for review. Feel free to comment. So far, I've written code for all functions except for the RegEnum family. General description: HKCR handles are special. All wine handles have the two lowest bits zero'd. HKCR handles are masked. 10b specifically. They have their own table separate from the generic handle table. An HKCR handle has an HKCU handle and an HKLM handle below it. Access mask and a string representing the path are also needed since the handle has to attempt to reopen previously failed openings at certain stages. First patch: specially handles HKCR handles WITHOUT affecting the general behavior. The end result is still the exact same. Patch provides a foundation for the rest. Second patch: added path management Third patch: added HKCU Here's a quick description of each function: create_hkcr_struct: allocates the memory needed for the struct, adds it to the table and gives back a pointer to it get_hkcr_path: given an HKCR handle and a subkey string, prepares a subkey string representing the same subkey rooted at HKLM/HKCU. create_hkcr: RegCreateKeyEx open_hkcr: RegOpenKeyEx resolve_hkcr: checks the HKCR handle, tries to reopen previously failed internal handles, gives back HKCU first if available then HKLM close_hkcr: deallocates path and struct, removes struct from table. http://pastie.org/8314658 http://pastie.org/8314662 http://pastie.org/8314663

3 3

Re: [PATCH 2/2] d3d11.idl: Added some missing declarations.
by Henri Verbeet 11 Sep '13

11 Sep '13

On 11 September 2013 12:09, Jacek Caban <jacek(a)codeweavers.com> wrote: > +typedef enum D3D11_RESOURCE_MISC_FLAG > +{ > + D3D11_RESOURCE_MISC_GENERATE_MIPS = 0x00000001, > + D3D11_RESOURCE_MISC_SHARED = 0x00000002, > + D3D11_RESOURCE_MISC_TEXTURECUBE = 0x00000004, > + D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS = 0x00000010, > + D3D11_RESOURCE_MISC_BUFFER_ALLOW_RAW_VIEWS = 0x00000020, > + D3D11_RESOURCE_MISC_BUFFER_STRUCTURED = 0x00000040, > + D3D11_RESOURCE_MISC_RESOURCE_CLAMP = 0x00000080, > + D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX = 0x00000100, > + D3D11_RESOURCE_MISC_GDI_COMPATIBLE = 0x00000200, > + D3D11_RESOURCE_MISC_SHARED_NTHANDLE = 0x00000800, > + D3D11_RESOURCE_MISC_RESTRICTED_CONTENT = 0x00001000, > + D3D11_RESOURCE_MISC_RESTRICT_SHARED_RESOURCE = 0x00002000, > + D3D11_RESOURCE_MISC_RESTRICT_SHARED_RESOURCE_DRIVER = 0x00004000, > + D3D11_RESOURCE_MISC_GUARDED = 0x00008000 > +} D3D11_RESOURCE_MISC_FLAG; Arguably those should be __MSABI_LONG, although we may not care enough. We certainly aren't very consistent about it in a lot of other places either.

3 2

riched20/tests: Add tests for ITextDocument_Save. (try 2)
by Jactry Zeng 11 Sep '13

11 Sep '13

Update: Add todo_wine

1 0

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context.
by Henri Verbeet 11 Sep '13

11 Sep '13

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1880,9 +1888,8 @@ struct wined3d_device > WORD d3d_initialized : 1; > WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ > WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ > - WORD useDrawStridedSlow : 1; > WORD filter_messages : 1; > - WORD padding : 8; > + WORD padding : 1; I don't think that's quite right.

2 2

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload
by Henri Verbeet 11 Sep '13

11 Sep '13

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - /* Reading the declaration makes only sense if the stateblock is finalized and the buffer bound to a stream */ > - if (device->isInDraw && buffer->resource.bind_count > 0) > + /* Reading the declaration makes only sense if we have valid state information > + * (i.e., if this function is called during draws). */ > + if (state) Technically what needs to be valid is the stream info, although we probably don't care that much about the distinction.

1 0

Re: [PATCH 3/5] wined3d: Pass stream info and needed fixups to buffer_find_decl.
by Henri Verbeet 11 Sep '13

11 Sep '13

On 11 September 2013 11:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -330,7 +331,7 @@ static BOOL buffer_find_decl(struct wined3d_buffer *This) > if(This->resource.usage & WINED3DUSAGE_STATICDECL) return FALSE; > } > > - if (use_vs(state)) > + if (fixup_flags & WINED3D_BUFFER_FIXUP_USE_SHADER) It can actually be a bit simpler than that. Note that all the texcoord checks are redundant when "support_d3dcolor" is true, because declaration_element_valid_ffp() already prevents D3DCOLOR elements from being used with texcoords. That then implies you can mostly just pass the fixup mask to buffer_check_attribute(), and check for an empty fixup mask instead of vertex shader usage here. (Although that means inverting the flags as you have them right now.)

1 0

Re: (resend) gdi32: abc values remain the same despite any changes in layout direction or Viewport
by Marvin 11 Sep '13

11 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2103 Your paranoid android. === wxppro (32 bit font) === font.c:1323: Test failed: abcB should be unchanged font.c:1323: Test failed: abcC should be unchanged font.c:1323: Test failed: abcfB should be unchanged font.c:1323: Test failed: abcfC should be unchanged font.c:1345: Test failed: abcB should be unchanged font.c:1345: Test failed: abcC should be unchanged font.c:1345: Test failed: abcfB should be unchanged font.c:1345: Test failed: abcfC should be unchanged

1 0

Re: po: Add English (Philippines) resource (resend)
by Alexandre Julliard 11 Sep '13

11 Sep '13

Ken Sharp <kennybobs(a)o2.co.uk> writes: > @@ -111,6 +111,9 @@ filter: dummy > .svg.bmp: > CONVERT="$(CONVERT)" ICOTOOL="$(ICOTOOL)" RSVG="$(RSVG)" $(BUILDIMAGE) $< $@ > > +$(top_srcdir)/po/en_PH.po: $(top_srcdir)/po/en_US.po > + $(LN_S) -f en_US.po $@ > + You can't create links in the source tree, and in any case this should be done directly in wrc, with some sort of alias mechanism. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: (resend) [PATCH] serial: wait_for_event() must set Information in PIO_STATUS_BLOCK
by Dmitry Timoshkov 11 Sep '13

11 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > - if (commio->iosb) commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS : STATUS_CANCELLED; > + if (commio->iosb) { > + commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS : STATUS_CANCELLED; > + if (*commio->events) > + commio->iosb->Information = sizeof(DWORD); > + } Did you run 'make test' with this change? Probably some todo_wine statements need to be removed. Also why 'Information' is set only in the case if events != 0? I'd guess that it should be set in any case since 'events' is always initialized. -- Dmitry.

1 0

Embedding a HWND window into an X11 window
by Alexandre Bique 10 Sep '13

10 Sep '13

Hi, How could I embed a HWND window created with CreateWindow() into an X11 window? Thanks! :-) -- Alexandre Bique

5 8

RFC: HKCR merge implementation
by George Stephanos 10 Sep '13

10 Sep '13

I'm proposing my HKEY_CLASSES_ROOT implementation patches for review. Feel free to comment. So far, I've written code for all functions except for the RegEnum family. General description: HKCR handles are special. All wine handles have the two lowest bits zero'd. HKCR handles are masked. 10b specifically. They have their own table separate from the generic handle table. An HKCR handle has an HKCU handle and an HKLM handle below it. Access mask and a string representing the path are also needed since the handle has to attempt to reopen previously failed openings at certain stages. First patch: specially handles HKCR handles WITHOUT affecting the general behavior. The end result is still the exact same. Patch provides a foundation for the rest. Second patch: added path management Third patch: added HKCU Here's a quick description of each function: create_hkcr_struct: allocates the memory needed for the struct, adds it to the table and gives back a pointer to it get_hkcr_path: given an HKCR handle and a subkey string, prepares a subkey string representing the same subkey rooted at HKLM/HKCU. create_hkcr: RegCreateKeyEx open_hkcr: RegOpenKeyEx resolve_hkcr: checks the HKCR handle, tries to reopen previously failed internal handles, gives back HKCU first if available then HKLM close_hkcr: deallocates path and struct, removes struct from table.

1 0

Re: winemac: Don't return characters for Ctrl-(non-letter symbol) keypresses from ToUnicodeEx() as X11 driver already does (try 2)
by Ken Thomases 10 Sep '13

10 Sep '13

Hi, On Sep 9, 2013, at 7:38 PM, Phil Krylov wrote: > Sorry, my first try had wrong patch attached > > -- Ph. > <0001-winemac-Don-t-return-characters-for-Ctrl-non-letter-try2.patch.txt> Is there a specific problem that you're trying to fix? The Mac driver's ToUnicodeEx() implementation started out very similar to the X11 driver's. It was basically a copy that I hacked on. It originally had this same restriction. However, some testing revealed that this is not an absolute restriction on Windows. For example, in the Khmer keyboard layout, Control-<digit> produces characters for some digits. Given that some Windows keyboard layouts produce characters for Control-<digit>, I figured it was best left up to the Mac keyboard layout. Similarly for Control-<punctuation>. For example, the Windows Chinese keyboard layouts produce characters for some of those keystrokes. So does the Czech layout. It might still be possible to re-introduce this restriction if it can be justified based on broad breakage of apps. Although even then, I'd want to make it possible to override the restriction with a registry setting or something. You never know if the ability to enter characters using these key combinations might be crucial for certain Mac users because of the nature of their native keyboard layout. If a modification like this were justified, it should go earlier in macdrv_ToUnicodeEx(). There's a section at the top where I moved the checks for combinations that don't produce characters. Also, the check should test that Alt is _not_ pressed, since Control-Alt-<digit or punct> and Control-Alt-Shfit-<digit or punct> very commonly produce characters. Control-Alt is a synonym for the AltGr key on some keyboards (e.g. Swiss). Finally, if we're going to pursue this, there are some minor style issues I'd prefer be changed. So, check with me before resubmitting. Thanks and cheers, Ken

2 2

Re: ntdll: Try application manifest path when searching for dependent assemblies
by Alexandre Julliard 10 Sep '13

10 Sep '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2776,8 +2776,7 @@ static NTSTATUS lookup_assembly(struct actctx_loader* acl, > /* FIXME: add support for language specific lookup */ > > nameW.Buffer = NULL; > - if (!(buffer = RtlAllocateHeap( GetProcessHeap(), 0, > - (strlenW(acl->actctx->appdir.info) + 2 * strlenW(ai->name) + 2) * sizeof(WCHAR) + sizeof(dotManifestW) ))) > + if (!(buffer = RtlAllocateHeap( GetProcessHeap(), 0, MAX_PATH * sizeof(WCHAR) ))) Please try to allocate the correct size. If you want to use MAX_PATH you then have to check for overflow when building the string, which is probably worse. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] ntdll: Make NtWriteFile handle special offset -2 same way as -1. Resend.
by Alexandre Julliard 10 Sep '13

10 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 31 +++++++++++++++---------------- > 1 file changed, 15 insertions(+), 16 deletions(-) Why do you need that? It doesn't look to me like an improvement. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] oledb32: Implement IDataSourceLocator get/put hWnd (resend)
by Nikolay Sivov 10 Sep '13

10 Sep '13

On 9/10/2013 13:30, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > oledb32: Implement IDataSourceLocator get/put hWnd > > > Best Regards > Alistair Leslie-Hughes Hi, Alistair. This is wrong, interface definition should be fixed as well, HWND parameter can't be LONG: --- [id(0x60020000), propget] HRESULT hWnd([out, retval] long* phwndParent); [id(0x60020000), propput] HRESULT hWnd([in] long phwndParent); --- PSDK header has COMPATIBLE_LONG thing to make it work on win64.

1 0

Re: xcopy: Add an explicit check to avoid an out of array access. access. (RESEND)
by Alexandre Julliard 10 Sep '13

10 Sep '13

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > On Sun, 24 Mar 2013, Gerald Pfeifer wrote: >> This _may_ not be necessary, strictly speaking, but new versions of >> GCC (GCC 4.8) complain about this. (And there might be a fringe case?) > > How about this patch? I see it was not applied, but also did not > see a response. It can't happen (and removing the last char unconditionally is broken anyway). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] ntdll: Add support to NtWriteFile for special offset -1. Take 3.
by Alexandre Julliard 10 Sep '13

10 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -961,16 +961,23 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > > if (type == FD_TYPE_FILE) > { > + off_t off; > + > if (!(options & (FILE_SYNCHRONOUS_IO_ALERT | FILE_SYNCHRONOUS_IO_NONALERT)) && !offset) > { > status = STATUS_INVALID_PARAMETER; > goto done; > } > > - if (offset && offset->QuadPart != (LONGLONG)-2 /* FILE_USE_FILE_POINTER_POSITION */) > + off = offset ? offset->QuadPart : (off_t)-2 /* FILE_USE_FILE_POINTER_POSITION */; > + > + if (off == (off_t)-1 /* FILE_WRITE_TO_END_OF_FILE */) > + off = lseek( unix_handle, 0, SEEK_END ); You are not supposed to change the position for the asynchronous case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 5)
by Marvin 10 Sep '13

10 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2084 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (138): not at the OOB mark: 1 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (934): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (934): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (934): error 10054: sock.c:534: Test failed: oob_server (934): not at the OOB mark: 1

1 0

Re: [1/5] ntdll: Add support to NtWriteFile for special offset -1. Take 2.
by Alexandre Julliard 09 Sep '13

09 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 13 ++++++++++--- > dlls/ntdll/tests/file.c | 15 --------------- > 2 files changed, 10 insertions(+), 18 deletions(-) This is causing test failures all over the place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty
by Dmitry Timoshkov 09 Sep '13

09 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > + if (res || (!res && GetLastError() == ERROR_IO_PENDING)) > + /* if data has been sent: wait for termination */ > + Sleep(timeout); I don't see such a problem with real COM-port and serial-USB cable under Windows or Linux here and under testbot VMs. -- Dmitry.

3 12

Re: server: Add a serial event mask change counter.
by Alexandre Julliard 09 Sep '13

09 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -209,7 +211,7 @@ DECL_HANDLER(get_serial_info) > reply->writemult = serial->writemult; > > /* event mask */ > - reply->eventmask = serial->eventmask; > + reply->eventmask = serial->eventmask | (serial->generation << 16); It would be better to return it as a separate field, particularly since eventmask is already an int. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] ws2_32: Fix parameters checking in WSADuplicateSocket
by Alexandre Julliard 09 Sep '13

09 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + fd = get_sock_fd( s, FILE_READ_DATA, NULL ); > + if (fd == -1) > + { > + SetLastError(WSAENOTSOCK); > + return SOCKET_ERROR; > + } > + release_sock_fd( s, fd ); You should avoid retrieving the fd if you are not using it. The handle should be checked at the point where you are doing something with it. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/5] wined3d: Move the decoded stream info into the context
by Henri Verbeet 09 Sep '13

09 Sep '13

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- I think this patch does a couple of things at once, and would probably benefit from being broken up. > static struct arb_vs_compiled_shader *find_arb_vshader(struct wined3d_shader *shader, > - const struct arb_vs_compile_args *args, > + const struct wined3d_context *context, const struct arb_vs_compile_args *args, > const struct wined3d_shader_signature_element *ps_input_sig) I think it makes more sense to pass a wined3d_stream_info structure here instead of a context, or perhaps even just the use_map field. > -static BOOL buffer_find_decl(struct wined3d_buffer *This) > +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context) Same. > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 23d32c2..f7ded75 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1086,6 +1086,7 @@ struct wined3d_context > DWORD padding : 1; > DWORD texShaderBumpMap : 8; /* MAX_TEXTURES, 8 */ > DWORD lastWasPow2Texture : 8; /* MAX_TEXTURES, 8 */ > + DWORD use_draw_strided_slow : 1; > DWORD shader_update_mask; > DWORD constant_update_mask; > DWORD numbered_array_mask; I think that's an unfortunate place to insert the field, and you should update the padding. > @@ -1880,9 +1889,7 @@ struct wined3d_device > WORD d3d_initialized : 1; > WORD inScene : 1; /* A flag to check for proper BeginScene / EndScene call pairs */ > WORD softwareVertexProcessing : 1; /* process vertex shaders using software or hardware */ > - WORD useDrawStridedSlow : 1; > WORD filter_messages : 1; > - WORD padding : 8; Padding?

3 3

Re: [PATCH 5/5] wined3d: Explicitly pass the state information to buffer_internal_preload
by Henri Verbeet 09 Sep '13

09 Sep '13

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context) > +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct wined3d_context *context, > + const struct wined3d_state *state) buffer_find_decl() doesn't really care about the context state, it's really just about determining what fixups it should check for, and should probably be passed a mask instead.

1 0

Re: [PATCH 1/5] wined3d: Don't mess with the device in buffer_create_buffer_object
by Henri Verbeet 09 Sep '13

09 Sep '13

On 9 September 2013 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -148,7 +149,7 @@ static void buffer_create_buffer_object(struct wined3d_buffer *This, const struc > } > > if (This->buffer_type_hint == GL_ELEMENT_ARRAY_BUFFER_ARB) > - device_invalidate_state(This->resource.device, STATE_INDEXBUFFER); > + context_invalidate_state(context, STATE_INDEXBUFFER); > GL_EXTCALL(glBindBufferARB(This->buffer_type_hint, This->buffer_object)); > error = gl_info->gl_ops.gl.p_glGetError(); > if (error != GL_NO_ERROR) The patch is fine, although I probably would have preferred something along the lines of "Only invalidate STATE_INDEXBUFFER for the current context in buffer_create_buffer_object()." for the commit message.

1 0

Re: [PATCH 1/6] ws2_32: Mark WinNT result as broken
by Marvin 09 Sep '13

09 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2061 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (7e0): unexpectedly at the OOB mark: 0

2 1

Re: [PATCH 6/6] ws2_32: Fill WSAPROTOCOL_INFO struct in WSADuplicateSocket
by Marvin 08 Sep '13

08 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2065 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (f0): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (f0): unexpectedly at the OOB mark: 0

1 0

Implementation of ITextDocument_fnOpen needs some advice
by Jactry Zeng 08 Sep '13

08 Sep '13

Hi folks, I need your advice or comment! Implement ITextDocument_fnOpen[0] (riched20) is a part of work to my GSoC. The 'pencils down' date is coming. And I think it is time to clear the code up. This series of patches is the implementation of ITextDocument_fnOpen. I would like to improve it to be enough good for sending to wine-patches and being accepted. I split the implementation into six patches: - patch 0001 is just a simple implementation; - patch 0002 added the creation mode to let it support these parameters: tomCreateNew, tomCreateAlways, tomOpenExisting, tomOpenAlways, tomTruncateExisting; - patch 0003 added the access mode to let support tomReadOnly and any combination of tomReadOnly and tomShareDenyRead, tomShareDenyWrite, tomPasteFile; - patch 0004 added the support of RTF - patch 0005 added tomPasteFile support - patch 0006 added a UTF-16 support, with this patch you can open a UTF-6 text file without dependence of the long CodePage parameter. If you want to open a utf-8 text file with it, you may need these patch to fix a bug of EM_SETTEXTEX: http://source.winehq.org/patches/data/98574 http://source.winehq.org/patches/data/98575 http://source.winehq.org/patches/data/98576 http://source.winehq.org/patches/data/98577 I appreciate for any comment! :) Thank you. ** Thanks my mentor Huw and Qian Hong for giving me a lot good advice. Thanks other people for help! ** [0] http://msdn.microsoft.com/en-us/library/windows/desktop/bb774093(v=vs.85).a… -- Regards, Jactry Zeng

1 0

Re: [PATCH 5/6] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 4)
by Marvin 08 Sep '13

08 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2064 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (ec): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (3a4): not at the OOB mark: 1

1 0

Re: [PATCH 4/6] ws2_32: Add more WSADuplicateSocket tests
by Marvin 08 Sep '13

08 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2063 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62 === w7pro64 (32 bit sock) === sock.c:519: Test failed: oob_server (138): unexpectedly at the OOB mark: 0 sock.c:768: sock.c:288: Test failed: do_synchronous_recv (138): error 10054: sock.c:534: Test failed: oob_server (138): not at the OOB mark: 1 === w7pro64 (64 bit sock) === sock.c:528: Test failed: oob_server (ab8): not at the OOB mark: 1

1 0

Re: [PATCH 3/6] ws2_32: Fix parameters checking in WSADuplicateSocket
by Marvin 08 Sep '13

08 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2062 Your paranoid android. === wxppro (32 bit sock) === sock.c:509: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 71AB8D62

1 0

Patch for bug 34388
by Charles Davis 07 Sep '13

07 Sep '13

Hi Juan, I need some advice. Attached is a patch to fix bug 34388, where an app that tries to verify its code signature fails because Wine, while parsing the certificates embedded within the signature, encounters an item in the CMS signer info (tag 0x31, i.e. ASN_UNIVERSAL | ASN_CONSTRUCTOR | 0x11), right before the HashEncryptionAlgorithm sequence item, that it doesn't yet know how to decode. This patch (which just skips the item in question) allows that app to successfully verify its code signature and run, but... My testing on Windows (cf. job 2037 on newtestbot) shows some interesting behavior. Windows will indeed accept this item, but only if the AuthAttrs item is also present and immediately precedes it in the sequence. (The other test bails out with CRYPT_E_ASN_BADTAG.) I don't quite know what to make of this. The odd thing is that the certificate in question doesn't have this optional AuthAttrs item, and yet (in most cases, at least) most people who run this particular app on Windows do not have this problem. I can't seem to find anything about this from reading the relevant RFCs. Is there something I'm missing? Thanks. Chip

2 5

Re: ntdll: Implement job objects. (try 3)
by Alexandre Julliard 07 Sep '13

07 Sep '13

Andrew Cook <ariscop(a)gmail.com> writes: > This will be my last submission for this piece of code, i want to work > on other things and it's been almost 2 weeks with zero comments on my > previous submission. It's clearly not ready, and you already know that since you've added TODOs all over the place. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: Completely revised SIO_ADDRESS_LIST_CHANGE patches
by Erich E. Hoover 06 Sep '13

06 Sep '13

As some of you know I've been working on fixing SIO_ADDRESS_LIST_CHANGE in order to fix some problems with Silverlight on a variety of streaming sites. Due to some feedback I've received I've gone to the effort to completely revise these patches to work inside of the server instead of using iphlpapi. Any and all feedback is appreciated, special thanks go to Sebastian Lackner for looking over these patches ahead of time. Design considerations: 0001) This patch was modeled after similar behavior for unimplemented ioctl() calls in ntdll 0002) The implementation uses a per-socket queue so that when a socket is destroyed prior to a notification event then that socket's async operations are all appropriately woken up. Only one interface change notification object exists at a time, so the object is destroyed whenever there are no sockets expecting events and is then re-created as needed. 0003) This patch is a simple test case with the rest of the socket tests #ifdef'd out for your convenience Looking forward to hearing back! Best, Erich

1 0

Re: aclui: Remove some unneeded header inclusions. (IWYU)
by Alexandre Julliard 06 Sep '13

06 Sep '13

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > @@ -18,15 +18,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > -#include "config.h" > - > -#include <stdarg.h> > - > #include "initguid.h" > -#include "windef.h" > -#include "winbase.h" > -#include "winuser.h" > -#include "winnt.h" > #include "aclui.h" That's not useful. The headers will be included anyway. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/6] ntdll: Add support to NtWriteFile for special offset -1.
by Alexandre Julliard 06 Sep '13

06 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/ntdll/file.c | 3 +++ > dlls/ntdll/tests/file.c | 15 --------------- > 2 files changed, 3 insertions(+), 15 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 9420df5..9d5b02a 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -967,6 +967,9 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > goto done; > } > > + if (offset && offset->QuadPart == (LONGLONG)-1 /* FILE_WRITE_TO_END_OF_FILE */) > + offset->QuadPart = lseek( unix_handle, 0, SEEK_END ); > + This looks very wrong, offset belongs to the caller. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 3)
by Alexandre Julliard 06 Sep '13

06 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +static int ws_protocol_info(SOCKET s, int unicode, WSAPROTOCOL_INFOW *buffer) > +{ > + int size; > + union _info > + { > + WSAPROTOCOL_INFOA *a; > + WSAPROTOCOL_INFOW *w; > + } info; > + info.w = buffer; > + > + size = unicode ? sizeof(WSAPROTOCOL_INFOW) : sizeof(WSAPROTOCOL_INFOA); > + memset(buffer, 0, size); > + info.w->iAddressFamily = WS_AF_UNSPEC; > + > + SERVER_START_REQ( get_socket_info ) > + { > + req->handle = wine_server_obj_handle( SOCKET2HANDLE(s) ); > + wine_server_call( req ); > + info.w->iAddressFamily = convert_af_u2w(reply->family); > + info.w->iSocketType = convert_socktype_u2w(reply->type); > + info.w->iProtocol = convert_proto_u2w(reply->protocol); > + } > + SERVER_END_REQ; You need to check the server return status and set the correct error code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: D3D command stream patches for testing
by LOMBARD Maxime 06 Sep '13

06 Sep '13

Hi Stefan, I've tested two games "FarCry3" and "Splinter Cell Blacklist" with : - Wine 1.7.1 + CS patch + CSMT On/Off - Wine 1.7.1 clean - CSMT On = CSMT enabled + StrictDrawOrdering disabled - CSMT Off = CSMT disabled + StrictDrawOrdering enabled I run the game by *WINEDEBUG=fps,err-all,fixme-all primusrun /home/berillions/Desktop/Build/32/wine-1.7.1-{clean/csmt}/wine "$1" 2>&1 | tee /dev/stderr | grep --line-buffered "^trace:fps:" | osd_cat -c white -s 1 -l2;* ## My Laptop ## - Nvidia GTX670MX - Intel I5-3230M - Debian Sid 64-bits - Nvidia drivers 325.15 ## FarCry 3 tests ## Graphic options : - Texture : High - Ambient Lighting : High - Shadow : Ultra - Post Fx : Ultra - Geometry : Ultra - Vegetation : Very High - Terrain : High - Water : Very High - Environment : High Wine 1.7.1 clean : - Main Menu : ~35 fps - In-game (move or static camera) : ~12 fps average Wine 1.7.1 + CS patch + CSMT Off : - Main Menu : ~45fps - In-game : ~14 fps average Wine 1.7.1 + CS patch + CSMT On : - Main Menu : ~45fps - In-game : ~18 fps average ## Splinter Cell Blacklist ## Graphic Options : - Texture detail : Ultra - Shadow Quality : High - Parallax : On - Tesselation : Off - Texture Filtering : Anisotropic 4x - V-Sync : On - Dynamic ambient Occlusion : Field AO - Anti-Aliasing : FXAA - Directx : Dx9 Wine 1.7.1 clean : - In-game : ~15 fps average Wine 1.7.1 + CS patch + CSMT Off : - In-game : ~15 fps average Wine 1.7.1 + CS patch + CSMT On : - In-game : ~3 fps average In resume, CS patch works for FarCry 3, +6fps but cause a very low fps for SC Blacklist, divide by 5 the fps in game. Max

1 0

Re: crypt32 patch review
by Juan Lang 06 Sep '13

06 Sep '13

[+wine-devel] Hi Jacek, I've added the list so the discussion can take place in public. On Tue, Sep 3, 2013 at 8:50 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > I have a patch for crypt32. I'd appreciate your review before I submit > it to Wine. It has high potential to be insecure... This should fix Wine bug 28004 as well as some websites that don't send full cert chain in > SSL/TLS handshake, but instead just their own certs. For that we need > two changes. First, we need to look for issuers in global stores (as in > those that are not passed to CertGetCertificateChain). When I did that, > I don't really see a security issue here. The global stores are implicitly trusted, so neglecting to check them was probably an oversight on my part. Your tests imply something is missing. My only real question here is whether the test results are in any way impacted by some unknown caching happening in Windows. Has this chain been verified prior to running the test? I'm going to guess that the test bot machines are "clean" prior to running the tests, but if they download their test executables from winehq.org, that won't be the case. > it came out that it's not enough for intermediate issuers. Those have to > be downloaded if we have information about their location stored in > validated cert. That's easy using cryptnet. Could you please review the > attached patch? > + for(i=0; i < info->cAccDescr; i++) { + if(!strcmp(szOID_PKIX_CA_ISSUERS, info->rgAccDescr[i].pszAccessMethod) + && info->rgAccDescr[i].AccessLocation.dwAltNameChoice == CERT_ALT_NAME_URL) { You explicitly make use of the AIA extension to find the location of intermediate certs. This is reasonable, and it gets your test case to pass, but it won't cover end certs that don't make use of the AIA extension. As I said above, I wonder whether caching is impacting the test results. More: The thing that would be also nice to have as follow up is to cache > downloaded URLs. They are already cached in URL cache, but I believe > that they should be also cached in some place like world collection or > something like that. I'm not sure what would be appropriate. Do you have > a suggestion? > Yes. I suspect the most relevant bug is actually 27168. 28004 is probably a dupe of it, except that I'm not certain that PartyPoker uses chromium. In brief, Microsoft's crypt32 appears to cache intermediate certs in a PCCERT_CONTEXT's hCertStore. What I should be doing in crypt32, but am not, is to have certs ref count the stores they're in, such that the last cert to be closed causes its store to be freed, if the store is closed prior to the cert being freed. This, combined with certificate chains being cached in Microsoft's implementation, would allow intermediate certs to be found without explicitly checking the AIA. You can see how the certificate chain engine ought to support caching on MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa377184(v=vs.85).a… I never implemented chain caching, as I expected it'd be a performance optimization and could be addressed at a later time, and never got back to it. In addition to bug 27168, you can see how Chromium is making use of crypt32's certificate caching in net::X509Certificate::CreateOSCertChainForCert, both its comments and implementation: http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.h http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate_w… Back to your patch: I'm not entirely opposed to the explicit AIA approach, but I think it's worth at least thinking about other methods. And, I'd prefer to see the code block more explicitly separated from the surrounding code, with either a comment or a clear function name to indicate what's going on. As it is, one has to read quite a bit of CRYPT_FindIssuer to realize that it's really looking for an AIA extension to find intermediate issuers. Last thing on the patch, some style nits. (You already remarked that it needs splitting, and I agree.) + if(issuer) { Elsewhere in crypt32 I indent prior to open parentheses, so I worry this will make it a little harder to maintain a consistent style. Please observe the existing style, here and elsewhere. - issuer = CertFindCertificateInStore(store, - subject->dwCertEncodingType, 0, CERT_FIND_SUBJECT_NAME, - &subject->pCertInfo->Issuer, prevIssuer); + issuer = CRYPT_FindIssuer(engine, subject, store, CERT_FIND_SUBJECT_NAME, + &subject->pCertInfo->Issuer, flags, prevIssuer); It might not be easy to guess my indenting style for continuation lines, but I use a single additional space to indicate continuation through crypt32. I'd appreciate observing the same style. - hAdditionalStore, &chain); + hAdditionalStore, dwFlags, &chain); Likewise, the indentation change here doesn't seem necessary. Thanks very much for working on this. Hope my comments are helpful, let me know if I can be of further assistance. --Juan

2 1

Re: ntdll/tests: Add tests for job objects. (try 2)
by Frédéric Delanoy 06 Sep '13

06 Sep '13

On Fri, Sep 6, 2013 at 5:41 AM, Andrew Cook <ariscop(a)gmail.com> wrote: > --- > dlls/ntdll/tests/Makefile.in | 1 + > dlls/ntdll/tests/job.c | 151 > +++++++++++++++++++++++++++++++++++++++++++ > include/winnt.h | 5 ++ > 3 files changed, 157 insertions(+) > create mode 100644 dlls/ntdll/tests/job.c + if(pNtIsProcessInJob) + todo_wine todo_wine ok(pNtIsProcessInJob(pi[0].hProcess, JobObject) == STATUS_PROCESS_NOT_IN_JOB, + "NtIsProcessInJob: expected STATUS_PROCESS_NOT_IN_JOB, got %x\n", ret); Is that double todo_wine intended? It seems weird... -- Frédéric Delanoy

2 1

Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode. (try 2)
by Nikolay Sivov 06 Sep '13

06 Sep '13

On 9/4/2013 07:17, Jactry Zeng wrote: > - ME_EndToUnicode(unicode, wszText); > + ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText); It's still ugly to use magic numbers like that, in a similar situation I had some time ago I use ~0 to mark WCHAR data encoding that does need special handling. Even with a value like ~0 it needs to be documented in code comments.

2 2

Re: [PATCH 2/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 3)
by Marvin 06 Sep '13

06 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2035 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b8): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000

1 0

D3D command stream patches for testing
by Pierre Franco 05 Sep '13

05 Sep '13

I've tested some games (wine 1.7.1 64-bit for Guild Wars 2 and SCII, 32-bit for Skyrim, no wined3d/d3d patch except the patchset for CSMT). I have a GTX660 (slightly overclocked, +10 Mhz or so) with the 325.15 Nvidia blob and an Intel i5 2500K (overclocked to 4.2 Ghz). #Guild Wars 2(in the Lion's Arch with ~75-100 players, always from the same spot): Quality Options: -Fullscreen Mode -1600x1200 -Animation: High -Anti-aliasing: FXAA -Environment: High -LOD: Excellent -Textures: High -Reflections: Land and Sky(causes high frame rate drops when moving the camera) -Render Sampling: Supersampling -Shadows: High -Shaders: High -Post-processing: High(absolutely doesn't influence frame rate) -No High Res Character Textures -Character model limit/Character model quality: Medium -VSyng: Off -Optimal Texture Filtering: Off(no real effect except reducing the FPS) Without -dx9single(it should use more than one core and DX10 then): -With __GL_THREADED_OPTIMIZATIONS: 30-45 FPS in the login screen, 8-10 FPS when not moving the camera, 3-5 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: 60 FPS in the login screen, 18-20 FPS when not moving the camera, 5-10 FPS when moving it. With -dx9single(the game is far more quicker to load with it): -With __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 5-20 FPS when moving it. -Without __GL_THREADED_OPTIMIZATIONS: >60 FPS in the login screen, 23-24 FPS when not moving the camera, 20 FPS when moving it. Conclusion: -dx9single is GOOD and __GL_THREADED_OPTIMIZATIONS is BAD. #Starcraft II Quality Options: Ultra(default mode, also for the textures). The game claims 50-70 FPS, but it seems to lag when moving the camera and the output is only trash (I need to change a graphical setting to be able to see anything). With __GL_THREADED_OPTIMIZATIONS, it's even more laggy and the FPS drop below 40. #Skyrim Quality Options: Very High. I can't see the FPS of the game, but it was running smoothly and is still running smoothly with the patchset. I didn't tried with __GL_THREADED_OPTIMIZATIONS(well, I tried long ago, and that was horribly slow). I also want to say that wine is spamming "Waiting for the cs" in the console (I assume it's nothing really important as the project seems to be WIP, why asking for tester otherwise?) and wgl errors (err:wgl:wglFlush wglFlush). Cordially. P.S. : Sorry for my English, I am still learning it. -- Pierre Franco nob.dir.info(a)gmail.com

1 0

Re: [PATCH 6/6] kernel32/tests: remove several todos in test_waittxempty
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2023 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:856: Test failed: WaitCommEvent failed with a timeout comm.c:868: recovering after WAIT_TIMEOUT... comm.c:879: Test failed: WaitCommEvent error 0 comm.c:880: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:884: WaitCommEvent for EV_TXEMPTY took 2137 ms (timeout 2133) comm.c:885: Test failed: WaitCommEvent used 2137 ms for waiting comm.c:919: Test failed: WaitCommEvent error 87 comm.c:921: Test failed: WaitCommEvent failed with a timeout comm.c:932: recovering after WAIT_TIMEOUT... comm.c:938: Test failed: WaitCommEvent failed with a timeout comm.c:943: Test failed: WaitCommEvent error 0 comm.c:944: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:948: WaitCommEvent for EV_TXEMPTY took 3151 ms (timeout 2133) comm.c:949: Test failed: WaitCommEvent used 3151 ms for waiting comm.c:1617: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1584: Changing CommMask on the fly for handle 00000130 after timeout 500

1 0

Re: [PATCH 2/5] wait until all data from earlier test has been written in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > > > > > With my patches 1/2 and 2/2 I get: > > > > > > > > > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped > > > > > 0x10ee8ec): > > > > > stub wine: configuration in '/home/walterw/.wine' has been updated. > > > > > fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub > > > > > comm.c:857: Test succeeded inside todo block: WaitCommEvent failed > > > > > with a > > > > > timeout comm.c:881: Test succeeded inside todo block: WaitCommEvent > > > > > error > > > > > 997 comm.c:883: Test succeeded inside todo block: WaitCommEvent: > > > > > expected > > > > > EV_TXEMPTY, got 0x4 comm.c:889: Test succeeded inside todo block: > > > > > WaitCommEvent used 1141 ms for waiting err:comm:set_line_control > > > > > ByteSize > > > > > fixme:ntdll:server_ioctl_file Unsupported ioctl 1b000c (device=1b > > > > > access=0 > > > > > func=3 method=0) comm.c:2036: Tests skipped: interactive tests (set > > > > > WINETEST_INTERACTIVE=1) > > > > > > > > Successes inside of todo_wine blocks are treated as failres. > > > > > > So you think I should remove the wine_todos already here? > > > > No, the source of the failures is still there. > > What do you mean with that? The tests indeed do succeed now and there is a > reason they do: when you call WaitCommEvent() while the tx buffer is not empty > yet the wine code will detect that EV_TXEMPTY correctly: The tests must pass under Wine without any additional "fixes" as they do currently under Windows. If you add some code to the tests which suddenly makes them pass under Wine - that's not a fix, Wine implementation should be fixed instead. -- Dmitry.

3 6

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack() (try 6)
by Alexandre Julliard 05 Sep '13

05 Sep '13

Ralf Habacker <ralf.habacker(a)freenet.de> writes: > +/****************************************************************** > + * test api function AllocateAndGetTcpExTableFromStack() > + * > + * Only specific tests required because the function is based > + * on build_tcp_table() which is covered by test_GetExtendedTcpTable() > + */ The tests are supposed to test the behavior on Windows. The details of the Wine implementation are irrelevant. You can't assume that the functions share an implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll/tests: Add tests for job objects.
by Alexandre Julliard 05 Sep '13

05 Sep '13

Andrew Cook <ariscop(a)gmail.com> writes: > diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in > index 10d6674..1903d10 100644 > --- a/dlls/ntdll/tests/Makefile.in > +++ b/dlls/ntdll/tests/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > file.c \ > generated.c \ > info.c \ > + job.c \ Please put this in an existing file, like om.c > +static DWORD getProcess(PHANDLE handle) { > + STARTUPINFO startup = {}; > + PROCESS_INFORMATION info = {}; > + > + if(!CreateProcessA(NULL, GetCommandLine(), NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info)) { > + ok(FALSE, "CreateProcess: %x\n", GetLastError()); > + return 0; > + } > + > + CloseHandle(info.hThread); > + *handle = info.hProcess; > + > + return info.dwProcessId; > +} You should use the existing winetest support for creating child processes. > + ok(TerminateProcess(hprocess[0], 1), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); > + ok(TerminateProcess(hprocess[1], 2), "TerminateProcess: %x\n", GetLastError()); > + Sleep(1000); Don't add sleeps when not necessary. > +static void is_zombie(void) > +{ > + WCHAR val[32] = {0}; > + static const WCHAR envName[] = { 'T','E','S','T',0 }; > + static const WCHAR envVal[] = { 'J','o','b','O','b','j','e','c','t',0 }; > + > + GetEnvironmentVariableW(envName, val, 32); > + > + if(lstrcmpW(envVal, val) == 0) > + /* Wait forever, we've been created for a process handle */ > + while(1) Sleep(INFINITE); > + > + SetEnvironmentVariableW(envName, envVal); > +} That's ugly. Again, check how child processes are handled in other tests. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: Cope with invalid protocols in WSAEnumProtocols
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> wrote: > +INT validprotocols[] = { WS_IPPROTO_TCP, > + WS_IPPROTO_UDP, > + NSPROTO_IPX, > + NSPROTO_SPX, > + NSPROTO_SPXII, > + 0 }; This should be 'static const'. -- Dmitry.

2 1

Re: [PATCH 5/5] ddraw: Enumerate DXT2 and DXT4
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Yes, we don't actually support those, but that's wined3d's problem, not > ddraw's. We do. The difference between DXT2/DXT3 and DXT4/DXT5 is just a convention wrt. storing pre-multiplied alpha or not, there's no difference in the actual encoding.

2 1

Re: [PATCH 5/5] kernel32/tests: remove several todos in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > - ok(!res && GetLastError() == ERROR_IO_PENDING, "%d: WaitCommEvent error %d\n", i, GetLastError()); > + ok(res || (!res && GetLastError() == ERROR_IO_PENDING), "%d: WaitCommEvent error %d\n", i, GetLastError()); This change looks spurious and unrelated. Also todos must be removed in the patch that fixes appropriate behaviour. -- Dmitry.

2 6

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Henri Verbeet 05 Sep '13

05 Sep '13

On 5 September 2013 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(DDSD->ddsCaps.dwCaps2 & DDSCAPS2_TEXTUREMANAGE) Minor formatting error here.

2 1

Re: [PATCH 3/5] ddraw/tests: Test DDCAPS2_TEXTUREMANAGE compatibility with other flags
by Marvin 05 Sep '13

05 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2016 Your paranoid android. === wxppro (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw7) === ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 2. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw7.c:3694: Test failed: Got unexpected, hr 0x80004002, case 4. ddraw7.c:3694: Test failed: Got unexpected, hr 0x88760233, case 8. === wxppro (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x8876014a, case 3. === wvista (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (32 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8. === w7pro64 (64 bit ddraw4) === ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 3. ddraw4.c:3880: Test failed: Got unexpected, hr 0x88760233, case 8.

1 0

Re: [PATCH 1/5] use a correct timeout in test_waittxempty
by Dmitry Timoshkov 05 Sep '13

05 Sep '13

Wolfgang Walter <wine(a)stwm.de> wrote: > When we send 17 bytes with 150 baud, no parity, one stop bit then > we need to wait at least 17*10/150 seconds > 1000 ms Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere. -- Dmitry.

2 3

Re: D3D command stream patches for testing
by Prot Secret 05 Sep '13

05 Sep '13

Hi, I am interested in your work, but after patching wine171 of this patch and enabled csmt, i have seen this in SC2 http://postimg.org/gallery/1w8y6jbg I use nvidia GTX 680 with proprietary i386 nvidia driver 319.49. Where I could be wrong, or what else can be set that would be normalized image using the patch? Thanks!

2 1

RE: D3D command stream patches for testing
by Vedran Rodic 04 Sep '13

04 Sep '13

Hello, I was not subscribed to wine-devel, so I can't reply to Stefan's mail directly, but here are some of my observations with Dota 2 on an Intel HD4000 GPU. Intel Mesa driver doesn't seem to like glBufferSubData in a way this patchset uses it. I get many many messages like these per frame when I enable INTEL_DEBUG=perf performance feedback of the Intel Mesa driver: Using a blit copy to avoid stalling on 588b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 480b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 1104b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 252b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 204b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 192b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. Using a blit copy to avoid stalling on 12b glBufferSubData() to a busy buffer object. I'm not sure how much this really impacts performance, but even with my Dota 2 wine perf hacks [1] it's not faster than current Wine git (performance is very similar). On what hardware did you test this patchset? [1]: http://vrodic.blogspot.com/2013/08/dota-2-wine-optimization-for-intel-gpus.…

2 1

Re: [PATCH 3/5] wined3d: Don't set WINED3DUSAGE_RENDERTARGET on the front buffer.
by Stefan Dösinger 04 Sep '13

04 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-04 08:56, schrieb Henri Verbeet: > We never render directly to the front buffer, and in case of e.g. a > P8 front buffer, we would fail surface creation if we were to > enforce format restrictions. This patch uncovers a problem I am not quite sure how to solve. We set the frontbuffer as render target in wined3d_device_init_3d if there's no backbuffer, i.e., when ddraw is used. In theory this doesn't matter because we're not rendering to it, just blitting. Similarly, dlls/ddraw/device.c calls set_render_target to set the ddraw frontbuffer on release. The call fails now, but that doesn't cause any visible problems yet. There is a zombie wined3d surface left, but it goes away on ddraw shutdown or when a new ddraw IDirect3DDevice is created. However, when we create wined3d textures for standalone surfaces, the ddraw surface isn't destroyed until the wined3d surface goes away because we're waiting for the callback. This keeps the ddraw surface alive as well. The ddraw tests notice this because keeping the IDirectDrawSurface alive means keeping an IDirect3DDevice1 alive as well. The device holds a reference to the attached viewport(s), which triggers a failure in the ddraw1 tests. The test failure was lingering before, I fixed this by adding a similar set_render_target call to ddraw_surface_release_iface_destroy. See the attached patches for reference. The easiest solution seems to create a separate dummy render target that ddraw can use to unset application targets. That still leaves the problem that we're initializing wined3d with an invalid render target now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJ6NiAAoJEN0/YqbEcdMwqEsP/3We5UyaUsuUmh8DuqpUDozy OPFdfg0defIGBB3xdcRPYtwz265jsThxK8ek/vb24E1fJXJsm7zE1CJq1jUh/Beo X1zkewvL29WpriNvh11AW0+FIrE2XMwmr/5ekHQMXM4Evv2aRWG6zmWj0Wv1zR+x EcFgHE7J6boOIHtogPoge8KHiVULjxm91Dpnariab0YzUNDUfaHUXopWH0N4hb3T W5ds4cnHLOapOk8ihDfyAcBXOH4JlvConKKG4zDtbcuovp01yLR+eF03m/eBqt5m 0x3VpPyyaIJpFtOERAi9CqbN0Xuy3wOLmtgHsjy8Qh1wKr/I+DmkuakcsJYELmrY Ou7n+fDRceJyxdqP8vGtwlsP7Skkyxet/KYt7xbWsMcIcMjFDv6KW6YMyOGg2aJM O4o8gEFH3zgBQqLBsOf+O85GbQ2ZTLFoRaWkbRYFYYBaypd+S4TBRn9i0gL0Qw/q KImvYV47HcBK0uTuuV0dG/2YzUs/JraKGMU0sVmUNiDqfOm7+R+NAlU86jQ4PNo+ G0cV2IpEt9Bk/06XmSWI944X7NTe/ZDXs8Fa5MveLk87wETzg54F3RK2AoyHPY59 UK/3nisrRmUDeRZHiRp53E6eSW7VSXoHUgqeHt04fvLheMXpAnuibKJcKGTYqYMe kfkNuq73chpb9uZhe0EJ =PCrO -----END PGP SIGNATURE-----

2 1

Re: oledb32: Implement IDataSourceLocator get/put hWnd
by Alexandre Julliard 04 Sep '13

04 Sep '13

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > > > Changelog: > oledb32: Implement IDataSourceLocator get/put hWnd It doesn't work here: ../../../tools/runtest -q -P wine -M oledb32.dll -T ../../.. -p oledb32_test.exe.so database.c && touch database.ok database.c:252: Test failed: got 80040154 make[1]: *** [database.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] wined3d: Fix per-stage constant in GLSL fixed function pipeline + add tests. (try 2)
by Matteo Bruni 04 Sep '13

04 Sep '13

2013/9/4 Christian Costa <titan.costa(a)gmail.com>: > This patch fixes part of bug 33606 and 31918. > > The current code generates shaders that support per-stage constant but does not declare the variables used causing thus compilation failures. > With this patch, these variables are declared and updated when needed. Tests are also added. > > Thanks to Matteo Bruni for review and support. > > Try 2: > - update with latest git Hi, I have a few small nits still, please bear with me... > --- > dlls/d3d9/tests/visual.c | 80 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/wined3d/glsl_shader.c | 34 ++++++++++++++++++- > 2 files changed, 112 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c > index b856c93..6072c23 100644 > --- a/dlls/d3d9/tests/visual.c > +++ b/dlls/d3d9/tests/visual.c > @@ -10742,6 +10742,85 @@ static void dp3_alpha_test(IDirect3DDevice9 *device) { > ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > } > > +static void perstage_constant_test(IDirect3DDevice9 *device) > +{ > + HRESULT hr; > + D3DCAPS9 caps; > + DWORD color; > + struct vertex quad[] = { > + { -1.0, -1.0, 0.1, 0x408080c0 }, > + { 1.0, -1.0, 0.1, 0x408080c0 }, > + { -1.0, 1.0, 0.1, 0x408080c0 }, > + { 1.0, 1.0, 0.1, 0x408080c0 }, > + }; > + Can you please make quad[] static const? Also, add the 'f' suffix to the float constants and move the opening brace to newline. > + memset(&caps, 0, sizeof(caps)); > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); > + ok(SUCCEEDED(hr), "GetDeviceCaps failed with 0x%08x\n", hr); > + if (!(caps.PrimitiveMiscCaps & D3DPMISCCAPS_PERSTAGECONSTANT)) > + { > + skip("D3DPMISCCAPS_PERSTAGECONSTANT not supported\n"); Please put a '.' at the end of the message. Same for the following prints. > + return; > + } > + > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | D3DFVF_DIFFUSE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetFVF failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_CONSTANT, 0x80a1b2c3); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + > + /* Check color values */ > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_CONSTANT); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + Although you don't strictly need it here, I'd explicitly set D3DTSS_COLOROP for stage 1 to D3DTOP_DISABLE. Also maybe set D3DTSS_ALPHAOP for stage 0 to disabled? > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); > + ok(hr == D3D_OK, "IDirect3DDevice9_Clear failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_BeginScene failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "DrawPrimitiveUP failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed with 0x%08x\n", hr); > + > + color = getPixelColor(device, 320, 240); > + ok(color_match(color, 0x00a1b2c3, 4), "perstage constant test 0x%08x, expected 0x00a1b2c3\n", color); > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_Present failed with 0x%08x\n", hr); > + > + /* Check alpha value */ > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_CONSTANT | D3DTA_ALPHAREPLICATE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAARG1, D3DTA_CONSTANT); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); > + ok(hr == D3D_OK, "IDirect3DDevice9_Clear failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_BeginScene failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "DrawPrimitiveUP failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed with 0x%08x\n", hr); > + > + color = getPixelColor(device, 320, 240); > + ok(color_match(color, 0x00808080, 4), "perstage constant test 0x%08x, expected 0x00808080\n", color); > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_Present failed with 0x%08x\n", hr); > + > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_DISABLE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); > + hr = IDirect3DDevice9_SetTextureStageState(device, 0, D3DTSS_ALPHAOP, D3DTOP_DISABLE); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetTextureStageState failed with 0x%08x\n", hr); I'd move those to the test which actually requires it (which is depth_buffer2_test IIUC). It could be a separate patch. The other option would be to move this new test out of the way (e.g. by executing it next to resz_test(), thus using a separate device). I don't have a strong opinion in that regard though. > +} > + > static void zwriteenable_test(IDirect3DDevice9 *device) { > HRESULT hr; > DWORD color; > @@ -14811,6 +14890,7 @@ START_TEST(visual) > texop_range_test(device_ptr); > alphareplicate_test(device_ptr); > dp3_alpha_test(device_ptr); > + perstage_constant_test(device_ptr); > depth_buffer_test(device_ptr); > depth_buffer2_test(device_ptr); > depth_blit_test(device_ptr); > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 740e100..2b8041a 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -132,6 +132,7 @@ struct glsl_ps_program > GLint bumpenv_mat_location[MAX_TEXTURES]; > GLint bumpenv_lum_scale_location[MAX_TEXTURES]; > GLint bumpenv_lum_offset_location[MAX_TEXTURES]; > + GLint const_location[MAX_TEXTURES]; > GLint tex_factor_location; > GLint specular_enable_location; > GLint ycorrection_location; > @@ -918,6 +919,15 @@ static void shader_glsl_load_constants(void *shader_priv, struct wined3d_context > else > GL_EXTCALL(glUniform4fARB(prog->ps.specular_enable_location, 0.0f, 0.0f, 0.0f, 0.0f)); > > + for (i = 0; i < MAX_TEXTURES; ++i) > + { > + if (prog->ps.const_location[i] != -1) > + { > + D3DCOLORTOGLFLOAT4(state->texture_states[i][WINED3D_TSS_CONSTANT], col); > + GL_EXTCALL(glUniform4fARB(prog->ps.const_location[i], col[0], col[1], col[2], col[3])); > + } > + } > + > checkGLcall("fixed function uniforms"); > } > Like I already mentioned privately, this could have its own WINED3D_SHADER_CONST_* flag but I'm not sure it would be worth it. Comments? > @@ -5167,7 +5177,6 @@ static const char *shader_glsl_get_ffp_fragment_op_arg(struct wined3d_shader_buf > break; > > case WINED3DTA_CONSTANT: > - FIXME("Per-stage constants not implemented.\n"); > switch (stage) > { > case 0: ret = "const0"; break; > @@ -5447,6 +5456,16 @@ static GLuint shader_glsl_generate_ffp_fragment_shader(struct wined3d_shader_buf > > for (stage = 0; stage < MAX_TEXTURES; ++stage) > { > + if ((settings->op[stage].carg0 == WINED3DTA_CONSTANT) > + || (settings->op[stage].carg1 == WINED3DTA_CONSTANT) > + || (settings->op[stage].carg2 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg0 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg1 == WINED3DTA_CONSTANT) > + || (settings->op[stage].aarg2 == WINED3DTA_CONSTANT)) > + { > + shader_addline(buffer, "uniform vec4 const%d;", stage); > + } > + > if (!(tex_map & (1 << stage))) > continue; > > @@ -5803,6 +5822,8 @@ static void shader_glsl_init_ps_uniform_locations(const struct wined3d_gl_info * > ps->bumpenv_lum_scale_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > snprintf(name, sizeof(name), "bumpenv_lum_offset%u", i); > ps->bumpenv_lum_offset_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > + snprintf(name, sizeof(name), "const%u", i); > + ps->const_location[i] = GL_EXTCALL(glGetUniformLocationARB(program_id, name)); > } > > ps->tex_factor_location = GL_EXTCALL(glGetUniformLocationARB(program_id, "tex_factor")); > @@ -7106,7 +7127,8 @@ static void glsl_fragment_pipe_get_caps(const struct wined3d_gl_info *gl_info, s > { > caps->wined3d_caps = WINED3D_FRAGMENT_CAP_PROJ_CONTROL > | WINED3D_FRAGMENT_CAP_SRGB_WRITE; > - caps->PrimitiveMiscCaps = WINED3DPMISCCAPS_TSSARGTEMP; > + caps->PrimitiveMiscCaps = WINED3DPMISCCAPS_TSSARGTEMP > + | WINED3DPMISCCAPS_PERSTAGECONSTANT; > caps->TextureOpCaps = WINED3DTEXOPCAPS_DISABLE > | WINED3DTEXOPCAPS_SELECTARG1 > | WINED3DTEXOPCAPS_SELECTARG2 > @@ -7251,6 +7273,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(0, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(0, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(0, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(0, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(0, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7260,6 +7283,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(1, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(1, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(1, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(1, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7269,6 +7293,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(2, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(2, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(2, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(2, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7278,6 +7303,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(3, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(3, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(3, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(3, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7287,6 +7313,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(4, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(4, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(4, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(4, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7296,6 +7323,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(5, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(5, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(5, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(5, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7305,6 +7333,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(6, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(6, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(6, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(6, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_OP), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_ARG1), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_COLOR_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > @@ -7314,6 +7343,7 @@ static const struct StateEntryTemplate glsl_fragment_pipe_state_template[] = > {STATE_TEXTURESTAGE(7, WINED3D_TSS_ALPHA_ARG2), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_ALPHA_ARG0), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > {STATE_TEXTURESTAGE(7, WINED3D_TSS_RESULT_ARG), {STATE_PIXELSHADER, NULL }, WINED3D_GL_EXT_NONE }, > + {STATE_TEXTURESTAGE(7, WINED3D_TSS_CONSTANT), {STATE_TEXTURESTAGE(7, WINED3D_TSS_CONSTANT), glsl_fragment_pipe_invalidate_constants}, WINED3D_GL_EXT_NONE }, > {STATE_PIXELSHADER, {STATE_PIXELSHADER, glsl_fragment_pipe_shader }, WINED3D_GL_EXT_NONE }, > {STATE_RENDER(WINED3D_RS_FOGENABLE), {STATE_RENDER(WINED3D_RS_FOGENABLE), glsl_fragment_pipe_fog }, WINED3D_GL_EXT_NONE }, > {STATE_RENDER(WINED3D_RS_FOGTABLEMODE), {STATE_RENDER(WINED3D_RS_FOGENABLE), NULL }, WINED3D_GL_EXT_NONE }, > > > Cheers, Matteo.

1 0

Re: 0001-Fix-race-for-IOCTL_SERIAL_WAIT_ON_MASK.patch
by Alexandre Julliard 04 Sep '13

04 Sep '13

Wolfgang Walter <wine(a)stwm.de> writes: > @@ -1265,8 +1265,12 @@ static inline NTSTATUS io_control(HANDLE hDevice, > case IOCTL_SERIAL_WAIT_ON_MASK: > if (lpOutBuffer && nOutBufferSize == sizeof(DWORD)) > { > + piosb->u.Status = STATUS_PENDING; > + piosb->Information = 0; > if (!(status = wait_on(hDevice, fd, hEvent, piosb, lpOutBuffer))) > sz = sizeof(DWORD); > + else if (status == STATUS_PENDING) > + return status; Status is not supposed to be set until the operation is done. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] rpcrt4: Clear the connection pool when closing an http connection.
by Jacek Caban 04 Sep '13

04 Sep '13

On 09/04/13 15:01, Hans Leidekker wrote: > --- > dlls/rpcrt4/rpc_transport.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c > index d0857fa..1eb0151 100644 > --- a/dlls/rpcrt4/rpc_transport.c > +++ b/dlls/rpcrt4/rpc_transport.c > @@ -3234,6 +3234,8 @@ static int rpcrt4_ncacn_http_close(RpcConnection *Connection) > HeapFree(GetProcessHeap(), 0, httpc->servername); > httpc->servername = NULL; > > + /* don't allow this connection to be reused */ > + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0); There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start... Jacek

2 3

Re: [3/6] ntdll: NtWriteFile should fail for overlapped IO on files if offset is negative.
by Alexandre Julliard 04 Sep '13

04 Sep '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c > index cde299c..c802432 100644 > --- a/dlls/ntdll/tests/file.c > +++ b/dlls/ntdll/tests/file.c > @@ -2124,11 +2124,8 @@ todo_wine > iob.Information = -1; > offset.QuadPart = (LONGLONG)-2 /* FILE_USE_FILE_POINTER_POSITION */; > status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents, sizeof(contents), &offset, NULL); > -todo_wine > ok(status == STATUS_INVALID_PARAMETER, "expected STATUS_INVALID_PARAMETER, got %#x\n", status); > -todo_wine > ok(iob.Status == -1, "expected -1, got %#x\n", iob.Status); > -todo_wine > ok(iob.Information == -1, "expected -1, got %ld\n", iob.Information); A test for a non-magic negative value would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] opencl/tests: Add initial tests
by Marvin 04 Sep '13

04 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2003 Your paranoid android. === build (build) === Unable to regenerate dlls/opencl/Makefile Recreation of tests/Makefile failed

1 0

Re: wininet: Don't start the next chunk if the read is satisfied.
by Jacek Caban 04 Sep '13

04 Sep '13

Hi Hans, On 09/04/13 09:22, Hans Leidekker wrote: > --- > dlls/wininet/http.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 1832b4f..521e4aa 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -2795,7 +2795,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream_t *chunked_stream = (chunked_stream_t*)stream; > DWORD read_bytes = 0, ret_read = 0, res = ERROR_SUCCESS; > > - if(chunked_stream->chunk_size == ~0u) { > + if(!chunked_stream->chunk_size || chunked_stream->chunk_size == ~0u) { > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) > return res; > @@ -2835,7 +2835,7 @@ static DWORD chunked_read(data_stream_t *stream, http_request_t *req, BYTE *buf, > chunked_stream->chunk_size -= read_bytes; > size -= read_bytes; > ret_read += read_bytes; > - if(!chunked_stream->chunk_size) { > + if(size && !chunked_stream->chunk_size) { > assert(read_mode != READMODE_NOBLOCK); > res = start_next_chunk(chunked_stream, req); > if(res != ERROR_SUCCESS) This patch breaks two assumptions: - chunk_size outside chunked_read means the end of the stream - READMODE_SYNC should read as much data as possible There is longer story about the way it's implemented the way it is. Native IE in the past considered zero-length reporting data in INTERNET_STATUS_REQUEST_COMPLETE to be an error. If you stop reading in the end of chunk and the next chunk is the last one, then you will send such report asynchronously. That's why we read the whole chunk only if we can start reading the next one (and we can't if we don't want to block). Now I think that the failure could possibly be caused by a combination of returning zero size and some other bug and the behaviour that I described could just hide the problem. Commit 851866e22a731141da7e3cbd2550c67c59968959 fixed a problem that could potentially be the other one. This means that I'm not entirely sure that we really shouldn't report zero size data. This is illogical to begin with, but we even have tests for that: ok(!on_async, "Returned zero size in response to request complete\n"); I think we should try harder to have a test reporting zero size data (this may be tricky to write one for Wine tests, but if we could just observe such occasional notifications, that would be enough). And this would need more testing with native IE. This all means that intention of the patch may be right, but it needs more work. Thanks, Jacek

2 2

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Bruno Jesus 04 Sep '13

04 Sep '13

On Wed, Sep 4, 2013 at 8:02 AM, Ralf Habacker <ralf.habacker(a)freenet.de> wrote: > > - added test case (update) > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > dlls/iphlpapi/iphlpapi.spec | 1 + > dlls/iphlpapi/ipstats.c | 33 +++++++++++++++++++++++++++++++++ > dlls/iphlpapi/tests/iphlpapi.c | 32 ++++++++++++++++++++++++++++++++ > 3 Dateien geändert, 66 Zeilen hinzugefügt(+) > + // WinXP SP3 crashes on this test > + //ret = pAllocateAndGetTcpExTableFromStack( 0, FALSE, GetProcessHeap(), HEAP_ZERO_MEMORY, AF_INET ); > + //ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); C++ comments are not allowed. You could use if(0) {} to make sure the code compiles. You are still missing the (try X) at the end of the email subject. Regards, Bruno

1 0

Re: atl90: Add new DLL
by Zhenbo Li 04 Sep '13

04 Sep '13

Sorry, I've made a typo. This patch is for bug 34432 2013/9/4 Zhenbo Li <litimetal(a)gmail.com> > This patch could fix bug 34431, which is caused by missing atl90.dll > > --- > configure | 1 + > configure.ac | 1 + > dlls/atl90/Makefile.in | 7 ++++ > dlls/atl90/atl90.c | 93 ++++++++++++++++++++++++++++++** > ++++++++++++++++++++ > dlls/atl90/atl90.spec | 52 ++++++++++++++++++++++++++++ > include/atlbase.h | 1 + > tools/make_specfiles | 1 + > 7 files changed, 156 insertions(+) > -- Have a nice day! Zhenbo Li

1 0

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack()
by Marvin 04 Sep '13

04 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1995 Your paranoid android. === wxppro (32 bit iphlpapi) === iphlpapi: unhandled exception c0000005 at 76D6EFE7

1 0

Re: [PATCH 1/3] riched20: Use codepage in ME_ToUnicode.
by Phil Krylov 04 Sep '13

04 Sep '13

Hello, >- ME_EndToUnicode(unicode, wszText); >+ unicode ? ME_EndToUnicode(1200, wszText) : ME_EndToUnicode(CP_ACP, wszText); Personally I dislike this stuff in C code. Especially when you could make it shorter: ME_EndToUnicode(unicode ? 1200 : CP_ACP, wszText) -- Ph.

2 1

Adding an appcompat/appshim bugzilla keyword
by Austin English 04 Sep '13

04 Sep '13

Anastasius mentioned at http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for bugs that are caused by applications using broken/deprecated behavior might be useful. I'm in favor of it, but wanted some more opinions (and potentially a better naming scheme). Comments/opinions? -- -Austin

2 1

Re: [PATCH 2/5] d3d9: Check for support before creating textures
by Henri Verbeet 03 Sep '13

03 Sep '13

On 3 September 2013 14:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm checking this in d3d9/d3d8/ddraw because we create textures for > everything nowadays, even stand-alone surfaces. For ddraw that's not true yet, but I think my preferred way to handle this would be to introduce a WINED3DUSAGE_TEXTURE usage flag, and then handle the format restrictions in resource_init() in wined3d. Note that I have a couple of patches for enforcing render target and depth stencil format restrictions for bug 34284 that should go in later this week. It may be best to hold this of until after that's in.

2 3

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
by Alexandre Julliard 03 Sep '13

03 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > Narrow the loop for the specified protocol > Add a new test for invalid sockets Considering what WSAEnumProtocols does, the loop doesn't seem necessary at all. -- Alexandre Julliard julliard(a)winehq.org

3 8

D3D command stream patches for testing
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In the past months I have been working on a command stream / worker thread for wined3d. It moves most OpenGL calls into a separate thread to improve performance (bug 11674) and fix some bugs that are otherwise hard to fix (24684). You can test the attached patches by applying them (git am /path/to/patches/*) and setting HKCU/Software/Wine/Direct3D/CSMT = "enabled". Make sure to disable StrictDrawOrdering. It is no longer required with those patches and will destroy any performance gains. (It might be useful for debugging though). The patches apply on top of Wine 1.7.1. Please test those patches with your games. I'm interested in any successes or failures and performance differences. Performance numbers with plain Wine 1.7.1, this patchset with CSMT off and on, and Wine 1.7.7 + bugzilla attachment 44420 and __GL_THREADED_OPTIMIZATIONS would be greatly appreciated. A notes for non-developers: *) GPU limited games don't see any improvement. If you're GPU limited heavilly depends on your hardware *) So far I have not tested anything but Nvidia hardware. It should work on all GPUs and drivers though. *) Yes, this is essentially the same as Nvidia's __GL_THREADED_OPTIMIZATIONS. Just driver independent, under our control, and thus easier to fix bugs. *) A lot of games see 50%-100% performance improvements and now run as fast as on Windows or even faster. Examples are Source-Engine based games, StarCraft 2, 3DMark 2001. *) Call of Duty Modern Warfare 2 is improved a lot because you no longer need StrictDrawOrdering. It's still not as good as it could be, because it uses dynamic surfaces, which aren't properly implemented in the patchset yet. *) Some games have CPU-side bottlenecks outside d3d. Mass Effect 2 seems to be one of those. *) Some games have CPU-side bottlenecks in the GL driver, and comparably little game logic on their own. I think this applies to Civ V, which doesn't see much improvement with those patches. Some implementation notes: *) One of the big design decisions is to do all OpenGL calls from one thread, including resource creation and buffer maps. This is faster than using glFlush calls to synchronize anything we do from the main thread, and easier than trying to sync everything in a performant fashion with ARB_sync. This means I need the priority command queue. This is not yet fully implemented though, so you see GL calls from the main thread as well. *) There seem to be driver bugs when calling into GL from two threads, even though those are two different contexts. Remember, we don't have the GL lock any longer. *) The other controversial design decision is that the command stream does not hold any references to objects stored in pending commands or its own state structure. This prevents the client libraries and applications from "seeing" the CS via delayed destruction of objects and freeing of application private data. *) Currently resource destruction waits for the CS to execute all pending commands. The goal is to handle private resources and removal from the device's resource list in the main thread and freeing of GL resources, freeing of resource->heap_memory and freeing of the main structure in the worker thread. *) A big issue that needs fixing is that there isn't a clear separation between functions that are called from the main thread and functions that are called from the worker thread. The plan is to introduce comments similar to those that clarify who is responsible for context activation. *) Buffers are double-buffered and use glBufferSubData when the multithreaded CS is in use. This is necessary because we can't draw from a mapped buffer. In the long run GL_ARB_buffer_storage should be able to fix this. *) You can roughly see how surface and volume handling is going to work in the volume code. I am not entirely happy with the code yet, I hacked it together in the past few days... *) The plan behind wined3d_device_get_bo and wined3d_device_release_bo is to cache created GL BOs. Before I do that I have to write a benchmark for dynamic volumes to verify that this is really a performance improvement. *) Before this can be merged, surfaces need a cleanup similar to volumes. It's going to be a lot trickier though. *) The tests should run with the single-threaded and multi-threaded command stream. *) There should not be any temporary regressions with the single-threaded CS. If something's broken, git bisect should work with CSMT off. *) With CSMT on, there are a few known regressions and test failures. The d3d9 and ddraw tests fail between patch 18 and 71. Occlusion queries are broken between 22 and 108. In general nothing's working right between 80 and 99. Some of those problems can be fixed or their impact reduced, but I will not be able to completely avoid them. The ddraw test failure is a driver bug and GL occlusion queries break by design when used from a different thread. So if you try to bisect a regression in this patch series with CSMT on YMMV. *) This work was originally started by Henri. Some patches in the series are from him and either unmodified or with minor adjustments. Some patches are based on his work, but with heavy modifications. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJJjDAAoJEN0/YqbEcdMw1VMP/i4OvTg/HT+jJhZFDzbmtB8o aHIFslhkH9CJDCTGzZExGnPoM+0gLokzzk6ppodQiyC0bJ4jLzeulIhfaUs0sgxy srWpryXYfpeoG/A/MJQlbUQEiMpqdKLvM1j3UupjMY2IsGbECronAYdUi0PTh0Oo RqlWQ64bTARpFXtywO22goNfi57e3UKf2r8Q3Q4f20eH0CwvvVC1YU/sAZ2iyvbR c0fcfergDsPSRQsw+EgEwD4N11/Z+At2XfTeXMC9MyHlZR7bfJfOYMiu6AXfy9gB uFKLgNrXXJho5UsPLjcsCw+UczR98dsyX7B5BZOfG9eyn1Du5YAAVEZ7QCHvUbLj 0WMR86q4GiCZVd5q7GZ7YH3wdNE3R1kEMQA3JRHTP7jLPpSfODUlTxP5NDk220OI +fiPSr5a0BpLqua+dNRjAQvW1Qhrk+7EgLqfwrq8632x/6sInSTnlE84UQ4FJiH6 Wql7PxPPfOJv2qG6l1nqffT7fCbiEHnemoF/4GEvG22MZbMXYTnpkLC6Y1aLUJN5 WXxAICXcy7S2dk5Io/t1IKUm4fwtWnI59MX5rPbfDpY3GGePnlo40pNLlGVv8lc8 ktDS4dvf1Lx/JKrLzu1G/1TYBePFHEVQRvJjzCw0YhNOW7sUOLbf5rgHmAeyOxvD Zdq+l22uJ1Se8m9iAbtF =lm4e -----END PGP SIGNATURE-----

2 3

Re: [PATCH 1/5] d3d8/tests: Add cnd instruction test.
by Henri Verbeet 03 Sep '13

03 Sep '13

On 2 September 2013 23:04, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + float quad1[] = { > + -1.0, -1.0, 0.1, 0.0, 0.0, 1.0, > + 0.0, -1.0, 0.1, 1.0, 0.0, 1.0, > + -1.0, 0.0, 0.1, 0.0, 1.0, 0.0, > + 0.0, 0.0, 0.1, 1.0, 1.0, 0.0 > + }; I think that should be static const, and could do with an 'f' suffix on the literals. > + ok(hr == D3D_OK, "IDirect3DDevice8_BeginScene returned %08x\n", hr); > + if(SUCCEEDED(hr)) > + { I think the if block is pointless. > + /* 1.1 shader. All 3 components get set, based on the .w comparison */ > + color = getPixelColor(device, 158, 358); > + ok(color == 0x00ffffff, "pixel 158, 358 has color %08x, expected 0x00ffffff\n", color); > + color = getPixelColor(device, 162, 358); > + ok( (((color & 0x00ff0000) >> 16) <= 0x01) && (((color & 0x0000ff00) >> 8) <= 0x01) && ((color & 0x000000ff) <= 0x01), > + "pixel 162, 358 has color %08x, expected 0x00000000\n", color); I think that should use color_match(). I realize those are all present in the original test, but that's more of a reason to fix the original instead of copying it.

2 1

Re: [PATCH 4/5] d3d9/tests: Test blocked texture creation restrictions
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fwiw, d3d8, ddraw and volumes behave in the same way. I've attached the tests for reference. The volume and ddraw tests need a bit of preparation work in ddraw/wined3d and a little bit of work themselves. Am 2013-09-03 14:07, schrieb Stefan Dösinger: > --- dlls/d3d9/tests/device.c | 225 > +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, > 210 insertions(+), 15 deletions(-) > > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index d705e3e..af39ffa 100644 --- a/dlls/d3d9/tests/device.c +++ > b/dlls/d3d9/tests/device.c @@ -5815,7 +5815,7 @@ static void > test_surface_double_unlock(void) DestroyWindow(window); } > > -static void test_surface_lockrect_blocks(void) +static void > test_surface_blocks(void) { static const struct { @@ -5824,20 > +5824,21 @@ static void test_surface_lockrect_blocks(void) > unsigned int block_width; unsigned int block_height; BOOL broken; > + BOOL create_size_checked, core_fmt; } formats[] = { - > {D3DFMT_DXT1, "D3DFMT_DXT1", 4, 4, FALSE}, - > {D3DFMT_DXT2, "D3DFMT_DXT2", 4, 4, FALSE}, - > {D3DFMT_DXT3, "D3DFMT_DXT3", 4, 4, FALSE}, - > {D3DFMT_DXT4, "D3DFMT_DXT4", 4, 4, FALSE}, - > {D3DFMT_DXT5, "D3DFMT_DXT5", 4, 4, FALSE}, + > {D3DFMT_DXT1, "D3DFMT_DXT1", 4, 4, FALSE, TRUE, > TRUE }, + {D3DFMT_DXT2, "D3DFMT_DXT2", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT3, "D3DFMT_DXT3", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT4, "D3DFMT_DXT4", 4, > 4, FALSE, TRUE, TRUE }, + {D3DFMT_DXT5, "D3DFMT_DXT5", 4, > 4, FALSE, TRUE, TRUE }, /* ATI2N has 2x2 blocks on all AMD cards > and Geforce 7 cards, * which doesn't match the format spec. On > newer Nvidia cards * it has the correct 4x4 block size */ - > {MAKEFOURCC('A','T','I','2'), "ATI2N", 4, 4, TRUE}, - > {D3DFMT_YUY2, "D3DFMT_YUY2", 2, 1, FALSE}, - > {D3DFMT_UYVY, "D3DFMT_UYVY", 2, 1, FALSE}, + > {MAKEFOURCC('A','T','I','2'), "ATI2N", 4, 4, TRUE, FALSE, > FALSE}, + {D3DFMT_YUY2, "D3DFMT_YUY2", 2, 1, FALSE, FALSE, > TRUE }, + {D3DFMT_UYVY, "D3DFMT_UYVY", 2, 1, FALSE, FALSE, > TRUE }, }; static const struct { @@ -5854,17 +5855,45 @@ static > void test_surface_lockrect_blocks(void) {D3DPOOL_SYSTEMMEM, > "D3DPOOL_SYSTEMMEM",TRUE}, {D3DPOOL_MANAGED, "D3DPOOL_MANAGED", > TRUE}, }; + static struct + { + D3DRESOURCETYPE rtype; + > const char *type_name; + D3DPOOL pool; + const char > *pool_name; + BOOL need_driver_support, > need_runtime_support; + } + create_tests[] = + { + > {D3DRTYPE_SURFACE, "D3DRTYPE_SURFACE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_SURFACE, > "D3DRTYPE_SURFACE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", TRUE, > TRUE }, + /* Managed offscreen plain surfaces are not > supported */ + {D3DRTYPE_SURFACE, "D3DRTYPE_SURFACE", > D3DPOOL_SCRATCH, "D3DPOOL_SCRATCH", FALSE, TRUE }, + + > {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_TEXTURE, > "D3DRTYPE_TEXTURE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", TRUE, > FALSE}, + {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", > D3DPOOL_MANAGED, "D3DPOOL_MANAGED", TRUE, FALSE}, + > {D3DRTYPE_TEXTURE, "D3DRTYPE_TEXTURE", D3DPOOL_SCRATCH, > "D3DPOOL_SCRATCH", FALSE, TRUE }, + + > {D3DRTYPE_CUBETEXTURE, "D3DRTYPE_CUBETEXTURE", D3DPOOL_DEFAULT, > "D3DPOOL_DEFAULT", TRUE, FALSE}, + {D3DRTYPE_CUBETEXTURE, > "D3DRTYPE_CUBETEXTURE", D3DPOOL_SYSTEMMEM, "D3DPOOL_SYSTEMMEM", > TRUE, FALSE}, + {D3DRTYPE_CUBETEXTURE, > "D3DRTYPE_CUBETEXTURE", D3DPOOL_MANAGED, "D3DPOOL_MANAGED", TRUE, > FALSE}, + {D3DRTYPE_CUBETEXTURE, "D3DRTYPE_CUBETEXTURE", > D3DPOOL_SCRATCH, "D3DPOOL_SCRATCH", FALSE, TRUE }, + }; > IDirect3DTexture9 *texture; + IDirect3DCubeTexture9 *cube_texture; > IDirect3DSurface9 *surface; D3DLOCKED_RECT locked_rect; > IDirect3DDevice9 *device; - unsigned int i, j; + unsigned int > i, j, w, h; BOOL surface_only; IDirect3D9 *d3d; ULONG refcount; > HWND window; HRESULT hr; RECT rect; + BOOL tex_pow2, cube_pow2; > + D3DCAPS9 caps; > > if (!(d3d = pDirect3DCreate9(D3D_SDK_VERSION))) { @@ -5882,14 > +5911,142 @@ static void test_surface_lockrect_blocks(void) return; > } > > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); + > ok(SUCCEEDED(hr), "Failed to get caps, hr %#x.\n", hr); + tex_pow2 > = !!(caps.TextureCaps & D3DPTEXTURECAPS_POW2); + if (tex_pow2) + > tex_pow2 = !(caps.TextureCaps & > D3DPTEXTURECAPS_NONPOW2CONDITIONAL); + cube_pow2 = > !!(caps.TextureCaps & D3DPTEXTURECAPS_CUBEMAP_POW2); + for (i = 0; > i < (sizeof(formats) / sizeof(*formats)); ++i) { + BOOL > tex_support, cube_support, surface_support, format_known, > dynamic_tex_support; + + hr = > IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_TEXTURE, > formats[i].fmt); + tex_support = SUCCEEDED(hr); + hr > = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_CUBETEXTURE, > formats[i].fmt); + cube_support = SUCCEEDED(hr); + > hr = IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + 0, D3DRTYPE_SURFACE, > formats[i].fmt); + surface_support = SUCCEEDED(hr); + + /* > Scratch pool in general allows texture creation even if the driver > does + * not support the format. If the format is an > extension format that is not + * known to the runtime, > like ATI2N, some driver support is required for + * this > to work. + * + * It is also possible that Windows > Vista and Windows 7 d3d9 runtimes know + * about ATI2N. I > cannot check this because all my Vista+ machines support + * ATI2N > in hardware, but none of my WinXP machines do. */ + format_known = > tex_support || cube_support || surface_support; + + for (w = 1; w > <= 8; w++) + { + for (h = 1; h <= 8; h++) + > { + BOOL block_aligned = TRUE; + BOOL > size_is_pow2; + + if (w & (formats[i].block_width - > 1) || h & (formats[i].block_height - 1)) + > block_aligned = FALSE; + + size_is_pow2 = !(w & (w - 1) || h & (h - > 1)); + + for (j = 0; j < sizeof(create_tests) / > sizeof(*create_tests); j++) + { + > BOOL support, pow2; + HRESULT expect_hr; + BOOL > may_succeed = FALSE; + IUnknown **check_null; + + > if (!formats[i].core_fmt) + { + /* AMD warns > against creating ATI2N textures smaller than + * the block size > because the runtime cannot calculate the + * correct texture size. > Generalize this for all extension + * formats. */ + > if (w < formats[i].block_width || h < formats[i].block_height) + > continue; + } + + texture = > (IDirect3DTexture9 *)0xdeadbeef; + cube_texture > = (IDirect3DCubeTexture9 *)0xdeadbeef; + > surface = (IDirect3DSurface9 *)0xdeadbeef; + + > switch (create_tests[j].rtype) + { + case > D3DRTYPE_TEXTURE: + check_null = > (IUnknown **)&texture; + hr = > IDirect3DDevice9_CreateTexture(device, w, h, 1, 0, + > formats[i].fmt, create_tests[j].pool, &texture, NULL); + support = > tex_support; + pow2 = tex_pow2; + > break; + + case D3DRTYPE_CUBETEXTURE: + > if (w != h) + continue; + check_null > = (IUnknown **)&cube_texture; + hr = > IDirect3DDevice9_CreateCubeTexture(device, w, 1, 0, + > formats[i].fmt, create_tests[j].pool, &cube_texture, NULL); + > support = cube_support; + pow2 = > cube_pow2; + break; + + case > D3DRTYPE_SURFACE: + check_null = > (IUnknown **)&surface; + hr = > IDirect3DDevice9_CreateOffscreenPlainSurface(device, w, h, + > formats[i].fmt, create_tests[j].pool, &surface, NULL); + support = > surface_support; + pow2 = FALSE; + > break; + + default: + check_null = NULL; > + pow2 = FALSE; + support = FALSE; + > break; + } + + if > (create_tests[j].need_driver_support && !support) + expect_hr = > D3DERR_INVALIDCALL; + else if > (create_tests[j].need_runtime_support && !formats[i].core_fmt && > !format_known) + expect_hr = > D3DERR_INVALIDCALL; + else if > (formats[i].create_size_checked && !block_aligned) + expect_hr = > D3DERR_INVALIDCALL; + else if (pow2 && > !size_is_pow2 && create_tests[j].need_driver_support) + expect_hr = > D3DERR_INVALIDCALL; + else + expect_hr = D3D_OK; > + + /* Wine knows about ATI2N and happily > creates a scratch resource even if GL + * does not support it. > Accept scratch creation of extension formats on + > * Windows as well if it occurs. We don't really care if e.g. a > Windows 7 + * on an r200 GPU creates scratch > ATI2N texture even though the card doesn't + * support it. */ + > if (!formats[i].core_fmt && !format_known && FAILED(expect_hr)) + > may_succeed = TRUE; + + ok(hr == expect_hr || > ((SUCCEEDED(hr) && may_succeed)), + > "Got unexpected hr %#x for format %s, pool %s, type %s, size > %ux%u.\n", + hr, formats[i].name, > create_tests[j].pool_name, create_tests[j].type_name, w, h); + if > (FAILED(hr)) + ok(*check_null == NULL, "Got > object ptr %p, expected NULL.\n", *check_null); + else + > IUnknown_Release(*check_null); + } + } + } + > surface_only = FALSE; - if > (FAILED(IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, - D3DUSAGE_DYNAMIC, > D3DRTYPE_TEXTURE, formats[i].fmt))) + hr = > IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, + D3DUSAGE_DYNAMIC, > D3DRTYPE_TEXTURE, formats[i].fmt); + dynamic_tex_support = > SUCCEEDED(hr);; + if (!dynamic_tex_support) { - if > (FAILED(IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, > D3DFMT_X8R8G8B8, - 0, D3DRTYPE_SURFACE, > formats[i].fmt))) + if (!surface_support) { > skip("Format %s not supported, skipping lockrect offset tests.\n", > formats[i].name); continue; @@ -5997,6 +6154,44 @@ static void > test_surface_lockrect_blocks(void) > > IDirect3DSurface9_Release(surface); } + + if > (!dynamic_tex_support) + { + skip("Dynamic %s > textures not supported, skipping mipmap test.\n", formats[i].name); > + continue; + } + + if > (formats[i].block_width == 1 && formats[i].block_height == 1) + > continue; + if (!formats[i].core_fmt) + continue; + + > hr = IDirect3DDevice9_CreateTexture(device, formats[i].block_width, > formats[i].block_height, 2, + D3DUSAGE_DYNAMIC, formats[i].fmt, > D3DPOOL_DEFAULT, &texture, NULL); + ok(SUCCEEDED(hr), > "Failed to create texture, hr %#x, format %s.\n", hr, > formats[i].name); + + hr = > IDirect3DTexture9_LockRect(texture, 1, &locked_rect, NULL, 0); + > ok(SUCCEEDED(hr), "Failed lock texture, hr %#x.\n", hr); + hr = > IDirect3DTexture9_UnlockRect(texture, 1); + ok(SUCCEEDED(hr), > "Failed lock texture, hr %#x.\n", hr); + + rect.left = 0; + > rect.top = 0; + rect.right = formats[i].block_width == 1 ? 1 > : formats[i].block_width >> 1; + rect.bottom = > formats[i].block_height == 1 ? 1 : formats[i].block_height >> 1; + > hr = IDirect3DTexture9_LockRect(texture, 1, &locked_rect, &rect, > 0); + ok(SUCCEEDED(hr), "Failed lock texture, hr %#x.\n", hr); + hr > = IDirect3DTexture9_UnlockRect(texture, 1); + ok(SUCCEEDED(hr), > "Failed lock texture, hr %#x.\n", hr); + + rect.right = > formats[i].block_width; + rect.bottom = > formats[i].block_height; + hr = > IDirect3DTexture9_LockRect(texture, 1, &locked_rect, &rect, 0); + > todo_wine ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", > hr); + if (SUCCEEDED(hr)) + > IDirect3DTexture9_UnlockRect(texture, 1); + + > IDirect3DTexture9_Release(texture); } > > refcount = IDirect3DDevice9_Release(device); @@ -6779,7 +6974,7 @@ > START_TEST(device) test_surface_dimensions(); > test_surface_format_null(); test_surface_double_unlock(); - > test_surface_lockrect_blocks(); + test_surface_blocks(); > test_set_palette(); test_swvp_buffer(); test_rtpatch(); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJdJoAAoJEN0/YqbEcdMwkZkP/18bJEtlTuDSPlTg16mUVZn4 8XeOXELM/a+156LoBAyjy6XC6Mn4kO+fhuzdhKa846bjtL8L3A0HIbVWVw5VVbLi jV4pU7oXiKP2upSieDAro1IXQAgKabeLaKPYMz3dDJevXZoTglr8S7irzUy7WYhN /Pxj2vDvV6FDyonaHz/+odvBCnFmfD2FoqbgxWlTQ5fSt6iuCwXklJsmmOXTWjv7 6o4zFlvQ6Q42QSPDhHgDSoiXlpoK4mNfDPE6j1n3BdnCIbse5Peh5V8F1NGcjQJQ iV9t7gjruiEPhqG/W7zLoDVgRLZIsXiQNY5jNA8JJaGX5eWUrlRRPR1RsANKoaUU oltPEy3J9D/ILfRc1mK39NpvXuJWnNB8uDjMzGJurs6JCAMQHYaOoUKY7DkJqc9y n1CzmlDrMeDeverpRSLAXr8MtBPyGbg9NcTzzaLji+7DIyQJNMXU53Gj/heleurs 4ZVfxPaIr3ww2xOlC/tkhjZcy4F/Az48Py2EARRtLp8YMW9skej/U51jc2n32Akd m8zEdKdWgC0WdLtWEf4+u8O8azuhq4dPiw+iAUC2KNxhwtt0jjDPrV+LsrygRbNG iZvUgAZLga6X6Pk8vZPrT26nX2WfF1QEVKPAXwWmzd0beVNnGqEuEV24Vrd/RcL+ JicqI3oBax7saTMiRyni =6u3G -----END PGP SIGNATURE-----

1 0

Re: [PATCH 3/5] wined3d: Don't clamp texture lookups in the GLSL fixed function fragment pipe.
by Stefan Dösinger 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-09-03 09:47, schrieb Henri Verbeet: > This originally came from the ARB fragment program implementation, > but I don't see a justification for clamping there either. For the > texture formats typically used with the fixed function pipe > clamping wouldn't make a difference, and we don't have any tests > that say we need to clamp. The idea behind the clamps is that the fixed function pipeline is generally limited to the [0.0;1.0] range. bbf313e7 added a test for that, and there was e.g. 14706 (which doesn't contain much info tbh). Personally I'd keep the clamps in unless a test says otherwise or there's another compelling reason to remove them. But since it is quite unlikely to matter that's not a strong opinion. The ideal solution is of course to write a test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJciCAAoJEN0/YqbEcdMwQ2gP/Ayrnyv1b7VmviOCBLdKpW3P YjEgLSFtaiEMGjJ6DD3iTLTRBaMOWZIryKyXdE5QLecKx35xuk6GbC+OAXgCCZfU a558nJwymMtMpiU9Wa2nuUXF4p+KuC8CHkCgfOGF1D4wDZcQQxfEcvKcwAGPaZwV PWiKKI8SWO69XlawZHOLyWz97gghYpLrHIexOxbCVXGMXee7pqAQTSz2oRVppHot 39T2qbFo21qtoyK7sgqMgnRko52eiJGSBVHCfcfhhMPh+mksQvPoZDcdK/KSAl6r K5Py0kbVjBDjE9I6uCGO9+bt6a6RrJpC/6JGIOypDvicnjd/7X4LK8SYfGv3Cvr6 qejlsAouxrQgdYARrdjnoR4IEK8WviBzOZDnvxOS8dlEsJxjMjxIScnemdNacNKO QY3DJ/GmfnsnOXnrrvADKkLvCkeIUCE5v6U9Kv+S9GsMgNeJs1IEHzQpROBmt/iO ukUH+aOe4JReH1mtynrX+GsjwZkDPzatx48SxOOopWW5akiCbEsJNFirR4m1St9E 5+iOCkGQkjWVz95XgZt3VRpUBxx12JHsX1/UscBmprvkutmbUOYvRIpgqdTyZknD dW4x79KWQ6YUu3k8Lho8EfChR8rzPoDeaHwclY/WrwE+yuHugk+z0dv/gclC3eiL HAQ0T8GuuElJvdPfgE3F =8XAf -----END PGP SIGNATURE-----

2 2

Re: gdi32: Fixed Rectangle() rotation problem with GM_ADVANCED graphics mode.
by Alexandre Julliard 03 Sep '13

03 Sep '13

Ralf Habacker <ralf(a)habacker.de> writes: > see http://bugs.winehq.org/show_bug.cgi?id=34381 > --- > dlls/gdi32/painting.c | 18 ++++++++++++++++-- > 1 Datei geändert, 16 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-) This would have to be done in the drivers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
by Marvin 03 Sep '13

03 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1970 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (23c): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (320): not at the OOB mark: 1

1 0

Re: Sort the AUTHORS file by their last names.
by André Hentschel 02 Sep '13

02 Sep '13

Am 02.09.2013 08:24, schrieb Tae Wong: > Add more authors from the GIT log. > > Commit this patch. > > > It seems you have some need to change the order of the AUTHORS file, but it's autogenerated, so you would need to fix the generation. And Michael already pointed out that this non-trivial problem can't be automated. If you simply want to get into wine development, you really should pick something else to start with. PS: It also seems it's not clear to you what a patch is, so you might want to read http://wiki.winehq.org/SubmittingPatches

2 1

Re: [docs 2/2] winedev: Don't recommend a preprocessor check to comment out code
by Frédéric Delanoy 02 Sep '13

02 Sep '13

On Mon, Sep 2, 2013 at 10:34 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > en/winedev-coding.sgml | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) There's a typo in - block of code. + block of code and it makes sure the code get's maintained. get's => gets -- Frédéric Delanoy

1 0

Re: [PATCH 3/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO
by Alexandre Julliard 02 Sep '13

02 Sep '13

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + items = WSAEnumProtocolsW(NULL, NULL, &listsize); > + if (items == SOCKET_ERROR && WSAGetLastError() == WSAENOBUFS && > + (buffer = HeapAlloc(GetProcessHeap(), 0, listsize))) > + { > + items = WSAEnumProtocolsW(NULL, buffer, &listsize); > + for (i = 0; i < items; i++) > + { > + if (buffer[i].iAddressFamily == info.a->iAddressFamily && > + buffer[i].iSocketType == info.a->iSocketType && > + buffer[i].iProtocol == info.a->iProtocol) > + { > + if (unicode) > + memcpy(info.w, &buffer[i], sz); > + else > + { > + /* convert the structure from W to A */ > + memcpy(info.a, &buffer[i], FIELD_OFFSET(WSAPROTOCOL_INFOA, szProtocol)); > + WideCharToMultiByte(CP_ACP, 0, buffer[i].szProtocol, -1, > + info.a->szProtocol, WSAPROTOCOL_LEN+1, NULL, NULL); > + } > + break; > + } > + } > + } There's no reason to enumerate the protocols since you already know the one you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] kernel32/tests: Add a test to show that WaitCommEvent should fail if there is a pending wait.
by Marvin 02 Sep '13

02 Sep '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1957 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:850: Test failed: WaitCommEvent failed with a timeout comm.c:862: recovering after WAIT_TIMEOUT... comm.c:874: Test failed: WaitCommEvent error 0 comm.c:876: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:880: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:882: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:970: recovering after WAIT_TIMEOUT... comm.c:1549: test_AbortWaitCts timeout 500 handle 00000130 comm.c:1516: Changing CommMask on the fly for handle 00000130 after timeout 500

2 1

Re: [2/3] d3d9: Partial implementation of IDirect3DSwapChain9Ex (try 2)
by Henri Verbeet 02 Sep '13

02 Sep '13

On 30 August 2013 17:09, Michael Müller <michael(a)fds-team.de> wrote: > +static HRESULT WINAPI d3d9_swapchain_GetLastPresentCount(IDirect3DSwapChain9Ex *iface, > + UINT *pLastPresentCount) > +{ > + FIXME("iface %p, pLastPresentCount %p, stub!\n", iface, pLastPresentCount); > + > + if(pLastPresentCount) > + *pLastPresentCount = 0; > + > + return D3D_OK; > +} Please use the same style as the rest of the code. E.g., "if (last_present_count)". > +static HRESULT WINAPI d3d9_swapchain_GetDisplayModeEx(IDirect3DSwapChain9Ex *iface, > + D3DDISPLAYMODEEX *pMode, D3DDISPLAYROTATION *pRotation) > +{ > + struct d3d9_swapchain *swapchain = impl_from_IDirect3DSwapChain9Ex(iface); > + struct wined3d_display_mode wined3d_mode; > + enum wined3d_display_rotation wined3d_rotation; > + HRESULT hr; > + > + TRACE("iface %p, pMode %p, pRotation %p.\n", iface, pMode, pRotation); > + > + wined3d_mutex_lock(); > + hr = wined3d_swapchain_get_display_mode(swapchain->wined3d_swapchain, &wined3d_mode, &wined3d_rotation); > + wined3d_mutex_unlock(); > + > + if (SUCCEEDED(hr)) > + { > + if(pMode) > + { > + pMode->Size = sizeof(D3DDISPLAYMODEEX); > + pMode->Width = wined3d_mode.width; > + pMode->Height = wined3d_mode.height; > + pMode->RefreshRate = wined3d_mode.refresh_rate; > + pMode->Format = d3dformat_from_wined3dformat(wined3d_mode.format_id); > + pMode->ScanLineOrdering = wined3d_mode.scanline_ordering; > + } > + > + if(pRotation) > + *pRotation = wined3d_rotation; > + > + } > + > + return hr; > +} This is different from d3d9_GetAdapterDisplayModeEx(). The way you handle "pMode->Size" looks suspicious, while the NULL checks on "pMode" and "pRotation" may make sense. Please add tests to show this is correct. (See also test_get_adapter_displaymode_ex(), although that test has some room for improvement itself.)

1 0

Re: [3/3] d3d9/tests: Test if IDirect3DSwapChain9Ex is available without IDirect3D9Ex
by Henri Verbeet 02 Sep '13

02 Sep '13

On 30 August 2013 17:09, Michael Müller <michael(a)fds-team.de> wrote: > > + /* Get the implicit swapchain */ > + hr = IDirect3DDevice9_GetSwapChain(device, 0, &swapchain); > + ok(SUCCEEDED(hr), "Failed to get the implicit swapchain (%08x)\n", hr); > + if (SUCCEEDED(hr)) > + { > + hr = IDirect3DSwapChain9_QueryInterface(swapchain, &IID_IDirect3DSwapChain9Ex, (void **) &swapchainEx); > + ok(hr == E_NOINTERFACE, > + "IDirect3DSwapChain9::QueryInterface for IID_IDirect3DSwapChain9Ex returned %08x, expected E_NOINTERFACE\n", > + hr); > + ok(swapchainEx == NULL, "QueryInterface returned interface %p, expected NULL\n", swapchainEx); > + if(swapchainEx) IDirect3DSwapChain9Ex_Release(swapchainEx); > + } > + if(swapchain) IDirect3DSwapChain9_Release(swapchain); It probably wouldn't hurt to have a test for the other case as well. I.e., that you can get an IDirect3DSwapChain9Ex interface from a device created from an IDirect3D9Ex interface.

1 0

Re: iphlpapi: Add AllocateAndGetTcpExTableFromStack().
by Bruno Jesus 31 Aug '13

31 Aug '13

On Sat, Aug 31, 2013 at 9:16 AM, Ralf Habacker <ralf.habacker(a)freenet.de> wrote: > new > - add doc for family parameter > - add doc for additional return code > - sorting in c file fixed > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> I guess the patch was marked as pending because you didn't add any tests. You are also missing the (try X) at the end of the subject. Regards, Bruno

1 0

Re: [PATCH 3/3] ws2_32: Implement get socket option SO_PROTOCOL_INFO
by Marvin 31 Aug '13

31 Aug '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1945 Your paranoid android. === wxppro (32 bit sock) === sock: unhandled exception c0000005 at 00000000

1 0

Re: [PATCH] widl: Limit recursion deepth within structs to 1 for checking for full-pointers.
by Paul Chitescu 30 Aug '13

30 Aug '13

Hi! It would help to attach the patch, not your editor's swap file. Paul On Friday 30 August 2013 10:57:26 pm Kai Tietz wrote: > Hello, > > attached patch limits recursion in type_has_full_pointer-function to a > deeth of 1. By this all necessary checks should be possible, but > endless-recursion due diamond/cycle type-declarations are avoided. > I was finding this issue by working on propidl.idl rework, and hit > such an endless recursion. > > Regards, > Kai

2 1

Re: [PATCH 5/5] wined3d: Enforce volume texture block restrictions
by Henri Verbeet 30 Aug '13

30 Aug '13

On 30 August 2013 00:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (format->flags & WINED3DFMT_FLAG_BLOCKS) > + { > + UINT width_mask = format->block_width - 1; > + UINT height_mask = format->block_height - 1; > + if (desc->width & width_mask || desc->height & height_mask) > + { > + WARN("(%p) : Texture cannot be created - width or height not block size aligned.\n", texture); > + return WINED3DERR_INVALIDCALL; > + } > + } > + Is this different from surfaces? IIRC surfaces are padded up to the next multiple of the block size, although I may have that wrong. Not a fan of the "(%p) : " trace formatting.

2 3

Re: [PATCH 3/5] d3d9/tests: Add a DXT5 volume test
by Henri Verbeet 30 Aug '13

30 Aug '13

On 30 August 2013 00:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* A 8x4x2 texture consisting of 4 4x4 blocks. The colors of the blocks are red, green, blue and white. */ > + 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00, 0xF8, 0x00, 0x00, 0x00, 0x00, > + 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xE0, 0x07, 0xE0, 0x07, 0x00, 0x00, 0x00, 0x00, > + 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1F, 0x00, 0x1F, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00 In general we're using lower-case hex in wined3d, but I think it should at least be consistent within the same test.

2 1

Sequences in a loop
by matyapiro31 30 Aug '13

30 Aug '13

I found many wine sources use not a pointer,but a sequence . for example: krnl386.exe16/dma.c: for(i=0,p=(char*)DMA_CurrentBaseAddress[channel];i<ret*size;i++) msdaps/usrmarshal.c: for(prop = 0; prop < rgPropertySets[prop_set].cProperties; prop++) I know in some cases to use sequences are wiser way than pointers, but so many of them are used in loops. Should I change them?

3 2

Help to create a server request
by Bruno Jesus 30 Aug '13

30 Aug '13

Hi all, I need some help to continue my current wine work. In order to implement SO_PROTOCOL_INFO for getsockopt I need to retrieve some information from the socket like its family and protocol. I have searched for a few days and ended up with a solution I dislike so I had a better idea (at least I hope I did). Instead of using non-portable SO_DOMAIN and SO_PROTOCOL/SO_PROTOTYPE to retrieve the socket family and protocol or using non-reliable guessing using only the socket type I thought it would be better to ask the server for this information. Using a request just like is used for several other information in ws2_32 (operation which will work on every OS). So, all I need is a server request that based on the socket fd will return the socket family, type and protocol. I tried to understand how requests work but I failed completely. Maybe this request can be later improved to return the connection time so we can finally fix SO_CONNECT_TIME option. The current solution is attached, since I sent the tests separated and they were commited the patch will not apply, it's only for reference. The idea is to remove the functions get_sock_[family|protocol|type] to a single server request. So, is this a good idea? If yes, how can I create and use the request? If not I'm all ears. Best wishes and thanks in advance, Bruno

2 2

Re: oleaut32: Add ICreateTypeInfo2::SetVarName implementation
by Nikolay Sivov 30 Aug '13

30 Aug '13

On 8/30/2013 16:28, Piotr Caban wrote: > --- > dlls/oleaut32/tests/typelib.c | 13 +++++++++++-- > dlls/oleaut32/typelib.c | 13 +++++++++++-- > 2 files changed, 22 insertions(+), 4 deletions(-) > > > > ITypeInfoImpl *This = info_impl_from_ICreateTypeInfo2(iface); > - FIXME("%p %u %s - stub\n", This, index, wine_dbgstr_w(name)); > - return E_NOTIMPL; > + > + FIXME("%p %u %s\n", This, index, wine_dbgstr_w(name)); > + It probably should be TRACE.

1 0

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.
by Alexandre Julliard 30 Aug '13

30 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Printing complete lsr value in the log may help with diagnosing > test failures on Alexandre's machine. I don't see how, since TIOCSER_TEMT is the only defined bit. Do you actually have a driver that returns other status? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: kernel32/tests: Add a FlushFileBuffers test for a COM port. Resend.
by Marvin 30 Aug '13

30 Aug '13

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://newtestbot.winehq.org/JobDetails.pl?Key=1932 Your paranoid android. === wxppro (32 bit comm) === comm.c:849: Test failed: WaitCommEvent failed with a timeout comm.c:861: Test failed: WaitCommEvent error 997 comm.c:863: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:867: WaitCommEvent for EV_TXEMPTY took 1000 ms (timeout 1000) comm.c:869: Test failed: WaitCommEvent used 1000 ms for waiting

1 0

Re: d3d9: Partial implementation of IDirect3DSwapChain9Ex
by Stefan Dösinger 30 Aug '13

30 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2013-08-30 10:19, schrieb Michael Müller: > This patch implements the IDirect3DSwapChain9Ex interface as an > extension of IDirect3DSwapChain9 and thus fixes bug 34252 - > "Silverlight accelerated graphics cause a D3D critical section > lockup" since Silverlight does no longer try to create a Direct3D > context in an endless loop. The functions > d3d9_swapchain_GetLastPresentCount and > d3d9_swapchain_GetPresentStatistics are just stubs so far. Good work on finding out what causes that bug! > - if (IsEqualGUID(riid, &IID_IDirect3DSwapChain9) + if > (IsEqualGUID(riid, &IID_IDirect3DSwapChain9) || IsEqualGUID(riid, > &IID_IDirect3DSwapChain9Ex) || IsEqualGUID(riid, &IID_IUnknown)) For IDirect3D9Ex and IDirect3DDevice9Ex, the Ex versions are only available if IDirect3D9 was created with the extended method. I suspect swapchains are the same. Please write some tests for this. > + TRACE("iface %p, pLastPresentCount %p.\n", iface, pLastPresentCount); > + WARN("not implemented.\n"); If a function is not implemented we write a FIXME, e.g. FIXME("iface %p, pLastPresentCount %p, stub!\n", iface, pLastPresentCount); If this causes too much spam on the console, you can use a static variable to print it just once. > + if (SUCCEEDED(hr)) + { + if(pMode){ Please use a code style that is consistent with the rest of the file. Tbh the existing files aren't as consistent as we'd like. The general rule is a space between if and (, and { in newlines. 4 spaces intendation. If there's a one-line statement in an if, put that statement in a new line and don't write curly brackets. My personal opinion, and the style I use, is to use brackets for both branches of an if-else if one of those branches has more than one line. > - * IDirect3DSwapChain9 interface + * IDirect3DSwapChain9(Ex) > interface */ #define INTERFACE IDirect3DSwapChain9 > DECLARE_INTERFACE_(IDirect3DSwapChain9,IUnknown) You have to create a new interface declaration named IDirect3DSwapChain9Ex with all the methods and the invocation macros. The header change should go in a separate patch. The d3d9 code should be changed to always use IDirect3D9Swapchain9Ex, like it does for device and direct3d. Thanks for your work! Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIFimAAoJEN0/YqbEcdMwbW0P/jC/gsziWzCtxBH1gDETnX6+ j0csX5cORWKCaq/wsPbT9ZDVV/OYFYlWRB0QZiJIUWAp4PzdGXCxQN8srdybT1hp PG3HTDzv4Kmq57fYSXEoLnZNO/pgfr4JiGmhcwQSyheJ1+lcb5Z/GE09goHwcLce CJVrIQu9f05TQb+r0BJCxIyGAIuq8to7xdIJ1tPR2MmKwYzS0XWkB1yN8QIGy/Qm z4aH7JGsOJ37t/90D4eHVBX6EtiI6pRHHiaO3hFrgYiu7wf/CeiE3E9QWnwycG1h DdPWjreQx+6/JQfg71eXDW81WYgdRl7TfMfBOc8UFh7Byj9b4llR0E+NFSkQ81NL XAQkB/PthmEpJIH1tSo91aNrZkfN/jw7D1gA4kUHFEtr5n1yuUXQQvKLYEOMWrV0 lV1plnzzLEZa50c0Y3/zCgQFCbzgo47ohO/4msMHOU33n255oJg/Bd6CLoA1oPFq hxQkkv0bW5VL6Jn0WVAC1FPjfmRF6zD6h9n8KKPWU2rz/tmkoEhoJ0Nd2a483N86 6EvOTpecczmNBlICFvyUOVAisHnVdwk+cPI+6hoqHBq0C7fGXi7R41pDOvf4o1yH wZyMH4e+kiG+7qaeGRwsTEDW1V77VAbPXJkNZPU2Wvb/gVzLU1TVQ87Bz5T83tpv tFvZjJrjOYO4qL4Afm14 =zjgo -----END PGP SIGNATURE-----

1 0

Re: d3d9: Partial implementation of IDirect3DSwapChain9Ex
by Nikolay Sivov 30 Aug '13

30 Aug '13

On 8/30/2013 12:19, Michael Müller wrote: > This patch implements the IDirect3DSwapChain9Ex interface as an > extension of IDirect3DSwapChain9 and thus fixes bug 34252 - "Silverlight > accelerated graphics cause a D3D critical section lockup" since > Silverlight does no longer try to create a Direct3D context in an > endless loop. The functions d3d9_swapchain_GetLastPresentCount and > d3d9_swapchain_GetPresentStatistics are just stubs so far. > > > --- > dlls/d3d9/swapchain.c | 71 > ++++++++++++++++++++++++++++++++++++++++++++++++- > include/d3d9.h | 14 +++++++++- > include/d3d9types.h | 8 ++++++ > 3 files changed, 91 insertions(+), 2 deletions(-) > > @@ -34,7 +34,7 @@ static HRESULT WINAPI d3d9_swapchain_QueryInterface(IDirect3DSwapChain9 *iface, > { > TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > > - if (IsEqualGUID(riid, &IID_IDirect3DSwapChain9) > + if (IsEqualGUID(riid, &IID_IDirect3DSwapChain9) || IsEqualGUID(riid, &IID_IDirect3DSwapChain9Ex) > || IsEqualGUID(riid, &IID_IUnknown)) > { > IDirect3DSwapChain9_AddRef(iface); > @@ -221,12 +221,76 @@ static HRESULT WINAPI d3d9_swapchain_GetPresentParameters(IDirect3DSwapChain9 *i > return D3D_OK; > } I don't know if d3d9 is special in this regard, but this is a wrong way to implement derived interface. You need you make everything IDirect3DSwapChain9Ex, for example this one: > /***************************************************************************** > - * IDirect3DSwapChain9 interface > + * IDirect3DSwapChain9(Ex) interface > */ > #define INTERFACE IDirect3DSwapChain9 > DECLARE_INTERFACE_(IDirect3DSwapChain9,IUnknown) > @@ -405,6 +405,10 @@ DECLARE_INTERFACE_(IDirect3DSwapChain9,IUnknown) > STDMETHOD(GetDisplayMode)(THIS_ D3DDISPLAYMODE* pMode) PURE; > STDMETHOD(GetDevice)(THIS_ struct IDirect3DDevice9** ppDevice) PURE; > STDMETHOD(GetPresentParameters)(THIS_ D3DPRESENT_PARAMETERS* pPresentationParameters) PURE; > + /*** IDirect3DSwapChain9Ex methods ***/ > + STDMETHOD(GetLastPresentCount)(THIS_ UINT* pLastPresentCount) PURE; > + STDMETHOD(GetPresentStats)(THIS_ D3DPRESENTSTATS* pPresentationStatistics) PURE; > + STDMETHOD(GetDisplayModeEx)(THIS_ D3DDISPLAYMODEEX* pMode,D3DDISPLAYROTATION* pRotation) PURE; > }; > #undef INTERFACE is no longer just IDirect3DSwapChain9. This will fix vtbl type too.

1 0

Re: [2/2] ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit.
by Dmitry Timoshkov 30 Aug '13

30 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Printing complete lsr value in the log may help with diagnosing > test failures on Alexandre's machine. This patch is marked as 'Build failure' in the tracker, but I've checked it once again and compiles just fine here. What kind of build failure is that? -- Dmitry.

2 1

RFC: Mark dylib/mach-o on Mac OS X
by André Hentschel 29 Aug '13

29 Aug '13

Hi, at [1] i noticed that dylibs are printed as PEs. This intents to fix that, but i have no Mac, could someone please review/test? [1] http://test.winehq.org/data/8ef3a142263e6db11f1514f77b3de84c8b08d7a0/mac_fg… diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c index 6bea436..41fa7e6 100644 --- a/dlls/dbghelp/module.c +++ b/dlls/dbghelp/module.c @@ -33,6 +33,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(dbghelp); const WCHAR S_ElfW[] = {'<','e','l','f','>','\0'}; +const WCHAR S_MachoW[] = {'<','m','a','c','h','o','>','\0'}; const WCHAR S_WineLoaderW[] = {'<','w','i','n','e','-','l','o','a','d','e','r','>','\0'}; static const WCHAR S_DotSoW[] = {'.','s','o','\0'}; static const WCHAR S_DotDylibW[] = {'.','d','y','l','i','b','\0'}; @@ -94,6 +95,9 @@ static void module_fill_module(const WCHAR* in, WCHAR* out, size_t size) if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) && (l = match_ext(out, len - 3))) strcpyW(&out[len - l - 3], S_ElfW); + else if (len > 6 && !strcmpiW(&out[len - 6], S_DotDylibW) && + (l = match_ext(out, len - 6))) + strcpyW(&out[len - l - 6], S_MachoW); } while ((*out = tolowerW(*out))) out++; } diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c index c0b86ba..c2c7c08 100644 --- a/programs/winedbg/info.c +++ b/programs/winedbg/info.c @@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base) } } } + else if (strstr(im.mi[i].ModuleName, "<macho>")) + { + dbg_printf("MACH-O\t"); + module_print_info(&im.mi[i], FALSE); + } else { /* check module is not embedded in another module */ @@ -253,8 +258,11 @@ void info_win32_module(DWORD64 base) break; } if (j < im.num_used) continue; - if (strstr(im.mi[i].ModuleName, ".so") || strchr(im.mi[i].ModuleName, '<')) + if (strstr(im.mi[i].ModuleName, ".so") || strstr(im.mi[i].ModuleName, "<elf>") || + strstr(im.mi[i].ModuleName, "<wine-loader>")) dbg_printf("ELF\t"); + else if (strstr(im.mi[i].ModuleName, ".dylib") || strstr(im.mi[i].ModuleName, "<macho>")) + dbg_printf("MACH-O\t"); else dbg_printf("PE\t"); module_print_info(&im.mi[i], FALSE);

4 9

Re: patch:kernel32
by Charles Davis 29 Aug '13

29 Aug '13

On Aug 29, 2013, at 8:15 AM, matyapiro31 wrote: > > <0001-kernel32-change-for-loop-to-optimize.patch><0002-kernel32-change-for-loop-to-optimize.patch> One patch per email, please. Also, the subject should be more descriptive. The first one doesn't look much better than the second one (which was already rejected). sizeof(array)/sizeof(array[0]) is a constant expression; any optimizing compiler worth its salt will optimize that for you. (And I would know, because I work on LLVM and Clang.) The first part of that patch (against dlls/kernel32/console.c) might be a bit more promising, though, since it hoists a computation that isn't constant at compile time but is constant for the duration of the loop; but again, any good optimizing compiler would be smart enough to do that, too. Oh, and you forgot to actually declare the variables that hold the hoisted values. Those assignments don't count, because: a) You never gave them a type. That's an error in any C compiler (C89, C99, etc.) I'm not even sure a K&R compiler would take that. b) Wine is written in C89 (with some GNU extensions scattered throughout, but generally we try to write portable code around here); that means (among other things) all variable declarations must come before other statements. Did you even try to compile Wine with these patches? Chip

1 0

Re: [PATCH 2/2] ddraw/tests: Test WM_ACTIVATEAPP messages generated by SetCooperativeLevel
by Henri Verbeet 29 Aug '13

29 Aug '13

On 29 August 2013 11:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +BOOL activateapp_received; > +IDirectDraw *activateapp_ddraw; > +HWND activateapp_window; > +DWORD activateapp_coop_level; > + I think those should be static, and you'll probably want to put them in a structure.

1 0

my patch was wrong at dlls/kernel32/computernames.c
by matyapiro31 29 Aug '13

29 Aug '13

From if ( isalnumW ( wc ) ) return wc; for ( i = 0; i < 17; i++ ) To if ( isalnumW ( wc ) ) return wc; for ( i = 0; i < 16; i++ ) and the original version was wrong,too. It counts the NULL of the end.

2 1

Re: patch:kernel32
by Bruno Jesus 29 Aug '13

29 Aug '13

On Thu, Aug 29, 2013 at 11:15 AM, matyapiro31 <matyapiro31(a)gmail.com> wrote: The patch could have a better subject =) > + unix_len=sizeof(unix_vars)/sizeof(unix_vars[0]; Missing the closing ) ? Will this compile? > - for ( i = 0; i < sizeof (special) / sizeof (WCHAR); i++ ) > + for ( i = 0; i < 17; i++ ) I guess the compiler does this for you. And for the other cases too. Also you should send only one patch per email. Regards, Bruno

1 0

Re: patch:try 2 of adding wine ja mannual
by Akihiro Sagawa 29 Aug '13

29 Aug '13

On Wed, 28 Aug 2013 20:29:43 +0900, �� wrote: > diff --git a/loader/Makefile.in b/loader/Makefile.in > index a7ab893..bc11378 100644 > --- a/loader/Makefile.in > +++ b/loader/Makefile.in > @@ -20,14 +20,16 @@ MANPAGE = wine.man > EXTRA_MANPAGES = \ > wine.de.man \ > wine.fr.man \ > - wine.pl.man > + wine.pl.man \ > + wine.ja.man The line was indented spaces, use tabs instead here, please. The list should be in alphabetical order, i.e. de, fr, ja, pl. > INSTALLDIRS = \ > $(DESTDIR)$(bindir) \ > $(DESTDIR)$(mandir)/man$(prog_manext) \ > $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext) \ > $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext) \ > - $(DESTDIR)$(mandir)/pl.UTF-8/man$(prog_manext) > + $(DESTDIR)$(mandir)/pl.UTF-8/man$(prog_manext) \ > + $(DESTDIR)$(mandir)/ja/man$(prog_manext) Use tabs and insert the line between fr and pl, please. Why don't you use ja.UTF-8? > diff --git a/loader/wine.ja.man.in b/loader/wine.ja.man.in > new file mode 100644 > index 0000000..e2e1cba > --- /dev/null > +++ b/loader/wine.ja.man.in The document still looks like wine 1.4 age text. Some sentences deleted before 1.6 release, e.g. git url, still remain. Updated texts, e.g. DESCRIPTION section, aren't reflected in the translated one. Please refer the diff page [1] to figure out what was changed between wine-1.4 and wine-1.6. [1] http://source.winehq.org/git/wine.git/blobdiff/wine-1.4..wine-1.6:/loader/w… I noticed that you added Japanese specific section -- 文字化けについて -- to the man page. I'm not sure about this because other translators didn't do like this and it is difficult to keep up-to-date language specific information. Regards, Akihiro Sagawa

1 0

Re: wininet: Replacing a header with an empty value deletes it.
by testbot＠winehq.org 29 Aug '13

29 Aug '13

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 http://newtestbot.winehq.org/JobDetails.pl?Key=1918 Your paranoid android. === w7pro64 (32 bit http) === http.c:4279: Test failed: HttpSendRequest failed: 12057 http.c:4284: Test failed: expected secure flag to be set === w7pro64 (64 bit http) === http.c:3445: Test failed: HttpQueryInfo failed 0

1 0

Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
by Alexandre Julliard 29 Aug '13

29 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/kernel32/tests/comm.c | 5 +---- > dlls/ntdll/serial.c | 13 +++++-------- > 2 files changed, 6 insertions(+), 12 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so comm.c && touch comm.ok comm.c:835: Test failed: WriteFile took 1 ms to write 17 Bytes at 150 Baud comm.c:848: Test failed: WaitCommEvent failed with a timeout comm.c:859: Test failed: WaitCommEvent error 997 comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting comm.c:1895: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) make: *** [comm.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

3 10

Re: [1/2] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port. Take 2.
by Dmitry Timoshkov 29 Aug '13

29 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Based on a patch of Wolfgang Walter. Is there anything wrong with this patch? -- Dmitry.

1 0

Re: ntdll: Store all 'comClass' attributes (try3)
by Michael Stefaniuc 28 Aug '13

28 Aug '13

Hello Nikolay, On 08/27/2013 12:16 PM, Nikolay Sivov wrote: > +static OLEMISC get_olemisc_value(const WCHAR *str, int len) > +{ > + int min, max; > + > + min = 0; > + max = sizeof(olemisc_values)/sizeof(struct olemisc_entry) - 1; > + > + while (min <= max) > + { > + int n, c; > + > + n = (min+max)/2; > + > + c = strncmpW(olemisc_values[n].name, str, len); why don't you just compare the length first? If the length matches you can do a simple strcmpW between the strings to verify the match. Something like the below code: if (olemisc_values[n].len == len) { if (!strcmpW(olemisc_values[n].name, str) return olemisc_values[n].value; else ... } else if (olemisc_values[n].len > len) max = n-1; else min = n+1; > + if (!c) > + { > + if (olemisc_values[n].len < len) > + c = -1; > + else if (olemisc_values[n].len > len) > + c = 1; > + } > + > + if (!c) > + return olemisc_values[n].value; > + > + if (c > 0) > + max = n-1; > + else > + min = n+1; > + } > + > + WARN("unknown flag %s\n", debugstr_wn(str, len)); > + return 0; > +} bye michael

1 0

Re: [PATCH] iphlpapi: Add AllocateAndGetTcpExTableFromStack().
by Hans Leidekker 28 Aug '13

28 Aug '13

On Wed, 2013-08-28 at 12:21 +0200, Ralf Habacker wrote: > diff --git a/dlls/iphlpapi/iphlpapi.spec b/dlls/iphlpapi/iphlpapi.spec > index 36ba13f..1eed5ae 100644 > --- a/dlls/iphlpapi/iphlpapi.spec > +++ b/dlls/iphlpapi/iphlpapi.spec > @@ -6,6 +6,7 @@ > @ stdcall AllocateAndGetIpForwardTableFromStack( ptr long long long ) > @ stdcall AllocateAndGetIpNetTableFromStack( ptr long long long ) > @ stdcall AllocateAndGetTcpTableFromStack( ptr long long long ) > +@ stdcall AllocateAndGetTcpExTableFromStack( ptr long long long long ) AllocateAndGetTcpExTableFromStack sorts before AllocateAndGetTcpTableFromStack. > diff --git a/dlls/iphlpapi/ipstats.h b/dlls/iphlpapi/ipstats.h > index bf5bb92..efdb1cc 100644 > --- a/dlls/iphlpapi/ipstats.h > +++ b/dlls/iphlpapi/ipstats.h > @@ -33,6 +33,7 @@ > DWORD getInterfaceStatsByName(const char *name, PMIB_IFROW entry) DECLSPEC_HIDDEN; > > DWORD WINAPI AllocateAndGetUdpTableFromStack(PMIB_UDPTABLE *ppUdpTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; > +DWORD WINAPI AllocateAndGetTcpExTableFromStack(PVOID *ppTcpTable, BOOL bOrder, HANDLE heap, DWORD flags, DWORD family) DECLSPEC_HIDDEN; Again, you don't need this part.

2 2

[AppDB] How to deal with hardware/driver dependent test result?
by Felix Yan 28 Aug '13

28 Aug '13

Hi, I'm maintaining Spore 1.0, and it works correctly in wine for over a year on Nvidia video card with closed-source nvidia driver - but I do noticed with Intel cards with open source drivers, the game is nearly not playable - missing texture and more problems. Today comes in a new test result that mark the game as "Garbage", while the description is exactly what happened on my laptop with Intel chip. What should I do about this? To proceed with the test result and change the game to "Garbage" stage, or reject with "Nvidia cards works fine"? I don't think either is fine, so I come to the list for help. Thanks! Regards, Felix Yan

3 2

Re: [PATCH] iphlpapi: Add AllocateAndGetTcpExTableFromStack().
by Hans Leidekker 28 Aug '13

28 Aug '13

On Wed, 2013-08-28 at 11:41 +0200, Ralf Habacker wrote: > diff --git a/dlls/iphlpapi/iphlpapi.spec b/dlls/iphlpapi/iphlpapi.spec > index 36ba13f..cad2ca9 100644 > --- a/dlls/iphlpapi/iphlpapi.spec > +++ b/dlls/iphlpapi/iphlpapi.spec > @@ -6,6 +6,7 @@ > @ stdcall AllocateAndGetIpForwardTableFromStack( ptr long long long ) > @ stdcall AllocateAndGetIpNetTableFromStack( ptr long long long ) > @ stdcall AllocateAndGetTcpTableFromStack( ptr long long long ) > +@ stdcall AllocateAndGetTcpExTableFromStack( ptr long long long ) These should be sorted. > diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c > index 809dbc6..bcb3021 100644 > --- a/dlls/iphlpapi/ipstats.c > +++ b/dlls/iphlpapi/ipstats.c > @@ -2327,6 +2327,32 @@ DWORD WINAPI AllocateAndGetTcpTableFromStack( PMIB_TCPTABLE *ppTcpTable, BOOL bO > return build_tcp_table( TCP_TABLE_BASIC_ALL, (void **)ppTcpTable, bOrder, heap, flags, NULL ); > } > > +/****************************************************************** > + * AllocateAndGetTcpExTableFromStack (IPHLPAPI.@) > + * > + * Get the TCP connection table. > + * Like GetTcpTable(), but allocate the returned table from heap. > + * > + * PARAMS > + * ppTcpTable [Out] pointer into which the MIB_TCPTABLE_EX is > + * allocated and returned. > + * bOrder [In] whether to sort the table > + * heap [In] heap from which the table is allocated > + * flags [In] flags to HeapAlloc > + * > + * RETURNS > + * ERROR_INVALID_PARAMETER if ppTcpTable is NULL, whatever GetTcpTable() > + * returns otherwise. > + */ > +DWORD WINAPI AllocateAndGetTcpExTableFromStack( PMIB_TCPTABLE_EX *ppTcpTable, BOOL bOrder, > + HANDLE heap, DWORD flags ) > +{ > + TRACE("table %p, bOrder %d, heap %p, flags 0x%08x\n", ppTcpTable, bOrder, heap, flags); > + > + if (!ppTcpTable) return ERROR_INVALID_PARAMETER; > + return build_tcp_table( TCP_TABLE_OWNER_PID_ALL, (void **)ppTcpTable, bOrder, heap, flags, NULL ); > +} > + > static DWORD get_udp_table_sizes( UDP_TABLE_CLASS class, DWORD row_count, DWORD *row_size ) > { > DWORD table_size; > diff --git a/dlls/iphlpapi/ipstats.h b/dlls/iphlpapi/ipstats.h > index bf5bb92..823fadb 100644 > --- a/dlls/iphlpapi/ipstats.h > +++ b/dlls/iphlpapi/ipstats.h > @@ -34,6 +34,7 @@ DWORD getInterfaceStatsByName(const char *name, PMIB_IFROW entry) DECLSPEC_HIDDE > > DWORD WINAPI AllocateAndGetUdpTableFromStack(PMIB_UDPTABLE *ppUdpTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; > DWORD WINAPI AllocateAndGetTcpTableFromStack(PMIB_TCPTABLE *ppTcpTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; > +DWORD WINAPI AllocateAndGetTcpExTableFromStack(PMIB_TCPTABLE_EX *ppTcpTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; > DWORD WINAPI AllocateAndGetIpNetTableFromStack(PMIB_IPNETTABLE *ppIpNetTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; > DWORD WINAPI AllocateAndGetIpForwardTableFromStack(PMIB_IPFORWARDTABLE *ppIpForwardTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; You don't need this, AllocateAndGetTcpExTableFromStack can be made static. The first parameter should be a void ** like in recent versions of iphlpapi.h. > diff --git a/include/tcpmib.h b/include/tcpmib.h > index 477500c..bc63c3f 100644 > --- a/include/tcpmib.h > +++ b/include/tcpmib.h > @@ -150,6 +150,9 @@ typedef struct _MIB_TCPTABLE2 > MIB_TCPROW2 table[1]; > } MIB_TCPTABLE2, *PMIB_TCPTABLE2; > > +typedef MIB_TCPROW_OWNER_PID _MIB_TCPROW_EX; > +typedef MIB_TCPTABLE_OWNER_PID MIB_TCPTABLE_EX; > +typedef PMIB_TCPTABLE_OWNER_PID PMIB_TCPTABLE_EX; Recent headers don't define these so we shouldn't either.

1 0

Re: [PATCH] iphlpapi: Add AllocateAndGetTcpExTableFromStack().
by Nikolay Sivov 28 Aug '13

28 Aug '13

On 8/28/2013 13:41, Ralf Habacker wrote: > > Signed-off-by: Ralf Habacker <ralf.habacker(a)freenet.de> > --- > dlls/iphlpapi/iphlpapi.spec | 1 + > dlls/iphlpapi/ipstats.c | 26 ++++++++++++++++++++++++++ > dlls/iphlpapi/ipstats.h | 1 + > include/tcpmib.h | 3 +++ > 4 Dateien geändert, 31 Zeilen hinzugefügt(+) > > > > +DWORD WINAPI AllocateAndGetTcpExTableFromStack( PMIB_TCPTABLE_EX *ppTcpTable, BOOL bOrder, > + HANDLE heap, DWORD flags ) Are you sure about this? It doesn't match a prototype from MSDN.

1 0

Re: kernel32/tests: Remove a useless trace.
by Marvin 28 Aug '13

28 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26897 Your paranoid android. === WVISTAX64 (64 bit comm) === comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud comm.c:1445: test_AbortWaitCts timeout 500 handle 000000000000003C comm.c:1412: Changing CommMask on the fly for handle 000000000000003C after timeout 500

1 0

Re: msvcr90/tests: Add more ARM forwards and use them in tests
by Marvin 27 Aug '13

27 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26894 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found

1 0

Re: [1/4] ntdll: Ignore ioctl(TIOCGICOUNT) failures.
by Wolfgang Walter 27 Aug '13

27 Aug '13

Am Dienstag, 27. August 2013, 22:00:59 schrieben Sie: > Wolfgang Walter <wine(a)stwm.de> wrote: > > > Wolfgang Walter <wine(a)stwm.de> wrote: > > > > I made similar changes so that several applications we use work. I > > > > tested > > > > your patches, all but one do work. I don't know why one does not, > > > > though. > > > > > > What patch doesn't work for you? > > > > I tested all your patches together (indivually they will not really work > > here). > > Yeah, the patches need to be tested after applying all of them. They were > broken into smaller parts in order to make regression test easier in case of > a regression. If I don't know what doesn't work I can't make any > improvement. Yes, that's clear. I'll have a closer look what's the main difference. The problematic application uses asynchronous IO. I wrote my patch 2009 (and earlier version 2008) so I have to rethink about it. I remember that TX_TXEMPTY detection was a problem, then. It could get lost. The reason I moved the output buffer empty detection from get_irq_info() into check_events() was simply because I thought handling input queue in check_events() but ouput queue in get_irq_info() seems odd. I also think that it's better to detect that get_irq_info() basicly does not work with drivers not supporting TIOCGICOUNT and it is good to have that information in the callers of get_irq_info(). So I return STATUS_NOT_IMPLEMENTED and handle the situation in the caller. And then it is better to move empty sending queue handling out of get_irq_info(). I handle the TIOCSERGETLSR wrong, as I see now (I should & with TIOCSER_TEMT). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Abteilungsleiter IT Leopoldstraße 15 80802 München

1 0

Retiring winetestbot
by Jeremy White 27 Aug '13

27 Aug '13

Folks, I am writing to announce that we will be retiring the original Wine Test Bot, written by the late Ge van Geldorp, as of August 31, 2013. We will switch over to the new test bot that Francois has been working on at that time. On September 1, we'll panic and fix everything that is broken <grin>). I want to thank Ge's family, notably his brother Arno, for keeping the servers running these years since Ge passed away. It's also important to note how incredible a contribution the Wine Test Bot has proven to be for the Wine project; Wine owes an incredible debt to Ge, and I hope we can all collectively work to remember the great gift he gave us and the world. Cheers, Jeremy

1 0

Re: Does auto-apt work to get wine dependencies in source code?
by Susan Cragin 27 Aug '13

27 Aug '13

--Sorry about the HTML in the earlier message. >> Was thinking of running some tests but the list of dependencies on the website seems outdated, apt-get build-dep does not work. >Is that with the ubuntu-wine ppa enabled? There are two answers to that question, surprisingly. (1) bitbox In the instructions it looks like the wine ppa repository can be installed the Debian way. But I did that and here's the result. ---------------- E: You must put some 'source' URIs in your sources.list ---------------- So, I had to add the wine-ppa by manually adding to the sources.list. (2) non bitbox This morning a new version of the i386 photo function was added, and now the depencencies install. Conclusion: This afternoon I was able to update all dependencies and compile without a problem using (with modifications above) the bitbox instructions. Compiled only. Did not install because I needed symlinks, but at least I know where I am and what I have to do. Susan

1 0

Re: ntdll: Implement job objects
by Dmitry Timoshkov 27 Aug '13

27 Aug '13

Andrew Cook <ariscop(a)gmail.com> wrote: > +typedef struct _JOBOBJECT_ASSOCIATE_COMPLETION_PORT { > + PVOID CompletionKey; > + HANDLE CompletionPort; > +} JOBOBJECT_ASSOCIATE_COMPLETION_PORT, *PJOBOBJECT_ASSOCIATE_COMPLETION_PORT; This needs to go into its owm header. > +static DWORD getProcess(PHANDLE handle) { > + STARTUPINFO startup = {}; > + PROCESS_INFORMATION info = {}; > + > + if(!CreateProcessA(NULL, GetCommandLine(), NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info)) { > + ok(FALSE, "CreateProcess: %x\n", GetLastError()); > + return 0; > + } > + > + CloseHandle(info.hThread); > + *handle = info.hProcess; > + > + return info.dwProcessId; > +}; Indentation is completely messed up in the tests, please set tab size to 8 and even better avoid tabs at all. ';' at the end of function looks funny. > +typedef struct _JOBOBJECT_ASSOCIATE_COMPLETION_PORT { > + PVOID CompletionKey; > + HANDLE CompletionPort; > +} JOBOBJECT_ASSOCIATE_COMPLETION_PORT, *PJOBOBJECT_ASSOCIATE_COMPLETION_PORT; Same as above. > +static NTSTATUS (WINAPI *pNtCreateJobObject)( PHANDLE handle, ACCESS_MASK access, const OBJECT_ATTRIBUTES *attr ); > +static NTSTATUS (WINAPI *pNtSetInformationJobObject)( HANDLE handle, JOBOBJECTINFOCLASS klass, PVOID info, ULONG len ); > +static NTSTATUS (WINAPI *pNtAssignProcessToJobObject)( HANDLE job, HANDLE process ); > +static NTSTATUS (WINAPI *pNtIsProcessInJob)( HANDLE process, HANDLE job ); > +static NTSTATUS (WINAPI *pNtTerminateJobObject)( HANDLE job, NTSTATUS status ); Please move it to the beginning of the file. > --- a/include/wine/server_protocol.h > +++ b/include/wine/server_protocol.h And don't include autogenerated stuff in the patch. -- Dmitry.

2 2

Re: ntdll: Implement job objects
by Marvin 27 Aug '13

27 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26885 Your paranoid android. === W2KPROSP4 (32 bit job) === job: unhandled exception c0000005 at 00000000

1 0

Re: [1/4] ntdll: Ignore ioctl(TIOCGICOUNT) failures.
by Wolfgang Walter 27 Aug '13

27 Aug '13

Hello, I made similar changes so that several applications we use work. I tested your patches, all but one do work. I don't know why one does not, though. I attached my patch, maybe it is usefull to you. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Abteilungsleiter IT Leopoldstraße 15 80802 München

2 1

Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
by Marvin 27 Aug '13

27 Aug '13

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 http://testbot.winehq.org/JobDetails.pl?Key=26878 Your paranoid android. === WVISTAX64 (32 bit comm) === comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud comm.c:1443: test_AbortWaitCts timeout 500 handle 000000B4 comm.c:1410: Changing CommMask on the fly for handle 000000B4 after timeout 500

2 1

Re: ntdll: Store all 'comClass' attributes (try2)
by Alexandre Julliard 27 Aug '13

27 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > +static OLEMISC get_olemisc_value(const WCHAR *str, int len) > +{ > + int min, max; > + > + min = 0; > + max = ARRAY_SIZE(olemisc_values) - 1; > + > + while (min <= max) > + { > + int n, c; > + > + n = (min+max)/2; > + > + c = memcmp(olemisc_values[n].name, str, min(len, olemisc_values[n].len)*sizeof(WCHAR)); > + if (!c) > + { > + if (olemisc_values[n].len < len) > + c = -1; > + else if (olemisc_values[n].len > len) > + c = 1; > + } Actually, memcmp is not a good choice for comparing Unicode strings. It doesn't make a difference for ASCII-only strings, but it would still be cleaner to do it right. strncmpW is preferable (as long as you use it correctly...) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Store all 'comClass' attributes
by Alexandre Julliard 27 Aug '13

27 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > + while (min <= max) > + { > + int n, c; > + > + n = (min+max)/2; > + > + c = strncmpW(olemisc_values[n].name, str, len); strncmp isn't enough. -- Alexandre Julliard julliard(a)winehq.org

2 1

Does auto-apt work to get wine dependencies in source code?
by Susan Cragin 27 Aug '13

27 Aug '13

Hello, Was thinking of running some tests but the list of dependencies on the website seems outdated, apt-get build-dep does not work.

4 3

Re: [PATCH 1/3] ws2_32: Implement SIO_ADDRESS_LIST_CHANGE with NotifyAddrChange (try 2).
by Bruno Jesus 27 Aug '13

27 Aug '13

On Mon, Aug 5, 2013 at 1:24 AM, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > The attached patch is the next step in the series of fixes for > Silverlight/PlayReady under Wine. This particular patch does not > impact Netflix, but it does impact a number of other PlayReady > streaming services (and a variety of non-streaming sites as well). > Sorry it's taken so long to get back to this, life has been busy > lately. > > With this patch the SIO_ADDRESS_LIST_CHANGE call gets passed on to > NotifyAddrChange, which effectively fixes a problem where Silverlight > apps can loop forever calling SIO_ADDRESS_LIST_CHANGE (Bug #32328). > Part 2 actually implements the NotifyAddrChange call on Linux, though > this patch is sufficient on its own to resolve the bug since the > overlapped IO event no longer gets triggered. > > This version of the patch has bee updated to include tests that show > that the notification is not tied to the socket. For example, > changing an interface that the socket is not bound to still results in > an overlapped notification. It's worth noting that these tests > require interactive mode and a PC with two network cards, so for my > testing I used an actual (non-VM) Windows 7 box with a wired and a > wireless card. Was this patch already reviewed? Is there anything else take can be done to get it commited? I tested it in 2 different environments (win7 eth+wifi and winxp eth+eht) and the tests work as expected. Regards, Bruno

1 0

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