December 2008 - Wine-Devel - list.winehq.org

Re: Combining Fuse and Wine - What's the best way?

by Vitaliy Margolen

Richard Stitz wrote: > I tried but I've hit a problem. I'm just trying to compile the "Hello > world" Fuse application. > (http://fuse.sourceforge.net/helloworld.html) In regular gcc, I can > compile and run it fine: Just using "winegcc" is not enough. You have to run it with Wine: http://forum.winehq.org/viewtopic.php?t=3177 Vitaliy

Dec. 24, 2008

Re: Bugzilla - CVS/GIT tag

by Vitaliy Margolen

Austin English wrote: > In an effort to remove the CVS/GIT tag, I was going to go through and > start changing the versions based on when the bug was filed. I.e., > look at when 1.1.10 was out, and any bugs filed in those dates with > CVS/GIT tag get moved to 1.1.10. I'm thinking of starting with 0.9, as > anything before that is _really_ old and not worth the effort... Agreed. Non need to generate huge volume of spam changing all the old versions. Especially for closed bugs. > Also, the FIXME, NoAppDBEntry, and BugBuster should probably be > removed...they're not that useful anyway... > NoAppDBEntry might be useful if anyone tracks that. Others are pretty much useless. Vitaliy

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Nikolay Sivov

Vitaly Lipatov wrote: > В сообщении от 24 декабря 2008 Austin English написал(a): > >> On Wed, Dec 24, 2008 at 7:36 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: >> > ... > >>> I know it is common question about testcase, but I think it does not >>> means with this functions. >>> Note, I do not fix some functions, I have implemented from scratch it >>> instead stub. >>> And my better test case is a popular account application used this >>> functions. >>> > ... > >> I'm not saying your patch is wrong by any means. Testcases serve as >> documentation of the Win32 API, and also help prevent regressions in >> those functions. >> > I agree, but I have not idea how to make test for it. I wrote this code about > one year ago and do not remember how it works :) But I use these functions > every day in an accounting application. > You could start with testing for some special cases (such as NULL input parameters). For me your comment looks suspicious: ----- + * TODO + * Check if OLE object has no verbs ----- + hr = IOleObject_EnumVerbs(lpOleObj, &pEnumVerbs); + if (hr == S_OK) { ---- Will this hr be OLEOBJ_E_NOVERBS when no verbs present? If it's so you're actually checking for this. This one needs a testcase for example. At the end you return HMENU without NULL check ---- + *lphMenu = popup; + return TRUE; } ----- Does native crash on it or not? I'm not sure. The same about SetLastError on failure - this should be checked by testing it directly.

Dec. 24, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Nick Burns

Thanks for the explanation -- I will email asking why soon -- and perhaps resubmit the other patch I have been looking at http://winehq.org/pipermail/wine-cvs to see what has been applied But source.winehq.org/git shows the diffs much nicer - Nick ---------------------------------------- > From: stefan(a)codeweavers.com > To: adger44(a)hotmail.com; wine-devel(a)winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux) > Date: Wed, 24 Dec 2008 15:48:24 +0100 > >> Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) >> BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix >> ddraw surface version setting)? > Yes, I recommend to do that. It is likely that it was lost or didn't apply > any longer after the 3 days it waited in moderation. > > You can see on source.winehq.org/git or with 'git log origin' if your patch > was applied. If it wasn't, it is best to send a mail to wine-devel asking > why, or ask Alexandre(nick 'julliard') on #winehackers. Quite often > Alexandre sends a reply if he doesn't like the patch(or someone else does), > but not always. > > Alexandre usually wants a confirmation from someone who knows the area(in > the case of d3d Heri, Roderick or me) if a new contributor sends a patch, > hence my "the patch is ok" mails. > > I don't know if Alexandre will apply patches over the holidays, so if the > patch is silently ignored it is best to resend it in a few days.

Dec. 24, 2008

Re: Combining Fuse and Wine - What's the best way?

by Richard Stitz

I tried but I've hit a problem. I'm just trying to compile the "Hello world" Fuse application. (http://fuse.sourceforge.net/helloworld.html) In regular gcc, I can compile and run it fine: $ gcc -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=22 -lfuse -o main main.c $ mkdir test $ ./main test $ cat test/hello Hello World! $ sudo umount test $ rm -r test All goes well. However, if I try to compile this app with winegcc, it fails to run properly: $ winegcc -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=22 -lfuse -o main main.c $ mkdir test $ ./main test fusermount: failed to open /etc/fuse.conf: Permission denied fusermount: waitpid: No child processes $ sudo umount test (I still had to umount the directory even though the mount failed, as mtab recorded that both /dev/fuse and main.exe.so were mounted to the directory, despite the failed mount. Using umount cleaned the entried from mtab.) I also tried to do so as root (given the whole permission denied thing): $ sudo su # ./main test fuse: waitpid: No child processes # umount test # rm -r test If I compile the app again using the first method, it goes flawlessly again. What do I need to do to get it working with winegcc? On Wed, Dec 24, 2008 at 6:52 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > You have to use winegcc(see 'winemaker' for starting points). That way your > app is compiled to a .exe.so file that can be run with 'wine foo.exe.so' or > with a helper script. This application is a native Linux app, and it can > link to Linux libraries like Fuse, and at the same time use Win32 API calls > from Wine and e.g. open a DLL with LoadLibrary.

Dec. 24, 2008

Re: wineoss: Remove a superfluous semicolon

by Andrew Talbot

Or "wineoss.drv:...", to be precise.

Dec. 24, 2008

Bugzilla - CVS/GIT tag

by Austin English

In an effort to remove the CVS/GIT tag, I was going to go through and start changing the versions based on when the bug was filed. I.e., look at when 1.1.10 was out, and any bugs filed in those dates with CVS/GIT tag get moved to 1.1.10. I'm thinking of starting with 0.9, as anything before that is _really_ old and not worth the effort... Anyone opposed to this plan? Also, the FIXME, NoAppDBEntry, and BugBuster should probably be removed...they're not that useful anyway... -- -Austin

Dec. 24, 2008

Re: WoW instantly crashes since commits on 23rd

by Austin English

On Wed, Dec 24, 2008 at 3:23 AM, Jukka Tastula <poltsy(a)gmail.com> wrote: > Bisect gives me the following > > 878c2a83325b66cea79c24dc7379e5a6ee976044 is first bad commit > commit 878c2a83325b66cea79c24dc7379e5a6ee976044 > Author: Vincent Pelletier <plr.vincent(a)gmail.com> > Date: Mon Dec 22 21:56:14 2008 +0100 > > user32: Fix SPI_GETMOUSESPEED and SPI_SETMOUSESPEED. > > > > Please use bugzilla for bug reporting. That said, there's already a bug: http://bugs.winehq.org/show_bug.cgi?id=16611 and Dmitry's already prepared a patch: http://www.winehq.org/pipermail/wine-patches/2008-December/066689.html he's a quick one :-). -- -Austin

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Vitaly Lipatov

В сообщении от 24 декабря 2008 Austin English написал(a): > On Wed, Dec 24, 2008 at 7:36 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: ... > > I know it is common question about testcase, but I think it does not > > means with this functions. > > Note, I do not fix some functions, I have implemented from scratch it > > instead stub. > > And my better test case is a popular account application used this > > functions. ... > I'm not saying your patch is wrong by any means. Testcases serve as > documentation of the Win32 API, and also help prevent regressions in > those functions. I agree, but I have not idea how to make test for it. I wrote this code about one year ago and do not remember how it works :) But I use these functions every day in an accounting application. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Austin English

On Wed, Dec 24, 2008 at 7:36 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: > В сообщении от 24 декабря 2008 Вы написали: >> On Wed, Dec 24, 2008 at 5:49 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: >> > Hello, >> > >> > Can anyone comment what bad with my >> > OleUIAddVerbMenuA/W implementation. >> > >> > I know no one is interested in this function at your side, but it is >> > really used function for more than one year. >> > >> > В сообщении от 20 декабря 2008 Vitaly Lipatov написал(a): >> >> Real implementation of the OleUIAddVerbMenu function. >> > >> > -- >> > Vitaly Lipatov, ALT Linux Team >> > Russia, Saint-Petersburg, www.etersoft.ru >> >> Can you add a testcase for these functions? > I know it is common question about testcase, but I think it does not means > with this functions. > Note, I do not fix some functions, I have implemented from scratch it instead > stub. > And my better test case is a popular account application used this functions. > > > -- > Vitaly Lipatov, ALT Linux Team > Russia, Saint-Petersburg, www.etersoft.ru > I'm not saying your patch is wrong by any means. Testcases serve as documentation of the Win32 API, and also help prevent regressions in those functions. -- -Austin

Dec. 24, 2008

RE: d3d9/visual tests timed out

by Stefan Dösinger

> My Atom based netbook with i915 graphics on F10 hits the timeout too. > It's a minor nuisance as I have to hit the "OK" button even though the > test will finish just fine. Maybe its time to split the d3d9 visual tests up. There are so many tests in there, which often have little in common appart of the comparably small framework for visual tests. On a properly working machine the tests run in just a second or less, but some drivers(even on Windows) are pretty slow in GetFrontBufferData. That may be the reason for the timeout.

Dec. 24, 2008

RE: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Stefan Dösinger

I think henri sent a reply. He recommended to clamp the new pointsize instead of leaving the old one set. Of course a test would be interesting too, to see how windows behaves here. > -----Original Message----- > From: wine-devel-bounces(a)winehq.org [mailto:wine-devel- > bounces(a)winehq.org] On Behalf Of Vincent Pelletier > Sent: Tuesday, December 23, 2008 7:31 PM > To: wine-devel(a)winehq.org > Subject: [RFC] wined3d: Avoid triggering OPENGL errors when setting > point size > > (Resent, originally sent to -patches... Sorry) > > If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render > state is set to an invalid size, glPointSize will fail. > This happens in "Black & White 2", causing log/stderr to be flooded > with opengl errors. > > I'm not sure if this should be fixed here, or when setting state value. > Also, maybe it should be avoided to double-check against opengl bounds > when WINED3DRS_POINTSCALEENABLE is true. > > I would be happy to get some feedback on that patch. > > -- > Vincent Pelletier

Dec. 24, 2008

RE: Combining Fuse and Wine - What's the best way?

by Stefan Dösinger

> I'm writing a program in which I have a Windows DLL that I need to load. The DLL contains a function that > returns a pointer to some data, and I want to expose that data as file data in a Fuse file system. > My first thought was that I could have the program load the DLL using winelib, but I'm not sure what's > involved in this and whether the resulting program could also use the Fuse libraries. I'm a bit of a > novice to Wine, and Linux programming in general, so I'd appreciate any expert opinions you guys have about > the best way to do this. Unfortunately you can't just link to winelib with -lwine or something, because the Wine DLLs(and most likely the Windows DLL) need some extra services running to work properly. That includes things like a certain memory layout, the registry, etc. You have to use winegcc(see 'winemaker' for starting points). That way your app is compiled to a .exe.so file that can be run with 'wine foo.exe.so' or with a helper script. This application is a native Linux app, and it can link to Linux libraries like Fuse, and at the same time use Win32 API calls from Wine and e.g. open a DLL with LoadLibrary.

Dec. 24, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Stefan Dösinger

> Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) > BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix > ddraw surface version setting)? Yes, I recommend to do that. It is likely that it was lost or didn't apply any longer after the 3 days it waited in moderation. You can see on source.winehq.org/git or with 'git log origin' if your patch was applied. If it wasn't, it is best to send a mail to wine-devel asking why, or ask Alexandre(nick 'julliard') on #winehackers. Quite often Alexandre sends a reply if he doesn't like the patch(or someone else does), but not always. Alexandre usually wants a confirmation from someone who knows the area(in the case of d3d Heri, Roderick or me) if a new contributor sends a patch, hence my "the patch is ok" mails. I don't know if Alexandre will apply patches over the holidays, so if the patch is silently ignored it is best to resend it in a few days.

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Vitaly Lipatov

