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.
Here are the options that I can think of: 1. We could continue to implement msftedit.dll as a wrapper around riched20.dll. This patch would be a step in that direction. 2. We could have two separate implementations, despite the fact that the two dlls are very similar. 3. We could have one implementation, and hope that it doesn't matter to programs using them, but this seem too inflexible to me. 4. We could also have a single implementation with preprocessor conditions, and then compile the code twice with different defines. On Fri, Jun 27, 2008 at 3:30 PM, Phil Krylov <[EMAIL PROTECTED]> wrote: > Hi, > > 2008/6/27 Dylan Smith <[EMAIL PROTECTED]>: > > riched20.dll is implementing all the versions of richedit controls (1.0, > 2.0, > > 3.0, and 4.1), so it is better to store the version that is being > emulated. > > The bEmulateVersion10 value is replaced with dwEmulatedVersion. > > I thought it implements 1.0 emulation for riched32.dll usage and > latest possible version for other usages - just like native. Or are > you planning to add some functionality depending on the actual > emulated version, not on (dwEmulatedVersion < 0x200) boolean flag? > > -- Ph. >
