- wine-devel - winehq.org

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)
by Stefan Dösinger 29 May '15

29 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There's one major problem I missed previously: Am 2015-05-29 um 10:22 schrieb Alistair Leslie-Hughes: > + case DPNA_DATATYPE_STRING: > + memcpy(pvBuffer, &entry->data.string, entry->size); > + break; This won't work. There's a & too much. Please consider adding tests for String and Binary types to catch this kind of thing. GetComponentByName once had the same problem I believe. Minor stuff: > + TRACE("(%p)->(%d %p %p %p %p %p)\n", This, dwComponentID, pwszName, pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); A DWORD is unsigned, %u is better. > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + *pdwDataType = entry->type; > + return DPNERR_BUFFERTOOSMALL; > + } You forgot to add a WARN here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaCrwAAoJEN0/YqbEcdMwypEP/RttOLSqc6fQQW4XeMkBgVaS aiKUyYSysq9MnRoqP32A6lKq9LHpW23liKsvpwoWegdarTc35ENYwG7pLSLJuOIy i/e7AlWGLDphN9qdYMU0oCQ8PXGU8Y3Mb7kozZcnYm9EuYoJEFIiAYHtx4nFeGMj rVx/mruLmYTdgyR378iE4cYqNeMwzK7YtGNRHMPz8FNTzdLyzUu1blYQ8cYEbzAk Mm4RaIixByzKiGO7qUPCX4OOgYoohBOgMRiVWTJfZLrhKY0vyj0x2Jt5GWCzWeht 7mszNRRpvW+v60axT2xwemXmQSobjgjnddF0bwxC/vHZisfXF8H52lLgupXv9KRo efOsvX3lTpJstEL1Wt61NL/MqF4vwRjbrWeKD45DxHEzPX8wzUg4yFodz/yxAAN1 /l4fuX8BEjr9tttV4uup4fdOlVhlX95ZujQFT5Ue1zF97SSLOC9id/8Uy8xlHYmY Ou0H9GG5rILqG5+r9m3OghjuQcwomL6T7BSLYJ+WncdTgtxRbarhMI/mq9m0MiB2 OHkUddm/zn9EFPboQsCjqRuPFa6fcbx+b/XUmyLeBjosO3j7Otws4TGUEkzjbvWF f3fOORfbxpknZH9GxVaEFWlyUerNSJ4C4hYp5J+pHS9N5u+L9KsN0fXYT9jqpvh2 Tmu94XyHSblAoeS1ORgq =M5Sz -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)
by Marvin 29 May '15

29 May '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=13665 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: [PATCH 5/5] wined3d: Always enable GL_PROGRAM_POINT_SIZE in the GLSL backend.
by Henri Verbeet 29 May '15

29 May '15

On 28 May 2015 at 23:23, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6987,6 +7006,13 @@ static void shader_glsl_select(void *shader_priv, struct wined3d_context *contex > GLuint program_id = 0, prev_id = 0; > GLenum old_vertex_color_clamp, current_vertex_color_clamp; > > + if (!ctx_data->backend_init_done) > + { > + gl_info->gl_ops.gl.p_glEnable(GL_PROGRAM_POINT_SIZE); > + checkGLcall("GL_PROGRAM_POINT_SIZE"); > + ctx_data->backend_init_done = TRUE; > + } > + Is this shared state between contexts? Otherwise you need to do this once for every context. Also, shader_glsl_select() is kind of a hot path, it may be better to just add an entry to struct wined3d_shader_backend_ops for this kind of initialization.

2 2

Re: [PATCH 9/11] qcap: add the SmartTee filter automatically as necessary, and test this
by Marvin 28 May '15

28 May '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=13651 Your paranoid android. === w2008s64 (32 bit smartteefilter) === smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 === w2008s64 (64 bit smartteefilter) === smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1926: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154 smartteefilter.c:1985: Test failed: couldn't create NullRenderer, hr=0x80040154

1 0

Re: [PATCH 8/11] qcap: get the SmartTee filter to a minimally functional level
by Marvin 28 May '15

28 May '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=13650 Your paranoid android. === w2000pro (32 bit smartteefilter) === The test timed out

1 0

Re: [PATCH 7/11] qcap: implement the SmartTee allocator functions
by Marvin 28 May '15

28 May '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=13649 Your paranoid android. === w2000pro (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === wxppro (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === w7u (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time === w8 (32 bit smartteefilter) === smartteefilter.c:1366: Test failed: timeout: threads did not receive sample in time

1 0

Re: winex11: Fix ctrl-<symbol> to generate codes below 0x20 where necessary.
by Marvin 28 May '15

28 May '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=13631 Your paranoid android. === wvistau64 (32 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

2 1

Save the Date: WineConf on September 19, 20 in Vienna
by Stefan Dösinger 28 May '15

28 May '15

Hi, I am happy to announce that we will have a WineConf again this year: It will be on Saturday September 19th and Sunday September 20th 2015 in Vienna, in the InterCityHotel Wien. I have added some basic information to http://wiki.winehq.org/WineConf2015 , and more detailed information will follow soon. Please help by suggesting talk topics and adding them to the list. I will write another mail to the list once we have an RSVP page set up. Cheers, Stefan

1 2

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 10)
by Stefan Dösinger 28 May '15

28 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm sorry for the late review. I completely forgot about this patch (also in the private mail you sent me). It looks good to me, except one issue noted below that I missed earlier. Am 2015-05-23 um 13:22 schrieb Alistair Leslie-Hughes: > index 7e10136..bad84ef 100644 > --- a/dlls/dpnet/address.c > +++ b/dlls/dpnet/address.c > @@ -405,9 +405,58 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { > - IDirectPlay8AddressImpl *This = impl_from_IDirectPlay8Address(iface); > - TRACE("(%p): stub\n", This); > - return DPN_OK; > + IDirectPlay8AddressImpl *This = impl_from_IDirectPlay8Address(iface); > + struct component *entry; > + int namesize; > + > + TRACE("(%p)->(%p %p %p %p)\n", This, pwszName, pvBuffer, pdwBufferSize, pdwDataType); You're not tracing dwComponentID and pdwNameLen here. In particular dwComponentID seems important, as it is the thing that the method call retrieves. > + if(!pdwNameLen || !pdwBufferSize || !pdwDataType) > + return DPNERR_INVALIDPOINTER; > + > + if(dwComponentID > This->comp_count) > + return DPNERR_DOESNOTEXIST; As I've noted in other patches it would be a good idea to write a WARN in error cases, especially in a COM method where +relay can't be used to check return values. You can also print the available and required size in case of DPNERR_BUFFERTOSMALL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVZvMGAAoJEN0/YqbEcdMww2sP+gJRvmzLAZ4oXx3FJFSPIvpn JsbdhoKeZkmdsTCPQjvfPVAUKj1qSQcm1w9rRFBthZhkVWNgXGDTbsbTmtVRiATz qqoX+MjKKQeguWmgnEiQY0k/NW15kAvUkP/vT1qQfKOyqadXJs1a6gli0zfqHSqO uviq2P5mQ82vvIYbv5rS8tAGBTh/FHd1802tSPcMGXQqrqqjW3UH/rV4DymP33FF IsSpPBt2niCz7jSt6QGg/8R9Q2xK8D2sOOe1CcLvtRzrh7Ws+j0p1B8Y73aX8047 s7Pp/oUgfmcEUGheeD+c1YlAQOW6Xp9urjiCc9Pqp+sJBv9fJ5p40r9A6wXrP/Jb Zkei91cF+XcwuhZysQX/qJCwff2VyqG55cDdS1R7DTva/DSamhFB6jYrRAjotgrT g4ulnkbVR4khDzJRVk4K9rxJ2OPwoUkPVpspjrKzuT7oEm2U31PVHPUQa8qeIWzr b1vLyDnG/Zz+B27yHc9sLfwZm5olWz2XTDht7kZKGMU2FRy1Q2wK0wZ6Q6ekB/f5 jnnQep7DmgsMe4EN175k5L5e3yW/SISk0U2O/VtukKMbZQ/hoIhHw8ieiaAo16MM S6nvCRbHxRCe9vB/0zKt5+5SAzWrTTsdw03qdeFg82PSGi6I/F7RrrQnY76GtYKB gtjHMs5QPp0FZRriR0T0 =MUbC -----END PGP SIGNATURE-----

1 0

Re: [PATCH] kernel32: Return ERROR_CALL_NOT_IMPLEMENTED in GetUserPreferredUILanguages.
by Alexandre Julliard 28 May '15

28 May '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > On 27/05/15 14:12, Alexandre Julliard wrote: >> Not that it really matters, but I don't see why you'd need to change >> Wine in order to be able to write a test. > > How am I supposed to know if GetUserPreferredUILanguages fails because it's not implemented, > or fails for some other reason? That doesn't matter. You are testing the Windows behavior, so unless there's a Windows version that returns ERROR_CALL_NOT_IMPLEMENTED, you should never need to check for it. Once your test succeeds on Windows, you add todo_wine in places where Wine differs. Whether that's because the function is unimplemented, or because it's implemented but broken, doesn't make any difference as far as the test is concerned. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] msvcp110: Add _File_size implementation and test.
by Piotr Caban 28 May '15

28 May '15

On 05/27/15 04:35, YongHao Hu wrote: > +/* filesystem */ > +static unsigned long long (__cdecl*p_tr2_sys__File_size)(char const*); You should avoid using "long long" type. Please e.g. use ULONGLONG instead. > + mkdir("tr2_test_dir"); > + file = CreateFileA("tr2_test_dir/f1", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > + SetFilePointerEx(file, large, NULL, FILE_BEGIN); > + SetEndOfFile(file); Please test return values of CreateFile, SetFilePointerEx and SetEndOfFile. > + large.LowPart = 4000000000u; > + large.HighPart = 120; > + file = CreateFileA("tr2_test_dir/f2", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > + SetFilePointerEx(file, large, NULL, FILE_BEGIN); > + SetEndOfFile(file); > + val = p_tr2_sys__File_size("tr2_test_dir/f2"); > + ok(val == 519396075520 || broken(val == 0), "file_size is %llu\n", val); /* not enough storage on the testbots */ > + CloseHandle(file); Please remove this test. It's not a good idea to create ~500GB file in the tests. > + val = p_tr2_sys__File_size("tr2_test_dir"); > + ok(val == 0, "file_size is %llu\n", val); > + > + val = p_tr2_sys__File_size("tr2_test_dir/not_exists_file"); > + ok(val == 0, "file_size is %llu\n", val); It would be nice to test GetLastError and errno value after this calls. What happens if NULL is passed as the argument? > +ULONGLONG __cdecl tr2_sys__File_size(const char* path) > +{ > + WIN32_FILE_ATTRIBUTE_DATA fad; Please add a trace message. > + if(!GetFileAttributesExA(path, GetFileExInfoStandard, &fad)) > + return (ULONGLONG)0; This cast is not needed, you can just return 0 here. > + if(fad.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + return (ULONGLONG)0; > + return ((ULONGLONG)(fad.nFileSizeHigh) << (sizeof(fad.nFileSizeLow)*8)) + fad.nFileSizeLow; I think that it's better to simply write 32 instead of sizeof(fad.nFileSizeLow)*8 here. Thanks, Piotr

2 2

Re: libport: Fix build on PowerPC
by Grazvydas Ignotas 27 May '15

27 May '15

On Tue, May 26, 2015 at 11:16 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > It was broken by recent commits > --- > libs/port/interlocked.c | 15 +++++++++++++++ Maybe we could just drop all this powerpc specific code, especially considering missing cmpxchg64 implementation (better use mutex fallback there) and that some other platforms (ARM/ARM64) don't have any of this anyway and just use the fallbacks. Gražvydas

2 1

Re: [PATCH] kernel32: Return ERROR_CALL_NOT_IMPLEMENTED in GetUserPreferredUILanguages.
by Alexandre Julliard 27 May '15

27 May '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > I want to include GetUserPreferredUILanguages in a test I'm writing, but can't at present as > it doesn't return the stub error code. Not that it really matters, but I don't see why you'd need to change Wine in order to be able to write a test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] msvcp110: Add _Equivalent implementation and test.
by Piotr Caban 27 May '15

27 May '15

On 05/27/15 04:36, YongHao Hu wrote: > +static void test_tr2_sys__Equivalent(void) > +{ > + BOOL val; > + int i; > + FILE *file; > + struct { > + char const *file_path1; > + char const *file_path2; > + BOOL equivalent; It will make more sense to define it as int. > + } tests[] = { > + { "f1", "tr2_test_dir", -1 }, > + { "tr2_test_dir", "tr2_test_dir", -1 }, > + { "not_exists_file" , "not_exists_file", -1 }, > + { "tr2_test_dir/./f1", "tr2_test_dir/f2", FALSE }, > + { "tr2_test_dir/f1" , "tr2_test_dir/f1", TRUE }, > + { "tr2_test_dir\\f1", "tr2_test_dir/././f1", TRUE }, > + { "tr2_test_dir/../tr2_test_dir/f1", "tr2_test_dir/f1", TRUE }, Please add following test: { NULL, NULL, ... }, { "not_existing_file", "tr2_test_dir/f1", ... } The tests are also failing when run from VirtualBox share. It's caused by the virtual machine bug (their probably generate a random FileIndexHigh/Low every time file is opened). Could you please create the test files inside temp directory to workaround this bug? Cheers, Piotr

1 0

Re: [PATCH] wined3d: fix color in range comparison
by Stefan Dösinger 27 May '15

27 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-26 um 14:41 schrieb Sergey Isakov: > +#define RED_KEY(x) (x & 0xff0000) > +#define GREEN_KEY(x) (x & 0x00ff00) > +#define BLUE_KEY(x) (x & 0x0000ff) > + return ((RED_KEY(color) >= RED_KEY(color_key->color_space_low_value)) && > + (RED_KEY(color) <= RED_KEY(color_key->color_space_high_value)) && > + (GREEN_KEY(color) >= GREEN_KEY(color_key->color_space_low_value)) && > + (GREEN_KEY(color) <= GREEN_KEY(color_key->color_space_high_value)) && > + (BLUE_KEY(color) >= BLUE_KEY(color_key->color_space_low_value)) && > + (BLUE_KEY(color) <= BLUE_KEY(color_key->color_space_high_value))); > +#undef RED_KEY > +#undef GREEN_KEY > +#undef BLUE_KEY The basic idea is most likely right, but it needs tests. Do you have a game that needs this behavior? The way you're extracting individual colors from the key is wrong. The bitmasks depend on the texture format. The code you're modifying is unused on any modern GPU. On GPUs that support ARB_fragment_program or GLSL we do the color key comparison in the fragment shader nowadays. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVZXSWAAoJEN0/YqbEcdMwbEUP/RM4QUsbdSzhSLyIz5j00Epb AW1ZcNOg61yrfymjHdhJkqfdNmEiKQFsRshD+ZQAxVHqMsZLTxXtRFfBB14WtmNI Ng5jwwiAzDqlmpjftlZ4CmkR1w7DMxH6Nt4e9OQBlDKShSIoGngL6RremV+2Wq+f nNC6HfdmUiAIReVvI2aMm5B9C5L624SKLvoAZNI8QW+HJeZeESSGmT9bx4IRVQwl QX+aKojT43CJwq6UpZRu7ZkniotrmO9aDC+6S3S0od0ZJWSP5Q9upCNWNcN+iPG7 9kCPwZMsEAxNUjvh/wQx8xE1+wiR7Ugjl/X6yTN8HFesFHChrqC2UeHUAkUKU++L WC4kwijfbktKSZnIiSvrTAzWvLOeCZMifFQqm8aqmlOqyvbNwyOJjh6yM/nqZi+c 2aEdEIMY5aaoswDIlyGRRN57zeWtqjZVmg7UzVxmZqfiocmUVxgdmdRv8BvFi0RF R4A6YTDP5EYb33SvH3qQE5kIrtDdtL8qtanmBsuHnhhwd1rdgeeq/9N0tqSjH1GQ s8vsXVmd3qU+mQMzyaxN9Cc9RGxGNgd+g1LkkoPqe+aVUw/JDzvAdMDGpy63zjhM QUlfS771f+Zt43wku/20XP1engXXti4m+KfnSOS3nCdKO1xRKOGHAMlUZzd8+jhU 2rWKuh42D3mSMDk1OhLR =IdO/ -----END PGP SIGNATURE-----

1 0

Re: winedump: Add more image debug types
by Michael Stefaniuc 27 May '15

27 May '15

On 05/26/2015 10:59 PM, André Hentschel wrote: > My main goal is to destroy the ccache from Michael S. ;) Did you just ask for your patch to be Rejected? But I don't mind anymore since I got my new beefy box as compilation is fast enough with that ;-P bye michael > --- > include/winnt.h | 4 ++++ > tools/winedump/pe.c | 8 ++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/include/winnt.h b/include/winnt.h > index b25c25b..4c89750 100644 > --- a/include/winnt.h > +++ b/include/winnt.h

1 0

Re: [PATCH] ntdll/tests: NtOpenFile a directory with NULL ObjectName.
by Marvin 27 May '15

27 May '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=13614 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

programs/regsvr32: Output strings as WCHAR to support non-ascii characters
by Hugh McMaster 27 May '15

27 May '15

On Mon, 25 May 2015 12:06:43 -0300, Bruno Jesus wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=38638 Hi Bruno, Your patch had the unfortunate side-effect of breaking output for almost all resource strings used in regsvr32. The problem is that the names of DLLs and input commands are still in ASCII. Fixing the issue requires more work, as regsvr32 needs to be converted to Unicode first. I wrote patches to do that last year, but Alexandre felt they weren't needed. He said something like, "If it isn't broken, don't fix it". But now there is a problem, as translations are broken. I've rebased the patches against the latest commit base and uploaded them to my Dropbox account. [1] Feel free to use them. Or, if you like, I'll resend them to wine-patches. -- Hugh McMaster [1] https://www.dropbox.com/sh/7j8wh9n0n09znk5/AADz3Fa3oEmtRUhqVG-Kq0kIa?dl=0

2 2

Re: [PATCH 3/8] wined3d: Keep track of renderbuffer capabilities.
by Henri Verbeet 26 May '15

26 May '15

On 22 May 2015 at 10:11, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1145,18 +1151,21 @@ static HRESULT texture_init(struct wined3d_texture *texture, const struct wined3 > /* WINED3DUSAGE_DEPTHSTENCIL needs WINED3DFMT_FLAG_DEPTH or WINED3DFMT_FLAG_STENCIL, not both. */ > > if ((format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & required_flags) == required_flags > - && (!(desc->usage & WINED3DUSAGE_DEPTHSTENCIL) || (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & ds_flags)) > + && check_ds_support(format, WINED3D_GL_RES_TYPE_TEX_2D, desc->usage) > && (gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT] > || (desc->width == pow2_width && desc->height == pow2_height))) > gl_type = WINED3D_GL_RES_TYPE_TEX_2D; > else if ((format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] & required_flags) == required_flags > - && (!(desc->usage & WINED3DUSAGE_DEPTHSTENCIL) || (format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] & ds_flags))) > + && check_ds_support(format, WINED3D_GL_RES_TYPE_TEX_RECT, desc->usage)) > gl_type = WINED3D_GL_RES_TYPE_TEX_RECT; > + else if ((format->flags[WINED3D_GL_RES_TYPE_RB] & required_flags) == required_flags > + && check_ds_support(format, WINED3D_GL_RES_TYPE_RB, desc->usage)) > + gl_type = WINED3D_GL_RES_TYPE_RB; > else > gl_type = WINED3D_GL_RES_TYPE_TEX_2D; /* No error, may be SCRATCH pool or emulated conditional np2. */ > This is kind of ok because the existing code is like this, but notice the similarity to some of the code in resource_init(). In fact, is there any reason the caller needs to pass "gl_type" to resource_init() instead of letting it figure it out on its own? > -static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info) > +static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info, > + enum wined3d_gl_resource_type d3d_type, GLuint *object) > { > - gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, > - GL_TEXTURE_2D, 0, 0); > + switch (d3d_type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + case WINED3D_GL_RES_TYPE_TEX_2D: > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + case WINED3D_GL_RES_TYPE_TEX_3D: > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + gl_info->gl_ops.gl.p_glDeleteTextures(1, object); > + break; > + > + case WINED3D_GL_RES_TYPE_RB: > + gl_info->fbo_ops.glDeleteRenderbuffers(1, object); > + break; > + > + case WINED3D_GL_RES_TYPE_BUFFER: > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > } Why is "object" a pointer?

3 7

GSoC 2015 projects
by Matteo Bruni 26 May '15

26 May '15

Hey all, tomorrow the coding period of the Summer of Code begins and I though it might be a nice idea to let the community know about the projects we've got this year. Actually, I though it would be even better if the student themselves wrote a short summary of their own project for the mailing list. So, with no authority backing me, I'm kindly asking that. No need to write anything too fancy, just a few lines explaining what are you going to work on over the summer and maybe what are the expected benefits for Wine. Thank you! Matteo.

5 4

Re: [PATCH] d3d11.idl: add the basic interfaces to enable video decoding
by Steve Lhomme 26 May '15

26 May '15

On Sun, May 24, 2015 at 8:03 AM, Steve Lhomme <robux4(a)videolabs.io> wrote: > Any update on this patch ? Should I submit again with the one space removed ? I'm sending the updated version. > Steve > > On Wed, May 13, 2015 at 11:06 AM, Steve Lhomme <robux4(a)videolabs.io> wrote: >> On Wed, May 13, 2015 at 1:02 PM, Stefan Dösinger >> <stefandoesinger(a)gmail.com> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, >>> >>> This patch looks better. Ultimately Henri and Alexandre have to decide >>> if they're happy with it. Henri is on vacation this week, so don't >>> expect much movement until Monday. >> >> No problem. >> >>> Am 2015-05-11 um 15:41 schrieb Steve Lhomme: >>>> +interface ID3D11VideoDecoderOutputView : ID3D11View >>>> +{ >>>> + void GetDesc( >>>> + [out] D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc ); >>>> +} >>> There's a space that doesn't match the rest of the patch, but does match >>> what's in the MS headers. Since it is the only case I can spot I think >>> it's a typo in a self-typed header rather than a missed fixup in a >>> copypasted header. >> >> Should I resubmit without the extra space ? >> >>> You don't have to use the same parameter names in Methods or functions. >>> Instead of "pDesc" you can e.g. use "desc". The rest of the header >>> already uses pCrap though, so I'm ok with the current way. >> >> I checked the other d3d IDL files in the repo to match what's already >> in use and pDesc is very common, for example in d3d10.idl. >> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQIcBAEBAgAGBQJVUy8wAAoJEN0/YqbEcdMwXHwQAJd+LDxvH03XR5L/+bpxZB/o >>> U6g7cgMmtkklfSeCazZrUe0R5ZZExbmmIN+bBr6GJpbQezVQW3vng9EQj6ihfBjf >>> 6CEKr9BJF/xOhYdHPrhg3yxaD9MZrnsXa9llNFGds6SI0q1L8uCclyAuPxV+AoSO >>> fxgElN7/+LCRTwEM9shdwuxVELrikW52UmVTEajhNematVixplOh6pJMe+8XyPp/ >>> iSn+6p/jBeytKzjb83uUnyGqVaFLOIg9ywR2PPeA43RvNYVnfV9agxeOGJYvO7Zw >>> mKWmv+fG9sIXzvF/G9upnceE69YHf8WoIdEHW+kZsOl2ctRRB4ycBHp0rG4s2IeH >>> f1XpENP55lT+dYIc/Tef8IdpABzmGD7JwtnbLyxRbF4F9Qwfe6x7GP3VtEBp1M/+ >>> 5nePonYZ4N55sShelaU8X7/JxUuZb8onlz1UfEXJkIykopyQJJw49rXkQv7OFm2k >>> xyJAsXCQk5Z9sqXXBuFxUnKkip9P8UaLOwFJ8WFUVgHrkS9UAceiehUKgvpcwYfX >>> vxh48j6gAE4fBEUBVOlXiR4lMV7cDUWIoJdCopUkzxysPMp/hi3BcDk7EdrF9LX9 >>> c01jQc2N+JwzjIyNhSC01Jk23Qp2lOG+pUT1UrKcACesoB1H6Zm3QbNv5hVgUfkz >>> pFuJsryqPWxQFS02SvTu >>> =ToVh >>> -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] Add the GUID definition of DXGI_DEBUG_D3D11
by Steve Lhomme 26 May '15

26 May '15

Any update on this patch ? Thanks On Tue, May 12, 2015 at 4:24 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: > --- > According to https://msdn.microsoft.com/en-us/library/windows/desktop/hh780344%28v=vs.85… > --- > include/d3d11sdklayers.idl | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/d3d11sdklayers.idl b/include/d3d11sdklayers.idl > index 638e53c..f21d11e 100644 > --- a/include/d3d11sdklayers.idl > +++ b/include/d3d11sdklayers.idl > @@ -20,6 +20,8 @@ import "oaidl.idl"; > import "ocidl.idl"; > import "d3d11.idl"; > > +cpp_quote("DEFINE_GUID(DXGI_DEBUG_D3D11, 0x4b99317b, 0xac39, 0x4aa6, 0xbb, 0x0b, 0xba, 0xa0, 0x47, 0x84, 0x79, 0x8f);") > + > typedef enum D3D11_MESSAGE_CATEGORY { > D3D11_MESSAGE_CATEGORY_APPLICATION_DEFINED, > D3D11_MESSAGE_CATEGORY_MISCELLANEOUS, > -- > 2.4.0 > > >

1 0

Re: [PATCH 2/2] Add dxgidebug.idl
by Steve Lhomme 26 May '15

26 May '15

