December 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 15/15] api-ms-win-core-winrt-string: Implement a few HSTRING functions.

by Martin Storsjö

Hi Sebastian, On Mon, 1 Dec 2014, Sebastian Lackner wrote: >>> * http://msdn.microsoft.com/en-us/library/br224632(v=vs.85).aspx >>> mentions: """Calling WindowsDeleteString decrements the reference >>> count of the backing buffer, and if the reference count reaches 0, >>> the Windows Runtime de-allocates the buffer.""" >>> >>> I don't see the concept of refcounted backing buffers anywhere in >>> your code, which is most likely wrong. Its difficult to fix that >>> later. >> >> I had a really hard time understanding the MSDN part here - I don't >> find any corresponding function for increasing a refcount, so I don't >> see how the HSTRING itself would be refcounted. So I think that only >> matters once you pass those string handles into the full Windows >> Runtime itself. > > I think the main purpose of that is to implement fast versions for > functions like SubString(...). If its not created with > WindowsCreateStringReference(...) both strings can use the same backing > buffer, which is faster than copying part of the string. > > Normally strings are immutable, but as it is also possible to get a raw > pointer to the buffer ( > http://msdn.microsoft.com/en-us/library/br224636(v=vs.85).aspx ) an > application might depend on this specific implementation detail. Tests > would really help here to confirm my theory that changing the substring > also modifies the original one. I did test this now, and no, a string created with WindowsSubstring doesn't share the same backing buffer as the original string it was based on (created with WindowsCreateString), so changes to either of them via the pointer from WindowsGetStringRawBuffer doesn't affect the other one. So therefore I don't really see where reference counting would come into play with this API at all, unless the Windows Runtime hooks into HSTRING objects via some other (non-public) functions. Or is CloseHandle supposed to be able to handle HSTRINGs, and is there any corresponding function that would increase the reference count of any generic HANDLE? // Martin

Dec. 6, 2014

Please help spread the word about the Software Freedom Conservancy

by Jeremy White

