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

Re: [resend] atl.DllRegisterServer
by Alexandre Julliard 30 Aug '05

30 Aug '05

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hi Alexandre, > > anything wrong with this patch ? Well, the resource id is 1, so loading it with 0x65 is certainly not going to work. Were you planning to change the resource too? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: WLDAP32: implement more functions
by Vitaly Lipatov 30 Aug '05

30 Aug '05

В сообщении от 29 Август 2005 23:26 Hans Leidekker написал(a): > -Hans > > Changelog > Implement ldap_count_entries, ldap_count_references, > ldap_first_attribute*, ldap_first_entry, ldap_first_reference, > ldap_next_attribute*, ldap_next_entry and ldap_next_reference. I guess, this patch cause an compile error: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before "BerElement" winldap_private.h:290: error: syntax error before "BerElement" winldap_private.h:322: error: syntax error before "BerElement" winldap_private.h:323: error: syntax error before "BerElement" -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

BUG[1481] : unimplemented function msvcrt.dll._mbsbtype
by Vijay Kiran Kamuju 30 Aug '05

30 Aug '05

Hi, can we use the reactos implementation of the _mbsbtype? http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html Any ReactOS guys, please respond regarding the licensing of the above code? Thanks, Vijay

4 6

Re: wine/ include/prsht.h include/commctrl.h dlls/ ...
by Frank Richter 30 Aug '05

30 Aug '05

On 30.08.2005 12:07, Alexandre Julliard wrote: > Log message: > Frank Richter <frank.richter(a)gmail.com> > Fix warnings in 64bit. No I didn't; something must have been mixed up while making the commit message. -f.r.

1 0

Possible critical section bug - lock by invalid thread
by Alex Villacís Lasso 30 Aug '05

30 Aug '05

In several RPG I have been testing, I have found deadlocks on the sound thread - the sound loops on and on, and the program freezes. At the same time, I see messages like the following: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fe32708)->(00010022,00000008) err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82310 err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82880 err:wave:DSDB_MMAPCopy mmap partially failed. err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) I thought that DirectSound was not performing locking properly, until I noticed the following: all the times I see this deadlock, the thread ID "responsible" for the deadlock is 0000. From a little digging in the code, I see that 0 is the value used in the critical section when it is not held by any thread. So these are potentially cases where a previous thread frees the critical section, but somehow the critical section remains locked. I think I saw a select() call in the wineserver, used as an implementation for this wait, and this select() call times out, resulting in the behavior shown above. All these instances happen under heavy CPU load, so I suspect some sort of race condition. If I really try and bog down the CPU, I can even trigger this deadlock on the DirectSound tests (under ALSA). Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome. Alex Villacís Lasso

3 2

Possible theming bug?
by James Liggett 30 Aug '05

30 Aug '05

Hi, Yesterday I updated CVS and tried the new theme system. While I find it very impressive, I think I may have discovered a glaring problem with it. I copied the WinXP "Luna" theme from my XP partition into the Resources folder as directed by this week's WWN issue. It showed up in the Appearances tab as "Windows XP style." It works quite well, shown here: http://members.cox.net/jrliggett/screenshots/theme.png. After deciding that I preferred the old style, I set the theme back to "(No theme)" But, there was a problem: all the colors that the theme I had before were still there (but no other visual effects)--and not the usual dark gray/blue combination. Here's a shot of what I mean: http://members.cox.net/jrliggett/screenshots/theme-bug.png Is this type of behavior a bug or am I doing something wrong? Thanks, James

1 0

WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
by Alex Villacís Lasso 29 Aug '05

29 Aug '05

