November 2015 - Wine-Devel - list.winehq.org

Re: [PATCH] odbccp32: Implement SQLGetPrivateProfileStringW/SQLGetPrivateProfileString (try 2)
by Nikolay Sivov Nov. 8, 2015

Nov. 8, 2015

On 08.11.2015 13:09, Alistair Leslie-Hughes wrote: > + ret = RegOpenKeyW(hkeyfilename, section, &hkeysection); > + RegCloseKey(hkeyfilename); > + > + return hkeysection; I didn't mean that you need to remove error handling completely, last return in previous iteration 'return ret ? ...' was fine.

1 0

Re: include: Add d3dx10.h file (try 3)
by Matteo Bruni Nov. 8, 2015

Nov. 8, 2015

I know I told you otherwise earlier, but looking again now: please use an unsigned literal for DXGI_FORMAT_FROM_FILE too, the definition of DXGI_FORMAT has a "DXGI_FORMAT_FORCE_UINT" entry so it should use unsigned values. While you're at it, you can drop the parentheses from the 3 defines.

1 0

Re: *.idl: Use correct type for BSTR strings in the defaultvalue() statements.
by Nikolay Sivov Nov. 6, 2015

Nov. 6, 2015

On 06.11.2015 11:37, Dmitry Timoshkov wrote: > This matches midl/PSDK syntax, and allows to use Wine headers for compiling > applications with a C++ win32/win64 compiler. In order to be usable by C++ > unix compilers widl needs to emit appropriate statically initialized WCHAR > strings, but that's a different problem, currently the generated Wine headers > with default(BSTR) statements can't be used with C++ at all. > Where do you see this? Mshtml.idl from Windows 10 SDK doesn't use this notation, and in fact only fsrm*.idl files do, so it's not a common practice. Generated headers should use L"", like you said. But only in case of empty strings. Also leaving this broken for everything that's not PSDK compiler doesn't sound right.

3 8

Re: [PATCH 1/3] msvcrt: Lock the heap in _callnewh
by Piotr Caban Nov. 6, 2015

Nov. 6, 2015

On 11/06/15 11:28, Martin Storsjo wrote: > int CDECL _callnewh(MSVCRT_size_t size) > { > + int ret = 0; > + LOCK_HEAP; > if(MSVCRT_new_handler) > - (*MSVCRT_new_handler)(size); > - return 0; > + ret = (*MSVCRT_new_handler)(size); > + UNLOCK_HEAP; > + return ret; > } It doesn't make sense to lock heap cs in this case. Native is not doing it (at least in case of msvcp90.dll). The return value change looks almost correct - the function only returns 0 or 1. Thanks, Piotr

2 3

Re: [PATCH 1/2] winemac: Use CVDisplayLink to limit window redrawing to the display refresh rate.
by Huw Davies Nov. 6, 2015

Nov. 6, 2015

