- wine-devel - winehq.org

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

Problem receiving UDP broadcast on wxppro and w2008s64
by Bruno Jesus 07 Apr '15

07 Apr '15

Hi, Francois, I hope you can help me in this situation. The patch attached to bug 31994 [1] (compiled version at [2]) runs fine in most testbot machines (tested dozens of times) and my personal XP machine, but for some reason it doesn't work in xppro and w2008s64. The test creates 2 UDP sockets and send a broadcast from socket A to the network where B is bound, but the broadcasted packet never is received by B resulting in test timeout due to recvfrom never getting data. According to [3] all testbots share similar IP addresses like and I can't imagine a reason for them not to work: wxppro: testing broadcast for interface IP 10.42.42.134 (don't work) w2003std: testing broadcast for interface IP 10.42.42.140 (works) wvistau64: testing broadcast for interface IP 10.42.42.138 (works) w2008s64: testing broadcast for interface IP 10.42.42.216 (don't work) Any ideas? I wonder if it could be a firewall. The test also works fine in NT4. [1] https://bugs.winehq.org/attachment.cgi?id=51182 [2] https://testbot.winehq.org/GetFile.pl?JobKey=12594&StepKey=1 [3] https://testbot.winehq.org/JobDetails.pl?Key=12591 Best Regards, Bruno

2 5

Re: locale: [1/1] patch - 0x10000000 flag is NORM_STOP_ON_NULL (plus test fix)
by Marvin 07 Apr '15

07 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=12697 Your paranoid android. === w2000pro (32 bit locale) === locale.c:1776: Test failed: Without NORM_STOP_ON_NULL flag - strings `don\0a` (5) and `don\0b` (5) expected CSTR_LESS_THAN, got 2

1 0

CoInternetParseUrl and concepts explanation.
by Philippe Groarke 06 Apr '15

06 Apr '15

Hello, I am currently exploring Wine code base looking for low hanging fruits I can contribute to. I think CoInternetParseUrl and other URLMon stubs seemed easy enough I want to try and implement some. I also see many URLMon stubs when using Wine for games and applications. In CoInternetParseUrl, you use a switch case depending on the parameters passed. These in turn call specific methods for each parameter, which most do the same thing, call IInternetProtocolInfo_ParseUrl with the desired parse option . This function is defined in urlmon header. It seems to call a saved This on runtime, derefencing a saved (?) virtual table calling ParseUrl. It is also implemented in the header (static FORCEINLINE) and also calls the ParseUrl. There are some STDMETHODCALLTYPE pure virtual methods inside a IInternetProtocoleInfo class. A struct virtual table IInternetProtocolInfoVtbl O_o I cannot find the actual ParseUrl implementation, though in misc.c, there are many references to CHECK_CALLED(ParseUrl) and SET_EXPECT(ParseUrl). I have no clue what is going on here to be completely honest. Finally, in misc.c there are some pCoInternetParseUrl and CoInternetParseUrl tests. But nothing that seems to implement what I need. My question is, why go through all these hoops instead of implementing CoInternetParseUrl inside internet.c. I am sure there is good reasoning behind this, I would just like to understand why. Also, where do I implement ParseUrl or IInternetProtocolInfo_ParseUrl? Thank you for any help in understanding what is going on here. Good day, Philippe

2 1

Re: [PATCH 2/4] ntdll/test: Add ntdll test function test_file_full_size_information
by Nikolay Sivov 06 Apr '15

06 Apr '15

On 04.04.2015 10:03, Jianqiu Zhang wrote: > + trace("TotalAllocationUnits %08x %08x\n", fsi.TotalAllocationUnits.HighPart, fsi.TotalAllocationUnits.LowPart); > + trace("CallerAvailableAllocationUnits %08x %08x\n", fsi.CallerAvailableAllocationUnits.HighPart, fsi.CallerAvailableAllocationUnits.LowPart); > + trace("ActualAvailableAllocationUnits %08x %08x\n", fsi.ActualAvailableAllocationUnits.HighPart, fsi.ActualAvailableAllocationUnits.LowPart); > + trace("SectorsPerAllocationUnit %08x\n", fsi.SectorsPerAllocationUnit); > + trace("BytesPerSector %08x\n", fsi.BytesPerSector); > + Hi, Jianqiu. This is not exactly a test, as you're just printing a result. Same thing with patch 3/4. Also to print LONGLONG values you use wine_dbgstr_longlong() probably.

2 3

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.
by Bruno Jesus 06 Apr '15

06 Apr '15

