March 2012 - Wine-devel - list.winehq.org

Spelling errors in en_US translation
by Julian Rüger 26 Mar '12

26 Mar '12

Hi Francois, (and everybody else ;) are there any plans to create an ignore-list for these: http://fgouget.free.fr/wine-po/en_US.spell.html to be able to distinguish real typos from false positives? Most reported errors are false positives (like "codec" or "checksum") but there are real errors, or at least instances of uncommon spelling (like "customising", which is British English afaik, or "Cancelled") which should be fixed (after 1.4), imho. Best regards, Julian

2 3

Re: [PATCH 1/2] shell32: Prepare ASSOC_GetValue and ASSOC_ReturnData to work on non WCHAR* data
by Alexandre Julliard 26 Mar '12

26 Mar '12

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/shell32/assoc.c | 49 > +++++++++++++++++++++++++------------------------ > 1 files changed, 25 insertions(+), 24 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M shlwapi.dll -T ../../.. -p shlwapi_test.exe.so assoc.c && touch assoc.ok assoc.c:131: Test failed: Expected 72, got 36 assoc.c:160: Test failed: Expected 24, got 12 make: *** [assoc.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d10core: Standardize COM aggregation for d3d10_device.
by Henri Verbeet 26 Mar '12

26 Mar '12

On 22 March 2012 00:50, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > -static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown *iface, REFIID riid, void **object) > +static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown *iface, REFIID riid, > + void **ppv) > { > - struct d3d10_device *This = d3d10_device_from_inner_unknown(iface); > + struct d3d10_device *This = impl_from_IUnknown(iface); > > - TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); > + TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), ppv); > > - if (IsEqualGUID(riid, &IID_IUnknown) > - || IsEqualGUID(riid, &IID_ID3D10Device)) > + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_ID3D10Device)) > + *ppv = This; > + else if (IsEqualGUID(riid, &IID_IWineDXGIDeviceParent)) > + *ppv = &This->IWineDXGIDeviceParent_iface; > + else > { > - ID3D10Device_AddRef(&This->ID3D10Device_iface); > - *object = This; > - return S_OK; > + WARN("%s not implemented, returning E_NOINTERFACE\n", debugstr_guid(riid)); > + *ppv = NULL; > + return E_NOINTERFACE; > } > > - if (IsEqualGUID(riid, &IID_IWineDXGIDeviceParent)) > - { > - IWineDXGIDeviceParent_AddRef(&This->IWineDXGIDeviceParent_iface); > - *object = &This->IWineDXGIDeviceParent_iface; > - return S_OK; > - } > - > - WARN("%s not implemented, returning E_NOINTERFACE\n", debugstr_guid(riid)); > - > - *object = NULL; > - return E_NOINTERFACE; > + IUnknown_AddRef((IUnknown*)*ppv); > + return S_OK; > } I'm not sure this really makes it much better, but I guess it's mostly up to how Alexandre wants these.

2 1

Re: msi: Implement MSIMODIFY_MERGE function in TABLE_modify.
by Marvin 26 Mar '12