On Fri, Nov 06, 2015 at 02:47:10AM -0600, Ken Thomases wrote: > dlls/winemac.drv/Makefile.in | 2 +- > dlls/winemac.drv/cocoa_window.h | 2 + > dlls/winemac.drv/cocoa_window.m | 166 ++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 169 insertions(+), 1 deletion(-) Hi Ken, This doesn't build for me on 10.7: gcc -m32 -c -o cocoa_window.o cocoa_window.m -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes \ -Wwrite-strings -Wpointer-arith -gdwarf-2 -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 cocoa_window.m:161: error: expected specifier-qualifier-list before ‘CVDisplayLinkRef’ cocoa_window.m:174: error: expected ‘)’ before ‘displayLink’ cocoa_window.m: In function ‘-[WineDisplayLink initWithDisplayID:]’: cocoa_window.m:181: warning: implicit declaration of function ‘CVDisplayLinkCreateWithCGDisplay’ cocoa_window.m:181: error: ‘_link’ undeclared (first use in this function) cocoa_window.m:181: error: (Each undeclared identifier is reported only once cocoa_window.m:181: error: for each function it appears in.) cocoa_window.m:185: warning: implicit declaration of function ‘CVDisplayLinkSetOutputCallback’ cocoa_window.m:185: error: ‘WineDisplayLinkCallback’ undeclared (first use in this function) cocoa_window.m: In function ‘-[WineDisplayLink dealloc]’: cocoa_window.m:200: error: ‘_link’ undeclared (first use in this function) cocoa_window.m:202: warning: implicit declaration of function ‘CVDisplayLinkStop’ cocoa_window.m:203: warning: implicit declaration of function ‘CVDisplayLinkRelease’ cocoa_window.m: In function ‘-[WineDisplayLink addWindow:]’: cocoa_window.m:215: warning: implicit declaration of function ‘CVDisplayLinkStart’ cocoa_window.m:215: error: ‘_link’ undeclared (first use in this function) cocoa_window.m: In function ‘-[WineDisplayLink removeWindow:]’: cocoa_window.m:225: error: ‘_link’ undeclared (first use in this function) cocoa_window.m: At top level: cocoa_window.m:242: error: expected ‘)’ before ‘displayLink’ cocoa_window.m: In function ‘+[WineWindow createWindowWithFeatures:windowFrame:hwnd:queue:]’: cocoa_window.m:689: error: request for member ‘autodisplay’ in something not a structure or union cocoa_window.m: In function ‘-[WineWindow orderBelow:orAbove:activate:]’: cocoa_window.m:1310: warning: ‘WineWindow’ may not respond to ‘-checkWineDisplayLink’ cocoa_window.m:1310: warning: (Messages without a matching method signature cocoa_window.m:1310: warning: will be assumed to return ‘id’ and accept cocoa_window.m:1310: warning: ‘...’ as arguments.) cocoa_window.m:1329: warning: ‘WineWindow’ may not respond to ‘-checkWineDisplayLink’ cocoa_window.m: In function ‘-[WineWindow doOrderOut]’: cocoa_window.m:1370: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1372: warning: ‘WineWindow’ may not respond to ‘-grabDockIconSnapshotFromWindow:force:’ cocoa_window.m:1383: warning: ‘WineWindow’ may not respond to ‘-checkWineDisplayLink’ cocoa_window.m: In function ‘-[WineWindow checkWineDisplayLink]’: cocoa_window.m:1682: warning: ‘WineWindow’ may not respond to ‘-isEmptyShaped’ cocoa_window.m:1689: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1694: warning: ISO C90 forbids mixed declarations and code cocoa_window.m: In function ‘-[WineWindow grabDockIconSnapshotFromWindow:force:]’: cocoa_window.m:1744: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1761: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1774: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1781: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1785: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1788: warning: ISO C90 forbids mixed declarations and code cocoa_window.m:1805: warning: ‘NSImage’ may not respond to ‘-drawInRect:’ cocoa_window.m:1811: warning: ISO C90 forbids mixed declarations and code cocoa_window.m: In function ‘-[WineWindow miniaturize:]’: cocoa_window.m:2031: warning: ISO C90 forbids mixed declarations and code cocoa_window.m: In function ‘-[WineWindow windowWillResize:toSize:]’: cocoa_window.m:2413: warning: ISO C90 forbids mixed declarations and code cocoa_window.m: In function ‘-[WineWindow draggingEntered:]’: cocoa_window.m:2554: warning: ‘WineWindow’ may not respond to ‘-draggingUpdated:’ cocoa_window.m:2554: warning: return makes integer from pointer without a cast make[1]: *** [cocoa_window.o] Error 1 make: *** [dlls/winemac.drv] Error 2

2 5

Re: [PATCH 2/3] msvcrt: Use the right _iob functions in the public msvcrt header for ucrtbase
by Piotr Caban Nov. 6, 2015

Nov. 6, 2015

