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

Re: [PATCH] shlwapi/tests: ChrCmpI* not present on Win95B (winetestbot)
by Nikolay Sivov 30 Jan '10

30 Jan '10

On 1/30/2010 18:25, Detlef Riekenberg wrote: > > @@ -608,9 +610,13 @@ static void test_StrCmpA(void) > static const char str2[] = {'a','B','c','d','e','f'}; > ok(0 != StrCmpNA(str1, str2, 6), "StrCmpNA is case-insensitive\n"); > ok(0 == StrCmpNIA(str1, str2, 6), "StrCmpNIA is case-sensitive\n"); > - ok(!ChrCmpIA('a', 'a'), "ChrCmpIA doesn't work at all!\n"); > - ok(!ChrCmpIA('b', 'B'), "ChrCmpIA is not case-insensitive\n"); > - ok(ChrCmpIA('a', 'z'), "ChrCmpIA believes that a == z!\n"); > + if (pChrCmpIA) { > + ok(!pChrCmpIA('a', 'a'), "ChrCmpIA doesn't work at all!\n"); > + ok(!pChrCmpIA('b', 'B'), "ChrCmpIA is not case-insensitive\n"); > + ok(pChrCmpIA('a', 'z'), "ChrCmpIA believes that a == z!\n"); > + } > + else > + win_skip("ChrCmpIW() is not available\n"); > > Should be ChrCmpIA() in message.

1 0

new valgrind results...
by Dan Kegel 30 Jan '10

30 Jan '10

This is with an almost-unpatched trunk (the only patch is my tweak to handle bogus environment variables), so it's now using Alexandre's heap patches rather than mine. There are some interesting new warnings, not sure quite what to make of them yet. Logs at http://kegel.com/wine/valgrind/logs/2010-01-29-20.52/ Stats at http://kegel.com/wine/valgrind/logs/2010-01-29-20.52.errs.txt 2 Source and destination overlap in memcpy 2 Syscall param writev 3 Use of uninitialised value of size 4 7 Invalid read of size 2 10 Invalid write of size 4 20 Invalid write of size 1 29 Invalid free/ delete / delete[] 30 Invalid read of size 4 46 Conditional jump or move depends on uninitialised value 86 Invalid read of size 1 279 XXX bytes in XXX blocks are definitely lost total: 514

1 0

Re: Student Interested in Google Summer of Code 2010
by Tony Wasserka 29 Jan '10

29 Jan '10

Hi, We've had two D3DX projects last year - one implementing shaders, the other (which was mine) implementing meshes, fonts and texturing code. Both have only partially been integrated, yet (as far as I know), but most of the other stuff in d3dx9 is still untouched, you can take a look at the msdn documentation to see the whole list of interfaces. I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures. I'm not sure how much has been implemented in D3D10's effect area (they merged the effect interfaces from d3dx into d3d10), but you should maybe clarify with some d3d devs how much code can be shared here before. Just my suggestion, there might be other interesting areas of d3dx and Wine in general as well of course. Best Regards, Tony

13 30

Re: [PATCH] Implement OleCreatePropertyFrame (try 3)
by Geoffrey Hausheer 29 Jan '10

29 Jan '10

Is there anything I can do to move this patch forward? I've fixed all the issues that have been raised so far. I have no dea what it is waiting on, and if there is anything I can do to get it committed or if it is just a question of being patient. As I said previously I'd happily write a test for it, but I couldn't find any examples of how to test a modal dialog box in Wine, so I just don't know what the right way to do that is.

2 1

relay log problem
by Stefan Leichter 29 Jan '10

29 Jan '10

Hello, does anyone notice a problem that the lines of the logging are written over each other as in the attached log? My system has an AMD Phenom(tm) II X2 550 Processor on a NVIDIA GeForce 8300 Chipset running running Debian Lenny 32 bit Is this a know problem? Is a work around available? -- Stefan

7 13

Re: [2/5] d3d9: Test invalid buffer lock parameters
by Henri Verbeet 29 Jan '10

29 Jan '10

On 29 January 2010 11:35, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static HMODULE d3d9_handle = 0; This is redundant. > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 0, (void *) &bufstart, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 1024, (void *) &data, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + ok(bufstart == data, "Two locks returned different addresses: %p, %p\n", bufstart, data); > Why would we care if the buffer is always mapped at the same address? Also note that the test doesn't necessarily prove this is the case. > + /* This happily wraps around the address space */ > + hr = IDirect3DVertexBuffer9_Lock(buffer, ~0U, 1024, (void *) &data, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock(start ~0U) failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + ok(bufstart -1 == data, "~0U start lock returned unexpected address: expected %p, got %p\n", bufstart - 1, data); > I'd expect this to break on 64 bit. Also, like the previous test, why do we care? Do you seriously have an application that does this?

