April 2009 - Wine-devel - list.winehq.org

Re: [4/8] WineD3D: Support the full amount of constants in GLSL
by Henri Verbeet 10 Apr '09

10 Apr '09

2009/4/9 Stefan Dösinger <stefan(a)codeweavers.com>: > Please do not apply this patch without patches 5, 6, 7 and 8. In some > circumstances, this patch can step on the toes of inefficient MacOS drivers > or old fglrx versions. The additional patches give wined3d knowledge of these > driver problems to prevent this. > If this patch depends on those patches to work properly, shouldn't it come after them? > +void record_const_read(DWORD reg, unsigned int *array, int *num) { This should be static. Wrt the implementation, there are only 16 boolean constants and 16 integer constants. Using a bitmap and doing a bitcount should be trivial.

1 0

Re: [5/8] WineD3D: Add a more formal framework for driver quirks
by Henri Verbeet 10 Apr '09

10 Apr '09

There are a couple of things I don't like about this patch. - I don't like how much information specific to constant fixups the table contains. - The "apple" field is weird. If you're going to have a callback function you might as well match that information there, if appropriate. On the other hand, I don't think you really need the callback function, you only match on vendor and card anyway. - What is the point of only allowing one fixup per card, and then adding QUIRK_NO_SANITY_CHECK to allow more fixups? You might as well just allow multiple fixups and apply them in the order they're defined. - Why do you store the quirk table in gl_info? It's never used from there. (I realise the next couple of patches do use it from there). How about something like this: struct wined3d_driver_quirk { enum wined3d_driver_platform platform; GL_Vendors vendor; GL_Cards card; void (*fixup)(WineD3D_GL_Info *gl_info) }; and just add a DWORD "quirk_flags" to gl_info.

1 0

Test: patch to add adva,ced d3d settings in winecfg
by Warren Dumortier 09 Apr '09

09 Apr '09

Hello everybody... My patch to add advanced d3d settings in winecfg is almost ready. In fact, i only have to figure out how to detect video memory size to display it when no key is set to force it or to reset. Stefan D told me to use DirectDraw, but i wouldn't find. So that is the last thing (except some better naming...) to do for this patch. Everything works well and i would like some feedback. Thanks, kind regards.

3 4

Re: Sources of noise on test.winehq.org?
by Dan Kegel 09 Apr '09

09 Apr '09

The problem with the current arrangement is that when machines pop in and out, any failures that are more likely on those machines also pop in and out, so error counts fluctuate, which obscures the smaller changes due to wine fixes or regressions. I like the current output, and don't want to change it; I just want to add another view for people who want to judge progress. Setting up a view with a fixed set of machines would do, too. Which is easier? On Apr 9, 2009 12:12 PM, "Alexandre Julliard" <julliard(a)winehq.org> wrote: Dan Kegel <dank(a)kegel.com> writes: > On Thu, Apr 9, 2009 at 10:17 AM, Alexandre Julliard <julliard(a)... I don't see the point. If you want statistics for a specific machine, sure, we could generate a page for that. But the global index should show all the results we have. If it shows too many failures it means the tests are not robust enough across machines and should be fixed, not ignored. -- Alexandre Julliard julliard(a)winehq.org

2 1

Sources of noise on test.winehq.org?
by Dan Kegel 09 Apr '09

09 Apr '09