В сообщении от 24 декабря 2008 Вы написали: > On Wed, Dec 24, 2008 at 5:49 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: > > Hello, > > > > Can anyone comment what bad with my > > OleUIAddVerbMenuA/W implementation. > > > > I know no one is interested in this function at your side, but it is > > really used function for more than one year. > > > > В сообщении от 20 декабря 2008 Vitaly Lipatov написал(a): > >> Real implementation of the OleUIAddVerbMenu function. > > > > -- > > Vitaly Lipatov, ALT Linux Team > > Russia, Saint-Petersburg, www.etersoft.ru > > Can you add a testcase for these functions? I know it is common question about testcase, but I think it does not means with this functions. Note, I do not fix some functions, I have implemented from scratch it instead stub. And my better test case is a popular account application used this functions. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Austin English

On Wed, Dec 24, 2008 at 5:49 AM, Vitaly Lipatov <lav(a)etersoft.ru> wrote: > Hello, > > Can anyone comment what bad with my > OleUIAddVerbMenuA/W implementation. > > I know no one is interested in this function at your side, but it is really > used function for more than one year. > > В сообщении от 20 декабря 2008 Vitaly Lipatov написал(a): >> Real implementation of the OleUIAddVerbMenu function. > > > > -- > Vitaly Lipatov, ALT Linux Team > Russia, Saint-Petersburg, www.etersoft.ru > > > Can you add a testcase for these functions? -- -Austin

