On Fri, 2004-11-19 at 03:22, Mike McCormack wrote:
Michael Ost wrote:
(1) The wine bug (I think) is that riched32.dll is registering the wrong window class name. Here's a suggested patch:
RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The windows 2000 implementation uses riched20.dll to implement riched32.dll (ie. moves the richedit code to riched20.dll and implements the RICHEDIT_CLASS10A class using the new RICHEDIT_CLASS20A class.
In short, the existing code registers the correct class name, but we need to make a new dll dlls/riched20, and do alot of work on the richedit control :)
This isn't quite clear to me. It sounds like you are saying there is a riched20.dll in wine, but I can't find one. Are these statements correct?
* Wine's only implements RichEdit10A via riched32.dll. Wine does not implement RichEdit20A.
* Win2K (and later) provides riched20.dll which implements RICHEDIT_CLASS20A. This one I can verify as true on my winxp system.
* There are significant differences between the two window classes
My winelib app is hosting a 3rd party DLL which is specifically requesting "RichEdit20A". That suggests that the DLL was built with win2K or later, from what you were saying. Sounds like my options are to:
* hack their request to use the window class registered by wine's riched32.dll. How well could I expect this to work? How big are the diffs between 10A and 20A?
* get them to provide win2k's riched20.dll
* have them change their DLL to ask for RichEdit10A instead
* implement riched20.dll in Wine. Sounds like a big job!
Sound right? Any comments? Thanks a bunch... mo