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