June 2003 - Wine-Devel - list.winehq.org

[DSOUND?] SMP problem workaround, more info
by OverrideX June 18, 2003

June 18, 2003

Hi again, Ok so I've found a workaround (not a great one..) for the deadlock I experience running System Shock 2 in wine using a SMP box. I've also tried another game in wine, Jedi Knight 2 which does not deadlock, I'm guessing it has to do with how ss2 is calling sounds, since it seems directly related to dsound underruns, and dsound_main.c says in the todo it's missing critical section locking in some parts of it's code, and it's critical section timeouts with the same address, and different tid's that are in the log when the deadlock occurs. (see older thread for more info....) I decided I needed to try a new kernel, 2.5.70 to see if it was something with my kernel - and I also had an idea of how to work around it. The kernel upgrade still deadlocked, but 2.5.70 has the ability to set hard cpu affinity, so by restricting all the wine processes to only using cpu1, the deadlock disappears - obviously this should be fixed in the code rather than working around it like this, but I can't trace it since it doesn't happen when the game plays slow. It seems like it only happens when the game is playing at a good pace and two or more sounds are about to play at the same time. I hope someone knows what needs to be fixed for this without too much more info, as I'm only a novice coder. But until then I'll do some heavy reading on how wine works and see if I can figure it out myself... cheers -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 It is difficult to legislate morality in the absence of moral legislators.

2 2

Re: Graphics Problem
by Robert Shearman June 17, 2003

June 17, 2003

