search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

Roderick Colenbrander thunderbird2k at gmail.com
Sat Oct 17 10:35:55 CDT 2009


On Sat, Oct 17, 2009 at 5:22 PM, Dan Kegel <dank at kegel.com> wrote:
> On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White <jwhite at codeweavers.com> wrote:
>> Alexandre wanted a version check when asked a different question.  That
>> question
>> was when would we prefer an available native Richedit over the builtin one.
>> (i.e. in the LoadLibrary("riched20") case).
>
> Looking back at the bug, that one uses an absolute path, too:
> 00e6:Call KERNEL32.LoadLibraryA(0032a40c "C:\\Program Files\\Common
> Files\\Microsoft Shared\\office12\\riched20.dll") ret=3261c0d6
>
>> I think if we get a loadlibrary on an explicit private path, we should load
>> that dll natively, even if we have a builtin dll of the same name.
>

I guess loading the native dll when an absolute path is specified is
correct. It might also be useful to figure our where the LoadLibrary
is really coming from as it might be a bug in a different part of
Wine. Assuming Microsoft correctly uses technologies like manifest to
fix version hell, I can imagine that Office 2007 is using this for
loading riched20.dll and assuming that is the case the LoadLibrary is
coming from Wine itself and it would mean that some of our activation
context is not working correctlly.

Roderick



More information about the wine-devel mailing list