- wine-devel - winehq.org

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

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