Rob Hughes said: > make[2]: Entering directory `/usr/src/wine/dlls/opengl32' > gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include > -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 > -gstabs+ -Wpointer-arith -g -O2 -o opengl_ext.o opengl_ext.c > opengl_ext.c:12: redefinition of `GLintptrARB' > /usr/X11R6/include/GL/gl.h:67: `GLintptrARB' previously declared here > opengl_ext.c:13: redefinition of `GLsizeiptrARB' > /usr/X11R6/include/GL/gl.h:68: `GLsizeiptrARB' previously declared here > make[2]: *** [opengl_ext.o] Error 1 > make[2]: Leaving directory `/usr/src/wine/dlls/opengl32' > make[1]: *** [opengl32] Error 2 > make[1]: Leaving directory `/usr/src/wine/dlls' > make: *** [dlls] Error 2 > > This is with cvs as of this morning and NVIDIA 43.63 drivers. > It appears as though a CVS commit 4 days ago added those types. Perhaps Lionel could have a look at these errors? Rob

1 0

Re: PATCH: dlls/cabinet/fdi.c
by Gregory M. Turner June 17, 2003

June 17, 2003

On Tuesday 17 June 2003 03:42 am, Gerald Pfeifer wrote: > This patch removes an unused variable introduced by the recent changes > to this file and thus avoids the following warning: > - cab_UBYTE buf[64], buf2[256] /* for modification [snip] > + cab_UBYTE buf[64] /* for modification by call back fn */ ; Was going to use that as the user-modifiable buffer for the cabinet name in the "Next Cabinet" notification callback, which I never implemented, as it's part of the split cabinets puzzle. I promise this warning will go away with my next patch. Sorry about that, I've been known to give others an earful for leaving warnings lying around, so I will not complain if the patch is applied, although this would create a trivial merge situation for me, as the variable will probably have to be revived again in my next patch. Also, the patch is incorrect, buf2 only, not buf, is for modification by the callback, so if we kill the variable, we should also kill the comment. My apologies for the superfluous warning! -- "Socialism in general has a record of failure so blatant that only an intellectual could ignore or evade it." -- Thomas Sowell gmt

2 1

Re: ntdll/kernel32: #27
by Alexandre Julliard June 17, 2003

June 17, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - this patch partially implements this scheme. It's partial because > console handles are still handled by wineserver. Their value is > however obfuscated so that we can track their real usage. IMO you shouldn't need to have any obfuscation code in the server at all. If you need that, something is wrong with the design. > - next step would mean implementing the console handle management > outside of wineserver (likely in wineconsole) I'm not convinced we really need that; IMO it's OK to keep them in the server, as long as we can identify them as console handles from the client. -- Alexandre Julliard julliard(a)winehq.com

2 6

Re: Dmusic interfaces
by Rok Mandeljc June 17, 2003

June 17, 2003

Hi everyone. Sorry for not contributing anything to dmusic in a while, but I'm currently busy with final exams... As I can see, more work was done on it :) > Is anyone of you working on Dmusic interfaces ? > Now doing test with Dxdiag doesnt work, > it says "No such interface" when trying to create a IDirectPerformance > object. This problem can be fixed with adding a if (IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance) || IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance8)) in DMUSIC_CreateDirectMusicPerformance8 (at the time being, there's check for IID_IDirectMusicPerformance8 only). But even with this added, dxdiag creates interface, calls some functions and then crashes (though I have no idea why). I was looking at code and i wonder if it's ok to allocate memory for interfaces like this: segment = (IDirectMusicSegmentImpl*)HeapAlloc(GetProcessHeap(),0,sizeof(IDirectMusicImpl)); I mean, it's IDirectMusicSegmentImpl, why using size of IDirectMusicImpl then? (or this doesn't matter?) Another thing... does anyone of you know how to write effective chunk loading function (it will be needed sooner or later since most dmusic objects are stored in files)? -- Rok Mandeljc <rok.mandeljc(a)gimb.org> "All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. >From the ashes a fire shall be woken, A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be king." -- J.R.R. Tolkien

2 1

TTYDRV woes :/
by Kye Lewis June 17, 2003

June 17, 2003

Heyas, Firstly, (for those of you who really care - or who even have a clue who I am.)... I'm back again, and ready for some wine action :) Anyway.... I'm having a bit of a problem with *running* wine stuff - more specifically TTYDRV... I'm getting lots of messages like "fixme:ttydrv:TTYDRV_CreateWindow (10045): stub" (obviously with different actual functions blah blah...) And I have no idea... And yes, before you ask, I am running this in X :) - I've tried CVS, i've tried compiling from a tar.gz, i've tried RPM's, and all seem to produce the same result. I'm using the latest nVidia drivers (from www.nvidia.com) if that would make any difference. Anyone else experienced this problem? Thanks, Kye Lewis ========================= kye(a)lewislan.id.au or, if that doesn't work: kyethespy(a)softhome.net will!

2 1

Re: TypeLib containment refcounting
by Alexandre Julliard June 17, 2003

June 17, 2003

Mike Hearn <mike(a)theoretic.com> writes: > ChangeLog: > When providing a TypeInfo object, inc/dec the refcount so that programs > don't call GetContainingTypeLib and crash as the container has been > destroyed. This doesn't look right, you increment the refcount on every GetTypeInfo but only decrement when the typeinfo object is destroyed. -- Alexandre Julliard julliard(a)winehq.com

5 10

RPMs and fake windows drive
by Mike Hearn June 17, 2003

June 17, 2003

Hi, How many of the RPMs up on the download section create a fake windows drive? If the answer is all of them, then we should probably remove the part of the howto that tells people to manually create their drive, as it causes confusion in newbies who don't understand why they are told in one place that they need it, and told in another that they don't. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

vfat utf8 read problems
by olivier June 17, 2003

June 17, 2003

Hello, I'm using environment with gtk 2.x..x - gnome 2.x.x e.g. RedHat 9. gtk 2.x work (only) with charset UTF-8. I share documents on a vfat disk. To see correctly the file name with gnome, I must use the utf8 option in the fstab. But in this case, I can't see the files bigger than 8 chars with the Wine DialogFileOpen. Sorry for my poor English. Regards, Olivier the windebug messages: -------------------------------------------------- err:dosfs:DRIVE_ReadSuperblock Couldn't open device for drive I: ! (not available, symlink not valid or no permission) Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '.wine/config' err:dosfs:DRIVE_GetLabel Invalid or unreadable superblock on (I:). err:dosfs:DRIVE_ReadSuperblock Couldn't open device for drive I: ! (not available, symlink not valid or no permission) Perhaps you have not properly edited or created your Wine configuration file. This is (supposed to be) '.wine/config' Invalid or unreadable superblock on (I:). Maybe not FAT?

1 0

Re: Re: [DMUSIC07] more
by fenix＠club-internet.fr June 17, 2003

June 17, 2003

Hi >> PS: Christian with your last patch dmusic crash when WinMM is disabled (no >> sound drivers => DirectSoundCreate8 returns an error) >> >Ok, I will do more checks. :) >But how do you disable WinMM explicitely? By removing the driver >name in the config file? "Drivers" = "" >Bye, >Christian Regards, Raphael

1 0