Folks, Tony at the Conservancy reached out to us to ask our help in spreading the word about Conservancy. The Conservancy is our sponsoring organization, and they have been a great friend to Wine through the years. As they requested, I'm sending an email blast to our mailing list to spread the word. I'd ask you to scan their email and if you can help them in any of the ways they ask, please help them. They're good people, and good for Wine. Thanks, Jeremy -------- Forwarded Message -------- Subject: Conservancy projects: help us launch the Official Conservancy Supporter program! Date: Wed, 03 Dec 2014 17:17:47 -0500 From: Tony Sebro Hi, all: We at Conservancy are committed to doing whatever we can to support our member projects, and to help you produce great, freely-licensed software for the public's benefit. At this time, we could use the support of you, our member projects, as well. Today, Conservancy launched the official Conservancy Supporter program (http://sfconservancy.org/supporter/) This is our first campaign to build awareness about Conservancy, and our first attempt to really engage the public in a fundraising campaign. While we're glad to help you organize project-specific revenue-generating activities (e.g., project fundraisers, conferences, etc.), we've kept the percentage of revenue we receive from member projects under our FSA so low that it doesn't even pay for a single Conservancy staff member. So, we need our member projects' help to get the word out about who we are, what we do, and how friends of free and open source software can become Conservancy Supporters. Conservancy Supporters will receive: - an "Official Conservancy Supporter" badge for display on their personal websites; - a printable "Official Conservancy Supporter" card; and - a snazzy Conservancy T-Shirt. _ Ways__you can help spread the word_: - Follow @Conservancy on Twitter and/or Identi.ca - Tweet/Dent/Microblog about the Conservancy Supporter program on your social media platform of choice, with a link to the campaign page (please use the #ConservancySupporter hashtag) - If your project has an official social media account, please use that to microblog as well - Send email blasts to your project's mailing lists - Write a blog post or a testimonial about Conservancy (we'd really appreciate it) We thank you in advance for your support -- especially during this giving time of the year! Best, -Tony

Dec. 5, 2014

Re: ws2_32/tests: Add SO_BSP_STATE tests

by Marvin

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=10633 Your paranoid android. === wxppro (32 bit sock) === sock.c:610: Test failed: oob_server (190): unexpectedly at the OOB mark: 0

Dec. 5, 2014

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.

by Marvin

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=10625 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

Dec. 5, 2014

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.

by Marvin

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=10623 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

Dec. 5, 2014

Re: [PATCH 5/9] d3d8/tests: Test WM_SYSCOMMAND handling.

by Marvin

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=10620 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2550: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2555: Test failed: The focus window is active. device.c:2563: Test failed: Got unexpected hr 0x88760869. device.c:2569: Test failed: Got unexpect screen size 800x600. device.c:2584: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2593: Test failed: Got unexpect screen size 800x600. device.c:2606: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2614: Test failed: Got unexpect width 640. device.c:2615: Test failed: Got unexpect height 480.

Dec. 4, 2014

Re: [PATCH 3/9] d3d8/tests: Test focus loss message filtering.

by Marvin

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=10618 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2524: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2529: Test failed: The focus window is active. device.c:2537: Test failed: Got unexpected hr 0x88760869. device.c:2543: Test failed: Got unexpect screen size 800x600. device.c:2558: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2567: Test failed: Got unexpect screen size 800x600. device.c:2580: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2587: Test failed: Got unexpect width 640. device.c:2588: Test failed: Got unexpect height 480.

Dec. 4, 2014

Re: ntdll: Adds support for custom serial port baudrates on Mac

by Nathan Fearnley

I've tried update the code to be a little more cleanly separated, and fixed the issue with BOOL. This code really just runs as an exception when a custom baudrate is requested. Otherwise, it pretty much shares the same code. If someone can suggest a better way to organize the code, I'd be happy to implement it. (Sorry for the duplicate email, Nikolay, I forgot to replay all at first) On 1 December 2014 at 02:21, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 11/29/2014 07:53 PM, Nathan Fearnley wrote: > >> Mac OS X supports a special function call for custom baud rates. I have >> implemented this feature to allow non-standard baud rates. >> Unfortunately, setting any other parameters using tcsetattr will fail, >> because it does not support the higher baud rates. In order to work >> around this, when setting other parameters, the baud rate is temporarily >> set to 9600, then reset back to custom rate after the changes are >> complete. >> >> >> > I can't comment on functional part, but regarding code structure this > should be better separated imho. Maybe it's even better to duplicate whole > functions and ifdef them all in case when __APPLE__ is not defined. Also > don't use C++ 'bool', use BOOL with TRUE/FALSE defines. > >

Dec. 4, 2014

Re: [PATCH] winealsa: do not destroy remapping info on IsFormatSupported

by Andrew Eikum

Good catch. I don't like the copying, though. What about making: struct alsa_channel_map { int alsa_channels; int map[32]; }; and passing that into map_channels()? need_remapping can be indicated by a S_FALSE vs S_OK return from map_channels(), or maybe set outside the call in _Initialize(). What do you think? Andrew On Thu, Dec 04, 2014 at 02:26:05PM +0000, Mark Harmstone wrote: > At present, AudioClient_IsFormatSupported nukes the remapping information > if called after AudioClient_Initialize. > > --- > dlls/winealsa.drv/mmdevdrv.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 007f351..3d14a53 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -1598,6 +1598,8 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > WAVEFORMATEX *closest = NULL; > unsigned int max = 0, min = 0; > int err; > + int alsa_channels_orig, alsa_channel_map_orig[32]; > + BOOL need_remapping_orig; > > TRACE("(%p)->(%x, %p, %p)\n", This, mode, fmt, out); > > @@ -1692,9 +1694,18 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > closest->nChannels = min; > } > > + need_remapping_orig = This->need_remapping; > + alsa_channels_orig = This->alsa_channels; > + memcpy(alsa_channel_map_orig, This->alsa_channel_map, sizeof(This->alsa_channel_map)); > + > if(FAILED(map_channels(This, fmt))){ > hr = AUDCLNT_E_DEVICE_INVALIDATED; > WARN("map_channels failed\n"); > + > + This->need_remapping = need_remapping_orig; > + This->alsa_channels = alsa_channels_orig; > + memcpy(This->alsa_channel_map, alsa_channel_map_orig, sizeof(This->alsa_channel_map)); > + > goto exit; > } > if(This->alsa_channels > max){ > @@ -1702,6 +1713,10 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface, > closest->nChannels = max; > } > > + This->need_remapping = need_remapping_orig; > + This->alsa_channels = alsa_channels_orig; > + memcpy(This->alsa_channel_map, alsa_channel_map_orig, sizeof(This->alsa_channel_map)); > + > if(closest->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > ((WAVEFORMATEXTENSIBLE*)closest)->dwChannelMask = get_channel_mask(closest->nChannels); > > >

Dec. 4, 2014

Re: [PATCH 6/8] ddraw/tests: Test WM_SYSCOMMAND handling.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/14 17:14, Marvin wrote: > === w8 (32 bit ddraw2) === > ddraw2.c:3814: Test failed: Expected WM_ACTIVATEAPP, but did not receive it. > > === w8 (32 bit ddraw4) === > ddraw4.c:4169: Test failed: Expected WM_ACTIVATEAPP, but did not receive it. This is a different test, and this is a pre-existing problem, at least on my XP machine. However, the affected test should use SetForegroundWindow instead of SetActiveWindow, which fixes the XP problem for me and will hopefully fix this issue on Windows 8 too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUgKuPAAoJEN0/YqbEcdMwmZUP/jMVj7na524A6HcIzPDdsKX8 smVbAD2Lod/oPab7JCVfLC2lwWAfbMYipGKvbQ0UgeGmdrnZ91/kURkDyic5Glwa mCXsHSWoxusbrZxrsqCRpEFjNH2ibc82Ex+vYXxc107+T6b8+wmXPvWgAep6/8m5 ggwnrIZzdapNjii08VCOFkdzl7f7N4fyMdA/ry9FdnCnqb6nmUZyQyxEqrTpauve 32I/sfBoBnwhbgGS8f4TOUS2WDFywdcD4OUPs3rhxWXdTVcJKSKfyd5S9AEGO82I dLxuf/WuzklCEm8DssYf7KCZuFlFq/nq7KTYdFzm6XW/RNb5w8WM8nu0HUw+neQn P7ugIoIeCXvDejIguTsNrA04myiQiFmz8K8lRc1oq2DakzoC+nW/yydAYlClPPzD o57Fr11rE9o51lUNHGpV+AUjP3VcMTH8QqeN7Jiq4uvPlIiAhfIVbJGqnCrzufbc eRGuCUcCITdgr38oehNtXAbQgv6jHqTBhYrQk7LYhxfPr7T8tE1dDh0u6sLixmzB fitWkMcSAuoSuuf3ZpReeLS/a+TxZiLXvdIdAbu7qjWOrpGCAtvzWYAEjyzAWZdw DlC8we6/VgC70zR3aOTaXsBEq0qtRLlMuqB3+vf/ztNXR0G/9dmipCJix+0ltiLi 5S61BCzcyfd8Oie36kPl =oHmc -----END PGP SIGNATURE-----

Dec. 4, 2014