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

Re: rebar patch

by Mike McCormack

qingdoa daoo wrote: > Hi > Can i suggest a patch to wine's rebar src > > The patch is made against current cvs source. > [root(a)localhost comctl32]# diff -u rebar.c.cvs rebar.c > attach.diff > --- rebar.c.cvs 2006-03-24 09:53:28.000000000 +0800 > +++ rebar.c 2006-03-24 09:38:29.000000000 +0800 Sure, we like patches. Please send them to wine-patches(a)winehq.org. You might also consider doing the diff in the wine directory: cd wine diff -urp dlls/comctl32/rebar.c.cvs dlls/comctl32/rebar.c > attach.diff That makes it easier to apply the patch, because whoever applies it doesn't have to figure out that it's against a file in dlls/comctl32. Then attach it to your mail as you have, with a ChangeLog line, something like: ChangeLog: Let apps remember rebar layout across runs. Mike (who especially likes Qingdao pijiu)

March 24, 2006

Re: GoogleEarth

by Dimi Paun

On Thu, 2006-03-23 at 19:48 +0100, Francois Gouget wrote: > Is there a place where we collect changes we'd like to see/do in other > projects? It would be a good resource when the date of some 'Linux on > the desktop' summit nears... The wiki would be a good place, I guess. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 24, 2006

rebar patch

by qingdoa daoo

Hi Can i suggest a patch to wine's rebar src The patch is made against current cvs source. [root(a)localhost comctl32]# diff -u rebar.c.cvs rebar.c > attach.diff --- rebar.c.cvs 2006-03-24 09:53:28.000000000 +0800 +++ rebar.c 2006-03-24 09:38:29.000000000 +0800 @@ -2820,7 +2820,7 @@ } if (lprbbi->fMask & RBBIM_SIZE) - lprbbi->cx = lpBand->cx; + lprbbi->cx = lpBand->ccx; if (lprbbi->fMask & RBBIM_BACKGROUND) lprbbi->hbmBack = lpBand->hbmBack; @@ -2902,7 +2902,7 @@ } if (lprbbi->fMask & RBBIM_SIZE) - lprbbi->cx = lpBand->cx; + lprbbi->cx = lpBand->ccx; if (lprbbi->fMask & RBBIM_BACKGROUND) lprbbi->hbmBack = lpBand->hbmBack; It's a fix to the problem that apps can't remember rebar layout across runs. When apps exit, they often ask the rebar for current band info so that the next time they run, they can tell the rebar how to layout the bands. When they ask about the size of a band, current code passes them lpBand->cx, which is a value passed by apps at band creation time, validated and stored by rebar, and then never gets updated. So apps alway get the old size value, while lpBand->ccx as the name suggests is the current rebar size. Tested with some apps, and no regression observed. Source Insight works better, so is Internet Explorer. I have actually made more changes to rebar.c. Wondering if some could review this patch and submit it. So that I can suggest subsequent patches against the updated source. --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Mike McCormack wrote: > > Tom Spear (Dustin Booker, Dustin Navea) wrote: > >> Hmm.. I'm thinking that the test isn't doing it right then... Cause >> windows will let you delete a readonly file, but it prompts you first > > Deleting using the UI isn't the same as a program using DeleteFile(). > > Mike > Crap, you are right.. doing del in the command prompt returns access denied.... ok the test is right....

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Mike McCormack

Tom Spear (Dustin Booker, Dustin Navea) wrote: > Hmm.. I'm thinking that the test isn't doing it right then... Cause > windows will let you delete a readonly file, but it prompts you first Deleting using the UI isn't the same as a program using DeleteFile(). Mike

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Huw D M Davies wrote: > On Thu, Mar 23, 2006 at 01:24:53PM -0500, Matt Finnicum wrote: > >> I'm at a windows XP machine right now. >> >> I have no trouble deleting read-only files - I get the dialog informing me >> it's read-only, but then it allows me to delete it. >> >> Is it the same on 95/98? >> > > How are you trying to delete them? The question is whether the > DeleteFile() function works as tested - the way to find this is to run > that test on Windows XP. > > Huw. > > I usually do Shift+Delete (skip the recycle bin), but delete will work to move a readonly file to the recycle bin as well... Tom

