wine-devel October 2014

wine-devel@winehq.org

52 participants
183 discussions

Re: [PATCH 1/6] reg: Sanitize key paths in main
by Stefan Dösinger 29 Oct '14

29 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch is a lot more readable than the past version IMO. I'll look at the other patches tomorrow. Am 2014-10-27 13:10, schrieb Jonathan Vollebregt: > +static WCHAR *sanitize_path(WCHAR *key){ Inconsistent curly bracket placement. The other patches have more cases of that. > + else > + reg_message(STRING_INVALID_KEY); Doesn't get_rootkey() implicitly take care of this? I don't see why you need an extra check for a single leading backslash. There's one (intended?) side effect of this check though: It ensures that the code below doesn't crash on the input string "\\". > + i = strlenW(key); > + if (key[i - 1] == '\\') > + key[i - 1] = 0; Why do you need this? The existing code and the todo_wine test suggests that RegCreateKey accepts any number of trailing slashes. Adding a test for this in dlls/advapi32/tests/registry.c would be a good idea. This is the only case where you modify the input string. If it indeed is not necessary you can change the parameter to a const WCHAR * and return a BOOL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUTs1oAAoJEN0/YqbEcdMw0rsP/3XocRwBZ2zPgs/0ERHMOL0q 84+09LlpOMMBzEQDue4WnxLgNwT6EUdP1W+CpMLtjdh6r35qePWRuHwrieuRoKsF 7SoZhAqB1XGfSTfHC5yaSlC3a3didsGn8wCvb9R66wFcBstWY+wW9cdnyUzRhXeK oowmLBioiKlWGHBX84k7pvxLEzokeW+yEj0D/NXaVeFJ5ATfsqRynIiMJOeMJzJj XcnrH9YBDzvOy36zSREclwEtwt73dZ9dRYiLO4fHaaqsBMM0xiuZYl5CkfUxGjtm /c33mOOUl4l9EEpQLdu6kMtrT6kF13XbT2ume0AcqTbL4KrJVl7j173wck0vt1e7 kaLS1ViU4TGxHHo7mkqfMUjDpJM1tR5etV9DqQGQYui+BQ1ZOTpISrmuFxbXPAOd ecwvZGXEePGWrZlsV4lECc25/1BJQfEpxKK/5pc6fTv0TYd+JGOOnOSlTR9xlOSW rs/mjTuedQDNIFr+RvfMK+OpJIXXA9ve0jkpDX0XLnl3lZWG0p+rGholQXwHC5VS 1YUucH8moIW/8kN1s39/RSzcBgkxvAEDgiFsIigYqyEnPpafTbSQn3rNIVD5DQ0X +Fy7gBffr+uaOSKAh8ShdMGvRFGipd4WNQTelemCVcD1Pku2X01ImBImyHeMxBzW 2JdXxGTtZT8PribxigHn =eTay -----END PGP SIGNATURE-----

2 6

Re: [1/2] ndis.sys: add a stub dll
by Alistair Leslie-Hughes 29 Oct '14

29 Oct '14

Hi Austin, On 29/10/14 06:10, Austin English wrote: > > -- > -Austin This file should be installed into the system32\drivers directory by default. Modify wine.in.inf, look for mountmgr.sys as an example. Best Regards Alistair Leslie-Hughes

2 1

Re: [PATCH] mshtml: check null before release the elem object
by Jacek Caban 29 Oct '14

29 Oct '14

Hi Hao, On 10/24/14 11:37, Hao Peng wrote: > Check null pointer before release the script elem object, prevent to > release them twice. The real problem is that stop_binding is called twice. I sent a patch fixing that. Jacek

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByName (try 2 - resend)
by Stefan Dösinger 29 Oct '14

