wine-devel May 2013

wine-devel@winehq.org

77 participants
183 discussions

Re: dbghelp: Add stub SymGetLineNextW64
by Alexandre Julliard 21 May '13

21 May '13

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1717,6 +1717,17 @@ BOOL WINAPI SymGetLineNext64(HANDLE hProcess, PIMAGEHLP_LINE64 Line) > } > > /****************************************************************** > + * SymGetLineNextW64 (DBGHELP.@) > + * > + */ > +BOOL WINAPI SymGetLineNextW64(HANDLE hProcess, PIMAGEHLP_LINEW64 Line) > +{ > + FIXME("(%p %p) stub \n", hProcess, Line); > + > + return FALSE; > +} It wouldn't be much harder to implement this properly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: riched20: Added tests for ITextDocument::Open
by Nikolay Sivov 21 May '13

21 May '13

On Tue, May 21, 2013 at 3:45 PM, Jactry Zeng <jactry92(a)gmail.com> wrote: > > > > > If the whole purpose of storing flags names is to output readable debug info I think it's better to have a single separate function that takes flags combination and returns static buffer pointer with a name. This way it will need just to append after bitwise 'and' check. + /* tests for ITextDocument::Open */ + for(; tomNunSingle >= 0; tomNunSingle--) Do you really need to go from the tail here?

1 0

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.
by Dmitry Timoshkov 21 May '13

21 May '13

Alexandre Julliard <julliard(a)winehq.org> wrote: > case DLL_PROCESS_DETACH: > - msvcrt_free_popen_data(); > msvcrt_free_io(); > + if (lpvReserved) break; > + msvcrt_free_popen_data(); > msvcrt_free_mt_locks(); > msvcrt_free_console(); > msvcrt_free_args(); Shouldn't msvcrt_free_io() be also protected by this guard? -- Dmitry.

3 6

Re: [PATCH] d3dxof: Cleanup separators handling and allow multi-semicolons + single comma separator.
by Alexandre Julliard 21 May '13

21 May '13

Christian Costa <titan.costa(a)gmail.com> writes: > There is one test becoming todo. This will be fixed in another patch. > This patch also should fix bug 30897. > --- > dlls/d3dxof/parsing.c | 35 ++++++++++------------------------- > dlls/d3dxof/tests/d3dxof.c | 22 +++++++++++----------- > 2 files changed, 21 insertions(+), 36 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -M d3drm.dll -T ../../.. -p d3drm_test.exe.so d3drm.c && touch d3drm.ok d3drm.c:275: Test failed: Cannot load mesh data (hr = 88760311) d3drm.c:280: Test failed: Retrieved name '' instead of 'Object' d3drm.c:283: Test failed: IDirect3DRMMeshBuilder_GetName returned hr = 0 d3drm.c:298: Test failed: Wrong number of vertices 0 (must be 4) d3drm.c:301: Test failed: Wrong number of faces 0 (must be 3) d3drm.c:305: Test failed: Wrong number of vertices 0 (must be 4) d3drm.c:306: Test failed: Wrong number of normals 0 (must be 4) d3drm.c:307: Test failed: Wrong number of face data bytes 0 (must be 22) d3drm.c:315: Test failed: Wrong component n[1].x = 0.000000 (expected -0.229416) d3drm.c:318: Test failed: Wrong component n[2].x = 0.000000 (expected -0.229416) d3drm.c:319: Test failed: Wrong component n[2].y = 4021199976020422122536960.000000 (expected 0.688247) d3drm.c:320: Test failed: Wrong component n[2].z = 9973638011820690691325952.000000 (expected 0.688247) d3drm.c:321: Test failed: Wrong component n[3].x = 0.000000 (expected -0.577350) d3drm.c:323: Test failed: Wrong component n[3].z = 1387759860774554023173815085733773312.000000 (expected 0.577350) d3drm.c:329: Test failed: Cannot get texture coordinates (hr = 88760316) d3drm.c:330: Test failed: Wrong coordinate 1.230000 (must be 0.0) etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2]vbscript: Implemented builtin function CBool
by Marvin 21 May '13

