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

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

On 3/21/06, Bryan Mayland <bmayland(a)leoninedev.com> wrote: > Dan Kegel wrote: > > Yes. Make the code as small and simple as possible > > to check that one limit. > > > I've sent the patch to wine-patches as suggested at winehq. I'm not > subscribed to that list though, so let me know if there are any problems > receiving it or you don't like the test case. I haven't seen it yet at http://www.winehq.org/pipermail/wine-patches/2006-March/ so perhaps there was some trouble with mail. Did you make sure the test passed on both wine and windows when built as a standalone program? e.g. if you happen to have msvc and the platform sdk installed, and have your environment set up right, you can just do cd dlls/kernell/tests cl -DSTANDALONE -D_X86_ -I../../../include sync.c to compile the test as a standalone app, and then run sync.exe on both Windows and Wine. - Dan > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

Dan Kegel wrote: > Yes. Make the code as small and simple as possible > to check that one limit. > I've sent the patch to wine-patches as suggested at winehq. I'm not subscribed to that list though, so let me know if there are any problems receiving it or you don't like the test case. Thanks for your guidance!

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

On 3/21/06, Bryan Mayland <bmayland(a)leoninedev.com> wrote: > ...My test app is 150 lines of ugly > code whose purpose was to narrow down where the problem was, which was > that MAXIMUM_WAIT_OBJECTS weren't supported. You probably don't want to > put all that socket code in just to test the event system. Right. > Should the > test I create actually just create MAXIMUM_WAIT_OBJECTS events and do a > wait on them to verify that it can be done? Yes. Make the code as small and simple as possible to check that one limit. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

Dan Kegel wrote: > Congratulations, sounds like you found a bug in Wine! > Yay! I'm glad I'm not crazy. > Looks like it should be changed. > > You've helped greatly with your post. > You could help even more by posting a patch > that modifies dlls/kernel/tests/sync.c to incorporate your test > and also fixes the error. Yeah this is no problem at all. My test app is 150 lines of ugly code whose purpose was to narrow down where the problem was, which was that MAXIMUM_WAIT_OBJECTS weren't supported. You probably don't want to put all that socket code in just to test the event system. Should the test I create actually just create MAXIMUM_WAIT_OBJECTS events and do a wait on them to verify that it can be done?

March 21, 2006

Re: Wine and RDPRINT

by Frederico Bertucci