Any update on this patch ? Thanks On Tue, May 12, 2015 at 4:24 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: > --- > Useful to debug DXGI leaks > See https://msdn.microsoft.com/en-us/library/windows/desktop/hh780352%28v=vs.85… > --- > include/Makefile.in | 1 + > include/dxgidebug.idl | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 45 insertions(+) > create mode 100644 include/dxgidebug.idl > > diff --git a/include/Makefile.in b/include/Makefile.in > index ad87f47..d496bd8 100644 > --- a/include/Makefile.in > +++ b/include/Makefile.in > @@ -42,6 +42,7 @@ PUBLIC_IDL_H_SRCS = \ > dwrite_2.idl \ > dxgi.idl \ > dxgi1_2.idl \ > + dxgidebug.idl \ > dxva2api.idl \ > endpointvolume.idl \ > exdisp.idl \ > diff --git a/include/dxgidebug.idl b/include/dxgidebug.idl > new file mode 100644 > index 0000000..94f57da > --- /dev/null > +++ b/include/dxgidebug.idl > @@ -0,0 +1,44 @@ > +/* > + * Copyright 2015 Steve Lhomme > + * > + * This library 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. > + * > + * This library 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 this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +import "oaidl.idl"; > + > +cpp_quote("DEFINE_GUID(DXGI_DEBUG_ALL, 0xe48ae283, 0xda80, 0x490b, 0x87, 0xe6, 0x43, 0xe9, 0xa9, 0xcf, 0xda, 0x08);") > +cpp_quote("DEFINE_GUID(DXGI_DEBUG_DX, 0x35cdd7fc, 0x13b2, 0x421d, 0xa5, 0xd7, 0x7e, 0x44, 0x51, 0x28, 0x7d, 0x64);") > +cpp_quote("DEFINE_GUID(DXGI_DEBUG_DXGI, 0x25cddaa4, 0xb1c6, 0x47e1, 0xac, 0x3e, 0x98, 0x87, 0x5b, 0x5a, 0x2e, 0x2a);") > +cpp_quote("DEFINE_GUID(DXGI_DEBUG_APP, 0x06cd6e01, 0x4219, 0x4ebd, 0x87, 0x90, 0x27, 0xed, 0x23, 0x36, 0x0c, 0x62);") > + > +typedef enum DXGI_DEBUG_RLO_FLAGS { > + DXGI_DEBUG_RLO_SUMMARY = 0x0001, > + DXGI_DEBUG_RLO_DETAIL = 0x0002, > + DXGI_DEBUG_RLO_IGNORE_INTERNAL = 0x0004, > + DXGI_DEBUG_RLO_ALL = 0x0007 > +} DXGI_DEBUG_RLO_FLAGS; > + > +[ > + object, > + local, > + uuid(119e7452-de9e-40fe-8806-88f90c12b441) > +] > +interface IDXGIDebug : IUnknown > +{ > + HRESULT ReportLiveObjects( > + [in] GUID apiid, > + [in] DXGI_DEBUG_RLO_FLAGS flags); > +} > + > -- > 2.4.0 > > >

1 0

Re: [PATCH 3/4] riched20: Initial support for changing font properties
by Marvin 26 May '15

26 May '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=13591 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wxppro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2003std (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w8 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700

1 0

Re: msvcirt: Share exceptions implementation with msvcp
by Alexandre Julliard 26 May '15

26 May '15

Iván Matellanes <matellanesivan(a)gmail.com> writes: > This is the first patch of my GSoC project :) > It implements the exceptions in msvcirt by using the code in msvcp90. > @@ -304,13 +304,15 @@ typedef enum __exception_type { > EXCEPTION_RERAISE, > EXCEPTION, > EXCEPTION_BAD_ALLOC, > - EXCEPTION_BAD_CAST, > EXCEPTION_LOGIC_ERROR, > +#ifndef _MSVCIRT > EXCEPTION_LENGTH_ERROR, > EXCEPTION_OUT_OF_RANGE, > EXCEPTION_INVALID_ARGUMENT, > EXCEPTION_RUNTIME_ERROR, > EXCEPTION_FAILURE, > + EXCEPTION_BAD_CAST, > +#endif Please avoid as many ifdefs as possible. For instance, having extra enums or unexported functions doesn't do any harm, so there's no reason to make a special case for them. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/4] riched20: Implement tomTrackParms/tomCacheParms
by Marvin 26 May '15

26 May '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=13590 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wxppro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2003std (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w8 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700

1 0

Re: [PATCH 1/4] riched20: Support ITextFont instances detached from a range
by Marvin 26 May '15

26 May '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=13589 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wxppro (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2003std (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w8 (32 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === wvistau64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 === w2008s64 (64 bit richole) === richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700 richole.c:1838: Test failed: got -1 richole.c:1939: Test failed: got 700

1 0

Re: [2/3] widl: Fix handling of circular imports that involve the file passed on the command line.
by Alexandre Julliard 25 May '15

25 May '15

Francois Gouget <fgouget(a)free.fr> writes: > --- > tools/widl/parser.l | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/widl/parser.l b/tools/widl/parser.l > index b911186..2333687 100644 > --- a/tools/widl/parser.l > +++ b/tools/widl/parser.l > @@ -488,6 +488,9 @@ int do_import(char *fname) > int ptr = import_stack_ptr; > int ret, fd; > > + if (strcmp(import_stack_ptr ? import_stack[0].input_name : input_name, > + fname) == 0) > + return 0; /* initial source file */ This won't work for out-of-tree builds. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/ole32: Silence a FIXME
by Stefan Dösinger 25 May '15

25 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-25 um 07:56 schrieb Hugh McMaster: > This fixme appears on wine init either before console output or > after it. The fixme text is interrupting the output for Wine's > CLI-based programs, making the output difficult to read. WINEDEBUG=-all is the best way to deal with disturbing debug output. Or if you want other fixmes WINEDEBUG=-ole helps for this specific one. Though in many other places trying to QI an unknown interface is a WARN, not a FIXME. Which interface(s) are the application(s) / other libs trying to QI? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVYtuhAAoJEN0/YqbEcdMwaLcP/iP/cWFNiqommeRRFXKpv1GN gCxfqO3H5H/dWlobvFahZ6caZvRg87tw940dO6l9ch3i29A3ooJR0QNmJefk4WBa RGCp+g9lDxqIp9KvsnHGeHN4gdNXdIkNDtTusuDi1HC31MW3Wcl9rL3eCwTLeK3O 6QNTmAgUK+ZJM5xvBcTPMEidqgw2+L8SyjRTS3I84NPa5tZhRWV5gwvglBIKlvlk j2ve5wu7MYMyCU0yadmDyCioLeVzMMvIK1vFTkMbLlWlQc+ni2wgAvjD51ODW9Mg LiJJow6CVnyIF2htAaqs1bVWgtRYiFkHecidliJzqlP3CS11dmys0izy4GCO5nCZ 8vQpvVjHnKjzyrTaHkJJnGXdCSFhcDdjj2VlxrhKZy0C5TUKhsu9HLux3ZZnh8rX 3LX/Di16PgALnx28oAGaA/tkjuutdToZioHVi6V4doRZu1gVQAVdVuqu+jyj8rnR GQfdUbBsMN0sfdm4wzG2Ls+BdPyymq4FtgvMoYjH7Ue3+4smQu0EilmTCHAnQdZU OjF4dUgOqSdenQOWbVJGuiQzabwfxfQVePVlUuse7sthnXf8xAk5CCEBl/ITvYxZ vbORohm8+Xr1yQ9qi7rgRB1ItU3ThrEUFm6DAruIHUtgfiK4zVXczFXh83GXoPur mY9cApML3tVu3Q0S+WtK =5NtD -----END PGP SIGNATURE-----

3 2

Re: [PATCH 5/5] riched20/tests: Initial tests for font duplication behavior
by Marvin 24 May '15

24 May '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=13570 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === wxppro (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === w2003std (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === wvistau64 (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === w2008s64 (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === w8 (32 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === wvistau64 (64 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1 === w2008s64 (64 bit richole) === richole.c:1938: Test failed: got -1 richole.c:1976: Test failed: got -1 richole.c:1986: Test failed: got -1

1 0

Re: [PATCH] d3d11.idl: add the basic interfaces to enable video decoding
by Steve Lhomme 24 May '15

24 May '15

Any update on this patch ? Should I submit again with the one space removed ? Steve On Wed, May 13, 2015 at 11:06 AM, Steve Lhomme <robux4(a)videolabs.io> wrote: > On Wed, May 13, 2015 at 1:02 PM, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> This patch looks better. Ultimately Henri and Alexandre have to decide >> if they're happy with it. Henri is on vacation this week, so don't >> expect much movement until Monday. > > No problem. > >> Am 2015-05-11 um 15:41 schrieb Steve Lhomme: >>> +interface ID3D11VideoDecoderOutputView : ID3D11View >>> +{ >>> + void GetDesc( >>> + [out] D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc ); >>> +} >> There's a space that doesn't match the rest of the patch, but does match >> what's in the MS headers. Since it is the only case I can spot I think >> it's a typo in a self-typed header rather than a missed fixup in a >> copypasted header. > > Should I resubmit without the extra space ? > >> You don't have to use the same parameter names in Methods or functions. >> Instead of "pDesc" you can e.g. use "desc". The rest of the header >> already uses pCrap though, so I'm ok with the current way. > > I checked the other d3d IDL files in the repo to match what's already > in use and pDesc is very common, for example in d3d10.idl. > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBAgAGBQJVUy8wAAoJEN0/YqbEcdMwXHwQAJd+LDxvH03XR5L/+bpxZB/o >> U6g7cgMmtkklfSeCazZrUe0R5ZZExbmmIN+bBr6GJpbQezVQW3vng9EQj6ihfBjf >> 6CEKr9BJF/xOhYdHPrhg3yxaD9MZrnsXa9llNFGds6SI0q1L8uCclyAuPxV+AoSO >> fxgElN7/+LCRTwEM9shdwuxVELrikW52UmVTEajhNematVixplOh6pJMe+8XyPp/ >> iSn+6p/jBeytKzjb83uUnyGqVaFLOIg9ywR2PPeA43RvNYVnfV9agxeOGJYvO7Zw >> mKWmv+fG9sIXzvF/G9upnceE69YHf8WoIdEHW+kZsOl2ctRRB4ycBHp0rG4s2IeH >> f1XpENP55lT+dYIc/Tef8IdpABzmGD7JwtnbLyxRbF4F9Qwfe6x7GP3VtEBp1M/+ >> 5nePonYZ4N55sShelaU8X7/JxUuZb8onlz1UfEXJkIykopyQJJw49rXkQv7OFm2k >> xyJAsXCQk5Z9sqXXBuFxUnKkip9P8UaLOwFJ8WFUVgHrkS9UAceiehUKgvpcwYfX >> vxh48j6gAE4fBEUBVOlXiR4lMV7cDUWIoJdCopUkzxysPMp/hi3BcDk7EdrF9LX9 >> c01jQc2N+JwzjIyNhSC01Jk23Qp2lOG+pUT1UrKcACesoB1H6Zm3QbNv5hVgUfkz >> pFuJsryqPWxQFS02SvTu >> =ToVh >> -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 10)
by Marvin 23 May '15

23 May '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=13560 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: [3/3] ws2_32: Add WSAPoll() implementation
by Marvin 23 May '15

23 May '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=13559 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

WineConf 2015
by Tom Wickline 22 May '15

22 May '15

I posted this on the wineconf mailing list but I'm not sure everyone is currently subscribed to that list so I'm posting here as well. Their is a Facebook page setup for anyone interested in WineConf 2015 to confirm their attendance, post to page, like, invite etc etc. https://www.facebook.com/events/734919546617361/ Cheers, Tom

1 0

Re: [1/2] include: Add stuff related to WSAPoll()
by Bruno Jesus 22 May '15

22 May '15

Please ignore the series, it seems to break ws2_32 due to multiple definitions for struct pollfd. Any ideas what can I do to fix this? Like what #ifdef could be used to prevent it? Best wishes, Bruno On Thu, May 21, 2015 at 3:52 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >

1 1

Re: [1/2] ntdll: Implement RtlUnicodeToUTF8N.
by Nikolay Sivov 22 May '15

22 May '15

Any reason you can't use wine_utf8_mbstowcs/wine_utf8_wcstombs ?

1 0

Re: [PATCH 3/3] riched20/tests: Added tests for ITextFont getters on detached font
by Marvin 21 May '15

21 May '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=13520 Your paranoid android. === wvistau64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF57FACFA === w2008s64 (64 bit richole) === richole: unhandled exception c0000005 at 000007FEF648ACFA

1 0

Re: [PATCH 1/2] msvcp120: Added _Call_once implementation
by Nikolay Sivov 21 May '15

21 May '15

On 20.05.2015 23:18, Piotr Caban wrote: > --- > dlls/msvcp110/msvcp110.spec | 4 +-- > dlls/msvcp120/msvcp120.spec | 4 +-- > dlls/msvcp120/tests/msvcp120.c | 55 > +++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 4 +-- > dlls/msvcp90/misc.c | 35 +++++++++++++++++++++++ > 5 files changed, 96 insertions(+), 6 deletions(-) > > You sure it's not a wrapper around InitOnce* calls from kernel32?

2 1

Re: [PATCH] winex11drv: Fix uninitialized memory access appearing in multiple tests (Valgrind) (resend)
by Nikolay Sivov 21 May '15

21 May '15

On 05/21/2015 08:05 AM, efbiaiinzinz(a)hotmail.com wrote: > From: Indrek Altpere <efbiaiinzinz(a)hotmail.com> > > --- > dlls/winex11.drv/window.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c > index 06e2294..de39a44 100644 > --- a/dlls/winex11.drv/window.c > +++ b/dlls/winex11.drv/window.c > @@ -701,6 +701,7 @@ static void set_size_hints( struct x11drv_win_data *data, DWORD style ) > static void set_mwm_hints( struct x11drv_win_data *data, DWORD style, DWORD ex_style ) > { > MwmHints mwm_hints; > + memset(&mwm_hints, 0, sizeof(mwm_hints)); > > if (data->hwnd == GetDesktopWindow()) > { > This looks too much, isn't it enough to just set input_mode = 0 once, before making a call?

2 1

widl problem in argument ordering
by Marcus Meissner 21 May '15

21 May '15

Hi, Coverity issue "CID 1299032 Explicit null dereferenced" shows I think a problem of the widl generated stub marshaller. The IDL is: interface IAccIdentity : IUnknown { HRESULT GetIdentityString([in] DWORD idchild, [out, size_is(*string_len)] BYTE **str, [out] DWORD *string_len); } the generated stub is: void __RPC_STUB IAccIdentity_GetIdentityString_Stub( IRpcStubBuffer* This, IRpcChannelBuffer *_pRpcChannelBuffer, PRPC_MESSAGE _pRpcMessage, DWORD* _pdwStubPhase) { struct __frame_IAccIdentity_GetIdentityString_Stub __f, * const __frame = &__f; __frame->_This = (IAccIdentity*)((CStdStubBuffer*)This)->pvServerObject; NdrStubInitialize(_pRpcMessage, &__frame->_StubMsg, &Object_StubDesc, _pRpcChannelBuffer); RpcExceptionInit( 0, __finally_IAccIdentity_GetIdentityString_Stub ); __frame->str = 0; __frame->string_len = 0; RpcTryFinally { if ((_pRpcMessage->DataRepresentation & 0xffff) != NDR_LOCAL_DATA_REPRESENTATION) NdrConvert( &__frame->_StubMsg, &__MIDL_ProcFormatString.Format[216]); __frame->_StubMsg.Buffer = (unsigned char *)(((ULONG_PTR)__frame->_StubMsg.Buffer + 3) & ~0x3); if (__frame->_StubMsg.Buffer + sizeof(DWORD) > __frame->_StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } __frame->idchild = *(DWORD *)__frame->_StubMsg.Buffer; __frame->_StubMsg.Buffer += sizeof(DWORD); __frame->str = NdrAllocate(&__frame->_StubMsg, *__frame->string_len * 4); // DEREFERENCED memset(__frame->str, 0, *__frame->string_len * 4); __frame->string_len = &__frame->_W0; // ACTUALLY initialized __frame->_W0 = 0; Not that __frame->string_len is dereferenced before it is set to &__frame->_W0. There seems to be a bit of an ordering problem here? Ciao, Marcus

2 1

Re: [PATCH] rpcrt4: make sure we do not have *data allocated on error (Coverity)
by Michael Stefaniuc 20 May '15

20 May '15

On 05/20/2015 04:50 PM, Marcus Meissner wrote: > 713688 Resource leak > > callers expect *data only allocated when success is returned. > --- > dlls/rpcrt4/rpc_transport.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c > index 34f434d..4080b14 100644 > --- a/dlls/rpcrt4/rpc_transport.c > +++ b/dlls/rpcrt4/rpc_transport.c > @@ -2359,6 +2359,7 @@ static RPC_STATUS rpcrt4_http_read_http_packet(HINTERNET request, RpcHttpAsyncDa > if (!RPCRT4_IsValidHttpPacket(hdr, *data, data_len)) > { > ERR("invalid http packet\n"); > + if (*data) HeapFree(GetProcessHeap(), 0, *data); Marcus, you don't need the if not NULL check as HeapFree(NULL) is a no-op. bye michael

1 0

Re: [PATCH 2/4] ntdll: If read_directory_getattrlist() finds that the file doesn't exist, return successful "no file" result to stop search.
by Matteo Bruni 20 May '15

20 May '15

---- diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 0e5af8a..42e1842 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -2185,6 +2185,11 @@ static int read_directory_getattrlist( int fd, IO_STATUS_BLOCK *io, void *buffer } else io->u.Status = STATUS_NO_MORE_FILES; } + else if (errno == ENOENT || errno == ENOTDIR) + { + io->u.Status = STATUS_NO_MORE_FILES; + ret = 0; + } } else ret = -1; ---- Actually that's how my patch originally looked like (http://source.winehq.org/patches/data/111375) but then I realized that would break if the filesystem is case-sensitive, since it would return the file as missing while it might be present with a different name casing. I haven't actually tested it though.

2 3

Re: [PATCH 4/4] ntdll: Fix read_directory_getattrlist() to get the name of a symlink rather than its target, but still detect if the symlink is broken.
by Matteo Bruni 20 May '15

20 May '15

2015-05-20 20:40 GMT+02:00 Ken Thomases <ken(a)codeweavers.com>: > --- > dlls/ntdll/directory.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) Not sure it matters in practice but it might be better to check for HAVE_SYS_VNODE_H in both the definition of and the call to read_directory_getattrlist().

2 1

Re: [PATCH] kernel32: Implement a few more classes in GetFileInformationByHandleEx
by Marvin 20 May '15

20 May '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=13506 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: msvcr120: Add erf functions (try 2)
by Alexandre Julliard 20 May '15

20 May '15

Daniel Lehman <dlehman(a)esri.com> writes: > @@ -73,6 +73,32 @@ int CDECL MSVCRT__set_SSE2_enable(int flag) > return sse2_enabled; > } > > +#if _MSVCR_VER>=120 > +/********************************************************************* > + * erff (MSVCRT.@) > + */ > +float CDECL MSVCRT_erff( float num ) > +{ > + return erff(num); > +} > + > +/********************************************************************* > + * erf (MSVCRT.@) > + */ > +double CDECL MSVCRT_erf( double num ) > +{ > + return erf(num); > +} Please add configure checks. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/7] riched20: Implement GetFont() for selection range
by Marvin 20 May '15

20 May '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=13500 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] riched20: Implement GetLanguageID()
by Marvin 20 May '15

20 May '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=13499 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] riched20: Implement GetSize()
by Marvin 20 May '15

20 May '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=13498 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] wined3d: Check resource types separately in check_fbo_compat.
by Henri Verbeet 19 May '15

19 May '15

On 16 May 2015 at 15:29, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static void delete_fbo_attachment(const struct wined3d_gl_info *gl_info, > + enum wined3d_gl_resource_type d3d_type) > +{ > + switch (d3d_type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + gl_info->fbo_ops.glFramebufferTexture1D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_1D, 0, 0); > + break; > + > + case WINED3D_GL_RES_TYPE_TEX_2D: > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, > + wined3d_gl_type_to_enum(d3d_type), 0, 0); > + break; > + > + case WINED3D_GL_RES_TYPE_TEX_3D: > + gl_info->fbo_ops.glFramebufferTexture3D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_3D, 0, 0, 0); > + break; > + > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, > + GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB, 0, 0); > + break; > + > + case WINED3D_GL_RES_TYPE_BUFFER: > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > +} > + This is kind of pointless. Any of the FramebufferTexture*() calls with a 0 texture will detach the current attachment. You shouldn't need to detach the current attachment before attaching a new one either, but I suppose the existing code already does that.

2 1

Re: [PATCH 3/5] riched20: Implement GetSize() (resend)
by Marvin 19 May '15

19 May '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=13468 Your paranoid android. === w7u (32 bit richole) === richole.c:1287: Test failed: got weight 400

1 0

Re: [PATCH 2/5] riched20: Implement GetWeight() (resend)
by Marvin 19 May '15

19 May '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=13467 Your paranoid android. === w7u (32 bit richole) === richole.c:1283: Test failed: after 400

1 0

Re: [PATCH 1/5] riched20: Implement GetBold()/GetItalic()
by Marvin 19 May '15

19 May '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=13451 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: kernel32/tests: Add tests for delete behaviour of CopyFileEx.
by Marvin 19 May '15

19 May '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=13465 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: dmusic: Remove "keep in sync with oneself" comments
by Michael Stefaniuc 18 May '15

18 May '15

Hello Frederic, why would you want to do this? Keeping the files identical just allows to copy it as is. Or easily verify it by just checking the SHA1 sum. On 05/18/2015 02:47 AM, Frédéric Delanoy wrote: > --- > dlls/dmusic/dmobject.c | 1 - > dlls/dmusic/dmobject.h | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/dlls/dmusic/dmobject.c b/dlls/dmusic/dmobject.c > index cabb6f7..8e9f58e 100644 > --- a/dlls/dmusic/dmobject.c > +++ b/dlls/dmusic/dmobject.c > @@ -1,6 +1,5 @@ > /* > * Base IDirectMusicObject Implementation > - * Keep in sync with the master in dlls/dmusic/dmobject.c > * > * Copyright (C) 2003-2004 Rok Mandeljc > * Copyright (C) 2014 Michael Stefaniuc > diff --git a/dlls/dmusic/dmobject.h b/dlls/dmusic/dmobject.h > index ad6bf6d..ffc683c 100644 > --- a/dlls/dmusic/dmobject.h > +++ b/dlls/dmusic/dmobject.h > @@ -1,6 +1,5 @@ > /* > * Base IDirectMusicObject Implementation > - * Keep in sync with the master in dlls/dmusic/dmobject.h > * > * Copyright (C) 2014 Michael Stefaniuc > * > bye michael

1 0

Re: [PATCH 3/5] riched20: Implement GetSize()
by Marvin 18 May '15

18 May '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=13453 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/5] riched20: Implement GetWeight()
by Marvin 18 May '15

18 May '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=13452 Your paranoid android. === build (build) === Patch failed to apply

1 0

Why does ntdll/thread.c use pthread_attr_setstack
by Mate Antunovic 18 May '15

18 May '15

I have noticed that RtlCreateUserThread in dlls/ntdll.thread.c uses the following call pthread_attr_setstack( &attr, teb->DeallocationStack, (char *)teb->Tib.StackBase - (char *)teb->DeallocationStack ); I have the source code from release 1.7.41. I am working on a complex project that traces the execution of programs running in Wine (won't go into detail here). I have noticed problems in RtlCreateUserThread when services.exe is launched in my environment. Basically the call to pthread_create causes a SIGSEGV. Let me make it clear that under ordinary conditions, Wine works fine. Playing around with things, I note that if I change the call above to be pthread_attr_setstacksize(&attr, 0x10000), then I don't get the same problem. My question is, why does the exact position of the stack need to be set in this way?

1 0

Re: [PATCH] oledlg: Make object name menu item localized
by Alex Henrie 18 May '15

18 May '15

+ WCHAR objectW[50]; /* should be enough*/ In the past I was told to always allocate memory in multiplies of 8 bytes,[1] and I personally have started to prefer powers of 2 in particular. Alexandre seems to prefer allocating at least 64 characters for short strings like this, judging from how he amended a proposed patch of mine several years ago.[2] + if (!LoadStringW(OLEDLG_hInstance, IDS_VERBMENU_OBJECT, objectW, sizeof(objectW)/sizeof(WCHAR))) { + static const WCHAR enobjectW[] = {'&','O','b','j','e','c','t',0}; + strcpyW(objectW, enobjectW); + } Is this really necessary? How could LoadString fail? I recently submitted a very similar patch [3] and didn't have to provide a special fallback. Just to be clear, I do really appreciate you taking the time to make sure that Wine is properly localized :-) I just don't want to see the codebase made unnecessarily complicated or inefficient. -Alex [1] https://www.winehq.org/pipermail/wine-devel/2011-December/093516.html [2] https://source.winehq.org/git/wine.git/commitdiff/6e5bba1b60f97fce34415ea30… [3] https://www.winehq.org/pipermail/wine-patches/2015-May/139132.html

2 1

Re: [PATCH 1/2] kernel32: Implement GetSystemTimePreciseAsFileTime
by Andrew Eikum 18 May '15

18 May '15

On Thu, May 07, 2015 at 11:02:34PM +0300, Martin Storsjo wrote: > +/*********************************************************************** > + * GetSystemTimePreciseAsFileTime (KERNEL32.@) > + * > + * Get the current time in utc format, with <1 us precision. > + * > + * RETURNS > + * Nothing. > + */ > +VOID WINAPI GetSystemTimePreciseAsFileTime( > + LPFILETIME time) /* [out] Destination for the current utc time */ > +{ > + GetSystemTimeAsFileTime(time); > +} I don't know why this one's not getting in. I have a couple small guesses. Personally, I'm opposed to including a bunch of documentation in Wine. I don't think Wine is the right place to document the Windows API. I don't know if others feel this way, or if this is enough for rejection. You're also using VOID, LPJUNK, etc, which I think we're trying to avoid these days. Andrew

3 3

Re: [PATCH] kernel32: Implement a few more classes in GetFileInformationByHandleEx
by Marvin 17 May '15

17 May '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=13414 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: oledlg: Partially implement OleUIAddVerbMenuW(), with basic tests
by Marvin 15 May '15

15 May '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=13373 Your paranoid android. === build (build) === Patch failed to apply

2 1

Why WINE renders the text in winecfg and notepad differently?
by John Found 15 May '15

15 May '15

In the attached picture, you can see, how the UI text differs for the simultaneously running WINE applications - notepad and winecfg. They both are running in the same WINEPREFIX and I expected to have the same appearance. Why this happens and how I can make them to look the same? Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

2 4

Re: mshtml: Initialize output value before passing it to VariantCopy.
by Marvin 14 May '15

14 May '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=13368 Your paranoid android. === wvistau64 (32 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue === w2008s64 (32 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue === w7u (32 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue === w8 (32 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue === wvistau64 (64 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue === w2008s64 (64 bit events) === events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue events.c:1083: Test failed: get_returnValue failed: 80020008 events.c:1084: Test failed: unexpected returnValue

1 0

Re: ntdll/tests: Wait for pending file operations to complete.
by Marvin 14 May '15

14 May '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=13361 Your paranoid android. === w8 (32 bit file) === file.c:407: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: [PATCH 3/3] user32: Fall back to downscaling the big icon for ICON_SMALL2.
by Marvin 14 May '15

