- wine-devel - winehq.org

Re: [1/2] loader: FreeBSD requires pre_exec() on x86_64
by André Hentschel 03 Feb '15

03 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.02.2015 um 21:20 schrieb David Naylor: > Just as with i386, FreeBSD requires the maximum size of the data segment to be > extended on x86_64 for Wine to work correctly. > --- > loader/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/loader/main.c b/loader/main.c > index ac67290..bb4f949 100644 > --- a/loader/main.c > +++ b/loader/main.c > @@ -181,7 +181,7 @@ static int pre_exec(void) > return 1; /* we have a preloader on x86-64 */ > } > > -#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && defined(__i386__) > +#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && (defined(__i386__) || defined(__x86_64__)) > > static int pre_exec(void) > { > > > > This is already fixed for a while, see: https://www.winehq.org/wwn/383#Wine64%20on%20FreeBSD -> https://bugs.winehq.org/show_bug.cgi?id=34330 -> https://source.winehq.org/git/wine.git/blobdiff/036670810c7e8bf55a5ee0e71e3… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUz+qIAAoJEGm5GZTakYssKKEL/1kc5U/Um4TIfoIWFCZZoenL XhlZwjyJ90hJDicOZAHCKZxIcpu5J0fld52FIB5JunJZGSVcIXtcwmp1OwiA1BT4 5QPGR1WJ2bL4MU2lWw6+IEFZoL92Z7EsFkKjEM5l+u0l/APXp/5pq7Tj61qYvyoI HWhgauD7oWSK9PThWVdT7KiLmWFMLL5Rt3wB4coVExOhNah2jfGsJUDQUW08fX6B wKIB2r+O0h7xaR+zjnZSdB8iBqSTuCasUcaq0YcT8NccPQedlKJswnVu809Ygdg4 5PDn89Y1MGbSBIlcM8PjRtQrfU7bWLqOXmbY5bpaJbRbABz39UryrW0RleDTWC/G 8sJ3jtF7sO3YILQeFaaLUc0lyD64uGnwEoeGTJjB6n4khSVG5ZCsbn+twU6TwlT4 JYRfCNLgAv/fr9LnoI54HmBuyOscpP/1k9UO/6w2mQvugLe5k6TBQoiUMkk5le93 TbyOop4cFqHXR6DPfaIRuJ1czdrqVrZ1kZySKXubSg== =gd3v -----END PGP SIGNATURE-----

2 1

[2/2] Directx 11.2 idl's d3d11_2.idl
by Martell Malone 03 Feb '15

03 Feb '15

The second idl needed for dx11.2 function and structure compliance. Please review :)

1 1

Fwd: Add d3d11_CreateDeviceAndSwapChain
by Martell Malone 02 Feb '15

02 Feb '15

This is the explanation for the d3d11 patch I submitted to wine-patches. Stefan said Henri might have an interest so I should post the explanation here Comments are welcome :) ---------- Forwarded message ---------- From: Martell Malone <martellmalone(a)gmail.com> Date: Mon, Feb 2, 2015 at 7:12 PM Subject: Re: Add d3d11_CreateDeviceAndSwapChain To: Stefan Dösinger <stefandoesinger(a)gmail.com> Whoops that sent without my comments In the d3d code we use use 8 byte extran indentation for continued lines: > > void function() > { > <4> FIXME("bla long text bla\n", > <4> <8> param1, param2); > } > I have sent an updated patch to reflect this. I'm curious, does this improve the behavior of some application? E.g. game > X now falls back to d3d9 without crashing due to the stub? > My main focus for writing this was for the mingw-w64 project that imports the headers and libs from wine. We were just casually missing 1 of the 3 most important functions so I sent in this patch :) There are 2 ways to create a device and swapchain however. You can do them seperatly or this function does them both at once. I assume that this returns the correct error like CreateDevice so that if the application has a fallback it can use it. So thats highly possible. Kind Regards Martell On Mon, Feb 2, 2015 at 7:06 PM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi Stefan, > > On Mon, Feb 2, 2015 at 6:33 PM, Stefan Dösinger <stefandoesinger(a)gmail.com > > wrote: > >> Hi, >> >> I'm curious, does this improve the behavior of some application? E.g. >> game X now falls back to d3d9 without crashing due to the stub? >> >> > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, >> D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, >> > + const D3D_FEATURE_LEVEL >> *feature_levels, UINT levels, UINT sdk_version, >> > + const >> DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, >> > + ID3D11Device **device, >> D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) >> > +{ >> > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, >> feature_levels %p, levels %#x, sdk_version %d, " >> > + "swapchain_desc %p, swapchain %p, device %p, feature_level >> %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, >> > + flags, feature_levels, levels, sdk_version, swapchain_desc, >> swapchain, device, feature_level, context); >> > + return E_OUTOFMEMORY; >> sdk_version is an UINT, you need to print it with %u. >> >> In the d3d code we use use 8 byte extran indentation for continued lines: >> >> void function() >> { >> <4> FIXME("bla long text bla\n", >> <4> <8> param1, param2); >> } >> >> Cheers, >> Stefan >> >> >

1 0

Re: Add d3d11_CreateDeviceAndSwapChain
by Stefan Dösinger 02 Feb '15

02 Feb '15

Hi, I'm curious, does this improve the behavior of some application? E.g. game X now falls back to d3d9 without crashing due to the stub? > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, > + const D3D_FEATURE_LEVEL *feature_levels, UINT levels, UINT sdk_version, > + const DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, > + ID3D11Device **device, D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) > +{ > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, feature_levels %p, levels %#x, sdk_version %d, " > + "swapchain_desc %p, swapchain %p, device %p, feature_level %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, > + flags, feature_levels, levels, sdk_version, swapchain_desc, swapchain, device, feature_level, context); > + return E_OUTOFMEMORY; sdk_version is an UINT, you need to print it with %u. In the d3d code we use use 8 byte extran indentation for continued lines: void function() { <4> FIXME("bla long text bla\n", <4> <8> param1, param2); } Cheers, Stefan

1 0

D3d11 CreateDeviceAndSwapChain
by Martell Malone 01 Feb '15

01 Feb '15

Hi, I hope this is the right place to send this Jacek asked me to send d3d11 patches to wine and not mingw-w64 first. More will come so if this is the wrong place please correct me :) Kind Regards Martell

