wine-devel February 2014

wine-devel@winehq.org

63 participants
247 discussions

Start a nNew thread

Re: [PATCH 3/4] wmp: Added SetObjectRects implementation.
by Marvin 24 Feb '14

24 Feb '14

1 0

Re: [PATCH 2/4] wmp: Added DoVerb(OLEIVERB_HIDE) implementation.
by Marvin 24 Feb '14

24 Feb '14

1 0

Re: [PATCH 1/4] wmp: Return success in IPersistStreamInit::InitNew.
by Marvin 24 Feb '14

24 Feb '14

1 0

Re: ntdll: use case-insensitive matching for typelib flags
by Nikolay Sivov 24 Feb '14

24 Feb '14

On 2/22/2014 03:06, Austin English wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=35636 > > -- > -Austin Add a test please.

2 2

Re: Assorted typos fixes
by Dmitry Timoshkov 23 Feb '14

23 Feb '14

Andrey Gusev <andrey.goosev(a)gmail.com> wrote: > diff --git a/dlls/gdiplus/tests/image.c b/dlls/gdiplus/tests/image.c > index c4e61cc..1f94516 100644 > --- a/dlls/gdiplus/tests/image.c > +++ b/dlls/gdiplus/tests/image.c > @@ -3251,7 +3251,7 @@ static void test_GdipGetAllPropertyItems(void) > { PropertyTagTypeShort, 0x102, 6, { 8,0,8,0,8,0 } }, > { PropertyTagTypeShort, 0x103, 2, { 1 } }, > { PropertyTagTypeShort, 0x106, 2, { 2,0 } }, > - { PropertyTagTypeASCII, 0x10d, 27, "/home/meh/Desktop/test.tif" }, > + { PropertyTagTypeASCII, 0x10d, 27, "/home/meh/Desktop/test.tiff" }, > { PropertyTagTypeLong, 0x111, 4, { 8,0,0,0 } }, This change is obviously wrong. > diff --git a/dlls/ieframe/dochost.c b/dlls/ieframe/dochost.c > index 8c5d4b5..78b3f9e 100644 > --- a/dlls/ieframe/dochost.c > +++ b/dlls/ieframe/dochost.c > @@ -846,7 +846,7 @@ static HRESULT WINAPI DocHostUIHandler_ResizeBorder(IDocHostUIHandler2 *iface, > LPCRECT prcBorder, IOleInPlaceUIWindow *pUIWindow, BOOL fRameWindow) > { > DocHost *This = impl_from_IDocHostUIHandler2(iface); > - FIXME("(%p)->(%p %p %X)\n", This, prcBorder, pUIWindow, fRameWindow); > + FIXME("(%p)->(%p %p %x)\n", This, prcBorder, pUIWindow, fRameWindow); > return E_NOTIMPL; > } What's the reason for this one? -- Dmitry.

1 0

Re: Assorted typos fixes
by Marvin 23 Feb '14

23 Feb '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5100 Your paranoid android. === wxppro (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === wvista (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === wvistau64 (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === w2008s64 (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === w7pro64 (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === w8 (32 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === wvistau64 (64 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === w2008s64 (64 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch === w7pro64 (64 bit image) === image.c:3327: Test failed: 6: data mismatch image.c:3389: Test failed: 6: data mismatch

1 0

Re: Assorted typos fixes
by Marvin 23 Feb '14

23 Feb '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5099 Your paranoid android. === w2000pro (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === wxppro (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === wvista (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === wvistau64 (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === w2008s64 (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === w7pro64 (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === w8 (32 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === wvistau64 (64 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === w2008s64 (64 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output. === w7pro64 (64 bit dssenh) === dssenh.c:470: Test failed: Incorrect hash output. dssenh.c:470: Test failed: Incorrect hash output.

1 0

Re: resend: Windows sets CCS_VERT when TBSTYLE_EX_VERTICAL is set
by Marvin 23 Feb '14

23 Feb '14

1 0

ff-core effect id handling in case of a failed effect upload
by Elias Vanderstuyft 23 Feb '14

