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

RE: msi:RECORD_StreamFromFile bug, help needed

by robert.van.herk＠serioustoys.com

> 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

June 20, 2012

Re: shell32: Make ShellExecute use native file association databases as fallback path (try 2)

by Francois Gouget

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>

June 20, 2012

RE: msi:RECORD_StreamFromFile bug, help needed

by Hans Leidekker

On Tue, 2012-06-19 at 21:45 +0200, robert.van.herk(a)serioustoys.com wrote: > > We don't have to call SHCreateStreamOnFileEx, we can add a suitable implementation to msi. > > Ah, I see. > > I guess this stream cannot escape from MSI. The only way it can be accessed is > through MsiRecordReadStream and MsiRecordSetStream, but it can never be accessed > directly? > > In that case, we don't have to use an IStream... > I could alter msipriv.h such that MSIFIELD just holds a HANDLE in case the field > is a stream. > The handle can then be created through CreateFile, and I guess then I could alter > the permissions such that it matches the MS implementation... > > Do you think that that is the way to go? > > Or is there a deep reason why we should use IStream, and create our own IStream > implementation? 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.

June 20, 2012

RE: msi:RECORD_StreamFromFile bug, help needed

by robert.van.herk＠serioustoys.com

> We don't have to call SHCreateStreamOnFileEx, we can add a suitable implementation to msi. Ah, I see. I guess this stream cannot escape from MSI. The only way it can be accessed is through MsiRecordReadStream and MsiRecordSetStream, but it can never be accessed directly? In that case, we don't have to use an IStream... I could alter msipriv.h such that MSIFIELD just holds a HANDLE in case the field is a stream. The handle can then be created through CreateFile, and I guess then I could alter the permissions such that it matches the MS implementation... Do you think that that is the way to go? Or is there a deep reason why we should use IStream, and create our own IStream implementation? Regards, Robert

June 19, 2012

RE: msi:RECORD_StreamFromFile bug, help needed

by Hans Leidekker

On Tue, 2012-06-19 at 20:55 +0200, robert.van.herk(a)serioustoys.com wrote: > > Yes, the concern is that the file could be changed or removed. We should > > test what native does here but it probably means that we need to create a stream > > on the file with a sharing mode that denies writing. > > So... I tried this out. I do not understand what I found though! > > On Windows, after MSI_RecordSetStreamFromFileW, you CAN call DeleteFile on that file. > But you cannot open the file for writing; that will give ERROR_ACCESS_DENIED. > > I found in the specs of DeleteFile that this behaviour is understandable, because > " > The DeleteFile function marks a file for deletion on close. Therefore, the file > deletion does not occur until the last handle to the file is closed. Subsequent > calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. > " > > On the other hand, it says: > " > The DeleteFile function fails if an application attempts to delete a file that > is open for normal I/O or as a memory-mapped file. > " > > So... I figured that somehow in the MS implementation of RecordSetStreamFromFile > they called SHCreateStreamOnFileEx with parameters that allowed it to be scheduled > for deletion through DeleteFile, and didn't allow the file to be opened again for > writing. > > So far so good. > > So I set out to find this combination of parameters and I cannot find it. I saw > that for CreateFile, you can pass FILE_SHARE_DELETE, and I guess that that allows > for DeleteFile to be called. However, you cannot pass flags to SHCreateStreamOnFileEx > that will cause this flag to be set... We don't have to call SHCreateStreamOnFileEx, we can add a suitable implementation to msi.

June 19, 2012

RE: msi:RECORD_StreamFromFile bug, help needed

by robert.van.herk＠serioustoys.com

> Yes, the concern is that the file could be changed or removed. We should > test what native does here but it probably means that we need to create a stream > on the file with a sharing mode that denies writing. So... I tried this out. I do not understand what I found though! On Windows, after MSI_RecordSetStreamFromFileW, you CAN call DeleteFile on that file. But you cannot open the file for writing; that will give ERROR_ACCESS_DENIED. I found in the specs of DeleteFile that this behaviour is understandable, because " The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. " On the other hand, it says: " The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. " So... I figured that somehow in the MS implementation of RecordSetStreamFromFile they called SHCreateStreamOnFileEx with parameters that allowed it to be scheduled for deletion through DeleteFile, and didn't allow the file to be opened again for writing. So far so good. So I set out to find this combination of parameters and I cannot find it. I saw that for CreateFile, you can pass FILE_SHARE_DELETE, and I guess that that allows for DeleteFile to be called. However, you cannot pass flags to SHCreateStreamOnFileEx that will cause this flag to be set... I am a bit out of ideas now... Maybe SHCreateStreamOnFileEx does NOT actually create the stream, but just opens the file and stores the filename in order to create the stream later on, when it is needed? Thus, some sort of lazy initialization? Any other ideas? Regards, Robert

June 19, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability.

by André Hentschel

Am 19.06.2012 03:09, schrieb Erich E. Hoover: > On Mon, Jun 18, 2012 at 3:26 PM, André Hentschel <nerv(a)dawncrow.de> wrote: >> Am 18.06.2012 15:52, schrieb Erich E. Hoover: >> ... >>> Changelog: >>> hhctrl.ocx: Add HTML to Unicode decoding capability. >> >> You're adding dead code here, you should maybe merge Patch 1 & 2 > > Since part 2 and 3 are both dependent upon this code I chose to do it > this way in order to aid in any potential debugging and regression > testing (allowing for the easy independent removal of either the ToC > changes or the Index changes). So, would you prefer that I leave it; > just merge part 1 and 2; or merge part 1, 2, and 3. merge patch 1 and (patch 2 or patch 3) -- Best Regards, André Hentschel

June 19, 2012

Re: shell32: add some tests for the Progman DDE interface

by Alexandre Julliard

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

June 19, 2012

Re: ntdll : add ThreadQuerySetWin32StartAddress in NtQueryInformationThread

by Alexandre Julliard

Roman Dadkov <romand(a)etersoft.ru> writes: > @@ -63,7 +63,7 @@ struct reply_header > /* this is used to construct the generic_request union */ > struct request_max_size > { > - int pad[16]; /* the max request size is 16 ints */ > + int pad[18]; /* the max request size is 18 ints */ > }; You can't change that. -- Alexandre Julliard julliard(a)winehq.org

June 19, 2012

Re: mmcndmgr: Implement IMMCVersionInfo (try 4)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -66,8 +179,6 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > > switch (fdwReason) > { > - case DLL_WINE_PREATTACH: > - return FALSE; /* prefer native version */ Changing this may or may not be a good idea at this point, but it definitely shouldn't be silently sneaked in as part of a different patch. -- Alexandre Julliard julliard(a)winehq.org

June 19, 2012