November 2010 - Wine-devel - list.winehq.org

Re: (try 2)[PATCH 1/4] d3dcompiler: Add initial reflection parsing.
by Henri Verbeet 09 Nov '10

09 Nov '10

2010/11/8 Rico Schüller <kgbricola(a)web.de>: > - object->vtbl = &d3dcompiler_shader_reflection_vtbl; > - object->refcount = 1; > + hr = d3dcompiler_shader_reflection_init(object, data, data_size, riid); > + if (FAILED(hr)) > + { > + WARN("Failed to initialize shader reflection\n"); > + IUnknown_Release((IUnknown *)object); > + return hr; > + } You can't do that. Since d3dcompiler_shader_reflection_init() is responsible for setting the vtbl, you can't assume it's set if d3dcompiler_shader_reflection_init() fails. You'll have to use HeapFree() here. > + if (!IsEqualGUID(riid, &IID_ID3D11ShaderReflection)) > + { > + WARN("Wrong rrid %s, accept only %s!\n", debugstr_guid(riid), debugstr_guid(&IID_ID3D11ShaderReflection)); > + return E_FAIL; > + } This can be done in D3DReflect() before even allocating the reflection object. (Also, "rrid" is a typo.)

2 3

Re: AUTHORS list and the C locale on Mac OS X
by James Mckenzie 09 Nov '10

09 Nov '10

Charles Davis <cdavis(a)mymail.mines.edu> wrote: > >Hi, > >There may be a problem with the way the authors.c file is generated on a >Mac with GNU sed installed. > >On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. >This has some pretty surprising consequences. For example, since the >AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the >MacRoman encoding, GNU sed doesn't match those sequences in the .* >regexp, and the authors.c file comes out wrong. Mac OS sed does not have >this problem. So now I'm stuck changing the Makefile to use the system >sed (in /usr/bin) instead of GNU sed. > I found this a long time ago. Fink just modifies the Authors.c file to remove those sequences. I went one better and removed GNU sed from my Mac (fink purge sed) as I found that MacOSX version of sed would do everything that GNU sed did and I did not have to edit the file. >I could uninstall GNU sed, but there's one small problem. I have a >Gentoo prefix set up. It is the reason I have GNU sed installed. If I >install or upgrade practically anything in my Gentoo prefix, then GNU >sed will just get pulled right back in. > >Reading the manual for GNU sed tells me that this is by design and that >this behavior--not matching characters that are invalid in the current >locale--is in fact mandated by POSIX. If that's the case, then the >LC_ALL= statement in the Makefile needs to change. To what, I don't >know. I'm hoping one of you has an idea. > >If you think, however, that this is a bug in GNU sed, then I will gladly >write a report to the maintainer about it. > No, it is not a bug in GNU sed. The authors.c file needs to have the erroneous characters for the language used by MacOSX changed to be acceptable? James McKenzie

2 1

AUTHORS list and the C locale on Mac OS X
by Charles Davis 09 Nov '10

09 Nov '10

Hi, There may be a problem with the way the authors.c file is generated on a Mac with GNU sed installed. On Mac OS X, the C locale's default encoding is MacRoman, not UTF-8. This has some pretty surprising consequences. For example, since the AUTHORS file contains UTF-8 multibyte sequences that aren't valid in the MacRoman encoding, GNU sed doesn't match those sequences in the .* regexp, and the authors.c file comes out wrong. Mac OS sed does not have this problem. So now I'm stuck changing the Makefile to use the system sed (in /usr/bin) instead of GNU sed. I could uninstall GNU sed, but there's one small problem. I have a Gentoo prefix set up. It is the reason I have GNU sed installed. If I install or upgrade practically anything in my Gentoo prefix, then GNU sed will just get pulled right back in. Reading the manual for GNU sed tells me that this is by design and that this behavior--not matching characters that are invalid in the current locale--is in fact mandated by POSIX. If that's the case, then the LC_ALL= statement in the Makefile needs to change. To what, I don't know. I'm hoping one of you has an idea. If you think, however, that this is a bug in GNU sed, then I will gladly write a report to the maintainer about it. Chip

1 0

Re: gdi32: Remove broken check for WinXP.
by Marvin 09 Nov '10

09 Nov '10

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=6910 Your paranoid android. === W2KPROSP4 (32 bit font) === Failure running script in VM: Exceeded timeout limit of 315 sec