23 Feb '14

Hi, In the process of reviewing the Wine DInput translation layer, I noticed an inconvenience (in the ff-core implementation?) that can possibly lead to confusing problems to application developers (not only for Wine), in short: If a new (id==-1) effect was uploaded (look at ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), ff-core will have assigned a positive number to the effect id. This can be confusing because the dev->ff->effects[] array will not contain an element at the index of that new effect id. Here is a more elaborated description/discussion: - This is a bug that is either the responsibility of the Linux kernel, or of Wine (and possibly other applications that do the same thing as described below): It is caused by the following situation: When uploading an effect, the specific kernel device driver may return an error, e.g. EINVAL for example when a periodic's effect period is set to zero. This error will then be returned by "ioctl(*(This->fd), EVIOCSFF, &This->effect)". With or without error, one can find out that /drivers/input/ff-core.c:input_ff_upload(...) is called, which will set effect->id >= 0, if it was set to -1 (=> new effect created) by the user. But in case of an error: - Assume effect->id was set to -1 by the user: The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will also be set >= 0 (*). The offending effect will not be saved in the ff->effects[] array (***). - Assume effect->id was set >= 0 by the user (and ff->effects[effect->id] is a valid existing effect): The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will remain unchanged (**). The offending effect will not overwrite the ff->effects[effect->id] element (****). Is this (see *, **, *** and ****) desired behaviour? - If yes: Change the following in Wine's dinput/effect_linuxinput.c:90 : if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { to : int effectId_old = This->effect.id; if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { This->effect.id = effectId_old; - If no for *: Kernel code /drivers/input/ff-core.c:input_ff_upload(...) has to be patched to revert "effect->id" back to its original value set by the user, which is only needed when the initial (by user) value of "effect->id" was equal to -1. - If no for **** (or maybe also ***): ff->effects[effect->id] could be replaced by an 'empty' effect (however this can get complex because the effect's type has to remain unchanged) This would be a change in the kernel code /drivers/input/ff-core.c:input_ff_upload(...). - If no for **: I don't really know. Discussion is needed. - In my opinion, **, *** and **** are desired behaviour, while * should leave the effect->id at -1. In that case, Wine's dinput implementation does not have to be patched, and the kernel code only should apply a minor patch. Best regards, Elias

4 8

Re: oleaut32: Use BOOL type where appropriate
by Nikolay Sivov 22 Feb '14

22 Feb '14

On 2/22/2014 15:22, Frédéric Delanoy wrote: > --- > dlls/oleaut32/varformat.c | 8 ++++---- > dlls/oleaut32/vartype.c | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c > index e72a170..a6a10cf 100644 > --- a/dlls/oleaut32/varformat.c > +++ b/dlls/oleaut32/varformat.c > @@ -2303,9 +2303,9 @@ HRESULT WINAPI VarFormatNumber(LPVARIANT pVarIn, INT nDigits, INT nLeading, INT > if (nLeading == -2) > GETLOCALENUMBER(LOCALE_ILZERO, LeadingZero); > else if (nLeading == -1) > - numfmt.LeadingZero = 1; > + numfmt.LeadingZero = TRUE; > else > - numfmt.LeadingZero = 0; > + numfmt.LeadingZero = FALSE; > > if (nGrouping == -2) > { > @@ -2484,9 +2484,9 @@ HRESULT WINAPI VarFormatCurrency(LPVARIANT pVarIn, INT nDigits, INT nLeading, > if (nLeading == -2) > GETLOCALENUMBER(LOCALE_ILZERO, LeadingZero); > else if (nLeading == -1) > - numfmt.LeadingZero = 1; > + numfmt.LeadingZero = TRUE; > else > - numfmt.LeadingZero = 0; > + numfmt.LeadingZero = FALSE; > That's not a case when it's appropriate - 'LeadingZero' is UINT, not BOOL. Somewhat improved variant of above conditions could look like that: --- else numfmt.LeadingZero = nLeading == -1; ---

3 3

← Newer
1
...
5
6
7
8
9
10
11
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2014