14 May '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=13357 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [PATCH] d3d11.idl: add the basic interfaces to enable video decoding
by Stefan Dösinger 13 May '15

13 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch looks better. Ultimately Henri and Alexandre have to decide if they're happy with it. Henri is on vacation this week, so don't expect much movement until Monday. Am 2015-05-11 um 15:41 schrieb Steve Lhomme: > +interface ID3D11VideoDecoderOutputView : ID3D11View > +{ > + void GetDesc( > + [out] D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc ); > +} There's a space that doesn't match the rest of the patch, but does match what's in the MS headers. Since it is the only case I can spot I think it's a typo in a self-typed header rather than a missed fixup in a copypasted header. You don't have to use the same parameter names in Methods or functions. Instead of "pDesc" you can e.g. use "desc". The rest of the header already uses pCrap though, so I'm ok with the current way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVUy8wAAoJEN0/YqbEcdMwXHwQAJd+LDxvH03XR5L/+bpxZB/o U6g7cgMmtkklfSeCazZrUe0R5ZZExbmmIN+bBr6GJpbQezVQW3vng9EQj6ihfBjf 6CEKr9BJF/xOhYdHPrhg3yxaD9MZrnsXa9llNFGds6SI0q1L8uCclyAuPxV+AoSO fxgElN7/+LCRTwEM9shdwuxVELrikW52UmVTEajhNematVixplOh6pJMe+8XyPp/ iSn+6p/jBeytKzjb83uUnyGqVaFLOIg9ywR2PPeA43RvNYVnfV9agxeOGJYvO7Zw mKWmv+fG9sIXzvF/G9upnceE69YHf8WoIdEHW+kZsOl2ctRRB4ycBHp0rG4s2IeH f1XpENP55lT+dYIc/Tef8IdpABzmGD7JwtnbLyxRbF4F9Qwfe6x7GP3VtEBp1M/+ 5nePonYZ4N55sShelaU8X7/JxUuZb8onlz1UfEXJkIykopyQJJw49rXkQv7OFm2k xyJAsXCQk5Z9sqXXBuFxUnKkip9P8UaLOwFJ8WFUVgHrkS9UAceiehUKgvpcwYfX vxh48j6gAE4fBEUBVOlXiR4lMV7cDUWIoJdCopUkzxysPMp/hi3BcDk7EdrF9LX9 c01jQc2N+JwzjIyNhSC01Jk23Qp2lOG+pUT1UrKcACesoB1H6Zm3QbNv5hVgUfkz pFuJsryqPWxQFS02SvTu =ToVh -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/2] user32: Use window class small icon if the window does not have its own.
by Sebastian Lackner 13 May '15

13 May '15

On 13.05.2015 07:36, Alex Henrie wrote: > We were already doing this for ICON_SMALL2, which is supposed to be > almost identical to ICON_SMALL: > https://source.winehq.org/git/wine.git/blob/5f35f1a8dbbc9dc3fa629a7f123e045… > https://msdn.microsoft.com/en-us/library/windows/desktop/ms632625%28v=vs.85… > > This patch is part 1 of the fix for > https://bugs.winehq.org/show_bug.cgi?id=29337 > --- > dlls/user32/defwnd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/user32/defwnd.c b/dlls/user32/defwnd.c > index bcd6f91..935134d 100644 > --- a/dlls/user32/defwnd.c > +++ b/dlls/user32/defwnd.c > @@ -634,6 +634,7 @@ static LRESULT DEFWND_DefWinProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lPa > { > case ICON_SMALL: > ret = wndPtr->hIconSmall; > + if (!ret) ret = (HICON)GetClassLongPtrW( hwnd, GCLP_HICONSM ); > break; > case ICON_BIG: > ret = wndPtr->hIcon; > The patch breaks existing tests (user32/win): win.c:2009: Test failed: wrong small icon 0x3b0058/0

1 0

Re: [PATCH 2/2] kernel32: Implement a few more classes in GetFileInformationByHandleEx
by Martin Storsjö 12 May '15

12 May '15

On Thu, 7 May 2015, Martin Storsjo wrote: > --- > dlls/kernel32/file.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/dlls/kernel32/file.c b/dlls/kernel32/file.c > index 006db1c..9bf318e 100644 > --- a/dlls/kernel32/file.c > +++ b/dlls/kernel32/file.c > @@ -23,6 +23,7 @@ > #include "config.h" > #include "wine/port.h" > > +#include <assert.h> > #include <stdarg.h> > #include <stdio.h> > #include <errno.h> > @@ -894,11 +895,10 @@ BOOL WINAPI GetFileInformationByHandleEx( HANDLE handle, FILE_INFO_BY_HANDLE_CLA > { > NTSTATUS status; > IO_STATUS_BLOCK io; > + FILE_INFORMATION_CLASS nt_class; > > switch (class) > { > - case FileBasicInfo: > - case FileStandardInfo: > case FileRenameInfo: > case FileDispositionInfo: > case FileAllocationInfo: > @@ -919,8 +919,24 @@ BOOL WINAPI GetFileInformationByHandleEx( HANDLE handle, FILE_INFO_BY_HANDLE_CLA > SetLastError( ERROR_CALL_NOT_IMPLEMENTED ); > return FALSE; > > + case FileBasicInfo: > + case FileStandardInfo: > case FileNameInfo: > - status = NtQueryInformationFile( handle, &io, info, size, FileNameInformation ); > + switch (class) { > + case FileBasicInfo: > + nt_class = FileBasicInformation; > + break; > + case FileStandardInfo: > + nt_class = FileStandardInformation; > + break; > + case FileNameInfo: > + nt_class = FileNameInformation; > + break; > + default: > + assert(0); > + break; > + } > + status = NtQueryInformationFile( handle, &io, info, size, nt_class ); > if (status != STATUS_SUCCESS) > { > SetLastError( RtlNtStatusToDosError( status ) ); > -- > 1.8.1.2 Is there anything concrete that needs to be fixed in this (and the other kernel32 patch in the same thread) to be acceptable? // Martin

2 2

Re: [PATCH] d3d11.idl: add the basic interfaces to enable video decoding
by Steve Lhomme 11 May '15

11 May '15