29 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-29 05:26, schrieb Alistair Leslie-Hughes: > + 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; + > case DPNA_DATATYPE_STRING: + memcpy(pvBuffer, > &entry->data.string, entry->size); + break; + > case DPNA_DATATYPE_STRING_ANSI: + > memcpy(pvBuffer, &entry->data.ansi, entry->size); + > break; + case DPNA_DATATYPE_BINARY: + > memcpy(pvBuffer, &entry->data.binary, entry->size); + > break; + } Using assignments like in AddComponent would be nicer. Since you're replacing everything but the function declaration you can rename the parameter names to get rid of the lpFoo names. The string types need some tests for the terminating 0 character. AddComponent currently does not check if the string length matches the input size. (It doesn't overflow though since it allocates according to the string length.) > + size = sizeof(GUID)-1; + hr = > IDirectPlay8Address_GetComponentByName(localaddr, UNKNOWN, > &compguid, &size, &type); + ok(hr == DPNERR_BUFFERTOOSMALL, > "got 0x%08x\n", hr); + ok(size == sizeof(GUID), "got %d > expected %d\n", size, sizeof(GUID)); Does it return DPNERR_BUFFERTOSMALL if pvBuffer is NULL? The d3d private data API returns D3D_OK in this case. This is worth a check. Does GetComponentByName correct the size downward when *pdwBufferSize > size? Also test this with pvBuffer != NULL Your implementation suggests pdwDataType is only set if the buffer has an appropriate size. Is this the case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUUPfSAAoJEN0/YqbEcdMwlBoP/jL3jPsPavfF4iQEr/fKe5y3 HLT67L/yqgriTCo4soOECoa+9fh9+8YFvBKrDvN7ISpZyni+paK38kxifAtwR0Xl QB7yrk3x+TVvIy8f3+QxwbqI7b/CX6AxEYcXG7Y30QNZchw+qN396HOs8XPU+HCG umYrNcnknizbASMQwkl0vaoZgun0JJP3L1jSEFnuLSZkl3f9CTIq5exS3q+ndqn7 0P0iqvo1CI1Pry/5qQGCYYxKqoFRfrqKbF0q1kGcImnwjpz211iuEQyVo23UICVI 0iMX1X2KueFQ4r9QrzRJmo+/8H5PpKsEQrWlhdBZyhhOX6m3BMxOrQK9/7OIzpua l8cYkrKpLCgMsvhF5hZchX1CY5ZomFdhOjFAQldYCpSVHuupnFqOPXx2qqmjGzU3 38h/liv4VgHLvpckLgvjsD8SGqtkBH/nk4WTk50fzWupegtLqnQ1gxILTNuh+e9Y kX4PWcMbbMQ6t1rjrdjBz4hDX/wAF44vx4NDLnht59aV3of9xtKfVWW8SFV9il40 2WDPhHESojF8BU/Nt/qx70YokSPIqpmwXdg1RQPXi5FNj2W5uqZoGCxCTeFfnY60 a68+EOaZaQhdSW5VSjGGWprs9jfBN4wB5SPoUU24adu5ygjcUsGj3IHj9H6ssBPN vwscAjUYyZDTzkgRQYAE =OHT3 -----END PGP SIGNATURE-----

1 1

Re: dplayx: Fix some crashes and wine_todo's ( try 2)
by Stefan Dösinger 29 Oct '14

29 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-29 06:13, schrieb Alistair Leslie-Hughes: > hr = IDirectPlayX_InitializeConnection( pDP, pAddress, 0 ); > - todo_wine checkHR( DP_OK, hr ); > + checkHR( DP_OK, hr ); Apparently running those tests only in interactive mode caused quite a bit of bitrot :-\ . According to ab448df3 the tests were too slow. Is this still the case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUUPlaAAoJEN0/YqbEcdMwYHsP/jwHawWB1Y+iGVlg+fT56yaI kYJ5knxAn2JaLwPB9DVyt2JRMG2SqvWmS0glqKfOVvWR8RFOGzUL/S1nS0H1VpgD drKtxFJFq1KOYFsgsBxHZdvsPnlayB/GXwAmIRXn6rI4rvkvuWDM2q7ovM9ZNsW+ 0zgiV5z9JMMiC/UOVedS4WF5ScoHjJfwW6S9bk4KAWltaybDFQA1Txo4OT+wpW0t 34p+GOB8uAoqqpyzONA5O2MpOdtodhFT03++6FLU3Y26+pyeKDqMP+TpX3MTRB70 JwIk09OBxSlqHjKUiU/4shd4bFSY0Pf/yzGpvFEsXTDHlcodvpBEHMKQj+8RXqqL PglmiK/Xy1J4OmrDmrTRMuGn/FmD1Mkj4WfQTsZ17ODHcubRlVhdNxsHqgDZDEVB krHYGcAJ5t6ZjVnM8m7uGLyvyJbsMeefHiR1+SFHi1VyBJnlD6Iu+osDQPKRSDK7 vcMciPMuXI0e3UUIzf5Kuz0gXDHdWuNerMI8j+6s3hyjc4zQnSd4GRL3fKV0GQOv lMEYS9DiF9ESUhjqC/9NFb233sbPmxabkVaoA+9C6vXgDdDhbE2rAQ75HFDoXh52 856Mq5tMuQQVFaZxHVd0A8bArNlb1ZLksuN02b5bo/q4Q0mN7oJEjxybgSxuHKAd yODcTxiiPmIVo1IWzKYJ =wqXw -----END PGP SIGNATURE-----

1 0

