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