I try run this patch, but it not works still... some have another idea, or patch to run... with windows app works okay but with this specific application that uses rdprint, does not work... -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX --------- Mensagem Original -------- De: Mariusz Kie³piñski <kielpi(a)poczta.onet.pl> Para: wine-devel(a)winehq.org <wine-devel(a)winehq.org> Assunto: Re: Wine and RDPRINT Data: 17/03/06 17:40 > > Dnia pi±tek, 17 marca 2006 14:35, Frederico Bertucci napisa³: > Hi > > Good morning guys > > > > I did my system works with wine no problem, but when I try print using > > then, doesnt work... if I print from any other aplication, works. > > > > I talked with my developer and he told me that are using a delphi componet > > called RDPRINT, this in windows, to create better graphics. > > > > So, Are there any way to print in wine, using this RDPRINT ?? any dll, any > > configuration > > > > I am using latest wine configured with winetools, the printer is a lx300. > > > > I am trying do this works since 2 weeks ago and not sucefull > > > > Tks guys > > > > > > try this patch > > > ================================= > > wine.15.03.06.19.02.59.diff > ? dlls/msvideo/Makefile > ? dlls/win32s/Makefile > ? dlls/winsock/Makefile > ? dlls/winsock/libws2_32.def > ? dlls/winsock/version.res > ? dlls/winsock/tests/Makefile > ? dlls/winsock/tests/testlist.c > Index: dlls/gdi/printdrv.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v > retrieving revision 1.46 > diff -u -p -1 -r1.46 printdrv.c > --- dlls/gdi/printdrv.c 12 Sep 2005 10:30:06 -0000 1.46 > +++ dlls/gdi/printdrv.c 15 Mar 2006 18:03:01 -0000 > @@ -471,3 +471,3 @@ static int CreateSpoolFile(LPCSTR pszOut > if (!psCmd[0] && !strncmp("LPR:",pszOutput,4)) > - sprintf(psCmd,"|lpr -P%s",pszOutput+4); > + sprintf(psCmd,"|lp -d'%s' ",pszOutput+4); > > > ======================================= > > > > > > > > > > > > > > ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

March 21, 2006

re: WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Dan Kegel

Bryan Mayland wrote: > dlls/kernel/sync.c:173: > 176 if (count >= MAXIMUM_WAIT_OBJECTS) > 177 { > 178 SetLastError(ERROR_INVALID_PARAMETER); > 179 return WAIT_FAILED; > > Windows supports up to and including that number, wine only supports up > to that number. Congratulations, sounds like you found a bug in Wine! > Since the rest of the code actually does support the > full 64 wait objects, is there any reason this should not be changed to > 176 if (count > MAXIMUM_WAIT_OBJECTS) Looks like it should be changed. You've helped greatly with your post. You could help even more by posting a patch that modifies dlls/kernel/tests/sync.c to incorporate your test and also fixes the error. Feel up to it? Just yell if you need help. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 21, 2006

Re: Known issues area on main wiki page

by Segin

Tony Lambregts wrote: > Tom Spear wrote: > >> On 3/21/06, **Vitaliy Margolen** <wine-devel(a)kievinfo.com >> <mailto:wine-devel(a)kievinfo.com>> wrote: >> >> [...] > > [...] > Keeping them around for a while even after they are fixed would be a > good idea since not everyone keeps up with the latest version of wine. I have an idea, let's add a update check program to wine, so that when a person run it, they get to know what the latest version is, and their current version, plus make a standard executable of it for use on older versions.

March 21, 2006

Re: edit: Only adjust margins if the edit control is above a certain size.

by Alexandre Julliard

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > Huw Davies <huw(a)codeweavers.com> > edit: Only adjust the margins if the edit control is above a certain > size. This breaks the tests here: edit.c:788: Test failed: got 0 edit.c:789: Test failed: got 0 edit.c:802: Test failed: got 0 edit.c:808: Test failed: got 0 edit.c:809: Test failed: got 0 edit.c:813: Test failed: got 0 edit.c:814: Test failed: got 0 edit.c:817: Test failed: got 0 edit.c:818: Test failed: got 0 edit.c:840: Test failed: got 0 edit.c:841: Test failed: got 0 make[1]: *** [edit.ok] Error 11 -- Alexandre Julliard julliard(a)winehq.org

March 21, 2006

Re: Known issues area on main wiki page

by Tony Lambregts

Tom Spear wrote: > On 3/21/06, *Vitaliy Margolen* <wine-devel(a)kievinfo.com > <mailto:wine-devel(a)kievinfo.com>> wrote: > > I sure hope all users will go look at this page first. But some how I > don't think they will. When we getting _exact_ duplicates with the same > summary and almost identical comments. I don't think users will > bother to > look anywhere else. > > But that will add extra work on our side to keep this list in synch. On > top of the usual stuff that we already do. > > Vitaliy. > > It wouldnt take much extra time outta my day to do it. 5 mins at max > and only once I notice something is being reported rather frequently. I > assume that these people who are reporting identical duplicates read > some of the dodcumentation though, because otherwise they probably > wouldn't have even known about winecfg. > > Tom > One Major advantage is that even if people keep on reporting duplicates then it will make it easier for those people doing QA in Bugzilla. If they have a place to go when they think a bug is a duplicate instead of having to search for or remember the bug numbers[1]. Keeping them around for a while even after they are fixed would be a good idea since not everyone keeps up with the latest version of wine. [1] http://bugs.winehq.org/show_bug.cgi?id=219 (SafeDisk) http://bugs.winehq.org/show_bug.cgi?id=1631 (dsound: problem with underrun detection) http://bugs.winehq.org/show_bug.cgi?id=1410 (mouse always recenterd) -- Tony Lambregts

March 21, 2006

Re: Store GL context in the TEB

by Wino Rojo

Hi Tom, Where can I find more information about this, or a path to try? I'm currently getting the BadMatch error and I would like to try this solution Thanks, W >From: Tomas Carnecky <tom(a)dbservice.com> >To: wine-devel(a)winehq.org >Subject: Re: Store GL context in the TEB >Date: Tue, 21 Mar 2006 18:04:39 +0100 > >Mike Hearn wrote: > > Mike Hearn <mike(a)plan99.net> > > Optimize thunks by storing GL context in the thread environment block > > > >good job. this fixed the BadMatch error in World of Warcraft and also >increased performance, from ~20fps to ~25fps. > >tom > > _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 21, 2006

WaitForMultipleObjectsEx will not take up to MAXIMUM_WAIT_OBJECTS

by Bryan Mayland

I've been digging into why versions of uTorrent greater than 1.1.3 do not work under the latest wine and tracked it down to their use of WSAEventSelects to receive socket notifications. I created a small test application which mimics this behavior which works under WindowsXP but not wine. The problem is that they create MAXIMUM_WAIT_OBJECTS events and pass them to WaitForMultipleObjectsEx. That function bails out early due to dlls/kernel/sync.c:173: 176 if (count >= MAXIMUM_WAIT_OBJECTS) 177 { 178 SetLastError(ERROR_INVALID_PARAMETER); 179 return WAIT_FAILED; 180 } Windows supports up to and including that number, wine only supports up to that number. Since the rest of the code actually does support the full 64 wait objects, is there any reason this should not be changed to 176 if (count > MAXIMUM_WAIT_OBJECTS)

March 21, 2006

Re: Store GL context in the TEB

by Tomas Carnecky

Mike Hearn wrote: > Mike Hearn <mike(a)plan99.net> > Optimize thunks by storing GL context in the thread environment block > good job. this fixed the BadMatch error in World of Warcraft and also increased performance, from ~20fps to ~25fps. tom

March 21, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Robert Shearman

Dan Kegel wrote: >On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > > >>Alex wrote: >> >> >>>It seems that I will have to wait until I code >>>enough of a test case for a *successful* >>>ITypeInfo::Invoke() >>> >>> > >A few more vaguely relevant notes: >http://codeguru.earthweb.com/Cpp/COM-Tech/atl/article.php/c3565/ >briefly mentions how ATL uses ITypeInfo::Invoke(). >http://www.opengroup.org/onlinepubs/009899899/CHP18GDC.HTM >is the Open Group's documentation for ActiveX (!) which also >covers this a bit. And, more usefully, >http://groups.google.com/group/comp.os.ms-windows.programmer.ole/msg/c1417f… >says: >0) Call CoCreateInstance() to get a pointer to the object >1) Create a ITypeLib interface (via the 'LoadTypeLib' API function). >2) Call ITypeLib::GetTypeInfo to obtain ITypeInfo interface. >3) Call ITypeInfo::Invoke (almost like IDispatch::Invoke) >which is exactly what I was starting to gather by >reading the Automation and Type Libraries chapters of "Essence of COM". > I appreciate the effort, but none of those sources provide any more information than that present on MSDN, and even MSDN is woefully inadequate on the behaviour of the function in less common cases. Attached is a test case that covers a bit of the functionality in ITypeInfo::Invoke. -- Rob Shearman

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear

On 3/21/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote: > > On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote:Tom Spear (Dustin > Booker, Dustin Navea) wrote: > > >> Jesse Allen wrote: > >> > >>> 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 > >>> > >>> > >> > >> Which is why I agree with the ideas from Mike and Dimi AND Segin.. > >> Why not put an autodetect button, have the exception handler catch the > >> crash if arts decides to die, and then still have a popup dialog for > >> when arts is manually selected that tells users it is buggy and not > >> recommended to use?That doesn't fix your specific problem Jesse, I > >> know, but at least it keeps winecfg open when you click on the audio > tab. > >> > >> Tom > >> > >> > >> > > The reason I added the probe of all drivers in winecfg was so that the > > broken and marginal drivers would get used and hopefully fixed.Moving > > the problem will just create different bugs: [BUG xxx] winecfg crashes > > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > > xyz selected. > > > > > > > Yes, and I agree that that is a good idea, which is why I asked > > about putting a known issues page somewhere where a lot of users will > > see it. It wouldnt just have to be used for the issue mentioned > > above. It could be done for anything that is frequently reported. I'm > > going to go ahead and get started on putting it in tonight. Since it > > will be in the wiki, as the issues are fixed, they can be removed, and > > as other issues become more frequently reported, they can be added. I > > think it will be a good supplement to bugzilla and the appdb, as more > > people check out wiki's (as well as README's) than do the appdb, and so > > therefore they will see that the issue is already reported, and can > > find out what bug # it is instead of filing a duplicate bug. It also > > helps cut down on the number of bug submissions in the comments of the > > appdb.. > > I sure hope all users will go look at this page first. But some how I > don't think they will. When we getting _exact_ duplicates with the same > summary and almost identical comments. I don't think users will bother to > look anywhere else. > > But that will add extra work on our side to keep this list in synch. On > top of the usual stuff that we already do. > > Vitaliy. > > > > > It wouldnt take much extra time outta my day to do it. 5 mins at max and only once I notice something is being reported rather frequently. I assume that these people who are reporting identical duplicates read some of the dodcumentation though, because otherwise they probably wouldn't have even known about winecfg. Tom

March 21, 2006

Re: Known issues area on main wiki page

by Vitaliy Margolen

Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote: > On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote:Tom Spear (Dustin Booker, Dustin Navea) wrote: >> Jesse Allen wrote: >> >>> 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 >>> >>> >> >> Which is why I agree with the ideas from Mike and Dimi AND Segin.. >> Why not put an autodetect button, have the exception handler catch the >> crash if arts decides to die, and then still have a popup dialog for >> when arts is manually selected that tells users it is buggy and not >> recommended to use? That doesn't fix your specific problem Jesse, I >> know, but at least it keeps winecfg open when you click on the audio tab. >> >> Tom >> >> >> > The reason I added the probe of all drivers in winecfg was so that the > broken and marginal drivers would get used and hopefully fixed. Moving > the problem will just create different bugs: [BUG xxx] winecfg crashes > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > xyz selected. > Yes, and I agree that that is a good idea, which is why I asked > about putting a known issues page somewhere where a lot of users will > see it. It wouldnt just have to be used for the issue mentioned > above. It could be done for anything that is frequently reported. I'm > going to go ahead and get started on putting it in tonight. Since it > will be in the wiki, as the issues are fixed, they can be removed, and > as other issues become more frequently reported, they can be added. I > think it will be a good supplement to bugzilla and the appdb, as more > people check out wiki's (as well as README's) than do the appdb, and so > therefore they will see that the issue is already reported, and can > find out what bug # it is instead of filing a duplicate bug. It also > helps cut down on the number of bug submissions in the comments of the > appdb.. I sure hope all users will go look at this page first. But some how I don't think they will. When we getting _exact_ duplicates with the same summary and almost identical comments. I don't think users will bother to look anywhere else. But that will add extra work on our side to keep this list in synch. On top of the usual stuff that we already do. Vitaliy.

