wine-devel July 2008

wine-devel@winehq.org

135 participants
411 discussions

Re: [resent] [WideChar conversion improvements - 5/5] Add a lot of WideCharToMultiByte tests
by Jeff Latimer 31 Jul '08

31 Jul '08

Colin Finck wrote: > Add a lot of new tests for the actual WideCharToMultiByte string > conversion as well. Are you planning to move on to MultiByteToWideChar tests? I was planning on adding a few and don't want to get into your way. Jeff

2 1

New valgrind warnings in kernel32/tests/codepage.c
by Dan Kegel 31 Jul '08

31 Jul '08

Hi Colin, your change http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b8… seems to have triggered some valgrind warnings, http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-d… e.g. + Use of uninitialised value of size 4 + at wcstombs_sbcs (wctomb.c:186) + by wine_cp_wcstombs (wctomb.c:457) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:351) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) + Use of uninitialised value of size 4 + at wcstombs_sbcs_slow (wctomb.c:246) + by wine_cp_wcstombs (wctomb.c:453) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:352) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) Could you have a look?

2 1

Re: [3/7] WineD3D: Beware of the frontbuffer coordinate system difference
by H. Verbeet 31 Jul '08

31 Jul '08

You'll need to modify stretch_rect_fbo() as well.

1 0

xinput implementation
by chourmovs 31 Jul '08

31 Jul '08

hi everyone I'd like to participate to wine improvement instead of always requesting for new features Maybe i'm wrong but i thaught xinput support lack for new games and its implementation is maybe not the hardest thing to do The fact is that i have lack of knowledge in msdn and c coding, maybe i could read interesting documentation on how included wine dll's work By my side, i'm going to read all i can find on website documentation to get familiarized with wine code Maybe someones could guide me through this "Way of the Cross" Vincent -- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/

2 1

Re: shdocvw(2/2): rudimentary implementation of CLSID_InternetShortcut (try 3)
by Alexandre Julliard 31 Jul '08

31 Jul '08

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > +static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out) > +{ The usual pattern is to return the new pointer, not an HRESULT. The only possible error is E_OUTOFMEMORY anyway. > +static HRESULT WINAPI UniformResourceLocatorA_SetUrl(IUniformResourceLocatorA *url, LPCSTR pcszURL, DWORD dwInFlags) > +{ > + HRESULT hr; > + LPWSTR wideURL; > + InternetShortcut *This = impl_from_IUniformResourceLocatorA(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_a(pcszURL), dwInFlags); > + hr = strdupAtoW(pcszURL, &wideURL); > + if (SUCCEEDED(hr)) > + { > + hr = This->uniformResourceLocatorW.lpVtbl->SetURL(&This->uniformResourceLocatorW, wideURL, dwInFlags); In general you shouldn't access lpVtbl. You should either use the COM macros, or if you know the target function like in this case, call it directly. Here it would be even better to not call anything and simply store the pointer to avoid duplicating the string twice. > +static HRESULT WINAPI UniformResourceLocatorW_SetUrl(IUniformResourceLocatorW *url, LPCWSTR pcszURL, DWORD dwInFlags) > +{ > + InternetShortcut *This = impl_from_IUniformResourceLocatorW(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_w(pcszURL), dwInFlags); > + if (dwInFlags != 0) > + FIXME("ignoring unsupported flags 0x%x\n", dwInFlags); > + This->isDirty = TRUE; > + HeapFree(GetProcessHeap(), 0, This->url); > + if (pcszURL == NULL) > + This->url = NULL; > + else > + { > + This->url = heap_strdupW(pcszURL); > + if (This->url == NULL) > + return E_OUTOFMEMORY; You should preserve the old value on error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ole32: don't crash when running the marshal tests on Vista.
by Rob Shearman 31 Jul '08

31 Jul '08

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > When running the ole32:marshal tests on Vista, the call to > CoUnmarshalInterface fails. This results in pProxy being NULL which > then causes the crash on the QueryInterface call. > > This patch makes sure that the pProxy-dependant tests are only called > when pProxy is valid. We need to work out why the test is failing - possibly it requires more implementation of the object we are marshalling than in previous versions of Windows. Also, the typical way of detecting failure in our COM code in Wine is to check the return value rather than whether a output object is NULL or not. -- Rob Shearman

2 1

Re: d3d9: fix device crashing on Vista.
by H. Verbeet 31 Jul '08

31 Jul '08

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > SetMaterial crashes when passed a NULL argument. > If you're going to do that, you might as well remove the entire test. I think this test has caused trouble before.

2 1

RE: ddraw/tests: Skip cubemap tests when cubemap isn't supported.
by Stefan Dösinger 31 Jul '08

31 Jul '08

> skip("No cubemap support\n"); if you return right after that you wouldn't have to change the indention on all the rest of the code Also I think in the case of the surface test, there should be an easier way to tell if cubemaps are supported, without starting a d3d device. In the worst case just abort on a CreateSurface error > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Alexander Dorofeyev > Sent: Tuesday, July 29, 2008 5:25 PM > To: wine-patches(a)winehq.org > Subject: ddraw/tests: Skip cubemap tests when cubemap isn't supported. > > > Fixes some test failures on systems without cubemap support. > --- > dlls/ddraw/tests/d3d.c | 428 ++++++++++++++++++++++------------ > --------- > dlls/ddraw/tests/dsurface.c | 57 ++++++- > 2 files changed, 275 insertions(+), 210 deletions(-)

5 11

Re: [1/3] WineD3D: Use C bitfields to compact the ffp description (try 2)
by Alexandre Julliard 30 Jul '08

30 Jul '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -1785,16 +1785,17 @@ void gen_ffp_op(IWineD3DStateBlockImpl *stateblock, struct ffp_settings *setting > }; > unsigned int i; > DWORD ttff; > + DWORD cop, aop, carg0, carg1, carg2, aarg0, aarg1, aarg2; > > for(i = 0; i < GL_LIMITS(texture_stages); i++) { > IWineD3DBaseTextureImpl *texture; > if(stateblock->textureState[i][WINED3DTSS_COLOROP] == WINED3DTOP_DISABLE) { > settings->op[i].cop = WINED3DTOP_DISABLE; > settings->op[i].aop = WINED3DTOP_DISABLE; > - settings->op[i].carg0 = settings->op[i].carg1 = settings->op[i].carg2 = 0xffffffff; > - settings->op[i].aarg0 = settings->op[i].aarg1 = settings->op[i].aarg2 = 0xffffffff; > + settings->op[i].carg0 = settings->op[i].carg1 = settings->op[i].carg2 = -1; > + settings->op[i].aarg0 = settings->op[i].aarg1 = settings->op[i].aarg2 = -1; It's not very clean to store -1 into unsigned variables, the previous code was better IMO. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [2]wined3d: rework surface Blt a bit to only lock the part of the destination surface being drawn to
by H. Verbeet 30 Jul '08

30 Jul '08

2008/7/30 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/wined3d/surface_base.c | 122 > +++++++++++++++++++++++-------------------- > 1 files changed, 65 insertions(+), 57 deletions(-) > Looks reasonable to me, although you might want to wait for Stefan to look it over as well.

2 1

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 July 2008