August 2009 - Wine-Devel - list.winehq.org

Re: [1/7] [try 2] mapi32: Add stub functions for loading/unloading MAPI providers

by Henri Verbeet

2009/8/31 Owen Rudge <orudge(a)codeweavers.com>: > +BOOL load_mapi_providers(); > +void unload_mapi_providers(); That doesn't do what you think it does. Also, a return value isn't very useful if you're just going to ignore it.

Aug. 31, 2009

Re: msxml3: Add IDispatchEx support to IXMLDOMElement

by Jacek Caban

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Add IDispatchEx support to IXMLDOMElement +static const tid_t domelem_iface_tids[] = { + IXMLDOMNode_tid, + IXMLDOMElement_tid, IXMLDOMElement inherits from IXMLDOMNode, so there is not need to add IXMLDOMNode here. Jacek

Aug. 31, 2009

Re: [PATCH] [Msvcrt]: fixing errno handling in strtol and strtoul (#18151)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > @@ -250,3 +250,25 @@ int CDECL __STRINGTOLD( MSVCRT__LDOUBLE *value, char **endptr, const char *str, > #endif > return 0; > } > + > +/****************************************************************** > + * strtol (MSVCRT.@) > + */ > +long int MSVCRT_strtol(const char* nptr, char** end, int base) > +{ > + /* wrapper to forward libc error code to msvcrt's error codes */ > + long ret = strtol(nptr, end, base); > + msvcrt_set_unix_errno(); > + return ret; > +} You can't simply use long here, you need to handle the difference in the size of long between Win32 and Unix. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2009

Re: programs/clock: Corrected a small lexical error in the italian translation (Corrected)

by Riccardo Loti

Il Sun, 30 Aug 2009 15:23:40 -0700, James McKenzie ha scritto: > Riccardo Loti wrote: >> Il Sat, 29 Aug 2009 11:56:46 -0700, James Mckenzie ha scritto: >> >> >> >>>> Fixed a small typing error in the italian translation of clock.exe in >>>> the property menu label (Properietà -> Proprietà). Compiled and >>>> tested correctly on Ubuntu 9.04 64bit. >>>> >>>> (My first patch I send, so please be kind for any error, I'll be >>>> happy to correct it if pointed to, thanks) >>>> >>>> P.S.: For some reason the previous mail attachment showed up empty in >>>> the archives list, even if sent mail is correct, and using >>>> Thunderbird I prefer not to paste it int he message body. Sorry for >>>> double sending. >>>> >>> Riccardo: >>> >>> Please look at the processed mail message before sending to make sure >>> that your patch is an attachment and not bound in-line. Thunderbird >>> likes to do this to text attachments, so you might want to change the >>> extension to .patch or .diff so Thunderbird will not do this. >>> >>> I did not have this problem with using git when git was configured per >>> the GitWine page on the Wiki. >>> >>> James McKenzie >>> >>> >> I will check, anyway I'll probably just configure git properly and send >> mail from git send-email. >> Anyway, about this patch itself, is it correct? I just have to wait for >> it to be accepted or refused now? >> > Using git-send is preferred to copy/paste. Thunderbird seems to > cooperate with it once you have git setup properly. > > And the patch looks good. > > Alexandre is the one who approves/denies any patch for the Wine code > base. > > James McKenzie I Couldn't have asked for more precise informations. ;) That was actually all I needed to know, I suppose I'll just wait... and dedicate to other bug in the meanwhile. Thanks again, Ric

Aug. 31, 2009

Re: d3dx9: Implement converting and copying surface data in D3DXLoadSurfaceFromMemory (review please)

by Tony Wasserka

> > You are right, but it would be neat to have them all grouped like they > are in d3dx9tex.h. > Not sure about that, assuming we ever support all possible filters and conversions in D3DXLoadSurfaceFromMemory, we probably don't want to have the texture stuff starting suddenly at line 3k or something... We won't be able to put the ID3DXBaseMesh, ID3DXMesh, ID3DXPatchMesh, ID3DXPMesh and ID3DXSPMesh interface implementations in one file either. > I seem to remember one additional thing from the MSDN: The alpha > channel has a specific behavior when it is added (RGB -> RGBA), it is > set to either 0.0 or 1.0. 1.0 makes sense. I think other channels > are set to 0.0 if they are added. > > Better test this though. > > According to http://msdn.microsoft.com/en-us/library/bb206254%28VS.85%29.aspx (and to my tests), new channels are set to their maximum value with the exception of A8, which was not yet handled in my patch but will be trivial to add in the new version.

Aug. 31, 2009

Re: d3dx9: Implement converting and copying surface data in D3DXLoadSurfaceFromMemory (review please)

by Philip Nilsson

On Sun, Aug 30, 2009 at 12:56:26PM +0200, Tony Wasserka wrote: > > I think it would be better to store this in surface.c since I can't > > think of anything else that would need this. > > > D3DXCheckTextureRequirements in texture.c will make use of the format > table, since it also needs information about bits per component and > component ordering. You are right, but it would be neat to have them all grouped like they are in d3dx9tex.h. I seem to remember one additional thing from the MSDN: The alpha channel has a specific behavior when it is added (RGB -> RGBA), it is set to either 0.0 or 1.0. 1.0 makes sense. I think other channels are set to 0.0 if they are added. Better test this though.

Aug. 31, 2009

Re: RFC: Fixing kernel32:locale tests on Vista and higher

by Alexandre Julliard

"Ge van Geldorp" <ggeldorp(a)vmware.com> writes: > Now, it is possible to fix all those failures. However, doing so would > require us to duplicate the tables that Microsoft uses. This is basically > the same problem that we have with the collation tables. To work around > this, I simply skip the test on Vista+, just like we skip the sorting > test. Does this sound like the right approach? We don't want to skip the tests. What we should do in those tests is test a few characters that are known to work identically across the board. It doesn't make sense to test the whole character range because that will never match perfectly on Wine anyway. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2009

Re: Missing libxml2 -> msxml3 compilation error

by Jacek Caban

Francois Gouget wrote: > It turns out I was missing libxml2 in one of my environments and this > lead to the following compilation error: > > $ gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wwrite-strings -Wpointer-arith -g -O2 -o dispex.o dispex.c > dispex.c:49: field `tid' has incomplete type > dispex.c:76: `LAST_tid' undeclared here (not in a function) > dispex.c:115: parameter `tid' has incomplete type > ... > > The problem is that tid_t is defined by msxml_private.h in a section > enclosed in an #ifdef HAVE_LIBXML2. But it's then used in dispex.c > regardless of HAVE_LIBXML2. > That would be my fault, sorry. > So should tid_t always be defined or should the relevant portions of > dispex.c be enclosed in an #ifdef HAVE_LIBXML2 I think it would be better to always define it. Thanks, Jacek

Aug. 31, 2009

Missing libxml2 -> msxml3 compilation error

by Francois Gouget

It turns out I was missing libxml2 in one of my environments and this lead to the following compilation error: $ gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -g -O2 -o dispex.o dispex.c dispex.c:49: field `tid' has incomplete type dispex.c:76: `LAST_tid' undeclared here (not in a function) dispex.c:115: parameter `tid' has incomplete type ... The problem is that tid_t is defined by msxml_private.h in a section enclosed in an #ifdef HAVE_LIBXML2. But it's then used in dispex.c regardless of HAVE_LIBXML2. So should tid_t always be defined or should the relevant portions of dispex.c be enclosed in an #ifdef HAVE_LIBXML2? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Aug. 31, 2009

Re: RFC: Fixing kernel32:locale tests on Vista and higher

by Greg Geldorp

From: Reece Dunn > Does anyone understand what these are doing and (in a general sense) > what the changes to Vista are? When you specify the MAP_FOLDCZONE flag, FoldStringW() on Vista will try to return a "simple" presentation for the Unicode characters. For example, if you pass in 0x01c7 ("LATIN CAPITAL LETTER LJ", L and J combined into a single Unicode character, see http://www.fileformat.info/info/unicode/char/01c7/index.htm) then FoldStringW() will return two characters: the letter L (0x004c) and the letter J (0x004a). Versions prior to Vista simply returned the exact same code that you passed in for all codes < 0xf900. Flag MAP_EXPAND_LIGATURES does something similar for ligatures. > I suppose the main questions to ask are: > 1/ are there applications that depend on the pre-Vista locale rules? > 2/ are the Linux/*BSD/Mac/OpenSolaris (or glibc, uLibc, ...) locale > rules *compatible* with Windows? > > I haven't seen anything on the locale changes for Vista breaking > anything except the Wine tests. As a result, it should (in theory) be > possible to use the native version. This would then remove the need > for Wine to copy the Microsoft locale tables. Right. But that wouldn't fix the current tests. Ge.

Aug. 30, 2009