<div class="gmail_quote">2009/2/17 Alexandre Julliard <span dir="ltr"><<a href="mailto:julliard@winehq.org">julliard@winehq.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dan Kegel <<a href="mailto:dank@kegel.com">dank@kegel.com</a>> writes:<br>
<br>
> See <a href="http://bugs.winehq.org/show_bug.cgi?id=14980" target="_blank">http://bugs.winehq.org/show_bug.cgi?id=14980</a><br>
><br>
> Essentially, to run Office 2007, you have to set an override<br>
> for riched20. Since Office installs a new, spiffier version<br>
> of riched20 in its own private directory, and expects to<br>
> find it there, isn't it a bug that we don't let it have it?<br>
<br>
There's no guarantee that using the private version would help. In some<br>
cases it does, in other cases it makes things worse. So defaulting to<br>
builtin is preferable, this way at least when it doesn't work we have a<br>
chance of fixing it. </blockquote><div><br>Well, no, that's the nature of dlls though. There's no guarantee that if an <br>app supplies one to override a system dll it will make anything run any <br>"better" than the system dll.<br>
<br>However the app that supplies a dll most certainly expects it will get that <br>dll, including whatever buggy behaviour it contains and may indeed rely <br>on to work, which is why Windows lets the app hang itself with its own <br>
rope and looks there first.<br><br>--<br>Chris<br></div></div>