March 21, 2006

Re: Known issues area on main wiki page

by Chris Morgan

> aRts in and of itself is a buggy hack, 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 has been unmaintained for many years now. As the original author I was on the mailing list for a number of years and support was bad even when the arts plugin was originally written. The website documentation was out of date, it was difficult to find the latest version of the code. If there is something we can do to get arts working now that would be great since many people still use it and will continue to do so for some years. I'm certainly looking forward to when it is end-of-lifed with kde 4.0. Chris

March 21, 2006

Re: [WINEDOCS] add question on Intel MacOS X

by Emmanuel Maillard

Hi, The plan for porting Darwine/ppc is to use qemu either Bochs. Thanks Emmanuel Le 21 mars 06 à 06:48, Brian Vincent a écrit : > Are there any other FAQ additions anyone wants to see? There's at > least one other one I was thinking of adding but have since forgotten. > > Changelog: > Brian Vincent > Explicitly address Intel Mac OS X. > > Index: en/wine-faq.sgml > =================================================================== > RCS file: /cvsroot/wine/docs/en/wine-faq.sgml,v > retrieving revision 1.15 > diff -u -u -r1.15 wine-faq.sgml > --- en/wine-faq.sgml 1 Feb 2006 04:47:04 -0000 1.15 > +++ en/wine-faq.sgml 21 Mar 2006 05:45:34 -0000 > @@ -591,9 +591,12 @@ > <para> > Mac OS X / Darwin: The <ulink > url="http://darwine.opendarwin.org/">Darwine</ulink> > project is > - currently working on porting Wine to the Darwin/x86 > platform. Their > - goal is to eventually make it possible to run x86 Windows > + currently working on porting Wine to the Darwin/x86 > platform. > + Their goal is to eventually make it possible to run x86 > Windows > applications on Darwin/PPC and then Mac OS X by using > Bochs. > + In addition, CodeWeavers has focused some of their > resources on > + Intel Mac OS X as well. With a little luck, Wine will > be running on > + it by the third quarter of 2006. > </para> > <para> > FreeBSD: This port is well maintained and should work with > @@ -606,7 +609,32 @@ > </para> > </answer> > </qandaentry> > - > + <qandaentry> > + <question id="Will-wine-run-on-macintel"> > + <para> > + I want to run Wine on an Intel Mac OS X (MacIntel) > system, will it > + work? > + </para> > + </question> > + <answer> > + <para> > + (Also see the previous question.) As of March, 2006, > simple > + applications are just beginning to to run on Intel Mac > OS X. > + It's possible in about 6 months we'll see applications > running > + similarly to how they do on Linux or FreeBSD. > + </para> > + <para> > + There are some complicated issues surrounding Wine on > Mac OS X. > + Working with low-level features, such as signal handling > and system > + registers, are quite different on Mac OS X. Further > hampering > + the issue are some bugs within the operating system. > Beyond > + that, integration on Mac OS X becomes difficult because > it is > + vastly different than a traditional *nix desktop. Menuing > + and graphics drivers are just two areas that require a > complete > + reimplementation in order to be functional. > + </para> > + </answer> > + </qanaentry> > <qandaentry> > <question id="What-minimum-CPU-must-I-have"> > <para> > >

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear

On 3/21/06, Robert Reif <reif(a)earthlink.net> wrote: > > Tom Spear (Dustin Booker, Dustin Navea) wrote: > > > Jesse Allen wrote: > > > >> 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 > >> > >> > > > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. > > Why not put an autodetect button, have the exception handler catch the > > crash if arts decides to die, and then still have a popup dialog for > > when arts is manually selected that tells users it is buggy and not > > recommended to use? That doesn't fix your specific problem Jesse, I > > know, but at least it keeps winecfg open when you click on the audio > tab. > > > > Tom > > > > > > > The reason I added the probe of all drivers in winecfg was so that the > broken and marginal drivers would get used and hopefully fixed. Moving > the problem will just create different bugs: [BUG xxx] winecfg crashes > when autodetect button pressed or [BUG yyy] winecfg crashes when driver > xyz selected. > > Yes, and I agree that that is a good idea, which is why I asked about putting a known issues page somewhere where a lot of users will see it. It wouldnt just have to be used for the issue mentioned above. It could be done for anything that is frequently reported. I'm going to go ahead and get started on putting it in tonight. Since it will be in the wiki, as the issues are fixed, they can be removed, and as other issues become more frequently reported, they can be added. I think it will be a good supplement to bugzilla and the appdb, as more people check out wiki's (as well as README's) than do the appdb, and so therefore they will see that the issue is already reported, and can find out what bug # it is instead of filing a duplicate bug. It also helps cut down on the number of bug submissions in the comments of the appdb.. Tom

