January 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 1/8] winhttp: Use schannel in netconn_secure_connect if OpenSSL is not available

by Jacek Caban

On 01/22/13 20:21, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> The following patch makes winhttp use schannel instead of OpenSSL for >> SSL (HTTPS) connections. It is made to be as minimal change as possible >> (but complete enough to replace all OpenSSL functionality) to limit the >> scope for potential regressions. Further changes and improvements are >> left for later. > It doesn't work here: > I think I found the problem. I will fix a new version. Thanks, Jacek

Jan. 23, 2013

Re: [PATCH] wined3d: Ignore clears if count = 0 and rects != NULL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-01-23 13:36, schrieb Stefan D￶singer: > I was under the assumption that we already had a test for that - > those interfaces expect both count and rectangle to be non-zero, > otherwise they return an error. > > I can't find the test right now, so it seems that assumption was > wrong. Found them on my pile of half-finished viewport tests I postponed for Wine 1.4... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ/94pAAoJEN0/YqbEcdMwBpgP/3J3wOqPxvpBFH6t4JHzs+8N yBNdyeePXz2P7q0QqGexC4jpfRZPPesCYaZTYKfL1pDNDmU2qHAGQym83cF269BG KV3t0cytuIqL0aXvxDNHIYkMZQJ1WYg2qRR9FyPWZ6s/GDu94CfsoUavUoIRkPsu PxSbIiRvce7qNOYViZNYpJ214d0ETAEdsFAMdpdCL988AlF/tjRIxa5XG3Gi9xxu H5z8PfNOJup+ce3r2KpVCNkRUiucSY3/dsRnCBqeRqNCT9eLFfbZm/x1zNJkqJef JFYXTV7c/+mgkDfg3HpqcbvLFX7IOPbGsYzdiYBSfJfbfUtEl2592CbqJzqBmbiY WSlPBFHZQFahq1R3G803raZnQhrRr8clU7+upRNmazv+BUlui8l11HhepSBYvTHH qzeavwGZnWuYo/m+XO13xzXfOc6E4/GjiedMsHFcjoDnWy6jiELgECQdkcg3Gki5 EiTTmJWqlFBN+0h03jWGp5ZlZCK1YhIZxjiMIIjABX2oHXuYVjWQ6ppKetuoNJa3 r/RKIp/wZbP0xaAv2FMuTX09F8dJmTzaYD4fdR8Ad1XugF1IgE00c+xloFSRGzHR IXoqCyuB19a0V7hsCR4i1jWZmHrsnEIdDrmcL6L2btarKfVaeucOwh/oQ7/A7Y/1 WXfkRMmN7BUxarT1e/XJ =97Ov -----END PGP SIGNATURE-----

Jan. 23, 2013

Re: [PATCH] wined3d: Ignore clears if count = 0 and rects != NULL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-01-23 13:28, schrieb Henri Verbeet: > Although I don't expect a difference in behaviour, it probably > wouldn't hurt to add tests for the other ddraw versions as well > (i.e. through the viewport interface). I was under the assumption that we already had a test for that - those interfaces expect both count and rectangle to be non-zero, otherwise they return an error. I can't find the test right now, so it seems that assumption was wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ/9lpAAoJEN0/YqbEcdMwnFwP/RzV2jNv/IJCNP7VmViBvIwv m9irM59PbgWzIyxsjrGaogwpDuyok75yg+itpmEsQYBi7iMKem6vwQH1iUR2qb/O SMXylcp29K0IphYMUIbd/CQSEeSsGL+00t4FpRQhqdWi2PN8Vuw6ODXKwFPnbGyI VN4BaTv8gTJyCv+CNg6Li0/u+ueu5Ut/uZo+weKTS0hMyuKx7sUxypsETNHsdltb uq/1fEWhm8Z/NQvUftQ4DlykjmxLr64OHg5lTeyKIWPti+q1VT+mBWGG6jr2Kv9e 61G70jGVCwUJa40MFDQaBJ90EuihFT5jKrl+j/J5ujNAoqUZr7QQsiBy4M2/HvYJ BQg+hN9A199RpHNOmtBG/6XTiNDj57o1CF6LQ9GmikFNbmhKHVbxoQf5yRGay98y aahejLoj14B3xH91SsvmzVyiIFQ5NBqYFunveVE1Uc79vCHUixHindHgZnfJgHqs 1mSE8sTBVgxDk8OHueZODEBkaR6Yj9EAiMK4ogKaZ5estNpm7nKs2VivFUmGvgyP Kk/mgDAr320eTaHjRcOfSnommJN54PWZ9i8kCulOh0KRLxcuoEA7YACm9fjz0wCD tYFcydlCyp2DyyhYvVmHsIgAI9MyZqxowlyK4w8b3b30QpHUQIKsaL7IQmZMeWBR VBgOn9UAWAhYA8cJXkX2 =6ijd -----END PGP SIGNATURE-----

Jan. 23, 2013

Re: [PATCH] wined3d: Ignore clears if count = 0 and rects != NULL

by Henri Verbeet

On 23 January 2013 13:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > dlls/d3d8/tests/visual.c | 17 +++++++++++++++++ > dlls/d3d9/tests/visual.c | 16 ++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 36 ++++++++++++++++++++++++++++++++++++ > dlls/wined3d/device.c | 6 ++++++ > 4 files changed, 75 insertions(+) > Although I don't expect a difference in behaviour, it probably wouldn't hurt to add tests for the other ddraw versions as well (i.e. through the viewport interface).