Dec. 24, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Vitaly Lipatov

Hello, Can anyone comment what bad with my OleUIAddVerbMenuA/W implementation. I know no one is interested in this function at your side, but it is really used function for more than one year. В сообщении от 20 декабря 2008 Vitaly Lipatov написал(a): > Real implementation of the OleUIAddVerbMenu function. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 24, 2008

Re: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Roderick Colenbrander

We have both a glDrawPixels and texture backend. You can switch to a different backend using the RenderTargetLockMode registry key. It has values readdraw (readpixels + drawpixels), readtex (readpixels + texture rendering) and some others (textex and texdraw). I plan on making readtex default at some point. Roderick > > Why not create a texture and draw a quad instead of using glDrawPixels (as > it is deprecated in gl3)?Reference -- ogl 3 spec -- > (http://www.opengl.org/registry/doc/glspec30.20080811.pdf)Under "E.1 Proﬁles and Deprecated > Features of OpenGL 3.0""Pixel drawing - DrawPixels and PixelZoom (section > 3.7.4). However, the > language describing pixel rectangles in section 3.7 is retained as it is > required > for TexImage* and ReadPixels. " - Nick> From: adger44(a)hotmail.com> To: > stefan(a)codeweavers.com; wine-devel(a)winehq.org> Subject: RE: [PATCH] Fix > glReadPixels call from read_from_framebuffer (re-redux)> Date: Tue, 23 Dec 2008 > 11:11:08 -0800> > > Thanks for reviewing my patch (it sure makes the SHOGO > menu much nicer)> BTW do you know if I need to resubmit my other SHOGO patch > ([PATCH] Fix ddraw surface version setting)?> > > Concerning negative > pixelzoom and drawpixels on R500> Please file a radar on that (and email the > mac-opengl mailing list)> > > - Nick> > > ---------------------------------------->> From: stefan(a)codeweavers.com>> To: wine-devel(a)winehq.org>> Subject: > RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)>> > Date: Tue, 23 Dec 2008 13:30:40 +0100>>>> This patch looks good.>>>> There's > one last thing we should check: It seems that this is the only code>> that > uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is>> > probably not needed. I think for now it is better to add it because I>> suspect > the code in surface_download_data most likely depends on the default>> > settings without properly controlling them.>>>> There's some related driver bug > on OSX too(no radar filed yet,>> unfortunately). Using a PBO for > glDrawPixels with a negative pixelzoom(wine>> uses -1 for y) breaks at least on my > radeon X1600 with MacOS 10.5.5. I>> haven't yet tested it with 10.5.6, but if > it is still broken there I have to>> remember to file a bug. It is sort of > a follow-up bug to a bug fixed in>> 10.5.5; Before that glPixelZoom and > PixelPos were completely ignored with>> PBOs.>>>> This bug was on my todo > list for a long time by the way. I wanted to fix it,>> got distracted and > forgot again :-/ -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Paul Vriens

Dmitry Timoshkov wrote: > "Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > >> Could you also zip these huge things up in the future (mail is now >> 1217KB)? > > It would be better to exclude the auto generated files instead, configure > diff took more than 2/3 of the patch. > Yeah, just saw that as well. -- Cheers, Paul.

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Dmitry Timoshkov

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > Could you also zip these huge things up in the future (mail is now 1217KB)? It would be better to exclude the auto generated files instead, configure diff took more than 2/3 of the patch. -- Dmitry.

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Massimo Del Fedele

Paul Vriens ha scritto: > Massimo Del Fedele wrote: >> Here the second part, it contains winedib.drv code and changes to >> Makefiles. >> >> Still no way to enable/disable the engine, besides of deleting the .so >> inside dlls/winedib.drv. >> >> I'll wait for some feedback before going fourther. >> >> Ciao >> >> Max >> >> >> ------------------------------------------------------------------------ >> >> > Hi Max > > I don't think this should have gone to wine-patches but to wine-devel instead. > After all it's a proof of concept and not a complete solution. > Well, I asked about it before posting, but I didn't get a clear answer on where to post it. Next time it'll be on devel. > Could you also zip these huge things up in the future (mail is now 1217KB)? > Ok, I didn't know if it is correct or not to zip the patches. Ciao Max

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Massimo Del Fedele

Jeff Zaroyko ha scritto: > On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele <max(a)veneto.com> wrote: >> Here the second part, it contains winedib.drv code and changes to Makefiles. >> >> Still no way to enable/disable the engine, besides of deleting the .so >> inside dlls/winedib.drv. >> >> I'll wait for some feedback before going fourther. >> >> Ciao >> >> Max >> > > Instead of deleting it, you could simply set winedib.drv to disabled in winecfg? > > -Jeff > > > Yes, of course. The final idea is registry/environment var; I posted the patch quickly because many people asked for.... and I've got no time to work on it on these days. Ciao Max

Dec. 24, 2008

WoW instantly crashes since commits on 23rd

by Jukka Tastula

Bisect gives me the following 878c2a83325b66cea79c24dc7379e5a6ee976044 is first bad commit commit 878c2a83325b66cea79c24dc7379e5a6ee976044 Author: Vincent Pelletier <plr.vincent(a)gmail.com> Date: Mon Dec 22 21:56:14 2008 +0100 user32: Fix SPI_GETMOUSESPEED and SPI_SETMOUSESPEED.

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Paul Vriens

Massimo Del Fedele wrote: > Here the second part, it contains winedib.drv code and changes to > Makefiles. > > Still no way to enable/disable the engine, besides of deleting the .so > inside dlls/winedib.drv. > > I'll wait for some feedback before going fourther. > > Ciao > > Max > > > ------------------------------------------------------------------------ > > Hi Max I don't think this should have gone to wine-patches but to wine-devel instead. After all it's a proof of concept and not a complete solution. Could you also zip these huge things up in the future (mail is now 1217KB)? -- Cheers, Paul.

Dec. 24, 2008

Re: Testing DIB Engine (second part)

by Jeff Zaroyko

On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Here the second part, it contains winedib.drv code and changes to Makefiles. > > Still no way to enable/disable the engine, besides of deleting the .so > inside dlls/winedib.drv. > > I'll wait for some feedback before going fourther. > > Ciao > > Max > Instead of deleting it, you could simply set winedib.drv to disabled in winecfg? -Jeff

Dec. 24, 2008

Re: Regression: Sound broken in PoP series

by Jerome Leclanche

See http://bugs.winehq.org/show_bug.cgi?id=16607 On Wed, Dec 24, 2008 at 4:53 AM, M.Kiesel <wine-devel(a)continuity.cjb.net> wrote: > Hi! > > The following commit breaks sound in (at least) Prince of Persia SoT and > PoP TWW. Reece, let me know how I can help with that. > > commit ce06de420874b9983324508f8257a580fee341ca > Author: Reece Dunn <msclrhd(a)googlemail.com> > Date: Mon Dec 22 13:33:43 2008 +0000 > dsound: Correct the dsound fraglen calculations. > > Regards > > > - JL -- Adys

Dec. 24, 2008

Combining Fuse and Wine - What's the best way?

by Richard Stitz

I'm writing a program in which I have a Windows DLL that I need to load. The DLL contains a function that returns a pointer to some data, and I want to expose that data as file data in a Fuse file system. My first thought was that I could have the program load the DLL using winelib, but I'm not sure what's involved in this and whether the resulting program could also use the Fuse libraries. I'm a bit of a novice to Wine, and Linux programming in general, so I'd appreciate any expert opinions you guys have about the best way to do this. Thanks in advance, Richard

Dec. 23, 2008

Regression: Sound broken in PoP series

by M.Kiesel

Hi! The following commit breaks sound in (at least) Prince of Persia SoT and PoP TWW. Reece, let me know how I can help with that. commit ce06de420874b9983324508f8257a580fee341ca Author: Reece Dunn <msclrhd(a)googlemail.com> Date: Mon Dec 22 13:33:43 2008 +0000 dsound: Correct the dsound fraglen calculations. Regards

Dec. 23, 2008

Re: [Wine] Re: MacOS X cocoa and carbon for Linux?

by James McKenzie

Richie wrote: > James McKenzie wrote: > >> hahomir4ev wrote: >> You might find a friendly discussion somewhere else on the >> implementation of Cocoa/Carbon on Linux, but this is not a topic of >> discussion here. >> James McKenzie >> > > Of cource it would be a completely unrelated project. Therefore the wine forum is not the right place for such a project. > BUT: Up to now there is no McWine or MINE project. Sad to say, but there IS a project for porting Wine to the PowerPC platform: Darwine. It has stalled and really could use help. It has forked so that there are two paths of development and the Intel fork is being worked back into the main Wine project. That leaves the PowerPC fork to be worked on to incorporate Qemu, an x86 emulator for the PowerPC. As to the Aqua 'look and feel' there is an effort to do this as well that may or may not need assistance. The goal in that project is to remove all Object C code and replace it with 'c' code equivalents. You can ask the status of that project on the Wine Development list. Again, this is not the area for discussing development of Wine. Let's move this to the appropriate venue. Thank you. James McKenzie

Dec. 23, 2008

re: Symlink vulnerability in winetricks

by Dan Kegel

Stefan Nordhaus wrote: > Winetricks has a symlink vulnerability... Fixed in today's winetricks (20081223), thanks! - Dan

Dec. 23, 2008

Re: Wine t-shirts?

by Ismael Barros²

Looks like the poll is pretty dead, and unless somebody wants to link it somewhere, I suppose we should start getting some conclussion White T-shirt wins 17-11 over white and red, but designs A and B are drawn, so our designer will choose (and she really disliked option A :P) About the slogan, there are 5 for "no slogan at all" and 4 for "run windows applications etc", and I see the drunk penguin T-shirt more suitable with either an informal slogan or just with the project name and website. So according to the poll (if nobody else wants to vote, the poll is still open) we have cute drunk penguin D with no slogan, "Wine" name, www.winehq.org somewhere and white T-shirt. When we are able to get more Wine T-shirts going, we will use design A and "run windows applications etc" slogan. Anything else?

Dec. 23, 2008

Re: Trouble compiling today's git.

by Austin English

On Tue, Dec 23, 2008 at 5:13 PM, Susan Cragin <susancragin(a)earthlink.net> wrote: > Is anyone else having trouble compiling today's git? > Or is it just my flu-addled brain? > > > make[1]: Entering directory `/home/susan/wine/server' > ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c > make[1]: Leaving directory `/home/susan/wine/server' > make[1]: Entering directory `/home/susan/wine/server' > ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c > make[1]: Leaving directory `/home/susan/wine/server' > make[1]: Entering directory `/home/susan/wine/tools' > make[2]: Entering directory `/home/susan/wine/tools/widl' > ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l > make[2]: Leaving directory `/home/susan/wine/tools/widl' > make[2]: Entering directory `/home/susan/wine/tools/widl' > ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l > make[2]: Leaving directory `/home/susan/wine/tools/widl' > make[2]: Entering directory `/home/susan/wine/tools/winebuild' > ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c > make[2]: Leaving directory `/home/susan/wine/tools/winebuild' > make[2]: Entering directory `/home/susan/wine/tools/winebuild' > ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c > make[2]: Leaving directory `/home/susan/wine/tools/winebuild' > make[2]: Entering directory `/home/susan/wine/tools/winedump' > ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c > make[2]: Leaving directory `/home/susan/wine/tools/winedump' > make[2]: Entering directory `/home/susan/wine/tools/winedump' > ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c > make[2]: Leaving directory `/home/susan/wine/tools/winedump' > make[2]: Entering directory `/home/susan/wine/tools/winegcc' > ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c > make[2]: Leaving directory `/home/susan/wine/tools/winegcc' > make[2]: Entering directory `/home/susan/wine/tools/winegcc' > ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c > make[2]: Leaving directory `/home/susan/wine/tools/winegcc' > make[2]: Entering directory `/home/susan/wine/tools/wmc' > ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y > make[2]: Leaving directory `/home/susan/wine/tools/wmc' > make[2]: Entering directory `/home/susan/wine/tools/wmc' > ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y > make[2]: Leaving directory `/home/susan/wine/tools/wmc' > make[2]: Entering directory `/home/susan/wine/tools/wrc' > ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.c parser.y parser.l > make[2]: Leaving directory `/home/susan/wine/tools/wrc' > make[2]: Entering directory `/home/susan/wine/tools/wrc' > ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.c parser.y parser.l > make[2]: Leaving directory `/home/susan/wine/tools/wrc' > ../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c > make[1]: Leaving directory `/home/susan/wine/tools' > ./tools/makedep -C. -S. -T. > make[1]: Entering directory `/home/susan/wine/tools' > make[1]: `makedep' is up to date. > make[1]: Leaving directory `/home/susan/wine/tools' > make[1]: Entering directory `/home/susan/wine/libs' > make[2]: Entering directory `/home/susan/wine/libs/port' > ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -h -H ../../include/wtypes.h ../../include/wtypes.idl > make[2]: ../../tools/widl/widl: Command not found > make[2]: *** [../../include/wtypes.h] Error 127 > make[2]: Leaving directory `/home/susan/wine/libs/port' > make[1]: *** [port] Error 2 > make[1]: Leaving directory `/home/susan/wine/libs' > make: *** [libs] Error 2 > susan(a)ubuntu:~/wine$ > > > > > > It's a regression caused by http://source.winehq.org/git/wine.git/?a=commitdiff;h=dc1a9f19c1f4c462f1e68… -- -Austin

Dec. 23, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Nick Burns

Why not create a texture and draw a quad instead of using glDrawPixels (as it is deprecated in gl3)?Reference -- ogl 3 spec -- (http://www.opengl.org/registry/doc/glspec30.20080811.pdf)Under "E.1 Proﬁles and Deprecated Features of OpenGL 3.0""Pixel drawing - DrawPixels and PixelZoom (section 3.7.4). However, the language describing pixel rectangles in section 3.7 is retained as it is required for TexImage* and ReadPixels. " - Nick> From: adger44(a)hotmail.com> To: stefan(a)codeweavers.com; wine-devel(a)winehq.org> Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)> Date: Tue, 23 Dec 2008 11:11:08 -0800> > > Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer)> BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)?> > > Concerning negative pixelzoom and drawpixels on R500> Please file a radar on that (and email the mac-opengl mailing list)> > > - Nick> > ---------------------------------------->> From: stefan(a)codeweavers.com>> To: wine-devel(a)winehq.org>> Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)>> Date: Tue, 23 Dec 2008 13:30:40 +0100>>>> This patch looks good.>>>> There's one last thing we should check: It seems that this is the only code>> that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is>> probably not needed. I think for now it is better to add it because I>> suspect the code in surface_download_data most likely depends on the default>> settings without properly controlling them.>>>> There's some related driver bug on OSX too(no radar filed yet,>> unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine>> uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I>> haven't yet tested it with 10.5.6, but if it is still broken there I have to>> remember to file a bug. It is sort of a follow-up bug to a bug fixed in>> 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with>> PBOs.>>>> This bug was on my todo list for a long time by the way. I wanted to fix it,>> got distracted and forgot again :-/

Dec. 23, 2008

Trouble compiling today's git.

by Susan Cragin

Is anyone else having trouble compiling today's git? Or is it just my flu-addled brain? make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/server' ../tools/makedep -C. -S.. -T.. async.c atom.c change.c class.c clipboard.c completion.c console.c context_alpha.c context_i386.c context_powerpc.c context_sparc.c context_x86_64.c debugger.c device.c directory.c event.c fd.c file.c handle.c hook.c mach.c mailslot.c main.c mapping.c mutex.c named_pipe.c object.c process.c procfs.c ptrace.c queue.c region.c registry.c request.c semaphore.c serial.c signal.c snapshot.c sock.c symlink.c thread.c timer.c token.c trace.c unicode.c user.c window.c winstation.c make[1]: Leaving directory `/home/susan/wine/server' make[1]: Entering directory `/home/susan/wine/tools' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c utils.c widl.c write_msft.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/widl' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winebuild' ../../tools/makedep -C. -S../.. -T../.. import.c main.c parser.c relay.c res16.c res32.c spec16.c spec32.c utils.c make[2]: Leaving directory `/home/susan/wine/tools/winebuild' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winedump' ../../tools/makedep -C. -S../.. -T../.. debug.c dos.c dump.c emf.c le.c lib.c lnk.c main.c minidump.c misc.c msc.c msmangle.c ne.c output.c pdb.c pe.c search.c symbol.c make[2]: Leaving directory `/home/susan/wine/tools/winedump' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/winegcc' ../../tools/makedep -C. -S../.. -T../.. utils.c winegcc.c make[2]: Leaving directory `/home/susan/wine/tools/winegcc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wmc' ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y make[2]: Leaving directory `/home/susan/wine/tools/wmc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' make[2]: Entering directory `/home/susan/wine/tools/wrc' ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.c parser.y parser.l make[2]: Leaving directory `/home/susan/wine/tools/wrc' ../tools/makedep -C. -S.. -T.. -I/usr/include/freetype2 fnt2bdf.c fnt2fon.c make_ctests.c makedep.c relpath.c sfnt2fnt.c make[1]: Leaving directory `/home/susan/wine/tools' ./tools/makedep -C. -S. -T. make[1]: Entering directory `/home/susan/wine/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/susan/wine/tools' make[1]: Entering directory `/home/susan/wine/libs' make[2]: Entering directory `/home/susan/wine/libs/port' ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -h -H ../../include/wtypes.h ../../include/wtypes.idl make[2]: ../../tools/widl/widl: Command not found make[2]: *** [../../include/wtypes.h] Error 127 make[2]: Leaving directory `/home/susan/wine/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/susan/wine/libs' make: *** [libs] Error 2 susan(a)ubuntu:~/wine$

Dec. 23, 2008

Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.

by Maarten Lankhorst

Hi Juan and Hans, Juan Lang schreef: > Hi Hans, > > >> Maarten, do you remember what the code to store attribute certs was >> needed for? I'd like to address Juan's concern by either adding a test >> or taking the code out. >> > > I wouldn't worry about it. The code looks correct to the eye, it's > just calling part of crypt32 that's stubbed out (and on my list.) > Mainly I was curious if you'd managed to test with native crypt32 > somehow, as that's something I've never managed to make work (on > Linux.) > I was working on some code that needed it, The specific functions were stubbed out (crossover proprietary advantage (TM)) so it's not used, but the correct implementation of CryptCATGetCertAttr/CryptCATEnumCertAttr would need the attributes. Cheers, Maarten.

Dec. 23, 2008

Re: Wine build failed

by Austin English

On Tue, Dec 23, 2008 at 3:43 AM, Stefan Leichter <sle85276(a)gmx.de> wrote: > Hello, > > building current git tree fails to me on Debian Etch (x86) with: > > ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include > -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o > font.o ../../../wine-git/dlls/gdi32/font.c ccache gcc -c > -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include > -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o > freetype.o ../../../wine-git/dlls/gdi32/freetype.c > ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration > specifiers or '...' before 'FT_LcdFilter' > ../../../wine-git/dlls/gdi32/freetype.c: In function > 'WineEngGetGlyphOutline': ../../../wine-git/dlls/gdi32/freetype.c:4776: > error: 'FT_LcdFilter' undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared > identifier is reported only once > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it > appears in.) ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected > ';' before 'lcdfilter' ../../../wine-git/dlls/gdi32/freetype.c:4777: > warning: ISO C90 forbids mixed declarations and code > ../../../wine-git/dlls/gdi32/freetype.c:4785: error: 'lcdfilter' undeclared > (first use in this function) ../../../wine-git/dlls/gdi32/freetype.c:4785: > error: too many arguments to function 'pFT_Library_SetLcdFilter' > ../../../wine-git/dlls/gdi32/freetype.c:4803: error: 'FT_LCD_FILTER_DEFAULT' > undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c:4803: error: 'FT_LCD_FILTER_LIGHT' > undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c: In function > 'is_subpixel_rendering_enabled': > ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to > function 'pFT_Library_SetLcdFilter' make[2]: *** [freetype.o] Fehler 1 > make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' > make[1]: *** [gdi32] Fehler 2 > make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' > make: *** [dlls] Fehler 2 > > > ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o font.o ../../../wine-git/dlls/gdi32/font.c > ccache gcc -c -I../../../wine-git/dlls/gdi32 -I. -I../../../wine-git/include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o ../../../wine-git/dlls/gdi32/freetype.c > ../../../wine-git/dlls/gdi32/freetype.c:187: error: expected declaration specifiers or â€˜...â€™ before â€˜FT_LcdFilterâ€™ > ../../../wine-git/dlls/gdi32/freetype.c: In function â€˜WineEngGetGlyphOutlineâ€™: > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: â€˜FT_LcdFilterâ€™ undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: (Each undeclared identifier is reported only once > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: for each function it appears in.) > ../../../wine-git/dlls/gdi32/freetype.c:4776: error: expected â€˜;â€™ before â€˜lcdfilterâ€™ > ../../../wine-git/dlls/gdi32/freetype.c:4777: warning: ISO C90 forbids mixed declarations and code > ../../../wine-git/dlls/gdi32/freetype.c:4785: error: â€˜lcdfilterâ€™ undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c:4785: error: too many arguments to function â€˜pFT_Library_SetLcdFilterâ€™ > ../../../wine-git/dlls/gdi32/freetype.c:4803: error: â€˜FT_LCD_FILTER_DEFAULTâ€™ undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c:4803: error: â€˜FT_LCD_FILTER_LIGHTâ€™ undeclared (first use in this function) > ../../../wine-git/dlls/gdi32/freetype.c: In function â€˜is_subpixel_rendering_enabledâ€™: > ../../../wine-git/dlls/gdi32/freetype.c:5923: error: too many arguments to function â€˜pFT_Library_SetLcdFilterâ€™ > make[2]: *** [freetype.o] Fehler 1 > make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' > make[1]: *** [gdi32] Fehler 2 > make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' > make: *** [dlls] Fehler 2 > > > > > A fix was committed today, please retest. -- -Austin

Dec. 23, 2008

Re: d3d9/visual tests timed out

by Rico Schüller

Michael Stefaniuc schrieb: > Jeff Zaroyko wrote: >> On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller <kgbricola(a)web.de> wrote: >>> Hi, >>> >>> on my XP machine the visual d3d9 test produces a timeout message, when >>> it is started from the winetest build. Anyone here could run the tests >>> on windows without a timeout (and off course without skipping half of >>> the tests - have to be more than 4k tests)? >>> >>> Also there is no message about a timeout on the test site ( >>> http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-… >>> >>> ). >>> >>> Cheers >>> Rico >> >> While it's true that it takes some time and says it timed out while >> running and will attempt to terminate it when you hit OK, I think this >> dialog appears while the test is still running you don't notice it >> until after it successfully finishes and exits, so the attempt to >> terminate does nothing. >> >> I have seen this happen on Windows 2008 with GeForce 8 (180.42) and >> Windows 98 with GeForce 5. > My Atom based netbook with i915 graphics on F10 hits the timeout too. > It's a minor nuisance as I have to hit the "OK" button even though the > test will finish just fine. > > bye > michael > Thanks for the answers, so nothing to worry about, it's just a little bit annoying. Cheers Rico

Dec. 23, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Nick Burns

Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer) BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw surface version setting)? Concerning negative pixelzoom and drawpixels on R500 Please file a radar on that (and email the mac-opengl mailing list) - Nick ---------------------------------------- > From: stefan(a)codeweavers.com > To: wine-devel(a)winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux) > Date: Tue, 23 Dec 2008 13:30:40 +0100 > > This patch looks good. > > There's one last thing we should check: It seems that this is the only code > that uses GL_PACK_ROW_LENGTH and friends, so the backup and restore is > probably not needed. I think for now it is better to add it because I > suspect the code in surface_download_data most likely depends on the default > settings without properly controlling them. > > There's some related driver bug on OSX too(no radar filed yet, > unfortunately). Using a PBO for glDrawPixels with a negative pixelzoom(wine > uses -1 for y) breaks at least on my radeon X1600 with MacOS 10.5.5. I > haven't yet tested it with 10.5.6, but if it is still broken there I have to > remember to file a bug. It is sort of a follow-up bug to a bug fixed in > 10.5.5; Before that glPixelZoom and PixelPos were completely ignored with > PBOs. > > This bug was on my todo list for a long time by the way. I wanted to fix it, > got distracted and forgot again :-/