March 21, 2006

Re: IAMMultiMediaStream::OpenFile

by Robert Shearman

Ivan Leo Puoti wrote: >@@ -282,9 +283,15 @@ > { > IAMMultiMediaStreamImpl *This = (IAMMultiMediaStreamImpl *)iface; > >- FIXME("(%p/%p)->(%s,%lx) stub!\n", This, iface, debugstr_w(pszFileName), dwFlags); >+ TRACE("(%p/%p)->(%s,%lx)\n", This, iface, debugstr_w(pszFileName), dwFlags); > >- return E_NOTIMPL; >+ /* We should check the file format and fail to open it if we can't reder it */ >+ >+ This->FileHandle = CreateFileW(pszFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); >+ if(This->FileHandle == INVALID_HANLDE_VALUE) >+ return E_FAIL; >+ >+ return CoCreateInstance(&CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, &IID_IGraphBuilder, (LPVOID*)&This->pFilterGraph); > } > This is wrong. Here is the pseudo-code I sent to Peter Åstrand for the very same function: CoCreateInstance with IFileSourceFilter on CLSID_AsyncReader. Call IFileSourceFilter_Load. Get the output pin and stash it in This. Call IGraphBuilder_AddSourceFilter. Then IAMMultiMediaStreamImpl_Render should do the following: Call IGraphBuilder_Render using the pin previously stashed away. -- Rob Shearman

