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

Re: BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Jesse Allen

On 8/29/05, Ge van Geldorp <gvg(a)reactos.com> wrote: > > From: Vijay Kiran Kamuju > > > > 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? > > Most of the code in our C Runtime originates from the DJGPP compiler > package. I've checked, the DJGPP libc is LGPL. So I think using this in Wine > should be no problem. > > Gé van Geldorp. > > > > Quick question. Does React OS or DJGPP include a portable implementation of printf in msvcrt? I tried looking using your source browser but I could not tell where it is actually located. Jesse

Aug. 29, 2005

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)

by Robert Reif

Alex Villacís Lasso wrote: > Robert Reif wrote: > >> Alex Villacís Lasso wrote: >> >>> The first test that fails with the ALSA driver is the so-called >>> "reference" tone, which, as far as I could see, is played with a >>> primary buffer, and no secondary buffer. The reference tone uses the >>> hardware position directly, which wraps around at a buffer size that >>> changes unexpectedly when switching playback formats. I have >>> prepared a patch that "fixes" this, by re-querying the buffer size >>> in the case of a primary buffer, and displaying a warning if it >>> detects a buffer size change. However, I don't know if the buffer >>> size is supposed to remain constant across buffer format changes. If >>> it does, then the patch would need to be modified to mark this as a >>> TODO. >> >> >> >> Fix the wine ALSA driver rather than the test unless you can prove >> that the test fails on Windows. >> > This is a modified patch that marks the problematic buffer resize as a > todo_wine. Could somebody please test this patch and confirm that the > buffer size actually remains constant across playback format changes? > The problem is that the wine ALSA driver creates a fixed time buffer rather than a fixed size buffer. Please try your patched test on a real Windows 9X system and on a Windows 2k/xp system. Windows 2k up doesn't really have a hardware primary buffer because of kmixer but a Windows 9X vdx driver will communicate directly with the hardware. If the test fails on Windows, then we need to change the direct sound implementation to read the new buffer size. Otherwise we need to change the ALSA driver to always create a fixed buffer size regardless of the requested format (like OSS). We can fix the test and the direct sound dll to work around ALSA's current behavior but that won't help other apps that depend on the primary buffer size not changing if that's what Windows really does.

Aug. 29, 2005

Re: Possible critical section bug - lock by invalid thread

by James Liggett

I also see this in PokerStars.NET (an online poker game) In my case, I believe the threads are valid however. I'll check on that and get back to you. I notice it after playing the game for about a half-hour, sometimes a bit longer. When this happens, I also noticed that I can barely move my mouse, CPU usage is maxed, and the hard drive is busy too. I think your theory about a race condition is probably correct. The odd thing is I see this in both ALSA and OSS sound modes, so I don't think the problem is there, but is more likely to be somewhere the server, because any critical section used by a running Windows program seems to be affected. I get wait timeouts like what you're showing everywhere in Wine (x11drv, sound, anything) Perhaps you should post a full output the errors you get someplace on the web. (I imagine it'll be too big for the list) James On Mon, 2005-08-29 at 14:07 -0500, Alex Villacís Lasso wrote: > 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 > >

Aug. 29, 2005

theming error on initial startup

by Stefan Leichter

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

Aug. 29, 2005

Re: DDraw: Better flag handling in SetCooperativeLevel

by Stefan Dösinger

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 )

Aug. 29, 2005

standard load address for a Win32 program (0x00400000) not available

by James Hawkins

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

Aug. 29, 2005

Re: KERNEL: check for NULL in LoadModule16

by Andreas Mohr

Hi, On Mon, Aug 29, 2005 at 01:43:04PM -0500, Alex Villacís Lasso wrote: > I could not find any MSDN reference on any documented behavior for > LoadLibrary16 or LoadModule16 when libname == NULL. > > Even if Windows does not check for NULL in this function, I do not think > that the bug-for-bug compatibility should extend to the point where Wine > crashes on the same invalid parameters as Windows does. This only leaves That's what you think, but we will DEFINITELY want bug-for-bug compatibility (well, except for fringe cases, which that one isn't, IMHO). (no criticism) We really want that, even if it's only used to be sure that an error is an error (in order to realize immediately that something is badly wrong since the program shouldn't behave that way). Simply returning an *illegal* return code instead of crashing (like Windows!) is NOT an option. All that assuming that Windows LoadModule16 does crash, of course... > the exact value of the return value - I don't have the tools to generate > a 16-bit executable under Windows, or else I don't know of any freely > available ones, so I could only check the 32-bit LoadLibrary. Maybe > somebody could point me to an URL to download a 16-bit compiler for > Windows? You want OpenWatcom, believe me. You want it. Badly! :) (I have an old NonopenWatcom installation here, so I'll write a short test, but maybe you'll even beat me to it) > The specific value of ERROR_READ_FAULT was chosen because a) it is less > than 31, as the MSDN documents, b) it is the closest description of what > happens when the function attempts to use the parameter without checking. Wine cannot choose or guess. Wine has to know. Even a single bit can be different and cause as much harm as making a whole Windows program fail... (which is why so many people say that "Wine is crap, it doesn't work": one single "completely irrelevant" difference can cause a terrible amount of trouble, no matter how absolutely incredibly perfect all the remaining parts of Wine are) Andreas

Aug. 29, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Michael Jung

On Monday 29 August 2005 18:09, Duane Clark wrote: > I am seeing it now, using winecfg and browsing to "Add application..." > in the Applications tab. And this entirely within wine drives. Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Aug. 29, 2005

Re: Theme regression

by Paul Vriens

On Mon, 2005-08-29 at 21:08, Paul Vriens wrote: > Hi, > > with the latest CVS I'm seeing major graphical glitches when using a > theme. After 'disabling' theming the glitches are gone, so it points to > theming. > > No regression testing done yet. Anybody else seeing this problem ? > > Paul. > > > It's http://cvs.winehq.org/patch.py?id=19861 Any idea's ? Cheers, Paul.

Aug. 29, 2005

Theme regression

by Paul Vriens

Hi, with the latest CVS I'm seeing major graphical glitches when using a theme. After 'disabling' theming the glitches are gone, so it points to theming. No regression testing done yet. Anybody else seeing this problem ? Paul.

Aug. 29, 2005