- wine-devel - winehq.org

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

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