wine-devel February 2011

wine-devel@winehq.org

92 participants
246 discussions

Re: Re: user32/tests: Test for behavior of WM_SETTEXT handler
by Marvin 04 Feb '11

04 Feb '11

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=8838 Your paranoid android. === WNT4WSSP6 (32 bit msg) === msg.c:5649: Test failed: WM_SETTEXT on a button: 3: the msg 0x0138 was expected, but got msg 0x8000 instead === W7PROX64 (64 bit msg) === Timeout

1 0

Re: RFC: Adding Mac support to secur32/schannel.c
by James Mckenzie 03 Feb '11

03 Feb '11

Juan Lang <juan.lang(a)gmail.com> wrote: I'll make this quick and address a comment here from Juan from the viewpoint of someone building Wine from scratch using one of the porting services: Fink. > >Besides, I'm still not convinced that GnuTLS on the Mac is such an >onerous problem. This is not just a Codeweavers' problem but a problem that: 1. MacOSX provides native TLS support. 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on the existing capabilities. Interfacing the existing TLS capabilities to appear as the GNU product may be a solution to this. I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine. Thank you for reading this. James McKenzie

4 5

Re: RFC: Adding Mac support to secur32/schannel.c
by James Mckenzie 03 Feb '11

03 Feb '11

Charles Davis <cdavis(a)mymail.mines.edu> wrote: > >On 2/3/11 9:22 AM, James Mckenzie wrote: >> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the >>known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on >>the existing capabilities. >What are you talking about? MacPorts doesn't need patches for GnuTLS anymore. Looking at GnuTLS's Portfile, there are no >patch files pulled in and no reinplace (i.e. sed -ie) operations. It was my understanding that MacPorts did have them. I'll look at Fink tonight and see if there still is a patch file needed with the latest version. In any case, Mac users should be using build in functionality and as few as possible (none if possible) external 'Unix' add-on packages. For a while, they will be needed. >> I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine. >I'm for that. In fact, my humble opinion is that Wine on Mac should only use libraries that are part of the OS (i.e. only >dylibs in /usr/lib and frameworks in /System/Library/Frameworks). There are a whole host of benefits, not the least of >which is that it makes binary distribution easier (to date, Mac OS is one of the few platforms that does not have >an official binary distribution) and it could potentially expand our user-base (since users would no longer have to have >MacPorts or Fink or Gentoo Prefix or use a third-party distro just to run Wine). +1 :) It would be a great thing if we did not have to have 'special' builds for MacOSX and we could send out either an installable package or a disk image as the project. James McKenzie > >We've got a long way to go in that department, unfortunately. :( > >Chip > >

1 0

RFC: Adding Mac support to secur32/schannel.c
by Ken Thomases 03 Feb '11

03 Feb '11

Hi, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. I'd appreciate a review of this general plan. Thanks, Ken

8 18

Re: user32/tests: Test for behavior of WM_SETTEXT handler
by Alexandre Julliard 03 Feb '11

03 Feb '11

Alexander LAW <exclusion(a)gmail.com> writes: > + { WM_CTLCOLORSTATIC, sent|parent|optional}, /*Windows sends it, Wine doesn't*/ > + { WM_CTLCOLORSTATIC, sent|parent|optional}, /*Windows sends it, Wine doesn't*/ > + { WM_APP, sent|wparam|lparam, 0, 0 }, > + { WM_PAINT, sent }, > + { WM_NCPAINT, sent|defwinproc|optional }, /* FIXME: Wine sends it */ You can't add 'optional' to hide Wine bugs; if the message is sent on Windows it should be a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: gdi32: Upper 24 bits of a character range must be same.
by Greg Geldorp 03 Feb '11

03 Feb '11

Hi, I'm sure you've noticed that this change causes some failures on a Simplified Chinese-language test machine, see http://test.winehq.org/data/5ae2b0f219cb5aed2bdf32746a57a699a32767a2/xp_wtb… Can you take a look at that please? I'm wondering if it wouldn't make more sense to use GetCharABCWidthsW instead of the Ansi version for this test? Thanks, Greg.

2 1

Re: msvcrt: Partially implement type_info::name_internal_method()
by Alexandre Julliard 03 Feb '11