2 2

Re: [2/3] mciqtz32: "status mode" returns resource strings.
by Marvin 30 Jan '15

30 Jan '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=11379 Your paranoid android. === wxppro (32 bit mci) === mci.c:1287: Test failed: mci capability device type returned MCIERR_DEVICE_LOCKED

1 0

Re: League of Legends shop in game fix
by Austin English 30 Jan '15

30 Jan '15

On Thu, Jan 29, 2015 at 9:19 AM, Monster <manuiglesias96(a)yahoo.es> wrote: > @@ -220,7 +220,10 @@ BOOL wined3d_resource_allocate_sysmem(struct > wined3d_resource *resource) > SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); > void *mem; > - if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > resource->size + align))) > + UINT size = resource->size; > + if (resource->width <= 128 && resource->height <= 128) > + size *= 2; > + if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + > align))) > return FALSE; > p = (void **)(((ULONG_PTR)mem + align) & ~(RESOURCE_ALIGNMENT - 1)) - 1; > > > > Please use your real name when sending patches. -- -Austin

3 2

Re: [PATCH] winemac.drv: Always initialize a closure-captured object pointer.
by Ken Thomases 30 Jan '15

30 Jan '15

On Jan 29, 2015, at 5:23 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > You might argue that we don't need to do this because we only use it on > the control paths where we initialize it. Ah, but it *is* used on one of > the other paths: it is captured by the Block closure whether or not we > actually use it inside the Block. This means that, when we copy the > Block onto the heap in OnMainThreadAsync(), the runtime will attempt to > retain it. For some reason, we got away with this in 32-bit > land--probably because the pointer happened to be NULL anyway--but it > broke and died horribly on 64-bit. > > With this change, 64-bit winemac.drv is actually usable. Nice. I was aware of the warning but assumed that it was benign. I'm not sure it's a coincidence that it worked in 32-bit. I don't think that dispatch objects are actually automatically retained by blocks which reference them in 32-bit. It's not entirely related, but it's relatively recent that ARC started doing that and, of course, that requires the modern Objective-C runtime and thus 64-bit. Anyway, I'm glad the Mac driver crashiness in the 64-bit build stemmed from a single cause. I'm sure it wasn't fun to find it. Thanks for doing so. -Ken

1 0

Re: msvcrt: Bump MSVCRT_MB_LEN_MAX to 6 and use it in MSVCRT__wctomb_l for default buffer length
by Piotr Caban 29 Jan '15

29 Jan '15

On 01/23/15 18:38, Orion Poplawski wrote: > diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h > index 41f31b9..401628a 100644 > --- a/dlls/msvcrt/msvcrt.h > +++ b/dlls/msvcrt/msvcrt.h > @@ -47,7 +47,7 @@ > #define MSVCRT_I64_MAX (((__int64)0x7fffffff << 32) | 0xffffffff) > #define MSVCRT_I64_MIN (-MSVCRT_I64_MAX-1) > #define MSVCRT_UI64_MAX (((unsigned __int64)0xffffffff << 32) | 0xffffffff) > -#define MSVCRT_MB_LEN_MAX 2 > +#define MSVCRT_MB_LEN_MAX 6 MB_LEN_MAX equals 5 on windows. It should probably be set to 5 here as well. Probably include/msvcrt/limits.h should also be changed. Thanks, Piotr

2 2

Re: [PATCH 1/2] kernel32/tests: Make loader tests independent from each other
by Dmitry Timoshkov 28 Jan '15

28 Jan '15

> +const static IMAGE_NT_HEADERS nt_header_template = 'static const' is a commonly accepted order. There are various reasons of the current tests structure, if you are not planning to add new tests please leave the code as it is please. -- Dmitry.

2 4

Re: mshtml: Added support for _self target in IHTMLWindow2::open.
by Marvin 28 Jan '15

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

1 0

Re: msvcrt: Fix inconsistent rounding behaviour for sprintf and add tests.
by Piotr Caban 28 Jan '15

28 Jan '15

On 01/26/15 12:29, YongHao Hu wrote: > + if(flags.Precision >= 0 && toupper(flags.Format)!='G') { > + temp = pow(10, flags.Precision); > + val = round(val * temp) / temp; > + } This is not correct, val may loose to much precision. Also temp can become INF (in your patch temp is int but I guess it's a mistake). I'm afraid that in order to fix this bug you'll need to stop using glibcs sprintf in wine's printf implementation. Your patch to msvcp tests depends on this patch. Please send patches that depend on each other in series. Thanks, Piotr

2 1

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab
by Andrew Eikum 27 Jan '15

27 Jan '15

I think you can squash the last two patches. No need to add symbols before they're used. Does it make sense to have a "system default" configuration as well? For example if the user changes which device ALSA's "default" points to from a 5.1 setup to a stereo setup, the "system default" setting should report the configurations correctly (or, as correctly as the backend allows, but you get the point). This might require storing the user-selected speaker configuration elsewhere in the registry, and updating the real registry entry on mmdevapi load. Couple notes below. On Mon, Jan 26, 2015 at 10:28:26PM +0000, Mark Harmstone wrote: > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ > + i = 0; > + while (speaker_configs[i].text_id != 0 && info->speaker_config == 999) { > + if ((speaker_configs[i].speaker_mask & pv.u.ulVal) == speaker_configs[i].speaker_mask) > + info->speaker_config = i; > + i++; > + } > + } This is kind of awkward. Could be a for-loop and break early. > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) > + info->speaker_config = 2; > + Yeah, I don't like 999 either. The "system default" would provide a reasonable fallback option here, too. > + IPropertyStore_Release(ps); > + > return TRUE; > + for (i = 0; i < num_render_devs; i++) { > + ERR("%s -> %u\n", wine_dbgstr_w(render_devs[i].id), speaker_configs[render_devs[i].speaker_config].speaker_mask); Looks like a debug line that should be removed or switched to TRACE. > + pv.u.ulVal = speaker_configs[render_devs[i].speaker_config].speaker_mask; > + WARN("speaker_config = %u\n", pv.u.ulVal); Another debug line? > + > + hr = IPropertyStore_SetValue(ps, &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + if (FAILED(hr)) > + WARN("IPropertyStore_SetValue failed for %s: 0x%08x\n", wine_dbgstr_w(render_devs[i].id), hr); > + > + IPropertyStore_Commit(ps); This isn't actually implemented in mmdevapi, so we end up with noisy "stub" messages on the terminal. Best thing to do would be to fix the property store implementation, but in lieu of that, I'd just switch the FIXME in mmdevapi with a TRACE. Andrew

