January 2014 - Wine-devel - list.winehq.org

Re: strmbase: Store BasePinFuncTable inside Base*PinFuncTable structs.
by Alexandre Julliard 03 Jan '14

03 Jan '14

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/amstream/mediastreamfilter.c | 15 +++++++-------- > dlls/qcap/avico.c | 32 ++++++++++++++------------------ > dlls/qcap/avimux.c | 32 ++++++++++++++------------------ > dlls/qcap/vfwcapture.c | 15 +++++++-------- > dlls/quartz/filesource.c | 15 +++++++-------- > dlls/quartz/parser.c | 15 +++++++-------- > dlls/strmbase/pin.c | 24 ++++++++++++------------ > dlls/strmbase/renderer.c | 17 ++++++++--------- > dlls/strmbase/transform.c | 30 ++++++++++++++---------------- > include/wine/strmbase.h | 7 +++++-- > 10 files changed, 95 insertions(+), 107 deletions(-) There are other users, like winegstreamer and wineqtdecoder. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: Add test for FindFirstFileA()
by Marvin 03 Jan '14

03 Jan '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=3963 Your paranoid android. === wxppro (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooD.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === wvista (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooFB6A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo9FA.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo580A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo93F.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooF4B6.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267

1 0

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection (try2)
by Dmitry Timoshkov 03 Jan '14

03 Jan '14

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref-1; > +} This one still looks somewhat strange. Why not do something more straightforward like the following one? static inline ULONG get_refcount(IUnknown *iface) { IUnknown_AddRef(iface); return IUnknown_Release(iface); } -- Dmitry.

1 0

Re: [PATCH 4/5] scrrun: Implement IEnumVARIANT stub for folder collection
by Dmitry Timoshkov 03 Jan '14

03 Jan '14

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static inline ULONG get_refcount(IUnknown *iface) > +{ > + ULONG ref = IUnknown_AddRef(iface); > + IUnknown_Release(iface); > + return ref; > +} This implementation may lead to wrong conclusions. -- Dmitry.

2 3

How to bisect the 1.6.x series of commits
by Alan W. Irwin 03 Jan '14

03 Jan '14

