November 2004 - Wine-Devel - list.winehq.org

Re: Version Resources
by Dan Kegel Nov. 23, 2004

Nov. 23, 2004

Tom wrote: > I hope this patch looks better. :) > If anything is incorrect just let me know. FYI, please don't use # in patch filenames. Sometimes that's a comment character, and it gives us shell programmers the willies. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

System colors
by Kevin Koltzau Nov. 23, 2004

Nov. 23, 2004

CreateBrushIndirect under Wine currently returns stock brushes if the brush requested matches the color. In gdi/brush.c the following comment is made: /* If a solid brush is created in a color matching one of the * stock brushes, native returns the stock object (GDI heap * optimisation). Some apps rely on this as they otherwise * would leak their brushes. */ However under both Windows 95 and Windows XP this does not seem to be the case. Under Windows, the following holds true, but fails under Wine GetStockObject(BLACK_BRUSH) != CreateSolidBrush(RGB(0,0,0)) This issue currently breaks applications making calls to SetSysColors as stock brushes are deleted as the new colors are added. Does anyone know why this was setup in this way? Or which version of Windows that exhibits the behavior mentioned in the comment? -Kevin

2 1

Problems with mailing list
by Robert van Herk Nov. 23, 2004

Nov. 23, 2004

Hi all, Last month I moved, as did my ip address. Since then, I don't seem to get any messages from the wine devel mailing list, although I am still subscribed. I don't know whom to send this to, but can somebody (the admin of the list) please try to find out what is the problem? Thanx, Robert

2 1

Handles in GDI
by lats Nov. 23, 2004

Nov. 23, 2004

I have been trying to track a problem in gdiobj.c where I had a handle of 0x107e. In GDI_GetObjPtr the handle & 2 is said to indicate a GDI Heap handle. From everything else I have read, that bit is supposed to indicate a Moveable handle. Is there something special about GDI handles that I should know about? Jeff

1 0

Configure missing a step
by Scott Ritchie Nov. 23, 2004

Nov. 23, 2004

I managed to get past configure and then have a compile error due to a missing header file: intrinsic.h Configure should be checking for this file, like it checks for flex and bison and such. The package I needed to install was libxt-dev I'm on Ubuntu at the moment, but this should be true for all Debian systems. Could someone else clean this up? I'm scared to touch configure. -Scott Ritchie

1 0

Re: syscolors: do not delete stock brushes
by Kevin Koltzau Nov. 23, 2004

Nov. 23, 2004

Please do not apply this patch On Thursday 11 November 2004 11:38 pm, Kevin Koltzau wrote: > This is a bit of a bad hack, but very bad things happen when a stock brush is deleted > > Changelog > Prevent deletion of stock brushes when system colors change >

1 0

Re: Resend: [dx9-12 next try] SetStreamSource changes
by Mike Hearn Nov. 23, 2004

Nov. 23, 2004

On Mon, 22 Nov 2004 20:01:03 +0000, Ann and Jason Edmeades wrote: > Was there a problem with this one - Its really holding me up with progress, > so I need to ensure I resolve any issues asap. Apologies if this is still in > your list of patches to work through as I heard you have just moved If the problem is source control related (as opposed to technical direction related) you may want to look at svk, which lets you branch CVS repositories into a local repository then commit to your branch. Unlike arch it doesn't require a gateway and it isn't hard to set up or use. Hope that helps. thanks -mike

2 1

Re: profiling GTA4. question about polling
by Brian Gunlogson Nov. 23, 2004

Nov. 23, 2004

--- Raphael <fenix(a)club-internet.fr> wrote: > Well, drawStriddedSlow is very very very slow (as function name :) ) > because is the software rendering path of wine d3d8 implementation > The only way to have good performances is to add needed support to hardware > rendering path (drawStriddedFast). > > Current version on hardware rendering path doesn't support (see > d3d8/drawprim.c:1590): > - pixel size (rarely used) > - blending weights (low use) > - diffuse color (highly used) > > In this cases the slow rendering path is used instead. > > I have a local "prototype" to have a better support of that cases (using > hardware vertex buffers) who have very good performances. > Ex: i have now a good framerate for UT2004 and Unreal2 (before i had ugly > lags) > > But, as Jason is currently doing a lot of work on splitting/moving code to > wined3d, we'll have to wait to commit it (and i should help him, when i'll > have time). Is this a tedious task or does it require knowledge of the codebase? I might be able to help. > Anyway, can you test what GTA4 want to use: diffuse, psize or/and blending ? > I'll try to send you a patched version of d3d8 to test after that :) GTA uses diffuse color exclusively. This was after playing the game for about 3 minutes on highest settings: pixel size: 0 diffuse: 745455 blending weights: 0 > Regards, > Raphael > > PS: > how have you done to use oprofile on wine ? > i'm very interested :) Just download the latest CVS from http://oprofile.sourceforge.net/download/ and see the README. I assume you know how to get it compiled and installed :) As root: # opcontrol --start # opcontrol --reset '--reset' clears out any old unwanted profiling data # opcontrol --separate=kernel '--separate=kernel' Seperates output by library and kernel [this is the hardest option to understand]. Profiling is on, run the application to profile and do not do anything else. When done: # opcontrol --dump '--dump' flushes remaining data to disk # opreport -l >./myreport.log Stores the flat profile in a file called myreport.log. Brian G __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn wrote: >> I'm not aware of e.g. an LSB-1.3 application that doesn't run properly >> on any system that supports LSB-1.3. Are you? > > I'm not aware of any LSB applications at all, actually. But let's take > RealPlayer for example. Let's pretend that Real had made it an LSB app. > > Would that have saved it from being broken by NPTL. No. LSB doesn't > specify (as far as I'm aware) that LSB apps must be linked > against LinuxThreads. Bzzt. In the real world, the distro vendor would have noticed this during LSB certification, and since the shared library loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2, the vendor can easily force libc to be linuxthreads based even if the default libc is NPTL based. I believe that as people start building LSB-compliant apps, they'll find it quite a useful way to avoid having to package ten different flavors of their apps just to be compatible. It's going to be a lot easier with LSB 3.0, since by that time the C++ ABI will have settled down, but I do think even LSB 2.0 is worth looking at for some applications. Yes, I know, you'll probably want to post something bitter and negative about LSB in response, but I'm going to put my hands over my ears and go "la la la", so I won't notice whether you actually do :-) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn: > 1) The RH9 RPMs are apparently being compiled with epoll support linked > in. This is causing user pain. We should really be using dlsym here, > why are we not again? Alexandre Julliard: > glibc is not backwards compatible, the RH9 RPMs should be built > against the RH9 glibc. There is nothing special about epoll, you can > have the same issue with any glibc symbol, and we can't start > dynamically loading them all. Mike Hearn: > We don't have to be over-general about it, just dynamically loading the > ones that cause problems would be fine (or using syscalls directly). The > vast majority of the symbols are always there and so it doesn't make sense > to use dlsym. Alexandre Julliard: > I think it's much better to ask packagers to build their packages > correctly, it will cause much less trouble in the long run. Or better yet, ask people to download the right package. I just downloaded http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm and it worked fine on RH9. I wonder, though: the fact that somebody downloaded the wrong package means there are probably too many different versions at sourceforge to download. I count 24 packages! (OK, a few of them are srpms.) Shoot, can't we package Wine as an LSB package? I suspect Wine depends on nothing that isn't in the LSB. That'd make life a lot easier for the users... at least for those whose distros come with LSB support installed by default. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

12 28