1 0

Re: shell32: Handle TRASH_EnumItems failures correctly
by Marvin 27 Jan '15

27 Jan '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=11318 Your paranoid android. === wvistau64 (32 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes === wvistau64 (64 bit recyclebin) === recyclebin.c:98: Test failed: Expected recycle bin to have 0x8 bytes

1 0

Re: [PATCH 3/3] winecfg: add speaker config controls to audio tab
by André Hentschel 26 Jan '15

26 Jan '15

Hi, first, this should be merged with patch 2. (atomic changes) Am 26.01.2015 um 23:28 schrieb Mark Harmstone: > - IPropertyStore_Release(ps); > if(FAILED(hr)){ > CoTaskMemFree(info->id); > info->id = NULL; > + IPropertyStore_Release(ps); > return FALSE; > } This looks like a independent atomic fix... > + hr = IPropertyStore_GetValue(ps, > + &PKEY_AudioEndpoint_PhysicalSpeakers, &pv); > + > + info->speaker_config = 999; > + if(SUCCEEDED(hr) && pv.vt == VT_UI4){ minor whitespace issue(s) and seen some more whitespace issues, no need to keep consistent with existing code here i'd say > + > + /* fallback to stereo */ > + if(info->speaker_config == 999) my thoughts on this: not sure, maybe -1 is better, or ~0. maybe it should be unsigned... I hope my thoughts help anyway

1 0

Re: [PATCH 2/2] mshtml: Report about protocol as UI resource.
by Alexandre Julliard 26 Jan '15

26 Jan '15

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/nsio.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) This is apparently causing the script.c test to hang here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] d3d/tests: Show that WM_SYSCOMMAND(SC_RESTORE) is delivered only once.
by Marvin 26 Jan '15

26 Jan '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=11305 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:2557: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2562: Test failed: The focus window is active. device.c:2570: Test failed: Got unexpected hr 0x88760869. device.c:2576: Test failed: Got unexpect screen size 800x600. device.c:2591: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2600: Test failed: Got unexpect screen size 800x600. device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2621: Test failed: Got unexpect width 640. device.c:2622: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 1/2] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc (v2).
by Marvin 26 Jan '15

26 Jan '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=11303 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.

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 5)
by Stefan Dösinger 26 Jan '15

26 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > +static void add_component(IDirectPlay8AddressImpl *This, struct component *item) > +{ > + if(!This->comp_count) > + This->components = HeapAlloc(GetProcessHeap(), 0, sizeof(struct component *) * This->comp_count+1 ); You can use your heap_alloc() helper here. The same applies to the HeapFree calls added in the patch. Other than that I think error handling would be a good idea. You can check for NULL (as well as in the place where you allocate storage for the component in AddComponent) and return from AddComponent with E_OUTOFMEMORY. The patch has a few formatting issues. Since it looks like dplay & friends will be mostly your reign I'll leave it up to you on how to handle formatting. Do you want me to continue pointing them out? In that case please send me a mail what your intended formatting is. (Obviously it'd be even better if you described your intended formatting to git in the form of a git pre-commit hook containing some regexes ;-) ). Other than this the patch looks good. The following is unrelated to this patch, I just noticed it (again?) while reading through it: Am 2015-01-23 um 08:10 schrieb Alistair Leslie-Hughes: > + case DPNA_DATATYPE_STRING: > + memcpy(pvBuffer, &entry->data.string, entry->size); > + break; Please add a test for a case where AddComponent is called with DPNA_DATATYPE_STRING where (strlen(string) + 1) * sizeof(WCHAR) != dwDataSize. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUxS4iAAoJEN0/YqbEcdMwvFkP/RF6kH1o1C4fQgfa/J+4j6zV kwp3M7rqU5VTasKYV+G0pdAQ+wvBzHpMPSqLRD/HfBWGf3dAPCk94C9d659enkJN Qhy7hhO6aazsXKq7iWVAgQrGJy59oBoL14Vg+44hUJIeu7qWv3uuqihVgKUqiG2K Bl235p9cM/WYLGXFEF4d1UFHBKZb0bhRudwuzRbuN8r3RLwpEhrKbbKg8yXOPjLq Vejc4d219iib3ZpbT13pq0j/+a+ox+R62+O9S5wGbu/G8IGxVPTgsY20mpFyPsHX DoedE56wfSSe5Psb78NVmC32bWY8nmUzJA9YBb26a0KPO9QZNVnJkkYkOKIFr6P/ ouVLfWbO4QV2dOPRbYnh+40XCIbPeatGMq9vE7TDZPtxLBkRTEl1GudZ5usFwCK7 XgTPjb+BIu37UCbt0hpWA4IH8UeyYue08DnGCWkMkGS6ClH9KCG2xVqL8F1gr8Bw W5iKcVVHFZzHS6D947nN17Fl6Rg4+oLui0zkgtveU/AY/ew8xptHt4rW6It3QU5t HkNce4St+2w1LErIuYRITrvQV6lrndDDgvvlPcK1P1zt2D1a9gpqnsPgKM/tZLu+ fO8P8Yjl81KZHlAVWMUutiDzlelUOJvaXnVNX5VVkyOajHDI569MKy4qOETSdiim gwulxslghTkPCsAa+LpB =iY0u -----END PGP SIGNATURE-----

1 1

Re: [PATCH 5/5] atl100/tests: Added initial interface tests for AtlAxAttachControl.
by Qian Hong 26 Jan '15

26 Jan '15

Please ignore this patch, I'm working on an improved version. On Fri, Jan 23, 2015 at 5:21 PM, Qian Hong <qhong(a)codeweavers.com> wrote: > Test cases based on dlls/mshtml/tests/activex.c, thanks Jacek Caban for the > previous work. > > --- > dlls/atl100/tests/Makefile.in | 2 +- > dlls/atl100/tests/atl.c | 446 > ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 447 insertions(+), 1 deletion(-) > > > > > -- Regards, Qian Hong - http://www.codeweavers.com

1 0

Re: [3/3] cmd: implemented && and || functionality (try 2)
by Marvin 24 Jan '15