On 11/06/15 11:28, Martin Storsjo wrote: > #ifndef _STDIO_DEFINED > -# ifdef __i386__ > -FILE* __cdecl __p__iob(void); > -# define _iob (__p__iob()) > +# ifdef UCRTBASE > +FILE* __cdecl __acrt_iob_func(unsigned); > +# define _iob(x) (__acrt_iob_func(x)) > # else > +# ifdef __i386__ > +FILE* __cdecl __p__iob(void); > +# define _iob(x) (__p__iob() + (x)) > +# else > FILE* __cdecl __iob_func(void); > -# define _iob (__iob_func()) > +# define _iob(x) (__iob_func() + (x)) > +# endif This makes _iob definition incompatible with native headers. It can't be done this way. I don't know how to solve this problem. Maybe adding something like this in msvcp90/ios.c will be acceptable: #if _MSVCP_VER >= 140 FILE* __cdecl __acrt_iob_func(unsigned); #undef stdin #define stdin __acrt_iob_func(STDIN_FILENO) ... #endif Thanks, Piotr

1 0

Re: [RFC PATCH] msvcp140: Add MSVC 2015 C++ support DLL
by Piotr Caban Nov. 6, 2015

Nov. 6, 2015

On 11/04/15 20:12, Martin Storsjo wrote: > The built DLL links to (and loads function pointers at runtime from) > msvcr120, instead of ucrtbase (which would be more correct). We really need to e.g. share file handles between ucrtbase and msvcp140. We will need to find a way of linking against ucrtbase. It will probably need to be done by defining wrappers around some functions. For example missing _invalid_parameter should be probably worked around by defining following function in msvcp140: void __cdecl _invalid_parameter(const wchar_t *expr, const wchar_t *func, const wchar_t *file, unsigned int line, uintptr_t arg) { return _invalid_parameter_noinfo(); } Something similar needs to be done with __p__iob (use __acrt_iob_func function). If you have any problems with other function please let me know. Probably some more testing/work will be needed to deal with missing new/delete functions. Thanks, Piotr

2 3

Re: *.idl: Use correct type for BSTR strings in the defaultvalue() statements.
by Marvin Nov. 6, 2015

Nov. 6, 2015

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=18008 Your paranoid android. === 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 === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

1 0

Re: [2/2 v2] riched20: Implement alignment styles support.
by Huw Davies Nov. 6, 2015

Nov. 6, 2015

On Fri, Nov 06, 2015 at 10:44:57AM +0800, Jactry Zeng wrote: > --- a/dlls/riched20/editor.h > +++ b/dlls/riched20/editor.h > @@ -213,7 +213,7 @@ void ME_DumpParaStyleToBuf(const PARAFORMAT2 *pFmt, char buf[2048]) DECLSPEC_HID > BOOL ME_SetSelectionParaFormat(ME_TextEditor *editor, const PARAFORMAT2 *pFmt) DECLSPEC_HIDDEN; > void ME_GetSelectionParaFormat(ME_TextEditor *editor, PARAFORMAT2 *pFmt) DECLSPEC_HIDDEN; > void ME_MarkAllForWrapping(ME_TextEditor *editor) DECLSPEC_HIDDEN; > -void ME_SetDefaultParaFormat(PARAFORMAT2 *pFmt) DECLSPEC_HIDDEN; > +void ME_SetDefaultParaFormat(DWORD alignStyle, PARAFORMAT2 *pFmt) DECLSPEC_HIDDEN; Why did you change this? Your last patch had ME_TextEditor* as the first parameter, which was much better. > --- a/dlls/riched20/tests/editor.c > +++ b/dlls/riched20/tests/editor.c > @@ -7951,6 +7951,77 @@ static void test_EM_SETFONTSIZE(void) > DestroyWindow(richedit); > } > > + ^ There's a trailing space here. Huw.

2 1

Re: *.idl: Use correct type for BSTR strings in the defaultvalue() statements.
by Marvin Nov. 6, 2015

Nov. 6, 2015

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=18007 Your paranoid android. === 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 === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

1 0

Re: [resend 3/5] ddraw7/tests: test SetColorKey on cubemap surfaces
by Stefan Dösinger Nov. 6, 2015