Dec. 23, 2008

Re: how to create a broken .tlb file

by Alexandre Julliard

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > a) Include a broken (hand-patched) tlb file as binary file in git > b) Include a program that breaks tlb files and call it while > building tests > c) Include tlb file patching into the testcase (i.e. copy a good tlb, > patch it, and perform some tests with the copy, than delete it) > > Which approach would have the highest chance of getting the fix > (including the testcase that tests broken type libraries) included into > Wine? c) is the way to go. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2008

Re: bugfix: resend: fix serial_flush

by Alexandre Julliard

Wolfgang Walter <wine(a)stwm.de> writes: > Would it be acceptable to call tcdrain directly in NtFlushBuffersFile: Yes, something like that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2008

[RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Vincent Pelletier

(Resent, originally sent to -patches... Sorry) If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is set to an invalid size, glPointSize will fail. This happens in "Black & White 2", causing log/stderr to be flooded with opengl errors. I'm not sure if this should be fixed here, or when setting state value. Also, maybe it should be avoided to double-check against opengl bounds when WINED3DRS_POINTSCALEENABLE is true. I would be happy to get some feedback on that patch. -- Vincent Pelletier

Dec. 23, 2008

Re: d3d9/visual tests timed out

by Michael Stefaniuc

Jeff Zaroyko wrote: > On Tue, Dec 23, 2008 at 9:57 PM, Rico Schüller <kgbricola(a)web.de> wrote: >> Hi, >> >> on my XP machine the visual d3d9 test produces a timeout message, when >> it is started from the winetest build. Anyone here could run the tests >> on windows without a timeout (and off course without skipping half of >> the tests - have to be more than 4k tests)? >> >> Also there is no message about a timeout on the test site ( >> http://test.winehq.org/data/028617b90ba586bdb30723c700eea888c159ada7/xp_rs-… >> ). >> >> Cheers >> Rico > > While it's true that it takes some time and says it timed out while > running and will attempt to terminate it when you hit OK, I think this > dialog appears while the test is still running you don't notice it > until after it successfully finishes and exits, so the attempt to > terminate does nothing. > > I have seen this happen on Windows 2008 with GeForce 8 (180.42) and > Windows 98 with GeForce 5. My Atom based netbook with i915 graphics on F10 hits the timeout too. It's a minor nuisance as I have to hit the "OK" button even though the test will finish just fine. bye michael

Dec. 23, 2008

Symlink vulnerability in winetricks

by Stefan Nordhausen

Hi! Winetricks has a symlink vulnerability, it does (echo "$title"; echo ""; echo "$text") > /tmp/x_showmenu.txt An attacker can exploit this by creating a symlink called /tmp/x_showmenu.txt and have it point to some file that a winetricks user can write (e.g. ~/Documents/important_stuff.odf). Winetricks will then overwrite that file with its data. To solve this, apply the following patch that simply avoids the creation of a temporary file: --- winetricks 2008-12-18 06:34:42.000000000 +0100 +++ winetricks 2008-12-23 18:00:17.000000000 +0100 @@ -207,8 +207,8 @@ args="$args,$1" shift done - (echo "$title"; echo ""; echo "$text") > /tmp/x_showmenu.txt - xmessage -print -file /tmp/x_showmenu.txt -buttons "Cancel,$args" | sed 's/Cancel//' + (echo "$title"; echo ""; echo "$text") | \ + xmessage -print -file - -buttons "Cancel,$args" | sed 's/Cancel//' } showmenu() Merry Christmas Stefan

Dec. 23, 2008

Re: DIB Engine

by Jesse Allen

On Tue, Dec 23, 2008 at 3:44 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > As my DIB engine is becoming usable (I already use it on Autocad for my > job), I'm thinking to publish the patches. > As it's still not complete, I'm thinking to add a way to enable it on > demand with registry and environment variable : > > export WINEDIB=ON activates it > export WINEDIB=OFF deactivates it > > if no environment variable, it checks a registry key (I'd like to have > some suggestion on where to put it). > If no environment variable nor registry entry are present it'll be > disabled (by now) as is for testing purposes. A reg key is a good idea with it off by default. The other thing I did was if a packager didn't want to include it then it automatically fell back to winex11 for DIBs to run like before. > > How should I publish it ? A big unique patch, 2 patches, one with the > (small) changes in gdi32 and another big one with the engine itself, or > many small patches ? > Is it right to put on wine patches list ? > My intention to proposing patches would have been in this order. 1. The gdi changes to allow the engine to work. 2. The skeleton of the dib driver. 3. A patch per function with test cases proving the functionality. But my recommendation for your current work is to make one big patch for review so I and others can just give you immediate feedback. We can split it up or put up a git fork later. Jesse