I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date. The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot builds and tests, but when I recently tried 1.6.1, my usual parallel tests of PLplot software failed with an error indicating plot devices (small dll's) cannot be dynamically loaded by the PLplot principal library for that version of Wine. (The problem disappears if I do the tests sequentially for 1.6.1, but I obviously want to avoid that method of testing because it doubles the test time for my two-cpu PC.) The tests of 1.6-rc4 and 1.6.1 were quite similar but not absolutely identical so I do have to confirm the regression in behaviour for 1.6.1 with absolutely identical tests. But assuming I can do that, then I still have to discover if the problem occurred for 1.6. If so, the bisection needs to be an ordinary principal branch one that I am already familiar with between 1.6-rc4 and 1.6, but if not it needs to follow the 1.6.x development branch between 1.6 an 1.6.1. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

4 4

Re: advapi32/tests: Use BOOL type where appropriate
by Dmitry Timoshkov 03 Jan '14

03 Jan '14

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > diff --git a/dlls/advapi32/tests/security.c b/dlls/advapi32/tests/security.c > index 9f1e611..232a729 100644 > --- a/dlls/advapi32/tests/security.c > +++ b/dlls/advapi32/tests/security.c > @@ -4526,13 +4526,14 @@ static void test_mutex_security(HANDLE token) > STANDARD_RIGHTS_ALL | MUTEX_ALL_ACCESS }; > static const struct > { > - int todo, generic, mapped; > + BOOL todo; > + int generic, mapped; > } map[] = > { > - { 1, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > - { 0, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > - { 0, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > - { 0, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > + { TRUE, GENERIC_READ, STANDARD_RIGHTS_READ | MUTANT_QUERY_STATE }, > + { FALSE, GENERIC_WRITE, STANDARD_RIGHTS_WRITE }, > + { FALSE, GENERIC_EXECUTE, STANDARD_RIGHTS_EXECUTE | SYNCHRONIZE }, > + { FALSE, GENERIC_ALL, STANDARD_RIGHTS_ALL | MUTANT_QUERY_STATE } > }; Please don't touch these tests, 'int' is intentionally used here, and 'BOOL' buys you nothing. It's better to actually fix the source of these todos and remove them altogether. -- Dmitry.

1 0

Re: ddraw/tests: Use BOOL type where appropriate
by Marvin 03 Jan '14

03 Jan '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=3950 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

1 0

Re: [PATCH] ntdll: Improve handling of THUMB_MOV32 relocations
by André Hentschel 02 Jan '14

02 Jan '14

Am 02.01.2014 17:01, schrieb Martin Storsjo: > Since the delta variable actually is signed, the delta > 0xffff > condition could be false even if the high part of the delta > was nonzero, ending up with not updating the high half of the > relocation at all. > > Additionally, carry any overflow from the low word into the > high word delta. Hi, Do you have an App that triggers that? So you mean the case when the sign bit is used, e.g. 10101010b... Then the delta is negative, but is everything set correctly in the instruction? > --- > dlls/ntdll/loader.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index e0907e7..1f13424 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2230,19 +2230,19 @@ IMAGE_BASE_RELOCATION * WINAPI LdrProcessRelocationBlock( void *page, UINT count > DWORD inst = *(INT_PTR *)((char *)page + offset); > DWORD imm16 = ((inst << 1) & 0x0800) + ((inst << 12) & 0xf000) + > ((inst >> 20) & 0x0700) + ((inst >> 16) & 0x00ff); > + int hi_delta; Why you're using int here? DWORD looks much better for this.

2 2

Re: msvcp80: Fix ostreambuf_iterator<char> structure definition
by Alexandre Julliard 02 Jan '14

02 Jan '14

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcp90/ios.c | 88 > +++++++++++++++++++++++++++++++++++++------------- > dlls/msvcp90/msvcp90.h | 6 ++++ > 2 files changed, 72 insertions(+), 22 deletions(-) It breaks the Mingw build: locale.o:locale.c:(.text+0x94c): undefined reference to `_num_put_char_do_put_long(a)28' locale.o:locale.c:(.text+0x954): undefined reference to `_num_put_char_put_long(a)28' locale.o:locale.c:(.text+0x95c): undefined reference to `_num_put_char_do_put_ulong(a)28' locale.o:locale.c:(.text+0x964): undefined reference to `_num_put_char_put_ulong(a)28' locale.o:locale.c:(.text+0x96c): undefined reference to `_num_put_char_do_put_double(a)32' locale.o:locale.c:(.text+0x974): undefined reference to `_num_put_char_put_double(a)32' locale.o:locale.c:(.text+0x97c): undefined reference to `_num_put_char_put_ldouble(a)32' locale.o:locale.c:(.text+0x984): undefined reference to `_num_put_char_do_put_ptr(a)28' locale.o:locale.c:(.text+0x98c): undefined reference to `_num_put_char_put_ptr(a)28' locale.o:locale.c:(.text+0x994): undefined reference to `_num_put_char_do_put_int64(a)32' locale.o:locale.c:(.text+0x99c): undefined reference to `_num_put_char_put_int64(a)32' locale.o:locale.c:(.text+0x9a4): undefined reference to `_num_put_char_do_put_uint64(a)32' locale.o:locale.c:(.text+0x9ac): undefined reference to `_num_put_char_put_uint64(a)32' locale.o:locale.c:(.text+0x9b4): undefined reference to `_num_put_char_do_put_bool(a)28' locale.o:locale.c:(.text+0x9bc): undefined reference to `_num_put_char_put_bool(a)28' locale.o:locale.c:(.text+0xa0c): undefined reference to `_num_put_wchar_do_put_long(a)28' locale.o:locale.c:(.text+0xa14): undefined reference to `_num_put_short_do_put_long(a)28' locale.o:locale.c:(.text+0xa1c): undefined reference to `_num_put_wchar_put_long(a)28' locale.o:locale.c:(.text+0xa24): undefined reference to `_num_put_wchar_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa2c): undefined reference to `_num_put_short_do_put_ulong(a)28' locale.o:locale.c:(.text+0xa34): undefined reference to `_num_put_wchar_put_ulong(a)28' locale.o:locale.c:(.text+0xa3c): undefined reference to `_num_put_wchar_do_put_double(a)32' locale.o:locale.c:(.text+0xa44): undefined reference to `_num_put_short_do_put_double(a)32' locale.o:locale.c:(.text+0xa4c): undefined reference to `_num_put_wchar_put_double(a)32' locale.o:locale.c:(.text+0xa54): undefined reference to `_num_put_wchar_put_ldouble(a)32' locale.o:locale.c:(.text+0xa5c): undefined reference to `_num_put_wchar_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa64): undefined reference to `_num_put_short_do_put_ptr(a)28' locale.o:locale.c:(.text+0xa6c): undefined reference to `_num_put_wchar_put_ptr(a)28' locale.o:locale.c:(.text+0xa74): undefined reference to `_num_put_wchar_do_put_int64(a)32' locale.o:locale.c:(.text+0xa7c): undefined reference to `_num_put_short_do_put_int64(a)32' locale.o:locale.c:(.text+0xa84): undefined reference to `_num_put_wchar_put_int64(a)32' locale.o:locale.c:(.text+0xa8c): undefined reference to `_num_put_wchar_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa94): undefined reference to `_num_put_short_do_put_uint64(a)32' locale.o:locale.c:(.text+0xa9c): undefined reference to `_num_put_wchar_put_uint64(a)32' locale.o:locale.c:(.text+0xaa4): undefined reference to `_num_put_wchar_do_put_bool(a)28' locale.o:locale.c:(.text+0xaac): undefined reference to `_num_put_short_do_put_bool(a)28' locale.o:locale.c:(.text+0xab4): undefined reference to `_num_put_wchar_put_bool(a)28' locale.o:locale.c:(.text+0xaec): undefined reference to `_time_put_char_do_put(a)36' locale.o:locale.c:(.text+0xaf4): undefined reference to `_time_put_char_put(a)36' locale.o:locale.c:(.text+0xafc): undefined reference to `_time_put_char_put_format(a)36' locale.o:locale.c:(.text+0xb5c): undefined reference to `_time_put_wchar_do_put(a)36' locale.o:locale.c:(.text+0xb64): undefined reference to `_time_put_wchar_put(a)36' locale.o:locale.c:(.text+0xb6c): undefined reference to `_time_put_wchar_put_format(a)36' collect2: ld returned 1 exit status -- Alexandre Julliard julliard(a)winehq.org

1 0

testbot problem
by Stefan Leichter 02 Jan '14

02 Jan '14

Hello, i'm trying to understand why job 27632 did not build on the testbot. It builds fine for Linux 32/64 bit and Windows (make crosstest) on my computer. >From the build log it looks like a problem inside the Makefile (make: Nothing to be done for `all'.). Is there a way to access the Makefile after the job is finished? Regards Stefan

1 0