Nov. 6, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-11-04 um 19:51 schrieb Riccardo Bortolato: > + hr = IDirectDrawSurface7_GetColorKey(mipmap, DDCKEY_SRCBLT, > &color_key); + ok(hr == DDERR_NOCOLORKEY, "Got unexpected hr > %#x.\n", hr); + color_key.dwColorSpaceLowValue = 0x0000ff00; + > color_key.dwColorSpaceHighValue = 0x0000ff00; + hr = > IDirectDrawSurface7_SetColorKey(mipmap, DDCKEY_SRCBLT, > &color_key); + ok(SUCCEEDED(hr), "Failed to set color key, hr > %#x.\n", hr); One more thing that's interesting to test here: Set a different color key, and after the successful SetColorKey test which one you get back. You might even get DDERR_NOCOLORKEY back after the successful Set. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWO0wKAAoJEN0/YqbEcdMwsn4P/A9Mgwuq+4H0/2atLKdVlX7u RBAx/ZrhNEXT5W0Kzo1eZCUD5RjKf4mnuUi6x6LwX7JczJ9Dxxcz2Xx4gfeb3Wmy d6F2ttzejkKwG+tPkWfzc9AG0oZ0uFxvMuyBEdMqNxRAQXec7sxse9ELlsA7A1Wk snwvheVQ7o6XP6qya9mJBgiyWRH/86VzhW4/P6EluINmcXCVL/UaZKnj7BgYL7Yy pFvFN9r7N92bAspIsIl0MxnmxZ6qbK13qbqr4JJPvjSX8TfKQfoXsHj5BW0ZoZaR uWBvKtTmF0mhcY3rVOr/tQcBtp7xBYB0QiqBwMx0lBS1gZyaoeasEEFcP8s4HROs YHV3WKxG/esYAsqNfVRH+5wWUthTT0bthOv7mUuBwMC53kQOw5eqw9v5WOwW1Omu HRZ6ssDfvMx9YWhw06DIPnaCfyEL2KfxksRHA6TMHWbY8lHNL5nP0cc+tQhKXymc c2QS0awqTX95kjf+K0giBGRhnI/BXJa3jH2Bs9/8YXtyWq8k5UvKOZbjk6IUeeod KVgARsBCQ+3idRRU9nGA4P0OkjRymQFS7U+2DLYofIjv71p/TldvkOPUKKG3y8N4 rMhpCgsyGxEuHKnz4eLTirrjGEp+NPNIy6R7aSqd/j5XjSaHujtZjv84UBuyF60Y Z/UQmUCIFyr8IiIQSFZv =Ktln -----END PGP SIGNATURE-----

2 2

Re: ws2_32/tests: Add WSAPoll() tests
by Marvin Nov. 5, 2015

Nov. 5, 2015

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

1 0

Re: [6/6] oleaut32/tests: Add a bunch of new tests for typelib generation.
by Alexandre Julliard Nov. 5, 2015

Nov. 5, 2015

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/oleaut32/tests/test_tlb.idl | 59 +++++++++ > dlls/oleaut32/tests/typelib.c | 259 ++++++++++++++++++++++++++++++++++++--- > 2 files changed, 298 insertions(+), 20 deletions(-) This is causing build warnings. I understand it may be deliberate in order to test that path, but a standard build should be warning-free so this needs to be done differently. ../../../tools/widl/widl -o test_tlb.tlb -m32 -I. -I../../../include -D__WINESRC__ test_tlb.idl warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a753903} warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a753906} warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a75396b} warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a75396d} warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a753970} warning: duplicate uuid {016fe2ec-b2c8-45f8-b23b-39e53a753972} -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [v6 05/13] ddraw7/tests: Test SetColorKey() on cubemap surfaces.
by Marvin Nov. 5, 2015