1 0

Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
by Alexandre Julliard 09 Nov '10

09 Nov '10

Eric Pouech <eric.pouech(a)orange.fr> writes: > +int CDECL _vcprintf(const char* format, __ms_va_list xvalist) > { > char buf[2048], *mem = buf; > int written, resize = sizeof(buf), retval; > - __ms_va_list valist; > + __ms_va_list valist = xvalist; You can't copy a valist. This needs to be integrated properly with the other printf functions. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
by Eric Pouech 09 Nov '10

09 Nov '10

to sum up the recent discrepencies between msvcrt and msvcrN0 Dlls: - msvcrt doesn't raise exception on _s functions while msvcrN0 does - (likely) in _s functions returning an errno_t value, msvcrt does set errno to the returned value, while msvcrN0 doesn't change the errno value (tested on _itoa_s and wcsncat_s) I wonder if should challenge the current scheme of forwarding all APIs from msvcrN0 to msvcrt (and writing wrappers in msvcr90 to cope with the various discrepencies) we could let msvcrt behave differently when loaded from our msvcrN0 DLLs than when loaded standalone, and factorize the discrepencies within msvcrt itself comments welcome A+ -- Eric Pouech

1 0

(no subject)
by Greg Geldorp 08 Nov '10

08 Nov '10

> From: Eric Pouech > > how come I got two different test results for the same patch ? > moreover one is perfectly ok, while the other shows strange results > any idea ? Yeah, that's a bit weird. The only thing I can think of is some kind of timing issue, but looking at the code that seems unlikely in this case. So basically, I don't have a clue. Ge.

3 2

wine cannot handle fc-cache (64bit) but fc-cache32 is okay
by Per Olesen 08 Nov '10

08 Nov '10

Hi Is it as-it-should-be, that wine only handles 32bit fc-cache? Is it known, that executing the 64bit version /usr/sbin/fc-cache will make the font-cache fail for wine, hence making wine *very* slow to startup? Rebuilding the cache with fc-cache32 makes wine start quickly again. It seems that the actual font cache format for fc-cache has changed between architectures. ? Regards, Per

1 0

Re: winegcc: Add Macho-o lib detection support
by Charles Davis 08 Nov '10

08 Nov '10

On 11/8/10 10:52 AM, André Hentschel wrote: > @@ -321,7 +321,8 @@ static int check_platform( struct options *opts, const char *file ) > unsigned char header[16]; > if (read( fd, header, sizeof(header) ) == sizeof(header)) > { > - /* FIXME: only ELF is supported, platform is not checked beyond 32/64 */ > + /* FIXME: only ELF and Macho-o is supported, platform is not checked beyond 32/64 */ Typo 'Macho-o'. > @@ -331,6 +332,15 @@ static int check_platform( struct options *opts, const char *file ) > ret = (opts->force_pointer_size == 4 || > (!opts->force_pointer_size && opts->target_cpu != CPU_x86_64)); > } > + /* Big Endian or Little Endian Mach-o File */ > + else if (!memcmp( header, "\376\355\372\316", 4 ) || !memcmp( header, "\316\372\355\376", 4 )) For 64-bit files, the magic number is 0xfeedfacf, not 0xfeedface. (Notice how the 64-bit magic is one more than the 32-bit magic.) You should check for that, too. I would like to take this time to point out that on Mac OS, there are no separate 32-bit and 64-bit library directories (i.e. no lib32 and lib64, only lib). If you want a 32-bit and a 64-bit version of a binary or library installed, you're expected to build a fat binary/library. Nearly all of the system libraries and binaries installed with Mac OS X are in fact fat. Chip

2 1

'winetricks dotnet35' starting to work
by Dan Kegel 08 Nov '10

08 Nov '10

In svn ( http://winezeug.googlecode.com/svn/trunk/winetricks ), I've added Louis' workaround from http://bugs.winehq.org/show_bug.cgi?id=22551#c5 to winetricks dotnet35. This let the game Bloodline Champions at least show its splash screen. Perhaps it will be useful for other apps, too. With wine-1.3.4 or earlier, anyway; dotnet30 explodes with wine-1.3.5 or later, see http://bugs.winehq.org/show_bug.cgi?id=25074

2 1