24 Jan '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=11295 Your paranoid android. === build (build) === Patch failed to apply

1 0

Wine 1.7.35 source code scanning (Cppcheck)
by Игорь Чебаненко 24 Jan '15

24 Jan '15

1 0

Re: [PATCH 3/5] atl: Added stub AtlIPersistPropertyBag_Save.
by Jacek Caban 23 Jan '15

23 Jan '15

On 01/23/15 10:18, Qian Hong wrote: > +HRESULT WINAPI AtlIPersistPropertyBag_Save(LPPROPERTYBAG pPropBag, BOOL fClearDirty, BOOL fSaveAllProperties, > + ATL_PROPMAP_ENTRY *pMap, void *pThis, IUnknown *pUnk) > +{ > + > + FIXME("(%p, %x, %x, %p, %p, %p)\n", pPropBag, fClearDirty, fSaveAllProperties, pMap, pThis, pUnk); > + return S_OK; > +} It's a minor detail, but after two patches in series removing unnecessary empty lines, you add a new one here ;) Cheers, Jacek

2 1

Re: [PATCH 4/5] atl100: Implemented semi stub AtlAxCreateControlLic and AtlAxCreateControlLicEx.
by Jacek Caban 23 Jan '15

23 Jan '15

Hi Qian, On 01/23/15 10:19, Qian Hong wrote: > diff --git a/dlls/atl/atl_ax.c b/dlls/atl/atl_ax.c > index 15b0550..656165b 100644 > --- a/dlls/atl/atl_ax.c > +++ b/dlls/atl/atl_ax.c > @@ -1435,8 +1435,9 @@ INT_PTR WINAPI AtlAxDialogBoxA(HINSTANCE hInstance, LPCSTR lpTemplateName, HWND > */ > HRESULT WINAPI AtlAxCreateControlLic(const WCHAR *lpTricsData, HWND hwnd, IStream *stream, IUnknown **container, BSTR lic) > { > - FIXME("(%s %p %p %p %s)\n", debugstr_w(lpTricsData), hwnd, stream, container, debugstr_w(lic)); > - return E_NOTIMPL; > + if (lic) > + FIXME("semi stub (%s %p %p %p %s)\n", debugstr_w(lpTricsData), hwnd, stream, container, debugstr_w(lic)); > + return AtlAxCreateControl(lpTricsData, hwnd, stream, container); > } > > /*********************************************************************** > @@ -1446,9 +1447,10 @@ HRESULT WINAPI AtlAxCreateControlLic(const WCHAR *lpTricsData, HWND hwnd, IStrea > HRESULT WINAPI AtlAxCreateControlLicEx(const WCHAR *lpTricsData, HWND hwnd, IStream *stream, > IUnknown **container, IUnknown **control, REFIID iidSink, IUnknown *punkSink, BSTR lic) > { > - FIXME("(%s %p %p %p %p %s %p %s)\n", debugstr_w(lpTricsData), hwnd, stream, container, control, > + if (lic) > + FIXME("semi stub (%s %p %p %p %p %s %p %s)\n", debugstr_w(lpTricsData), hwnd, stream, container, control, > debugstr_guid(iidSink), punkSink, debugstr_w(lic)); > - return E_NOTIMPL; > + return AtlAxCreateControlEx(lpTricsData, hwnd, stream, container, control, iidSink, punkSink); > } > > #endif Please forward AtlAxCreateControlEx to AtlAxCreateControlLicEx and add FIXME about unsupported argument instead of the other way around. Otherwise we'd have to do that later to support the argument anyway. Also AtlAxCreateControlLic would probably be better forwarded to AtlAxCreateControlLicEx. Cheers, Jacek

2 1

Re: [PATCH 5/5] wined3d: Use the core version of the shader object functions.
by Henri Verbeet 23 Jan '15

23 Jan '15

On 21 January 2015 at 18:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + typedef void (WINE_GLAPI *gl_shader_source_type)(GLuint, GLsizei, const GLchar * const *, const GLint*); > + ... > + #define MAP_GL_FUNCTION_CAST(core_func, cast, ext_func) \ > + do \ > + { \ > + if (!gl_info->gl_ops.ext.p_##core_func) \ > + gl_info->gl_ops.ext.p_##core_func = (cast)gl_info->gl_ops.ext.p_##ext_func; \ > + } while (0) ... > + MAP_GL_FUNCTION_CAST(glShaderSource, gl_shader_source_type, glShaderSourceARB); I'm not sure that's really much better than just adding a (void *) cast.

3 4

Re: shell32: Implement IApplicationAssociationRegistration, QueryCurrentDefault (try 6)
by Nikolay Sivov 23 Jan '15

23 Jan '15

On 23.01.2015 10:24, Alistair Leslie-Hughes wrote: > + ret = RegGetValueW(hkey, NULL, NULL, RRF_RT_REG_SZ, &keytype, NULL, &size); > + if(ret == ERROR_SUCCESS) > + { > + *association = CoTaskMemAlloc(size * sizeof(WCHAR)); Does it really return length in characters? I thought it's always in bytes. > + if(*association) > + { > + ret = RegGetValueW(hkey, NULL, NULL, RRF_RT_REG_SZ, &keytype, *association, &size); > + if(ret == ERROR_SUCCESS) > + hr = S_OK; > + } > + } In case of !*association please return earlier with E_OUTOFMEMORY.

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 5)
by Marvin 23 Jan '15

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

1 0

Re: WineHQ zh_CN Translation Patch Up
by Bruno Jesus 22 Jan '15

22 Jan '15

On Thu, Jan 22, 2015 at 2:10 PM, Jeff Bai <jeffbaichina(a)gmail.com> wrote: > Hello fellow developers > > Here is a copy of the patch of changed zh_CN localization from AOSC (Anthon > Open Source Community) L10n project. We've fixed the msgid width problem > which was addressed last time. The patch is large so we put this on our > public PasteBin site, as follows > > https://pastebin.anthonos.org/view/a0c1c1a3 > > Please mail back with any issue over this patch. Hi, please send the email again with the patch as an attachment and I think a more proper subject would be: po: Update Simplified Chinese translation > Keep up the good work! > > Jeff Bai > AOSC Best regards, Bruno

1 0

Re: WineHQ zh_CN Translation Patch Up
by Alex Henrie 22 Jan '15

22 Jan '15

Jeff, The best way to submit patches is with `git format-patch` and `git send-email`. It looks like Alexandre won't accept patches submitted via pastebin. -Alex

1 0

Re: ws2_32: Better trace setsockopt/getsockopt
by Bruno Jesus 22 Jan '15

22 Jan '15

On Tue, Jan 6, 2015 at 12:49 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > The intention of this patch is to make it easier to read winsock logs, > for setsockopt it even displays the value if its size is less than 5 > bytes. Hi, any complains about this patch? It's pending for 2 weeks now and I think this is a good waiting time to ask. Best Regards, Bruno

2 1

Re: [PATCH 3/5] wined3d: Initialize the last two components of R16G16_SINT attributes.
by Henri Verbeet 22 Jan '15

22 Jan '15

On 21 January 2015 at 18:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - GL_EXTCALL(glVertexAttrib4svARB(index, ptr)); > + { > + GLshort s[4] = {((const GLshort *)ptr)[0], ((const GLshort *)ptr)[1], 0, 1}; > + GL_EXTCALL(glVertexAttrib4svARB(index, s)); > break; > + } Perhaps I'm missing something, but wouldn't it be much easier to just use glVertexAttrib2svARB() instead?

1 0

Re: [PATCH 6/6] kernel32: Invalid console handles for new processes are 0, not INVALID_HANDLE_VALUE.
by Alistair Leslie-Hughes 21 Jan '15

21 Jan '15

On 21/01/15 08:51, Erich E. Hoover wrote: > Several applications rely on the TEB value for fresh invalid console > handles to be zero instead of INVALID_HANDLE_VALUE (fixes Bug #36216 > and Bug #37914). > > +····if·(!params->hStdOutput·||·params->hStdOutput·==·INVALID_HANDLE_VALUE) > +········params->hStdOutput·=·0; The !params->hStdOutput check is redundant since it's already 0. Applies to the other places as well. Best Regards Alistair Leslie-Hughes

2 1

Wine Gecko 2.36-beta1
by Jacek Caban 21 Jan '15

21 Jan '15

Hi all, I just uploaded new Wine Gecko beta packages. This time it's based on Firefox 36 beta branch, so it should be pretty stable. To test it please use the attached patch. That's all you need, Wine will download Gecko automatically. Packages are also available on Wine SourceForge if you prefer to download it manually. All testing is appreciated. Regressions and build problems are most important, but all feedback is welcomed. I'm also sending this announcement mingw-w64 mailing list. I know that some distro package maintainers that maintain Wine Gecko packages read it. Beta releases are a good chance to make sure that it builds with toolchains available in distros. Note that the package requires very recent mingw-w64 Git version. A new release on mingw-w64 is planned, so hopefully it will be out before final Wine Gecko release (which is expected in 5-6 weeks). Thanks, Jacek

1 0

Re: msi: Add a partial implementation of MsiProvideComponent.
by Marvin 21 Jan '15

21 Jan '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=11245 Your paranoid android. === wxppro (32 bit msi) === The test timed out === w7u (32 bit msi) === The test timed out

1 0

Re: msxml3/tests: Actually test the return values (PVS-Studio)
by Michael Stefaniuc 21 Jan '15

21 Jan '15

Please ignore, wrong resend. On 01/21/2015 10:48 AM, Michael Stefaniuc wrote: > --- > dlls/msxml3/tests/domdoc.c | 1 + > dlls/msxml3/tests/schema.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > index a23fb66..e669de4 100644 > --- a/dlls/msxml3/tests/domdoc.c > +++ b/dlls/msxml3/tests/domdoc.c > @@ -11085,6 +11085,7 @@ static void test_xmlns_attribute(void) > V_VT(&v) = VT_BSTR; > V_BSTR(&v) = _bstr_("urn:schemas-microsoft-com:datatypes"); > hr = IXMLDOMAttribute_put_nodeValue(pAttribute, v); > + ok(hr == S_OK, "ret %08x\n", hr ); > > hr = IXMLDOMElement_setAttributeNode(root, pAttribute, NULL); > ok(hr == S_OK, "ret %08x\n", hr ); > diff --git a/dlls/msxml3/tests/schema.c b/dlls/msxml3/tests/schema.c > index f5d6fcd..be18fcf 100644 > --- a/dlls/msxml3/tests/schema.c > +++ b/dlls/msxml3/tests/schema.c > @@ -1292,6 +1292,7 @@ static void test_XDR_datatypes(void) > > VariantClear(&type); > hr = IXMLDOMNode_get_nodeTypedValue(node, &type); > + EXPECT_HR(hr, S_OK); > ok(V_VT(&type) == VT_BSTR, "got variant type %i\n", V_VT(&v)); > VariantClear(&type); > IXMLDOMNode_Release(node); >

1 0

Re: msxml3/tests: Remove an unused assignment (PVS-Studio)
by Michael Stefaniuc 21 Jan '15

21 Jan '15

*SIGH* please ignore this one as this is already commited. Pushed out the wrong mailbox. On 01/21/2015 10:43 AM, Michael Stefaniuc wrote: > --- dlls/msxml3/tests/domdoc.c | 1 - 1 file changed, 1 deletion(-) > > diff --git a/dlls/msxml3/tests/domdoc.c > b/dlls/msxml3/tests/domdoc.c index 1a73771..a23fb66 100644 --- > a/dlls/msxml3/tests/domdoc.c +++ b/dlls/msxml3/tests/domdoc.c @@ > -4903,7 +4903,6 @@ static void test_xmlTypes(void) > > doc = create_document(&IID_IXMLDOMDocument); > > - pNextChild = (void*)0xdeadbeef; hr = > IXMLDOMDocument_get_nextSibling(doc, NULL); ok(hr == E_INVALIDARG, > "ret %08x\n", hr );

1 0

Re: msxml3/tests: Actually test the return values (PVS-Studio)
by Marvin 21 Jan '15

21 Jan '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=11239 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: msxml3/tests: Remove an unused assignment (PVS-Studio)
by Marvin 21 Jan '15

21 Jan '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=11238 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: user32/tests: Don't test function directly when reporting GetLastError()
by Marvin 21 Jan '15

21 Jan '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=11234 Your paranoid android. === w7u (32 bit msg) === msg.c:12108: Test failed: unexpected hwnd 0014013C

1 0

About Patch 108345 Pending ( gdiplus: fix get_clip_hrgn when window origin point changed (try 2) )
by Changhui Liu 19 Jan '15

19 Jan '15

Hi, all, I reviewed this path http://source.winehq.org/patches/data/108345, I only found a code style problem: this: + if ( status == Ok && graphics->hdc)should :+ if (status == Ok && graphics->hdc) Could you help me point out the other mistake ? Thanks . ------------------ Regards, Changhui.

2 1

Re: gdi32: Do not enumerate fonts with names that are too long
by Dmitry Timoshkov 19 Jan '15

19 Jan '15

Aric Stewart <aric(a)codeweavers.com> wrote: > Both the FullName and the FamilyName need to fit in the LOGFONT > structure. What happens with such a font under Windows? I'd expect the name be simply truncated instead of the font being skipped. In the latter case the font should not be added to the list at all. -- Dmitry.

2 1

Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.
by Henri Verbeet 19 Jan '15

19 Jan '15

On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > We may want to consider moving mode changes, window setup and focus loss > handling into the client libs. With this patch and the next one we have > 3 wined3d flags just for focus loss handling. Furthermore, dxgi yet > again has different behavior - it doesn't hook the window procedure and Yeah, possibly, although I'd also like to keep the amount of Win32 specific stuff in the public wined3d API to a minimum, so I'd rather not have the client libs e.g. handle window messages directly. > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index ae6600e..89ec00a 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4961,7 +4961,7 @@ void device_invalidate_state(const struct wined3d_device *device, DWORD state) > LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL unicode, > UINT message, WPARAM wparam, LPARAM lparam, WNDPROC proc) > { > - if (device->filter_messages) > + if (device->filter_messages && message != WM_DISPLAYCHANGE) That seems pretty specific. I'd be curious how other broadcast messages are handled.

2 2

Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
by Henri Verbeet 19 Jan '15

19 Jan '15

On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 89ec00a..51dabd4 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4992,6 +4992,16 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL > > device->device_parent->ops->activate(device->device_parent, wparam); > } > + else if (message == WM_SYSCOMMAND) > + { > + if (wparam == SC_RESTORE && !(device->wined3d->flags & WINED3D_NO_SYSCOMMAND_HANDLING)) I'm not really a fan of this kind of double negative. The way the flag is used, it also seems to be about restores in particular instead of syscommands in general. > + { > + if (unicode) > + DefWindowProcW(window, message, wparam, lparam); > + else > + DefWindowProcA(window, message, wparam, lparam); > + } > + } > > if (unicode) > return CallWindowProcW(proc, window, message, wparam, lparam); Is this really how it's supposed to work? In particular, should DefWindowProc really always get the message before the application does, or should we give the application a chance first, and only pass to DefWindowProc if it doesn't handle the message?

2 2

Re: [PATCH 2/5] wined3d: Handle the SM4 SV_POSITION pixel shader input semantic in the GLSL shader backend.
by Stefan Dösinger 19 Jan '15

19 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-19 um 13:44 schrieb Henri Verbeet: > This is (mostly) equivalent to the vPos register in SM3. > ... > + if (!strcmp(semantic_name, "SV_POSITION")) > + shader_addline(buffer, "ps_in[%u]%s = vpos%s;\n", > + shader->u.ps.input_reg_map[i], reg_mask, reg_mask); The vpos variable has the d3d9 0.5 pixel offset applied, which to my knowledge is not correct for d3d10. Is this intentional? (I guess yes, either for simplicity to make patch 3 work and / or because we're still adding the offset on the vertex side even in d3d10.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUvQcWAAoJEN0/YqbEcdMwutkP/irVdyJWjIwnAnwgltjehO9A Vp4CZneYnbnAP/SJjhvsY7RwhHdUelzhv8wX8m9q0Y92jPMtvTt6OMAdppxATSOY Bo70j7fpaMJbRG/GCrDSCp3geyzN/1p6CQu5JfahVuSBOGg7EIDdR0OA4hA9aDEE R/pzerlOuvIY8vMOejYk99wBWEOLWJUcWNfrRq30ASnyIK6wcBhr3QLdcRI8/57m +MtFG53+R6wGdRQih1PfmDP4CJnfhr33TQgKod9ezYGyNcS8X/rRTq3mE0uqq3TJ 7+S4A21o7j2nEBlEWlwt6op7Yg2xhMan5znQU/MwREFaGGPWdapNpl1NxpWM/wp0 zm992j3TgpCqHLCW0u8Z5t2fClWuyU8IcZWsLql2FVZa3DvG6QOeXS3oEVlw5jxu fU9iMiJeh7Aywt8tvro4kG5opA2CCUFUJu1Cf7FBQpAUtHYqY5B1vm67fzeMfLt5 C2XC6L79dK0L0YenFqrGWQOU5/u4skW5Cgi5Yt5AKx0Ifk4gTrPq1/pSCeEFUS+T H2ZjZCqCYYp7NCWSXQSpBSFcVE7bURfJNBC3j9TTBCoT/pCOTKr8vv6Dqn0pjxku 6hdmAEaW7vUKr6ucUopgDNQ6E+aCdaofUMqJuhlOAOL8arthwIPZbO2hb8lLTSBq Smb3+zJL2d2YBZZelE4f =0cAR -----END PGP SIGNATURE-----

2 1

ole32:fix CoWaitForMultipleHandles cause RPC hang (try 2)
by Changhui Liu 19 Jan '15

19 Jan '15

Dear Sebastian: I commit a new ole32 path last month at here: http://source.winehq.org/patches/data/108302. Could you help me review it again when you are free? Thank you. ------------------ Regards, Changhui.

1 0

Re: [PATCH (try 3) 2/2] dpvoice: Turn GetCompressionTypes into a semi-stub.
by Stefan Dösinger 18 Jan '15

18 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-16 um 08:44 schrieb Alex Henrie: > Star Trek Armada II needs GetCompressionTypes to return at least > one value, see https://bugs.winehq.org/show_bug.cgi?id=29238 Is the game happy if you return DV_OK and set *pdwNumElements = 0? > MS-PCM is guaranteed to be present on Windows XP, and it's already > implemented in Wine, so advertising this codec shouldn't cause any > trouble. Even though we have the codec we probably don't have the dpvoice infrastructure to hook up a dpvoice client to the codec, right? That's not necessarily a reason to reject the semi-stub though. > +extern HRESULT DPVOICE_GetCompressionTypes(DVCOMPRESSIONINFO > *pData, DWORD *pdwDataSize, DWORD *pdwNumElements, DWORD dwFlags) > DECLSPEC_HIDDEN; Please avoid hungarian notation names (dwThisIsAdWord, *pThisIsAPointer). > + string_loc = (LPWSTR)((char*)pData + sizeof(pcm_type)); + > memcpy(pData, &pcm_type, sizeof(pcm_type)); + memcpy(string_loc, > pcm_name, sizeof(pcm_name)); + pData->lpszName = string_loc; I think there should be a nicer way to do this. I didn't test this with the compiler, but I guess you can do something like this: struct { DVCOMPRESSIONINFO info; const WCHAR name[]; } codec = { {80, {0x8de12fd4,0x7cb3,0x48ce {0xa7,0xe8,0x9c,0x47,0xa2,0x2e,0x8a,0xc5}}, &codec.name, NULL, 0, 64000}}, {'M','S','-','P','C','M',' ','6','4',' ','k','b','i','t','/','s',0}; }; ... memcpy(pData, codec, sizeof(codec)); I don't know how well the variable-size array at the end of the struct works. It also won't easily work for more than one element. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUuUN7AAoJEN0/YqbEcdMwFwcP/iSIxX72VcW9TSqbWHnq1Pi6 7Yv9zcL3h/3Mx0rERFiaT15Tmz7+YNyKfngR6kZwM7ms5usqePHCW1y1dT7ImCfM gSAgd5WBTKuk5qpr0k2zLgl4O3TVJn4zTP8wKNa+lwGDJgY7d3ThcgDd/LI6kkiU KI2Uv+jyh00Co2G6egmhlZDfwWo3dI/b+7fndC1jnYCcyIIxjLywdiQ80SCi3IgB sktBaQW7mvzzQDtMKgwR/BNUSze6AQeWQ5+xmWivIm4jsPGETmr3r0VnRtxxMduA LzXJJewnGojJoaQ1dsjsXJJ+S+3rKCd5cKrbnlyFXJ2pqHGrBdkQwbFTWse+8Tsf +Au00otO85InuwenrvKutN92c4pP8hfyxAQbKJUjVCnD5ppMDXkRrx0xKfAy7SWB FpQuO6KLeWMotDYcC21kwY3jGLAxKOWGh02p7S5AUIlnZ0m1kJ3PK1DxhomRHYax 4pgQx0jb/MITw1/L5hJ8KlNcucLJxC2FBGpgRC32LAUHMVcNurs6bHQbgbl9UKUS zH4gOA7PzNTGG3G3To/IqmayhmzNMLk/b0XusIGKF1Ao3uyU3Yw+5RuzPlGaKOkT cAhRIl5Ujbcjt8JKgtdq4x1VeGMutHlePhPuUpgZX98n+/Bgk9uZ5rScVLW1ELGW XQ6zfKUWW2qirySBqy+A =StHs -----END PGP SIGNATURE-----

2 4

Re: [2/3] msi: Open 32-bit component registry keys with KEY_WOW64_32KEY flag. (try 2)
by Marvin 18 Jan '15

18 Jan '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=11200 Your paranoid android. === wxppro (32 bit install) === The test timed out

1 0

Re: user32: Allocate memory based on HICON instead of DWORD to fix 64 bit problems
by Stefan Dösinger 18 Jan '15

18 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-17 um 23:51 schrieb Bruno Jesus: > - frames = HeapAlloc( GetProcessHeap(), 0, sizeof(DWORD)*header.num_frames ); > + frames = HeapAlloc( GetProcessHeap(), 0, sizeof(HICON)*header.num_frames ); sizeof(*frames)*header.num_frames would be better. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUu45mAAoJEN0/YqbEcdMwtrkP/2a+96GGXGtHq4g8P+UYBWjc AxGPcxAq5ND++lDYK22TyY1XC5ZXjByvxYOcrMsb4yhYRfJbPVgKx6gY+ALe6aog ilAFF0waM7kRPxXcNotcE9ZlXQpKAfLvTQajJSH9e1MgYUfcMbaSS8eSJMSNslcM Sa9rDDaeabp6wNymbvKOtpTjIOS767Jz9m7xCw+NtA9FFIHwrZsZ/LxeWiDQxDmR STNGPoEELt+vvAPB0K2Rnn/5AZrjekdYy0cUR78htsEqGIodBO86kD6K20r3cQ5s 7cmiAj8lHtUJ/6FPB54DynmSpNiPiXOlPc0dSL+ujsEEGJ/rI8wFtM/kCIzEe6GY 6sv881G8mXX8AMDgOg+O3Tlo0qprfWvVmkTE5ASGXGsdck04yPO4UfKvOon3IaXI dyrjRkBK8w2X63L5R39BzmKvtcZgKQj+r4M8is8Rn4hk2iAmz4ejFYlzcDVCJ0Zg W/kurjSSroUcOKsjcjMuB738W43mgHhh9xdbO/06FOYXULXOQVDFO7x19NI2ilpi VK5x6XRg4OxARuFU6tuSqll1a9PtNgIuzWc+BHDOS9Htc5WVpDTQvPUPtVif/6L/ 6MZbDeC9rm+IAytmXvpFDU+C6c2/axUMCfwB9idAKFaTKI5nemKLCeEPLiq1nVUh 5xulwJdbSnxoi7M72Vf6 =Tg70 -----END PGP SIGNATURE-----

1 0

Re: [PATCH (try 3) 2/2] dpvoice: Turn GetCompressionTypes into a semi-stub.
by Stefan Dösinger 16 Jan '15

16 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-16 um 08:44 schrieb Alex Henrie: > Star Trek Armada II needs GetCompressionTypes to return at least > one value, see https://bugs.winehq.org/show_bug.cgi?id=29238 Is the game happy if you return DV_OK and set *pdwNumElements = 0? > MS-PCM is guaranteed to be present on Windows XP, and it's already > implemented in Wine, so advertising this codec shouldn't cause any > trouble. Even though we have the codec we probably don't have the dpvoice infrastructure to hook up a dpvoice client to the codec, right? That's not necessarily a reason to reject the semi-stub though. > +extern HRESULT DPVOICE_GetCompressionTypes(DVCOMPRESSIONINFO > *pData, DWORD *pdwDataSize, DWORD *pdwNumElements, DWORD dwFlags) > DECLSPEC_HIDDEN; Please avoid hungarian notation names (dwThisIsAdWord, *pThisIsAPointer). > + string_loc = (LPWSTR)((char*)pData + sizeof(pcm_type)); + > memcpy(pData, &pcm_type, sizeof(pcm_type)); + memcpy(string_loc, > pcm_name, sizeof(pcm_name)); + pData->lpszName = string_loc; I think there should be a nicer way to do this. I didn't test this with the compiler, but I guess you can do something like this: struct { DVCOMPRESSIONINFO info; const WCHAR name[]; } codec = { {80, {0x8de12fd4,0x7cb3,0x48ce {0xa7,0xe8,0x9c,0x47,0xa2,0x2e,0x8a,0xc5}}, &codec.name, NULL, 0, 64000}}, {'M','S','-','P','C','M',' ','6','4',' ','k','b','i','t','/','s',0}; }; ... memcpy(pData, codec, sizeof(codec)); I don't know how well the variable-size array at the end of the struct works. It also won't easily work for more than one element. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUuUNyAAoJEN0/YqbEcdMwb/wP/3QuWJc0dQtO7tcPo/alre6S ASLeDH+5+F+LBTwFBnlNJhkizO7PtpRUCqH6k0fxGtSprsNMnyu3T/KqBPTku8kx XUhS4jNcV6lDzSvruKEHx4m+Lrpgs/onSK4pLUa9cP0FvZgKpLA+XTJtXgOuX40K 31/TOW/DRq6gXeGE11Oxz97Vx2mILfhmLfhtIeTRA4RpkGyMlWlKST9l3xyNn0dt ystZG62OWVnljq/g2U8Ce4n+zz97Hlxzkk7uB4ZI2/m8/EBdGEhOgGTsUdEulu6P cChWJqzJOo8zxJr+RXeWnQN38V2yKW6CwxnIQ90INKd1WV1NvGZfiYDMXdUBMrYm XrQ4A6xaLwfCIVgzJ1wyPDGYFb92sOr34ly3v/fTuQNb2DnamdgENhw/Gj9APsIS ErfHiTgoWGbh77WuRm2GC/GfxpOsK2lpnO2uwXcrWXyYy8u2GP9zEhHLl3ohcG2+ dEL7Q0MABEitbGQJ4qTbpNffFIbLwWdKcKEP67gBFM2T937/4z5ISce0WlI6SBHX l+yXKK/vSJ1U+/B2i+fsbyFOr0rQMCIt1k6uAOlnPM29uwZOjJtG3gCp6BbK+vqw Jc2yGJl3PdAjwfHuHGTakWx6EflZLLGqqcLXWnfs3gzgExHnbHGZaOdKDYx+qsqz cEUAmwJUxAcp6cMGiuQX =ue9K -----END PGP SIGNATURE-----

1 0

Re: [PATCH (try 2) 1/2] dpvoice/tests: Add GetCompressionTypes tests.
by Stefan Dösinger 16 Jan '15

16 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-15 um 12:55 schrieb Alex Henrie: > + DVCOMPRESSIONINFO data[32]; I can't really find any documentation about this. Is there a documented maximum number of elements returned? > + int i, j; Afaics you can make those unsigned. > + LPWSTR string_loc; Is the use of the LPFOO type intentional? > + if(GetCompressionTypes(iface, NULL, NULL, NULL, 0) == E_NOTIMPL) > + { > + skip("%s: GetCompressionTypes not implemented\n", name); > + return; > + } I think todo_wine ok(0, "GetCompressionTypes not implemented") is better here, but I don't particularly mind since you remove it in the next patch anyway. > + ok(data_size > sizeof(DVCOMPRESSIONINFO) && data_size < sizeof(data) - 1, > + "%s: tests[%i]: expected data_size between %i and %i got data_size=%i\n", > + name, i, sizeof(DVCOMPRESSIONINFO), sizeof(data) - 1, data_size); data_size is unsigned, you should use %u instead of %i. Same for i and j once you change them to unsigned. > + string_loc = (LPWSTR)((char*)data + num_elements * sizeof(DVCOMPRESSIONINFO)); It's interesting that native places the string in the same data blob, but it kinda makes sense. I think (WCHAR *)(data + num_elements) or (WCHAR *)&data[num_elements] should work as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUt7l0AAoJEN0/YqbEcdMwf/sQAIGsh8jbGM7AsbdeHt5uEJUD AGGg9OcqrDnW0PoCd5w36G70tNF/NFMRleNJ0tOL4r3HG8TD16BDXCkxW/U9hR7G 6c+DGAqnOFG0y6CjSAMGSvRh5VZVrD5OlI4XRTNFqYdL1QkVD0yQ/kXQl8YsvMUu x/sWJ1kF4FCcojmmhIP5tSo6AmZJlso18tlOReCBBnHDkdq+0ej8ltR/pG0NmZUp 3eOdSfyHd0Swc9P8nLossRKbieORr88fE0ZUBP7oOtg2JbLfs3l/F4fudbPoMF8v 5JbJXD+KuHdNvGYBJ2ppHEZCUC2ArHEYgMW0m2ffRoWfoXmrJCUE8AnJsyHsjaYI LFRiRGom7kRjoY8fhbTSJWdNTKLbW5swAiCzW7A+NkQvrXn5dcL2kZVpi2Z4x1gu 1JKYmb5G9G6SG+U4wblTWET4RWv5rAzoNeXvDZtznBW/KinnkNX2Ic7kug1/usqj ATJ9q8ARt+3DMPYRonk7sXzFdyRRXhlCROlBvqHBkPitVz3tLxvziB/4C1SZ9ybu wy28DMfEYfwbi/9iQnaHsn+811d7uf85QkKgiV6CBvS8XJ2xVzvHWnSWlbc0wNj1 /Gy5gCuKkluFWbJJjAliAf6+uHIypvBbFr85/Gn3gQy/tNUOH4FFSXPB18XrBXh3 CFH+vOFS/SN8fEA6WOtw =EJNM -----END PGP SIGNATURE-----

2 2

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