(This was last discussed in February, e.g. http://www.winehq.org/pipermail/wine-devel/2009-February/073060.html ) The results on test.winehq.org seem more variable than one would expect, which makes it harder to gauge wine's progress. I can think of two sources of noise: 1) 32 and 64 bit results are mixed together 2) we don't have a stable stable (sic) of machines running the tests Removing these two sources of noise might be as simple as 1) omit 64 bit results, and 2) omit computers for which results are not consistently available throughout the time range being displayed Shouldn't be too hard for someone to whip together an alternate report that did that. Wish I had the time to... - Dan

4 12

Status of TaskDialog implementation?
by Koro 09 Apr '09

09 Apr '09

Hi, I would like to know what's the status on the TaskDialog implementation in Wine based on the code I gave to Dan Kegel months ago. Relevant threads: http://www.winehq.org/pipermail/wine-devel/2008-October/069724.html http://www.winehq.org/pipermail/wine-devel/2008-October/069800.html Thanks.

1 0

Cool animated display of wine appdb stats
by Dan Kegel 09 Apr '09

09 Apr '09

Has anyone else noticed http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif which is shown on the right side of http://en.wikipedia.org/wiki/Wine_(software) ? It's kind of cool. Hats off to http://en.wikipedia.org/wiki/User_talk:Estemi who put it together. - Dan

4 4

Re: SoC: DirectShow/Gstreamer
by Maarten Lankhorst 09 Apr '09

09 Apr '09

Hello Trevor, I think this is a great idea. I have no idea how gstreamer works, but a lot of quartz is automatic pulling the pipes etc together. There are 3 categories of filters in directshow: - Source filters (can be a file, can be a webcam, can be any filter that has only an output) - Intermediate filters (can decode or parse a file, multiple can be linked together) - Renderers I have only peeked at gstreamer, but it seems it is very similar. Wine's directshow however still misses a few things that are probably important, like sending information about when new segments start, etc. If you implemented a gstreamer codec, a big part of it could be to fix this to be more similar to what windows does. You will probably find graphedt.exe from the microsoft sdk useful, it used to be part of the directx sdk, but later I think it became part of the platform sdk. It will probably still run, but the save/load function for saving/restoring filtergraphs is missing. However last time I looked most other functionality from it worked, if not patches should be easy to write. Also some older directx sdk's had in the extras a debug version of windows' quartz dll which is very useful if you want to test your stuff against windows' quartz. It would output extra debug information which you could use to debug stuff. I would have to do some digging to find it back again. I have also made a stand-alone codec for schroedinger last year, which falls in the 'intermediate filters' category. It's source is available at: http://www.diracvideo.org/git?p=direct-schro.git;a=tree;h=HEAD This is a very basic filter based on wine's directshow code and using the schroedinger open source codec to do the decoding and encoding (they're separate filters). In encoder.c there is also a beginning of a properties dialog, which might be useful if you need one for the gstreamer filter. Cheers, Maarten.

3 3

Re: possible NULL dereference?
by Joris Huizer 09 Apr '09

09 Apr '09

--- On Thu, 4/9/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > From: Paul Vriens <paul.vriens.wine(a)gmail.com> > Subject: Re: possible NULL dereference? > To: "Joris Huizer" <joris_huizer(a)yahoo.com> > Cc: wine-devel(a)winehq.org > Date: Thursday, April 9, 2009, 7:53 AM > Joris Huizer wrote: > > Looking at git commit > dcb3e52e2dfd0d6e494164932fb2b684d463a005, it seems, passing > a NULL size pointer to GetUserNameEx[AW] is likely to > crash. > > You may want to test whether Windows versions crash on > it, and check for it if needed. > > > > HTH, Joris > > > There is also another one (mentioned by Coverity) where > passing a NULL lpNameBuffer and a big enough nSize will > crash. I tested that one on W2K3 and this also crashes on > W2K3. > > I didn't test the NULL nSize however. > > If time permits I'll add some tests and comments in the > case of crashes. If somebody wants to be beat me to > it, be my guest. > > Out of curiosity, did you find this by visual inspection? > > -- Cheers, > > Paul. > Yea I just noticed this while skimming through, now and then I look at the latest changes on git. I assume Coverity doesn't complain as it noticed you don't test the nSize pointer in any code path, so it assumes you know what you're doing. That seems like a general problem - if it could pick up the WINAPI flag (explicitly different calling convention) and realize every argument is suspect, it would find all such problems as well; Such behavior would be desirable for library functions in general, except that different projects are likely to have very different requirements about when a function is a library function to be treated like that. Specifying "what is a library function" might already be supported or perhaps it could be requested as a generally useful feature? regards, Joris

1 0

Re: dlls/userenv: fixed stubs GetUserProfileDirectoryW/A (resend)
by Paul Vriens 09 Apr '09

09 Apr '09

Andreas Rosenberg wrote: > > ------------------------------------------------------------------------ > > Just had a look again on your resend: this doesn't seem correct: + if ( lpcchSize && lpcchSize ) I also think that your addition of _GetAccountNameFromTokenW is holding the committing of this patch back, especially because you don't seem to use that function. -- Cheers, Paul.

2 3