March 24, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Tom Spear (Dustin Booker, Dustin Navea)

Huw D M Davies wrote: > On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: > >> Umm.. I'm not totally sure this is 100% in conformance with windows. >> When I try to delete a readonly file, I get a dialog telling me that it >> is readonly, and asking me if I really want to delete it. If we are >> completely disallowing removal of a readonly file (by windows standard, >> not linux' standard), then it is incorrect and should be fixed... >> >> > > Well the test passes on Win 2000. > > C:\>kernel32_crosstest.exe file > file: 494243 test executed, 0 marked as todo, 0 failures. > > Huw. > Hmm.. I'm thinking that the test isn't doing it right then... Cause windows will let you delete a readonly file, but it prompts you first Tom

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Raphael

On Thursday 23 March 2006 20:26, Tomas Carnecky wrote: > Tomas Carnecky wrote: > > Changelog: > > - fail if the drawable and context Visual IDs don't match. > > > > why? because this will produce a BadMatch and crash the application so > > instead of the crash rather return GL_FALSE and let the application > > handle it. > > Please don't apply this patch yet. It fixes one case but there is more > to be aware of. > > This BadMatch bug is triggered if an application creates a window (with > a default Visual ID) and a custom (non-default) pixel format, the IDs > were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the > range from 0x21 to 0x70). yes, the classic wine problem :( > But! I've seen that World of Warcraft calls wglMakeCurrent() with a > darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now > 0x71 is not defined (according to the glxino output) but it works fine, > eg. glXMakeCurrent() doesn't produce the X Error in that case. > So I went up the backtrace, into create_glxpixmap(). I let this function > fail if it would produce a X Error, eg. if "depth of pixmap does not > match the GLX_BUFFER_SIZE value of vis". > Then I had to modify wglMakeCurrent() to respect the create_glxpixmap() > failure and return FALSE. Works good so far, framerate in WoW went up > from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is > incredible. good news. But try to see if users aren't too impacted (ie. diff between nvidia/ATI drivers) > So.. in this attachment you'll find a patch that does what I've just > described. I can't test it on anything else than WoW, so if someone > would please review it and test with outher opengl/d3d applications it > would be great. Sorry no time to test ii :( but send it to wine-users to see > Also, it would be great if we could put the *Swap*Buffers() into their > own log domain, something like 'swapbuffers', because the trace is > usually useless, only when you explicitly look whether these functions > are called or not, otherwise they only fill the log with garbage. > > thanks > tom Regards, Raphael

March 24, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent ()

by Raphael

On Friday 24 March 2006 00:13, Tomas Carnecky wrote: > Stefan Dösinger wrote: > > Hi, > > > >> So.. in this attachment you'll find a patch that does what I've just > >> described. I can't test it on anything else than WoW, so if someone > >> would please review it and test with outher opengl/d3d applications it > >> would be great. > > > > No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and > > Jedi Academy(GL). > > maybe it was because of the earlier opengl patch 'Store GL context in > TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps > > > That patch gave me a hint for a possible reason for the WineD3D slowness > > with a few games :) > > good, at least something :) > > > Something else.. now I know why there is this VisualID mismatch. Someone > didn't read the GLX spec. It's me. i have read the spec. And it's work (but not really well documented) :) > in opengl32/wgl.c:describeDrawable() you call > glXQueryDrawable() with GLX_VISUAL_ID, but that's not allowed ! only > GLX_FBCONFIG_ID and three others, according to the GLX 1.3/1.4 spec [1]. > > According to the spec, you can get the GLXFBConfig from a GLXDrawable > using glXQueryDrawable() and then the Visual from the GLXFBConfig using > glXGetFBConfigAttrib(). Yes i now that, problem is that glXQueryDrawable is not always available (only nvidia drivers implement it). So expect to break major part of wine users Regards, Raphael

March 24, 2006

Re: build failure on Gentoo Linux, recommended fix included.

