On Fri, Feb 27, 2009 at 8:32 PM, Dan Kegel <dank@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.