[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: search path redux - if office 2007 always uses a private
From:       Dylan Smith <dylan.ah.smith () gmail ! com>
Date:       2009-02-28 7:58:02
Message-ID: 5c6ee3b70902272358k4df998earc1e897ce17ba711a () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.

[Attachment #5 (text/html)]

<div class="gmail_quote">On Fri, Feb 27, 2009 at 8:32 PM, Dan Kegel <span \
dir="ltr">&lt;<a href="mailto:dank@kegel.com">dank@kegel.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">
</div>Hmm.  So making riched20 prefer native would break apps<br>
that use msftedit, if native riched20 but no native msftedit is present?<br>
</blockquote><div><br>Yes.  Although I haven&#39;t heard of this being an issue with \
people using winetricks. <br></div><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> <br>
Does this mean that our msftedit is doing things differently than<br>
the native one?</blockquote></div><br>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.<br><br>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&#39;s actually inconsistency with \
riched32 on it&#39;s improvements to riched20 (e.g. improvement in table \
implementation).  However, distinguishing between different version didn&#39;t seem \
popular when I proposed the idea before, so I am waiting until this inconsistency \
actually causes problems for any applications.<br> <br>Either way, I don&#39;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.<br>





[prev in list] [next in list] [prev in thread] [next in thread]