October 2007 - Wine-Devel - list.winehq.org

Re: pdh: check for NULL pointer reference

by Jeff Latimer

>> In this case the fix is for a Null reference as indicated in the >> accompanying tests. The test prangs in the current build and the patch >> for pdh_main.c fixes the behaviour on XP. As I said, I can't tell if it >> > > How can a fix to pdh_main.c (which is Wine's implementation) fix > something on XP? > The test shows a fault in wine not XP, sorry if I confused the issue. When this test is executed it causes a NULL reference in wine. The fix is for wine. >> fixes it in anything else. However, there needs to be a fix for the >> NULL reference and the case of needing a buffer if size and index > 0 >> seems to be reasonable behaviour. >> > When a test fails on some version of Windows something is wrong with > the test itself. Possible solutions are to make the test accept the > different behavior too or to remove the test altogether when it is > sufficiently clear that applications cannot depend on any particular > behaviour. > I have no idea whether this test has a problem on one version of Windows or another. I only know the behaviour in XP. This is not a case of XP explicit behaviour it is simply a case of NULL reference. I split the fix into two lines rather than merging it into one because it made the test pass ok in wine and Windows XP. I put a comment to say that as I am sure that someone would have picked that up and queried it. My question was whether this was the same behaviour in other flavours of windows. I suspect it is ok but... your previous posts indicated that there may be problems. Jeff

Oct. 22, 2007

Re: pdh: check for NULL pointer reference

by Hans Leidekker

On Monday 22 October 2007 13:15:57 Jeff Latimer wrote: > In this case the fix is for a Null reference as indicated in the > accompanying tests. The test prangs in the current build and the patch > for pdh_main.c fixes the behaviour on XP. As I said, I can't tell if it How can a fix to pdh_main.c (which is Wine's implementation) fix something on XP? > fixes it in anything else. However, there needs to be a fix for the > NULL reference and the case of needing a buffer if size and index > 0 > seems to be reasonable behaviour. When a test fails on some version of Windows something is wrong with the test itself. Possible solutions are to make the test accept the different behavior too or to remove the test altogether when it is sufficiently clear that applications cannot depend on any particular behaviour. -Hans

Oct. 22, 2007

Re: pdh: check for NULL pointer reference

by Jeff Latimer

> > I don't think we want to emulate the broken XP behaviour of requiring a > buffer, even when querying the buffer size. Apps written to comply with > this behaviour should work on the current implementation. And MSDN mentions > only XP, which implies that it has been fixed in Win2k3 and up. In this case the fix is for a Null reference as indicated in the accompanying tests. The test prangs in the current build and the patch for pdh_main.c fixes the behaviour on XP. As I said, I can't tell if it fixes it in anything else. However, there needs to be a fix for the NULL reference and the case of needing a buffer if size and index > 0 seems to be reasonable behaviour. Does the test set work on Win2003|win2K? Jeff

Oct. 22, 2007

Re: pdh: check for NULL pointer reference

by Hans Leidekker

On Monday 22 October 2007 11:30:10 Jeff Latimer wrote: > This function has specific XP behaviour which I have tested but I have > not been able to verify that Win2k etc works the same. Any comment welcome. I don't think we want to emulate the broken XP behaviour of requiring a buffer, even when querying the buffer size. Apps written to comply with this behaviour should work on the current implementation. And MSDN mentions only XP, which implies that it has been fixed in Win2k3 and up. -Hans

Oct. 22, 2007

"winefix" - interesting wrapper for wine

by Dan Kegel

Tom W. found and publicized a script called "winefix" by an ubuntu forums user named "deadlydeathcone": http://digg.com/linux_unix/Winefix_improved_desktop_integration_for_Wine http://wine-review.blogspot.com/2007/10/winefix-improved-desktop-integratio… http://ubuntuforums.org/showthread.php?s=6e904c1df87d3fd1698ab5d7bbdbf664&t… It's got a bunch of interesting stuff. I wonder if we could get him to join wine-devel and start contributing to wine itself... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Oct. 22, 2007

Anything wrong with my patch from 16.10. about w32x86 and win40 creation?

by Markus Gömmel

I think it's not a big deal but would help making on of our EmTec products more compatible... Markus

Oct. 22, 2007

Re: Phoronix: Ubuntu 7.10 + WINE vs. Windows XP

