May 2014 - Wine-devel - list.winehq.org

RFC: "once" FIXME capability
by Erich E. Hoover 14 May '14

14 May '14

While at LinuxTag Sebastian Lackner, Michael Müller, and I were chatting with Michael Stefaniuc and Anastasius Focht about the way we currently implement "one-time FIXME". It was discussed that a more global approach to this was desired, but that it should have the following characteristics: 1) It should work with ANSI C compilers (the variadic macro problem) 2) It should be something that we can disable with a debug channel (something AF would really appreciate that our current ad-hoc approach does not support) 3) It should be expandable to handling a "once per flag" capability Toward that end the three of us have put together several proposed "once" implementations. All three patch-sets are based on variations of the following trick to allow defining in-place static variables without any special compiler requirements: if(1) { \ static int __wine_debug_once = 0; \ int __wine_debug_once_temp = __wine_debug_once; \ if(!__wine_debug_once) __wine_debug_once = 1; \ if(__wine_debug_once_temp == 0) \ goto __WINE_LIMIT_LABEL(__LINE__); \ } else __WINE_LIMIT_LABEL(__LINE__): Here are the various approaches: 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you would use to prefix a FIXME/WARN/etc. The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 3). 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 4). 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits from the ability to turn off limiting on a per-channel basis, which should make it easier to track down problems when an unrelated debug channel is also spamming the console. We'd love to hear which approach everyone likes the most or any feedback you might have. Best, Erich

2 1

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.
by Nikolay Sivov 14 May '14

14 May '14