by Mike McCormack

Segin wrote: > Suggested fix: Include stdint.h in server/mailslot.c > > (Patch not included due to the simplicity of code changes) Please include the patch and send this mail to wine-patches instead, otherwise you're just making more work for somebody else. Mike

March 24, 2006

Re: What happened to the Fedora packages?

by Neal Gompa

I just decided to use the yum packages suggested earlier... and yes, it fails, then crashes! anyway, thanks! On 3/23/06, Francois Gouget <fgouget(a)free.fr> wrote: > > On Wed, 22 Mar 2006, Neal Gompa wrote: > > > Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, so > > that is not the problem! It just always fails.... > > Oh, the compilation fails? That's not the same as the computer > crashing... > > Maybe you can send us the error message and then we can help you. > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Demander si un ordinateur peut penser revient à demander > si un sous-marin peut nager. >

March 24, 2006

build failure on Gentoo Linux, recommended fix included.

by Segin

Kernel 2.6.15-gentoo-r7 (2.6.15.7) glibc 2.3.6 (NTPL/NTPL only) Build error in server/mailslot.c: mailslot.c: In function 'mailslot_next_msg_size': mailslot.c:221: error: 'uint32_t' undeclared (first use in this function) mailslot.c:221: error: (Each undeclared identifier is reported only once mailslot.c:221: error: for each function it appears in.) make[1]: *** [mailslot.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/wine-0.9.10/work/wine-0.9.10/server' Suggested fix: Include stdint.h in server/mailslot.c (Patch not included due to the simplicity of code changes)

March 23, 2006

Re: CVS EU Server

by Brian Vincent

On 3/23/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > > Uhoh, with my own little server problem I now seem to have started > some wildfire... No, no wildfire here. I'm still one of those heathens using CVS too. What I meant was use git to clone the existing git repository to the local rhlx01box. Then I naively assumed you could some how export from git into CVS. A git expert probably knows whether that's possible (a quick Google search didn't provide an answer). Then you'd have both git and CVS available in Europe as well. Did you try this copy of cvsup? ftp://ftp.winehq.org/pub/wine/cvsup/cvsup-glibc2.3.tar.gz -Brian

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Tomas Carnecky

Stefan Dösinger wrote: > Hi, >> So.. in this attachment you'll find a patch that does what I've just >> described. I can't test it on anything else than WoW, so if someone >> would please review it and test with outher opengl/d3d applications it >> would be great. > No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and Jedi > Academy(GL). > maybe it was because of the earlier opengl patch 'Store GL context in TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps > That patch gave me a hint for a possible reason for the WineD3D slowness with > a few games :) > good, at least something :) Something else.. now I know why there is this VisualID mismatch. Someone didn't read the GLX spec. in opengl32/wgl.c:describeDrawable() you call glXQueryDrawable() with GLX_VISUAL_ID, but that's not allowed ! only GLX_FBCONFIG_ID and three others, according to the GLX 1.3/1.4 spec [1]. According to the spec, you can get the GLXFBConfig from a GLXDrawable using glXQueryDrawable() and then the Visual from the GLXFBConfig using glXGetFBConfigAttrib(). .. I'll send a patch. tom [1] http://www.opengl.org/documentation/specs/

March 23, 2006

Re: What happened to the Fedora packages?

by Andreas Bierfert

On Wed, 22 Mar 2006 11:01:23 +0100 Michel Ludwig <miclud(a)studcs.uni-sb.de> wrote: > Nice and decent Fedora Wine packages are in Fedora Extras: I am interested in the _decent_ part... always open for suggestions :) - Andreas P.S.: wine-0.9.10.i386 made it to the x86_64 tree so x86_64 users of Fedora Extras can get wine.i386 now by typing yum install wine as well... -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

March 23, 2006

Re:wine.inf: Add a shdocvw.dll stub dll to the system directory

by Louis. Lenders