03 Feb '11

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -260,3 +307,24 @@ int CDECL _atoflt( _CRT_FLOAT *value, char *str ) > { > return _atoflt_l( value, str, NULL ); > } > + > +/********************************************************************* > + * ?_name_internal_method@type_info@@QBEPBDPAU__type_info_node@@@Z (MSVCR90.@) > + */ > +DEFINE_THISCALL_WRAPPER(MSVCRT_type_info_name_internal_method,8) > +const char * __thiscall MSVCRT_type_info_name_internal_method(type_info * _this, struct __type_info_node *node) > +{ > + /* this is a forward to type_info::name() */ > +#ifdef __i386__ > + static const char *typeinfo_name = "?name@type_info@@QBEPBDXZ"; > + void* (WINAPI *p)(void*); > +#else > + static const char typeinfo_name[] = "?name@type_info@@QEBAPEBDXZ"; > + void* (__cdecl *p)(void*); > +#endif > + static int once; > + > + if (node && !once++) FIXME("type_info_node parameter ignored\n"); > + p = (void*)GetProcAddress(GetModuleHandleA("msvcrt.dll"), typeinfo_name); > + return call_func1(p, _this); > +} I think it would be better to duplicate the implementation after all. Sorry for misleading you with the GetProcAddress suggestion, I hadn't realized that it would require the thiscall mess. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] winex11.drv: Complain a bit about missing s3tc support.
by Henri Verbeet 03 Feb '11

03 Feb '11

On 3 February 2011 01:00, Tobias Jakobi <liquid.acid(a)gmx.net> wrote: > *bumping* > > This patch never went into master, although it's _very_ important. Wine > users see a lot of D3D problems (mostly missing textures) since mesa drivers > don't support s3tc "out-of-the-box" (libtxc_dxtn needs to be available). > This leads to a lot of 'false' bug reports, which are in fact driver issues. > > Requesting to finally push this to master. > I'm not entirely sure on how to do this properly. Making it an ERR would be too loud for applications that never use s3tc textures, as a WARN it's never going to be seen unless you look at the debug channel. Printing a message in wined3d in CreateSurface() would probably work, but the resulting check would end up being pretty ugly because we'd have to check 5 different formats. You can't do much more than a WARN for a generic check either, because some formats may be legitimately missing / unimplemented. Note that the situation with floating point formats isn't much better.

2 1

Re: wined3d: Update clip planes when switching to/from offscreen rendering.
by Stefan Dösinger 02 Feb '11

02 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 15:13 schrieb Matteo Bruni: > It should fix http://bugs.winehq.org/show_bug.cgi?id=25877 > <0001-wined3d-Update-clip-planes-when-switching-to-from-offs.txt> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRssNAAoJEN0/YqbEcdMwZv8P+wbbhcamRsg42fMzJ02jKLcT s4p19OqKPZEdVvzsfQCe4e7KGgGdZUefMWsY2ib9AK21cQXB3R9fnyl5TMDcuxuh EojJvAQCVd/hgnz7tserUJT6rS/W08BPsdHM4dgxdnhRTzi2FAc7l3NgFOONJXpG i8HfcmD2AgaGOam6Wriv3SD8fM0zrfmpZdJDH1moCefqptEEWD9adwWRSMhaMvTl rlj1gDR9cRC9fsxur2U1f5NuXN0AY+a+5VPQHElZV2bP9ulheoa9nYuXU+8F7OhK RyIJ2DO4vpaLpEbXW/amtUWnlBSk0n7k3F9w/fcthOmUvlPHOBY7i2Ukf4j84vQD AhpN7Yf4cFZaSV8q/gww+U9H1udelidiTEL05OKQJUohnM1F9/cRnXbXmmA5Nuia rQlcCnm12cw1ClykdrY7B/hDCqGOPnnmPp580kW1LlEtidYyGbG35seyHxNqcNcQ RWlvVsGwvlzgex7qWf9hT34KOcUzMKZdlehfvtQn0Fjrcf+/3s5EvrtG4Mw6qHNh aBFNaeB8LkV36hu71r/1yxsqHO+taYt1/Ho8poANYbOplV9FCpd0nXeK8n7rqCPx L5TVgSJVd4n354FlguuIUAiFlXxcxFN2CJlN2Hd4dwhZZhGBh+4LH+XhjUtzX4ge 15usBq4VUhhssvv6dVys =urcm -----END PGP SIGNATURE-----

3 5

Wine FAQ edits
by Albert Lee 02 Feb '11

02 Feb '11

Hi Vitaliy, I notice you have reverted my edits to the FAQ on the wiki ( http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify the shell metacharacter information and operating system/platform support, and add new file association instructions, I would like to know why this happened and what changes should be done. -Albert

2 3

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 February 2011