Arf, sorry for all the noise. This patch compiles but doesn't run fine. I'll investigate. On Mon, May 11, 2015 at 2:02 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: > --- > include/d3d11.idl | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 168 insertions(+) > > diff --git a/include/d3d11.idl b/include/d3d11.idl > index 3726d32..79db53f 100644 > --- a/include/d3d11.idl > +++ b/include/d3d11.idl > @@ -2125,6 +2125,174 @@ interface ID3D11Device : IUnknown > UINT GetExceptionMode(); > } > > +typedef enum D3D11_VDOV_DIMENSION > +{ > + D3D11_VDOV_DIMENSION_UNKNOWN = 0, > + D3D11_VDOV_DIMENSION_TEXTURE2D > +} D3D11_VDOV_DIMENSION; > + > +typedef struct D3D11_TEX2D_VDOV > +{ > + UINT ArraySlice; > +} D3D11_TEX2D_VDOV; > + > +typedef struct D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC > +{ > + GUID DecodeProfile; > + D3D11_VDOV_DIMENSION ViewDimension; > + > + union > + { > + D3D11_TEX2D_VDOV Texture2D; > + }; > +} D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC; > + > +[ > + object, > + local, > + uuid(c2931aea-2a85-4f20-860f-fba1fd256e18) > +] > +interface ID3D11VideoDecoderOutputView : ID3D11View > +{ > + void GetDesc( [out] D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc); > +} > + > +[ > + object, > + local, > + uuid(3c9c5b51-995d-48d1-9b8d-fa5caeded65c) > +] > +interface ID3D11VideoDecoder : ID3D11DeviceChild > +{ > +} > + > +typedef enum D3D11_VIDEO_DECODER_BUFFER_TYPE > +{ > + D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS = 0, > + D3D11_VIDEO_DECODER_BUFFER_MACROBLOCK_CONTROL, > + D3D11_VIDEO_DECODER_BUFFER_RESIDUAL_DIFFERENCE, > + D3D11_VIDEO_DECODER_BUFFER_DEBLOCKING_CONTROL, > + D3D11_VIDEO_DECODER_BUFFER_INVERSE_QUANTIZATION_MATRIX, > + D3D11_VIDEO_DECODER_BUFFER_SLICE_CONTROL, > + D3D11_VIDEO_DECODER_BUFFER_BITSTREAM, > + D3D11_VIDEO_DECODER_BUFFER_MOTION_VECTOR, > + D3D11_VIDEO_DECODER_BUFFER_FILM_GRAIN > +} D3D11_VIDEO_DECODER_BUFFER_TYPE; > + > +typedef struct D3D11_ENCRYPTED_BLOCK_INFO > +{ > + UINT NumEncryptedBytesAtBeginning; > + UINT NumBytesInSkipPattern; > + UINT NumBytesInEncryptPattern; > +} D3D11_ENCRYPTED_BLOCK_INFO; > + > +typedef struct D3D11_VIDEO_DECODER_BUFFER_DESC > +{ > + D3D11_VIDEO_DECODER_BUFFER_TYPE BufferType; > + UINT BufferIndex; > + UINT DataOffset; > + UINT DataSize; > + UINT FirstMBaddress; > + UINT NumMBsInBuffer; > + UINT Width; > + UINT Height; > + UINT Stride; > + UINT ReservedBits; > + void *pIV; > + UINT IVSize; > + BOOL PartialEncryption; > + D3D11_ENCRYPTED_BLOCK_INFO EncryptedBlockInfo; > +} D3D11_VIDEO_DECODER_BUFFER_DESC; > + > +[ > + object, > + local, > + uuid(61f21c45-3c0e-4a74-9cea-67100d9ad5e4) > +] > +interface ID3D11VideoContext : ID3D11DeviceChild > +{ > + HRESULT GetDecoderBuffer( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] D3D11_VIDEO_DECODER_BUFFER_TYPE BufferType, > + [out] UINT *pBufferSize, > + [out] void **ppBuffer); > + HRESULT ReleaseDecoderBuffer( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] D3D11_VIDEO_DECODER_BUFFER_TYPE BufferType); > + HRESULT DecoderBeginFrame( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] ID3D11VideoDecoderOutputView *pVideoDecoderOutputView, > + [in] UINT ContentKeySize, > + [in] const void *pContentKey); > + HRESULT DecoderEndFrame( > + [in] ID3D11VideoDecoder *pDecoder); > + HRESULT SubmitDecoderBuffers( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] UINT NumBuffers, > + [in] const D3D11_VIDEO_DECODER_BUFFER_DESC *pBufferDesc); > +} > + > +typedef struct D3D11_VIDEO_DECODER_DESC > +{ > + GUID Guid; > + UINT SampleWidth; > + UINT SampleHeight; > + DXGI_FORMAT OutputFormat; > +} D3D11_VIDEO_DECODER_DESC; > + > +typedef struct D3D11_VIDEO_DECODER_CONFIG > +{ > + GUID guidConfigBitstreamEncryption; > + GUID guidConfigMBcontrolEncryption; > + GUID guidConfigResidDiffEncryption; > + UINT ConfigBitstreamRaw; > + UINT ConfigMBcontrolRasterOrder; > + UINT ConfigResidDiffHost; > + UINT ConfigSpatialResid8; > + UINT ConfigResid8Subtraction; > + UINT ConfigSpatialHost8or9Clipping; > + UINT ConfigSpatialResidInterleaved; > + UINT ConfigIntraResidUnsigned; > + UINT ConfigResidDiffAccelerator; > + UINT ConfigHostInverseScan; > + UINT ConfigSpecificIDCT; > + UINT Config4GroupedCoefs; > + USHORT ConfigMinRenderTargetBuffCount; > + USHORT ConfigDecoderSpecific; > +} D3D11_VIDEO_DECODER_CONFIG; > + > +[ > + object, > + local, > + uuid(10ec4d5b-975a-4689-b9e4-d0aac30fe333) > +] > +interface ID3D11VideoDevice : IUnknown > +{ > + HRESULT CreateVideoDecoder( > + [in] const D3D11_VIDEO_DECODER_DESC *pVideoDesc, > + [in] const D3D11_VIDEO_DECODER_CONFIG *pConfig, > + [out] ID3D11VideoDecoder **ppVideoDecoder); > + UINT GetVideoDecoderProfileCount(void); > + HRESULT GetVideoDecoderProfile( > + [in] UINT Index, > + [out] GUID *pDecoderProfile); > + HRESULT CheckVideoDecoderFormat( > + [in] const GUID *pDecoderProfile, > + [in] DXGI_FORMAT Format, > + [out] BOOL *pSupported); > + HRESULT CreateVideoDecoderOutputView( > + [in] ID3D11Resource *pResource, > + [in] const D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc, > + [out] ID3D11VideoDecoderOutputView **ppVideoDecoderOutputView); > + HRESULT GetVideoDecoderConfigCount( > + [in] const D3D11_VIDEO_DECODER_DESC *pDesc, > + [out] UINT *pCount); > + HRESULT GetVideoDecoderConfig( > + [in] const D3D11_VIDEO_DECODER_DESC *pDesc, > + [in] UINT Index, > + [out] D3D11_VIDEO_DECODER_CONFIG *pConfig); > +} > + > typedef enum D3D11_CREATE_DEVICE_FLAG { > D3D11_CREATE_DEVICE_SINGLETHREADED = 0x0001, > D3D11_CREATE_DEVICE_DEBUG = 0x0002, > -- > 2.4.0 > > >

1 0

Re: [PATCH] d3d11.idl: add the interfaces necessary to use the D3D11 video decoder
by Stefan Dösinger 11 May '15

11 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-05-11 um 11:53 schrieb Steve Lhomme: > On Mon, May 11, 2015 at 11:10 AM, Stefan Dösinger >> This patch still shows plenty of signs that it was copypasted >> from Microsoft's headers. > > Care to elaborate ? Suspicious trailing whitespaces at exactly the same place where Microsoft's code has them. There are more telling signs that I don't want to point out since I want a cleanly written header, not one that has a few problematic symptoms fixed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVUIP5AAoJEN0/YqbEcdMw2IEQAIagS0sWyxW/HtEyztMgpfQZ gzzQkC0Uwlf+PGdFTAM4kyJVljqlHdgu/ZMqmABeNnqW3jsHQmCvIVv3ahvSa1Y8 rl9cWWxoYl31BLFPy6F+QN8QUsvX4Hnz96bYxy2M733XWLodSWMlCAzvFpdLPfa3 bZ9BOAsRfkLKxEzdz0adjJtwxdPwwF/CwGwjucrHGiBVW4RCB01gYSagUK9LZxVH VMsFFWi0YbfzforISKGSGC4tF0iDUwGzQ7V5QAMZmnDiVpZXz47shzFXiOP1jaM/ kEnMQXkPH1vMqKwXK7HqbsN0qALxzN5DiMgMxtVUTyelAKlOT+c4Fyd0PSFpyi1r uvSM1M2gxh3NjZ/BSNh5GSwZgkAwCe5PaN0xDVWZ8c4GPm7e6n61XKvdm/NEtvjM modJb6WUx5iWkWY58sBbi4VG5Zl3eu+cqNKtZd3mo0m/LefF061DrAgMO+bSYiza JwHYyqfWVOyzGpuks7k1k7aub+YemJrGXT84LWoDlshf+xWUk0duszWySAFtBKSG XgJILPLSzRir1OQa39orFmAqCiMJwVh1pwuie1cQ9zq2GmyezilAD9Co1Qns9dSi an0MQlh1SpTnoWE1wduk2mcU1Q7GdanVgyATSWl7Any4FAn4Gru+nlW85dPDcIhp lM8l59NlJaTcdAnGPQEp =5XCl -----END PGP SIGNATURE-----

1 0

Re: [PATCH] d3d11.idl: add the interfaces necessary to use the D3D11 video decoder
by Stefan Dösinger 11 May '15

11 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch still shows plenty of signs that it was copypasted from Microsoft's headers. Am 2015-05-11 um 11:00 schrieb Steve Lhomme: > From: Steve Lhomme <slhomme(a)matroska.org> > > --- > include/d3d11.idl | 878 +++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 870 insertions(+), 8 deletions(-) > > diff --git a/include/d3d11.idl b/include/d3d11.idl > index 3726d32..70afbd5 100644 > --- a/include/d3d11.idl > +++ b/include/d3d11.idl > @@ -2125,16 +2125,878 @@ interface ID3D11Device : IUnknown > UINT GetExceptionMode(); > } > > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_MOCOMP_NOFGT, 0x1b81be64, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_MOCOMP_FGT, 0x1b81be65, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_IDCT_NOFGT, 0x1b81be66, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_IDCT_FGT, 0x1b81be67, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_NOFGT, 0x1b81be68, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_FGT, 0x1b81be69, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_WITHFMOASO_NOFGT, 0xd5f04ff9, 0x3418, 0x45d8, 0x95, 0x61, 0x32, 0xa7, 0x6a, 0xae, 0x2d, 0xdd);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_STEREO_PROGRESSIVE_NOFGT, 0xd79be8da, 0x0cf1, 0x4c81, 0xb8, 0x2a, 0x69, 0xa4, 0xe2, 0x36, 0xf4, 0x3d);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_STEREO_NOFGT, 0xf9aaccbb, 0xc2b6, 0x4cfc, 0x87, 0x79, 0x57, 0x07, 0xb1, 0x76, 0x05, 0x52);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_H264_VLD_MULTIVIEW_NOFGT, 0x705b9d82, 0x76cf, 0x49d6, 0xb7, 0xe6, 0xac, 0x88, 0x72, 0xdb, 0x01, 0x3c);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_WMV8_POSTPROC, 0x1b81be80, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_WMV8_MOCOMP, 0x1b81be81, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_WMV9_POSTPROC, 0x1b81be90, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_WMV9_MOCOMP, 0x1b81be91, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_WMV9_IDCT, 0x1b81be94, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_VC1_POSTPROC, 0x1b81beA0, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_VC1_MOCOMP, 0x1b81beA1, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_VC1_IDCT, 0x1b81beA2, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_VC1_VLD, 0x1b81beA3, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_VC1_D2010, 0x1b81beA4, 0xa0c7, 0x11d3, 0xb9, 0x84, 0x00, 0xc0, 0x4f, 0x2e, 0x73, 0xc5);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG4PT2_VLD_SIMPLE, 0xefd64d74, 0xc9e8, 0x41d7, 0xa5, 0xe9, 0xe9, 0xb0, 0xe3, 0x9f, 0xa3, 0x19);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG4PT2_VLD_ADVSIMPLE_NOGMC, 0xed418a9f, 0x010d, 0x4eda, 0x9a, 0xe3, 0x9a, 0x65, 0x35, 0x8d, 0x8d, 0x2e);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG4PT2_VLD_ADVSIMPLE_GMC, 0xab998b5b, 0x4258, 0x44a9, 0x9f, 0xeb, 0x94, 0xe5, 0x97, 0xa6, 0xba, 0xae);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_HEVC_VLD_MAIN, 0x5b11d51b, 0x2f4c, 0x4452, 0xbc, 0xc3, 0x09, 0xf2, 0xa1, 0x16, 0x0c, 0xc0);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_HEVC_VLD_MAIN10, 0x107af0e0, 0xef1a, 0x4d19, 0xab, 0xa8, 0x67, 0xa1, 0x63, 0x07, 0x3d, 0x13);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG2_MOCOMP, 0xe6a9f44b, 0x61b0, 0x4563, 0x9e, 0xa4, 0x63, 0xd2, 0xa3, 0xc6, 0xfe, 0x66);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG2_IDCT, 0xbf22ad00, 0x03ea, 0x4690, 0x80, 0x77, 0x47, 0x33, 0x46, 0x20, 0x9b, 0x7e);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG2_VLD, 0xee27417f, 0x5e28, 0x4e65, 0xbe, 0xea, 0x1d, 0x26, 0xb5, 0x08, 0xad, 0xc9);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG1_VLD, 0x6f3ec719, 0x3735, 0x42cc, 0x80, 0x63, 0x65, 0xcc, 0x3c, 0xb3, 0x66, 0x16);") > +cpp_quote("DEFINE_GUID(D3D11_DECODER_PROFILE_MPEG2and1_VLD, 0x86695f12, 0x340e, 0x4f04, 0x9f, 0xd3, 0x92, 0x53, 0xdd, 0x32, 0x74, 0x60);") > + > +typedef struct D3D11_VIDEO_DECODER_DESC > +{ > + GUID Guid; > + UINT SampleWidth; > + UINT SampleHeight; > + DXGI_FORMAT OutputFormat; > +} D3D11_VIDEO_DECODER_DESC; > + > +typedef struct D3D11_VIDEO_DECODER_CONFIG > +{ > + GUID guidConfigBitstreamEncryption; > + GUID guidConfigMBcontrolEncryption; > + GUID guidConfigResidDiffEncryption; > + UINT ConfigBitstreamRaw; > + UINT ConfigMBcontrolRasterOrder; > + UINT ConfigResidDiffHost; > + UINT ConfigSpatialResid8; > + UINT ConfigResid8Subtraction; > + UINT ConfigSpatialHost8or9Clipping; > + UINT ConfigSpatialResidInterleaved; > + UINT ConfigIntraResidUnsigned; > + UINT ConfigResidDiffAccelerator; > + UINT ConfigHostInverseScan; > + UINT ConfigSpecificIDCT; > + UINT Config4GroupedCoefs; > + USHORT ConfigMinRenderTargetBuffCount; > + USHORT ConfigDecoderSpecific; > +} D3D11_VIDEO_DECODER_CONFIG; > + > +typedef enum D3D11_VIDEO_DECODER_BUFFER_TYPE > +{ > + D3D11_VIDEO_DECODER_BUFFER_PICTURE_PARAMETERS = 0, > + D3D11_VIDEO_DECODER_BUFFER_MACROBLOCK_CONTROL = 1, > + D3D11_VIDEO_DECODER_BUFFER_RESIDUAL_DIFFERENCE = 2, > + D3D11_VIDEO_DECODER_BUFFER_DEBLOCKING_CONTROL = 3, > + D3D11_VIDEO_DECODER_BUFFER_INVERSE_QUANTIZATION_MATRIX = 4, > + D3D11_VIDEO_DECODER_BUFFER_SLICE_CONTROL = 5, > + D3D11_VIDEO_DECODER_BUFFER_BITSTREAM = 6, > + D3D11_VIDEO_DECODER_BUFFER_MOTION_VECTOR = 7, > + D3D11_VIDEO_DECODER_BUFFER_FILM_GRAIN = 8 > +} D3D11_VIDEO_DECODER_BUFFER_TYPE; > + > +typedef struct D3D11_ENCRYPTED_BLOCK_INFO > +{ > + UINT NumEncryptedBytesAtBeginning; > + UINT NumBytesInSkipPattern; > + UINT NumBytesInEncryptPattern; > +} D3D11_ENCRYPTED_BLOCK_INFO; > + > +typedef struct D3D11_VIDEO_DECODER_BUFFER_DESC > +{ > + D3D11_VIDEO_DECODER_BUFFER_TYPE BufferType; > + UINT BufferIndex; > + UINT DataOffset; > + UINT DataSize; > + UINT FirstMBaddress; > + UINT NumMBsInBuffer; > + UINT Width; > + UINT Height; > + UINT Stride; > + UINT ReservedBits; > + void *pIV; > + UINT IVSize; > + BOOL PartialEncryption; > + D3D11_ENCRYPTED_BLOCK_INFO EncryptedBlockInfo; > +} D3D11_VIDEO_DECODER_BUFFER_DESC; > + > +typedef struct D3D11_VIDEO_DECODER_EXTENSION > +{ > + UINT Function; > + void *pPrivateInputData; > + UINT PrivateInputDataSize; > + void *pPrivateOutputData; > + UINT PrivateOutputDataSize; > + UINT ResourceCount; > + ID3D11Resource **ppResourceList; > +} D3D11_VIDEO_DECODER_EXTENSION; > + > +typedef enum D3D11_VIDEO_FRAME_FORMAT > +{ > + D3D11_VIDEO_FRAME_FORMAT_PROGRESSIVE = 0, > + D3D11_VIDEO_FRAME_FORMAT_INTERLACED_TOP_FIELD_FIRST = 1, > + D3D11_VIDEO_FRAME_FORMAT_INTERLACED_BOTTOM_FIELD_FIRST = 2 > +} D3D11_VIDEO_FRAME_FORMAT; > + > +typedef enum D3D11_VIDEO_USAGE > +{ > + D3D11_VIDEO_USAGE_PLAYBACK_NORMAL = 0, > + D3D11_VIDEO_USAGE_OPTIMAL_SPEED = 1, > + D3D11_VIDEO_USAGE_OPTIMAL_QUALITY = 2 > +} D3D11_VIDEO_USAGE; > + > +typedef struct D3D11_VIDEO_PROCESSOR_CONTENT_DESC > +{ > + D3D11_VIDEO_FRAME_FORMAT InputFrameFormat; > + DXGI_RATIONAL InputFrameRate; > + UINT InputWidth; > + UINT InputHeight; > + DXGI_RATIONAL OutputFrameRate; > + UINT OutputWidth; > + UINT OutputHeight; > + D3D11_VIDEO_USAGE Usage; > +} D3D11_VIDEO_PROCESSOR_CONTENT_DESC; > + > +typedef struct D3D11_VIDEO_PROCESSOR_CAPS > +{ > + UINT DeviceCaps; > + UINT FeatureCaps; > + UINT FilterCaps; > + UINT InputFormatCaps; > + UINT AutoStreamCaps; > + UINT StereoCaps; > + UINT RateConversionCapsCount; > + UINT MaxInputStreams; > + UINT MaxStreamStates; > +} D3D11_VIDEO_PROCESSOR_CAPS; > + > +typedef struct D3D11_VIDEO_PROCESSOR_RATE_CONVERSION_CAPS > +{ > + UINT PastFrames; > + UINT FutureFrames; > + UINT ProcessorCaps; > + UINT ITelecineCaps; > + UINT CustomRateCount; > +} D3D11_VIDEO_PROCESSOR_RATE_CONVERSION_CAPS; > + > +typedef struct D3D11_VIDEO_PROCESSOR_CUSTOM_RATE > +{ > + DXGI_RATIONAL CustomRate; > + UINT OutputFrames; > + BOOL InputInterlaced; > + UINT InputFramesOrFields; > +} D3D11_VIDEO_PROCESSOR_CUSTOM_RATE; > + > +typedef enum D3D11_VIDEO_PROCESSOR_FILTER > +{ > + D3D11_VIDEO_PROCESSOR_FILTER_BRIGHTNESS = 0, > + D3D11_VIDEO_PROCESSOR_FILTER_CONTRAST = 1, > + D3D11_VIDEO_PROCESSOR_FILTER_HUE = 2, > + D3D11_VIDEO_PROCESSOR_FILTER_SATURATION = 3, > + D3D11_VIDEO_PROCESSOR_FILTER_NOISE_REDUCTION = 4, > + D3D11_VIDEO_PROCESSOR_FILTER_EDGE_ENHANCEMENT = 5, > + D3D11_VIDEO_PROCESSOR_FILTER_ANAMORPHIC_SCALING = 6, > + D3D11_VIDEO_PROCESSOR_FILTER_STEREO_ADJUSTMENT = 7 > +} D3D11_VIDEO_PROCESSOR_FILTER; > + > +typedef struct D3D11_VIDEO_CONTENT_PROTECTION_CAPS > +{ > + UINT Caps; > + UINT KeyExchangeTypeCount; > + UINT BlockAlignmentSize; > + ULONGLONG ProtectedMemorySize; > +} D3D11_VIDEO_CONTENT_PROTECTION_CAPS; > + > +typedef struct D3D11_VIDEO_PROCESSOR_FILTER_RANGE > +{ > + int Minimum; > + int Maximum; > + int Default; > + float Multiplier; > +} D3D11_VIDEO_PROCESSOR_FILTER_RANGE; > + > +typedef struct D3D11_VIDEO_COLOR_RGBA > +{ > + float R; > + float G; > + float B; > + float A; > +} D3D11_VIDEO_COLOR_RGBA; > + > +typedef struct D3D11_VIDEO_COLOR_YCbCrA > +{ > + float Y; > + float Cb; > + float Cr; > + float A; > +} D3D11_VIDEO_COLOR_YCbCrA; > + > +typedef struct D3D11_VIDEO_COLOR > +{ > + union > + { > + D3D11_VIDEO_COLOR_YCbCrA YCbCr; > + D3D11_VIDEO_COLOR_RGBA RGBA; > + }; > +} D3D11_VIDEO_COLOR; > + > +typedef struct D3D11_VIDEO_PROCESSOR_COLOR_SPACE > +{ > + UINT Usage :1; > + UINT RGB_Range :1; > + UINT YCbCr_Matrix :1; > + UINT YCbCr_xvYCC :1; > + UINT Nominal_Range :2; > + UINT Reserved : 26; > +} D3D11_VIDEO_PROCESSOR_COLOR_SPACE; > + > +typedef enum D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE > +{ > + D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE_OPAQUE = 0, > + D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE_BACKGROUND = 1, > + D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE_DESTINATION = 2, > + D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE_SOURCE_STREAM = 3 > +} D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE; > + > +typedef enum D3D11_VIDEO_PROCESSOR_OUTPUT_RATE > +{ > + D3D11_VIDEO_PROCESSOR_OUTPUT_RATE_NORMAL = 0, > + D3D11_VIDEO_PROCESSOR_OUTPUT_RATE_HALF = 1, > + D3D11_VIDEO_PROCESSOR_OUTPUT_RATE_CUSTOM = 2 > +} D3D11_VIDEO_PROCESSOR_OUTPUT_RATE; > + > +typedef enum D3D11_VIDEO_PROCESSOR_STEREO_FORMAT > +{ > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_MONO = 0, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_HORIZONTAL = 1, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_VERTICAL = 2, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_SEPARATE = 3, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_MONO_OFFSET = 4, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_ROW_INTERLEAVED = 5, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_COLUMN_INTERLEAVED = 6, > + D3D11_VIDEO_PROCESSOR_STEREO_FORMAT_CHECKERBOARD = 7 > +} D3D11_VIDEO_PROCESSOR_STEREO_FORMAT; > + > +typedef enum D3D11_VIDEO_PROCESSOR_STEREO_FLIP_MODE > +{ > + D3D11_VIDEO_PROCESSOR_STEREO_FLIP_NONE = 0, > + D3D11_VIDEO_PROCESSOR_STEREO_FLIP_FRAME0 = 1, > + D3D11_VIDEO_PROCESSOR_STEREO_FLIP_FRAME1 = 2 > +} D3D11_VIDEO_PROCESSOR_STEREO_FLIP_MODE; > + > +typedef enum D3D11_VIDEO_PROCESSOR_ROTATION > +{ > + D3D11_VIDEO_PROCESSOR_ROTATION_IDENTITY = 0, > + D3D11_VIDEO_PROCESSOR_ROTATION_90 = 1, > + D3D11_VIDEO_PROCESSOR_ROTATION_180 = 2, > + D3D11_VIDEO_PROCESSOR_ROTATION_270 = 3 > +} D3D11_VIDEO_PROCESSOR_ROTATION; > + > +[ > + object, > + local, > + uuid(3c9c5b51-995d-48d1-9b8d-fa5caeded65c) > +] > +interface ID3D11VideoDecoder : ID3D11DeviceChild > +{ > + HRESULT GetCreationParameters( > + [out] D3D11_VIDEO_DECODER_DESC *pVideoDesc, > + [out] D3D11_VIDEO_DECODER_CONFIG *pConfig); > + HRESULT GetDriverHandle( > + [out] HANDLE *pDriverHandle); > +} > + > +[ > + object, > + local, > + uuid(1d7b0652-185f-41c6-85ce-0c5be3d4ae6c) > +] > +interface ID3D11VideoProcessor : ID3D11DeviceChild > +{ > + void GetContentDesc( > + [out] D3D11_VIDEO_PROCESSOR_CONTENT_DESC *pDesc); > + void GetRateConversionCaps( > + [out] D3D11_VIDEO_PROCESSOR_RATE_CONVERSION_CAPS *pCaps); > +} > + > +typedef enum D3D11_VPOV_DIMENSION > +{ > + D3D11_VPOV_DIMENSION_UNKNOWN = 0, > + D3D11_VPOV_DIMENSION_TEXTURE2D = 1, > + D3D11_VPOV_DIMENSION_TEXTURE2DARRAY = 2 > +} D3D11_VPOV_DIMENSION; > + > +typedef struct D3D11_TEX2D_VPOV > +{ > + UINT MipSlice; > +} D3D11_TEX2D_VPOV; > + > +typedef struct D3D11_TEX2D_ARRAY_VPOV > +{ > + UINT MipSlice; > + UINT FirstArraySlice; > + UINT ArraySize; > +} D3D11_TEX2D_ARRAY_VPOV; > + > +typedef struct D3D11_VIDEO_PROCESSOR_OUTPUT_VIEW_DESC > +{ > + D3D11_VPOV_DIMENSION ViewDimension; > + > + union > + { > + D3D11_TEX2D_VPOV Texture2D; > + D3D11_TEX2D_ARRAY_VPOV Texture2DArray; > + }; > +} D3D11_VIDEO_PROCESSOR_OUTPUT_VIEW_DESC; > + > +[ > + object, > + local, > + uuid(a048285e-25a9-4527-bd93-d68b68c44254) > +] > +interface ID3D11VideoProcessorOutputView : ID3D11View > +{ > + void GetDesc( [out] D3D11_VIDEO_PROCESSOR_OUTPUT_VIEW_DESC *pDesc); > +} > + > +[ > + object, > + local, > + uuid(9b32f9ad-bdcc-40a6-a39d-d5c865845720) > +] > +interface ID3D11CryptoSession : ID3D11DeviceChild > +{ > + void GetCryptoType( > + [out] GUID *pCryptoType); > + void GetDecoderProfile( > + [out] GUID *pDecoderProfile); > + HRESULT GetCertificateSize( > + [out] UINT *pCertificateSize); > + HRESULT GetCertificate( > + [in] UINT CertificateSize, > + [out] BYTE *pCertificate); > + void GetCryptoSessionHandle( > + [out] HANDLE *pCryptoSessionHandle); > +} > + > +#define D3D11_OMAC_SIZE 16 > + > +typedef struct D3D11_OMAC > +{ > + BYTE Omac[D3D11_OMAC_SIZE]; > +} D3D11_OMAC; > + > +typedef enum D3D11_AUTHENTICATED_CHANNEL_TYPE > +{ > + D3D11_AUTHENTICATED_CHANNEL_D3D11 = 1, > + D3D11_AUTHENTICATED_CHANNEL_DRIVER_SOFTWARE = 2, > + D3D11_AUTHENTICATED_CHANNEL_DRIVER_HARDWARE = 3 > +} D3D11_AUTHENTICATED_CHANNEL_TYPE; > + > +typedef struct D3D11_AUTHENTICATED_CONFIGURE_OUTPUT > +{ > + D3D11_OMAC omac; > + GUID ConfigureType; > + HANDLE hChannel; > + UINT SequenceNumber; > + HRESULT ReturnCode; > +} D3D11_AUTHENTICATED_CONFIGURE_OUTPUT; > + > +[ > + object, > + local, > + uuid(3015a308-dcbd-47aa-a747-192486d14d4a) > +] > +interface ID3D11AuthenticatedChannel : ID3D11DeviceChild > +{ > + HRESULT GetCertificateSize( > + [out] UINT *pCertificateSize); > + HRESULT GetCertificate( > + [in] UINT CertificateSize, > + [out] BYTE *pCertificate); > + void GetChannelHandle( > + [out] HANDLE *pChannelHandle); > +} > + > +typedef enum D3D11_VPIV_DIMENSION > +{ > + D3D11_VPIV_DIMENSION_UNKNOWN = 0, > + D3D11_VPIV_DIMENSION_TEXTURE2D = 1 > +} D3D11_VPIV_DIMENSION; > + > +typedef struct D3D11_TEX2D_VPIV > +{ > + UINT MipSlice; > + UINT ArraySlice; > +} D3D11_TEX2D_VPIV; > + > +typedef struct D3D11_VIDEO_PROCESSOR_INPUT_VIEW_DESC > +{ > + UINT FourCC; > + D3D11_VPIV_DIMENSION ViewDimension; > + > + union > + { > + D3D11_TEX2D_VPIV Texture2D; > + }; > +} D3D11_VIDEO_PROCESSOR_INPUT_VIEW_DESC; > + > +[ > + object, > + local, > + uuid(11ec5a5f-51dc-4945-ab34-6e8c21300ea5) > +] > +interface ID3D11VideoProcessorInputView : ID3D11View > +{ > + void GetDesc( [out] D3D11_VIDEO_PROCESSOR_INPUT_VIEW_DESC *pDesc); > +} > + > +typedef enum D3D11_VDOV_DIMENSION > +{ > + D3D11_VDOV_DIMENSION_UNKNOWN = 0, > + D3D11_VDOV_DIMENSION_TEXTURE2D = 1 > +} D3D11_VDOV_DIMENSION; > + > +typedef struct D3D11_TEX2D_VDOV > +{ > + UINT ArraySlice; > +} D3D11_TEX2D_VDOV; > + > +typedef struct D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC > +{ > + GUID DecodeProfile; > + D3D11_VDOV_DIMENSION ViewDimension; > + > + union > + { > + D3D11_TEX2D_VDOV Texture2D; > + }; > +} D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC; > + > +[ > + object, > + local, > + uuid(c2931aea-2a85-4f20-860f-fba1fd256e18) > +] > +interface ID3D11VideoDecoderOutputView : ID3D11View > +{ > + void GetDesc( [out] D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc); > +} > + > +typedef struct D3D11_VIDEO_PROCESSOR_STREAM > +{ > + BOOL Enable; > + UINT OutputIndex; > + UINT InputFrameOrField; > + UINT PastFrames; > + UINT FutureFrames; > + ID3D11VideoProcessorInputView **ppPastSurfaces; > + ID3D11VideoProcessorInputView *pInputSurface; > + ID3D11VideoProcessorInputView **ppFutureSurfaces; > + ID3D11VideoProcessorInputView **ppPastSurfacesRight; > + ID3D11VideoProcessorInputView *pInputSurfaceRight; > + ID3D11VideoProcessorInputView **ppFutureSurfacesRight; > +} D3D11_VIDEO_PROCESSOR_STREAM; > + > +[ > + object, > + local, > + uuid(61f21c45-3c0e-4a74-9cea-67100d9ad5e4) > +] > +interface ID3D11VideoContext : ID3D11DeviceChild > +{ > + HRESULT GetDecoderBuffer( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] D3D11_VIDEO_DECODER_BUFFER_TYPE Type, > + [out] UINT *pBufferSize, > + [out] void **ppBuffer); > + HRESULT ReleaseDecoderBuffer( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] D3D11_VIDEO_DECODER_BUFFER_TYPE Type); > + HRESULT DecoderBeginFrame( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] ID3D11VideoDecoderOutputView *pView, > + [in] UINT ContentKeySize, > + [in] const void *pContentKey); > + HRESULT DecoderEndFrame( > + [in] ID3D11VideoDecoder *pDecoder); > + HRESULT SubmitDecoderBuffers( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] UINT NumBuffers, > + [in] const D3D11_VIDEO_DECODER_BUFFER_DESC *pBufferDesc); > + HRESULT DecoderExtension( > + [in] ID3D11VideoDecoder *pDecoder, > + [in] const D3D11_VIDEO_DECODER_EXTENSION *pExtensionData); > + void VideoProcessorSetOutputTargetRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] BOOL Enable, > + [in] const RECT *pRect); > + void VideoProcessorSetOutputBackgroundColor( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] BOOL YCbCr, > + [in] const D3D11_VIDEO_COLOR *pColor); > + void VideoProcessorSetOutputColorSpace( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] const D3D11_VIDEO_PROCESSOR_COLOR_SPACE *pColorSpace); > + void VideoProcessorSetOutputAlphaFillMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE AlphaFillMode, > + [in] UINT StreamIndex); > + void VideoProcessorSetOutputConstriction( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] BOOL Enable, > + [in] SIZE Size); > + void VideoProcessorSetOutputStereoMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] BOOL Enable); > + HRESULT VideoProcessorSetOutputExtension( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] const GUID *pExtensionGuid, > + [in] UINT DataSize, > + [in] void *pData); > + void VideoProcessorGetOutputTargetRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] BOOL *Enabled, > + [out] RECT *pRect); > + void VideoProcessorGetOutputBackgroundColor( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] BOOL *pYCbCr, > + [out] D3D11_VIDEO_COLOR *pColor); > + void VideoProcessorGetOutputColorSpace( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] D3D11_VIDEO_PROCESSOR_COLOR_SPACE *pColorSpace); > + void VideoProcessorGetOutputAlphaFillMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] D3D11_VIDEO_PROCESSOR_ALPHA_FILL_MODE *pAlphaFillMode, > + [out] UINT *pStreamIndex); > + void VideoProcessorGetOutputConstriction( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] BOOL *pEnabled, > + [out] SIZE *pSize); > + void VideoProcessorGetOutputStereoMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [out] BOOL *pEnabled); > + HRESULT VideoProcessorGetOutputExtension( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] const GUID *pExtensionGuid, > + [in] UINT DataSize, > + [out] void *pData); > + void VideoProcessorSetStreamFrameFormat( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] D3D11_VIDEO_FRAME_FORMAT FrameFormat); > + void VideoProcessorSetStreamColorSpace( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] const D3D11_VIDEO_PROCESSOR_COLOR_SPACE *pColorSpace); > + void VideoProcessorSetStreamOutputRate( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] D3D11_VIDEO_PROCESSOR_OUTPUT_RATE OutputRate, > + [in] BOOL RepeatFrame, > + [in] const DXGI_RATIONAL *pCustomRate); > + void VideoProcessorSetStreamSourceRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] const RECT *pRect); > + void VideoProcessorSetStreamDestRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] const RECT *pRect); > + void VideoProcessorSetStreamAlpha( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] FLOAT Alpha); > + void VideoProcessorSetStreamPalette( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] UINT Count, > + [in] const UINT *pEntries); > + void VideoProcessorSetStreamPixelAspectRatio( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] const DXGI_RATIONAL *pSourceAspectRatio, > + [in] const DXGI_RATIONAL *pDestinationAspectRatio); > + void VideoProcessorSetStreamLumaKey( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] FLOAT Lower, > + [in] FLOAT Upper); > + void VideoProcessorSetStreamStereoFormat( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] D3D11_VIDEO_PROCESSOR_STEREO_FORMAT Format, > + [in] BOOL LeftViewFrame0, > + [in] BOOL BaseViewFrame0, > + [in] D3D11_VIDEO_PROCESSOR_STEREO_FLIP_MODE FlipMode, > + [in] int MonoOffset); > + void VideoProcessorSetStreamAutoProcessingMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable); > + void VideoProcessorSetStreamFilter( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] D3D11_VIDEO_PROCESSOR_FILTER Filter, > + [in] BOOL Enable, > + [in] int Level); > + HRESULT VideoProcessorSetStreamExtension( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] const GUID *pExtensionGuid, > + [in] UINT DataSize, > + [in] void *pData); > + void VideoProcessorGetStreamFrameFormat( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] D3D11_VIDEO_FRAME_FORMAT *pFrameFormat); > + void VideoProcessorGetStreamColorSpace( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] D3D11_VIDEO_PROCESSOR_COLOR_SPACE *pColorSpace); > + void VideoProcessorGetStreamOutputRate( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] D3D11_VIDEO_PROCESSOR_OUTPUT_RATE *pOutputRate, > + [out] BOOL *pRepeatFrame, > + [out] DXGI_RATIONAL *pCustomRate); > + void VideoProcessorGetStreamSourceRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled, > + [out] RECT *pRect); > + void VideoProcessorGetStreamDestRect( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled, > + [out] RECT *pRect); > + void VideoProcessorGetStreamAlpha( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled, > + [out] FLOAT *pAlpha); > + void VideoProcessorGetStreamPalette( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] UINT Count, > + [out] UINT *pEntries); > + void VideoProcessorGetStreamPixelAspectRatio( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled, > + [out] DXGI_RATIONAL *pSourceAspectRatio, > + [out] DXGI_RATIONAL *pDestinationAspectRatio); > + void VideoProcessorGetStreamLumaKey( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled, > + [out] FLOAT *pLower, > + [out] FLOAT *pUpper); > + void VideoProcessorGetStreamStereoFormat( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnable, > + [out] D3D11_VIDEO_PROCESSOR_STEREO_FORMAT *pFormat, > + [out] BOOL *pLeftViewFrame0, > + [out] BOOL *pBaseViewFrame0, > + [out] D3D11_VIDEO_PROCESSOR_STEREO_FLIP_MODE *pFlipMode, > + [out] int *MonoOffset); > + void VideoProcessorGetStreamAutoProcessingMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnabled); > + void VideoProcessorGetStreamFilter( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] D3D11_VIDEO_PROCESSOR_FILTER Filter, > + [out] BOOL *pEnabled, > + [out] int *pLevel); > + HRESULT VideoProcessorGetStreamExtension( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] const GUID *pExtensionGuid, > + [in] UINT DataSize, > + [out] void *pData); > + HRESULT VideoProcessorBlt( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] ID3D11VideoProcessorOutputView *pView, > + [in] UINT OutputFrame, > + [in] UINT StreamCount, > + [in] const D3D11_VIDEO_PROCESSOR_STREAM *pStreams); > + HRESULT NegotiateCryptoSessionKeyExchange( > + [in] ID3D11CryptoSession *pCryptoSession, > + [in] UINT DataSize, > + [in,out] void *pData); > + void EncryptionBlt( > + [in] ID3D11CryptoSession *pCryptoSession, > + [in] ID3D11Texture2D *pSrcSurface, > + [in] ID3D11Texture2D *pDstSurface, > + [in] UINT IVSize, > + [in,out] void *pIV); > + void DecryptionBlt( > + [in] ID3D11CryptoSession *pCryptoSession, > + [in] ID3D11Texture2D *pSrcSurface, > + [in] ID3D11Texture2D *pDstSurface, > + [in] D3D11_ENCRYPTED_BLOCK_INFO *pEncryptedBlockInfo, > + [in] UINT ContentKeySize, > + [in] const void *pContentKey, > + [in] UINT IVSize, > + [in,out] void *pIV); > + void StartSessionKeyRefresh( > + [in] ID3D11CryptoSession *pCryptoSession, > + [in] UINT RandomNumberSize, > + [out] void *pRandomNumber); > + void FinishSessionKeyRefresh( > + [in] ID3D11CryptoSession *pCryptoSession); > + HRESULT GetEncryptionBltKey( > + [in] ID3D11CryptoSession *pCryptoSession, > + [in] UINT KeySize, > + [out] void *pReadbackKey); > + HRESULT NegotiateAuthenticatedChannelKeyExchange( > + [in] ID3D11AuthenticatedChannel *pChannel, > + [in] UINT DataSize, > + [in,out] void *pData); > + HRESULT QueryAuthenticatedChannel( > + [in] ID3D11AuthenticatedChannel *pChannel, > + [in] UINT InputSize, > + [in] const void *pInput, > + [in] UINT OutputSize, > + [out] void *pOutput); > + HRESULT ConfigureAuthenticatedChannel( > + [in] ID3D11AuthenticatedChannel *pChannel, > + [in] UINT InputSize, > + [in] const void *pInput, > + [out] D3D11_AUTHENTICATED_CONFIGURE_OUTPUT *pOutput); > + void VideoProcessorSetStreamRotation( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [in] BOOL Enable, > + [in] D3D11_VIDEO_PROCESSOR_ROTATION Rotation); > + void VideoProcessorGetStreamRotation( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + [in] UINT StreamIndex, > + [out] BOOL *pEnable, > + [out] D3D11_VIDEO_PROCESSOR_ROTATION *pRotation); > +} > + > +[ > + object, > + local, > + uuid(31627037-53ab-4200-9061-05faa9ab45f9) > +] > +interface ID3D11VideoProcessorEnumerator : ID3D11DeviceChild > +{ > + HRESULT GetVideoProcessorContentDesc( > + [out] D3D11_VIDEO_PROCESSOR_CONTENT_DESC *pContentDesc); > + HRESULT CheckVideoProcessorFormat( > + [in] DXGI_FORMAT Format, > + [out] UINT *pFlags); > + HRESULT GetVideoProcessorCaps( > + [out] D3D11_VIDEO_PROCESSOR_CAPS *pCaps); > + HRESULT GetVideoProcessorRateConversionCaps( > + [in] UINT TypeIndex, > + [out] D3D11_VIDEO_PROCESSOR_RATE_CONVERSION_CAPS *pCaps); > + HRESULT GetVideoProcessorCustomRate( > + [in] UINT TypeIndex, > + [in] UINT CustomRateIndex, > + [out] D3D11_VIDEO_PROCESSOR_CUSTOM_RATE *pRate); > + HRESULT GetVideoProcessorFilterRange( > + [in] D3D11_VIDEO_PROCESSOR_FILTER Filter, > + [out] D3D11_VIDEO_PROCESSOR_FILTER_RANGE *pRange); > +} > + > +[ > + object, > + local, > + uuid(10ec4d5b-975a-4689-b9e4-d0aac30fe333) > +] > +interface ID3D11VideoDevice : IUnknown > +{ > + HRESULT CreateVideoDecoder( > + [in] const D3D11_VIDEO_DECODER_DESC *pVideoDesc, > + [in] const D3D11_VIDEO_DECODER_CONFIG *pConfig, > + [out] ID3D11VideoDecoder **ppDecoder); > + HRESULT CreateVideoProcessor( > + [in] ID3D11VideoProcessorEnumerator *pEnum, > + [in] UINT RateConversionIndex, > + [out] ID3D11VideoProcessor **ppVideoProcessor); > + HRESULT CreateAuthenticatedChannel( > + [in] D3D11_AUTHENTICATED_CHANNEL_TYPE ChannelType, > + [out] ID3D11AuthenticatedChannel **ppAuthenticatedChannel); > + HRESULT CreateCryptoSession( > + [in] const GUID *pCryptoType, > + [in] const GUID *pDecoderProfile, > + [in] const GUID *pKeyExchangeType, > + [out] ID3D11CryptoSession **ppCryptoSession); > + HRESULT CreateVideoDecoderOutputView( > + [in] ID3D11Resource *pResource, > + [in] const D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC *pDesc, > + [out] ID3D11VideoDecoderOutputView **ppVDOVView); > + HRESULT CreateVideoProcessorInputView( > + [in] ID3D11Resource *pResource, > + [in] ID3D11VideoProcessorEnumerator *pEnum, > + [in] const D3D11_VIDEO_PROCESSOR_INPUT_VIEW_DESC *pDesc, > + [out] ID3D11VideoProcessorInputView **ppVPIView); > + HRESULT CreateVideoProcessorOutputView( > + [in] ID3D11Resource *pResource, > + [in] ID3D11VideoProcessorEnumerator *pEnum, > + [in] const D3D11_VIDEO_PROCESSOR_OUTPUT_VIEW_DESC *pDesc, > + [out] ID3D11VideoProcessorOutputView **ppVPOView); > + HRESULT CreateVideoProcessorEnumerator( > + [in] const D3D11_VIDEO_PROCESSOR_CONTENT_DESC *pDesc, > + [out] ID3D11VideoProcessorEnumerator **ppEnum); > + UINT GetVideoDecoderProfileCount(void); > + HRESULT GetVideoDecoderProfile( > + [in] UINT Index, > + [out] GUID *pDecoderProfile); > + HRESULT CheckVideoDecoderFormat( > + [in] const GUID *pDecoderProfile, > + [in] DXGI_FORMAT Format, > + [out] BOOL *pSupported); > + HRESULT GetVideoDecoderConfigCount( > + [in] const D3D11_VIDEO_DECODER_DESC *pDesc, > + [out] UINT *pCount); > + HRESULT GetVideoDecoderConfig( > + [in] const D3D11_VIDEO_DECODER_DESC *pDesc, > + [in] UINT Index, > + [out] D3D11_VIDEO_DECODER_CONFIG *pConfig); > + HRESULT GetContentProtectionCaps( > + [in] const GUID *pCryptoType, > + [in] const GUID *pDecoderProfile, > + [out] D3D11_VIDEO_CONTENT_PROTECTION_CAPS *pCaps); > + HRESULT CheckCryptoKeyExchange( > + [in] const GUID *pCryptoType, > + [in] const GUID *pDecoderProfile, > + [in] UINT Index, > + [out] GUID *pKeyExchangeType); > + HRESULT SetPrivateData( > + [in] REFGUID guid, > + [in] UINT DataSize, > + [in] const void *pData); > + HRESULT SetPrivateDataInterface( > + [in] REFGUID guid, > + [in] const IUnknown *pData); > +} > + > typedef enum D3D11_CREATE_DEVICE_FLAG { > - D3D11_CREATE_DEVICE_SINGLETHREADED = 0x0001, > - D3D11_CREATE_DEVICE_DEBUG = 0x0002, > - D3D11_CREATE_DEVICE_SWITCH_TO_REF = 0x0004, > - D3D11_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS = 0x0008, > - D3D11_CREATE_DEVICE_BGRA_SUPPORT = 0x0020, > - D3D11_CREATE_DEVICE_DEBUGGABLE = 0x0040, > + D3D11_CREATE_DEVICE_SINGLETHREADED = 0x0001, > + D3D11_CREATE_DEVICE_DEBUG = 0x0002, > + D3D11_CREATE_DEVICE_SWITCH_TO_REF = 0x0004, > + D3D11_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS = 0x0008, > + D3D11_CREATE_DEVICE_BGRA_SUPPORT = 0x0020, > + D3D11_CREATE_DEVICE_DEBUGGABLE = 0x0040, > D3D11_CREATE_DEVICE_PREVENT_ALTERING_LAYER_SETTINGS_FROM_REGISTRY = 0x0080, > - D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT = 0x0100, > - D3D11_CREATE_DEVICE_VIDEO_SUPPORT = 0x0800 > + D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT = 0x0100, > + D3D11_CREATE_DEVICE_VIDEO_SUPPORT = 0x0800 > } D3D11_CREATE_DEVICE_FLAG; > > const UINT D3D11_SDK_VERSION = 7; > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVUHHsAAoJEN0/YqbEcdMwt5IP/RQUorEad9xeKijd+ylUAZNH k9W6EpbcMUcwd8bWEE95XQadiG+NQ/IpQDrVAanqX8yW5rA9ldfVZmX5AzgQDY1b 2+z6DZ41S8AqUQFkjakJmlAJu9KAEh+jbDFEl5742ZRu0XARF1cQkJ8tDuNKOmUY dPetkbiPVNoP3wbfTr5PaQD5Ti4IgzkoPXP2ZEnLw//BGbqvj8zODN3KEEPrXW4X Vx9lGihijOiSbCs225sBCA9gV5qGdtAZaDRaYBhcBhssL79/zfe+IhRgSlFDfN9G DVu7MhCbJpC4ZhMiJq7XwywBFDFmRKRJ6ppOi5luUHOuowooG1OV71j+zkiTcId0 xkKiwz7hvRn634rbP8MO7jShVGJczYJRCECNYa8UcIz1IFJm/jas1lj3fNt0mZlw DWzOv5MxvNVyI61IgQs2kgJhOjKmya62Wsz1f7W4TFWazMg2/QKN4K97P2GH3B4L sypDv7Zgszds4kZDnihVzbJY115XlrbEEjyC2/wTzLr07ThwaFQGs1xlOkIYFiJY GrRdouYJlfGmg1vCV7BOgNkeQrOdEXWOgmD9lw3cDWqnBMvabVBPYWPUGk62yzNQ F9o0hktsMOAN+eHqD1kH5EcZX5qICIb+ys0SWWpROAkfnS3cbJfdBHeNYiRAFMfZ TVNEg78wDgXDA8MmxhAQ =efTb -----END PGP SIGNATURE-----

2 1

Re: [PATCH] add the interfaces necessary to use the D3D11 video decoder
by Matteo Bruni 11 May '15

11 May '15

2015-05-08 9:03 GMT+02:00 Steve Lhomme <robux4(a)videolabs.io>: > Anyone has anything to say about this ? > > Thanks > > On Tue, May 5, 2015 at 1:52 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: >> This is needed by VLC. Hi Steve, some parts of the patch are clearly copypasted from the MS idl, which is a deal breaker. While rewriting those parts try to use the wined3d style, like putting the '*' next to the variable instead of the type. Another potential issue (noticed by Henri) is that D3D11_VIDEO_PROCESSOR_COLOR_SPACE uses bitfields which aren't generally portable. I don't know if their implementation on Windows is compatible with the one used by the OSs and architectures we support. If that's not the case then we have a problem...

2 1

Re: [PATCH 5/5] shell32: Implement FolderItemVerbs::Item()
by Marvin 10 May '15

10 May '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=13306 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CB87106 === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CAA259F === wvistau64 (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 75C4B510 === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7522B578 === w7u (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 76C263C4 === wvistau64 (64 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 000007FEFEA52BD9 === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 000007FEFE352A7D

1 0

Re: [PATCH 3/5] shell32: Implement FolderItemVerbs_get_Count()
by Marvin 10 May '15

10 May '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=13305 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CB87106 === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CAA259F === wvistau64 (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 75C4B510 === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7522B578 === w7u (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 76C263C4 === wvistau64 (64 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 000007FEFEA52BD9 === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 000007FEFE352A7D

1 0

Re: [PATCH 2/5] shell32: Added FolderItemVerbs stub
by Marvin 10 May '15

10 May '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=13304 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CB87106 === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7CAA259F === wvistau64 (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 75C4B510 === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 7522B578 === w7u (32 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 76C263C4 === wvistau64 (64 bit shelldispatch) === shelldispatch: unhandled exception c0000005 at 000007FEFEA52BD9 === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" shelldispatch: unhandled exception c0000005 at 000007FEFE352A7D

1 0

Re: [PATCH 1/5] shell32: Implement ParseName()
by Marvin 10 May '15

10 May '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=13303 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\cadabra" === w2003std (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Documents and Settings\\Administrator\\Local Settings\\Temp\\cadabra" === w2008s64 (32 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra" === w2008s64 (64 bit shelldispatch) === shelldispatch.c:737: Test failed: path L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\cadabra"

1 0

WineTest log size
by Francois Gouget 08 May '15

08 May '15

TL;DR: The todo below generates more than 90 KB of test report data. It would be really nice to fix it. storage32.c:3401: todo_wine ok(failed == expect_failed, "open with byte %x locked, mode %x %s but should %s\n", Some of my WineTest reports went over the 1.5MB limit again and while the issue was not what I initially thought, I wrote a script (see attachment) to slice and dice them to figure out who contributes what. Lines Bytes Category 1530 114848 9 traces generating >= 5120 bytes each 1842 106511 33 traces generating 2048 - 5119 bytes each 7020 358649 2221 traces generating < 2048 bytes each 2071 180266 9 todos generating >= 5120 bytes each 842 67746 20 todos generating 2048 - 5119 bytes each 4622 329705 2894 todos generating < 2048 bytes each 170 15372 Test failed 2787 144801 Others -------------------- 20884 1317898 Total Traces are easy to deal with so I've sent some patches. We'll see how it goes. The todos are much harder as they require fixing Wine. Still, if we manage to fix the top 9 we'll save around 180 KB. The next 66 KB require fixing 20 more todos, which is still somewhat plausible, but it gets hopeless after that. The 'Others' category corresponds to the report header with the dlls list, and to the per test summaries. So we're looking at minimum report size of 813 KB, but in practice we're unlikely to get below 1 MB. Here are the top 20 traces and todos: $ dupcount --traces *.report | head -n 20 Lines Chars Match 296 31777 font.c:3711: # Patch pending 339 20378 protocol.c:765: # Patch pending 143 14471 ddrawmodes.c:369: # Patch pending 171 9576 loader.c:1414: # Patch pending 226 9121 clipboard.c:154: # Patch pending 90 9050 ddrawmodes.c:340: # Patch pending 105 7875 istream.c:486: # Patch pending 82 7444 win.c:82: 78 5156 button.c:588: 85 5015 shlview.c:59: 145 4785 locale.c:3296: # Patch pending 131 4716 protocol.c:583: # Patch pending 54 4539 http.c:428: 56 4300 metafile.c:1736: 75 4050 locale.c:3215: # Patch pending 145 3936 locale.c:3190: # Patch pending 57 3846 msg.c:11475: 98 3626 clipboard.c:132: # Patch pending 48 3574 metafile.c:504: $ dupcount -e '^[^:]*:[0-9]*: Test marked todo*:' *.report | head -n 20 Lines Chars Match 902 93357 storage32.c:3401: Test marked todo: 296 21312 sock.c:2741: Test marked todo: 256 18176 virtual.c:3350: Test marked todo: 256 14592 ebrowser.c:1742: Test marked todo: 110 8405 shlexec.c:1472: Test marked todo: 22 6530 shlexec.c:1462: Test marked todo: 74 6395 font.c:3789: Test marked todo: 92 6074 propvariant.c:169: Test marked todo: 63 5425 font.c:3781: Test marked todo: 63 4788 file.c:4209: Test marked todo: 63 4714 file.c:4207: Test marked todo: 29 4569 dib.c:1322: Test marked todo: 64 4504 graphics.c:3686: Test marked todo: 64 4432 graphics.c:3657: Test marked todo: 64 4432 graphics.c:3674: Test marked todo: 54 4042 saxreader.c:2393: Test marked todo: 42 3982 qcap.c:337: Test marked todo: 38 3834 saxreader.c:2489: Test marked todo: 25 3764 batch.c:312: Test marked todo: -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

2 1

Re: gdi32/tests: Silence some font traces that generate too many lines.
by Marvin 08 May '15

08 May '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=13293 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Re: [PATCH] add the interfaces necessary to use the D3D11 video decoder
by Qian Hong 08 May '15

08 May '15

Hi Steve, On Fri, May 8, 2015 at 3:03 PM, Steve Lhomme <robux4(a)videolabs.io> wrote: > Anyone has anything to say about this ? Thanks for your contribution, glad to see VLC people! I'm not the right person to ack your patch, but I can help to point out a few tiny formatting issues: - The patch title could be rename to "include: Add D3D11 video decoder interfaces" Here is an example of this stile of patch title: `git show e35f82665cfdb40231c2e0a8a41c81642273160d` - There are a couple of trailing spaces in the code which should be removed, for example: 94 + UINT NumEncryptedBytesAtBeginning;<spaces> 176 +typedef struct D3D11_VIDEO_PROCESSOR_CUSTOM_RATE<space> and about 90+ more lines with trailing spaces. Could you fix that and resubmit? Thanks! -- Regards, Qian Hong - http://www.winehq.org

1 0

[PATCH 1/2] cmd/tests: Add tests for console InsertMode
by Hugh McMaster 07 May '15

07 May '15

Alexandre, What changes to you want to see for my InsertMode tests to be committed? http://source.winehq.org/patches/data/111149 Thanks, Hugh -- Hugh McMaster

1 0

Re: winecfg: add all Windows versions and accompanying error message (try 5)
by Jason Overland 06 May '15

06 May '15

Is there anything I can do to improve this patch? Thanks, Jason On 04/30/2015 01:56 PM, Jason Overland wrote: > This supercedes winecfg: add all Windows versions and accompanying error message (try 4). > > Changes since try 4: > > Windows versions that are unavailable in 64 bit prefixes now have a different text in the combobox saying as such. They still display an error dialog if the user tries to select them.

1 0

Re: user32: After handling an internal message give a chance to real message to arrive.
by Alexandre Julliard 06 May '15

06 May '15

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > else > peek_message( msg, info.msg.hwnd, info.msg.message, > info.msg.message, flags | PM_REMOVE, changed_mask ); > - continue; > + > + /* give a chance to real message to arrive */ > + HeapFree( GetProcessHeap(), 0, buffer ); > + return FALSE; Why do you need to leave the function instead of checking for further messages? What is the issue you are seeing? -- Alexandre Julliard julliard(a)winehq.org

2 17

Wine Joysticks, seeking a plan
by Aric Stewart 06 May '15

06 May '15

Hi all, Ok I sat down with Ken (the benefits of being in the same office) and after a lengthy discussion I have come to terms with how it may not be the most ideal plan to put the joystick driver into the graphics driver. However I am still of the strong opinion that we need some sort of better joystick architecture and I know Alexandre is also of the like mindset. This was discussed back on 2005 and I know there was also recent discussion around BSD that also involves this. I also have an itch to start to poke at xinput, but I have no interest in poking at xinput with the current way joysticks are handled. When I was working on this driver thing Alexandre expressed he was pretty opposed to having a whole new set of platform specific wine drivers. (winejoystick_mac, winejoystick_linux, etc...) But if we at least did that we would reduce code duplication by not having the platform specific code duplicated in 2 (with xinput it would become 3) places and have it collected in one place. Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant. but before I do another big chunk of work I am seeking some community buy-in and not just discuss with with Alexandre. I understand if the USB driver path gets actually fleshed out and we try to support Joysticks via that then all this separate driver work would fall away and be replaced. We of course need to make sure we come up with a plan that Alexandre will approve of. Would a replacement winejoystick.drv that holds all the platform specific code be acceptable? Is there a case where we would want that driver to be able to build multiple platform code? Maybe Linux and Linux Input? I will admit I am pretty ignorant of the Linux side of this whole situation. Ideas? Comments? thanks! -aric

7 9

Re: [PATCH 1/2] shell32: Implement Application property of IShellFolderViewDual
by Marvin 06 May '15

06 May '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=13252 Your paranoid android. === wxppro (32 bit shelldispatch) === shelldispatch.c:389: Test failed: unexpected type guid {efd84b2d-4bcf-4298-be25-eb542a59fbda} === w2003std (32 bit shelldispatch) === shelldispatch.c:389: Test failed: unexpected type guid {efd84b2d-4bcf-4298-be25-eb542a59fbda}

1 0

Re: (resend) server: fixup input windows on thread_detach
by Alexandre Julliard 05 May '15

05 May '15

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -637,7 +637,7 @@ DECL_HANDLER(set_thread_desktop) > if (!current->process->desktop) > set_process_default_desktop( current->process, new_desktop, req->handle ); > > - if (old_desktop != new_desktop && current->queue) detach_thread_input( current ); > + if (old_desktop != new_desktop && current->queue) detach_thread_input( current, NULL ); You should also update the thread input in that case. There's no reason to require a specific thread for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/5] ddraw/tests: Add a ddraw2 specular lighting test.
by Marvin 04 May '15

04 May '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=13219 Your paranoid android. === build (build) === Make failed

2 1

Re: [PATCH 2/4] wined3d: Keep track of renderbuffer capabilities.
by Henri Verbeet 04 May '15

04 May '15

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 36be539..ad9b496 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4095,7 +4095,7 @@ static BOOL wined3d_check_pixel_format_color(const struct wined3d_gl_info *gl_in > BYTE redSize, greenSize, blueSize, alphaSize, colorBits; > > /* Float formats need FBOs. If FBOs are used this function isn't called */ > - if (format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_FLOAT) > + if (format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_FLOAT) That's not wrong as such, but it is pretty arbitrary. WINED3DFMT_FLAG_FLOAT is a basic property of the format, like e.g. the component masks and sizes, it shouldn't depend on the resource type. Once we'll get proper integer types for d3d10, it will probably make sense to keep track of the type (INT/UINT/FLOAT/UNORM/SNORM) as an enumeration instead, perhaps even per-component. > @@ -4178,8 +4178,8 @@ HRESULT CDECL wined3d_check_depth_stencil_match(const struct wined3d *wined3d, > ds_format = wined3d_get_format(&adapter->gl_info, depth_stencil_format_id); > if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > { > - if ((rt_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_RENDERTARGET) > - && (ds_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if ((rt_format->flags[WINED3D_GL_RES_TYPE_RB] & WINED3DFMT_FLAG_RENDERTARGET) > + && (ds_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) This is actually wrong. At least, as long as we don't allow (plain) renderbuffers to be used for FBO attachments. There's nothing in the spec that says formats that can be used for color rendering with renderbuffers have to be available for color rendering with textures as well, and in fact that's much of the reason for this patch set. > @@ -998,9 +998,9 @@ static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined > break; > > case WINED3D_BLIT_OP_DEPTH_BLIT: > - if (!(src_format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + if (!(src_format->flags[WINED3D_GL_RES_TYPE_RB] & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) Similar to WINED3DFMT_FLAG_FLOAT, these are basic properties of the format.

2 4

Re: server: fixup input windows on thread_detach
by Alexandre Julliard 04 May '15

04 May '15

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1075,6 +1075,27 @@ int attach_thread_input( struct thread *thread_from, struct thread *thread_to ) > return ret; > } > > +/* ensure the input data is correct for the thread after detach */ > +void correct_thread_input( struct thread *thread_from ) > +{ > + if (thread_from->queue) > + { > + struct thread *thread; > + if (thread_from->queue->input->focus) > + { > + thread = get_window_thread( thread_from->queue->input->focus ); > + if (thread != thread_from) thread_from->queue->input->focus = 0; > + release_object( thread ); > + } > + if (thread_from->queue->input->active) > + { > + thread = get_window_thread( thread_from->queue->input->active ); > + if (thread != thread_from) thread_from->queue->input->active = 0; > + release_object( thread ); > + } > + } > +} This needs to be done inside detach_thread_input so that it happens for all callers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ws2_32: Properly handle closing sockets during a select call.
by Marvin 04 May '15

04 May '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=13205 Your paranoid android. === wxppro (32 bit sock) === sock: unhandled exception c0000005 at C0000241

1 0

Re: [2/3] ntdll: Introduce a helper function to check for existance of server handles.
by Alexandre Julliard 04 May '15

04 May '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -1417,6 +1417,7 @@ > # Server interface > @ cdecl -norelay wine_server_call(ptr) > @ cdecl wine_server_fd_to_handle(long long long ptr) > +@ cdecl wine_server_handle_exists(long long) > @ cdecl wine_server_handle_to_fd(long long ptr ptr) > @ cdecl wine_server_release_fd(long long) > @ cdecl wine_server_send_fd(long) Why do you need a new export for this? Is it just to avoid a dup() call or is there another reason? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: jscript: Date.parse: long date with '/' or '-' (try2)
by Marvin 04 May '15

04 May '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=13202 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

libwine
by Theodore Dubois 04 May '15

04 May '15

Hi, I’ve been looking at the wine code, and wondering why all the initialization code is in libwine.so. I would think it would make more sense to put it in the wine executable itself. Any explanations? ~Theodore

1 0

Re: jscript: Date.parse: long date with '/' or '-' (try2)
by Marvin 03 May '15

03 May '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=13201 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

2 1

Re: [PATCH 5/5] shell32: Better handle creation/destruction of shellview window
by Marvin 03 May '15

03 May '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=13190 Your paranoid android. === wxppro (32 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected === w2003std (32 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected === wvistau64 (32 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:579: Test failed: unexpected === w2008s64 (32 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:579: Test failed: unexpected === wvistau64 (64 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:579: Test failed: unexpected === w2008s64 (64 bit shlview) === shlview.c:573: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:586: Test failed: unexpected shlview.c:605: Test failed: unexpected shlview.c:579: Test failed: unexpected shlview.c:579: Test failed: unexpected

1 0

Re: [PATCH 4/5] explorer: Return IShellBrowser in response to SID_STopLevelBrowser
by Marvin 03 May '15

03 May '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=13189 Your paranoid android. === wvistau64 (64 bit shelldispatch) === The test timed out

1 0

Re: [2/3] user32: Add some tests for EndDialog called from other thread.
by Marvin 30 Apr '15

30 Apr '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=13148 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 314e6/314f6

1 0

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window. Resend.
by Marvin 30 Apr '15

30 Apr '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=13147 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30ece/30ede

1 0

Re: [PATCH 2/5] d3d9/tests: Add a test for UpdateTexture. (v2, resend)
by Alexandre Julliard 30 Apr '15

30 Apr '15

Matteo Bruni <mbruni(a)codeweavers.com> writes: > v2: Make tests pass on the testbot, add a couple more test cases, some > small cleanups. It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so visual && touch visual.ok visual.c:12925: Tests skipped: No NVDB (depth bounds test) support, skipping tests. visual.c:16373: Tests skipped: DXT5 volume textures are not supported, skipping test. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 4. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 1. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 2. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 3. visual.c:18582: Test failed: Got unexpected color 0x0036c800, case 1, 4. visual.c:18409: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 1. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 2. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 3. visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 2, 4. make: *** [visual.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] wined3d: Don't use depth textures without ARB_depth_texture.
by Henri Verbeet 30 Apr '15

30 Apr '15

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (!gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + static const unsigned int depth_flags = WINED3DFMT_FLAG_SHADOW | WINED3DFMT_FLAG_DEPTH > + | WINED3DFMT_FLAG_STENCIL; > + format->flags[WINED3D_GL_RES_TYPE_TEX_1D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_2D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_3D] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_CUBE] &= ~depth_flags; > + format->flags[WINED3D_GL_RES_TYPE_TEX_RECT] &= ~depth_flags; > + } This is wrong for the reasons mentioned in patch 2/4, but it should also be unnecessary. WINED3DFMT_FLAG_TEXTURE is supposed to indicate if you can use a format for texturing or not.

1 0

Re: [PATCH 3/4] wined3d: Use renderbuffers if the resource type is RB.
by Henri Verbeet 30 Apr '15

30 Apr '15

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -341,6 +341,8 @@ void wined3d_resource_update_draw_binding(struct wined3d_resource *resource) > resource->draw_binding = WINED3D_LOCATION_DRAWABLE; > else if (resource->multisample_type) > resource->draw_binding = WINED3D_LOCATION_RB_MULTISAMPLE; > + else if (resource->gl_type == WINED3D_GL_RES_TYPE_RB) > + resource->draw_binding = WINED3D_LOCATION_RB_RESOLVED; I haven't looked much into what actually happens now, but the last time I looked at using renderbuffers for FBO attachments, one of the issues that came up was the initial surface contents. Right now we handle that by clearing WINED3D_LOCATION_SYSMEM and marking it current, but that won't work so well for renderbuffers. Somewhat related, does WINED3DFMT_D16_LOCKABLE need special handling?

1 0

Re: [PATCH 1/4] wined3d: Allow specifying a different depth stencil location.
by Henri Verbeet 30 Apr '15

30 Apr '15

On 30 April 2015 at 00:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2342,12 +2352,14 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > ++i; > } > context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, > - wined3d_rendertarget_view_get_surface(fb->depth_stencil), > - rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > + wined3d_rendertarget_view_get_surface(dsv), > + rt_count ? rts[0]->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB, > + dsv ? dsv->resource->draw_binding : WINED3D_LOCATION_TEXTURE_RGB); > } This works because we mostly just care that the color location isn't WINED3D_LOCATION_DRAWABLE if there's no attachment. (In particular for the case where the application is doing depth only rendering.) Strictly speaking though, it's probably more correct to use the color location if there's no depth/stencil attachment, to avoid silliness like the color attachment being in WINED3D_LOCATION_DRAWABLE and the depth/stencil attachment in WINED3D_LOCATION_TEXTURE_RGB. In fact, now that the color and depth/stencil locations are separate, you can probably just pass 0.

1 0

Re: [PATCH 5/5] wined3d: Don't use the same va_list multiple times in shader_vaddline().
by Henri Verbeet 30 Apr '15

30 Apr '15

On 29 April 2015 at 23:34, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > -static void string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > +static int string_buffer_vsprintf(struct wined3d_string_buffer *buffer, const char *format, va_list args) > { > if (!buffer) > - return; > + return 0; > string_buffer_clear(buffer); > - shader_vaddline(buffer, format, args); > + return shader_vaddline(buffer, format, args); > } > You could perhaps just merge this into string_buffer_sprintf(), but I don't care that much.

1 0

Re: d3drm: Fix refcounting for IDirect3DRM{1-3}
by Stefan Dösinger 30 Apr '15

30 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-29 um 23:47 schrieb Aaryaman Vasishta: > - if (!refcount) > + if (!refcount && !InterlockedDecrement(&d3drm->numIfaces)) > HeapFree(GetProcessHeap(), 0, d3drm); This works, but this way you have the code that destroys the object 3 times. Not much of an issue as long as it is just a HeapFree, but I think it would be nicer to have a separate function. Either add a d3drm_destroy function or a pair of d3drm_add_iface and d3drm_release_iface functions that also take care of InterlockedIncrement / Decrement for iface_count) > - { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, TRUE }, > - { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, TRUE }, > + { &IID_IDirect3DRM3, &IID_IDirect3DRM3, S_OK, FALSE }, > + { &IID_IDirect3DRM2, &IID_IDirect3DRM2, S_OK, FALSE }, Afaics all the TODOs are gone, so you can remove this field from the table and the todo_wine code from test_qi(). Either in the same patch or a separate one. > - LONG ref; > + LONG ref1, ref2, ref3, numIfaces; > }; Please use iface_count. Yeah, it's just a plain style thing, but d3drm is nicely consistent so far in not using CamelCase (except in cases where Microsoft determined the name). (Yesterday on IRC I said num_ifaces. Henri says xxx_count is the way he prefers.) > + if (refcount == 1) InterlockedIncrement(&d3drm->numIfaces); Another minor style issue: Please put the statement on a separate line, in consistency with the existing code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQdzBAAoJEN0/YqbEcdMw5WAP/0H52sqgEXMdSmh6sXH/dZMQ nTZY9uRhElUbb3r6D6HG0ylit994pPaq887t9BSl8F4vbjsPXLjruDbVSwoScCfp rIDKy9xET+ek4p5TSFC9cX1BFAiC2VKN7YYWmr/wHKVPZc+aFudU9ykac02bi9p2 Oe+9wMBcFbwv33UhNL+2dugA4+0yj6egfPJWmju9C6ff6CPGqgXH70rHsrSf1AYs VkNPRhGpfI9BxojBChVtgc0zwPM1HnfOwfmKWCW75YNgNg9lL0o+bdoy2wCcxiLq FYwLLT2o9K+RnPQqRDhdJBKWwY8VrJI/fHZEURRau7RW1ia26j4UrrsAdXTQwhPs Iy8A63pYOxyZsphq5KJ8cwGABYIlBPUG0lXZQRgKh1Jw8f39HIR5cfnu1at/fPSc Cw6tfL/t+g4KeHaZDWZnROwyp704kIZGgvSaPuJjwkPtHh2MN14cp9KQj389kCUM 4KfV6FxsAByRuJ8ur1HSaV2OeIOKOJkaDTzaiiMqc581A0awOeCy5SuAUSrQu4IE 4gAIjryIJXd+kTDw46y6OW5UNXHdNJKGWAMiih25yLBi0BLBfUiW0U7qW5Lcerls e7zefeUYNT+Umj3WU4sDu6B8B6auSZgKrLu9JAwYH2RUhKX9R+z3uTY25VUbJkoP 9WJfJJuosIA5zqLbjxu+ =/BI/ -----END PGP SIGNATURE-----

