September 2013 - Wine-Devel

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

Sept. 17, 2013

-----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 Sept. 17, 2013

Sept. 17, 2013

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 Sept. 17, 2013

Sept. 17, 2013

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 Sept. 17, 2013

Sept. 17, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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 Sept. 16, 2013

Sept. 16, 2013

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