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