wine-devel September 2012

wine-devel@winehq.org

54 participants
188 discussions

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 02 Sep '12

02 Sep '12

On 02.09.2012 22:28, Nozomi Kodama wrote: > > + for (order = 0; order < 10; order++) > Is there a reason why we'd want to test til 9? D3DXSH_MAXORDER is 6, so 7 Should be enough? I know the other test do this, but technically I see no reason for that. Specifically the if (.. order > D3DXSH_MAXORDER) says exactly that, so no need to further than 7, since the parameters or did I miss something? I guess you'd also out of bounds? table[36 * j + i]; (for j=3 and i=99 => 207) since the table only has 4*36 => 144 elements. Cheers Rico

1 0

Re: winhttp: disable TLSv1.1/1.2 by default
by Henri Verbeet 02 Sep '12

02 Sep '12

On 26 August 2012 18:56, André Hentschel <nerv(a)dawncrow.de> wrote: > It's for http://bugs.winehq.org/show_bug.cgi?id=30598 > So it has its reason > So assuming I don't feel like reading through various bug trackers to figure this out, what is the specific issue this patch is supposed to address?

1 0

Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
by Charles Davis 02 Sep '12

02 Sep '12

On Sep 2, 2012, at 11:23 AM, Erich E. Hoover wrote: > This patch adds the final feature to make the embedded help work > properly, allowing Elster to resize the HTML Help window whenever the > application window is resized. Without this feature the HTML Help > window would always remain at the same size as when the window was > first created. Er, uh, what patch? Chip

2 1

Re: [PATCH] kernel32: add condition variables prototypes and tests
by Marvin 02 Sep '12

02 Sep '12

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=21332 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH] kernel32: add condition variables prototypes and tests
by Marvin 02 Sep '12

02 Sep '12

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

1 0

Re: netapi32: Add stub for NetScheduleJobAdd
by Jacek Caban 01 Sep '12

01 Sep '12

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

1 0

Wine Gecko 1.8-beta1
by Jacek Caban 01 Sep '12

01 Sep '12

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.

1 0

Re: winhttp: disable TLSv1.1/1.2 by default
by Hiroshi Miura 01 Sep '12

01 Sep '12

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

1 0

Jump to page:

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 September 2012