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

Re: kernel32: Add a test for deleting an opened for reading file.
by Marvin 21 Jun '12

21 Jun '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=19407 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2KPROSP4 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === WXPPROSP3 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2K3R2SESP2 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === WVISTAADM (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2K8SE (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PRO (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PROX64 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === TEST64_W7SP1 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PROX64 (64 bit file) === file.c:3255: Test failed: DeleteFile error 2 === TEST64_W7SP1 (64 bit file) === file.c:3255: Test failed: DeleteFile error 2

1 0

Re: windowscodecs: Create a IWICMetadataReader for a TIFF frame. Take 3.
by Dmitry Timoshkov 21 Jun '12

21 Jun '12

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/windowscodecs/tiffformat.c | 75 +++++++++++++++++++++++++++++++++++++---- > 1 file changed, 69 insertions(+), 6 deletions(-) Just a note, that once this patch is committed plus today's IFD metadata reader improvements the infrastructure for metadata handling in TIFF files should be all done. WICExplorer is able to recognize and show complete metadata listings for every frame in a multiframe TIFF file (native riched20 is needed for nicer visualization). -- Dmitry.

1 0

Re: [PATCH] winspool/tests: Fix failures, when the spooler service is not running
by Marvin 20 Jun '12

20 Jun '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=19360 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: gdiplus: Implement GdipImageSelectActiveFrame. Take 2.
by Vincent Povirk 20 Jun '12

20 Jun '12

Looks good to me.

1 0

RE: msi:RECORD_StreamFromFile bug, help needed
by robert.van.herk＠serioustoys.com 20 Jun '12

20 Jun '12

> IStream is not exposed to the user, but an internal interface would probably end up looking a lot like IStream because we need read/write/seek operations, reference counting and the ability to create clones. So we might as well use IStream. Hmmm... Then I want exactly the same as SHCreateStreamOnFileEx, but the only difference is that the file should be opened with FILE_SHARE_DELETE. (I think). What is that policy on this? It seems overkill to copy istream.c from shlwapi, just because I want to change 1 flag. On the other hand, I don't want to expose more functions in the shlwapi header, as that would make it different from the Windows implementation... Regards, Robert

2 1

Re: mmcndmgr: Implement IMMCVersionInfo (try 5)
by Marvin 20 Jun '12

20 Jun '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=19325 Your paranoid android. === WNT4WSSP6 (32 bit mmcndmgr) === mmcndmgr.c:40: Test failed: got 0x80040154, expected 0x00000000 === W2KPROSP4 (32 bit mmcndmgr) === mmcndmgr.c:40: Test failed: got 0x80040154, expected 0x00000000

1 0

Re: shell32: Make ShellExecute use native file association databases as fallback path (try 2)
by Francois Gouget 20 Jun '12

20 Jun '12

On Tue, 19 Jun 2012, Erik van Pienbroek wrote: [...] > Additionally a check is added to make sure no recursive loop is > triggered when the native file association database points back to > wine and the fallback path is triggered again This looks much better. [...] > @@ -1911,6 +1944,44 @@ static BOOL SHELL_execute( LPSHELLEXECUTEINFOW sei, SHELL_ExecuteW32 execfunc ) > strcatW(lpstrTmpFile, lpFile); > retval = (UINT_PTR)ShellExecuteW(sei_tmp.hwnd, sei_tmp.lpVerb, lpstrTmpFile, NULL, NULL, 0); > } > +#if defined(HAVE_FORK) && defined(HAVE_WAITPID) > + /* Integration with native file association database */ > + else if (!getenv("WINE_INSIDE_SHELLEXECUTE")) > + { [...] > + /* Prevent the situation where the native file association database > + * tries to run wine to execute a program and we trigger this fallback > + * path again and end up in a recursive loop */ > + setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0); [...] + unsetenv("WINE_INSIDE_SHELLEXECUTE"); Setting WINE_INSIDE_SHELLEXECUTE here creates a race condition if two threads call ShellExecute() at the same time. So I think this should be set between the fork() and the exec() in SHELL_try_native_execute(). -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

msi:RECORD_StreamFromFile bug, help needed
by robert.van.herk＠serioustoys.com 20 Jun '12

20 Jun '12