On Sun, Apr 5, 2015 at 4:07 PM, Socapex <philippe.groarke(a)gmail.com> wrote: > If HAS_IPX isn't defined, compilation will throw error since > WS_IPX_* aren't declared. > --- > dlls/ws2_32/socket.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 09c8416..bc4d40a 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -365,6 +365,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKLEVEL(WS_NSPROTO_IPX); > switch(optname) > { > +#ifdef HAS_IPX > DEBUG_SOCKOPT(WS_IPX_PTYPE); > DEBUG_SOCKOPT(WS_IPX_FILTERPTYPE); > DEBUG_SOCKOPT(WS_IPX_DSTYPE); > @@ -372,6 +373,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKOPT(WS_IPX_MAXSIZE); > DEBUG_SOCKOPT(WS_IPX_ADDRESS); > DEBUG_SOCKOPT(WS_IPX_MAX_ADAPTER_NUM); > +#endif > } > break; Hi, unfortunately I don't have OSX so I only test my patches in Linux and FreeBSD, so sometimes these problems happen, sorry. I think it's better to simply remove the #ifdef around wsnwlink.h [1], this will not reduce the debug capabilities of debugstr_sockopt. Since wsnwlink.h is an internal include it will always be available, can you it, please? [1] From socket.c: 160 #ifdef HAS_IPX 161 # include "wsnwlink.h" 162 #endif Best Regards, Bruno

2 1

Re: [PATCH 2/2] ws2_32: Remove trailing white-spaces.
by Stefan Dösinger 05 Apr '15

05 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-04-05 um 21:07 schrieb Socapex: > -/* Note: EAI_NODATA is deprecated, but still > +/* Note: EAI_NODATA is deprecated, but still Generally we don't commit whitespace-only changes because they cause problems with git blame (though git blame has been improved in that regard) and merges. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVIYsNAAoJEN0/YqbEcdMwLUEP/jy+kbilEFxb+W5HrbvV5x4Y GKTrrE0sBYv3RmcLEdCEmivTt5BOHerIxmoy5Li2wsH/S1FglwcdVETTBBG9v8tV 0dEgJ/p3GAB8RPQTRtvHTyr5aiUqOQg0HNW08puy/OHF3Zr3BTiFfzNLfKcVRTj5 Vvp28AwThDTqjG85ajOezBfxw/H6g4D8GtmsETYr2NYQZD9lt+C28op9K5hxSuA9 E05Af00Rxye7qb8ry715cAbBg2nO/MDygRt5iYpCX6Rd8fmRuM5O27MJLDQkq/pU GDKilQuWmiwZPEQcs3PKbOql3xditgvLrGKk4jkYAiXfTtaxIvwz9GDA6KVXynom Hv/m2BFKV1odoBYkDWlZZ42XVj1aZFKFZIknVTddDoRN/AVfTBO3cz5TPWOwr0q3 jGWOBT31ksWStdXOaQsPyUjX7ZKws2T2ZTRZTKoY0o/c/LYAXIgqz0VNwVnVaIs2 x+xlrdEpg58E1JuLBL93F0z3Pe+YQXqdv3RhWNSgzosK3VmaEC8+GzWBUR8gQMlJ UW0WRSycE9AktMGJv1+Grf/PIk8pHRN+4veL4065M5a4jaeclghx/HxqswuI8WCV Ty1qe5eHeNbD/9cEzbRSHBOV5g/V+xmvgzY5M0DJ2TTSMchmkJzC00m0khRMWhaj JMLgp7jnoWasLLA2ufZH =MEUF -----END PGP SIGNATURE-----

1 0

Re: [PATCH 1/2] ws2_32: Fix compile on OS X.
by Stefan Dösinger 05 Apr '15

05 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You have to use your real name, not a nickname. We need this to be able to show where our code comes from. With best regards, Stefan Am 2015-04-05 um 21:07 schrieb Socapex: > If HAS_IPX isn't defined, compilation will throw error since > WS_IPX_* aren't declared. > --- > dlls/ws2_32/socket.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 09c8416..bc4d40a 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -365,6 +365,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKLEVEL(WS_NSPROTO_IPX); > switch(optname) > { > +#ifdef HAS_IPX > DEBUG_SOCKOPT(WS_IPX_PTYPE); > DEBUG_SOCKOPT(WS_IPX_FILTERPTYPE); > DEBUG_SOCKOPT(WS_IPX_DSTYPE); > @@ -372,6 +373,7 @@ static inline const char *debugstr_sockopt(int level, int optname) > DEBUG_SOCKOPT(WS_IPX_MAXSIZE); > DEBUG_SOCKOPT(WS_IPX_ADDRESS); > DEBUG_SOCKOPT(WS_IPX_MAX_ADAPTER_NUM); > +#endif > } > break; > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVIYmzAAoJEN0/YqbEcdMwmcMP/0UWQMONOFklXHtI9ibTn5rU Y8idfpQRQEj7s4UqKT5XdHbbGsmGa24byBybhWf54z/ykTqcwvcun4xDUs0/pmCK WRWx9hlgGd4xPSGrnum9XC/tnywjyP5s8eyRUU4CeMmBOIwauj15iePd/v4W+BA+ iHTyY4rjzyoyatmZURoaZaFFj/n5cLoqyqQ+fTNeP22z+Wjl7N76wXYbsylRsatB NKe8bAdBAQZL8LNngjpCVXW0PsKaH88LIdVPZpvI0T+hH8+LYRToKbfqCXtwkwYb LuE9RCdfAcRbIQTCe4FrpfduGUtQN2Nlxu7pIOH9GghWITTjIZn/XV0VYSBVDrNc d2zZ0lmyEWPU6H5RU/dzfhkJMhKP7RzZkd3j7yDKsjBlC651ysDT6ev/HpX2Jx7O aYf70/48Qk5BhbEZblQuPrssz/p4ErXHz2UQRGodqLjJm+ATSwkSlwsAGZ8iyjn0 3JQuL3BDDSF3CAjfQBLfcRXS4tNgNd58rr5dfoLmOhkKG+LIbYIQ55104UG03xDc 5LFubLU8i8r89OBR3yeZXLIX3BdR3oxANVDoPjjbbJiAKIoej5yJOCyLb8cPbchN CufNxeiY+wrKNWtuW6UXONaEJqt2MpcY0HUV70s9qRXZ2iZoPKDFkR5mPudR7qbj ZIUAqSKGQcWwmCw+aEk+ =ShND -----END PGP SIGNATURE-----

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