March 2006 - Wine-Devel - list.winehq.org

Re: Known issues area on main wiki page

by Segin

Mike McCormack wrote: > > Segin wrote: > >> aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the >> 4.0 release, Skype crashes if you use artsdsp with it and play sound, >> arts is also known to just segfault for no reason whatsoever. Best >> suggestion is to drop support for aRts entirely, it won't be around >> much longer. > > > aRts is not the only library giving trouble here. Here's one caused by > ALSA: > > http://bugs.winehq.org/show_bug.cgi?id=4901 > > Getting rid of aRts may cripple Wine on older systems, and it won't > solve the problem. We can't rely on all 3rd party sound libs to be > bug free, especially since there's a lot of dodgy homebrew systems out > there built by people who *think* they know what they're doing... > > Allowing users to use the Audio tab in WineCfg without forcing > possibly buggy libraries to load is a better option. > > Mike > Well, can we at least put in warnings when aRts support is enabled in winecfg (e.g. a popup that states that arts itself is buggy and it's use is not recomended?) Well, if we can't take support out, that there is a hell of a lot better than doing absoutly nothing. at least people get a warning when they do stupid stuff.

March 21, 2006

Re: Known issues area on main wiki page

by Jesse Allen

On 3/20/06, Mike McCormack <mike(a)codeweavers.com> wrote: > > Dimi Paun wrote: > > On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > > Navea) wrote: > > > >>clicking on the audio tab to check out bug 4051 first? Please! > > > > > > How about we fix the problem instead? :) > > The best way to fix it is probably to rearrange the code so that the > Audio tab shows, then there's a [Detect] button that the user can click > to run the autodetect code that might crash. At least then the user can > set their Wine Audio settings manually. > > Mike > > This is not enough, as when I click the audio tab, it will lock up in the kernel. I already identified where it happens and patch the kernel myself. I told the ALSA devs, but they haven't looked at why certain register usage causes a lockup. So it remains in the stable kernel who knows who else hits it. Jesse

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Dimi Paun wrote: > On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote: > >>Allowing users to use the Audio tab in WineCfg without forcing >>possibly buggy libraries to load is a better option. > > Sure, but they are not mutually exclusive. If the current > patch also prevents the crash, they can go well hand in hand. Looks to me like the patch in bug #4051 only catches aRts exceptions. Bug 4901 looks like it's caused by libasound problems. Exception handlers can't catch system hangs, which I've seen when some audio drivers are loaded, they can't clean up properly after the buggy library, and the library might leave the stack or heap corrupted. Moving the autodetect feature to a button in the Audio tab seems like a simple design change that will solve the problem once and for all. It allows configuration to be done manually, even if buggy libraries are present, which the current implementation doesn't. Mike

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Tue, 2006-03-21 at 15:35 +0900, Mike McCormack wrote: > Allowing users to use the Audio tab in WineCfg without forcing > possibly buggy libraries to load is a better option. Sure, but they are not mutually exclusive. If the current patch also prevents the crash, they can go well hand in hand. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Re: Known issues area on main wiki page

by Segin

Dimi Paun wrote: >On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote: > > >>The best way to fix it is probably to rearrange the code so that the >>Audio tab shows, then there's a [Detect] button that the user can >>click to run the autodetect code that might crash. At least then the >>user can set their Wine Audio settings manually. >> >> > >There is a patch in Bugzilla (posted Sun) that simply catches the >exception and avoids the crash that way. I think it's probably >good enough for the arts business, it's a dead-end anyway. > > > aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 release, Skype crashes if you use artsdsp with it and play sound, arts is also known to just segfault for no reason whatsoever. Best suggestion is to drop support for aRts entirely, it won't be around much longer.

March 21, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Stefan Dösinger