Nov. 5, 2015

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=17994 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2243: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw7.c:3084: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3086: Test failed: Got unexpected screen width 1024. ddraw7.c:3088: Test failed: Got unexpected screen height 768. ddraw7.c:3101: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3103: Test failed: Got unexpected screen width 1024. ddraw7.c:3105: Test failed: Got unexpected screen height 768. ddraw7.c:3109: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3111: Test failed: Got unexpected screen width 1024. ddraw7.c:3113: Test failed: Got unexpected screen height 768. ddraw7.c:3132: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3134: Test failed: Got unexpected screen width 1024. ddraw7.c:3136: Test failed: Got unexpected screen height 768. ddraw7.c:3140: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3142: Test failed: Got unexpected screen width 1024. ddraw7.c:3144: Test failed: Got unexpected screen height 768. ddraw7.c:3164: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3166: Test failed: Got unexpected screen width 1024. ddraw7.c:3168: Test failed: Got unexpected screen height 768. ddraw7.c:3173: Test failed: Got unexpected screen width 1024. ddraw7.c:3175: Test failed: Got unexpected screen height 768. ddraw7.c:3188: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3190: Test failed: Got unexpected screen width 1024. ddraw7.c:3192: Test failed: Got unexpected screen height 768. ddraw7.c:3196: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3198: Test failed: Got unexpected screen width 1024. ddraw7.c:3200: Test failed: Got unexpected screen height 768. ddraw7.c:3208: Test failed: Got unexpected screen width 1024. ddraw7.c:3210: Test failed: Got unexpected screen height 768. ddraw7.c:3222: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3224: Test failed: Got unexpected screen width 1024. ddraw7.c:3226: Test failed: Got unexpected screen height 768. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4081: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4094: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4110: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4129: Test failed: Display mode restored after ddraw1-ddraw7 SetCooperativeLevel() call sequence ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:5937: Test failed: Failed to set display mode, hr 0x80004001. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000 === w1064 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

Re: [1/5] gdi32: Fix the advance width in synthetic bold glyphs when using scaling factors.
by Huw Davies Nov. 5, 2015

Nov. 5, 2015

On Tue, Nov 03, 2015 at 03:06:24PM +0900, Akihiro Sagawa wrote: > @@ -6297,6 +6299,14 @@ static inline BOOL is_identity_MAT2(const MAT2 *matrix) > return !memcmp(matrix, &identity, sizeof(MAT2)); > } > > +static inline void calc_unit_vector(FT_Vector *vec) > +{ > + FT_Fixed len; > + len = pFT_Vector_Length(vec); > + vec->x = (vec->x << 6) / len; > + vec->y = (vec->y << 6) / len; > +} You need to check for division by zero. Huw.

2 1

Re: [1/5] gdi32: Fix the advance width in synthetic bold glyphs when using scaling factors.
by Henri Verbeet Nov. 5, 2015

Nov. 5, 2015

> +static inline void calc_unit_vector(FT_Vector *vec) > +{ > + FT_Fixed len; > + len = pFT_Vector_Length(vec); > + vec->x = (vec->x << 6) / len; > + vec->y = (vec->y << 6) / len; > +} For what it's worth, that's usually called normalisation. Given how this is used, there's probably something to be said for not modifying the input vector and just having an output variable instead.

2 1

Re: [resend 3/5] ddraw7/tests: test SetColorKey on cubemap surfaces
by Marvin Nov. 5, 2015

Nov. 5, 2015

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=17975 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2243: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw7.c:3084: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3086: Test failed: Got unexpected screen width 1024. ddraw7.c:3088: Test failed: Got unexpected screen height 768. ddraw7.c:3101: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3103: Test failed: Got unexpected screen width 1024. ddraw7.c:3105: Test failed: Got unexpected screen height 768. ddraw7.c:3109: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3111: Test failed: Got unexpected screen width 1024. ddraw7.c:3113: Test failed: Got unexpected screen height 768. ddraw7.c:3132: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3134: Test failed: Got unexpected screen width 1024. ddraw7.c:3136: Test failed: Got unexpected screen height 768. ddraw7.c:3140: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3142: Test failed: Got unexpected screen width 1024. ddraw7.c:3144: Test failed: Got unexpected screen height 768. ddraw7.c:3164: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3166: Test failed: Got unexpected screen width 1024. ddraw7.c:3168: Test failed: Got unexpected screen height 768. ddraw7.c:3173: Test failed: Got unexpected screen width 1024. ddraw7.c:3175: Test failed: Got unexpected screen height 768. ddraw7.c:3188: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3190: Test failed: Got unexpected screen width 1024. ddraw7.c:3192: Test failed: Got unexpected screen height 768. ddraw7.c:3196: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3198: Test failed: Got unexpected screen width 1024. ddraw7.c:3200: Test failed: Got unexpected screen height 768. ddraw7.c:3208: Test failed: Got unexpected screen width 1024. ddraw7.c:3210: Test failed: Got unexpected screen height 768. ddraw7.c:3222: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3224: Test failed: Got unexpected screen width 1024. ddraw7.c:3226: Test failed: Got unexpected screen height 768. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4081: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4094: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4110: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4129: Test failed: Display mode restored after ddraw1-ddraw7 SetCooperativeLevel() call sequence ddraw7.c:4035: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:5937: Test failed: Failed to set display mode, hr 0x80004001. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000 === w1064 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

