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

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

On Sat, Oct 17, 2009 at 5:22 PM, Dan Kegel <dank at> wrote:
> On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White <jwhite at> 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.


More information about the wine-devel mailing list