21 May '13

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 http://testbot.winehq.org/JobDetails.pl?Key=25647 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2]vbscript: Implemented builtin function CInt
by Marvin 21 May '13

21 May '13

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 http://testbot.winehq.org/JobDetails.pl?Key=25646 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2]vbscript: Implemented builtin function CInt
by Jacek Caban 21 May '13

21 May '13

Hi Zhan, On 05/17/13 16:53, Zhan Jianyu wrote: > This patch is built based on Jaceks's newly-submitted patch: > > commit 48a862306288d69d3623d5ecdc0f5a5a40addafe > ( vbscript: Round half to even in to_int) > > Thanks, Jacek. :-) > > With his patch, CInt could be implementd in a clean way, without > any introduced helper function. > > This patch also add tests for any corner cases, and it has passed testbot's > testing. > > --- > dlls/vbscript/global.c | 14 ++++++++++++-- > dlls/vbscript/tests/api.vbs | 23 +++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 2 deletions(-) As you may check here: http://source.winehq.org/patches/ your patch is marked as 'Apply failure'. Did you prepare the patch against recent Wine Git? Please rebase and resend the patch. Cheers, Jacek

1 0

Re: Troubles configuring and building wine-1.5.30 on Debian wheezy
by Hugh McMaster 21 May '13

21 May '13

On Monday May 20 at 22:24:58, Alan W. Irwin wrote: >wine at raven> wine64 >wine64: error while loading shared libraries: libwine.so.1: cannot >open shared object file: No such file or directory Hi Alan, This error is caused by a regression in Wine 1.5.30. It is not present in version 1.5.29. The general source for Wine 1.5.30 on WineHQ does contain a patch to resolve the issue. The patch is available from http://source.winehq.org/git/wine.git/patch/ce4b6451aabbe83809c7483c748cfa0…. To apply it, you will need to save the patch with either the extension .patch or .txt in the Wine source directory. You will then need to run the patch command from the source directory: patch -p1 < name.patch Alternatively, you can use Git to obtain the latest source: git clone git://source.winehq.org/git/wine.git ~/wine-git This option will come with the patch already applied and a lot of other changes. --- Hugh

1 0

Re: [1/4] server: Add support for console font size, maximum window size, etc.
by Dmitry Timoshkov 21 May '13

21 May '13

Hugh McMaster <hugh.mcmaster(a)masterindexing.com> wrote: > This patch modifies server/protocol.def and server/console.c to add support > for console font size detection and console window size rendering. It also > tidies up a few inconsistencies in the repeated usage of aspects of the > screen buffer struct. Your patches are full of formatting and white space changes, please don't do that. -- Dmitry.

2 1

Re: windowscodecs: Add support for IMILBitmapSource interface.
by Charles Davis 20 May '13

20 May '13