Alex Villacís Lasso wrote: > >> The good news: the patch sort of works (in my setup, at least, with >> Fedora Core 4). All the games I have (Japanese RPGs) now have smooth >> sound, unless the CPU load is too high. >> The bad news: the patch does nothing to make the dsound tests pass in >> Wine (but they were already failing before the patch :-) > > > In a previous post, I commented about DirectSound tests failing when > ALSA is used with full hardware acceleration. Now I know the reason why. > > As far as I can glean from the code, DirectSound is supposed to report > the application several properties of the sound system, including the > size of the hardware buffer. This hardware buffer is queried by the > snd_hw_params_get_buffer_size(), and is then converted from frame > units to bytes. Then the application, or in this case, the test, > expects the buffer size to remain constant for each and every hardware > buffer created, regardless of requested format. Only this assertion > fails in ALSA. For example, the capability query causes the following > output to be shown: > > trace:wave:DSDB_CreateMMAP format=U8 frames=11025 channels=2 > bits_per_sample=8 bits_per_frame=16 > trace:wave:DSDB_CreateMMAP created mmap buffer of 11025 frames (22050 > bytes) at 0x7c0fd100 > > This reported size (22050 bytes) remains constant as long as the > request is for U8 format with 2 channels (although the mmap address > jumps between three different values in my setup; this may or may not > be relevant). However, as soon as the requested format changes, the > trace shows the following: > > trace:wave:DSDB_CreateMMAP format=S16_LE frames=3763 channels=2 > bits_per_sample=16 bits_per_frame=32 > trace:wave:DSDB_CreateMMAP created mmap buffer of 3763 frames (15052 > bytes) at 0x7c0fd6b8 > > There goes a fourth mmap address, but the truly interesting thing is > that the buffer size also changes, and no longer matches the > previously reported size of 22050 bytes. The test then goes and plays > a 5-second sound with the (now incorrect) buffer size of 22050 bytes, > not noting that the reported position is wrapping around at 15052 bytes: > > ds3d.c:431: Playing 5 second 440Hz tone at 11025x16x2 > > ... > > trace:dsound:DSOUND_PrimaryGetPosition (0x7fe03ab8,0x7fa6fa80,(nil)) > trace:wave:IDsDriverBufferImpl_GetPosition hw_ptr=0x00000000, > playpos=0, writepos=-1, mmap_buflen_bytes=15052 > trace:dsound:DSOUND_PrimaryGetPosition playpos = 0, writepos = 0 > (0x7fe03ab8, time=1913) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 0, > writepos = 0 (0x7fe03ab8, time=1913) > ds3d.c:230:buf size=22050 last_play_pos=0 play_pos=0 played=0 / > 220500, fraction_played=0 > ds3d.c:248:offset=15052 free=6998 written=15052 / 220500 > > ... > ds3d.c:230:buf size=22050 last_play_pos=10296 play_pos=11700 > played=11700 / 220500, fraction_played=1404 > ds3d.c:248:offset=10296 free=1404 written=32346 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=11700 play_pos=13104 > played=13104 / 220500, fraction_played=1404 > ds3d.c:248:offset=11700 free=1404 written=33750 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=13104 play_pos=14508 > played=14508 / 220500, fraction_played=1404 > ds3d.c:248:offset=13104 free=1404 written=35154 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=14508 play_pos=860 > played=22910 / 220500, fraction_played=8402 > ds3d.c:248:offset=14508 free=8402 written=36558 / 220500 > > Please note that the play_pos wrapped from 14508 to 860 because it > exceeded 15052 bytes, but the test assumes it wrapped around at 22050 > bytes, so it miscalculates the fraction_played, advancing it at an > abnormally fast rate. That is how the following result ensues: > > trace:dsound:DSOUND_PrimaryGetPosition playpos = 176, writepos = 0 > (0x7fe03ab8, time=5366) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 176, > writepos = 0 (0x7fe03ab8, time=5366) > ds3d.c:230:buf size=22050 last_play_pos=13824 play_pos=176 > played=220676 / 220500, fraction_played=8402 > ds3d.c:237:all the samples have been played, stopping... > ds3d.c:279:stopping playback > trace:dsound:PrimaryBufferImpl_Stop (0x7fe143b8) > ds3d.c:628: Test failed: The sound played for 3453 ms instead of 5000 ms > > Many other tests with formats other than U8, 11025Hz fail for the same > reason. Any other DirectSound application that reuses the buffer size > as the test does will fail in the same way (music mixing up and > prematurely stopping). However, I am to understand that this test > passes on Windows, in all versions. > > Now that I have found the issue, I ask for help in suggesting a proper > fix. I think that the ALSA implementation used to have a separate > buffer from which samples were copied into the hardware buffer, but > this implementation was scrapped for some reason (and I think, without > re-running the ALSA tests). So I tried using > snd_hw_params_set_buffer_size() - it fails to set the buffer size to > the previously reported size. So I am still thinking about this. Any > comments or suggestions for fixing this will be greatly appreciated. > > BTW, does the DirectSound API allow the application to access the > hardware mmap directly (that is, not just by specifying the buffer to > be played)? If not, one possible solution would be to remember the > first reported buffer size, and wrap the *reported* position around at > that buffer size, even when the ALSA playback uses the real buffer > size. However, when I tried to do this (by hardcoding 22050 as a > wraparound value, just as a test), Wine promptly crashed, so I need > more insight into this. > > Alex Villacís Lasso > Resending because previous attempt probably was rejected due to gigantic attachment (my bad).

2 5

theming error on initial startup
by Stefan Leichter 29 Aug '05

29 Aug '05

Hello, starting wine (current cvs) without the .wine directory leads to the error below. Do i miss something? Bye Stefan wine: creating configuration directory '/home/sle/.wine'... err:theming:THEMING_Initialize Could not re-register class L"#32770": 582 err:theming:THEMING_Initialize Could not re-register class L"ComboBox": 582 err:theming:THEMING_Initialize Could not re-register class L"ComboLbox": 582 err:theming:THEMING_Initialize Could not re-register class L"Edit": 582 err:theming:THEMING_Initialize Could not re-register class L"ListBox": 582 wine: '/home/sle/.wine' created successfully. Wine 20050725 Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit

1 0

Re: DDraw: Better flag handling in SetCooperativeLevel
by Stefan Dösinger 29 Aug '05

29 Aug '05

Am Donnerstag, 25. August 2005 18:45 schrieb Stefan Dösinger: > Hello, > This patch adds better handling for the flags in > Main_DirectDraw_SetCooperativeLevel. The function reacts to > DDSCL_SETFOCUSWINDOW, DDSCL_CREATEDEVICEWINDOW and DDSCL_SETDEVICEWINDOW. > It doesn't really handle them, but it returns the correct return values. > The patch also contains a lenghty test which I used to verify the behaviour > with Windows 2000. Is anything wrong with this patch? Any reason why it wasn't applied? Stefan (link to archive: http://www.winehq.org/hypermail/wine-patches/2005/08/0648.html )

1 0

standard load address for a Win32 program (0x00400000) not available
by James Hawkins 29 Aug '05

29 Aug '05

Hi, I'm trying to run googletalk.exe with wine-pthread in order to debug the application. Running it fails with this error: $ /usr/bin/wine-pthread googletalk.exe err:virtual:map_image Image was mapped at 0xfb0000: standard load address for a Win32 program (0x00400000) not available err:virtual:map_image Do you have exec-shield or prelink active? wine: could not load L"Z:\\home\\truiken\\googletalk.exe" as Win32 binary exec-shield and prelink are definitely disabled, and running other native .exe's with wine-pthread work fine. Anyone have any ideas what the problem is, or how I can get this to work? -- James Hawkins

1 0