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

Re: msvcp110: Add VS2012 C/C++ runtime

by Piotr Caban

On 03/28/13 23:22, Stefan Leichter wrote: > --- > configure.ac | 1 + > dlls/msvcp110/Makefile.in | 5 + > dlls/msvcp110/msvcp110.c | 37 + > dlls/msvcp110/msvcp110.spec | 3900 > +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 3943 insertions(+), 0 deletions(-) > create mode 100644 dlls/msvcp110/Makefile.in > create mode 100644 dlls/msvcp110/msvcp110.c > create mode 100644 dlls/msvcp110/msvcp110.spec You can use tools/make_specfiles script to generate forwards to other msvcpXX dlls. The script will generate big parts of the spec file differently (because it prefers to forward to msvcp90, not to msvcp100).

March 29, 2013

Re: Windows API on Linux

by Henri Verbeet

On 29 March 2013 13:27, Abhinav Jangda <abhijangda(a)hotmail.com> wrote: > Hello everyone, I'm working on a project which aims to develop a port of > Windows API on Linux, so that programs written using Windows API could > directly be compiled and executed on Linux with its native look and feel. Is that really any different from what Wine does?

March 29, 2013

Windows API on Linux

by Abhinav Jangda

Hello everyone, I'm working on a project which aims to develop a port of Windows API on Linux, so that programs written using Windows API could directly be compiled and executed on Linux with its native look and feel. Anyone, interested in working on this project. I think some Wine developers will be as they would be having a good knowledge of Windows API. If anyone interested then please let me know. Thank You :)

March 29, 2013

Re: wined3d: Properly handle WS_VISIBLE and WS_EX_TOPMOST style flags on fullscreen windows.

by Henri Verbeet

On 29 March 2013 03:31, Sam Edwards <cfsworks(a)gmail.com> wrote: > Note that the tests are NOT (primarily) intended to make sure that > WS_VISIBLE and WS_EX_TOPMOST are still set. The main purpose of this patch > is to fix a slightly more serious bug: > > - Create a window without WS_VISIBLE. > - Create a fullscreen Direct3D device. > - wined3d applies its own flags (including WS_VISIBLE) to the window, to > make it fullscreen. > - Reset the device back to windowed mode. > - Because wined3d_device_setup_fullscreen_window didn't see the window had > WS_VISIBLE, wined3d_device_restore_fullscreen_window won't restore the > style. > > This patch corrects that behavior, and the window restores back to its > original style as on Windows. > I think the idea is basically ok, but I do have some comments: I think test_window_style() is a more appropriate place for the tests, and you should add them to the variants in ddraw as well. Ddraw applications in particular are very fragile in this regard. Note that the test_window_style() tests are fairly similar to what your tests do, except that they don't test restoring the window as such. That test also shows that we're actually not supposed to touch the styles at all, but that's hard to make work without calling into winex11. > - SetWindowPos(window, HWND_TOP, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); > + SetWindowPos(window, HWND_TOPMOST, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); This is really a separate change. > + device->style ^= (device->style^style) & WS_VISIBLE; Spaces around the (second) ^, please.

March 29, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Jacek Caban

Hi Juan, On 03/28/13 21:55, Juan Lang wrote: > On Thu, Mar 28, 2013 at 12:31 PM, Ken Thomases <ken(a)codeweavers.com > <mailto:ken(a)codeweavers.com>> wrote: > > On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > > > --- a/dlls/secur32/schannel_macosx.c > > +++ b/dlls/secur32/schannel_macosx.c > > @@ -630,6 +630,11 @@ static OSStatus > schan_push_adapter(SSLConnectionRef transport, const void *buff, > > return ret; > > } > > > > +DWORD schan_imp_enabled_protocols(void) > > +{ > > + /* NOTE: No support for TLS 1.1 and TLS 1.2 */ > > + return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT | > SP_PROT_TLS1_0_CLIENT; > > > Do we really want to continue supporting SSL2? It's got a number of > vulnerabilities, and is disabled pretty much everywhere by now: > http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_2.0 I implemented it the way it's done in Windows. It's a bit under-documented and contains usual MSDN mistakes, so let me explain what I found when testing Windows (most of it is implemented by http://source.winehq.org/git/wine.git/commitdiff/0f2e0365ea1f5c6baba4cfd9c0…) Each protocol has two kinds of enable/disable flags: "enabled" and "disabled by default". Those have different default values for each protocol and there are registry setting allowing to change each of them. Only "enabled" protocols are used at all. This patch limits "enabled" protocols to those that we can really support. If an application asks schannel to use default set of protocols (which I'd expect them to do unless they have a good reason), schannel will use all "enabled" protocols that are not "disabled by default". An alternative to default set of protocols is listing each allowed separately. This means that if protocol is "enabled" and "disabled by default" it won't be used unless application explicitly asks for it. SSL2 is such a protocol by default. Do you think we should do this differently? Thanks, Jacek