Re: [1/2] wined3d: Set D3DPMISCCAPS_FOGVERTEXCLAMPED flag in get_device_caps
by Henri Verbeet 29 Oct '14

29 Oct '14

On 28 October 2014 00:43, Joachim Priesner <joachim.priesner(a)web.de> wrote: > Wine clamps the oFog output of vertex shaders. Tests for the flag follow > in the second part of this patch. Why is it better to add the flag instead of just removing the clamping?

2 5

Re: [PATCH 7/8] dwrite: Implement system font collection as any other font collection
by Alexandre Julliard 29 Oct '14

29 Oct '14

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Subject: [PATCH 7/8] dwrite: Implement system font collection as any other > font collection It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M dwrite.dll -p dwrite_test.exe.so analyzer && touch analyzer.ok wine: Unhandled page fault on read access to 0x001a0000 at address 0x68665c0b (thread 007f), starting debugger... Unhandled exception: page fault on read access to 0x001a0000 in 32-bit code (0x68665c0b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68665c0b ESP:0032f6c0 EBP:0032f6e8 EFLAGS:00010216( R- -- I -A-P- ) EAX:001a0000 EBX:6867e828 ECX:006e0065 EDX:0018d418 ESI:0018c798 EDI:0018c7b8 Stack dump: 0x0032f6c0: 00000013 7b84aa26 0018c7d0 0018c7b8 0x0032f6d0: 0032f736 0018c928 68665b5b 6867e828 0x0032f6e0: 0032f736 0018c928 0032f7f8 6866720b 0x0032f6f0: 0018c798 0032f736 0018d418 00000000 0x0032f700: 00000040 00000001 6867298d 00002710 0x0032f710: 00000001 00000518 0018cb32 00000000 Backtrace: =>0 0x68665c0b add_localizedstring+0xbb(iface=0x18c798, locale="en-US", string="WenQuanYi Micro Hei?? ???I??????8bg --auto %ld %ld") [/home/julliard/wine/wine/dlls/dwrite/../../include/wine/unicode.h:200] in dwrite (0x0032f6e8) 1 0x6866720b opentype_get_font_strings_from_id+0x2fa(table_data=0x18c910, id=DWRITE_INFORMATIONAL_STRING_WIN32_FAMILY_NAMES, strings=0x32f854) [/home/julliard/wine/wine/dlls/dwrite/opentype.c:815] in dwrite (0x0032f7f8) 2 0x6865cab2 create_font_collection+0x1b1(factory=0x12af18, enumerator=0x12b830, ret=0x12af20) [/home/julliard/wine/wine/dlls/dwrite/font.c:1486] in dwrite (0x0032fa88) 3 0x6865d048 get_system_fontcollection+0x97(factory=0x12af18, collection=0x12af20) [/home/julliard/wine/wine/dlls/dwrite/font.c:1676] in dwrite (0x0032fab8) 4 0x68664bbd dwritefactory_GetSystemFontCollection+0xdc(iface=<couldn't compute location>, collection=<couldn't compute location>, check_for_updates=<couldn't compute location>) [/home/julliard/wine/wine/dlls/dwrite/main.c:566] in dwrite (0x0032faf8) 5 0x6865d59b gdiinterop_CreateFontFromLOGFONT+0x5a(iface=<couldn't compute location>, logfont=<couldn't compute location>, font=<couldn't compute location>) [/home/julliard/wine/wine/dlls/dwrite/../../include/dwrite.h:6896] in dwrite (0x0032fb58) 6 0x6862a87d create_fontface+0xac() [/home/julliard/wine/wine/dlls/dwrite/tests/../../../include/dwrite.h:4396] in dwrite_test (0x0032fc18) 7 0x6862b700 func_analyzer+0xb1f() [/home/julliard/wine/wine/dlls/dwrite/tests/analyzer.c:1044] in dwrite_test (0x0032fd58) 8 0x6862a083 main+0x332(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/dwrite/tests/../../../include/wine/test.h:584] in dwrite_test (0x0032fe08) 9 0x6863571f __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in dwrite_test (0x0032fe58) 10 0x7b85992c call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b85a8aa start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1104] in kernel32 (0x0032fea8) 12 0x7bc7a5a0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 13 0x7bc7d361 call_thread_func+0xb0(entry=0x7b85a850, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2724] in ntdll (0x0032ffa8) 14 0x7bc7a57e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc50f57 start_process+0x16(kernel_start=0x7b85a850) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2870] in ntdll (0x0032ffe8) 16 0x6803121d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0x68031380 wine_switch_to_stack+0x1f(func=0x7bc50f40, arg=0x7b85a850, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffdc1c18) 18 0x7bc56365 LdrInitializeThunk+0x1f4(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2924] in ntdll (0xffdc1c58) 19 0x7b860613 __wine_kernel_init+0x9b2() [/home/julliard/wine/wine/dlls/kernel32/process.c:1276] in kernel32 (0xffdc2b48) 20 0x7bc57123 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3133] in ntdll (0xffdc2bb8) 21 0x6802ee83 wine_init+0x2c2(argc=0x3, argv=0xffdc30f4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:958] in libwine.so.1 (0xffdc2c08) 22 0x7bf00d6a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xffdc3048) 23 0x68251a63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x68665c0b add_localizedstring+0xbb [/home/julliard/wine/wine/dlls/dwrite/../../include/wine/unicode.h:200] in dwrite: cmpw $0,0x0(%eax) 200 while (*s) s++; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] ddraw/tests: Port test_mode_change to ddraw (v2)
by Henri Verbeet 29 Oct '14

