September 2012 - Wine-Devel

Re: [PATCH] kernel32: add condition variables prototypes and 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 http://testbot.winehq.org/JobDetails.pl?Key=21331 Your paranoid android. === WINEBUILD (build) === Make failed

Sept. 2, 2012

Re: netapi32: Add stub for NetScheduleJobAdd

by Jacek Caban

Hi Jong, On 09/01/12 17:13, Jong Bin, Chae wrote: > --- > dlls/netapi32/netapi32.c | 6 ++++++ > dlls/netapi32/netapi32.spec | 2 +- > 2 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/dlls/netapi32/netapi32.c b/dlls/netapi32/netapi32.c > index 470adf0..f6c6d20 100644 > --- a/dlls/netapi32/netapi32.c > +++ b/dlls/netapi32/netapi32.c > @@ -238,6 +238,12 @@ NET_API_STATUS WINAPI NetUseEnum(LMSTR server, > DWORD level, LPBYTE* bufptr, DWOR > return ERROR_NOT_SUPPORTED; > } > > +NET_API_STATUS WINAPI NetScheduleJobAdd(LPCWSTR server, LPBYTE > bufptr, LPDWORD jobid) > +{ > + FIXME("stub (%s, %p, %p)\n", debugstr_w(server), bufptr, jobid); It looks like your mail client wraps lines. Please send patches as attachments or reconfigure your mail client. Cheers, Jacek

Sept. 1, 2012

Wine Gecko 1.8-beta1

by Jacek Caban

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko PS: This is a second resend. For some reason this mail didn't make to wine-devel yesterday.

Sept. 1, 2012

Re: winhttp: disable TLSv1.1/1.2 by default

by Hiroshi Miura

Hi, Thanks André to point the discussion On 2012年08月27日 01:56, André Hentschel wrote: > Am 26.08.2012 17:46, schrieb Marcus Meissner: >> On Sun, Aug 26, 2012 at 11:50:15AM +0900, Hiroshi Miura wrote: >>> >>> Windows 7 disables TLSv1.1/1.2 by default. >>> This patch intend to behave same as Windows. >> >> >> Please do not... The newer TLSv1.x fix some shortcomings >> of the older TLS versions. >> >> Is there a specific problem you see? >> >> Otherwise, I object. >> > > It's for http://bugs.winehq.org/show_bug.cgi?id=30598 > So it has its reason > Yes it has a reason to disable TLS 1.1 1.2 by DEFAULT. It also provide interface to enable it through registry entry, which is same as windows does. I also prefer to use TLS 1.1/1.2 than before SSL3.0/TLS1.0. but here is a interoperability issue with SSL3.0/TLS 1.0 only site and TLS1.1/1.2 enabled Wine program. In evernote case, client program use wininet dll instead of winhttp. Even such a case, it should be a same behavior for registry values in secur32/schannel, wininet, and winhttp dlls. I understand that wininet/winhttp has a issue to re-implement it using schannel instead of openssl. It means if we support a behavior disabling/enabling TLS1.1/1.2 with registry entry for Schannel, wininet/winhttp should also have a same behavior. We need to add function that enable/disable TLS1.1/1.2 in secur32/schannel according to this registry, but I've not implemented it yet. registry entry is like; ---- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 ----- see http://netsekure.org/2009/10/tls-1-2-in-windiows-7/ Hiroshi

Sept. 1, 2012