Jan. 23, 2013

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > @@ -228,9 +228,9 @@ static NTSTATUS open_key( HKEY *retkey, ACCESS_MASK access, OBJECT_ATTRIBUTES *a > static HKEY create_special_root_hkey( HKEY hkey, DWORD access ) > { > HKEY ret = 0; > - int idx = (UINT_PTR)hkey - (UINT_PTR)HKEY_SPECIAL_ROOT_FIRST; > + int idx = (DWORD)hkey - (DWORD)HKEY_SPECIAL_ROOT_FIRST; > > - if (hkey == HKEY_CURRENT_USER) > + if ((DWORD)hkey == (DWORD)HKEY_CURRENT_USER) You want HandleToUlong and the like. > @@ -947,6 +948,57 @@ static void test_reg_open_key(void) > "RegOpenKeyEx with KEY_WOW64_64KEY failed (err=%u)\n", ret); > RegCloseKey(hkResult); > > + /* check special HKEYs on 64bit > + * only the lower 4 bytes of the supplied key are used > + */ > + if (ptr_size == 64) > + { > + DWORD mask = ~0U; > + HKEY hkBig = (HKEY)((ULONG_PTR)HKEY_CURRENT_USER & mask); > + > + ret = RegOpenKeyA(HKEY_CURRENT_USER, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult != NULL, "expected hkResult != NULL\n"); > + hkPreserve = hkResult; > + RegCloseKey(hkResult); > + > + hkBig = (HKEY)(((ULONG_PTR)HKEY_CURRENT_USER & mask) | 0x100000000ULL); > + ret = RegOpenKeyA(hkBig, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult == hkPreserve, "expected hkResult == hkPreserve\n"); > + RegCloseKey(hkResult); Please don't use long long constants. -- Alexandre Julliard julliard(a)winehq.org

Jan. 23, 2013

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.

by Rico Schüller

Hi, please don't apply this one, I somehow garbled the rebase ... Cheers Rico On 23.01.2013 12:24, Rico Schüller wrote: > --- > dlls/advapi32/registry.c | 18 +++++++------- > dlls/advapi32/tests/registry.c | 54 > ++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 61 insertions(+), 11 deletions(-) > > > > >

Jan. 23, 2013

Re: [1/2] wineps.drv: Implement GetGlyphIndices.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) > >> >> case, and one of its helpers unconditionally calls dc->GetGlyphIndices and > >> >> dc->GetTextExtentExPointI which crashes for a wineps.drv device. > >> >> > >> >> These 2 patches make ExtTextOutW work in this case. > >> > > >> > What is the reason that these patches are marked as pending? > >> > >> They shouldn't be needed. f496a5a0e6 probably addresses the issue. > > > > Yes, it does for that particular case, thanks. But direct calls to those > > APIs will still cause the same problem. > > I don't see how. Do you have a test case? No, my use case is different. But looking at the code at least GetGlyphIndices() calls the driver wihout checking whether it exports that entry point. -- Dmitry.

Jan. 23, 2013

Re: [1/2] wineps.drv: Implement GetGlyphIndices.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) > >> case, and one of its helpers unconditionally calls dc->GetGlyphIndices and > >> dc->GetTextExtentExPointI which crashes for a wineps.drv device. > >> > >> These 2 patches make ExtTextOutW work in this case. > > > > What is the reason that these patches are marked as pending? > > They shouldn't be needed. f496a5a0e6 probably addresses the issue. Yes, it does for that particular case, thanks. But direct calls to those APIs will still cause the same problem. -- Dmitry.

Jan. 23, 2013

Re: [1/2] wineps.drv: Implement GetGlyphIndices.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> >> ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) >> >> >> case, and one of its helpers unconditionally calls dc->GetGlyphIndices and >> >> >> dc->GetTextExtentExPointI which crashes for a wineps.drv device. >> >> >> >> >> >> These 2 patches make ExtTextOutW work in this case. >> >> > >> >> > What is the reason that these patches are marked as pending? >> >> >> >> They shouldn't be needed. f496a5a0e6 probably addresses the issue. >> > >> > Yes, it does for that particular case, thanks. But direct calls to those >> > APIs will still cause the same problem. >> >> I don't see how. Do you have a test case? > > No, my use case is different. But looking at the code at least GetGlyphIndices() > calls the driver wihout checking whether it exports that entry point. No it doesn't. Check how GET_DC_PHYSDEV works. -- Alexandre Julliard julliard(a)winehq.org

Jan. 23, 2013

Re: [1/2] wineps.drv: Implement GetGlyphIndices.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) >> >> case, and one of its helpers unconditionally calls dc->GetGlyphIndices and >> >> dc->GetTextExtentExPointI which crashes for a wineps.drv device. >> >> >> >> These 2 patches make ExtTextOutW work in this case. >> > >> > What is the reason that these patches are marked as pending? >> >> They shouldn't be needed. f496a5a0e6 probably addresses the issue. > > Yes, it does for that particular case, thanks. But direct calls to those > APIs will still cause the same problem. I don't see how. Do you have a test case? -- Alexandre Julliard julliard(a)winehq.org

Jan. 23, 2013