Re: font-shape/font-query related regression in wine 1.1.28
--- On Sun, 23/8/09, Austin English austinengl...@gmail.com wrote: On Sun, Aug 23, 2009 at 2:02 PM, Hin-Tak Leunghintak_le...@yahoo.co.uk wrote: My favourite mono/.net application dies with 'Style Regular isn't supported by font Tahoma' in 1.1.28. I did a git bisect and commit 0b9ba054f6c8a2d96c898e7325087f56a6224644 Author: André Hentschel n...@dawncrow.de Date: Wed Aug 12 19:19:32 2009 +0200 was the entry that breaks, but just reversing it in 1.1.28 does not fix the problem - i.e. more problematic commits later?; however, replacing the wine-shipped tahoma fonts with those from Vista does cure the problem; so does simply deleting them from $WINEPREFIX/drive_c/windows/fonts (and allow substitution from system fonts happen, I think). Sounds like you need to rerun the regression test...Does: $ git reset --hard 0b9ba054f6c8a2d96c898e7325087f56a6224644 git show 0b9ba054f6c8a2d96c898e7325087f56a6224644 | patch -p1 -R ./configure make depend make fix it? The result of bisect is apparently real. Ran that, it fixes the problem, then applying the commit, and it breaks: $ git show 0b9ba054f6c8a2d96c898e7325087f56a6224644 | patch -p1 \ make clean ./configure make depend make As I said, another workaround is just copying Vista-shipped tahoma* to windows/fonts , or deleting wine-shipped tahoma* and let substitution from system font happen. It is curious why german translation has effect on english locale.
Re: [2/4] d3d10: Parse local variables.
2009/8/21 Rico Schüller kgbric...@web.de: --- dlls/d3d10/d3d10_private.h | 1 + dlls/d3d10/effect.c | 64 2 files changed, 65 insertions(+), 0 deletions(-) Are you sure these are incompatible with buffer variables?
Re: [3/4] d3d10: Implement ID3D10Effect::GetVariableByIndex.
2009/8/21 Rico Schüller kgbric...@web.de:
+if( index This-local_buffer_variable_count )
Please use consistent style.
+for (i = 0; i This-local_buffer_count; ++i)
+{
+struct d3d10_effect_local_buffer *l = This-local_buffers[i];
+unsigned int j;
+
+for (j = 0; j l-variable_count; ++j)
+{
+struct d3d10_effect_variable *v = l-variables[j];
+
+if (nr == index)
+{
+TRACE(Returning variable %p.\n, v);
+return (ID3D10EffectVariable *)v;
+}
+nr++;
+}
+}
This is unnecessary, you can just keep subtracting l-variable_count
from index until l-variable_count index, at which point index
should have the right value to index l-variables.
Re: [2/4] d3dx9: D3DXAssembleShader and D3DXAssembleShaderFromFile stubs
2009/8/21 Matteo Bruni matteo.myst...@gmail.com:
+HRESULT WINAPI D3DXAssembleShaderFromFileA(LPCSTR pSrcFile,
+ CONST D3DXMACRO* pDefines,
+ LPD3DXINCLUDE pInclude,
+ DWORD Flags,
+ LPD3DXBUFFER* ppShader,
+ LPD3DXBUFFER* ppErrorMsgs)
+{
+LPWSTR pSrcFileW = NULL;
+DWORD len;
+HRESULT ret;
+
+if (!pSrcFile) return D3DXERR_INVALIDDATA;
+
+len = MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, NULL, 0 );
+pSrcFileW = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
+MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, pSrcFileW, len );
+ret=D3DXAssembleShaderFromFileW(pSrcFileW, pDefines, pInclude, Flags,
ppShader, ppErrorMsgs);
+HeapFree( GetProcessHeap(), 0, pSrcFileW );
+return ret;
+}
It doesn't matter much which style you pick, but please try to keep it
consistent (applies to the other patches as well). Note that
HeapAlloc() might fail. Oh, and please don't use hungarian notation.
Re: Behavior of realloc vs. HeapReAlloc
Hello!
Paul Chitescu wrote:
While trying to debug a crash in msi.dll I noticed that the local
msi_realloc() is implemented as a (too) thin wrapper around HeapReAlloc() and
differs from the expected behavior of realloc() when the old pointer or the
new size are zero.
The runtime realloc() works like free() if the new size is zero and it works
like alloc() if the old pointer is null. HeapReAlloc never allocates or
completely frees memory.
realloc:
http://msdn.microsoft.com/en-us/library/xbebcx7d(VS.80).aspx
HeapReAlloc:
http://msdn.microsoft.com/en-us/library/aa366704(VS.85).aspx
So I suggest all implementations of heap_realloc to be modified like:
if (!size) {
HeapFree(...)
return 0;
}
else if (!mem)
return HeapAlloc(...)
else
return HeapReAlloc(...)
Any comments?
Well, the heap_alloc wrappers are really supposed to be thin wrappers.
Those are there to basically save typing and not to simulate the
behavior of malloc/realloc/free. But I don't feel too strong about the
realloc case; you'd need to convince Alexandre to accept such a patch.
bye
michael
Re: font-shape/font-query related regression in wine 1.1.28
Le dimanche 23 août 2009 21:02:33, Hin-Tak Leung a écrit : I don't know why a german translation would affect my environment (LANG=en_GB.utf8) and setting LANG=C does not fix the problem. I just yesterday found a similar fix for a segfaulting wine iexplore on a japanese environment kde. The best I could reach with japanese locale was a HTML followed by squares (the one when a glyph is missing) before the segfault - probably japanese localisation of html rendering disabled. Switching to LC_ALL=C cures the crash. Originaly, the crash was in WoW launcher (which uses web rendering for part of its window). -- Vincent Pelletier
Re: kernel32: set sLanguage to LOCALE_SABBREVLANGUAGE to match Windows behavior
Jeff Zaroyko jeffzaro...@gmail.com writes: This fixes bug 15181, test included - passes on Windows 95, 2003, XP, 2008, Vista and Windows 7 beta that I've tested. From 52ff2d29ba9fbffbe8da46a7523338e8b946bbcd Mon Sep 17 00:00:00 2001 From: Jeff Zaroyko je...@jeffz.name Date: Sun, 23 Aug 2009 12:38:17 +1000 Subject: kernel32: set sLanguage to LOCALE_SABBREVLANGUAGE to match Windows behavior As a Profile entry and under Control Panel\International sLanguage is not LOCALE_SLANGUAGE but instead appears to be LOCALE_SABBREVLANGNAME. I've verified this is the case for 95, XP, 2003, 2008, Vista and Win 7. With the sLanguage override set GetLocaleInfo for LOCALE_SLANGUAGE still returns the LOCALE_SLANGUAGE string and not the override, which suggests that the Control Panel\International sLanguage override should be ignored by GetLocaleInfo for LOCALE_SLANGUAGE. You shouldn't need any special casing for this, just change the existing mappings to use the appropriate value. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/5] msdaps: Use 2 byte structure packing.
Huw Davies h...@codeweavers.com writes:
diff --git a/dlls/msdaps/Makefile.in b/dlls/msdaps/Makefile.in
index d6f71a0..cebf659 100644
--- a/dlls/msdaps/Makefile.in
+++ b/dlls/msdaps/Makefile.in
@@ -5,6 +5,7 @@ VPATH = @srcdir@
MODULE= msdaps.dll
IMPORTS = oleaut32 rpcrt4 kernel32 ntdll
EXTRADEFS = -DREGISTER_PROXY_DLL -DPROXY_CLSID_IS={ 0x06210e88, 0x01f5,
0x11d1, { 0xb5, 0x12, 0x00, 0x80, 0xc7, 0x81, 0xc3, 0x84 } }
+EXTRAIDLFLAGS = -a2
Won't this break the 64-bit build?
--
Alexandre Julliard
julli...@winehq.org
Re: Easy starter bug: implement extrac32
On Sun, Aug 23, 2009 at 11:10 PM, Alexandros Dermenakisalder...@gmail.com wrote: sounds like an interesting project, I could work on this. For any questions or tips etc. I should send to this list? As I mentioned in previous emails, I'm a nb with wine, I have some experience with driver development and some high level stuff but that's it. Sure, wine-devel is typically the e-mail list for development questions. BTW, please bottom post on wine mailing lists. Welcome to Wine! -- -Austin
Re: kernel32/tests: Remove test that crashes on Win7
On Mon, Aug 24, 2009 at 7:15 AM, Ge van Geldorpggeld...@vmware.com wrote: Changelog: kernel32/tests: Remove test that crashes on Win7 --- dlls/kernel32/tests/console.c | 12 +--- 1 files changed, 1 insertions(+), 11 deletions(-) Rather than removing it, should probably #if 0 it out, so that it's still documented and no one tries to add a similar test in the future. -- -Austin
RE: kernel32/tests: Remove test that crashes on Win7
Hi Austin, From: Austin EnglishSent: maandag 24 augustus 2009 14:20 On Mon, Aug 24, 2009 at 7:15 AM, Ge van Geldorpggeld...@vmware.com wrote: Changelog: kernel32/tests: Remove test that crashes on Win7 Rather than removing it, should probably #if 0 it out, so that it's still documented and no one tries to add a similar test in the future. I think the comment that I added should take care of that. Ge.
Re: netapi32/tests: Fix tests on Win7
On Mon, Aug 24, 2009 at 7:19 AM, Ge van Geldorpggeld...@vmware.com wrote: Win7 no longer exports NetpGetComputerName() and returns a weird value for totalEntries in the NetWkstaTransportEnum() call Changelog: netapi32/tests: Fix tests on Win7 --- dlls/netapi32/tests/wksta.c | 8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) @@ -173,7 +173,8 @@ static void run_wkstatransportenum_tests(void) ok(bufPtr != NULL, got data back\n); ok(entriesRead 0, read at least one transport\n); -ok(totalEntries 0, at least one transport\n); +ok(totalEntries 0 || broken(totalEntries == 0) /* Win7 */, Should probably be win_skip rather than broken, so that a similar failure on wine isn't ignored. -- -Austin
Re: [PATCH 1/5] msdaps: Use 2 byte structure packing.
On Mon, Aug 24, 2009 at 01:51:24PM +0200, Alexandre Julliard wrote:
Huw Davies h...@codeweavers.com writes:
diff --git a/dlls/msdaps/Makefile.in b/dlls/msdaps/Makefile.in
index d6f71a0..cebf659 100644
--- a/dlls/msdaps/Makefile.in
+++ b/dlls/msdaps/Makefile.in
@@ -5,6 +5,7 @@ VPATH = @srcdir@
MODULE= msdaps.dll
IMPORTS = oleaut32 rpcrt4 kernel32 ntdll
EXTRADEFS = -DREGISTER_PROXY_DLL -DPROXY_CLSID_IS={ 0x06210e88, 0x01f5,
0x11d1, { 0xb5, 0x12, 0x00, 0x80, 0xc7, 0x81, 0xc3, 0x84 } }
+EXTRAIDLFLAGS = -a2
Won't this break the 64-bit build?
Yes, good point. 64-bit should be left to default to 8 byte
alignment. How do I do that?
Huw.
Re: netapi32/tests: Fix tests on Win7
From: Austin English On Mon, Aug 24, 2009 at 7:19 AM, Ge van Geldorpggeldorp at vmware.com wrote: -ok(totalEntries 0, at least one transport\n); +ok(totalEntries 0 || broken(totalEntries == 0) /* Win7 */, Should probably be win_skip rather than broken, so that a similar failure on wine isn't ignored. My understanding is that broken() always returns false on Wine, so this shouldn't have any effect on Wine? Ge.
Re: netapi32/tests: Fix tests on Win7
On Mon, Aug 24, 2009 at 7:40 AM, Greg Geldorpggeld...@vmware.com wrote: From: Austin English On Mon, Aug 24, 2009 at 7:19 AM, Ge van Geldorpggeldorp at vmware.com wrote: - ok(totalEntries 0, at least one transport\n); + ok(totalEntries 0 || broken(totalEntries == 0) /* Win7 */, Should probably be win_skip rather than broken, so that a similar failure on wine isn't ignored. My understanding is that broken() always returns false on Wine, so this shouldn't have any effect on Wine? Ge. Agh, you're right. Too early in the morning, I'll go get some coffee before replying more :-). -- -Austin
Re: ddraw: Separate reference counting for IDirectDraw7 and IDDS4 from IDDS3, IDDS2 and IDDS (try 2)
2009/8/22 Stefan Dösinger stefandoesin...@gmx.at: I think it is better to separate the vtables first - ie, give IDirectDrawSurface4, IDirectDrawSurface2 and IDirectDrawSurface their own vtable Also the last iteration of Michael Karcher's patches missed out some getters, like IDirect3DDevice*::GetRenderTarget. There may be other functions that need to be adjusted to AddRef/Release version specific refcounts. Here are my likely broken patches that separate the surface thunks for refcounting, from months ago. I think the first 4 are OK, but I named the last one broken so I guess that one isn't ;) Still it's a starting point. Luke. thunk_patches3.tar.gz Description: GNU Zip compressed data
Re: shlwapi/tests: Remove test that crashes on Win7
2009/8/24 Ge van Geldorp ggeld...@vmware.com: Changelog: shlwapi/tests: Remove test that crashes on Win7 -ret = IStream_Clone(stream, NULL); -ok(ret == E_NOTIMPL, expected E_NOTIMPL, got 0x%08x\n, ret); +/* Passing a NULL pointer crashes on Win7 */ If you are going to change this to a comment, could you please say which argument passing NULL to causes the crash. Thanks, - Reece
Re: [PATCH 1/5] msdaps: Use 2 byte structure packing.
Huw Davies h...@codeweavers.com writes:
On Mon, Aug 24, 2009 at 01:51:24PM +0200, Alexandre Julliard wrote:
Huw Davies h...@codeweavers.com writes:
diff --git a/dlls/msdaps/Makefile.in b/dlls/msdaps/Makefile.in
index d6f71a0..cebf659 100644
--- a/dlls/msdaps/Makefile.in
+++ b/dlls/msdaps/Makefile.in
@@ -5,6 +5,7 @@ VPATH = @srcdir@
MODULE= msdaps.dll
IMPORTS = oleaut32 rpcrt4 kernel32 ntdll
EXTRADEFS = -DREGISTER_PROXY_DLL -DPROXY_CLSID_IS={ 0x06210e88, 0x01f5,
0x11d1, { 0xb5, 0x12, 0x00, 0x80, 0xc7, 0x81, 0xc3, 0x84 } }
+EXTRAIDLFLAGS = -a2
Won't this break the 64-bit build?
Yes, good point. 64-bit should be left to default to 8 byte
alignment. How do I do that?
I suppose the easiest is to extend the -a option to allow specifying two
alignment sizes, or to add explicit options like --win32-align/--win64-align.
--
Alexandre Julliard
julli...@winehq.org
Re: wined3d: delete meaningless UNIX GL driver version parsing
Am Monday 24 August 2009 18:02:37 schrieb joerg-cyril.hoe...@t-systems.com: Hi, here's the patch not to report UNIX GL driver version numbers to MS-Windows apps, as suggested by Stefan and Roderick on 2009-05-25. On early 2009 NVidia MacOS, it will remove err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: 2.0 NVIDIA-1.5.44 The patch is fine with me. On a related note, it would be helpful if people who have an Intel GPU on their windows machines could update to the newest drivers and report the driver versions, so we can add then to the driver version table. the d3d9 visual test writes the driver version to stdout at the beginning.
Re: wined3d: delete meaningless UNIX GL driver version parsing
2009/8/24 Stefan Dösinger stefandoesin...@gmx.at: Am Monday 24 August 2009 18:02:37 schrieb joerg-cyril.hoe...@t-systems.com: Hi, here's the patch not to report UNIX GL driver version numbers to MS-Windows apps, as suggested by Stefan and Roderick on 2009-05-25. On early 2009 NVidia MacOS, it will remove err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: 2.0 NVIDIA-1.5.44 The patch is fine with me. It doesn't apply for me.
Build failure on current git
Hello, building current git fails for me with: make: Entering directory `/usr/src/wine/wine-build/dlls/winemp3.acm' ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared ../../../wine-git/dlls/winemp3.acm/winemp3.acm.spec mpegl3.o-o winemp3.acm.so -lwinmm -luser32 -lkernel32 ../../libs/port/libwine_port.a -lmpg123 mpegl3.o: In function `mp3_horse': /usr/src/wine/wine-build/dlls/winemp3.acm/../../../wine-git/dlls/winemp3.acm/mpegl3.c:153: undefined reference to `mpg123_feed' collect2: ld returned 1 exit status winegcc: ccache failed make: *** [winemp3.acm.so] Fehler 2 make: Leaving directory `/usr/src/wine/wine-build/dlls/winemp3.acm' s...@sle3:/usr/src/wine/wine-build$ dpkg --list | grep mpg123 ii libmpg123-0 1.4.3-4 MPEG layer 1/2/3 audio decoder -- runtime li ii libmpg123-dev 1.4.3-4 MPEG layer 1/2/3 audio decoder -- developmen ii mpg321 0.2.10.6mpg123 clone that doesn't use floating point
Re: Build failure on current git
according to the mpg123 NEWS file mpg123_feed was introduced with 1.5.0 if this is actually the lowest version to compile with, it should be checked by ./configure if possible. linking against system libmpg123 does have other issues however. im building a 32 bit wine on a 64 bit box here and i have installed a 32 bit libary of libmpg123 of course, however: mpegl3.o: In function `MPEG3_Reset': mpegl3.c:(.text+0xca): undefined reference to `mpg123_feedseek' the symbol is actually mpg123_feedseek_64 (which seems to be the case on a pure 32 bit box too according to one reporter) mpg123_findseek is correct for 64 bit however as there isn't mpg123_findseek_64 in my 64 bit libary.
Re: Build failure on current git
Stefan Leichter a écrit : Hello, building current git fails for me with: make: Entering directory `/usr/src/wine/wine-build/dlls/winemp3.acm' ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared ../../../wine-git/dlls/winemp3.acm/winemp3.acm.spec mpegl3.o-o winemp3.acm.so -lwinmm -luser32 -lkernel32 ../../libs/port/libwine_port.a -lmpg123 mpegl3.o: In function `mp3_horse': /usr/src/wine/wine-build/dlls/winemp3.acm/../../../wine-git/dlls/winemp3.acm/mpegl3.c:153: undefined reference to `mpg123_feed' collect2: ld returned 1 exit status winegcc: ccache failed make: *** [winemp3.acm.so] Fehler 2 make: Leaving directory `/usr/src/wine/wine-build/dlls/winemp3.acm' s...@sle3:/usr/src/wine/wine-build$ dpkg --list | grep mpg123 ii libmpg123-0 1.4.3-4 MPEG layer 1/2/3 audio decoder -- runtime li ii libmpg123-dev 1.4.3-4 MPEG layer 1/2/3 audio decoder -- developmen ii mpg321 0.2.10.6mpg123 clone that doesn't use floating point I get as well several problems on Mandriva from what I see (in my mpg123.h) file the libmpg123 lib can either be configured with FILE_OFFSET_BITS to 32 or 64 if the later, then most of the symbols exported from the library get a _64 suffix prompt string /usr/libmpg123.so | grep seek should tell. I get mpg123_seek_frame_64 mpg123_feedseek_64 mpg123_seek_64 moreover, in my case, the header/lib check in configure fails because of the following code in mpg123.h /#ifndef MPG123_NO_CONFIGURE /* Enable use of this file without configure. */ #include stdlib.h #include sys/types.h #if 1 /* If we need trickery for large file support. */ /* Check for compiling programs agains this libmpg123. */ #if (defined _FILE_OFFSET_BITS) (_FILE_OFFSET_BITS+0 == 64) /* ...all is fine, having enabled large file support and also the correct sort of which. */ #else #error Mismatch in large file setup! Enable/disable large file support appropriately to use libmpg123. #endif .../ as a temporary hack, something like this seems to help diff --git a/configure.ac b/configure.ac index 4b37e5f..3945157 100644 --- a/configure.ac +++ b/configure.ac @@ -278,6 +278,8 @@ case $host_cpu in ;; esac +AC_SYS_LARGEFILE + dnl Check for some libraries dnl Check for -li386 for NetBSD and OpenBSD diff --git a/dlls/winemp3.acm/mpegl3.c b/dlls/winemp3.acm/mpegl3.c index 9b4e2ac..4602a42 100644 --- a/dlls/winemp3.acm/mpegl3.c +++ b/dlls/winemp3.acm/mpegl3.c @@ -25,6 +25,7 @@ #include assert.h #include stdarg.h #include string.h +#include unistd.h #include windef.h #include winbase.h #include wingdi.h @@ -35,6 +36,8 @@ #include msacm.h #include msacmdrv.h +#define _FILE_OFFSET_BITS 64 + #ifdef HAVE_MPG123_H #include mpg123.h #endif one still needs to properly handle the definition of _FILE_OFFSET_BITS in mpegl3.c from the configuration bits before this patch gets ready for submission time to stop for tonight, more on this tomorrow A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
