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

James McKenzie jjmckenzie51 at earthlink.net
Sat Oct 17 14:12:57 CDT 2009


Dan Kegel wrote:
> On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith <dylan.ah.smith at gmail.com> wrote:
>   
>>> Say, have we considered making riched20 prefer native?
>>> That makes the app work, too.
>>>       
>> A couple of things to note, in case they are relevant:
>> 1. msftedit currently uses the native version by default
>> 2. builtin msftedit will not work with native riched20, since the classes
>> native msftedit loads are instead loaded by builtin riched20, and msftedit
>> just loads riched20
>>     
>
> Hmm.  So making riched20 prefer native would break apps
> that use msftedit, if native riched20 but no native msftedit is present?
>
> Does this mean that our msftedit is doing things differently than
> the native one?
>
>   
Let's stick a fork in this conversation for a moment and think about
what we are saying here:

Office 2007 comes with an 'improved' richedit handing set of files,
riched20.dll and riched32.dll which function drastically different from
those supplied with WindowsXP and even possibly Vista.

So what do we do?

1.  Detect and use the native dlls for Office2007 and use ours for
everything else (or)
2.  Work on blackboxing those dlls and adding in those functions that
are not currenly supported into the native dlls?

I prefer the second solution as this gets rid of 'dll hell' and makes
our dlls implementations better than those of MicroSoft.

Opinions from those gathered around the soapbox?

James McKenzie





More information about the wine-devel mailing list