Am Montag, 20. März 2006 23:26 schrieb Lionel Ulmer: > Well, in OpenGL each thread can have its own context (and you can also bind > a context to only one thread which explains why multi-threaded D3D > applications are such a pain to support). So you can have multi-threaded GL > applications with each thread having its own GL context. What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads. A little bit OT, but related to multi-threaded opengl is a bug in the dri radeon driver(https://bugs.freedesktop.org/show_bug.cgi?id=6240). I've reported it to the dri devs but didn't get any response so far. Stefan

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Segin wrote: > aRts in and of itself is a b/uggy ha/ck, KDE is droipping it in the 4.0 > release, Skype crashes if you use artsdsp with it and play sound, arts > is also known to just segfault for no reason whatsoever. Best suggestion > is to drop support for aRts entirely, it won't be around much longer. aRts is not the only library giving trouble here. Here's one caused by ALSA: http://bugs.winehq.org/show_bug.cgi?id=4901 Getting rid of aRts may cripple Wine on older systems, and it won't solve the problem. We can't rely on all 3rd party sound libs to be bug free, especially since there's a lot of dodgy homebrew systems out there built by people who *think* they know what they're doing... Allowing users to use the Audio tab in WineCfg without forcing possibly buggy libraries to load is a better option. Mike

March 21, 2006

Re: New Linux System calls (*at) in 2.6.16

by Marcus Meissner

On Tue, Mar 21, 2006 at 10:59:39AM +1100, Troy Rollo wrote: > Google for these combined with keywords related to Wine didn't show anything, > which surprised me since they seem ideal to solve a number of problems. A > bunch of new calls have been added to the Linux kernel 2.6.16 > <http://lwn.net/Articles/164887/> that are mirrors of the existing system > calls but take a file descriptor for a directory that becomes the base point > for relative paths. glibc support is needed too, and not a lot of people use glibc 2.4 yet. Oh, and: $ grep futimesat configure.ac libs/port/futimes.c configure.ac: futimesat \ libs/port/futimes.c: return futimesat( fd, NULL, tv ); $ Ciao, Marcus

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Tue, 2006-03-21 at 14:14 +0900, Mike McCormack wrote: > The best way to fix it is probably to rearrange the code so that the > Audio tab shows, then there's a [Detect] button that the user can > click to run the autodetect code that might crash. At least then the > user can set their Wine Audio settings manually. There is a patch in Bugzilla (posted Sun) that simply catches the exception and avoids the crash that way. I think it's probably good enough for the arts business, it's a dead-end anyway. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Re: Known issues area on main wiki page

by Segin

March 21, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > > [Let's use Abiword as the app to test, as I proposed long ago:] But before we do that, let's have a good gui test for wine's own notepad and wordpad. First things first, eh? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: Known issues area on main wiki page

by Mike McCormack

Dimi Paun wrote: > On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin > Navea) wrote: > >>clicking on the audio tab to check out bug 4051 first? Please! > > > How about we fix the problem instead? :) The best way to fix it is probably to rearrange the code so that the Audio tab shows, then there's a [Detect] button that the user can click to run the autodetect code that might crash. At least then the user can set their Wine Audio settings manually. Mike

March 21, 2006

Re: Known issues area on main wiki page

by Dimi Paun

On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: > clicking on the audio tab to check out bug 4051 first? Please! How about we fix the problem instead? :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 21, 2006

Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

I'm not trying to be a whiner here, but I think enough is enough when it comes to having to close bugs as a duplicate. There has to be some simple solution to cut down on the number of new bugs filed that report that winecfg crashes when clicking on the audio tab. I know that the subject above isn't it, but it is at least a start. I was about to create it myself, but my better judgement said I should ask here first. Can someone please(!) put something on some page that almost everyone sees saying that if you are having a problem with winecfg crashing when clicking on the audio tab to check out bug 4051 first? Please! Thanks Tom

March 21, 2006

Re: disallow networking flag

by Willie Sippel

Am Montag, 20. März 2006 12:55 schrieb n0dalus: > On 3/20/06, rauschenimweltnetz(a)web.de <rauschenimweltnetz(a)web.de> wrote: > > I think it would be very usefull to disallow an application started with > > wine to connect to the network/internet by an options flag. > > > > Unless somebody would help me to find out what I have to change... So I > > would try it by myself. But in consideration of the fact that I need this > > feature as soon as possible I would better like to just watch and > > learn... ;) > > I don't know how much of wine's source would need to be changed to > disallow all network commands, but I know that this kind of thing is > possible using iptables (particularly with the owner extension). > > If you create a new user id (which will be the one you use to start > the application, using su or sudo), something like 'nonet', then run > the following: > > iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with > imcp-net-unreachable > > or something like that (I haven't tested it), it will block the > 'nonet' user and any applications started as it from sending network > packets. > I think what Rauschi suggested was a per-application setting to disable network access. A checkbox in winecfg or something. I think iptables won't help there, but I think such a setting could be helpfull - preventing applications from calling home and such...? -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 21, 2006

New Linux System calls (*at) in 2.6.16

by Troy Rollo

Google for these combined with keywords related to Wine didn't show anything, which surprised me since they seem ideal to solve a number of problems. A bunch of new calls have been added to the Linux kernel 2.6.16 <http://lwn.net/Articles/164887/> that are mirrors of the existing system calls but take a file descriptor for a directory that becomes the base point for relative paths. -- Troy Rollo - wine(a)troy.rollo.name

March 20, 2006

Re: function counting script, memcheck.sh

by Segin

attached. Joris Huizer wrote: > Segin wrote: > >> Attached is version 0.2 of this script, with a lot of additional >> functionality. You will need to be able to write to /tmp and make a >> file /tmp/grep to use the extended functionality (default >> functionality needs none of that, and is unmodified.) >> > > Your message does not have the script attached, could you resend > please :-) > > regards, > > Joris > > >

