August 2006 - Wine-devel - list.winehq.org

Re: HAL and Copy Protection
by Jesse Allen 01 Aug '06

01 Aug '06

On 8/1/06, Martin Owens <doctormo(a)gmail.com> wrote: > the important part is not that HAL supports SecuRom (which it won't IMHO) > but if wine can use the direct access to the hardware in order to allow > securom to work through wine. > > Yes, that is correct. However I'm not sure if Wine interprets the HAL events correctly, or HAL overrides the important settings for correct hardware access. It's hard to know without having HAL on my system to look at.

1 1

wine notepad.exe: Segmentation fault
by Molle Bestefich 01 Aug '06

01 Aug '06

Been running 0.9.15 for a while without problems. Since a week ago (or so) when I updated to HEAD, all I get from Wine is this: wine-git # notepad Segmentation fault Nuking ~/.wine doesn't help: wine-git # rm -rf ~/.wine wine-git # notepad wine: creating configuration directory '/root/.wine'... /usr/local/bin/../lib/../bin/wineprefixcreate: line 171: 8574 Segmentation fault "${WINELOADER:-$bindir/wine}" rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf wine: wineprefixcreate failed while creating '/root/.wine'. GDB tells me a lot I don't quite understand: wine-git # gdb --quiet --args /usr/local/bin/wine-pthread /usr/local/bin/notepad.exe Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /usr/local/bin/wine-pthread /usr/local/bin/notepad.exe [Thread debugging using libthread_db enabled] [New Thread -1211160288 (LWP 9620)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211160288 (LWP 9620)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x7ffb0a40 in wine_server_call (req_ptr=0xbfe60d90) at server.c:321 #2 0x7ffb1bd4 in server_init_thread (unix_pid=9620, unix_tid=9620, entry_point=0x0) at server.c:937 #3 0x7ffb90b1 in thread_init () at thread.c:279 #4 0x7ff99cc6 in __wine_process_init () at loader.c:2365 #5 0xb7e417d6 in wine_init (argc=2, argv=0xbfe61464, error=0xbfe60fd0 "", error_size=1024) at loader.c:664 #6 0x7bf0117a in main (argc=2, argv=0xbfe61464) at main.c:58 (gdb) frame 1 #1 0x7ffb0a40 in wine_server_call (req_ptr=0xbfe34e10) at server.c:321 321 pthread_functions.sigprocmask( SIG_BLOCK, &block_set, &old_set ); (gdb) info locals req_ptr = (void *) 0xbfe34e10 old_set = {__val = {0 <repeats 11 times>, 3219344856, 2147308640, 3219344768, 3084813777, 2147158852, 9, 3219344800, 0, 0, 3219344792, 8, 0, 14, 0, 0, 3219344784, 3084988334, 3219344832, 16, 3219344856, 1}} (gdb) print block_set $1 = {__val = {268511747, 0 <repeats 31 times>}} (gdb) print /a block_set $2 = {__val = {0x10012a03, 0x0 <repeats 31 times>}} (gdb) print /a old_set $3 = {__val = {0x0 <repeats 11 times>, 0xbfe34dd8, 0x7ffd5460 <__wine_dbch___default+340>, 0xbfe34d80, 0xb7de85d1 <sendmsg+33>, 0x7ffb0b44 <wine_server_send_fd+148>, 0x9, 0xbfe34da0, 0x0, 0x0, 0xbfe34d98, 0x8, 0x0, 0xe, 0x0, 0x0, 0xbfe34d90, 0xb7e12fae <__wine_dbg_get_channel_flags+14>, 0xbfe34dc0, 0x10, 0xbfe34dd8, 0x1}} The only thing I can come up with that might cause a segfault in pthread_functions.sigprocmask() is a missing call to a pthread init function. I've grepped through the sources, but unfortunately I was unable to find any place where that is called (except for kthread.c, and I believe that modern systems all use pthread - right?), so I'm without clues. The only thing I can think of that might have happened (other than a Wine bug) is GCC or GLIBC being upgraded by 'emerge world'. GCC --version says "gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)", while ls /lib/libc* says "libc-2.3.6.so". Any suggestions (please!)?

5 6

Where can I get answers concerning winelib?
by Johannes Holzer 01 Aug '06

01 Aug '06

Hi Cause i get no answer to my winelib questions. Where can i ask about winelib? johannes holzer

2 1

usp10: resend Remove a test that fails on Windows
by Jeff L 01 Aug '06

01 Aug '06

This patch fixes a problem where a test fails in windows. It may also fix a problem with 64 bit code but I am unable to test that. I does this by declaring the HDC as global so it can be reused between test runs in test_ScriptItemIzeShapePlace and test_ScriptGetCMap. Change log: Fix glyph comparsion between tests. Jeff

1 0

usp10: Remove a test that fails on Windows
by Jeff L 01 Aug '06

01 Aug '06

This patch fixes a problem where a test fails in windows. It may also fix a problem with 64 bit code but I am unable to test that. I does this by declaring the HDC as global so it can be reused between test runs in test_ScriptItemIzeShapePlace and test_ScriptGetCMap. Change log: Fix glyph comparsion between tests. Jeff

1 0

Re: usp10: Remove a test that fails on Windows.
by Jeff Latimer 01 Aug '06

01 Aug '06

Hans, the test does fail on windows but that is becuase it is checking gylphs that are different between the windows and wine (ie. while the unicode is the same the gylphs are different). I don't know how to overcome that issue. What is it is supposed to do is check that there is a consistent translation between unicode and glyphs. It works 19 times out of 20 on my 32 bit system. Obviously there is an inconsisency. Is there any advice on how to achieve the aim of the test? Jeff Hans Leidekker wrote: >This test fails on Alexandre's system and also fails on my Windows XP >system, so I propose to remove it. > > > -Hans > >Changelog > Remove a test that fails on Windows. > > >------------------------------------------------------------------------ > >001e954162666f1e4de46326c94c7ee357157793 >diff --git a/dlls/usp10/tests/usp10.c b/dlls/usp10/tests/usp10.c >index 2a3d9c4..14ed56c 100644 >--- a/dlls/usp10/tests/usp10.c >+++ b/dlls/usp10/tests/usp10.c >@@ -222,7 +222,6 @@ void test_ScriptGetCMap(unsigned short p > unsigned short pwOutGlyphs3[256]; > WCHAR TestItem1[6] = {'T', 'e', 's', 't', 'a', 0}; > DWORD dwFlags; >- int cnt; > > /* We need a valid HDC to drive a lot of Script functions which requires the following * > * to set up for the tests. */ >@@ -269,10 +268,7 @@ void test_ScriptGetCMap(unsigned short p > hr = ScriptGetCMap(hdc, &psc, TestItem1, cInChars, dwFlags, pwOutGlyphs3); > ok (hr == 0, "ScriptGetCMap should return 0 not (%08x)\n", (unsigned int) hr); > ok (psc != NULL, "psc should not be null and have SCRIPT_CACHE buffer address\n"); >- for (cnt=0; cnt < cChars && pwOutGlyphs[cnt] == pwOutGlyphs3[cnt]; cnt++) {} >- ok (cnt == cInChars, "Translation not correct. WCHAR %d - %04x != %04x\n", >- cnt, pwOutGlyphs[cnt], pwOutGlyphs3[cnt]); >- >+ > hr = ScriptFreeCache( &psc); > ok (!psc, "psc is not null after ScriptFreeCache\n"); > } > > >------------------------------------------------------------------------ > > > >

2 2

Found a sample with source code of the broken character models/misplaced vertices
by Jason Green 01 Aug '06

01 Aug '06

The SkinnedMesh sample from the dx8.1 sdk is broken in shader mode, but you have to change the caps to get anything to show up. In directx.c, I set MaxVertexBlendMatrices to 4 and MaxVertexBlendMatrixIndex to 0 (to match to caps of my machine in Windows), then launched the sample and switched to Software mode, then Shader mode. (if you go straight to shader mode, it crashes - yet another bug. ;-) It results in a broken animation and misplaced vertices like many games have been experiencing: http://www.cmhousing.net/wine/skinnedmesh_broke.png We finally have a simple sample to experiment with which, when fixed, should fix the broken models in most newer games [hopefully].

1 0