2 1

Re: kernel32/tests: Add tests for deleting readonly files with NtCreateFile.
by Marvin 30 Apr '15

30 Apr '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=13137 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4052: Test failed: SetFileValidData failed 87 file.c:4055: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [3/3] ws2_32: Properly handle closing sockets during a select call.
by Marvin 30 Apr '15

30 Apr '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=13135 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

Re: shell32: Add caption to run dialog (resend)
by Alex Henrie 30 Apr '15

30 Apr '15

Thanks for your interest in developing Wine! A few pointers: You are supposed to use your name when submitting patches. I don't think Alexandre will accept just your initials. Also, you should avoid putting all that HTML garbage into the patch by using `git format-patch` and `git send-email`. If you cannot use git send-email, send the patch as an attachment. Please read http://wiki.winehq.org/SubmittingPatches Finally, your patch is more likely to be accepted if you can give an example of a Windows program that demonstrates the problem you're trying to fix. -Alex

1 0

Re: [PATCH 2/5] ddraw: Release the surface clipper (if any) in ddraw_surface_wined3d_object_destroyed() (Valgrind).
by Marvin 29 Apr '15

29 Apr '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=13125 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:1373: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1392: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00. ddraw1.c:6666: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6670: Test failed: Got unexpected color 0x00000080.