3 3

Re: [resend 5/5] wined3d: remove wined3d_surface_{inc,dec}ref
by Henri Verbeet Nov. 5, 2015

Nov. 5, 2015

For what it's worth, this patch seems fine. You should probably move it to the start of the series. It would be nice if you could split it per function that you modify (and used capitalization and punctuation in the subject line), but it's not strictly required.

2 1

Re: [resend 1/5] ddraw: check if surface is a mipmap sublevel through caps in ddraw_surface7_GetPriority
by Stefan Dösinger Nov. 5, 2015

Nov. 5, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-11-04 um 19:51 schrieb Riccardo Bortolato: > - else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || !surface->wined3d_texture) > + else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL)) > { > WARN("Called on non-managed texture or mipmap sublevel, returning DDERR_INVALIDPARAMS.\n"); > hr = DDERR_INVALIDPARAMS; This will cause a crash if called on a top level cube map that's not the positive X face because the follow-up code assumes that surface->wined3d_texture is there. This could use a test as well, similarly to SetColorKey. It's possible that crashing is the right thing to do. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWO0z2AAoJEN0/YqbEcdMwrhgP/03F5zCAxKbJ738MrKYu2iUk 0azMw0sVdO2trn9KzuAbGKr74HBJCmhnGCBwWvTnn767UmUU73kbuY/VHQ6ZsiMt 9qNwDYQew/VIzXeDPPDOgtwkj+tpFrYeBGZVpPAPqcY2QoCGvS1VXTfUnKHQWnYF BxI1Qwh0xOi30saYG2UVzCI2G1DWH8/FVB4K9k/4FXTBK5AEDO0BeWloZ3bStvWU d188Huk6R+9GFaAJyJ7oV2V1SV3WSRQVvY10YW16fFSWcTARMb6xMbyoAS0WQp7q 6w5cD1sr+rnwmgGmSKhMOrp6dfWzwma7tk66BXcd7zjT8JoI7+7Qniz2LFuG6zgW uIQIpfhdDE9eGShkZriguU8o0ZVojjg3K1ubf9gsmMxvs6yneUYCRS6MjjYAXccS HJALmJIn6YAcS6MBa0lXkHNxBBYHnmWNZjNhsyLuPj+TSh8xM//cayiT6ySURGSb 4/uK8cgkqm8QUBbLZTCN8Lv/S3Kx/o37GyujteJHs+2CLLoAe837dqcu6krPtWpA tPM3a++y5D3c5MpFG0qP2ZXRQkhlZtZJHj1gR2/hRWtRItaLd+n5iDCte+tw5f6T 5ld921LkMPR43ratmvHH6GlsKwPh3pqU7dH8s8viJAR2h4EcxQhxACcAHjpv5ByO Ia/F1xe5TUG0UY9CEBgA =SI7R -----END PGP SIGNATURE-----

2 1

Re: [resend 1/5] ddraw: check if surface is a mipmap sublevel through caps in ddraw_surface7_GetPriority
by Henri Verbeet Nov. 5, 2015

Nov. 5, 2015

On 4 November 2015 at 19:51, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > - else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || !surface->wined3d_texture) > + else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL)) Please don't add lines longer than 120 characters. (And aim for about 100.)

2 1

Re: [PATCH 2/5] ddraw: check if surface is a mipmap sublevel through caps in ddraw_surface7_GetPriority
by Stefan Dösinger Nov. 5, 2015