What about adding a few more, like opengl32 (http://bugs.winehq.org/show_bug.cgi?id=3877) and some more (there are more of these bugs in bugzilla that can be solved that way, i could make a quick list of them if necessary) Regards Louis Module: wine Branch: refs/heads/master Commit: c3c112de231fae2f28d3f685c341a204ddef26a9 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=c3c112de231fae2f28d3f68… Author: Mike McCormack <mike <at> codeweavers.com> Date: Wed Mar 22 23:46:31 2006 +0900 wine.inf: Add a shdocvw.dll stub dll to the system directory. --- tools/wine.inf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index 747eb83..17d9144 100644 --- a/tools/wine.inf +++ b/tools/wine.inf <at> <at> -2114,6 +2114,7 <at> <at> HKLM,%CurrentVersion%\Telephony\Country 11,,help.exe,winhelp.exe 11,,msiexec.exe 11,,notepad.exe +11,,shdocvw.dll 11,,progman.exe 11,,regsvr32.exe 11,,wcmd.exe ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Stefan Dösinger

Hi, > So.. in this attachment you'll find a patch that does what I've just > described. I can't test it on anything else than WoW, so if someone > would please review it and test with outher opengl/d3d applications it > would be great. No effects noticed with Half-life 1(GL), Warcraft III(GL and D3D) and Jedi Academy(GL). That patch gave me a hint for a possible reason for the WineD3D slowness with a few games :) Stefan

March 23, 2006

Re: Bugzilla: Duplicates

by Tony Lambregts

Jeremy Newman wrote: > On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote: > >>Hello, >> >> >>>Just found, that gcc has "Most frequently reported Bugs": >>>http://gcc.gnu.org/bugzilla/duplicates.cgi >>> >>>And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi >>>The Page is present, but not configured to be useful for wine. >>> >>>The code is in the cvs, but I'm unable to help here (perl). >>>(Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") >>> >>> >> >>Hmm, in principle one only needs to tweek at >>http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. >> >>Running ./checksetup.pl doesn't harm either >> >>The essential task is to fill the duplicates table using the script: >> http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl >>You need to run it using cron. >> >>Tobias >> > When I try to run the collectstats.pl script I get this: > > wineowner(a)wine:~/opt/bugzilla$ ./collectstats.pl > No value for param loginmethod at Bugzilla/Config.pm line 135. > BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. > Compilation failed in require at Bugzilla.pm line 27. > BEGIN failed--compilation aborted at Bugzilla.pm line 27. > Compilation failed in require at ./collectstats.pl line 37. > BEGIN failed--compilation aborted at ./collectstats.pl line 37. > > I have not looked into the code to find why it does not work. Seems > odd since the rest of bugzilla works fine. Looks like you need to give loginmethod a value in Bugzilla.pm. For whatever reason this file is not part of CVS. I can look at my local copy of this file when I get home. -- Tony Lambregts

March 23, 2006

Re: GoogleEarth

by Segin

Lionel Ulmer wrote: >On Thu, Mar 23, 2006 at 07:48:11PM +0100, Francois Gouget wrote: > > >>Is there a place where we collect changes we'd like to see/do in other >>projects? It would be a good resource when the date of some 'Linux on >>the desktop' summit nears... >> >> > >Some information is here for OpenGL: http://wiki.winehq.org/OpenGL > > Lionel > > > Google Earth works stable (barely usable due to some QT/GL errors, yes GoogleEarth uses QT under Windows) under wine 0.9.9

March 23, 2006

Re: Could not run Digital Mars C/C++ Compiler under Wine

by Eric Pouech

Igor Sysoev wrote: > When I try to run any program from Digital Mars C/C++ Compiler > http://www.digitalmars.com/download/freecompiler.html > under Wine 0.9.10 on FreeBSD 6.1, I always see the error: > this works fine here (on Linux)... may be a freebsd issue ? -- Eric Pouech

March 23, 2006

Re: Bugzilla: Duplicates

by Jeremy Newman

When I try to run the collectstats.pl script I get this: wineowner(a)wine:~/opt/bugzilla$ ./collectstats.pl No value for param loginmethod at Bugzilla/Config.pm line 135. BEGIN failed--compilation aborted at Bugzilla/Auth.pm line 36. Compilation failed in require at Bugzilla.pm line 27. BEGIN failed--compilation aborted at Bugzilla.pm line 27. Compilation failed in require at ./collectstats.pl line 37. BEGIN failed--compilation aborted at ./collectstats.pl line 37. I have not looked into the code to find why it does not work. Seems odd since the rest of bugzilla works fine. On Wed, 2006-03-22 at 21:22 +0100, Tobias Burnus wrote: > Hello, > > > Just found, that gcc has "Most frequently reported Bugs": > > http://gcc.gnu.org/bugzilla/duplicates.cgi > > > > And since we have also bugzilla, i tested http://bugs.winehq.org/duplicates.cgi > > The Page is present, but not configured to be useful for wine. > > > > The code is in the cvs, but I'm unable to help here (perl). > > (Browse the cvs: "http://cvs.winehq.org/cvsweb/bugzilla/") > > > > > > Hmm, in principle one only needs to tweek at > http://bugs.winehq.org/editparams.cgi the 'mostfreqthreshold' option. > > Running ./checksetup.pl doesn't harm either > > The essential task is to fill the duplicates table using the script: > http://cvs.winehq.org/cvsweb/bugzilla/collectstats.pl > You need to run it using cron. > > Tobias > >

March 23, 2006

Re: GoogleEarth

by Lionel Ulmer

On Thu, Mar 23, 2006 at 07:48:11PM +0100, Francois Gouget wrote: > Is there a place where we collect changes we'd like to see/do in other > projects? It would be a good resource when the date of some 'Linux on > the desktop' summit nears... Some information is here for OpenGL: http://wiki.winehq.org/OpenGL Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 23, 2006

Regression 16 bit threading problem with Use explorer to handle desktop window commit

by paul

If I start two 16 bit programs in wcmd or in the original case use wintask to start a Delphi 1 based GUI the second program does not get a new thread detach. As soon as the switch occurs back to the original task a page fault occurs. See bug for traces, more details and sample program. http://bugs.winehq.org/show_bug.cgi?id=4897 Paul Romanyszyn

March 23, 2006

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()

by Tomas Carnecky

Tomas Carnecky wrote: > Changelog: > - fail if the drawable and context Visual IDs don't match. > > why? because this will produce a BadMatch and crash the application so > instead of the crash rather return GL_FALSE and let the application > handle it. Please don't apply this patch yet. It fixes one case but there is more to be aware of. This BadMatch bug is triggered if an application creates a window (with a default Visual ID) and a custom (non-default) pixel format, the IDs were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the range from 0x21 to 0x70). But! I've seen that World of Warcraft calls wglMakeCurrent() with a darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now 0x71 is not defined (according to the glxino output) but it works fine, eg. glXMakeCurrent() doesn't produce the X Error in that case. So I went up the backtrace, into create_glxpixmap(). I let this function fail if it would produce a X Error, eg. if "depth of pixmap does not match the GLX_BUFFER_SIZE value of vis". Then I had to modify wglMakeCurrent() to respect the create_glxpixmap() failure and return FALSE. Works good so far, framerate in WoW went up from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is incredible. So.. in this attachment you'll find a patch that does what I've just described. I can't test it on anything else than WoW, so if someone would please review it and test with outher opengl/d3d applications it would be great. Also, it would be great if we could put the *Swap*Buffers() into their own log domain, something like 'swapbuffers', because the trace is usually useless, only when you explicitly look whether these functions are called or not, otherwise they only fill the log with garbage. thanks tom

March 23, 2006

Re: file.c:246: Test failed: shouldn't be able to delete a readonly file

by Huw D M Davies

On Thu, Mar 23, 2006 at 01:59:12PM -0500, Bryan Mayland wrote: > Huw D M Davies wrote: > >How are you trying to delete them? The question is whether the > >DeleteFile() function works as tested - the way to find this is to run > >that test on Windows XP. > > > DeleteFile on an read-only file under XP returns false. > GetLastError returns 5 (Access denied) Right, which is what we're testing for (well ok we don't test GetLastError). Huw.

March 23, 2006