2 1

Re: Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

On Wed, 29 Apr 2015, Henri Verbeet wrote: > On 29 April 2015 at 12:40, Francois Gouget <fgouget(a)free.fr> wrote: > > I am getting a strange wined3d crash during the d3d8:device test. > > > Is that a regression? We did touch the shader generation code recently. It is actually. This is the patch that introduced the crash: commit 28343db2083de7b4afe4079da090520f44b5544d Author: Matteo Bruni <mbruni(a)codeweavers.com> Date: Mon Apr 27 17:39:12 2015 +0200 wined3d: Don't use the builtin FFP uniforms for the lights. While at it, use D3D-like uniforms for the light parameters and (consequently) implement range and proper D3D spotlights support. I can test patches but I'm not sure I'll have time to debug this much further for a while :-( Note that this is with an Intel HD Graphics 4600 GPU. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

3 2

Re: ws2_32: Include inttypes.h for UINT32_MAX.
by Henri Verbeet 29 Apr '15

29 Apr '15

On 29 April 2015 at 11:34, Francois Gouget <fgouget(a)free.fr> wrote: > This fixes compilation on FreeBSD. > --- > > The only other files that use UINT32_MAX are: > * The .yy.c files. These are generated and always do an ifndef+define. > * dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason. > * dlls/jscript/string.c which simply defines it. > * dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac > OS X headers. > > Maybe mshtml and jscript should use inttypes.h, or to the contrary, > maybe ws2_32 should use the ifndef+define approach. > Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.

4 6

USB Support
by Steve Kenton 29 Apr '15

29 Apr '15

USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? Steve Kenton

5 11

Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

I am getting a strange wined3d crash during the d3d8:device test. It's annoying because it only happens with the 64 bit build, and disappears if I add traces (+d3d or +d3d_shader), and even if I add a FIXME() just before the crash. The crash happens in shader_glsl_ffp_vertex_lighting(): shader_addline(buffer, "gl_FrontSecondaryColor = %s * specular;\n", specular); According to the checks I've been able to do the specular pointer is still correct when this gets called. Here's the backtrace: http://pastebin.com/DKvXTVJn Any idea what's up? It almost feels like a compiler bug (gcc 4.9.2 (Debian 4.9.2-10) here). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 0

Re: [PATCH] wined3d: fix different level count while texture update
by Henri Verbeet 29 Apr '15

29 Apr '15

On 28 April 2015 at 20:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38048 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85) > source texture CAN have greater level count then destination > Current comparison "!=“ causes black textures as discussed in the bugzilla. > This may be correct, it may not be. This change needs tests, and I believe that was pointed out in the bug report already.

1 0

Re: [PATCH] wined3d: fix Unrecognized usage flags
by Henri Verbeet 29 Apr '15

29 Apr '15

Please use git send-email for sending patches. On 28 April 2015 at 09:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); This is fine, but WINED3DUSAGE_OWNDC is missing here as well. Is "buf" still larger enough after you add these flags? > - if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > + if (usage & ~WINED3DUSAGE_QUERY_MASK) FIXME("Unrecognized usage flag(s) %#x\n", usage); I think it makes more sense to do this in the caller. It may make even more sense to just merge debug_d3dusage() and debug_d3dusagequery().

1 0

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alex Henrie 29 Apr '15

29 Apr '15

2015-04-28 8:03 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Alexandre, >> >> What was wrong with this patch that you did not accept it? > > I'm concerned that you have been looking at Windows a bit too much. At first, I thought that Wine actually used this string. On closer look, it seems that Wine always replaces the dialog's string "Borders" with the string resource "Margins [inches]" or "Margins [mm]": https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… The following test (run with `./wine dlls/comdlg32/tests/comdlg32_test.exe.so printdlg`) also supports the hypothesis that Wine always overrides the dialog's string: diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc index d3deeab..9d37d69 100644 --- a/dlls/comdlg32/comdlg32.rc +++ b/dlls/comdlg32/comdlg32.rc @@ -438,7 +438,7 @@ BEGIN GROUPBOX "Orientation", grp1, 8, 156, 64, 56, BS_GROUPBOX AUTORADIOBUTTON "&Portrait", rad1, 16, 170, 52, 12, BS_AUTORADIOBUTTON AUTORADIOBUTTON "&Landscape", rad2, 16, 190, 52, 12, BS_AUTORADIOBUTTON - GROUPBOX "Borders", grp4, 80, 156, 152, 56, BS_GROUPBOX + GROUPBOX "foobar", grp4, 80, 156, 152, 56, BS_GROUPBOX LTEXT "L&eft:", stc15, 88, 172, 30, 8 EDITTEXT edt4, 119, 170, 36, 12, WS_TABSTOP|WS_GROUP|WS_BORDER LTEXT "&Right:", stc16, 159, 172, 30, 8 diff --git a/dlls/comdlg32/tests/printdlg.c b/dlls/comdlg32/tests/printdlg.c index 7e06c97..d6c7dff 100644 --- a/dlls/comdlg32/tests/printdlg.c +++ b/dlls/comdlg32/tests/printdlg.c @@ -88,7 +88,7 @@ static void test_PageSetupDlgA(void) ZeroMemory(pDlg, sizeof(PAGESETUPDLGA)); pDlg->lStructSize = sizeof(PAGESETUPDLGA); - pDlg->Flags = PSD_RETURNDEFAULT | PSD_NOWARNING; + pDlg->Flags = PSD_NOWARNING; SetLastError(0xdeadbeef); res = PageSetupDlgA(pDlg); ok( res || (CommDlgExtendedError() == PDERR_NODEFAULTPRN), If I am correct, it would be better to replace "Borders" with "" so that translators have one less string to worry about. Is that acceptable to you? -Alex

2 1

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alexandre Julliard 28 Apr '15

28 Apr '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Alexandre, > > What was wrong with this patch that you did not accept it? I'm concerned that you have been looking at Windows a bit too much. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Added IShellFolderViewDual definition
by Marvin 28 Apr '15

28 Apr '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=13085 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Henri Verbeet 28 Apr '15

28 Apr '15

On 27 April 2015 at 17:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static const float pi = 3.141592654f; I guess you'll have to resubmit this for the testbot, but while you're at it, I think I prefer M_PI.

1 0

Re: [PATCH 3/6] dmloader: Add and use a generic IPersistStream_GetClassID.
by Marvin 27 Apr '15

27 Apr '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=13066 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 2/6] dmloader/tests: Add more DirectMusicCollection tests.
by Marvin 27 Apr '15

27 Apr '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=13065 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 1/6] dmloader: Use the generic DirectMusicObject implementation for DMContainer.
by Marvin 27 Apr '15

27 Apr '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=13064 Your paranoid android. === build (build) === Make failed

1 0

Re: jscript: Date.parse: long date with '/' or '-'
by Stefan Dösinger 27 Apr '15

27 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-25 um 17:45 schrieb Thomas Faller: > This format is not documented under > > https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx > > but its implemented in the internet explorer and in the windows > script host. In this case a test would be very useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu Ln6ptTTJVzUg3QpSR6jN =a7ty -----END PGP SIGNATURE-----

2 2

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v3).
by Ken Thomases 27 Apr '15

27 Apr '15

On Apr 27, 2015, at 2:54 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 3: Use SendNotifyMessage for sending WM_MACDRV_DISPLAYCHANGE. > Ken, I need your review again to make sure that this change doesn't > have any negative impact regarding the sync_window_position call that > is part of the WM_MACDRV_DISPLAYCHANGE message handling. Looks OK to me. It is not necessary for the sync_window_position() call to be made synchronously with respect to the sending code. -Ken

1 0

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Marvin 27 Apr '15

27 Apr '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=13061 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: shell32: Add Association Registry entries (resend)
by Marvin 27 Apr '15

27 Apr '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=13043 Your paranoid android. === w2000pro (32 bit assoc) === The test timed out

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings (v3).
by Marvin 27 Apr '15

27 Apr '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=13041 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2497: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2510: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [3/3] user32: Don't perform SetWindowPos synchronously.
by Marvin 27 Apr '15

27 Apr '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=13038 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0017014A msg.c:12252: Test failed: bad time 31267/31276

1 0

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window.
by Marvin 27 Apr '15

27 Apr '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=13037 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 31100/3111f

1 0

Re: [PATCH 4/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices. (v3)
by Henri Verbeet 26 Apr '15

26 Apr '15

On 24 April 2015 at 22:25, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void shader_glsl_ffp_vertex_texmatrix_uniform(const struct wined3d_context *context, > + const struct wined3d_state *state, unsigned int tex, struct glsl_shader_prog_link *prog) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + struct wined3d_matrix mat; > + > + if (tex >= MAX_TEXTURES) > + return; I think the patch is fine as it is, but as a style comment, arguably you aren't so much validating "tex" against MAX_TEXTURES here as against ARRAY_SIZE(texture_matrix_location).

1 0

Re: [PATCH] wined3d: fix wrong struct initialization
by Henri Verbeet 26 Apr '15

26 Apr '15

On 26 April 2015 at 12:22, Patrick Rudolph <siro(a)das-labor.org> wrote: > - static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {FALSE, 1000 * 1000 * 1000}; > + static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {1000 * 1000 * 1000, FALSE}; The change is fine like this, but unfortunately it looks like your MUA has wrapped the patch.

1 0

Re: advapi32/tests: Add tests for RegQueryInfoKey.
by Nikolay Sivov 26 Apr '15

26 Apr '15

On 04/25/2015 08:41 PM, Thomas Faber wrote: > + /* class name with buffer one char too small */ > + memset(classbuffer, 0x55, sizeof(classbuffer)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyA(subkey, classbuffer, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + ok(ret == ERROR_MORE_DATA, "ret = %d\n", ret); > + todo_wine ok(classlen == sizeof(subkey_class) - 2, "classlen = %u\n", classlen); > + todo_wine ok(classbuffer[0] == 's', "classbuffer[0] = 0x%x\n", classbuffer[0]); > + todo_wine ok(classbuffer[1] == 'u', "classbuffer[1] = 0x%x\n", classbuffer[1]); > + todo_wine ok(classbuffer[10] == 's', "classbuffer[10] = 0x%x\n", classbuffer[10]); > + todo_wine ok(classbuffer[11] == 0, "classbuffer[11] = 0x%x\n", classbuffer[11]); > + ok(classbuffer[12] == 0x55, "classbuffer[12] = 0x%x\n", classbuffer[12]); I think it would be more readable if you tested it against a string. Also hardcoded offsets could be avoided in this case. > + memset(classbufferW, 0x55, sizeof(classbufferW)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyW(subkey, classbufferW, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + todo_wine ok(ret == ERROR_INSUFFICIENT_BUFFER, "ret = %d\n", ret); > + ok(classlen == sizeof(subkey_class) - 2 /* win8 */ || > + classlen == strlen(subkey_class), "classlen = %u\n", classlen); > + ok(classbufferW[0] == 0x5555, "classbufferW[0] = 0x%x\n", classbufferW[0]); > + ok(classbufferW[1] == 0x5555, "classbufferW[1] = 0x%x\n", classbufferW[1]); > + ok(classbufferW[10] == 0x5555, "classbufferW[10] = 0x%x\n", classbufferW[10]); > + ok(classbufferW[11] == 0x5555, "classbufferW[11] = 0x%x\n", classbufferW[11]); > + ok(classbufferW[12] == 0x5555, "classbufferW[12] = 0x%x\n", classbufferW[12]); If first element is not changed, it's really unlikely that anything else did. > + ok(classbuffer[12] == 0, "classbuffer[12] = 0x%x\n", classbuffer[12]); > + ok(classbuffer[13] == 0x55, "classbuffer[13] = 0x%x\n", classbuffer[13]); ... > + ok(!lstrcmpW(classbufferW, subkey_classW), "classbufferW = %s\n", wine_dbgstr_w(classbufferW)); > + ok(classbufferW[12] == 0, "classbufferW[12] = 0x%x\n", classbufferW[12]); > + ok(classbufferW[13] == 0x5555, "classbufferW[13] = 0x%x\n", classbufferW[13]); Could you replace offsets with calculated string length instead so it still works for different strings.

2 1

Re: [PATCH] wined3d: fix wrong data order for D3DQUERYTYPE_TIMESTAMPDISJOINT
by Henri Verbeet 25 Apr '15

25 Apr '15

On 25 April 2015 at 14:26, Patrick Rudolph <siro(a)das-labor.org> wrote: > At the moment the querry D3DQUERYTYPE_TIMESTAMPDISJOINT returns TRUE instead > of FALSE due to wrong data order in struct > wined3d_query_data_timestamp_disjoint. > Please use "git send-email" for sending patches. (Or fix your MUA to inline them.) Unfortunately swapping the order of the fields will introduce a hole in the structure between "disjoint" and "frequency", and make it incompatible with the equivalent d3d10 structure (D3D10_QUERY_DATA_TIMESTAMP_DISJOINT). I think it would be much nicer to fix the initializer of "disjoint_data" in wined3d_timestamp_disjoint_query_ops_get_data() to match the structure layout instead.

1 0

Re: (resend)comctl32:TTM_SETTOOLINFO does not change subclassing
by Alexandre Julliard 24 Apr '15

24 Apr '15

Aric Stewart <aric(a)codeweavers.com> writes: > + toolInfo2.cbSize = TTTOOLINFOA_V1_SIZE; > + toolInfo2.hwnd = parent2; > + toolInfo2.uId = 0x1234ABCE; > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(!(toolInfo2.uFlags & TTF_SUBCLASS), "uFlags has subclass\n"); > + wndProc = GetWindowLongPtrA(parent2, GWLP_WNDPROC); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); > + > + toolInfo2.uFlags |= TTF_SUBCLASS; > + SendMessageA(hwndTip, TTM_SETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(toolInfo2.uFlags & TTF_SUBCLASS, "uFlags does not have subclass\n"); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); Please use the correct types for window function pointers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/5] wined3d: Move volume DXTn handling to apply_format_fixups.
by Henri Verbeet 24 Apr '15

24 Apr '15

This fails the d3dx9_36 tests: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so texture && touch texture.ok ... texture.c:1778: Test failed: D3DXCreateVolumeTextureFromFileInMemory returned 0x8876086c, expected 0

1 0

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It's somewhat of an RFC at this point. In particular I'd like some > feedback about the API. In general, I think it goes in the right direction. > An obvious variant would be to store the pointer to the parent > wined3d_shader_buffer structure right before the string and just > return the string itself (thus avoiding having to add ->buffer to > all the uses of the string). Personally, I don't particularly mind the couple of extra characters, and it seems like a good thing to explicitly distinguish between string buffers and regular strings. > + tex_reg_name = shader_sprintf_unsafe(&priv->string_buffers, "tex%u", stage); > shader_glsl_color_correction_ext(buffer, tex_reg_name, WINED3DSP_WRITEMASK_ALL, > settings->op[stage].color_fixup); The problem with this construction is that it is likely to break as soon as shader_glsl_color_correction_ext() does anything that ends up calling shader_get_buffer(). To make it worse, shader_glsl_color_correction_ext() isn't aware of this because it just gets a const char *, and shader_glsl_generate_ffp_fragment_shader() isn't supposed to care about the internals of shader_glsl_color_correction_ext(). > @@ -276,13 +276,17 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > char *base = buffer->buffer + buffer->content_size; > int rc; > char *new_buffer; > + unsigned int new_buffer_size; > > while(1) > { > rc = vsnprintf(base, buffer->buffer_size - buffer->content_size, format, args); > if (rc < 0 /* C89 */ || (unsigned int)rc >= buffer->buffer_size - buffer->content_size /* C99 */) > { > - new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, buffer->buffer_size * 2); > + new_buffer_size = buffer->buffer_size * 2; > + while (rc > 0 && (unsigned int)rc >= new_buffer_size - buffer->content_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > if (!new_buffer) > { > ERR("The buffer allocated for the shader program string is too small at %d bytes.\n", buffer->buffer_size); > @@ -290,7 +294,7 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > return -1; > } > buffer->buffer = new_buffer; > - buffer->buffer_size = buffer->buffer_size * 2; > + buffer->buffer_size = new_buffer_size; > base = buffer->buffer + buffer->content_size; > } > else This is a bit of an unrelated change, but probably the right thing to do. Note that I have an unsent patch that separates tracing the shader source from shader_vaddline() though, so it's going to look a bit different fairly soon. > +static char shader_empty_string[] = ""; This should be const, right? > +static void shader_sprintf_va_list(struct wined3d_shader_buffer *buffer, const char *format, va_list args) I probably would have called that vprintf/vsprintf instead of sprintf_va_list. > +{ > + int ret; > + char *new_buffer; > + unsigned int new_buffer_size; > + > + if (!buffer) > + return; > + while (1) > + { > + ret = vsnprintf(buffer->buffer, buffer->buffer_size, format, args); > + if (ret < 0 || (unsigned int)ret >= buffer->buffer_size) > + { > + new_buffer_size = buffer->buffer_size * 2; > + while (ret > 0 && (unsigned int)ret >= new_buffer_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > + if (!new_buffer) > + { > + ERR("Couldn't allocate buffer for temporary string.\n"); > + buffer->buffer[0] = 0; > + return; > + } > + buffer->buffer = new_buffer; > + buffer->buffer_size = new_buffer_size; > + } > + else > + { > + break; > + } > + } > +} Once tracing the shader source is removed from shader_vaddline(), this comes down to a shader_buffer_clear() followed by shader_vaddline(). And arguably shader_get_buffer() should always shader_buffer_clear() the buffers it returns. > +/* This function immediately puts the buffer back into the free list (it's > + * intended to be used when the string is to be used and discarded immediately, > + * mostly useful to avoid having to move the string pointer out of the block). */ > +const char *shader_sprintf_unsafe(struct list *buffer_list, const char *format, ...) Not a fan, for the reasons mentioned at shader_glsl_generate_ffp_fragment_shader() above. > +void shader_release_buffer(struct list *list, struct wined3d_shader_buffer *buffer) > +{ > + if (!buffer) > + return; Can buffer ever legitimately be NULL? > +void shader_buffer_list_free(struct list *list) > +{ > + struct wined3d_shader_buffer *buffer, *buffer_next; > + > + LIST_FOR_EACH_ENTRY_SAFE(buffer, buffer_next, list, struct wined3d_shader_buffer, entry) > + { > + shader_buffer_free(buffer); > + HeapFree(GetProcessHeap(), 0, buffer); > + } > +} > + This doesn't actually remove the buffers from the list. There may also be an argument for wrapping the list itself in a structure, similar to struct wined3d_private_store. > struct wined3d_shader_buffer > { At some point we'll probably want to rename this to something like "wined3d_string_buffer".

2 2

Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* Always check 2D textures here, we don't want to write this ERR when the app tried > + * to create a compressed volume texture but s3tc support is otherwise available. */ > if ((desc->format == WINED3DFMT_DXT1 || desc->format == WINED3DFMT_DXT2 || desc->format == WINED3DFMT_DXT3 > || desc->format == WINED3DFMT_DXT4 || desc->format == WINED3DFMT_DXT5) > - && !(format->flags & WINED3DFMT_FLAG_TEXTURE) && !once++) > + && !(format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE) && !once++) > ERR_(winediag)("The application tried to create a DXTn texture, but the driver does not support them.\n"); But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition?

2 2

Favor / heads up - wine tasks in a hackathon
by Jeremy White 23 Apr '15

23 Apr '15

My alma mater is putting on a hackathon for college students in our region. http://carlhacks.io/ As an experiment, I'm wanted to see if I could get any of these students interested in Wine hacking. So we've sponsored prize money for any students that can fix a bug in Wine or fix a test. I have no idea if any students are going to take it on or not, but if you see an influx of urgent requests on #winehackers or here, starting Saturday and ending Sunday, you'll know why :-/. And if any such student does actually succeed in contributing a clearly useful or even promising patch, please let me know, so I can make a point to award the prize money during the closing ceremonies. Cheers, Jeremy

1 0

Re: [PATCH 4/5] wined3d: Query info for each resource type from ARB_internalformat_query2.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static GLenum wined3d_gl_type_to_enum(enum wined3d_gl_resource_type type) > +{ > + switch (type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + return GL_TEXTURE_1D; > + case WINED3D_GL_RES_TYPE_TEX_2D: > + return GL_TEXTURE_2D; > + case WINED3D_GL_RES_TYPE_TEX_3D: > + return GL_TEXTURE_3D; > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + return GL_TEXTURE_CUBE_MAP_ARB; > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + return GL_TEXTURE_RECTANGLE_ARB; > + case WINED3D_GL_RES_TYPE_BUFFER: > + return GL_TEXTURE_2D; /* TODO: GL_TEXTURE_BUFFER. */ > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > + ERR("Unexpected GL resource type %u.\n", type); > + return 0; > +} > + > + You have an extra newline here. > + for (type = 0; type < sizeof(format->flags) / sizeof(*format->flags); ++type) This isn't wrong as such, but you can use ARRAY_SIZE for this now. > { > - TRACE("Format %s doesn't support %s.\n", debug_d3dformat(format->id), string); > - format_clear_flag(format, flag); > + gl_info->gl_ops.ext.p_glGetInternalformativ(wined3d_gl_type_to_enum(type), internal, pname, 1, &value); > + if (value == GL_FULL_SUPPORT) > + { > + TRACE("Format %s supports %s.\n", debug_d3dformat(format->id), string); It would probably be helpful if this mentioned the resource type as well.

1 0

Re: [PATCH 5/6] d3d9/tests: Add a specular lighting test.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define VERTICES_SIDE 5 > +#define INDICES_COUNT ((VERTICES_SIDE - 1) * (VERTICES_SIDE - 1) * 2 * 3) > + I don't think you really need to #define these, but if you do you should probably #undef them once you're done with them.

1 0

Re: [PATCH 3/6] wined3d: Introduce D3D7+ normal matrix computation.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define SWAP_ROWS(a, b) { float *tmp = a; a = b; b = tmp; } > + I assume this is mostly borrowed from Mesa like invert_matrix_3d(), but unfortunately Mesa isn't particularly good at writing macros, even though they have more than enough of them. This one happens to more or less work for the cases you have here, but consider the following in particular: if (...) SWAP_ROWS(a, b); else SWAP_ROWS(c, d); Please just use the standard "do { ... } while(0)" construction when you need to define a macro like that. In this particular case there's of course no reason you need a macro in the first place.

1 0

Re: [PATCH 2/2] ntdll: Add support for FileFsFullSizeInformation class in NtQueryVolumeInformationFile(try 2)
by Alexandre Julliard 23 Apr '15

23 Apr '15

"Jianqiu Zhang" <zhangjianqiu_133(a)yeah.net> writes: > + if(!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) > + { > + io->u.Status = STATUS_INVALID_DEVICE_REQUEST; > + } > + else > + { > + ULONGLONG bsize; > +#if !defined(linux) || !defined(HAVE_FSTATFS) > + struct statvfs stfs; > + > + if(fstatvfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_frsize; > +#else > + struct statfs stfs; > + if(fstatfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_bsize; > +#endif Please avoid duplicating all that code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32/tests: Add a trailing '\n' to an ok() call.
by Marvin 23 Apr '15

23 Apr '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=12975 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

Re: user32: After handling an internal message give a chance to real message to arrive.
by Marvin 23 Apr '15

23 Apr '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=12973 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 315f0/315ff

1 0

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard 23 Apr '15

23 Apr '15

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: [PATCH 2/2] krnl386: Invalid console handles should translate into real handles when creating a new process.
by Alexandre Julliard 23 Apr '15

23 Apr '15

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch fixes an issue exposed by the fix in patch 1. The current > mechanism for initializing the DOS handles for a process uses > DuplicateHandle, which converts INVALID_HANDLE_VALUE into a usable > handle (but not 0). Without this fix the Caesar III demo installer > crashes with an unhandled page fault, though it may be more desirable > to allocate new handles than to replicate the behavior we used to have > prior to patch 1. Proper handles would be better, simply open the null device or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] wined3d: Shadow format flags in wined3d_rendertarget_view.
by Henri Verbeet 22 Apr '15

22 Apr '15

On 22 April 2015 at 11:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -101,6 +101,7 @@ static void wined3d_rendertarget_view_init(struct wined3d_rendertarget_view *vie > view->parent_ops = parent_ops; > > view->format = wined3d_get_format(gl_info, desc->format_id); > + view->format_flags = resource->format_flags; That's wrong. We won't be able to do much with this until we support ARB_texture_view, but the view format is mostly independent of the resource format, other than that they have to be from the same compatibility class. I guess you'd want something like "view->format_flags = view->format->flags[resource->gl_type];".

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)
by Stefan Dösinger 22 Apr '15

22 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-22 um 05:30 schrieb Alistair Leslie-Hughes: > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } > + > + if((*pdwNameLen && !pwszName) || (*pdwBufferSize && !pvBuffer)) > + return E_POINTER; This check suggests that a NULL pwszName is ok if *pdwNameLen is 0. However, the above check fails in this situation. Depending on how you want this to behave there's either an error in your logic or you have some redundant checks in there. Are you sure *pdwDataType is not set in the BUFFERTOOSMALL case? I mentioned pdwDataType in the last feedback already, please take a bit more care and check if some things I point out apply in a similar way to other places, and re-read the feedback you get after you think you have implemented all the changes to see if there's anything you missed. > + case DPNA_DATATYPE_DWORD: > + *(DWORD*)pvBuffer = entry->data.value ; The extra space in front of the semicolon looks weird. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, 100, NULL, NULL, NULL, &bufflen, &type); > - todo_wine ok(hr == E_POINTER, "got 0x%08x\n", hr); > + ok(hr == DPNERR_INVALIDPOINTER, "got 0x%08x\n", hr); In the code you return E_POINTER. DPNERR_INVALIDPOINTER is defined as E_POINTER, but please try to be consistent. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, i, NULL, &namelen, NULL, &bufflen, &type); > - todo_wine ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(namelen > 0, "namelen length is 0\n"); > + ok(bufflen > 0, "bufflen length is 0\n"); Please check the exact length, not just > 0. Please also check the name string, and the string and lengths in the success case (e.g. if you pass a length > than the necessary size does dpnet change the size?). Also, as pointed out above -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVN25ZAAoJEN0/YqbEcdMwf1cP/jXMXUuyMNzg5JAVG6YMMKgJ yIac4X5zxnmcPrJMjMRKIr2xU3u6ZDki/Kk5/GulDCCd4NQGlDJP0QY9WuuZ9eIN YiAipjXLpO4DPVi6eTRlDIbfCSDfpNJnjSWdDGbjpF/dpUkJOOZzwWvkJKZr598O kZohPT1kwTs12sU3yQyT8N3NGQer+AaWHcfohMW5f0UeZ+whviwjg3CGavrR65mH Q2fWn92mgw8KPTu+zvJ5oBbWQLf24o+lBp/vQ6zeOIA2lxXVLoMfg5q8QRWvKge9 IiPIG8BEOfrTXXSEZSUauif97fdq23JGQJOOGYUyZ+YLg/4Pqj2nWZBOmFM+3gVy E5FgFPT4EdE1vpyn7cnWGufzNtnctTZGOJ4F7AKxdMoBPqXxDEgdjmMFqN0yeTH8 Pm6NGVJP7uR8+wqXApHoGN2S7ceZLuEhMhdGYHbFakx9McPzCEayWMGQ/CIlbjHt YRB5aaxOAk896Fmb+PMuv3G9d4+y4409iLB+/Jrda20VOFfAp1qzNa33R9rhWXN7 sSdCale2KKYwStnzSWAcH4Mn7L+i1B/Dl7Md83HqPumAPfwlSK8VZVeqF0ZVjLaR KlokPcmQnIuS/ia6gPdGVbmAHnpoIIn0CNtgstKBqXkvGUlasXsKhy2ofWkWoaiW lO+hrwausmSORbzMGVaW =fTwv -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)
by Marvin 22 Apr '15

22 Apr '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=12940 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: comctl32:TTM_SETTOOLINFO does not change subclassing
by Nikolay Sivov 21 Apr '15

21 Apr '15

On 21.04.2015 17:40, Aric Stewart wrote: > > Prevents crashes when a subclassed window is unsubclassed and then destroyed. > > As per information found at: > https://support.microsoft.com/en-us/kb/kbview/154122 > --- > dlls/comctl32/tooltips.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > We definitely need a test for that.

2 1

Re: [PATCH 5/5] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin 21 Apr '15

21 Apr '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=12921 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2488: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2490: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2496: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2527: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2535: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2562: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2582: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2606: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2633: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2650: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2687: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2698: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2725: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2745: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2762: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2789: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2806: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2844: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}.

1 0

Re: [PATCH 4/5] ddraw/tests: Add more d3d7 lighting tests.
by Marvin 21 Apr '15

21 Apr '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=12920 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

1 0

Re: iexplore: Update version to 9.0.8112.16421.
by Nikolay Sivov 21 Apr '15

21 Apr '15

On 21.04.2015 12:19, Hans Leidekker wrote: > --- > programs/iexplore/iexplore.inf | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Maybe ieframe/mshtml versions should be updated as well?

2 1

Re: [2/2] server: GetQueueStatus should clear only checked queue changed bits.
by Marvin 21 Apr '15

21 Apr '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=12902 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00080150 msg.c:12252: Test failed: bad time 30c10/30c20

1 0

Re: [1/2] user32/tests: Add PeekMessage(PM_NOREMOVE) call to inter-thread messages test.
by Marvin 21 Apr '15

21 Apr '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=12901 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10471: Test failed: expected PeekMessage to return FALSE, got 1 === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30fa9/30fb8

1 0

Re: (resend)server: Do not replace focus and active windows with NULL on thread_attach_input
by Marvin 20 Apr '15

20 Apr '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=12890 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00080150 msg.c:12252: Test failed: bad time 30f1c/30f2c

1 0

Re: server: Do not replace focus and active windows with NULL on thread_attach_input
by Marvin 20 Apr '15

20 Apr '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=12889 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013E msg.c:12252: Test failed: bad time 3200d/3201d

1 0

Re: user32/tests: Add a test for sending inter-thread messages.
by Marvin 20 Apr '15

20 Apr '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=12880 Your paranoid android. === w7u (32 bit msg) === msg.c:6957: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x0014 instead msg.c:6957: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0082 instead msg.c:6957: Test failed: destroy child on thread exit: 2: the msg 0x0014 was expected, but got msg 0x000f instead msg.c:6957: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 0014 msg.c:12230: Test failed: unexpected hwnd 00060150 msg.c:12252: Test failed: bad time 31cc3/31cd2

1 0

GSoC 2015 Application
by lijianwei 20 Apr '15

20 Apr '15

Hi I'm a graduate student in NorthWestern Polytenical University.I have been study Parelism promraming,especially GPU programming for two year.So I want to accept task Implement OpenMP. But now,what should I do to begin my work. Watting for your answer! Than you! Best Regard

2 1

License of AppDb content and sql dump?
by Sebastian Lackner 20 Apr '15

20 Apr '15

Hiho, I've been wondering if there is any license information available for the appdb content. I've looked through lots of pages but didn't find any hint under which terms the data can be used. It would be nice if someone could clarify this situation a bit. For those who are wondering why I'm asking - I am planning to use the (anonymized) data (especially app names, categories and corresponding ratings) for further analysis and comparison between different Wine versions. There will of course be references to show where the data is from. Since the data is used in connection with the Wine project I would assume that it should be normally safe to do that - if anyone sees any legal issues please contact me. ;) Best regards, Sebastian

1 0

Re: [PATCH] urlmon: set hres also in else branch (Coverity)
by Nikolay Sivov 19 Apr '15

19 Apr '15

On 19.04.2015 14:42, Marcus Meissner wrote: > 718705 Unchecked return value > --- > dlls/urlmon/session.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/urlmon/session.c b/dlls/urlmon/session.c > index e01e647..001158f 100644 > --- a/dlls/urlmon/session.c > +++ b/dlls/urlmon/session.c > @@ -213,7 +213,7 @@ IInternetProtocolInfo *get_protocol_info(LPCWSTR url) > > hres = IClassFactory_QueryInterface(cf, &IID_IInternetProtocolInfo, (void**)&ret); > if(FAILED(hres)) > - IClassFactory_CreateInstance(cf, NULL, &IID_IInternetProtocolInfo, (void**)&ret); > + hres = IClassFactory_CreateInstance(cf, NULL, &IID_IInternetProtocolInfo, (void**)&ret); > IClassFactory_Release(cf); > > return ret; > It's still unchecked. If we want to use it we need to propagate return code to caller, right now it will return NULL interface pointer. So I'm thinking it's false positive.

2 1

Application for GSoC 2015 - Implement findstr.exe for Wine.
by KaiPeng Zeng 19 Apr '15

19 Apr '15

Hi folks, I’m Kaipeng Zeng who is a Linux user and Wine/CrossOver user from China. I am major in Biomedical Engineering in Guangdong Pharmaceutical University. I’d like to apply GSoC to work for Wine Project this year. My proposal is "Implementing findstr.exe for Wine". Though findstr is a quite independent program in Wine, I think it is valuable to implement. As far as I knew, there are some bugs about findstr in Bugzilla[1]. Any other programs in Chinese depend on it too. The implementation of findstr will help these programs and all the programs will also be good tests for our implementation. Besides, I think the code of grep will be helpful for implementing findstr. There are three parts in my plan: === Part 1: Add more tests for findstr.exe === I have submitted a patch for findstr’s test to wine-patches[2]. I will add more tests to prepare for the implementation. === Part 2: Implement an initial findstr.exe === With enough tests, I will try to implement the findstr gradually. My middle goal is having an initial implementation of findstr which can handle some simple work. Bug 35254[3] may be fixed after this part is finished. === Part 3: Add more parameters implementation === In this part, I will add more tests and try to implement more arguments for findstr, let it solve more things. [1] https://bugs.winehq.org/buglist.cgi?quicksearch=findstr&list_id=178519 [2] http://source.winehq.org/patches/data/110182 [3] https://bugs.winehq.org/show_bug.cgi

1 2

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v2).
by Ken Thomases 17 Apr '15

