February 2009 - Wine-Devel - list.winehq.org

Re: revert of a6c07ffba4b2b37d01affb4c39f032bb5f8d34bf

by Francois Gouget

On Thu, 19 Feb 2009, Steven Edwards wrote: > On Thu, Feb 19, 2009 at 5:43 AM, Francois Gouget <fgouget(a)free.fr> wrote: > > A little bit of explanation would be nice... > > I thought the Changelog in the patch would explain enough. MSG_WAITALL > is not defined on Cygwin when building wininet or winhttp without it. > Since I can't rebuild all of Wine and I've not checked on MSVC to see > if its just a w32api thing, maybe this one should be held off. Since it was a revert I did not expect anything in the patch. In fact it's not a revert at all since the diff is completely different from the original patch. Well, since Cygwin is a Unix platform after a fashion (iirc), I don't think you need to check with MSVC (with MinGW it would be different). So I think your patch is ok. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Feb. 20, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by James Hawkins

On Thu, Feb 19, 2009 at 11:30 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Thursday 19 February 2009 22:36:25 James Hawkins wrote: > >> > I don't see how it would hurt if we do match the sort order on Windows, >> > even if we achieve it by other means. >> > >> >> The reason it hurts in this case is because the sorting happens at the >> File/Directory API level and not in fusion itself. If the same logic >> applies, why don't we match sorting at that level in Wine? > > It would hurt overall performance if we do it at the directory API > level, so the same logic does not apply. > I'm not advocating adding it to the directory API. I'm saying if we don't care about it at that level, then we shouldn't care about it in fusion, and we certainly shouldn't add that functionality to fusion where it doesn't exist in native fusion. -- James Hawkins

Feb. 20, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by Hans Leidekker

On Thursday 19 February 2009 22:36:25 James Hawkins wrote: > > I don't see how it would hurt if we do match the sort order on Windows, > > even if we achieve it by other means. > > > > The reason it hurts in this case is because the sorting happens at the > File/Directory API level and not in fusion itself. If the same logic > applies, why don't we match sorting at that level in Wine? It would hurt overall performance if we do it at the directory API level, so the same logic does not apply. -Hans

Feb. 20, 2009

Re: msi: begin support for finding network last sources in find_published_source

by James Hawkins

On Thu, Feb 19, 2009 at 12:28 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > > Fix for office 2007 sp 1 install. > --- > dlls/msi/media.c | 33 +++++++++++++++++++++++++++++++++ > 1 files changed, 33 insertions(+), 0 deletions(-) > I believe you're going down the wrong road with respect to the Office 2007 SP1 installer. None of the files installed/patched by SP1 need access to the original media, or stored local copies of the cab archives. With the fullfile install (which I'm not sure there's another version), you should be able to remove the original media, erase the stored cab files, and successfully install SP1. The fact that our implementation tries to access those cabs or the original media is the bug. There are many conditions and variables that factor in to whether a file should be reinstalled or not, and most of them have been fixed, but this patch is hiding all of the rest of the bugs. I'm not sure if you got the email I sent Jer about this problem, but the real bug is that we aren't handling the REINSTALL variable correctly (or REINSTALLMODE for that matter.) Can you please describe the exact case for why this patch is needed? -- James Hawkins

Feb. 20, 2009

Re: fusion/tests: Do not use a fixed path to the assembly

by Nicolas Le Cam

2009/2/20 Detlef Riekenberg <wine.dev(a)web.de>: > James: A fixed path is broken by design. > > This fix the remaining failure on w2k. > > The asmcache has more failures on win9x, but a fix for that > failures conflict with the patchset from Hans. > > > -- > > By by ... Detlef > > > > Hi Detlef, I've already sent a similar patch, see http://www.winehq.org/pipermail/wine-patches/2009-February/069647.html

Feb. 20, 2009

Re: fusion/tests: Do not use a fixed path to the assembly

by James Hawkins

On Thu, Feb 19, 2009 at 4:14 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > James: A fixed path is broken by design. > A "Thanks for spending weeks of your time laboriously testing and implementing fusion" would have sufficed. -- James Hawkins

Feb. 20, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by James Hawkins

On Thu, Feb 19, 2009 at 1:14 PM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > > This isn't how it's done on Windows. On Windows, the order is based > > solely on directory enumeration, which we don't try to match in Wine. > > I don't see how it would hurt if we do match the sort order on Windows, > even if we achieve it by other means. > The reason it hurts in this case is because the sorting happens at the File/Directory API level and not in fusion itself. If the same logic applies, why don't we match sorting at that level in Wine? -- James Hawkins

Feb. 19, 2009

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.

by Hans Leidekker

> This isn't how it's done on Windows. On Windows, the order is based > solely on directory enumeration, which we don't try to match in Wine. I don't see how it would hurt if we do match the sort order on Windows, even if we achieve it by other means. -Hans

Feb. 19, 2009

Re: [13/13] fusion: Add tests for the IAssemblyEnum interface.

by Paul Vriens

Paul Vriens wrote: > Hans Leidekker wrote: >> Hi Paul, >> >>> These tests crash on Vista with .NET 3.5 (not sure about other >>> platforms/.NET versions yet). The enum_gac_assemblies function relies >>> on the fact that ffd.cFileName contains 2 underscores. On Vista >>> however I see some assemblies with a different format for the >>> cFileName like: >>> >>> 6.0.0.0_en_31bf3856ad364e35 >> >> Yes, that test simply ignores the culture attribute. Is that one of your >> own machines? If so, can you try this patch? >> >> -Hans >> > At least we don't crash at that point (but still at the HeapFree). The > patch is not correct however as tracing shows in some cases: > > Culture=en_31bf3856ad364e35 > > (and that makes sense reading the patch ;) ) > The second crash (HeapFree) is because we use strdup. Looks like on Windows strdup doesn't allocate memory on heap. I guess we should replace strdup by a HeapAlloc/lstrcpyA ? -- Cheers, Paul.

Feb. 19, 2009

Re: [13/13] fusion: Add tests for the IAssemblyEnum interface.

by Paul Vriens

Hans Leidekker wrote: > Hi Paul, > >> These tests crash on Vista with .NET 3.5 (not sure about other platforms/.NET >> versions yet). The enum_gac_assemblies function relies on the fact that >> ffd.cFileName contains 2 underscores. On Vista however I see some assemblies >> with a different format for the cFileName like: >> >> 6.0.0.0_en_31bf3856ad364e35 > > Yes, that test simply ignores the culture attribute. Is that one of your > own machines? If so, can you try this patch? > > -Hans > At least we don't crash at that point (but still at the HeapFree). The patch is not correct however as tracing shows in some cases: Culture=en_31bf3856ad364e35 (and that makes sense reading the patch ;) ) -- Cheers, Paul.

Feb. 19, 2009