Dec. 23, 2008

Re: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

by Rico Schüller

Stefan Dösinger schrieb: > I never saw this crashing on any of my systems, so it is probably driver dependent. Which Windows driver are you using? > > If the test crashes on either ATI, Nvidia or Intel it is a good idea to remove it. I don't think we should remove it if it crashes on something like VMWare or other 'noname' cards. > > I checked this on 4 different machines with the following cards all on XP - Ati 9700M - Geforce 5700FX - Geforce 8800GTS - Geforce 8800GT Just check the test page to see the d3d9 shader test crashes on all machines which didn't skip the complete test! ( http://test.winehq.org/data/0b3b6e67ea663e853cc6bb93f4da447ab934e50d/#group… ) Cheers Rico

Dec. 23, 2008

Re: MSVCP80 implementation

by Paul Chitescu

On Tuesday 23 December 2008 16:22:52 Steven Edwards wrote: > On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov > > <dmitry(a)codeweavers.com> wrote: > > MSVCP80 is not a part of win32 API, that's a redistributable run-time > > library supposed to be provided by an application. > > Does the EULA allow for it to be packaged for use on non-windows > systems? If not then thats not an option for Winelib developers. Winelib developers have the option not to use Visual C++ runtimes at all. If they need to access DLLs or executables installed by some other application then the other program should install MSV*80.DLL itself or the runtimes can be installed if missing just like you would do on Windows. The *other* application needs them and is legal to redistribute them being targeted at the Windows environment. Paul Chitescu

Dec. 23, 2008

Re: MSVCP80 implementation

by Steven Edwards

On Mon, Dec 22, 2008 at 10:31 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > MSVCP80 is not a part of win32 API, that's a redistributable run-time > library supposed to be provided by an application. Does the EULA allow for it to be packaged for use on non-windows systems? If not then thats not an option for Winelib developers. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 23, 2008

RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

by Detlef Riekenberg

On Di, 2008-12-23 at 14:24 +0100, Stefan Dösinger wrote: > I'm only afraid of this hypothetical scenario: > 1) We remove a test because it breaks on $NONSTANDARDWINDRV We disable the test with: if (0) { /* that crash on $NONSTANDARDWINDRV */ <full test here> } > 3) Some future patch changes this behavior > 4) The test doesn't warn us because it was removed Of course, the disabled test does not protect us from the scenario above, but the test is still available for documentation. > IMHO it is better to use broken() wherever possible, although with a crash that is hard to do. using broken() on a crashing test will not prevent the crash -- By by ... Detlef

Dec. 23, 2008

RE: d3d9: Set IDirect3DDevice9Impl_GetVertexShader return value to NULL on error

by Stefan Dösinger

> No, this patch is obviously correct. Hmm right, the code treats pShader == NULL as 'failure'. Looking at the WineD3D code, it would only fail if ppShader == NULL, which would moot the point of setting *ppShader to NULL anyway. My bad in this case

Dec. 23, 2008

RE: d3d9/tests: Don't create a Null-shader in d3d9, it will crash.

by Stefan Dösinger

> The patch is already applied, but I think removing the test is the > right thing to do. I only added the test to test what error d3d9 > returns when a NULL shader is passed. If it depends on the driver, I > doubt we care. This patch was a good idea, yes I'm only afraid of this hypothetical scenario: 1) We remove a test because it breaks on $NONSTANDARDWINDRV 2) $BUGGYGAME depends on the tested behavior, and is broken on above driver on Windows too 3) Some future patch changes this behavior 4) The test doesn't warn us because it was removed 5) $BUGGYGAME is now broken on Wine ???) The test removed in (1) is added again because $BUGGYGAME depends on it and the developer who fixes the regression doesn't know about $NONSTANDARDWINDRV IMHO it is better to use broken() wherever possible, although with a crash that is hard to do.

Dec. 23, 2008