17 Apr '15

On Apr 17, 2015, at 4:09 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 2: Also update macdrv_displays_changed. Supersedes 110793. Looks OK to me. -Ken

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings (v2).
by Marvin 17 Apr '15

17 Apr '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=12849 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2493: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2506: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings.
by Ken Thomases 17 Apr '15

17 Apr '15

Sorry for the double post. Sent by accident before I was finished. This hoists some of the knock-on effects of WM_MACDRV_UPDATE_DESKTOP_RECT to the place where it is sent. However, it only does so for one of the two places where it is sent. It is also sent in macdrv_displays_changed() which is called when something external to the process (may have) changed the display configuration. You would need to duplicate the hoisted code to that function, too, or find some other way to make sure the same work gets done. -Ken On Apr 16, 2015, at 5:18 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Same as the previous patch, just for winemac.drv. > > The message ping-pong between the ChangeDisplaySettings calling thread > and the desktop thread is more complicated here than in winex11. The > problem again is that sendMessageTimeout(SMTO_BLOCK) will not process > messages sent by the desktop, leading to a deadlock. Replacing > SendMessageTimeout in the desktop with PostMessage is not an option > either because then messages will be executed in a different order in > the thread that called ChangeDisplaySettings. > > This patch will lead to DISPLAYCHANGE messages being sent on redundant > changes. This matches the behavior of winex11 and happens to fix the > user32/sysparam.ok test, but it fixes it for the wrong reason (the real > problem afaics is that OSX only supports 32 bpp, so no change takes > place although one was requested). I think redundant changes should be > intercepted in user32 before the display driver is called. > --- > dlls/winemac.drv/display.c | 8 ++++++-- > dlls/winemac.drv/window.c | 4 ---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/winemac.drv/display.c b/dlls/winemac.drv/display.c > index 10ecf67..f7ce163 100644 > --- a/dlls/winemac.drv/display.c > +++ b/dlls/winemac.drv/display.c > @@ -564,8 +564,12 @@ better: > size_t width = CGDisplayModeGetWidth(best_display_mode); > size_t height = CGDisplayModeGetHeight(best_display_mode); > > - SendMessageW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > - MAKELPARAM(width, height)); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > + SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > + SendMessageTimeoutW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK, ~0U, NULL); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > ret = DISP_CHANGE_SUCCESSFUL; > } > else > diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c > index 7a777e6..fa12af5 100644 > --- a/dlls/winemac.drv/window.c > +++ b/dlls/winemac.drv/window.c > @@ -1666,13 +1666,9 @@ LRESULT CDECL macdrv_WindowMessage(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) > if (!GetWindowRect(hwnd, &current_desktop_rect) || > !CGRectEqualToRect(cgrect_from_rect(current_desktop_rect), new_desktop_rect)) > { > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > - SMTO_ABORTIFHUNG, 2000, NULL); > SetWindowPos(hwnd, 0, CGRectGetMinX(new_desktop_rect), CGRectGetMinY(new_desktop_rect), > CGRectGetWidth(new_desktop_rect), CGRectGetHeight(new_desktop_rect), > SWP_NOZORDER | SWP_NOACTIVATE | SWP_DEFERERASE); > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, wp, lp, > - SMTO_ABORTIFHUNG, 2000, NULL); > } > } > return 0; > -- > 2.3.4 > > >

2 1

Re: [PATCH] winex11: Don't pump messages in ChangeDisplaySettings (v2).
by Marvin 17 Apr '15

17 Apr '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=12824 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2493: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2506: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

2 1

Re: [PATCH 1/2] ntdll/tests: Add test for FileFsFullSizeInformation(try 2)
by Marvin 17 Apr '15

17 Apr '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=12844 Your paranoid android. === w8 (32 bit file) === file.c:407: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

WineConf 2015
by Michael Stefaniuc 17 Apr '15

17 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello guys, after we rethought WineConf and did it at/during FOSDEM for the last two years, it is time for a real WineConf again. We are missing too much our keynote, our governance discussions as well as our hackatons. Also the two full days should give more time for the most important topic aka the hallway discussions. After two years in Europe the old tradition would call for a session over in USA/Canada but this is not a strict requirement. Now the most important thing is to find volunteers that would want to host the WineConf. They have the bigger say in the date too, there are two options: - - either in late spring (preferred by me), - - or early fall (preferred by Jeremy) I have started also http://wiki.winehq.org/WineConf2015 please feel free to add agenda topics to it. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTY5awACgkQ0ei8kcpE1VG2YQCguwUys0se+wV96lPfjZ+Qi6LJ 8ooAoJDxist2eZLgMXsRqUZVloGpBRgz =7Ta5 -----END PGP SIGNATURE-----

6 12

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings.
by Ken Thomases 16 Apr '15

16 Apr '15

This hoists some of the knock-on effects of WM_MACDRV_UPDATE_DESKTOP_RECT to the place where it is sent. However, it only does so for one of the two places where it is sent. It is also sent in macdrv_displays_changed() On Apr 16, 2015, at 5:18 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Same as the previous patch, just for winemac.drv. > > The message ping-pong between the ChangeDisplaySettings calling thread > and the desktop thread is more complicated here than in winex11. The > problem again is that sendMessageTimeout(SMTO_BLOCK) will not process > messages sent by the desktop, leading to a deadlock. Replacing > SendMessageTimeout in the desktop with PostMessage is not an option > either because then messages will be executed in a different order in > the thread that called ChangeDisplaySettings. > > This patch will lead to DISPLAYCHANGE messages being sent on redundant > changes. This matches the behavior of winex11 and happens to fix the > user32/sysparam.ok test, but it fixes it for the wrong reason (the real > problem afaics is that OSX only supports 32 bpp, so no change takes > place although one was requested). I think redundant changes should be > intercepted in user32 before the display driver is called. > --- > dlls/winemac.drv/display.c | 8 ++++++-- > dlls/winemac.drv/window.c | 4 ---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/winemac.drv/display.c b/dlls/winemac.drv/display.c > index 10ecf67..f7ce163 100644 > --- a/dlls/winemac.drv/display.c > +++ b/dlls/winemac.drv/display.c > @@ -564,8 +564,12 @@ better: > size_t width = CGDisplayModeGetWidth(best_display_mode); > size_t height = CGDisplayModeGetHeight(best_display_mode); > > - SendMessageW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > - MAKELPARAM(width, height)); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > + SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > + SendMessageTimeoutW(GetDesktopWindow(), WM_MACDRV_UPDATE_DESKTOP_RECT, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK, ~0U, NULL); > + SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, mode_bpp, > + MAKELPARAM(width, height), SMTO_BLOCK | SMTO_ABORTIFHUNG, 2000, NULL); > ret = DISP_CHANGE_SUCCESSFUL; > } > else > diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c > index 7a777e6..fa12af5 100644 > --- a/dlls/winemac.drv/window.c > +++ b/dlls/winemac.drv/window.c > @@ -1666,13 +1666,9 @@ LRESULT CDECL macdrv_WindowMessage(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) > if (!GetWindowRect(hwnd, &current_desktop_rect) || > !CGRectEqualToRect(cgrect_from_rect(current_desktop_rect), new_desktop_rect)) > { > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_RESET_DEVICE_METRICS, 0, 0, > - SMTO_ABORTIFHUNG, 2000, NULL); > SetWindowPos(hwnd, 0, CGRectGetMinX(new_desktop_rect), CGRectGetMinY(new_desktop_rect), > CGRectGetWidth(new_desktop_rect), CGRectGetHeight(new_desktop_rect), > SWP_NOZORDER | SWP_NOACTIVATE | SWP_DEFERERASE); > - SendMessageTimeoutW(HWND_BROADCAST, WM_MACDRV_DISPLAYCHANGE, wp, lp, > - SMTO_ABORTIFHUNG, 2000, NULL); > } > } > return 0; > -- > 2.3.4 > > >

1 0

Re: [PATCH 1/2] d3drm/tests: Make get_refcount return ULONG instead of int.
by Stefan Dösinger 16 Apr '15

16 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 These patches look good to me. On 04/13/15 18:59, Aaryaman Vasishta wrote: > --- dlls/d3drm/tests/d3drm.c | 2 +- 1 file changed, 1 insertion(+), > 1 deletion(-) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 2f154f9..f089707 100644 --- a/dlls/d3drm/tests/d3drm.c +++ > b/dlls/d3drm/tests/d3drm.c @@ -33,7 +33,7 @@ ok(count == rc_new, > "Invalid refcount. Expected %d got %d\n", rc_new, count); \ } > > -static int get_refcount(IUnknown *object) +static ULONG > get_refcount(IUnknown *object) { IUnknown_AddRef( object ); return > IUnknown_Release( object ); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVL81eAAoJEN0/YqbEcdMwrRYP/j37mA7B6bg9RveFxAYQS8VX AVROgmPd+hZDl/JKKnSMrUgHU3Y6MtCGwKd6Pb42yRhpU8qw/j6dPW1QqUYSII0V MpqpON1tY6WRV8M2eCBJ5+qLBwzFDxi51a4ta+7BUbK6Jl9IJw58OdyL5pt5WSID XneEmweh3BVI3ay4ZYn5jlK53BArCFu5yfclYPklL5uNb4sdA5zTJoavvwUHYMHc grjeEXAxRnBn8zmD13H5+s8GRC59Sx/vHJl6PTlv2A4bU22HwTku3b7/RbAGyYtB rB4Y+SRUeDn8e5YAe6+kWmwAOORdQFf1plmLx+bjIc13UYlnBTLnOjV8KMZm9vrC nhCcxUVeY3YYahA7q37nEOMZHVt++mX5pJ00vdV47QzZVAat05pA9tiesI3n5IAm DNrDRPV1olBT2OIz20Xo0YvtdBnvkOQDKB+SfYtD8YnGGNw/WZKUEwBh5IpNtvbE iZ/d3AMB1h4A1trWofNR17nZJbTwQwTmIKI6ggw2Cr6DpPb6SFp6odoA4OjajGGB e+sqBTaf5yf2QbDzjn694f4PKAeTZwnkXXzR9Quu2J1Zu4dZFSWFvnFnq5ZMgTqq P1RrnGJJdx9p1JytzRhi9M9vnIr4UUGMNfOOGuw/qvnCyYHXM67ka9leXs82ruK3 aZbHB7YZDSthklM3u+RX =r66h -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings.
by Marvin 16 Apr '15

16 Apr '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=12822 Your paranoid android. === wxppro (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2003std (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === wvistau64 (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2008s64 (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w7u (32 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w8 (32 bit sysparams) === sysparams.c:2493: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2506: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === wvistau64 (64 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out === w2008s64 (64 bit sysparams) === sysparams.c:2958: Test failed: ChangeDisplaySettingsEx failed, -1 sysparams.c:2961: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out

1 0

Re: [PATCH 3 / 2] d3d9: Add support for d3d9ex formats
by Sergey Isakov 16 Apr '15

16 Apr '15

Ignore, please, this is included in previous patch. Sorry! On 16.04.2015, at 12:47, Sergey Isakov wrote: > just forget two lines in previous commit > <patch-d3d9ex-d3d9-device.txt>

1 0

Re: [PATCH 1 / 2] d3d9: Add support for D3D9ex new formats
by Stefan Dösinger 16 Apr '15

16 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Do you know a game that needs these formats? Is there a d3d9 game that actually locks the depth buffer? Do Windows drivers support these formats? Am 2015-04-16 um 09:37 schrieb Sergey Isakov: > + case WINED3DFMT_D32_LOCKABLE: return D3DFMT_D32_LOCKABLE; > + case WINED3DFMT_S8_LOCKABLE: return D3DFMT_S8_LOCKABLE; WINED3DFMT_D32_LOCKABLE doesn't exist yet. Your patches are in the wrong order. > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index 174fc13..6934528 100644 > --- a/dlls/d3d9/tests/device.c > +++ b/dlls/d3d9/tests/device.c > @@ -2199,6 +2199,8 @@ static void test_display_modes(void) > TEST_FMT(D3DFMT_R8G8_B8G8, D3DERR_INVALIDCALL); > > TEST_FMT(D3DFMT_D16_LOCKABLE, D3DERR_INVALIDCALL); > + TEST_FMT(D3DFMT_D32_LOCKABLE, D3DERR_INVALIDCALL); > + TEST_FMT(D3DFMT_S8_LOCKABLE, D3DERR_INVALIDCALL); Please add a test that actually uses the format and locks them. It's ok if parts of the test (those that depend on depth transfers to / from system memory) are marked todo since wined3d doesn't handle depth locking at all. > + /* d3d9ex formats */ > + /* Z-Stencil formats valid for CPU access */ > + D3DFMT_D32_LOCKABLE = 84, The second comment is misaligned and I don't think these comments add much information. > + // s10e5 formats (16-bits per channel) This is an unrelated change. C++ comments ("//") are not allowed in Wine as our sources are plain C. > + // Monochrome 1 bit per pixel format > + D3DFMT_A1 = 118, > + // 2.8 biased fixed point > + D3DFMT_A2B10G10R10_XR_BIAS = 119, > + // Binary format indicating that the data has no inherent type > + D3DFMT_BINARYBUFFER = 199, Adding those is OK, but should be in a separate patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVL4cnAAoJEN0/YqbEcdMw6eMP/2b06nt5c3E9Stwm52T7l3aZ ytyrBcrqT7lE2XHVEhFH6te/NSgUXO5KYPqkgZQfx+/YvmnnevXeA1jfIMh5wOoD trBXmIDbhtgt1ABXmOB6CmN710B3zLBwnxMj4rUfiZAHgW4T6aONKxy4VmNGNxnl i5QxgMBOJbsAocu5URUpeiyGd87f3YWD1mTcrtAjwgTSNyF33VAx7O0zcV7Iui9e NY5fzYG7ff19zcPKRDIuOO0/ga93yYh6OcesiyUon+CHh+PxCcnztdXuNA6uIf2X N+OOudRbWrgnrpGbhudraRgoQOXIl+Sg1chX97qmPdtgz8Ftgf98yBWMld+QKllW fbTa8mIyiZBdO+0hTRYeiSMdDH0q4PnBbetvPW1lLRHVIlNqbL67yi4q9F+nvRoz jv5ueaz8S4iflG57ZVBVjmBok4QMxoX34J1V3M/qahsWhK1+hFVKXM7cJn9j0hNW H6GS/HdNA35yqwNJyKQdj3i2P1ptom39vLqHLlPCmX9okjiTSXfrtDsJBZdsHNC3 GP9uJWZnhE61rTmlwQ1vpdxZvVUp8whIgsgu9GWX7KaDXa3kYSf58sjE5aEAuKhh 4thc8OElq1BzRPHRIZNbyUoqZ6qHELYt88UNMA74obHun69UOeyvN2MIKn8wvTDh wIttvErryrAqz5+mFjKK =r5/p -----END PGP SIGNATURE-----

1 0

Re: Andrew Eikum : winecfg: Use a listview for speaker configuration.
by Bruno Jesus 15 Apr '15

15 Apr '15

On Wed, Apr 15, 2015 at 10:43 AM, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: e17f4fd2f814a2a651c229ead4f86ab25130fe06 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e17f4fd2f814a2a651c229ead… > > Author: Andrew Eikum <aeikum(a)codeweavers.com> > Date: Tue Apr 14 14:01:46 2015 -0500 > > winecfg: Use a listview for speaker configuration. This is much better, thanks Andrew.

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 8)
by Stefan Dösinger 15 Apr '15

