June 2010 - Wine-devel - list.winehq.org

structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers
by Ilya Basin 25 Jun '10

25 Jun '10

The struct in question is CSFV defined in shlobh.h. If I try to compile shell32_test for x64 using headers from windows 2008 SDK, I get assertion failure here: http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-r… Is it normal for wine to have different structure packing?

2 1

Tests for msvcrt
by Paul Chitescu 25 Jun '10

25 Jun '10

Hi! What would be the best way of testing MSVCRT.DLL considering that many functions may or may be not present in the native version? > > /********************************************************************* > > + * getenv_s - not exported in native msvcrt > > + */ > > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char *name > Both getenv_s and _wgetenv_s are exported in native msvcrt. In older versions of MSVCRT.DLL (XP and earlier, no idea about Vista) these functions are not exported. They were added first in Visual Studio 2005 (MSVCRT80.DLL) and somehow made they way back in MSVCRT. Using LoadLibrary / GetProcAddress would fail on all older Windows platforms. It would be possible to test MSVCR80 instead but that may not be installed on the tested system. Any thoughts? Paul Chitescu

3 3

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's Misha

2 2

Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > +#if !defined(__cplusplus) || defined(CINTERFACE) > > +/*** IUnknown methods ***/ > > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > > +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p) > > +#define ID3DXMesh_Release(p) (p)->lpVtbl->Release(p) > > +#else > > +/*** IUnknown methods ***/ > > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->QueryInterface(a,b) > > +#define ID3DXMesh_AddRef(p) (p)->AddRef() > > +#define ID3DXMesh_Release(p) (p)->Release() > > +#endif > > + > Which version of the DX SDK do these match? > > > ______________________________________________________________________ Ok, now here I just have to plead ignorance my apologies... If I do not declare these functions, how do I call the Release method of the appropriate interfaces? Specifically, I started looking at the test for line.c - I believe that if I create a mesh, I have to release it. I have largely been learning from this page: http://www.mvps.org/directx/articles/d3dxmesh.htm (which is DirectX 8) but it seems I have to somehow release the functions no? Also, I'm probably going to start with the D3DXCreateBox function, as I need to figure out exactly what's going on with the vertices before I delve into something as complicated as spheres ;) Thanks y'all :) Misha

2 1

(no subject)
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". > So I don't think I'm going to be getting much productive done with 1.2 bugs done in a single day, and the one I started working on yesterday is now fixed. So might as well start thinking about D3DX9. So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in "D3dx9shape.h" whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in "D3dx9mesh.h" This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Thank you Misha

2 1

Re: sorry guys... slow on uptake today :)
by James Mckenzie 25 Jun '10

25 Jun '10

Misha Koshelev <misha680(a)gmail.com> wrote: > >So I've been working on bug 13891, but got sidetracked by what I thought >was a race condition as dlls/shell32/tests/shlexec.c was hanging. > >Spent several hours tracing it to line 464 in dlls/ntdll/directory.c > > if (stat( entry->mnt_dir, &st ) == -1) continue; > >(read from /etc/mtab) > >Turned out it was my curlftpfs file system, which tends to disconnect >randomly and not unmount (doh!). > >Anyway I hope to have perhaps some tests for this bug before I leave to >Russia (on Sat morning), but unfortunately I might not be able to get >this bug fixed until post-code freeze. Sorry :( > If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Have a safe travel. James Mckenzie

2 1

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
by Alexandre Julliard 25 Jun '10

25 Jun '10

Mikko Rasa <tdb(a)tdb.fi> writes: > + /* check that the buffer is large enough to hold the indices, > + * reallocate if necessary. > + */ > + hr = IWineD3DBuffer_GetDesc(This->indexbuffer, &desc); > + if(desc.Size < IndexCount * sizeof(WORD)) > + { > + UINT size = desc.Size; > + IWineD3DBuffer *buffer; > + IUnknown *parent; > + > + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + /* We keep adding zero bits to the right, so an overflow > + * will eventually result in all zeroes. Detect this to > + * avoid infinite loop. > + */ > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + LeaveCriticalSection(&ddraw_cs); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } A simple "size = max(desc.Size*2,IndexCount*sizeof(WORD))" would do just as well. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Silence a noisy fixme.
by Henri Verbeet 25 Jun '10

25 Jun '10

I don't think so. That FIXME should have been an ERR, and if you're seeing it that's a bug.

1 0

sorry guys... slow on uptake today :)
by Misha Koshelev 25 Jun '10

25 Jun '10

So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry->mnt_dir, &st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( Misha

1 0

Re: comctl32/tests: remove noisy trace
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

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=2910 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0