Nov. 5, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-11-03 um 11:45 schrieb Riccardo Bortolato: > - else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || !surface->wined3d_texture) > + else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL)) This will show different behavior on level 0 Y, Z and negative X cube map surfaces. (Positive X is the actual ddraw root surface). However, I vagely remember that native ddraw also misbehaved here, so the new behior is probably correct. I'll check with my SetColorKey tests and report back. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWOKFcAAoJEN0/YqbEcdMw+58P/2gMcrKJWf0CAQXZ4rATJiwt 5MzyMISpifgcKjmV/YdYz/cJG98QcOCUgOqHCHzBi2iXfDZth1y6PX9qMdR3wT5q OzT++ZiJa+JVYUjn5eNbpV7VUXxghqCS6yyD+je9wkgGAEWIgJaN5txiyXx91qAQ 5Pxe0dUHSJDD/sb2e3UTOzQoQsuE+vQWbho82Los5IJTs2Bl3fOqmwuDIpGdteYM TRsMkWLY7UUeb4XrSjTmDw37eHsWXoEAH2RC/HXTbbY+NDzW5a948Uk0YgHtEDSP sUbiYVJaIw2eM67dKC1mF+g9H3hsNtKw8EhqyUUEoFjl4bq9O8w4K9QaHPEXULEQ dIuUq/tOWGimPIGjMYQqS+aWB28L4H0SER0zC8uX1x/vO8W3+lmLoXgKp2p85K3g AJZmxO6lEZFEHvhDuIUlfWoSOOuc+rlHSDsgII7Qhy3V2wPrI01NNyUTfeLx3z2r Q35tSsi/j4me9tWgcNth0TdYstE7/aDej8bWv7MXj2xo+p3v6y6ppGnadjzHqNsu skKcgQpQIHt+2F4fPX3/xwj/CpvK7i8UwTC5/Zp+nGI3qxdCD1lNNTBQJA8Ajl9Y 8yWOpvR6tjhMc898qBOKp4opXbqW8x2hyIDGF/binGlHlKa2vOfsCl5JY0y4TzpL eDENyDHAisigjU/8qZYJ =ejR9 -----END PGP SIGNATURE-----

3 4

Re: [PATCH] ucrtbase: Implement _seh_filter_exe and _seh_filter_dll
by Piotr Caban Nov. 5, 2015

Nov. 5, 2015

On 11/04/15 11:19, Martin Storsjo wrote: I was not checking if this patch is correct yet. It causes compilation warnings: ../../../wine_src/dlls/msvcr120/../msvcrt/except.c: In function '_seh_filter_dll': ../../../wine_src/dlls/msvcr120/../msvcrt/except.c:283:159: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=] TRACE("(%08x,%p)\n", ex, ptr); ^ ../../../wine_src/dlls/msvcr120/../msvcrt/except.c: In function '_seh_filter_exe': ../../../wine_src/dlls/msvcr120/../msvcrt/except.c:293:159: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=] TRACE("(%08x,%p)\n", ex, ptr); Thanks, Piotr

2 1

Re: [resend 2/5] ddraw: check for mipmap sublevel through caps in ddraw_surface7_SetColorKey
by Stefan Dösinger Nov. 5, 2015