March 21, 2006

Re: IAMMultiMediaStream::OpenFile

by Dmitry Timoshkov

"Ivan Leo Puoti" <ivanleo(a)gmail.com> wrote: > + HANDLE FileHandle; > + This->FileHandle = CreateFileW(pszFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); > + if(This->FileHandle == INVALID_HANLDE_VALUE) > + return E_FAIL; I guess that you need to close that file handle somewhere. -- Dmitry.

March 21, 2006

Re: GoogleEarth

by Jeff Latimer

I have been looking at uniscribe functions which have been partially implemented. After I implement a few functions it was reported that GoogleEarth did not crash any more but did not display text. I think you will have to wait till more uniscribe is implemented or look at the code yourself. I will be having a look at more of it over the next couple of weeks. Jeff James Courtier-Dutton wrote: >Hi, > >Can one run GoogleEarth under wine? >It does not seem to run here under the default settings. > >James > > > > > > > >

March 21, 2006

Re: Known issues area on main wiki page

by Robert Reif

Tom Spear (Dustin Booker, Dustin Navea) wrote: > Jesse Allen wrote: > >> 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 >> >> > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. > Why not put an autodetect button, have the exception handler catch the > crash if arts decides to die, and then still have a popup dialog for > when arts is manually selected that tells users it is buggy and not > recommended to use? That doesn't fix your specific problem Jesse, I > know, but at least it keeps winecfg open when you click on the audio tab. > > Tom > > > The reason I added the probe of all drivers in winecfg was so that the broken and marginal drivers would get used and hopefully fixed. Moving the problem will just create different bugs: [BUG xxx] winecfg crashes when autodetect button pressed or [BUG yyy] winecfg crashes when driver xyz selected.

March 21, 2006

Re: Known issues area on main wiki page

by Tom Spear (Dustin Booker, Dustin Navea)

Jesse Allen wrote: > 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 > > Which is why I agree with the ideas from Mike and Dimi AND Segin.. Why not put an autodetect button, have the exception handler catch the crash if arts decides to die, and then still have a popup dialog for when arts is manually selected that tells users it is buggy and not recommended to use? That doesn't fix your specific problem Jesse, I know, but at least it keeps winecfg open when you click on the audio tab. Tom

March 21, 2006

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

by Jeff Latimer

Eric Pouech wrote: > - 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. I thought you meant that I needed a new method, might have come at it differently I if I had understood the parser at the beginning rather than tackle it at the end. I am not sure why the extra method is not a good thing. Is it a maintenance issue? > - 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. I think I see what you mean about needing to fix all the be_*.c files. My patch would cause a problem in that the method was not present for the other OS's, hence the INFO command would fail. In anycase I can see the work to be done. Will take a day or two. > - one of the test looks suspicious (shouldn't it be if > (!(ctx->loatSave.StatusWord & 0x00000001)) instead ?) > >> + if (!ctx->FloatSave.StatusWord & 0x00000001) > Point taken about the test and will fix though it did not seem to cause a problem. > A+ > Jeff

March 21, 2006

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

by Raphael

Hi Stefan, On Tuesday 21 March 2006 01:41, Stefan Dösinger wrote: > 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. You're right you can use the same context for many threads. you only have to "map" it to each threads (using MakeCurrent APIs) Anyway i have seen many problems when using the same context active for too many threads (seems the nvidia drivers don't like this kind of behavior) > 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 Regards, Raphael

March 21, 2006

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 20, 2006

Re: Known issues area on main wiki page

by Segin

March 20, 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 20, 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 20, 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 20, 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 20, 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 20, 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