On May 19, 2013, at 9:14 PM, Dmitry Timoshkov wrote: > diff --git a/dlls/windowscodecs/bitmap.c b/dlls/windowscodecs/bitmap.c > index f8904df..646f3a7 100644 > --- a/dlls/windowscodecs/bitmap.c > +++ b/dlls/windowscodecs/bitmap.c > @@ -446,6 +471,226 @@ static const IWICBitmapVtbl BitmapImpl_Vtbl = { > BitmapImpl_SetResolution > }; > > +static HRESULT WINAPI IMILBitmapImpl_QueryInterface(IMILBitmapSource *iface, REFIID iid, > + void **ppv) > +{ > + BitmapImpl *This = impl_from_IMILBitmapSource(iface); > + TRACE("(%p,%s,%p)\n", iface, debugstr_guid(iid), ppv); > + > + if (!ppv) return E_INVALIDARG; > + > + if (IsEqualIID(&IID_IUnknown, iid) || > + IsEqualIID(&IID_IMILBitmapSource, iid)) > + { > + *ppv = &This->IMILBitmapSource_iface; > + IUnknown_AddRef((IUnknown*)*ppv); > + return S_OK; > + } You're violating COM rules here: when you QI an object for an interface pointer, the QI must always return the same result no matter what. Here, however, you're returning this interface pointer in response to a query for IUnknown, when the already-existing QueryInterface method on the IWICBitmap interface returns *itself* for IUnknown! Now when you QI for IUnknown on both of these interfaces, they won't compare equal. (I suspect you're not convinced. After all, native might violate COM rules here, too. I doubt that (see below), but it might. So, write a test that QI's for IUnknown from both interfaces, and checks if they're equal or not. Then we'll see who's right.) > diff --git a/dlls/windowscodecs/wincodecs_private.h b/dlls/windowscodecs/wincodecs_private.h > index dddb327..29f7726 100644 > --- a/dlls/windowscodecs/wincodecs_private.h > +++ b/dlls/windowscodecs/wincodecs_private.h > @@ -27,6 +27,46 @@ DEFINE_GUID(GUID_WineContainerFormatTga, 0x0c44fda1,0xa5c5,0x4298,0x96,0x85,0x47 > > DEFINE_GUID(GUID_VendorWine, 0xddf46da1,0x7dc1,0x404e,0x98,0xf2,0xef,0xa4,0x8d,0xfc,0x95,0x0a); > > +DEFINE_GUID(IID_IMILBitmapSource,0x7543696a,0xbc8d,0x46b0,0x5f,0x81,0x8d,0x95,0x72,0x89,0x72,0xbe); > +#define INTERFACE IMILBitmapSource > +DECLARE_INTERFACE_(IMILBitmapSource,IUnknown) > +{ > + /*** IUnknown methods ***/ > + STDMETHOD_(HRESULT,QueryInterface)(THIS_ REFIID,void **) PURE; You know you can just use the STDMETHOD() macro (no trailing underscore), e.g.: STDMETHOD(QueryInterface)(THIS_ REFIID,void **) PURE; for methods that return an HRESULT, right? Or do you prefer explicitly declaring the return type like that, even if it is more typing? > + STDMETHOD_(ULONG,AddRef)(THIS) PURE; > + STDMETHOD_(ULONG,Release)(THIS) PURE; > + /*** IMILBitmapSource methods ***/ > + STDMETHOD_(HRESULT,GetSize)(THIS_ UINT *,UINT *); > + STDMETHOD_(HRESULT,GetPixelFormat)(THIS_ int *); > + STDMETHOD_(HRESULT,GetResolution)(THIS_ double *,double *); > + STDMETHOD_(HRESULT,CopyPalette)(THIS_ IWICPalette *); > + STDMETHOD_(HRESULT,CopyPixels)(THIS_ const WICRect *,UINT,UINT,BYTE *); > + STDMETHOD_(HRESULT,UnknownMethod1)(THIS_ void **); > +}; > +#undef INTERFACE > + > +#define INTERFACE IMILUnknown1 > +DECLARE_INTERFACE_(IMILUnknown1,IUnknown) > +{ > + /*** IUnknown methods ***/ > + STDMETHOD_(HRESULT,QueryInterface)(THIS_ REFIID,void **) PURE; > + STDMETHOD_(ULONG,AddRef)(THIS) PURE; > + STDMETHOD_(ULONG,Release)(THIS) PURE; > +}; > +#undef INTERFACE Wouldn't that just make this interface a plain old IUnknown? Or does it have its own IID? (Or does that not even matter, given that it's returned from that "UnknownMethod1" above?) If it is nothing more than a plain IUnknown, why did you even add this, since it doesn't really extend the IUnknown interface with any new methods? It's telling that its v-table is the very first v-table in the object. This probably indicates that this really is the canonical IUnknown (i.e. the one that gets returned when you QI for IUnknown), and the other interfaces' IUnknown methods just delegate to this one. If I haven't missed my guess about this object's QI implementation, then this is the IUnknown that should get returned from a QI for IUnknown. This might actually be an object that supports aggregation; you may want to test for that, too ;). Chip

2 1

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

Jump to page:

2025

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 May 2013