October 2015 - Wine-devel - list.winehq.org

Re: [PATCH 2/5] d3d11: Implement d3d10_device_CreateShaderResourceView1().
by Henri Verbeet 19 Oct '15

19 Oct '15

On 19 October 2015 at 01:41, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static HRESULT STDMETHODCALLTYPE d3d10_device_CreateShaderResourceView1(ID3D10Device1 *iface, > + ID3D10Resource *resource, const D3D10_SHADER_RESOURCE_VIEW_DESC1 *desc, ID3D10ShaderResourceView1 **view); Things like this are always a bit awkward because on the one hand you'd like to preserve the vtbl order, while on the other you'd like to avoid forward declarations. I think it's better to just move the implementation of d3d10_device_CreateShaderResourceView1() to be above d3d10_device_CreateShaderResourceView().

1 0

Re: [RFC PATCH 2/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
by Nikolay Sivov 19 Oct '15

19 Oct '15

On 18.10.2015 22:20, Martin Storsjo wrote: > +EXTRADEFS = -D_MT -D_MSVCR_VER=140 -DVCRUNTIME Is it not enough to have MSVCR_VER only? E.g. is it possible to have MSVCR_VER defined to 140 and undefined VCRUNTIME at the same time? > + case DLL_PROCESS_ATTACH: > +// msvcrt_init_exception(hinstDLL); > + if(!msvcrt_init_tls()) { Debug leftovers? > diff --git a/dlls/msvcrt/main-vcruntime.c b/dlls/msvcrt/main-vcruntime.c > new file mode 100644 > index 0000000..ccbe6a9 > --- /dev/null > +++ b/dlls/msvcrt/main-vcruntime.c This looks like a workaround to me. Will it work to duplicate this in vcruntime140 or consolidate it in some way making it usable from msvcrt and vcruntime*?

2 3

Re: patches: Make Author and Reviewer titles centered
by Nikolay Sivov 19 Oct '15

19 Oct '15

I'm not sure if it's better when centered to be honest. I personally find it easier to read when names are left aligned, same as with subject field. Other fields have limited number of possible values (or fixed char length for a long period of time), so it's not that jumpy when centered. In any case looks like Reviewer fields uses same 'author' class, so only that need changes to do what you want.

2 1

Re: [PATCH 4/5] ddraw: Accept all 3 versions of D3DFINDDEVICERESULT
by Stefan Dösinger 18 Oct '15

18 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-04 um 19:52 schrieb Andrew D'Addesio: > + /* Write ddHwDesc */ > + desc_ptr = (BYTE*)&fdr->ddHwDesc; > + memcpy(desc_ptr, &desc1, desc_size); > + ((D3DDEVICEDESC*)desc_ptr)->dwSize = desc_size; > + > + /* Write ddSwDesc */ > + desc_ptr += desc_size; > + memcpy(desc_ptr, &desc1, desc_size); > + ((D3DDEVICEDESC*)desc_ptr)->dwSize = desc_size; Is there a nicer way? I can't think of one to be honest, but this code feels somewhat unsatisfying. Also I guess we're lucky that all versions of D3DDEVICEDESC have a DWORD-aligned size, so we don't have to worry about padding between them. Native ddraw doesn't support d3d in 64 bit. Ours does though, mostly out of laziness. Did you run the test in a 64 bit build? It might fail due to different struct alignment. > + /* Invalid D3DDEVICEDESC sizes should fail */ > + search.dwSize = sizeof(search); > + search.dwFlags = 0; > + clear_device_result(&result, (D3D1_DESC_SIZE-4), (D3D1_DESC_SIZE-4)); > hr = IDirect3D_FindDevice(Direct3D1, &search, &result); > - ok(hr == D3D_OK, > - "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > + ok(hr == DDERR_INVALIDPARAMS, > + "Expected IDirect3D1::FindDevice to return DDERR_INVALIDPARAMS, got 0x%08x\n", hr); What happens when you use something between D3D1_DESC_SIZE and D3D2_DESC_SIZE, or e.g. the largest size + 4? I recommend to put the valid and invalid tests in a table together with an expect HRESULT. That way you don't have to duplicate the structure assignment code + FindDevice call and can just iterate over the table. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWEiUOAAoJEN0/YqbEcdMwTCgP/AqlzZ9yyJktv2U+OTgxVGTU 9tj/ZbsKIVk7S0FQFDvyUaKCmP7CcYH+ARoJapn7it6peMdNKHB7zbAgsR7koWph hKECmx+xJ4w4Fjvkj159XYL28DokEHqDmZeaeghwldPbCcXTMO5BulJrooO5F1MI Q2/lwhr+pOO3EDOlLvvLntrOszuYJdy0CbWB34ORlV0PQfk/7Wwm+9rkDzVTDS4r xnpNAzEPaFHNrlhmXlaoFa6arsKTILcwhpmt6wzXTMhcyGs8NRcHA1F5lgIbnH3X m6q84FI5Law/epfKwJSyXTI1eDdWB0PKGqw+xEUv4T79q8oRVRe+W/Sjvq9bluEa fDYshHOP2uVRQ0kcObqSTx9iOWW9RtCdTdHxhloHDOOPIAJyxyoENOkYV/5V+QBT P3pKUG9qjNFODFxQvHb6rvbUisVUXGPihC1fbdAkoNYD4Mf2V5rZ+K88RgXQmofS +zbxziLAr6ItmeCw4/nAvt3/8HoQAtWkF7Bb6ZxhtViOzRraNkLvjqPtJ1HAmz8F TueLADA2bRXpGmkW+9bjLbQ0Z6aK2fqQHYy4Rmkt1LJwGSqrMz5ctq63XChZgA+G +c2OXfvcC+zJsVfLxFHmPjPv1eQ0CQ3gyssjRVGPXq9JAQNHqJxm4ldK5e/dJcTS VBxzcIjMMFVLld6a+dS5 =TBrC -----END PGP SIGNATURE-----

3 5

Re: msrle32/tests: Add uncompressed video tests using MRLE as codec (try 2)
by Nikolay Sivov 18 Oct '15

18 Oct '15

On 18.10.2015 19:47, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > try 2: > Create the required video file on runtime, I squeezed the avi file as > much as I could to make it still functional. I don't think blob in sources is better. Clean way is to have a separate avi file, compile it as resource, and create temporary file from resource. That's how it's already done in qedit/tests, and in gdi32/dwrite for font files. And of course ideally it should be as small as possible, that has improved significantly from try1 (~450 bytes vs 20K). > > original: > While studying bug https://bugs.winehq.org/show_bug.cgi?id=33022 I > noticed that the game mouse cursors are stored in an uncompressed AVI > file, wine currently is not able to process such videos as ICLocate > will fail without finding a valid codec. > > Windows always returns the MRLE codec in such cases so this test opens > an uncompressed video and use explicitly MRLE to check if it is able > to decompress the video and it does. > > > >

1 0

Re: msrle32/tests: Add uncompressed video tests using MRLE as codec (try 2)
by Marvin 18 Oct '15

18 Oct '15

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=17431 Your paranoid android. === w8 (32 bit msrle) === msrle.c:174: Test failed: Expected non-NULL frame data msrle.c:176: Test failed: Expected non-NULL frame data === w864 (32 bit msrle) === msrle.c:174: Test failed: Expected non-NULL frame data msrle.c:176: Test failed: Expected non-NULL frame data === w1064 (32 bit msrle) === msrle.c:174: Test failed: Expected non-NULL frame data msrle.c:176: Test failed: Expected non-NULL frame data === w864 (64 bit msrle) === msrle.c:174: Test failed: Expected non-NULL frame data msrle.c:176: Test failed: Expected non-NULL frame data === w1064 (64 bit msrle) === msrle.c:174: Test failed: Expected non-NULL frame data msrle.c:176: Test failed: Expected non-NULL frame data

1 0

Undocumented Toolbar common control message is now documented by Microsoft
by Alan Feldman 18 Oct '15

18 Oct '15

Hello Wine developers, I don't know if you guys are interested in this or not, but I figured I'd let you know that Microsoft has now documented one of the undocumented toolbar messages. include/commctrl.h (Wine) #define TB_UNKWN45D (WM_USER + 93) include\um\commctrl.h (Windows) #define TB_SETBOUNDINGSIZE (WM_USER + 93) TB_SETBOUNDINGSIZE message https://msdn.microsoft.com/en-us/library/ee663584(v=vs.85).aspx << Sets the bounding size for a multi-column toolbar control. >> That would mean you could also make the corresponding changes to this code as well: dlls/comctl32/toolbar.c case TB_UNKWN45D: return TOOLBAR_Unkwn45D(hwnd, wParam, lParam); /* UNDOCUMENTED MESSAGE: This appears to set some kind of size. Perhaps it * is the maximum size of the toolbar? */ static LRESULT TOOLBAR_Unkwn45D(HWND hwnd, WPARAM wParam, LPARAM lParam) Anyway, just figured I'd share that with you guys. Cheers, Alan Feldman

2 1

Re: fltmgr.sys: add FltInitializePushLock stub (try 3)
by Dmitry Timoshkov 17 Oct '15

17 Oct '15

Austin English <austinenglish(a)gmail.com> wrote: > +void WINAPI FltInitializePushLock(EX_PUSH_LOCK *lock) > +{ > + FIXME("(%p): stub\n", lock); > +} > diff --git a/include/ddk/ntifs.h b/include/ddk/ntifs.h > index a8d90a1..8d22d41 100644 > --- a/include/ddk/ntifs.h > +++ b/include/ddk/ntifs.h > @@ -19,6 +19,9 @@ > #ifndef __NTIFS_H__ > #define __NTIFS_H__ > > +#define EX_PUSH_LOCK ULONG_PTR > +#define PEX_PUSH_LOCK PULONG_PTR I'd guess that's not what Alexandre meant with an opaque pointer (anyway 'ULONG_PTR *' and 'ULONG_PTR' are two different things, not sure what you tried to achieve with any of them), you may try with 'void *' instead. -- Dmitry.

1 0

Re: [PATCH] configure: Check for linker relocation support before relying on prelink
by Marcus Meissner 17 Oct '15

17 Oct '15

On Fri, Oct 16, 2015 at 10:21:50AM -0500, Michael Cronenworth wrote: > Prelink was used to rewrite binares and set their text segment, but > modern linkers support setting the value at link time. Prelink is > being retired by upstream. > > Signed-off-by: Michael Cronenworth <mike(a)cchtml.com> Can confirm it works on SUSE too. Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > configure.ac | 11 ++++++++--- > tools/winegcc/winegcc.c | 11 +++++++++-- > 2 files changed, 17 insertions(+), 5 deletions(-) > > diff --git a/configure.ac b/configure.ac > index de8cde5..f283802 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -988,10 +988,15 @@ wine-installed: main.o > *) LDEXECFLAGS="$LDEXECFLAGS -Wl,--section-start,.interp=0x7bf00400" ;; > esac > ]) > - AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin $PATH]) > - if test "x$PRELINK" = xfalse > + WINE_TRY_CFLAGS([-Wl,-Ttext-segment=0x7bc00000], > + [HAVE_TTEXT_SEGMENT="yes"]) > + if test "x$HAVE_TTEXT_SEGMENT" != "xyes" > then > - WINE_WARNING([prelink not found, base address of core dlls won't be set correctly.]) > + AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin $PATH]) > + if test "x$PRELINK" = xfalse > + then > + WINE_WARNING([prelink not found and linker does not support relocation, base address of core dlls won't be set correctly.]) > + fi > fi > ;; > esac > diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c > index 3b2794e..4acd12d 100644 > --- a/tools/winegcc/winegcc.c > +++ b/tools/winegcc/winegcc.c > @@ -1134,6 +1134,12 @@ static void build(struct options* opts) > } > break; > default: > + /* Try option first, modern linkers support this */ > + if (opts->image_base && > + !try_link(opts->prefix, link_args, strmake("-Wl,-Ttext-segment=%s", opts->image_base))) > + { > + strarray_add(link_args, strmake("-Wl,-Ttext-segment=%s", opts->image_base)); > + } > break; > } > > @@ -1167,8 +1173,9 @@ static void build(struct options* opts) > spawn(opts->prefix, link_args, 0); > strarray_free (link_args); > > - /* set the base address */ > - if (opts->image_base && !opts->target) > + /* set the base address with prelink if linker support is not present */ > + if (opts->image_base && !opts->target && > + try_link(opts->prefix, link_args, strmake("-Wl,-Ttext-segment=%s", opts->image_base))) > { > const char *prelink = PRELINK; > if (prelink[0] && strcmp(prelink,"false")) > -- > 2.4.3 > > > >

1 0

Re: [1/2] msrle32/tests: Add uncompressed video tests using MRLE as codec (resend)
by Marvin 17 Oct '15

17 Oct '15

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=17422 Your paranoid android. === build (build) === Make failed

4 4