Currently msftedit.dll is implemented by loading riched20.dll and then riched20.dll registers the classes that msftedit.dll normally register. Native msftedit.dll appears to be a full implementation of the richedit controls, rather than a wrapper.<br>
<br>Here are the options that I can think of:<br>1. We could continue to implement msftedit.dll as a wrapper around riched20.dll. This patch would be a step in that direction.<br>2. We could have two separate implementations, despite the fact that the two dlls are very similar.<br>
3. We could have one implementation, and hope that it doesn't matter to programs using them, but this seem too inflexible to me.<br>4. We could also have a single implementation with preprocessor conditions, and then compile the code twice with different defines.<br>
<br><div class="gmail_quote">On Fri, Jun 27, 2008 at 3:30 PM, Phil Krylov <<a href="mailto:phil.krylov@gmail.com">phil.krylov@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
2008/6/27 Dylan Smith <<a href="mailto:dylan.ah.smith@gmail.com">dylan.ah.smith@gmail.com</a>>:<br>
<div class="Ih2E3d">> riched20.dll is implementing all the versions of richedit controls (1.0, 2.0,<br>
> 3.0, and 4.1), so it is better to store the version that is being emulated.<br>
> The bEmulateVersion10 value is replaced with dwEmulatedVersion.<br>
<br>
</div>I thought it implements 1.0 emulation for riched32.dll usage and<br>
latest possible version for other usages - just like native. Or are<br>
you planning to add some functionality depending on the actual<br>
emulated version, not on (dwEmulatedVersion < 0x200) boolean flag?<br>
<br>
-- Ph.<br>
</blockquote></div><br>