29 Oct '14

For whatever it's worth, the ddraw test test_mode_change() was originally related to is test_coop_level_mode_set(). (I.e., see also commits 43aac32f, 1ac6f487, f41ea4fe.)

1 0

Re: [PATCH 1/3] d3d9/tests: The device restores the mode settings from the registry (v2).
by Henri Verbeet 29 Oct '14

29 Oct '14

On 27 October 2014 23:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + IDirect3D9_GetAdapterDisplayMode(d3d9, D3DADAPTER_DEFAULT, &d3ddm); > + adapter_mode_count = IDirect3D9_GetAdapterModeCount(d3d9, D3DADAPTER_DEFAULT, d3ddm.Format); Shouldn't "d3ddm.Format" just be "D3DFMT_A8R8G8B8" here, since the test is using create_device()? > + modes = HeapAlloc(GetProcessHeap(), 0, sizeof(*modes) * adapter_mode_count); > + for (i = 0; i < adapter_mode_count; ++i) > + { > + UINT j; > + > + hr = IDirect3D9_EnumAdapterModes(d3d9, D3DADAPTER_DEFAULT, d3ddm.Format, i, &d3ddm2); > + ok(SUCCEEDED(hr), "Failed to enumerate display mode, hr %#x.\n", hr); > + > + if (d3ddm2.Width == screen_width && d3ddm2.Height == screen_height) > + continue; Given the nature of this test, we'd probably want to retrieve "screen_width" and "screen_height" with EnumDisplaySettingsW() and ENUM_REGISTRY_SETTINGS, and perhaps also make sure they match the current settings before running any tests. > + /* The r200 driver on Windows XP enumerates modes like 320x200 and 320x240 but > + * refuses to create a device at these sizes. */ > + if (d3ddm2.Width < 640 || d3ddm2.Height < 480) > + continue; > + > + for (j = 0; j < mode_count; ++j) > + { > + if (modes[j].w == d3ddm2.Width && modes[j].h == d3ddm2.Height) > + break; > + } > + if (j == mode_count) > + { > + modes[j].w = d3ddm2.Width; > + modes[j].h = d3ddm2.Height; > + ++mode_count; > + } > + } > + > + /* Make sure the d3d mode is smaller or equal in both width and height > + * than the mode passed to ChangeDisplaySettings. Otherwise Windows > + * shrinks the window to the ChangeDisplaySettings parameters + 12. */ > + d3ddm.Width = d3ddm.Height = d3ddm2.Width = d3ddm2.Height = ~0U; > + for (i = 0; i < mode_count; i++) > + { > + if (modes[i].w < d3ddm.Width && modes[i].h < d3ddm.Height) > + { > + d3ddm.Width = modes[i].w; > + d3ddm.Height = modes[i].h; > + } > + } > + for (i = 0; i < mode_count; i++) > + { > + if (modes[i].w < d3ddm.Width || modes[i].h < d3ddm.Height) > + continue; > + if (modes[i].w == d3ddm.Width && modes[i].h == d3ddm.Height) > + continue; > + d3ddm2.Width = modes[i].w; > + d3ddm2.Height = modes[i].h; > + break; > + } > + > + HeapFree(GetProcessHeap(), 0, modes); > + if (d3ddm2.Width == ~0U) > + { > + skip("Could not find adequate modes, skipping mode tests.\n"); > + IDirect3D9_Release(d3d9); > + return; > + } This looks fairly complicated, but in the end you just need two display modes that satisfy a couple of conditions. I suspect this code could be simplified a fair bit. Of course that probably also applies to test_reset() where this looks borrowed from.

1 0

Re: dplayx: Fix some crashes and wine_todo's
by Marvin 29 Oct '14

29 Oct '14

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=9845 Your paranoid android. === w8 (32 bit dplayx) === The test timed out

3 3

Jump to page:

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 October 2014