March 29, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Jacek Caban

Hi Ken, On 03/28/13 20:31, Ken Thomases wrote: > On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > >> --- a/dlls/secur32/schannel_macosx.c >> +++ b/dlls/secur32/schannel_macosx.c >> @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef transport, const void *buff, >> return ret; >> } >> >> +DWORD schan_imp_enabled_protocols(void) >> +{ >> + /* NOTE: No support for TLS 1.1 and TLS 1.2 */ >> + return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT | SP_PROT_TLS1_0_CLIENT; >> +} > Mac OS X 10.8 introduced support for TLS 1.1 and 1.2. You can test at build time with: > > #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 > ... > #else > ... > #endif > > > If we want to support building on 10.8 for deployment to earlier versions, we'd do something like: > > #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 > SSLProtocol maxProtocol; > if (SSLGetProtocolVersionMax != NULL && SSLGetProtocolVersionMax(context, &maxProtocol) == noErr) > { > ... compare maxProtocol against kTLSProtocol11 and kTLSProtocol12 ... > } > ... > #else > ... > #endif Thanks for the pointers, I've been meaning to explore it as follow-up. My problem is that I'm still on 10.6 with Xcode 3.2. Would you mind taking care of the patch? > The idea is that SSLGetProtocolVersionMax() would be weak linked, so we'd check if it was actually available before calling it. Of course, the other complication is that that function requires a context parameter, but we can create one just for the query if we're interested in the framework capabilities (as opposed to what's been configured for a particular context). Yes, in this case we're only interested in framework capabilities. We should determine protocols used for given context ourselves, based on caller's requested protocol and confuration, and pass that to framework. Setting up framework is not implemented yet, I have patches for that that I want to test a bit more before sending. Thanks, Jacek

March 29, 2013

Re: [PATCH 1/3] extrac32: Implement more strict command line processing.

by Sergey Guralnik

On 2013-03-26 10:17, Sergey Guralnik wrote: > Is some problem with this series? -- Sergey

March 29, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Juan Lang

On Thu, Mar 28, 2013 at 12:31 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > > > --- a/dlls/secur32/schannel_macosx.c > > +++ b/dlls/secur32/schannel_macosx.c > > @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef > transport, const void *buff, > > return ret; > > } > > > > +DWORD schan_imp_enabled_protocols(void) > > +{ > > + /* NOTE: No support for TLS 1.1 and TLS 1.2 */ > > + return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT | > SP_PROT_TLS1_0_CLIENT; > Do we really want to continue supporting SSL2? It's got a number of vulnerabilities, and is disabled pretty much everywhere by now: http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_2.0 --Juan

March 28, 2013

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

by Ken Thomases

On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > --- a/dlls/secur32/schannel_macosx.c > +++ b/dlls/secur32/schannel_macosx.c > @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef transport, const void *buff, > return ret; > } > > +DWORD schan_imp_enabled_protocols(void) > +{ > + /* NOTE: No support for TLS 1.1 and TLS 1.2 */ > + return SP_PROT_SSL2_CLIENT | SP_PROT_SSL3_CLIENT | SP_PROT_TLS1_0_CLIENT; > +} Mac OS X 10.8 introduced support for TLS 1.1 and 1.2. You can test at build time with: #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 ... #else ... #endif If we want to support building on 10.8 for deployment to earlier versions, we'd do something like: #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080 SSLProtocol maxProtocol; if (SSLGetProtocolVersionMax != NULL && SSLGetProtocolVersionMax(context, &maxProtocol) == noErr) { ... compare maxProtocol against kTLSProtocol11 and kTLSProtocol12 ... } ... #else ... #endif The idea is that SSLGetProtocolVersionMax() would be weak linked, so we'd check if it was actually available before calling it. Of course, the other complication is that that function requires a context parameter, but we can create one just for the query if we're interested in the framework capabilities (as opposed to what's been configured for a particular context). -Ken

March 28, 2013

Re: gdi32: Copy gamma ramp validation from winex11 to make it driver independent (try 2)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + /* the bias could be because the app wanted something like a "red shift" > + * like when you're hit in Quake, but XVidMode doesn't support it, > + * so we have to reject a significant bias */ Clearly gdi32 doesn't care about XVidMode. > @@ -1325,6 +1405,18 @@ BOOL WINAPI SetDeviceGammaRamp(HDC hDC, LPVOID ptr) > if (GetObjectType( hDC ) != OBJ_MEMDC) > { > PHYSDEV physdev = GET_DC_PHYSDEV( dc, pSetDeviceGammaRamp ); > + struct gamma_ramp > + { > + WORD red[256]; > + WORD green[256]; > + WORD blue[256]; > + } *ramp = ptr; > + > + if (!check_gamma_ramp(ramp->red) || > + !check_gamma_ramp(ramp->green) || > + !check_gamma_ramp(ramp->blue)) > + return FALSE; This can't work. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2013