15 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are a few issues with this. They seem vaguely familiar to me, I think I have raised them before but they got lost in the list to array conversion: On 04/15/15 12:07, Alistair Leslie-Hughes wrote: > @@ -405,9 +405,48 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { I assume you're supposed to write the name to pwszName if it is non-NULL, and check *pdwNameLen against the string length first. > + entry = This->components[dwComponentID]; > + > + if(*pdwBufferSize < entry->size) > + { > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } It seems to me that it should assign *pdwDataType and *pdwNameLen in this case. The test should be extended to explicitly check the assigned lengths. Your code never sets *pdwNameLen, and it sets *pdwDataType only if the buffer is big enough. The concern about assigning *pdwDataType in the buffer to small case also applies to GetComponentByName. > + switch (entry->type) > + { > + case DPNA_DATATYPE_DWORD: > + memcpy(pvBuffer, &entry->data.value, sizeof(DWORD)); > + break; > + case DPNA_DATATYPE_GUID: > + memcpy(pvBuffer, &entry->data.guid, sizeof(GUID)); > + break; Assignments should be enough in these cases. The same applies to the existing GetComponentByName code. A semi-related problem in the existing GetComponentByName code: > if(!pwszName || !pdwBufferSize || !pdwDataType || (!pvBuffer && pdwBufferSize)) > return E_POINTER; The second check for pdwBufferSize is redundant, you already established it is not NULL. I assume that's supposed to be *pdwBufferSize. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVLj+3AAoJEN0/YqbEcdMws+UP/0q9wkiDyPPLi5+tbp8NXPKZ NItf38ksjFeForuNvmRt/Q0MAvQeJ0CSpqoyk3nH9G0EvcNQPXEpBHBCiL7aqUVU HN0OWc07OANPPrvAVqNRAVVaaAr1v9NFd+CJFNqNf7d0uOj0D1GMJtvJw+1ia06P qFfAUIIRSf1ay4RocO2HyAsaYwtps15Pib067jBJT/iVriMJQuflB9WRBy6BmKrR DM0PzySi3+quFjl+tYKUitUeR4RgGsMXUSx8V3l03929Y1duRO0uSfzAs18Mquqh wovE36jJfYhpBhJa7oAI9CVkNvr/EBMSVzHtBOGWM6mewMI3CGrfn+ZLxjOe1kk3 pIFXfIlbBBTZJYusL8fOxL0itacE2+YB5Opzi2K6TyNfnqWHscR5g7q+JH6iIe4k /JepaI2mqPsD2RgvM7SKBH2s6qz+cfd7uHWiW+QzzVEqIixbb3eJm1raR9p2UMAb +aJ9XPYpIeRzy8+BxCXLWhd5GQIFOSlUisQwxbwM9a/d9URFgcLS2KDX3ZjPPBcL hTOCS3jDiIfjf5lTpl1wj/rb+9zmK0JkpFyf6/EbxZEThP/fNuwSHtIYaY/4UO97 H9bpWYI5x1N7VnXaAFhCy9uwMeJ05ZYj0AhVl70S4Q1pHsFSX5XWumTOpfxXtJhH WRMpPPalUDabz3fPcAgG =rxp6 -----END PGP SIGNATURE-----

1 0

Re: msvcrt: improve accuracy of exp/pow/cosh and sinh
by Ruslan Kabatsayev 14 Apr '15

14 Apr '15

Hi, Are you sure this will be of any use if one selects SSE instead of x87 instruction set to handle doubles (like -mfpmath=sse)? No one guarantees the functions like sinh will be evaluated on x87 FPU and even that this legacy instruction set will used at all. Regards, Ruslan On Sat, Apr 4, 2015 at 7:40 PM, Zheng Chen <chanchengcc(a)gmail.com> wrote: > The default fpu_cw = 0x27f makes the exp/pow/cosh/sinh functions producing > less accurate results. This patch temporally changes fpu_cw to 0x37f in > these functions for more accurate results. > > Thanks to Qian for his ideas. > > This patch fixes parts of these two bugs: 37149, 37150 > > >

2 1

i3, i5, i7 benchmarks building wine-1.6.2
by Dan Kegel 14 Apr '15

14 Apr '15

Hi folks, in case anyone's wondering how fast a cheap computer builds wine these days, I did a little benchmark on the family computers. The benchmark was: $ sudo apt-get build-dep wine $ apt-get source wine $ cd wine1.6-1.6.2/ $ time debuild -b -uc -us $ dh clean $ time debuild -b -uc -us -j4 Results: Vintage CPU Ubuntu Time -j1 Time -j4 Details (model, barebones price) 2015 i3-4130 15.04b2 23m31s 12m16s http://kegel.com/new-computer-2015.html (ts140, $250, no drive) 2014 i5-4460 14.04 21m25s 8m12s http://kegel.com/new-computer-2014.html (h530, $426 including 1TB drive) 2010 i7-920 14.10 35m47s 13m44s http://kegel.com/new-computer-2010.html (ASRock x58 Extreme, $800, no drive) I'll probably semi-retire the ol' i7 and replace it with another ts140 soon, partly to save power, and partly to beef up my LAN party capabilities :-) (My new house has been averaging 22 kwh/day lately; switching from the i7 to the i3 will save something like 0.5 kwh/day on days when I work at home. Hope to add solar panels and go carbon-neutral sometime, but gotta fix the chimneys, replace furnaces with heat pumps, insulate, and replace the roof first.) - Dan

1 0

Re: dsound: Fix conning formula to correctly interpolate volume.
by Andrew Eikum 13 Apr '15

13 Apr '15

On Sat, Apr 11, 2015 at 03:44:14PM +0000, Igor Kotrasinski wrote: > > Original formula is obviously wrong (plug in a large flAngle and a small cone difference). This one does correct linear interpolation. Makes sense to me. Thanks! Andrew

1 0

Re: [PATCH] dsound: Stricter validation for formats in secondary buffers
by Marvin 13 Apr '15

13 Apr '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=12777 Your paranoid android. === wxppro (32 bit dsound) === dsound.c:1401: Test failed: secondary: SetFormat: 88780032 === w2003std (32 bit dsound) === dsound.c:1401: Test failed: secondary: SetFormat: 88780032

1 0

Re: [PATCH] shell32: Add more knownfolders
by Marvin 13 Apr '15

13 Apr '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=12776 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: winejoystick.dev: Add Graphics Driver connection for winejoystick.drv
by Charles Davis 13 Apr '15

13 Apr '15

I do not agree with this particular direction. You do realize that some people on Mac OS still use the X11 driver (e.g. to get virtual desktop support), right? With these patches, these people suddenly won’t have any joystick support at all. Don’t get me wrong, I still think putting all the joystick code in one place is the right thing to do. I just don’t think that one place should be the graphics driver. Chip

5 7

Re: mshtml: Remove nsIDOMWindowUtils::SetCriticalDisplayPortForElement.
by Alexandre Julliard 13 Apr '15

13 Apr '15

Thomas Faber <thomas.faber(a)reactos.org> writes: > This function is no longer present in Wine Gecko, so this re-aligns > the vtable. > > See https://www.winehq.org/pipermail/wine-devel/2015-April/107319.html It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so activex && touch activex.ok activex.c:1320: Test failed: unexpected call InPlaceDeactivate activex.c:1066: Test failed: unexpected call Close activex.c:1041: Test failed: unexpected call SetClientSite_NULL activex.c:1761: Test failed: OnUIActivate failed: 8000ffff activex.c:1716: Test failed: GetContainer failed: 8000ffff activex.c:1717: Test failed: container == NULL wine: Unhandled page fault on read access to 0x00000000 at address 0x7ecb5066 (thread 003a), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wininet: Avoid four instances of "logical not is only applied to the to the left hand side".
by Henri Verbeet 13 Apr '15

13 Apr '15

On 12 April 2015 at 23:04, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Indrek suggested that in this specific case the alternate approach > below also should work, so let me provide this as an option in case It probably would, but note that that doesn't do quite the same thing. BOOL values aren't restricted to TRUE/FALSE, so in principle there's no reason "ret" couldn't be e.g. ~0u. You'd need something like "!ret != !ie10_cache" to preserve the original behaviour, but I'm not sure that's really much better.

2 2

Re: winecfg: add all Windows versions and accompanying error message (try 3)
by Andrew Eikum 12 Apr '15

12 Apr '15

On Thu, Apr 09, 2015 at 05:42:36PM -0700, Jason Overland wrote: > @@ -399,9 +401,49 @@ static void on_remove_app_click(HWND dialog) > SendMessageW(GetParent(dialog), PSM_CHANGED, (WPARAM) dialog, 0); > } > > +static INT_PTR WINAPI win_ver_error_dlg_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) This function should be guarded by an #ifdef. On my 32-bit build, I get: appdefaults.c:404:90: warning: ‘win_ver_error_dlg_proc’ defined but not used [-Wunused-function] > @@ -159,6 +159,22 @@ BEGIN > COMBOBOX IDC_WINVER,100,194,145,56,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP > END > > +IDD_WINVERERROR DIALOGEX 100, 100, 238, 95 > +STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU > +CAPTION "Error: Invalid selection" > +FONT 8, "MS Shell Dlg" > +BEGIN > + LTEXT "This Wine prefix is built to support 64 bit applications. \ > + Because the Windows version you selected does not support 64 bit applications, \ > + this prefix cannot be configured to mimic that version of Windows.", > + IDC_STATIC,5,5,220,40 > + CONTROL "Please refer to \"How do I create a 32 bit wineprefix on a 64 bit system?\" \ > + in the \"Using Wine\" section of the <a href=\"http://wiki.winehq.org/FAQ\">Wine FAQ</a> \ > + for instructions on how to create a 32 bit Wine prefix.", > + IDC_WIN_VER_TEXT,"SysLink",0,5,40,220,70 For some reason, this renders without a space between "the" and the "Wine FAQ" link. Also half of the last 'x' and the period are cut off. It could be an issue on my system. I'm not very familiar with how RC files work. Other than those issues, it seems to work as intended. Andrew

3 2

Re: wined3d: Load ModelView matrix for glLightfv calls.
by Matteo Bruni 11 Apr '15

11 Apr '15

2015-04-11 17:16 GMT+02:00 Joachim Priesner <joachim.priesner(a)web.de>: > Analogous to the light() function in state.c, the correct ModelView matrix > has to be loaded when glLightfv is called. The code to load/restore the > matrix is copied from there. > --- > dlls/wined3d/glsl_shader.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 1a1b6b0..2422982 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -7208,6 +7208,11 @@ void glsl_vertex_pipe_view(struct wined3d_context *context, const struct wined3d > > context->constant_update_mask |= WINED3D_SHADER_CONST_FFP_MODELVIEW; > > + /* Light settings are affected by the ModelView transform in OpenGL, the View transform in Direct3D. */ > + gl_info->gl_ops.gl.p_glMatrixMode(GL_MODELVIEW); > + gl_info->gl_ops.gl.p_glPushMatrix(); > + gl_info->gl_ops.gl.p_glLoadMatrixf(&state->transforms[WINED3D_TS_VIEW]._11); > + > for (k = 0; k < gl_info->limits.lights; ++k) > { > if (!(light = state->lights[k])) > @@ -7218,6 +7223,8 @@ void glsl_vertex_pipe_view(struct wined3d_context *context, const struct wined3d > checkGLcall("glLightfv dirn"); > } > > + gl_info->gl_ops.gl.p_glPopMatrix(); > + > for (k = 0; k < gl_info->limits.clipplanes; ++k) > { > if (!isStateDirty(context, STATE_CLIPPLANE(k))) > -- > 1.8.4.5 AFAICS this patch is correct. Thank you Joachim!

1 0

Re: rpcrt4/tests: Fix a minor leak (Valgrind)
by Marvin 11 Apr '15

11 Apr '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=12764 Your paranoid android. === wvistau64 (64 bit ndr_marshall) === No test summary line found === w2008s64 (64 bit ndr_marshall) === No test summary line found

1 0

Re: [1/1] dwrite: case insensitive font search
by Nikolay Sivov 11 Apr '15

11 Apr '15

On 04/10/2015 10:20 PM, Julius Schwartzenberg wrote: > Running the tests on MS Windows, it turns out that Nikolay Sivov was > correct that it should just be a case insensitive search: > https://www.winehq.org/pipermail/wine-devel/2015-April/107309.html > This allows Samsung Smart View 2.0 to get further with starting up. Hi, Julius. This looks good enough, except subject line needs to be improved a bit to follow a pattern we usually use, something like 'dwrite: Font family lookup should be case-insensitive', but that's not critical at all. Thanks for tracking this down.

1 0

Re: [PATCH 8/9] wined3d: Handle color key dirtification in wined3d_cs_exec_set_texture.
by Henri Verbeet 10 Apr '15

10 Apr '15

On 9 April 2015 at 22:48, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index eb5c3b0..a888552 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1068,7 +1068,10 @@ DWORD get_flexible_vertex_size(DWORD d3dvtVertexType) DECLSPEC_HIDDEN; > #define STATE_POINT_SIZE_ENABLE (STATE_FRAMEBUFFER + 1) > #define STATE_IS_POINT_SIZE_ENABLE(a) ((a) == STATE_POINT_SIZE_ENABLE) > > -#define STATE_HIGHEST (STATE_POINT_SIZE_ENABLE) > +#define STATE_COLOR_KEY (STATE_POINT_SIZE_ENABLE + 1) You should handle this in debug_d3dstate() and validate_state_table() as well.

1 0

[RFC] mshtml: Remove nsIDOMWindowUtils::SetCriticalDisplayPortForElement.
by Thomas Faber 10 Apr '15

10 Apr '15

Hey Jacek, I just got an MSVC /RTCs stack pointer mismatch error after this call in mshtml's CustomDoc_Release: nsIDOMWindowUtils_CycleCollect(window_utils, NULL, 0); After some investigation I found that the vtable for this class was off by one element. The culprit seems to be SetCriticalDisplayPortForElement. The function got removed here in Gecko: http://sourceforge.net/p/wine/wine-gecko/ci/ed28b621505812d584723bfb389983b… However the latest nsiface.idl in Wine still has it: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/mshtml/nsiface.idl#l… I did my testing on mshtml 1.7.37 with Wine Gecko 2.34 but it looks like this is still present in the latest code as well. Do you agree with my analysis (i.e. the attached patch) here, or do you think I'm missing something? Thanks! And thanks for maintaining Wine Gecko... this truly opened my eyes to the complexity of that task ;) -Thomas

2 1

Re: [PATCH 2/2] wined3d: Implement color keying in the glsl fragment pipeline (v2).
by Marvin 10 Apr '15

10 Apr '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=12746 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/9] wined3d: Implement color keying in arbfp_blit.
by Matteo Bruni 10 Apr '15

10 Apr '15

2015-04-09 22:48 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>: > This intentionally discards on the alpha value. To do a proper color > compare we have to migrate fixed function pipeline color keying and > blits at the same time because the color keying conversion changes the > texture contents and can cause the key not to match. > --- > dlls/wined3d/arb_program_shader.c | 68 +++++++++++++++++++++++++++++++++------ > dlls/wined3d/surface.c | 51 +++++++++++++++++++---------- > dlls/wined3d/swapchain.c | 2 +- > dlls/wined3d/wined3d_private.h | 7 ++-- > 4 files changed, 99 insertions(+), 29 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c > index 79439f5..f740123 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -7539,7 +7549,24 @@ static GLuint arbfp_gen_plain_shader(struct arbfp_blit_priv *priv, > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader)); > > shader_addline(&buffer, "!!ARBfp1.0\n"); > - shader_addline(&buffer, "TEX result.color, fragment.texcoord[0], texture[0], %s;\n", tex_target); > + > + if (type->use_color_key) > + { > + shader_addline(&buffer, "TEMP color;\n"); > + shader_addline(&buffer, "TEMP compare;\n"); > + shader_addline(&buffer, "PARAM color_key = program.local[%u];\n", ARBFP_BLIT_PARAM_COLOR_KEY); > + shader_addline(&buffer, "TEX color, fragment.texcoord[0], texture[0], %s;\n", tex_target); > + shader_addline(&buffer, "SGE compare.r, color.a, color_key.a;\n"); > + shader_addline(&buffer, "SGE compare.g, -color.a, color_key.a;\n"); > + shader_addline(&buffer, "MUL compare, compare.r, -compare.g;\n"); > + shader_addline(&buffer, "KIL compare;\n"); > + shader_addline(&buffer, "MOV result.color, color;\n"); If you're checking for an exact match, that doesn't look right. You probably want something like: ... SGE compare.r, color.a, color_key.a; SGE compare.g, -color.a, -color_key.a; MUL compare, compare.r, compare.g; ... I might have misunderstood the point of the shader though, if that's the case then ignore this.

2 1

Re: [PATCH 3/4] d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame{1-3}
by Stefan Dösinger 09 Apr '15

09 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-09 um 16:11 schrieb Aaryaman Vasishta: > +static void test_frame1_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame, &IID_IDirect3DRMFrame, tests, sizeof(tests) / sizeof(*tests)); > ... > +static void test_frame2_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame2, &IID_IDirect3DRMFrame2, tests, sizeof(tests) / sizeof(*tests)); > ... > +static void test_frame3_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame3, &IID_IDirect3DRMFrame3, tests, sizeof(tests) / sizeof(*tests)); With this it won't be possible to find out which test failed if something fails. Please use more informative names for the test_name parameter of test_qi, e.g. "frame1_qi", "frame2_qi" and "frame3_qi". It is a bit unfortunate that you have to duplicate the big structure 3 times. You could in theory share it between the different functions, but then you'd have to lie about which interface you pass to test_qi, and I am not sure if this is nicer. If you can't find a better solution keep it the way it currently is. @Alexandre: The reason why I want to test all interface versions is our experience with ddraw. It has plenty of interface-specific behaviors, some of them depend on which version is called, and some of them depend on which version was used to create the object. (see struct ddraw_surface::version, struct ddraw::version and struct d3d_device::version, as well as various thunks). For this particular test the relevant information is that all interfaces can be queried from all object versions and that there are no refcounting differences, which could be introduced by the presumably aggregated IDirect3DRMObject2 interface. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVJvBaAAoJEN0/YqbEcdMwXYEP/2k4k4qdiGA2sxdv0S6mTaZW RXEPGDY1BqtDyOlw9EzwK+EmQTnE6B4zC25AM55yFAQjaIs8UyAk/TN3b0K+H9xz ZJJIgqGe2x+yIrzKqT70lGqUltYMaENHEw3oh8GdkYnIIK97bG7Y7vK7VZKIDPlh vfxcwG990di77KyPTt3eI4w6BQp4SyyEUxNC5vCy213ML+sF9XjGV+WPkV0UStcX nNCLRcszExminklJgEj4h1S6qcxNVIwJks8vCrgRx9isJfmbK8g5GrAzod3iTSES K1ccZWxGFbXupiT8Je6K5Te6b2PlHZtBVVHb5ndeYQdZJmwZIrTFbE3LjX3o2Vyt m0DvbPzAzNNJO7jREtWVSDXmg2OIaxsaIlMpH+v7VU2csqLNQZCijJ9/q3hN2qLf rYIS7i2fAmWDUoE6uFDOs+VJKDx88OljZaBTV4VFAHYwfeiqr3KXVdYZ3lciViif gjfno0N20inhG/ydjmJOn+tMipj2p1iffHDMaIlXVFhxitTj2Kk/bYp5b65T5q0C dn99clpZKU8xKg8w1I6MQv03CvMla0Z5k5d01H6YCW0YDSHtSnxfXeykxN2PeCGZ wYkTxF/KeSXhg3tLkl7StD1aRJsa5lv98FnJmQA2UWDNlcPfHcvv0Dam8ZsRohEr pPvj1H5GMcaaDGhfCOiZ =Eore -----END PGP SIGNATURE-----

1 0

Re: [PATCH] shell32: Add more knownfolders
by Marvin 09 Apr '15

09 Apr '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=12738 Your paranoid android. === w2000pro (32 bit shellpath) === The test timed out

1 0

Re: TestBot job 11764 results: [1/5] comctl32: Move TaskDialogIndirect function and its test to separate files (try 3)
by Joachim Priesner 09 Apr '15

09 Apr '15

Hi all, this patch series (implementing a basic version of TaskDialog/TaskDialogIndirect) has vanished from the patches list without comment. I'd appreciate any hint on what I did wrong. Thanks Joachim Am Donnerstag, 26. Februar 2015 schrieb Marvin: > VM Status Number of test failures > build completed > w2000pro completed 0 > wxppro completed 0 > w2003std completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w7u completed 0 > w8 completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w2000pro completed 0 > wxppro completed 0 > w2003std completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w7u completed 0 > w8 completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > > === build (build) === > No build failures found > > === w2000pro (32 bit taskdialog) === > No test failures found > > === wxppro (32 bit taskdialog) === > No test failures found > > === w2003std (32 bit taskdialog) === > No test failures found > > === wvistau64 (32 bit taskdialog) === > No test failures found > > === w2008s64 (32 bit taskdialog) === > No test failures found > > === w7u (32 bit taskdialog) === > No test failures found > > === w8 (32 bit taskdialog) === > No test failures found > > === wvistau64 (64 bit taskdialog) === > No test failures found > > === w2008s64 (64 bit taskdialog) === > No test failures found > > === w2000pro (32 bit misc) === > No test failures found > > === wxppro (32 bit misc) === > No test failures found > > === w2003std (32 bit misc) === > No test failures found > > === wvistau64 (32 bit misc) === > No test failures found > > === w2008s64 (32 bit misc) === > No test failures found > > === w7u (32 bit misc) === > No test failures found > > === w8 (32 bit misc) === > No test failures found > > === wvistau64 (64 bit misc) === > No test failures found > > === w2008s64 (64 bit misc) === > No test failures found

2 1

Re: dpnet: Convert Address components to use a list
by Stefan Dösinger 09 Apr '15

09 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-08 um 09:10 schrieb Alistair Leslie-Hughes: > +{ > + if(This->comp_count == This->comp_array_size) > + { > + struct component **temp; > + > + temp = heap_realloc(This->components, sizeof(struct component *) * (This->comp_array_size*2) ); Style hint: You can use sizeof(*temp) here, that way the alloc code doesn't need to be changed when you change the type of temp. This is even more helpful when the declaration of the pointer is in a different file, like in the heap_alloc call that allocates client->components. > + if(This->components) > + { > + This->components[This->comp_count] = item; > + This->comp_count++; > + return TRUE; > + } Can this ever be NULL for a legitimate reason? Note that the heap_realloc call already assumes This->components is not NULL. > @@ -540,8 +596,8 @@ HRESULT DPNET_CreateDirectPlay8Address(IClassFactory *iface, IUnknown *pUnkOuter > > client->IDirectPlay8Address_iface.lpVtbl = &DirectPlay8Address_Vtbl; > client->ref = 1; > - > - list_init(&client->components); > + client->comp_array_size = 4; > + client->components = heap_alloc( sizeof(struct component *) * client->comp_array_size ); Please add error checking here. (The NULL check in add_component doesn't help if this fails. You'll just get a half-working address object where AddComponent always fails) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVJkU+AAoJEN0/YqbEcdMwYRYP/0Vzb0FQDV6xBWc66VFjECxa dSyWsm34yksURXd9H7ayT+cGHQiyfq9dP5MIEL3Lrf7Npiqy7b3DV2NYH1X3foL8 NZoU0R6BSq1XUkqcEWFnXRDIHWs8f0Q1kNyRcUfsuXO4c6vAQOde7CdRtMHuLEy5 DOZjnnSbfAjoKq9Xk3JGJOs1juceoNumojpYE6wtbwDM5Q3Z8DOAdDEvv9qCw9SU Gziuis+LLN2yFDb+cONIKApy/XS/zs2imFS4z/wlKAEu72aGib/64j/d7j48jIxl C7ojDWjWGQj1CDSF6Wn0X80TV5Xjgolgw3ndyPFvqResCk4+UMeoyPaBXLLmozcu VaNtd4sGVTTAe7ivfKVaZx1K0gR8mezsFXEZ2jBfZlTOGHIRiImQ84ORZvahWr7t HYh0ZdDddzNOEbJVAlvxMrB/HLL+ODAOZJaElN6QXyWPBYFIb5AH+VwXeBccahSM xg8xkZLQIPqgDyQaI4TPDCboU5VzptTtl3uKJSy4QX+gV23IFXT9AUnPrWLas+3J qW0pX1tljdTxrVqU3mGvvE3KnUsHyEvx4sBVNWOzEagnSv4TQiabNlkyPfQmJsiH WE/Lx2WTWV9ucLfsGmCNbx+Cu52hDNj1R93hqgpSgAvvUjFeGjxTy4SQFD17ig6M ZFkE66v0L53cG4lQASGw =FqJl -----END PGP SIGNATURE-----

1 0

Re: [1/2] ws2_32/tests: Add tests about retrieving the local address of an interface bound socket
by Marvin 09 Apr '15

09 Apr '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=12730 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

dwrite font family issue
by Julius Schwartzenberg 09 Apr '15

09 Apr '15

Hi, On #winehq there was a discussion on Monday as I was trying to get Samsung Smart View 2.0 to run. (DotNOT 4.5 application requiring Windows 7/8.) I would report back on my findings. Anastasius Focht figured it was running into a problem discovering a suitable font (family). Here is a patch I came up with which lets the program continue. I'm not sure whether this is a correct fix however. What is happening is that in 'dlls/dwrite/font.c: collection_find_family' the name argument is completely uppercase. This is then compared to buffer which will contain a similar string at some point but with regular casing. Before that however I see the string passed with its original casing like this: 0009:Call KERNEL32.LCMapStringEx(00000000,00000200,0172c79c L"Arial",00000005,0172c7b4,00000005,00000000,00000000,001908b8) ret=00aaa471 0009:fixme:nls:LCMapStringEx unsupported lparam 1908b8 0009:Ret KERNEL32.LCMapStringEx() retval=00000005 ret=00aaa471 0009:trace:dwrite:dwritefontcollection_FindFamilyName (0x1966e8)->(L"ARIAL" 0x33be0c 0x33be08) I added two TRACE calls myself to print the values of name & buffer which gives: 0009:trace:dwrite:collection_find_family name=L"ARIAL" and later: 0009:trace:dwrite:collection_find_family buffer=L"Arial" The call to KERNEL32.LCMapStringEx may suggest that the casing is actually lost unintentionally. Thanks, Julius

2 1

Re: [PATCH 5/5] wined3d: Set color keys through the command stream.
by Henri Verbeet 08 Apr '15

08 Apr '15

On 6 April 2015 at 00:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +#define WINED3D_CKEY_REMOVE 0x80000000 > + It seems unfortunate to define part of the flags in include/wine/wined3d.h and part of the flags in dlls/wined3d/cs.c. You'd probably also want to mask out private flags in wined3d_cs_emit_set_color_key(). Ultimately though, why do you need this? Most of the CS ops operate on a wined3d_state structure, which is mirrored between the CS and the device, and (in theory) functions get passed the appropriate one depending on whether they're running from the CS or not. This one is different in that it operates on a texture, and anything that would need to read the color key would then need to either wait for the texture to become idle, or run from the CS itself. Perhaps that's ok, but it's more of a fundamental design decision than this commit makes it seem.

2 3

Re: [PATCH 2/2] shell32: Add more knownfolders
by Marvin 08 Apr '15

08 Apr '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=12722 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: winecfg: improve user experience by adding all Windows versions and accompanying error message
by Jason Overland 08 Apr '15

08 Apr '15

Is there anything I can do to improve this patch? Thanks, Jason On 03/26/2015 10:03 PM, Jason Overland wrote: > Hi, > This patch is a resubmission of and supersedes my previous patch "winecfg: add note about 32 bit prefixes to dialog". Thanks to everyone who provided feedback on that one. > > In this patch, winecfg's Application settings tab now includes all Windows versions in the combobox. If the user is running from a 64 bit prefix and selects a version of Windows that requires a 32 bit prefix, the selection will revert to the previous selection and a modal dialog containing an error message will appear: > > """ > This Wine prefix is built to support 64 bit applications. Because the Windows version you selected does not support 64 bit applications, this prefix cannot be configured to mimic that version of Windows. > > Please refer to "How do I create a 32 bit wineprefix on a 64 bit system?" in the "Using Wine" section of the Wine FAQ (http://wiki.winehq.org/FAQ) for instructions on how to create a 32 bit Wine prefix. > """ > > In addition, I noticed two File Open dialogs in winecfg which should be modal but are not modal. I made these modal by setting the appropriate owner window. While a separate issue, this seemed like a trivial enough change to include in this patch. >

3 3

Re: [1/3] ws2_32/tests: Add some more select() related tests
by Marvin 08 Apr '15

08 Apr '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=12715 Your paranoid android. === w7u (32 bit sock) === sock.c:7148: Test failed: bytesReturned isn't supposed to be 1 sock.c:7172: Test failed: GetOverlappedResult failed, error 0

1 0

Re: dinput: Add JoystickID to the Instance Name
by Dmitry Timoshkov 07 Apr '15

07 Apr '15

Aric Stewart <aric(a)codeweavers.com> wrote: > + if (SUCCEEDED(IDirectInputDevice2_GetProperty(iface, DIPROP_JOYSTICKID, (LPDIPROPHEADER)&pd))) > + index = pd.dwData; Please find a way to avoid the cast. > + if (SUCCEEDED(IDirectInputDevice2_GetProperty(iface, DIPROP_JOYSTICKID, (LPDIPROPHEADER)&pd))) > + index = pd.dwData; Same here. > + snprintf(buffer, MAX_PATH, "Joystick %d", index); 'index' is unsigned, sizeof() instead of a hardcoded value is better. -- Dmitry.

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