Nov. 5, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-11-04 um 19:51 schrieb Riccardo Bortolato: > - wined3d_mutex_lock(); > - if (!surface->wined3d_texture) > - { > - wined3d_mutex_unlock(); > + if (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL) > return DDERR_NOTONMIPMAPSUBLEVEL; > - } > - wined3d_mutex_unlock(); This is OK, but an fyi: The wined3d lock is also used to protect ddraw data (something we may want to change in the future). DDSCAPS2_MIPMAPSUBLEVEL is not changable after creation (via SetSurfaceDesc), so I don't think we need to worry about the lock here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWO02tAAoJEN0/YqbEcdMwlmsP/297KNeM9NoJ6C6cljdOi3us GixMSJeTHwOmz0xVsu8fHVOpetiKWmn7h0qVn5aGoZNgs6vIHd+f2F+gf5EIlkA0 LxHQWwZUnulbW+unUIh/mj+Z7exjtWn1vn1jFjGyRB+9QgqxiZ9Nm6cz3z5tbtIc +1q5M/VYabvwzEGojV+ZK8cRnFnt3UsFTysxL94s1fz+Mn4IMTXfPejwF/PbylEV QPWOqg8LF+OKULdZw8oxn3APjQ+CFHvTCsCRbaB9wpeVRb4SEaIWyjopXxBQA9F8 WF1WrxmgkHA+WGWhItdxHkJYBbYFyDU7Vy5Up0Z9i0cLOwUT6EtQGyWuojeGkoTk bJah077nAMf6Ua5yqrT/Dl+bPUWovPZQ60umZdnNul4HKCuyJeHvALkZharXYJU4 3P4YYlIzWPqRdk7csaehr1DPkKcQZvKRhdaGkYhzg+NKM89ztgNALeTNs08GmzHP Ta+w8OfSRZM1lwmwT/0Tk8NggMrFe6qX1w7Fu6I3cvcaa5H6e2xhFyXKGWFbUCBQ ieJ5Z0VKuO0WqOiWF2hPsrHqerLDMKCpR9pCCp5B9ciU9qZcmfGT/XKa5U01kah1 qEJ84ejVkM5bwnhbrS8BhmepVC9K7c7/bG/z25ayizU8foKukRNtS+Pz3DGA6OzF nfQeq4wZ/zAush2o+2oJ =aXfg -----END PGP SIGNATURE-----

1 0

Re: riched20: Implement alignment styles.
by Huw Davies Nov. 5, 2015

Nov. 5, 2015

On Wed, Nov 04, 2015 at 06:12:29PM +0800, Jactry Zeng wrote: > -ME_TextEditor *ME_MakeEditor(ITextHost *texthost, BOOL bEmulateVersion10) > +ME_TextEditor *ME_MakeEditor(ITextHost *texthost, BOOL bEmulateVersion10, DWORD align) > { > ME_TextEditor *ed = ALLOC_OBJ(ME_TextEditor); > int i; > @@ -2804,6 +2804,7 @@ ME_TextEditor *ME_MakeEditor(ITextHost *texthost, BOOL bEmulateVersion10) > ed->reOle = NULL; > ed->bEmulateVersion10 = bEmulateVersion10; > ed->styleFlags = 0; > + ed->alignStyle = align; > ITextHost_TxGetPropertyBits(texthost, > (TXTBIT_RICHTEXT|TXTBIT_MULTILINE| > TXTBIT_READONLY|TXTBIT_USEPASSWORD| Rather than add a new param to MakeEditor just explicitly set ed->alignStyle after the call in CreateTextHost. > diff --git a/dlls/riched20/para.c b/dlls/riched20/para.c > index 8cf3d24..88b821f 100644 > --- a/dlls/riched20/para.c > +++ b/dlls/riched20/para.c > @@ -30,7 +30,7 @@ void ME_MakeFirstParagraph(ME_TextEditor *editor) > LOGFONTW lf; > HFONT hf; > ME_TextBuffer *text = editor->pBuffer; > - ME_DisplayItem *para = ME_MakeDI(diParagraph); > + ME_DisplayItem *para = ME_MakeDI(editor, diParagraph); > ME_DisplayItem *run; > ME_Style *style; > int eol_len; I think we need a make_para( ME_TextEditor *editor ). It would call ME_MakeDI (no need for that to get editor) and then do the special case stuff for paragraphs. Huw.

1 0

Re: [PATCH] kernel32/tests: Add test of CreateDirectory with long path.
by Dmitry Timoshkov Nov. 5, 2015

Nov. 5, 2015

YongHao Hu <christopherwuy(a)gmail.com> wrote: > On Windows, CreateDirectoryA fail when the path's size longer than > MAX_PATH-12(248) while Wine's implementation succeed.[1] > > [1]:https://bugs.winehq.org/show_bug.cgi?id=39552 Is there an application that depends on this very strange implementation detail? Besides, the messages in the ok() calls sometimes are wrong. Also, you shouldn't test against TRUE/FALSE directly. -- Dmitry.

2 2