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

[Dylan Smith]

On Fri, Feb 27, 2009 at 8:32 PM, Dan Kegel <dank at kegel.com> wrote:

> Hmm.  So making riched20 prefer native would break apps
> that use msftedit, if native riched20 but no native msftedit is present?
>

Yes.  Although I haven't heard of this being an issue with people using
winetricks.

>
> Does this mean that our msftedit is doing things differently than
> the native one?


Yes, native is like a newer version of riched20, not a wrapper like builtin
msftedit.  Of course this may change, since riched32 used to be a complete
implementation, but was later turned into a wrapper around riched20.

In order to do this the same way as native msftedit we would probably need
to recompile the riched20 code using a version macro to select different
behaviour for different parts of the code. This is seperate from 1.0
emulation which msftedit also allows, despite it's actually inconsistency
with riched32 on it's improvements to riched20 (e.g. improvement in table
implementation).  However, distinguishing between different version didn't
seem popular when I proposed the idea before, so I am waiting until this
inconsistency actually causes problems for any applications.

Either way, I don't think it would be much worse than the way things are for
both dlls to prefer native.  I am not opposed to any of the ideas proposed
for fixing the bug (whether it is checking if it is loaded from the system32
directory, using a heuristic based on version of the dll, or having riched20
prefer native).  What matters is what Julliard prefers, so I am just trying
to provide any relevant knowledge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20090228/7340e6ec/attachment.htm