On 5/14/2014 09:56, Henri Verbeet wrote: > +[ > + local, > + object, > + uuid(a2296057-ea42-4099-983b-539fb6505426) > +] > +interface ID2D1Bitmap : ID2D1Image > +{ > + D2D1_SIZE_F GetSize(); > + D2D1_SIZE_U GetPixelSize(); > + D2D1_PIXEL_FORMAT GetPixelFormat(); > + void GetDpi( > + [out] float *dpi_x, > + [out] float *dpi_y > + ); > + HRESULT CopyFromBitmap( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1Bitmap *bitmap, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromRenderTarget( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1RenderTarget *render_target, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromMemory( > + [in, optional] const D2D1_RECT_U *dst_rect, > + [in] const void *src_data, > + [in] UINT32 pitch > + ); > +} > + > I don't think it makes sense to match msdn here regarding [optional] attribute, and that's why: - 'optional' without 'defaultvalue' has no effect on headers, as far as I can see; - you can't mix 'optional' with required arguments like that, midl will refuse to process such idl, optional arguments should be at the end of arguments list only; - msdn says that it only applies to VARIANT and VARIANT* types, not sure about that, probably it's meant to talk about typelib generation only. And we don't need a typelib for d2d1 anyway. It makes sense imo to eventually make widl more midl-compliant adding similar consistency checks, like 'optional' position, also duplicated guids in typelibs come to mind. It's up to you to keep it as it is, just pointing out potential problems.

3 6

Re: [user32] add a dde test for OEM CP
by Marvin 13 May '14

13 May '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7029 Your paranoid android. === w2000pro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1820: Test failed: DdeQueryStringA returned wrong string String dde.c:1831: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wxppro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1820: Test failed: DdeQueryStringA returned wrong string ?" dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w7u (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w8 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom

1 0

Re: oleacc: Add GetStateText implementation (try3)
by Alexandre Julliard 13 May '14

13 May '14

Piotr Caban <piotr(a)codeweavers.com> writes: > +UINT WINAPI GetStateTextW(DWORD state_bit, WCHAR *state_str, UINT state_str_len) > +{ > + DWORD state_id; > + > + TRACE("%x %p %u\n", state_bit, state_str, state_str_len); > + > + state_id = IDS_STATE_MIN; > + while(state_bit) { > + state_id++; > + state_bit /= 2; > + } > + > + if(state_id>=IDS_STATE_MIN && state_id<=IDS_STATE_MAX) { > + UINT ret; > + > + if(state_str) { > + ret = LoadStringW(oleacc_handle, state_id, state_str, state_str_len); > + }else { > + WCHAR tmp; > + ret = LoadStringW(oleacc_handle, state_id, &tmp, 0); > + } > + > + if(!ret && state_str && state_str_len) > + state_str[0] = 0; > + return ret; > + } The id range check doesn't seem very useful. Also it would be worth testing that a 0 length is supposed to return the string pointer the way LoadString does. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes
by Alexandre Julliard 13 May '14

13 May '14

Martin Storsjo <martin(a)martin.st> writes: > Instead of memcpying in whatever uninitialized data there was at > the end of long_nameW, memset the tail of the struct to zero > instead. > > This fixes running cl.exe from MSVC 2013 with native > msvcr120/msvcp120, fixing bug 35335. > > MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to > iterate through the headers in directories in the include path, > and prior to this change, the file names found during iteration > could get a suffix consisting of an uninitialized WCHAR. That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.
by Henri Verbeet 13 May '14

13 May '14

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1458,8 +1457,7 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > int src_pitch = 0; > int dst_pitch = 0; > > - /* In case of P8 the index is stored in the alpha component if the primary render target uses P8. */ > - if (format->id == WINED3DFMT_P8_UINT && swapchain_is_p8(surface->resource.device->swapchains[0])) > + if (format->id == WINED3DFMT_P8_UINT) > { > gl_format = GL_ALPHA; > gl_type = GL_UNSIGNED_BYTE; This branch is pretty pointless, the format / type for WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If ARB_fragment_program is supported, and the format is supported at all anyway.) > @@ -3256,53 +3252,19 @@ static void read_from_framebuffer(struct wined3d_surface *surface, DWORD dst_loc > switch (surface->resource.format->id) > { > case WINED3DFMT_P8_UINT: > - { > - if (swapchain_is_p8(context->swapchain)) > - { > - /* In case of P8 render targets the index is stored in the alpha component */ > - fmt = GL_ALPHA; > - type = GL_UNSIGNED_BYTE; > - mem = data.addr; > - bpp = surface->resource.format->byte_count; > - } > - else > - { > - /* GL can't return palettized data, so read ARGB pixels into a > - * separate block of memory and convert them into palettized format > - * in software. Slow, but if the app means to use palettized render > - * targets and locks it... > - * > - * Use GL_RGB, GL_UNSIGNED_BYTE to read the surface for performance reasons > - * Don't use GL_BGR as in the WINED3DFMT_R8G8B8 case, instead watch out > - * for the color channels when palettizing the colors. > - */ > - fmt = GL_RGB; > - type = GL_UNSIGNED_BYTE; > - pitch *= 3; > - mem = HeapAlloc(GetProcessHeap(), 0, surface->resource.size * 3); > - if (!mem) > - { > - ERR("Out of memory\n"); > - return; > - } > - bpp = surface->resource.format->byte_count * 3; > - } > - } > - break; > + fmt = GL_ALPHA; > + type = GL_UNSIGNED_BYTE; > + break; > > default: > - mem = data.addr; > fmt = surface->resource.format->glFormat; > type = surface->resource.format->glType; > - bpp = surface->resource.format->byte_count; > } Like above. > if (!srcIsUpsideDown) > { > - UINT len; > /* glReadPixels returns the image upside down, and there is no way to prevent this. > - Flip the lines in software */ > - len = surface->resource.width * bpp; > + * Flip the lines in software. > + * TODO: Consider flipping the image in an FBO. */ Possibly, but that would be a decision for surface_load_sysmem(), not read_from_framebuffer(). Note that reading the front buffer isn't particularly fast on Windows either though. > + row = HeapAlloc(GetProcessHeap(), 0, pitch); > + goto error; This looks unintentional. > @@ -3088,38 +3088,7 @@ DWORD wined3d_format_convert_from_float(const struct wined3d_surface *surface, c > } > > if (format->id == WINED3DFMT_P8_UINT) > - { > - const RGBQUAD *e; > - BYTE r, g, b, a; > - > - if (!surface->palette) > - { > - WARN("Surface doesn't have a palette, returning 0.\n"); > - return 0; > - } > - > - r = (BYTE)((color->r * 255.0f) + 0.5f); > - g = (BYTE)((color->g * 255.0f) + 0.5f); > - b = (BYTE)((color->b * 255.0f) + 0.5f); > - a = (BYTE)((color->a * 255.0f) + 0.5f); > - > - e = &surface->palette->colors[a]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return a; > - > - WARN("Alpha didn't match index, searching full palette.\n"); > - > - for (i = 0; i < 256; ++i) > - { > - e = &surface->palette->colors[i]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return i; > - } > - > - FIXME("Unable to convert color to palette index.\n"); > - > - return 0; > - } > + return (BYTE)((color->a * 255.0f) + 0.5f); So this could just use the table now, right?

2 3

Re: dpnet: Stub interface IDirectPlay8LobbyClient
by Stefan Dösinger 13 May '14

13 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 02:04, schrieb Alistair Leslie-Hughes: > @@ -127,6 +127,7 @@ extern HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkO > extern HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8ThreadPool(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; If you don't use LPJUNK for the iface and UnkOuter (yay :-) ), you might also do it for LPVOID. > +static HRESULT WINAPI lobbyclient_Initialize(IDirectPlay8LobbyClient *iface, PVOID pvUserContext, PFNDPNMESSAGEHANDLER pfn, DWORD dwFlags) No Hungarian notation please (dwFlags, pThisIsAPointer). Also, (L)PJUNK again. > + app = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (NULL == app) { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } Style inconsistency with the rest of the patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcddPAAoJEN0/YqbEcdMwu2oP/iKSBrRhn/4PoGRTAE6hHQsd 4qwWb7WNS+mczHW+ucVfBogFvPkecpUauHWMpEyND3mYp8kli/2BDqtQrovcvabK h5QRqrP3ToRyIm6VMgaijMx4WlrjsZKHKKzW7/k8TxBTAs25OOaBAUC8ihK1A65s lQVywsqPPHuq4u8LzFjr4xE8s5UyZy5tCPYyDFym0otbiRX9+MQJjztFtC3wd8si Fznv681ZTrpR5m3qvcrMn1Eo2mKFvM1Wbi7W58uO2QTEH6BRiMlfd3A/fqVbhCdZ jiYdcDgUSWugOxIoWtaJNzU/mh3oChyPe+WWFXNoPy5W0/wrJHXUbssAW/s5bX1p wRO6rqmbf27rGCFp57oimJMxb/QJT0o+sU2ZdYHv2hjAX7U1csGU6Z3bUQ/KYLlG AztBJBVkTbe9aoIKhsZx/ISHIQ5GYJyY8KntqBOadrziu/I0kzX0ONtDfTdFzkne RhBSXUFjlKxxm17hXyOEftMsD1tkMn74fChJzFOJUo6v3thkH1IcbMhqwNLvj6++ Om2bO4M5Lw77u/9jR84WpFWUh4wUUqgs+v1/VPpt07QTIhwAERU3CiMt1wlkZFvB cyiWm+a3q/GekR1gyyku31bbkqInDRZENDkRl3FXWS/t1Om38j2JgB45mCMEFKCq HoNMnRF44iY4XWaXwd5M =3BFT -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 3)
by Henri Verbeet 12 May '14

12 May '14

On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 96 insertions(+), 23 deletions(-) > This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok ... device.c:4609: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x00060300). And on Windows: device.c:4609: Test failed: Occlusion query returned an unexpected result (0xffff052a). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x0008052a). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x0008052a).

2 1

Re: testbot/log2revtimes: Add a script to extract the VM revert times from the WineTestBot log and prepare them for analysis.
by Francois Gouget 12 May '14

12 May '14

On Mon, 12 May 2014, Francois Gouget wrote: > --- > > I'm using this script to parse the Engine log and generate a CSV files I > can import in a spreadsheet to generate a graph of the VM revert times. > But having it only on my machine feels wrong. So I propose to put it in > the scripts directory (which feels like a sort of contrib directory) so > it can be used by others. And here is the spreadsheet I import the 'CVS' file into: http://fgouget.free.fr/wtb/vm1-revtime.xls.bz2 And the corresponding graphs: * Since the beginning of times This graph shows all the revert times since the new TestBot was put online. The Y axis is logarithmic so the high revert times don't cause all the low ones to be crunched together. Note that the stratification is caused by the 1 second ganularity of the mesurements. I guess it needs an annotation with the different events. http://fgouget.free.fr/wtb/vm1-revtimes-all.png * Since last April This shows the revert times a bit before the VM1 host crashed and went through reconstruction. This confirms my suspicions: the revert times are not very good :-( http://fgouget.free.fr/wtb/vm1-revtimes-recent.png -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 5/5] wined3d: Move get_dc palette updates to ddraw.
by Henri Verbeet 12 May '14

12 May '14

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Note that d3d9 does not support get_dc on D3DFMT_P8. d3d8 and d3d10+ do > not support get_dc at all. That's not strictly true, with d3d10+ you can still get GetDC() / ReleaseDC() through IDXGISurface1. It doesn't give you P8 though. > + if (palette) > + { > + const RGBQUAD *color_table = wined3d_palette_get_rgbquads(palette->wineD3DPalette); > + SetDIBColorTable(*hdc, 0, 256, color_table); > + } ... > +const RGBQUAD * CDECL wined3d_palette_get_rgbquads(const struct wined3d_palette *palette) > +{ > + return palette->colors; > +} That's a pretty terrible interface, it shouldn't be very hard to come up with something better.

1 0