26 Mar '12

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=17479 Your paranoid android. === WNT4WSSP6 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2KPROSP4 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === WXPPROSP3 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2K3R2SESP2 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === WVISTAADM (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2K8SE (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PRO (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PROX64 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === TEST64_W7SP1 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PROX64 (64 bit db) === db.c:1079: Test failed: MsiViewModify failed === TEST64_W7SP1 (64 bit db) === db.c:1079: Test failed: MsiViewModify failed

2 1

Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
by Hans Leidekker 26 Mar '12

26 Mar '12

On Mon, 2012-03-26 at 11:14 +0200, Andoni Morales wrote: > - case MSIMODIFY_REPLACE: > case MSIMODIFY_MERGE: > + /* check for a duplicated key */ > + r = msi_table_find_row( tv, rec, &row, column ); > + if (r == ERROR_SUCCESS) { > + /* check that both are identical */ > + r = compare_record (tv, row, rec); > + if (r != ERROR_SUCCESS) > + break; > + } else { > + r = table_validate_new( tv, rec, NULL ); > + if (r != ERROR_SUCCESS) > + break; > + r = TABLE_insert_row( view, rec, -1, FALSE ); > + break; > + } > + > + case MSIMODIFY_REPLACE: Please use bracketing and indentation style of the surrounding code. Some tests would be nice.

2 2

Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
by Dmitry Timoshkov 26 Mar '12

26 Mar '12

Andoni Morales <ylatuya(a)gmail.com> wrote: > - case MSIMODIFY_REPLACE: > case MSIMODIFY_MERGE: > + /* check for a duplicated key */ > + r = msi_table_find_row( tv, rec, &row, column ); > + if (r == ERROR_SUCCESS) { > + /* check that both are identical */ > + r = compare_record (tv, row, rec); > + if (r != ERROR_SUCCESS) > + break; > + } else { > + r = table_validate_new( tv, rec, NULL ); > + if (r != ERROR_SUCCESS) > + break; > + r = TABLE_insert_row( view, rec, -1, FALSE ); > + break; > + } > + > + case MSIMODIFY_REPLACE: > case MSIMODIFY_VALIDATE: Please get rid of redundant 'break' statements, and add one at the end of case processing. -- Dmitry.

1 0

PDB format documentation.
by Svyatoslav Kuzmich 26 Mar '12

26 Mar '12

Hello dear Wine mailing list! I've found that Wine dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? Thanks, Svyatoslav Kuzmich

2 1

Re: My Idea for GSOC
by Daniel Oom 25 Mar '12

25 Mar '12

I think I accidentally dropped wine-devel, I have re-added and hope it does not create any trouble. And thanks for the explanation, but I'm not sure I fully understand how the different versions of direct3d interact within wine's implementation. I will probably figure it out in time. Also I will try to come up with a better test that compares lighting-settings as this was fun and fine introduction to wine. On Wed, Mar 21, 2012 at 15:18, Stefan Dösinger <stefandoesinger(a)gmx.at>wrote: > Hi, > > Did you run the test on Windows? The purpose of the tests is not do > document > what we think should happen, but figure out how Windows behaves, and then > replicate the same behavior. > > Is suspect your test fails on Windows because you're verifying that > lighting > is on or off in the wrong way. IDirect3DDevice2_GetRenderState(device, > D3DRENDERSTATE_LIGHTING, &value) will most likely not work in this way > because > D3DRENDERSTATE_LIGHTING does not exist in IDirect3DDevice2. You have to > set up > the d3d states in a way that rendering produces a different result with > lighting on vs lighting off, then read back the rendering result(there's > already a get_pixel_color function for that) and verify that you get the > correct color. > > A basic recipie for that: With lighting off, you get the diffuse color in > the > vertex as final color(well, assuming that stuff like texturing, fog, etc. > are > off too). With lighting on it runs through the d3d lighting > calculations[1]. > If you disable all lights(d3d default), set the global ambient light to > black(in later d3d there's a renderstate for that, in d3d2 I suspect that's > part of D3DLIGHT and IDirect3DLight*), and set the emissive material > property > to a color != black, your emissive color will be the final color(since the > ambient, diffuse and specular components of the equation are zero). By > setting > the vertex color and emissive material color to different colors you can > tell > if lighting is on or off. > > Cheers, > Stefan > > PS: It's prefered to keep such discussions in public, ie with wine-devel > CCed. > I haven't CCed wine-devel yet, and I'm not sure if you dropped it or if I > dropped it accidentally. > > 1: http://msdn.microsoft.com/en- > us/library/windows/desktop/bb147178(v=vs.85).aspx > > Am Mittwoch, 21. März 2012, 09:25:40 schrieb Daniel Oom: > > I have poked around a bit with the source and managed to add tests that > > checks if lighting is disabled/enabled in device2 and device7. I also > added > > SetRenderState in IDirect3DDeviceImpl_2_DrawPrimitive. The tests works > but > > I have not checked what effect the change has in other circumstances. > > > > I attached a patch in hopefully the preferred format. > > > > On Sat, Mar 10, 2012 at 22:04, Stefan Dösinger > <stefandoesinger(a)gmx.at>wrote: > > > Am Samstag, 10. März 2012, 17:22:51 schrieb Daniel Oom: > > > > Hi, > > > > > > > > Writing tests, or implementing the command line tools seems like > > > > something I could do. I'm kinda leaning towards the command line > > > > tools, since it would offer a chance to thoroughly learn the shading > > > > languages. > > > > > > For learning purposes writing tests and fixing bugs uncovered by them > > > will be > > > better. The command line tools are mostly about parsing parameters and > > > forwarding them to d3dx9 functions(*). > > > > > > If you want to look a little bit in either proposal(we recommend that > in > > > general): > > > > > > For the test stuff, take a look at IDirect3DDeviceImpl_2_DrawPrimitive > > > in > > > dlls/ddraw/device.c. It thunks IDirect3DDevice2::DrawPrimitive to > > > IDirect3DDevice7::DrawPrimitive. The main difference is the VertexType > > > parameter. It is a D3DVERTEXTYPE in the IDirect3DDevice2 method, and a > > > DWORD > > > with D3DFVF_* flags in Device7. Our thunk simply converts between these > > > two, > > > but a deeper difference a user noticed is that D3DVT_LVERTEX in Device2 > > > disables lighting calculations, whereas the equivalent D3DFVF flag > > > collection > > > in Device3 and Device7 does not. Device3 and newer have > > > D3DRENDERSTATE_LIGHTING to enable / disable lighting, but this render > > > state does not exist in Device2. > > > > > > Fixing this is fairly straightforward, just call > > > SetRenderState(LIGHTING, > > > ...) > > > in the thunk, but it needs some tests to answer / show the following: > > > > > > * Show that D3DVT_LVERTEX indeed disables lighting, and D3DVT_VERTEX > > > enables > > > it > > > * Show that D3DFVF_LVERTEX does not influence lighting in Device2 and > > > Device7(D3DFVF_TLVERTEX disables all vertex processing in all d3d > > > versions, this is already tested and implemented) > > > * Test what happens when you call SetRenderState and GetRenderState in > > > Device2. > > > * Probably others > > > > > > There are numerous things like that that need testing and probably > > > fixes. > > > This > > > is just one example that happens to be on my todo list. ddraw tests go > > > to > > > dlls/ddraw/tests/ddraw*.c. The other files should be moved to the > > > tests/ddraw*.c files and extended to cover all ddraw versions. > > > > > > For the command line tools, download an older version of the directx > sdk > > > that > > > still has vsa.exe and psa.exe(I think 2007 ones were the last ones) and > > > compare their command line parameters to > > > d3dx9.D3DXAssembleShaderFromFile > > > and > > > friends. > > > > > > The tests are certainly the more useful task. vsa.exe and psa.exe would > > > mainly > > > serve developer convenience when writing d3d8 and d3d9 tests since we > > > wouldn't > > > need an ancient dx sdk to assemble our own test shaders. d3d tests and > > > fixes > > > fix actual games. > > > > > > Enjoy, > > > Stefan > > > > > > (*) Actually, that's not how native vsa/psa work. They seem to have > > > their > > > own > > > copy-pasted version of the compiler and assembler, or they link > > > statically. We > > > should probably do it by calling d3dx9 though, especially for tools > that > > > mainly serve developer convenience. >

2 2

re: PDB format documentation.
by Dan Kegel 25 Mar '12

25 Mar '12

Svyatoslav wrote: > I've found that Wine dbghelp.dll includes PDB file parser. Does anyone > know where I can find documentation of PDB internal structure? I think you've found it :-) As you probably know, PDB is an undocumented format. I suspect the best you can find are scattered posts like http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html http://www.godevtool.com/Other/pdb.htm from people who reverse engineer bits of it. Although http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html claims http://ccimetadata.codeplex.com/ has some interesting bits from the horse's mouth, and http://code.google.com/p/pdbparse/ http://code.google.com/p/pdbparser/ http://pdbparser.codeplex.com might be interesting.

1 0

re: GSoC proposal
by Dan Kegel 25 Mar '12

25 Mar '12

> submitting multiple proposals are explicitly allowed. True, but be careful, for two reasons: 1) there may have been cases where people who submit applications to two orgs fall through the cracks, with each org thinking the other was going to take him. 2) passion generally drives success, and unless you're like my friend who didn't sleep and got a triple major in four years (and now heads chip development for a major game console), splitting your passion between multiple applications could reduce the chances of either one being accepted. Going a bit further with a single application, e.g. by including [more] working patches, seems the better choice... assuming you pick a project that the organization really likes, anyway.

1 0