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

Re: Explicit fall-through in switch statements?

by Bruno Jesus

On Sun, Nov 25, 2012 at 9:20 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > For every wine version, static checkers (like coverity) detect cases > where a switch case automatically falls-through to the next case. > > Shouldn't be there a rule that such cases are always marked with a > "fall-through comment"? > With the possible exception of case with no statement? like 'case FOO: > case BAR: do_something();...'? I remember about a similar discussion: http://www.winehq.org/pipermail/wine-devel/2011-September/092475.html > Frédéric Best wishes, Bruno

Nov. 25, 2012

Explicit fall-through in switch statements?

by Frédéric Delanoy

For every wine version, static checkers (like coverity) detect cases where a switch case automatically falls-through to the next case. Shouldn't be there a rule that such cases are always marked with a "fall-through comment"? With the possible exception of case with no statement? like 'case FOO: case BAR: do_something();...'? This would probably help IMHO, especially when people refactor old code. Frédéric

Nov. 25, 2012

Re: [PATCH 5/5] winex11: Detect broken NVIDIA RandR setups.

by Henri Verbeet

On 24 November 2012 18:01, Dan Kegel <dank(a)kegel.com> wrote: > Do you happen to have a link to discussion about this, or an nvidia bug number? > Mostly http://www.nvnews.net/vbulletin/showpost.php?p=2552001&postcount=6 / http://www.nvnews.net/vbulletin/showthread.php?t=179892 and http://www.winehq.org/pipermail/wine-devel/2012-September/096933.html, but if you search around a bit you'll also find a number of forum posts from random users with now broken setups.

Nov. 24, 2012

re: [PATCH 5/5] winex11: Detect broken NVIDIA RandR setups.

by Dan Kegel

Henri wrote: >+ /* Recent (304.64, possibly earlier) versions of the nvidia driver only >+ * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes >+ * are only listed through RandR 1.0 / 1.1. This is completely useless, >+ * but NVIDIA considers this a feature, so it's unlikely to change Do you happen to have a link to discussion about this, or an nvidia bug number? Thanks!

Nov. 24, 2012

Re: [1/2] widl: Fix enum entries output based on previous entry value

by Nikolay Sivov

On 11/23/2012 19:06, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> Apparently this is how midl works > I'm not sure that's an improvement, it makes it harder to figure out the > actual value. > The reason I did that to match what midl does was that I got bunch of compiler warnings trying to define XmlError enum like that: --- warning: this decimal constant is unsigned only in ISO C90 --- for each entry in enum that has a value calculated by widl. The reason is that it always outputs it as decimal so you get: 0xc00cee00 for a first entry and 3222072833 for a next one. It's probably possible to preserve hex format basing on last defined value. Do you prefer this way?

Nov. 23, 2012

Re: [1/2] widl: Fix enum entries output based on previous entry value

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > On 11/23/2012 19:06, Alexandre Julliard wrote: >> Nikolay Sivov <nsivov(a)codeweavers.com> writes: >> >>> Apparently this is how midl works >> I'm not sure that's an improvement, it makes it harder to figure out the >> actual value. >> > The reason I did that to match what midl does was that I got bunch of > compiler warnings trying to define > XmlError enum like that: > > --- > warning: this decimal constant is unsigned only in ISO C90 > --- > > for each entry in enum that has a value calculated by widl. The reason > is that it always outputs it as decimal so you get: > > 0xc00cee00 for a first entry and > 3222072833 for a next one. > > It's probably possible to preserve hex format basing on last defined > value. Do you prefer this way? Actually this should apply to all large enum constants. I put in a fix. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2012

Re: [1/2] widl: Fix enum entries output based on previous entry value

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Apparently this is how midl works I'm not sure that's an improvement, it makes it harder to figure out the actual value. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2012

Re: [02/10] windowscodecs: Reimplement QueryCapability of the BMP decoder.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Does QueryCapability really QueryCapability? Can you get a > frame out of it? I guess it never occurred to me to try. I've added a test that confirms that GetFrame succeeds after a successful QueryCapability call. > I was OK with this for the other implementations because I figured > it'd be easy enough to invalidate the decoder after successfully > calling Initialize, if that turned out to be a problem. Yes, that was also my impression that implementing QueryCapability using Initialize and then undo the changes would be an obvious (and easy to do) way to implement it, but apparently MS developers decided leave the state of the decoder unchanged (that's a really confusing behaviour of QueryCapability if you ask me). -- Dmitry.

Nov. 23, 2012

Re: [02/10] windowscodecs: Reimplement QueryCapability of the BMP decoder.

by Vincent Povirk

Does QueryCapability really initialize the decoder? Can you get a frame out of it? I guess it never occurred to me to try. I was OK with this for the other implementations because I figured it'd be easy enough to invalidate the decoder after successfully calling Initialize, if that turned out to be a problem.

Nov. 23, 2012

Wine Gecko 1.9-beta1

by Jacek Caban

Hi all, Firefox 17 was released lately, meaning that Firefox 18 goes to beta channel and it's the next target for out Gecko package update. I've uploaded new Gecko builds to SourceForge [1]. To test them, you need recent Wine Git version with the attached patch. As usually, grab the build from SourceForge, put it in the right place [2] and run patched Wine. All help with testing is appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.9-beta1/ [2] http://wiki.winehq.org/Gecko

Nov. 22, 2012