by Stefan Dösinger

Am Montag, 22. Oktober 2007 08:24:18 schrieb Vitaliy Margolen: > H. Verbeet wrote: > > On 21/10/2007, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > >> GLSL maybe, but not FBO. It causes major slowdown in most source games. > >> And I'm talking about drop to 0.1 FPS. If that can be fixed then I don't > >> see major reasons why FBO can't be the default. If anything it does fix > >> a lot of lighting and geometry related problems in number of other > >> games. > > > > Is that a regression? At least for HL2 & CSS it never did that for me. > > (And at least a while ago CSS stress test actually was faster with > > FBOs) > > No it's not a regression. Not in Wine at least. I went back to older > versions and it still painfully slow. > Of course it could be some change in CSS. I also checked with older video > drivers and results the same. > > The major slowdown comes from ... SterchRect. And even with that disabled > FBOs are still slower then default. Apparently the source engine now uses a depth buffer with stencil, something it didn't use to do in the past. Perhaps some fallout of the Episode 2 extension of the engine.

Oct. 22, 2007

Re: ReplaceFileW (was: Phoronix: Ubuntu 7.10 + WINE vs. Windows XP)

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes: > I can't believe this, probably you misunderstood or misinterpreted something. > ReplaceFile API needs to abide sharing and access rights rules which are known > only to wineserver, and not known/available on the libc/kernel level. Of course you need to call CreateFile to check sharing etc., but after that the replacing should be done with link() and/or rename(), not by copying the files. Essentially it should be done just like MoveFile. -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2007

Re: ReplaceFileW (was: Phoronix: Ubuntu 7.10 + WINE vs. Windows XP)

by Reece Dunn

On 22/10/2007, Stephan Rose <kermos(a)somrek.net> wrote: > > On Sun, 2007-10-21 at 19:33 +0900, Dmitry Timoshkov wrote: > > "Reece Dunn" <msclrhd(a)googlemail.com> wrote: > > > > > On 20/10/2007, Dan Kegel <dank(a)kegel.com> wrote: > > >> Reece Dunn wrote: > > >> > The patch was rejected by Alexandre because the patch was > > >> > implementing that command using Windows API calls, > > >> > when it should be implemented natively as POSIX/GNU calls. > > >> > > >> Really? Where did he say that? It'd be nice to link to that from > > >> http://bugs.winehq.org/show_bug.cgi?id=7544 > > >> - Dan > > > > > > I asked him about it at WineConf and that is a summary of what he said. > > > > I can't believe this, probably you misunderstood or misinterpreted something. > > ReplaceFile API needs to abide sharing and access rights rules which are known > > only to wineserver, and not known/available on the libc/kernel level. > > > > Ok so what's the right way to implement this now? If I'm going to do > this, and I most certainly wouldn't mind doing that, I'd like to be able > to do it the right way the first time around. I'd suggest working on the tests first and get these passing on Windows, as I discussed on the initial thread. These should initially be based on the MSDN documentation. Don't forget to cover both A and W variants. This will then give you the behaviour of that function on Windows that you can then use to implement it on Wine and know that the function is implemented correctly. Also, the tests are more likely to get in than any implementation. These will also help convince Alexandre (if I interpreted what he said correctly) that the ReplaceFile[A/W] behaviour is more complex than he thinks. The stub for ReplaceFileW can be created and ReplaceFileA can be fully implemented, as that just feeds its data to ReplaceFileW. - Reece

Oct. 22, 2007

Re: Phoronix: Ubuntu 7.10 + WINE vs. Windows XP

by Vitaliy Margolen

H. Verbeet wrote: > On 21/10/2007, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> GLSL maybe, but not FBO. It causes major slowdown in most source games. And >> I'm talking about drop to 0.1 FPS. If that can be fixed then I don't see >> major reasons why FBO can't be the default. If anything it does fix a lot of >> lighting and geometry related problems in number of other games. >> > Is that a regression? At least for HL2 & CSS it never did that for me. > (And at least a while ago CSS stress test actually was faster with > FBOs) No it's not a regression. Not in Wine at least. I went back to older versions and it still painfully slow. Of course it could be some change in CSS. I also checked with older video drivers and results the same. The major slowdown comes from ... SterchRect. And even with that disabled FBOs are still slower then default. Vitaliy.

Oct. 22, 2007