Hi all, I think I found a msi.dll, record.c, RECORD_StreamFromFile. This function calls GlobalAlloc, with a file size as an argument. However, I believe that this can easily fail (which it does in my case) when the file size is too large. In my case, my msi builder (WiX) calls MsiRecordSetStreamW, which calls static function RECORD_StreamFromFile. WiX calls MsiRecordSetStreamW on some file that seems to be 0x11b2acc5 bytes (296 megs) large. Trying to allocate the block of 296 megs causes the error: 036:Call msi.MsiRecordSetStreamW(00000003,00000002,0cc8078c L"C:\\users\\robert\\Temp\\3c5c43d5\\1bfe39fa\\#product.cab") ret=009a4c3a 0036:Call KERNEL32.CreateFileW(0cc8078c L"C:\\users\\robert\\Temp\\3c5c43d5\\1bfe39fa\\#product.cab",80000000,00000001,00000000,00000003,00000000,00000000) ret=202868cf 0036:Ret KERNEL32.CreateFileW() retval=00000100 ret=202868cf 0036:Call KERNEL32.GetFileSize(00000100,0033ef58) ret=202868ef 0036:Ret KERNEL32.GetFileSize() retval=11b2acc5 ret=202868ef 0036:Call KERNEL32.GlobalAlloc(00000000,11b2acc5) ret=202869fb 0036:Ret KERNEL32.GlobalAlloc() retval=00000000 ret=202869fb <--- fail I believe the call to GlobalAlloc stems from RECORD_StreamFromFile. This tries to copy the full contents of the file in memory, and then create an IStream from that memory using CreateStreamOnHGlobal: /* read the data in a file into an IStream */ static UINT RECORD_StreamFromFile(LPCWSTR szFile, IStream **pstm) { ... handle = CreateFileW(szFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ... sz = GetFileSize(handle, &szHighWord); if( sz != INVALID_FILE_SIZE && szHig sz = GetFileSize(handle, &szHighWord); if( sz != INVALID_FILE_SIZE && szHighWord == 0 ) { hGlob = GlobalAlloc(GMEM_FIXED, sz); // <-- Fails in my case, because sz == 296 megs if( hGlob ) { BOOL r = ReadFile(handle, hGlob, sz, &read, NULL); if( !r ) { GlobalFree(hGlob); hGlob = 0; } } CloseHandle(handle); if( !hGlob ) return ERROR_FUNCTION_FAILED; // <-- hence, this error is raised. hr = CreateStreamOnHGlobal(hGlob, TRUE, pstm); ... } I want to fix this. I guess that apart from that the allocation fails, I have the feeling that copying this entire 296 megs into main memory is anyway a bit heavy, just for creating a stream. So I thought a better solution would be just to create a stream from the file. My first guess would be to use the SHCreateStreamOnFile function: HRESULT SHCreateStreamOnFile( __in LPCTSTR pszFile, __in DWORD grfMode, __out IStream **ppstm ); But then I was thinking: this seems like such an obvious thing to do, that it is almost suspicious. Was there any reason for copying the file contents to main memory and then create a memory stream? For instance, was the intention to have a non-mutable copy in memory, in case the backing file would be altered later on? I guess if that's the case, I could just create a copy of the original file in a temp dir, and mark it as STGM_DELETEONRELEASE. Before I wildly attempt a fix though, I would appreciate it if someone had an idea here... Kind regards, Robert van Herk

2 8

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability.
by André Hentschel 19 Jun '12

19 Jun '12

Am 18.06.2012 15:52, schrieb Erich E. Hoover: > Real Name: > Erich Hoover > > Description: > This patch adds the ability in HTML Help to convert HTML encoded > characters (e.g. ê) into the Unicode character equivalent. This > feature is needed by the table of contents and the index for > displaying international characters in some CHM files. With this > version of the patch the code for finding the appropriate symbol has > been split out into a separate function (requested by Michael > Stefaniuc) and the string comparison has been modified to use the > larger of the two lengths (the length of the symbol to check and the > length of the symbol given in the help file). > > Changelog: > hhctrl.ocx: Add HTML to Unicode decoding capability. You're adding dead code here, you should maybe merge Patch 1 & 2 -- Best Regards, André Hentschel

2 2

Re: shell32: add some tests for the Progman DDE interface
by Alexandre Julliard 19 Jun '12

19 Jun '12

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * shell32: add some tests for the Progman DDE interface Please merge that with the existing tests, assuming that what you are testing is not already covered. -- Alexandre Julliard julliard(a)winehq.org

1 0