2 1

Re: [PATCH 3/5] wined3d: Prune invalid states from the state table.
by Stefan Dösinger 29 Jan '10

29 Jan '10

On Thursday 28 January 2010 23:40:25 Henri Verbeet wrote: > +static void prune_invalid_states(struct StateEntry *state_table, const > struct wined3d_gl_info *gl_info) +{ > + unsigned int start, last, i; > + > + start = STATE_TEXTURESTAGE(gl_info->limits.texture_stages, 0); > + last = STATE_TEXTURESTAGE(MAX_TEXTURES - 1, > WINED3D_HIGHEST_TEXTURE_STATE); + for (i = start; i <= last; ++i) > + { > + state_table[i].representative = 0; > + state_table[i].apply = state_undefined; > + } Please use the number of texture blend stages reported from the fragment pipeline rather than gl_limits.texture_stages. texture_stages only works with the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok by chance on most GL cards). There's a deeper issue with how we manage texture limits, because currently the extension loading code picks limits.texture_stages, already anticipating which pipeline we'll choose later. We should handle this in the way shader constants are handled: Rename limits.texture_stages to limits.max_nv_general_combiners, make only the nvrc and nvts pipelines read this extension specific value, and use the pipeline reported d3d texture blend stages in fragment pipeline independent code. We're also (still) mixing up blend stages with fixed function vertex coordinates. Regarding masking out unsupported / invalid states, Ivan once suggested the idea to make the pipeline template's needed extension field more powerful, e.g. via a callback function. That way the pipeline would have more control over which state handlers it registers. I am fine with a pipeline independent function, I guess it will work just fine for our needs, just digging out the old idea.

2 4

Re: [2/5] d3d9: Test invalid buffer lock parameters
by Henri Verbeet 29 Jan '10

29 Jan '10

On 28 January 2010 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Copyright (C) 2010 Stefan Dösinger(For CodeWeavers) Please use UTF-8 like the other source files. (I'd also suggest a space and a lowercase 'F').

2 1

Loader, mapping and sharing issues with main exe
by Jason Edmeades 29 Jan '10

29 Jan '10

Hello, I've been debugging a problem with an application which checks itself for consistency before it runs. It does this extremely simply and fails in a trivial way under wine, but for the life of me I do not know how to fix it, and I would appreciate any thoughts - its not everyday I delve into the loader and server logic! I have cut this down to a 2 line test program, which basically fails because a native executable called eg. test.exe subsequently calls CreateFile(".\\test.exe", GENERIC_READ, 0 /* no share*/ - ie it's opening itself for read access and non-shared access. It suffers a sharing violation on wine whereas it works fine on windows Diagnosing the wine side, we are in trouble here - the act of loading a module ends up in load_dll which call find_dll_file which in turn calls NtOpenFile for GENERIC_READ access. This returns a file handle which is then used to create the in memory file mapping for the executable code, and the handle returned from the NtOpenFile is then closed. However, when we come along to the application code and try the open we end up checking the sharing and there are 3 things on the inode->open chain: The original open, with access of read The mapping, with access of mapping The open in progress (which is ignored for sharing checks) which does not want to SHARE_READ,and hence the sharing violation occurs. For reference we are failing in the 3rd (last) case of check_sharing returning STATUS_SHARING_VIOLATION, ie existing access if for read purposes, but the requested sharing doesnt allow this. What I dont understand is why the NtClose for the handle does not remove it from the 'open' list - I think from my reading of the fd_destroy code it will put it onto the closed list if there are other references to the same inode, although thats where my debugging will head next. This whole area has me confused now! Can anyone shed some light on how its all supposed to work please? Thanks, Jason

2 2

Quick multiple-patch submission question
by Erich Hoover 28 Jan '10

28 Jan '10

When submitting multiple patches that apply to the same component but each patch is unrelated (ie. each one fixes a different issue), is it still appropriate to label the patches with the [PATCH X/Y] notation? In the case I have at hand the patches are even for different files of the same component, so the apply order completely doesn't matter. Erich Hoover ehoover(a)mines.edu

4 3