March 20, 2006

Re: function counting script, memcheck.sh

by Joris Huizer

Segin wrote: > Attached is version 0.2 of this script, with a lot of additional > functionality. You will need to be able to write to /tmp and make a file > /tmp/grep to use the extended functionality (default functionality needs > none of that, and is unmodified.) > Your message does not have the script attached, could you resend please :-) regards, Joris

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Mon, Mar 20, 2006 at 05:09:53PM +0100, Leon Freitag wrote: > I don't think it would be that hard to realize. Right now we have the > ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c > and norm.c) where the check and sync occurs. One solution would be to make > two enter_gl functions -- one with the check and one without, and hardcode > some database with the function list in the script that generates the files. I agree, not hard at all to do, but the database needs to be maintained and it would mean that upgrading to new extensions would not be 'automatic' as it is now as one would need to review manually all new extensions to check the one that can modify / access the FB. Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Mon, Mar 20, 2006 at 05:37:50PM +0100, Leon Freitag wrote: > Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I > don't know if there are applications that draw opengl in multiple threads in > different contents, and if current code would make any problems with these. Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context. So instead of retrieving the context on each ENTER_GL / LEAVE_GL macro using the GLX call, one can simply store the currently bound context for the current thread in a thread-local variable. This is what Mike's patch does. Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 20, 2006

Re: winedbg: resend - add display for floating point status

by Eric Pouech

I'm getting picky, but there are a couple of things you still need to work on: - first, I don't think it's worthwhile to add another method to the CPU backend. Adding a boolean (as parameter) to print_context should do. - you also need to fix all the be_*.c files (for amd, ppc...) as well. Otherwise, they won't compile. The rule of thumb is never commit a patch that breaks compilation on some platforms. - one of the test looks suspicious (shouldn't it be if (!(ctx->loatSave.StatusWord & 0x00000001)) instead ?) > + if (!ctx->FloatSave.StatusWord & 0x00000001) A+ -- Eric Pouech

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/20/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > Dimi Paun wrote: > > Being able to run an emulation layer like msys/cygwin > > In my experience (couple of years worth of different Cygwin versions, > all relatively new stuff), the Cygwin kernel emulation stuff is > extremely unstable itself. unstable in the sense that it changes all the time, yes. msys, on the other hand, is working off a frozen snapshot of cygwin from long ago, and never changes. So it's stable in at least that sense. I have no idea how buggy it is. It works well enough to run configure scripts on real windows, though. > There are a couple of other Windows-->Unix emulation kits readily > available, so shouldn't be hard to find something that both runs > reliably and can make ./configure scripts work... Oh, really? Got URLs? Have you tried any of them on wine? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Re: Easy applications to write automated tests for?

by Molle Bestefich

Dimi Paun wrote: > Being able to run an emulation layer like msys/cygwin In my experience (couple of years worth of different Cygwin versions, all relatively new stuff), the Cygwin kernel emulation stuff is extremely unstable itself. So that would probably get you a heck of a lot of false positives in terms of faults occurring. There are a couple of other Windows-->Unix emulation kits readily available, so shouldn't be hard to find something that both runs reliably and can make ./configure scripts work...

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

P.S. Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I don't know if there are applications that draw opengl in multiple threads in different contents, and if current code would make any problems with these. Leon

March 20, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

> Does that work any better? The patch works wonderfully! Thank you very much! The only thing is that you have to modify the Makefile.in in the opengl32 directory and add "ntdll" to the libs list. > Well, to make this work better, one would need a two-tiered approach: > = use thread-local variables to check if it's a 'special' buffer or not > (like this patch does) > = only do this check on GL APIs that actually modify or read from the frame > buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...). > The last is easy to do for 'core' stuff, a bit harder for extensions though. > But anyway, this is mandatory if one day we want to fix the 'windowed' > OpenGL code properly (whatever the method we choose as long as we do not > have the GLX extension exporting the clip list feature to the application). I don't think it would be that hard to realize. Right now we have the ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c and norm.c) where the check and sync occurs. One solution would be to make two enter_gl functions -- one with the check and one without, and hardcode some database with the function list in the script that generates the files. This patch does already a great job for fixing Huw's regressions, and me and many Wine users would greatly appreciate its merge into Wine tree. Leon

March 20, 2006