July 2010 - Wine-Devel - list.winehq.org

New winetricks 20100731: new verbs eadm eufonts gfw glut ie8 safari secur32 xlive

by Dan Kegel

Another month, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English: New verbs eadm eufonts gfw (aka xlive) ie8 safari secur32 Turning off MouseWarpOverride should be 'disable' not 'disabled'. (Issue 138) flash, ogg: support silent installs Lots of updates and minor fixes Dan Kegel: New verb glut Mathieu Malaterre: update cmake to 2.8.2 (issue 136)

July 31, 2010

Re: [2/2] Try2: imagehlp: Implement ImageGetDigestStream

by Paul Vriens

Hi Andrey, On 07/18/2010 12:39 PM, Andrey Turkin wrote: > +static BOOL IMAGEHLP_ReportImportSection( IMAGE_SECTION_HEADER *hdr, > + DWORD num_sections, BYTE *map, DWORD fileSize, DWORD DigestLevel, > + DIGEST_FUNCTION DigestFunction, DIGEST_HANDLE DigestHandle ) > +{ > + BOOL ret = FALSE; > + DWORD offset, size, base; > + PBYTE import; import is defined here but not used any further down the line. > + > + /* Get import data */ > + offset = IMAGEHLP_GetSectionOffset( hdr, num_sections, ".idata",&size, > +&base ); > + if( !offset ) > + return FALSE; > + > + /* If CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO is set, the entire > + * section is reported. Otherwise, the debug info section is > + * decoded and reported piecemeal. See tests. However, I haven't been > + * able to figure out how the native implementation decides which values > + * to report. Either it's buggy or my understanding is flawed. > + */ > + if( DigestLevel& CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO ) > + ret = IMAGEHLP_ReportSectionFromOffset( offset, size, map, fileSize, > + DigestFunction, DigestHandle ); > + else > + { > + FIXME("not supported except for CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO\n"); > + SetLastError(ERROR_INVALID_PARAMETER); > + ret = FALSE; > + } > + HeapFree( GetProcessHeap(), 0, import ); Only freed. Can 'import' be removed? Coverity complained. -- Cheers, Paul.

July 31, 2010

Re: d3dx9: D3DXCreateMeshFVF

by Misha Koshelev

"Misha Koshelev" <misha680(a)gmail.com> wrote: >> Instead of implementing D3DXCreateMeshFVF, wouldn't it be better to >> implement D3DXCreateMesh and call the latter from D3DXCreateMeshFVF by >> previously using D3DXDeclaratorFromFVF? >> >> D3DXCreateMeshFVF would be pretty straight then: >> 1. get the const LPD3DVERTEXELEMENT9 *pDeclaration from the supplied FVF >> 2. call D3DXCreateMesh >> >> BTW, D3DXGetFVFVertexSize could then also be forwarded to >> D3DXGetDeclVertexSize and the code simplified. >Thank you > >Thank you. Yes indeed this is the approach that has been recommended by Henri Verbeet as well. > >Specifically, after the D3DXCreateSphere patch (in some form) is applied to git: >http://bugs2.winehq.org/attachment.cgi?id=29947 > >You can see two patches for tests here: >http://bugs2.winehq.org/attachment.cgi?id=29948 >http://bugs2.winehq.org/attachment.cgi?id=29949 > >The only caveat is that we must first implement D3DXFVFFromDeclarator at the very least, as the >CreateIndexBuffer call must be (to my understanding) supplied an FVF. > >Thank you >Misha > Fyi, I am currently taking a break from working on these patches as I feel like it may take some more time to get the D3DXCreateSphere tests into git given that it has been through so many tries. However, I hope that once this hurdle has passed I can once again continue to work on these implementations at full speed. Thank you Misha -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

July 31, 2010

Re: d3dx9: D3DXCreateMeshFVF

by Misha Koshelev

> Instead of implementing D3DXCreateMeshFVF, wouldn't it be better to > implement D3DXCreateMesh and call the latter from D3DXCreateMeshFVF by > previously using D3DXDeclaratorFromFVF? > > D3DXCreateMeshFVF would be pretty straight then: > 1. get the const LPD3DVERTEXELEMENT9 *pDeclaration from the supplied FVF > 2. call D3DXCreateMesh > > BTW, D3DXGetFVFVertexSize could then also be forwarded to > D3DXGetDeclVertexSize and the code simplified. Thank you Thank you. Yes indeed this is the approach that has been recommended by Henri Verbeet as well. Specifically, after the D3DXCreateSphere patch (in some form) is applied to git: http://bugs2.winehq.org/attachment.cgi?id=29947 You can see two patches for tests here: http://bugs2.winehq.org/attachment.cgi?id=29948 http://bugs2.winehq.org/attachment.cgi?id=29949 The only caveat is that we must first implement D3DXFVFFromDeclarator at the very least, as the CreateIndexBuffer call must be (to my understanding) supplied an FVF. Thank you Misha

July 31, 2010

d3dx9: D3DXCreateMeshFVF

by Luis Buquets

Instead of implementing D3DXCreateMeshFVF, wouldn't it be better to implement D3DXCreateMesh and call the latter from D3DXCreateMeshFVF by previously using D3DXDeclaratorFromFVF? D3DXCreateMeshFVF would be pretty straight then: 1. get the const LPD3DVERTEXELEMENT9 *pDeclaration from the supplied FVF 2. call D3DXCreateMesh BTW, D3DXGetFVFVertexSize could then also be forwarded to D3DXGetDeclVertexSize and the code simplified.

July 31, 2010

Re: [PATCH] d3dx9_36/tests: Added HLSL test suite. (Try 2)

by Jeff Zaroyko

On Sat, Jul 31, 2010 at 1:21 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > > === WXPPROSP3 (32 bit hlsl) === > hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a > No test summary line found > ...further CreateDevice test failures snipped... Is the purpose of these tests device creation? If not, then it doesn't really make any sense to do: > ok(SUCCEEDED(hres), "Could not create device, IDirect3D9_CreateDevice returned: %08x\n", hres); It would make more sense to just test the result of SUCCEEDED(hres) and then skip the tests if it's not possible to create the device rather than counting it as a failed test. Jeff

July 31, 2010

Re: [PATCH] d3dx9_36/tests: Added HLSL test suite. (Try 2)

by testbot＠testbot.winehq.org

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=4080 Your paranoid android. === WXPPROSP3 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W2K3R2SESP2 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === WVISTAADM (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W2K8SE (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PRO (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PROX64 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PROX64 (64 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a Timeout

July 31, 2010

Re: GetVolumeInformationA: please test this on MS-Windows

by Jeff Zaroyko

On Fri, Jul 30, 2010 at 7:01 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Do you get different results when doing the following: > # assuming C: is where %WINDOWSDIR% resides There's a %WINDIR% which is c:\windows > C: > cd \ > X: # which dir on X should not matter > Y:\path\to\kernel32_test.exe volume Passes outside of MinGW. > C: > cd \windows > X: > Y:\path\to\kernel32_test.exe volume > # X: must not be C:; Y: can be any drive Passes outside of MinGW. > For completion, you could check whether you get different results when > invoking the test.exe with current directory > a) C:\ # many GetVolumeInfo tests are skipped > b) C:\windows # dito > c) X:\ with \windows as CD on C: > d) X:\anysubdir with \windows as CD on C: > e) X:\anysubdir with \ as CD on C: > f) X:\ with \ as CD on C: > I think that if SetEnv has no effect you'll get different failures. > > I.e. this batch file > C: > CD \ > Y:\path\to\kernel32_test.exe volume > CD windows > Y:\path\to\kernel32_test.exe volume > X: > CD \ > Y:\path\to\kernel32_test.exe volume > CD \anysubdir > Y:\path\to\kernel32_test.exe volume > C: > CD \ > X: > Y:\path\to\kernel32_test.exe volume > CD \ > Y:\path\to\kernel32_test.exe volume No failures outside of MinGW. Inside MinGW, I invoke cmd to run the batch file: jeffz(a)JEFFZ-PC ~/Desktop $ cmd Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. c:\Users\jeffz\Desktop>joerg.bat c:\Users\jeffz\Desktop>C: c:\Users\jeffz\Desktop>CD \ c:\>c:\users\jeffz\Desktop\kernel32_test.exe volume volume.c:365: Test failed: GetVolumeInformationA did not fail, last error 373 8559 volume.c:384: Test failed: GetVolumeInformationA did not fail, last error 373 8559 volume: 406 tests executed (0 marked as todo, 2 failures), 0 skipped. c:\>CD windows c:\Windows>c:\users\jeffz\Desktop\kernel32_test.exe volume volume.c:395: Test failed: GetVolumeInformationA failed, last error 123 volume.c:406: Test failed: GetVolumeInformationA failed, last error 123 volume: 406 tests executed (0 marked as todo, 2 failures), 0 skipped. c:\Windows>D: D:\>CD \ D:\>c:\users\jeffz\Desktop\kernel32_test.exe volume volume: 406 tests executed (0 marked as todo, 0 failures), 0 skipped. D:\>CD \recovery D:\RECOVERY>c:\users\jeffz\Desktop\kernel32_test.exe volume volume: 406 tests executed (0 marked as todo, 0 failures), 0 skipped. D:\RECOVERY>C: c:\Windows>CD \ c:\>D: D:\RECOVERY>c:\users\jeffz\Desktop\kernel32_test.exe volume volume: 406 tests executed (0 marked as todo, 0 failures), 0 skipped. D:\RECOVERY>CD \ D:\>c:\users\jeffz\Desktop\kernel32_test.exe volume volume: 406 tests executed (0 marked as todo, 0 failures), 0 skipped. D:\> Regards Jeff

July 31, 2010

Re: [website] Wine 1.3.0 freigegeben

by Frédéric Delanoy

2010/7/30 André Hentschel <nerv(a)dawncrow.de>: > --- > news/de/2010073001.xml | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 news/de/2010073001.xml > > -- > > Best Regards, André Hentschel I know you're sending the German translation, but patches commit logs should stay in English IMHO. Imagine everyone sending a log message with their own mother tongue... what would you do in you received a patch with a commit log in, say, Korean... Regards, Frédéric

July 30, 2010

Re: [5/9] msi: Set/unset the SourceDir property at the right stage in the execution sequence.

by Paul Vriens

Hi Hans, On 07/23/2010 09:42 AM, Hans Leidekker wrote: > + /* full UI, no ResolveSource action */ > + r = MsiInstallProductA(msifile, NULL); > + ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %u\n", r); Right about here I get a popup, waiting for 'OK' to be pushed, on Win95/98/Me that says "Test 14 failed". That does explain some of the timeouts we see on test.winehq.org for those platforms as of this patch. -- Cheers, Paul.

July 30, 2010