The MASM Forum

General => The Workshop => Topic started by: jj2007 on May 25, 2016, 06:21:43 PM

Title: Making RichEdit work properly on Windows 10
Post by: jj2007 on May 25, 2016, 06:21:43 PM
After "upgrading" one of my machine to Windows 10, I discovered a glitch in its handling of the RichEdit control:
When launching RichMasm (http://masm32.com/board/index.php?topic=5314.0) the first time, a message box pops up saying "msptls.dll missing".

On further investigation, it turns out that this DLL sits in C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\MSPTLS.DLL, together with the RICHED20.DLL that RichMasm (http://masm32.com/board/index.php?topic=5314.0) loads successfully.

This is fixed for RichMasm in the latest MasmBasic release (http://masm32.com/board/index.php?topic=94.0), and MB coders can test the workaround (attached) with e.g.

include \masm32\MasmBasic\Res\MbGui.asm
  GuiControl MyRich, "richedit"
  SetWin$ hMyRich=FileRead$(CL$())
GuiEnd


Chances are that you will never encounter the "msptls.dll missing" box, because most of the time people simply use
Code: [Select]
invoke LoadLibrary, chr$("RichEd20.dll") or
invoke LoadLibrary, chr$("msftedit.dll")

Both load the DLL from C:\Windows\System32. While I have not tested the msftedit dll extensively (it looked crappy), I did work a lot with RichEd20. It is buggy, too, but we know our workarounds. What is remarkable, though, is that the System32 version is SLOOOOOW. You won't notice any problems with e.g. \Masm32\Examples\*.asm, but beyond a few hundred lines, loading a file into a richedit control becomes a PITA.

The solution is to use a better version. Only Murray Sargent (https://blogs.msdn.microsoft.com/murrays/) ("I'm a software development engineer in Microsoft Office and have been working mostly on the RichEdit editor since 1994.") knows why M$ offers the crappy DLL in System32, but fortunately, there is a solution: Use the Office version, e.g.:
Code: [Select]
C:\Program Files (x86)\Common Files\microsoft shared\Office11\RICHED20.DLL
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL

RichMasm does this automatically for you, and MB coders can use
Code: [Select]
  MbLoadRich PROTO
  call MbLoadRich

Put an int 3 in front if you want to discover the magic workaround that makes the Office12 version work on Win10 ;-)

Depending on availability, you get Office11, then Office12, then Sys32.
The fastest one is Office11, O12 is 10% slower, Sys32 is a factor 25 or so slower.

OK, you checked, and that folder doesn't exist :(
On my Win8.1 PC that I "upgraded" to Win10, both folders are present but only Office12 has the DLL in it. That is why I got the error box. No idea whether Office12 is installed by default, and why.

Anyway, M$ is at your service: View, print and copy Word documents, even if you don't have Word installed. This download is a replacement for Word Viewer 2003 (https://www.microsoft.com/en-us/download/details.aspx?id=4)
Install it (24 MB), then discover a new folder and a fast RichEdit control.

EDIT: Attached Mini_Rtf_Reader.exe needs a filename in the commandline, otherwise it throws an exception.
Title: Re: Making RichEdit work properly on Windows 10
Post by: hutch-- on May 25, 2016, 07:46:50 PM
I think you get the speed loss from using RTF rather than plain text. I still use the DLL call to rich edit 2 and because of the plain text only it will load many megabytes quickly.
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on May 25, 2016, 08:05:49 PM
I think you get the speed loss from using RTF rather than plain text. I still use the DLL call to rich edit 2 and because of the plain text only it will load many megabytes quickly.

Hutch,
What you write is correct, but why use a rich edit control for poor text? It is meant for rich text, and there is no excuse that my bigger files load a factor 50 slower with the crappy System32 OS version. Or that msftedit.dll has fat bugs:

If only I could convince the RichEdit50W EM_STREAMOUT message that occasionally "forgetting" a line feed is not an acceptable behaviour (https://blogs.msdn.microsoft.com/murrays/2006/10/19/some-richedit-history/)

Even the man behind RichEdit complains: (https://blogs.msdn.microsoft.com/murrays/2006/10/13/richedit-versions/#comment-2763)

Quote
MurrayS
March 26, 2009 at 12:42 pm   

RichEdit is developed by Microsoft Office and is a basic component in this program suite. Two versions (RichEdit 3.0 and 4.1) are also distributed with Windows. They shipped originally with Office 2000 and Office 2002. We’ve been hoping to ship a newer version in Windows for some time, but testing the huge backward compatibility scenarios and writing the up-to-date documentation have been stumbling blocks. Comments like yours help increase the priority. Thanks

We are now 2016, 22 years after Murray Sargent started working on it. The latest finest Windows 10 RichEd.DLL is still slow as hell: 20 seconds to load my 1.5MB testbed, instead of 0.8 seconds with the Office version. With the Office11 RichEd20.dll, you can load 80MB of rich text in about 5 seconds. This is ok, but why does the crappy OS version still hang around? To discourage developers from using RichEdit?

This is Microsoft at its best :redface:

P.S.: So far I found 4 versions of RichEd20.dll - note the deliciously consistent versioning system:
Code: [Select]
C:\Windows\System32\riched20.dll:
Rich Text Edit control v 3.1
5.31.23.1230
NAME: Microsoft Rich Text Edit control version 3.1
473600 bytes, 21 Nov 2010

Office11 folder:
Version 5.0
5.50.99.2050
NAME: Copyright Microsoft 1997-2006
original file name MsftEdit.dll
1103280 bytes, 18 June 2007

Office12 folder:
Version 6.0
12.0.6500.5000
NAME: 2007 Microsoft Office system
1017176 bytes, 26 Feb 2009

Office 2010 (?):
Version 6.0
14.0.4750.1000
NAME: Microsoft Office 2010
1366376 bytes, 1 Oct 2010
Title: Re: Making RichEdit work properly on Windows 10
Post by: TWell on May 26, 2016, 03:38:52 AM
My small test with small RTF-file 48 Mb.
Code: [Select]
riched20.dll:  8727 ms v 3.1
riched20.dll:  1254 ms v 4.0
riched20.dll:  1421 ms v 5.0
msftedit.dll:  2163 ms v 4.1
msftedit.dll:  1911 ms v 7.5 Windows 8.1
msftedit.dll: 12027 ms v 7.5 Windows 10
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on May 26, 2016, 04:12:11 AM
Doesn't look very plausible. How did you fill the control? Can you post the test?

EDIT: Tim sent me a fat RTF, and I did some tests:
Code: [Select]
Timings (seconds)
1.1 Office 2010 RichEd20.DLL *)
1.5   Office 2010, version 4 <<< compact and fast, correct as 6.0, added by Tim 26.5.
1.8 Office11 folder
2.2 Office12 folder
15.0 Windows\System32\RichEd20.dll

So we have a clear winner: Tim's Office 2010 version. But check the screenshot below - it loads only 50% of the doc... ::)

Note that the math formulas appear correctly in MS Word and WordPad - they are saved as images, apparently. The doc is 48MB, but saved as plain text, only 0.7MB remain, so there must be plenty of embedded images.

Given that the official Sys32 (last screenshot) is just slow and crappy, the choice is basically between the versions that the free Word viewers (https://www.microsoft.com/en-us/download/details.aspx?id=4) install as C:\Program Files (x86)\Common Files\microsoft shared\Office1?\RICHED20.DLL (see Oct 2013 thread (http://masm32.com/board/index.php?topic=2448.msg25637#msg25637))

The Office11 folder gets filled by the free Word Viewer (https://www.microsoft.com/en-us/download/details.aspx?id=4) (recommended, the best and fastest RichEd20 imho), the Office12 folder by the free Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint File Formats (https://www.microsoft.com/en-us/download/details.aspx?id=3).
Title: GETTEXTLENGTHEX
Post by: jj2007 on June 06, 2016, 07:49:22 AM
One more goodie for those who still stick to this great control: the flags of GETTEXTLENGTHEX 8)

My tests with a 4MB file show that
Code: [Select]
GTL_PRECISE or GTL_USECRLF or GTL_NUMBYTES
is about a factor 5,000 slower than
Code: [Select]
GTL_PRECISE or GTL_NUMCHARS
Which probably means that the control maintains an internal counter for the latter combination of flags. Good to know if you deal with large files ;)
Title: Re: Making RichEdit work properly on Windows 10
Post by: murrays on April 19, 2017, 09:17:33 AM
Please don't use Windows' riched20.dll. It's only there for compatibility with ancient code. Upgrade to msftedit.dll. It's modern, fast, but doesn't yet support math. Hopefully soon. It did for a while in the Windows 8 beta, but then somebody disabled it  :( The Office riched20.dll is the best version at the moment. RichEdit runs on iOS, Mac, Android, Windows and WinRT. It supports math and now supports LaTeX math input/output as well. My Math in Office blog will have a post on it soon.
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on April 19, 2017, 10:25:46 AM
Welcome to the Forum, Murray :icon14:

I guess I can speak for everybody: We feel honoured to see one of the fathers of Windows here... (The click moment that helped Windows to survive (http://connectingperspectives.com/web/2012/09/04/the-click-moment-that-helped-windows-to-survive/))
Quote
... the professional network of a Microsoft engineer, Dave Weise, was activated at a Friday-night party. He met an old acquaintance, Murray Sargent, a professor at the University of Arizona and an avid programmer. They talked about the Windows 3 technical problems and Sargent suggested a potential solution. They teamed up and started implementing that solution. Some days later, Steve Ballmer, Microsoft’s number two executive, went for a jog with Sargent...

The Office riched20.dll is the best version at the moment.

Indeed, my idiosyncratic editor (http://masm32.com/board/index.php?topic=5314.0) has always used, if available, the Office 11 version, which is fast and stable. Only with the latest, math-enabled version, it uses the Office 12 version if the file to open is in SF_BINARY format. So far I have not been able to find a simple example how to implement the linear format for math, which would allow (?) to save the file in "normal" rtf format. If by any chance you have something in your pockets, I'd be grateful to see it.
Title: Re: Making RichEdit work properly on Windows 10
Post by: guga on April 19, 2017, 12:55:03 PM
Welcome to the forum, Murray.  :t

Great work, indeed.

Since you are updating richedit, may we ask some requests for the next versions ?

a) keeping richedit compatible with all windows versions prior to WinXP.
b) More documentation and examples on the Apis usage. Ex: The math functionality on richedit20 is achieved through msptls.dll that have lots of exports and no documentation about the apis of it.
c) making it be easier to use in other applications, and not only the ones related to Office package.
Title: Re: Making RichEdit work properly on Windows 10
Post by: hutch-- on April 19, 2017, 02:08:55 PM
Hi Murray,

Good to see you here. I have been using rich edit controls since the earliest win9x OS versions for pure ascii plain text and in that context the early versions worked well. With the advent of the later versions (2/3), the extra functionality was very useful with multiple levels of undo/redo and certainly fast enough. For a programming editor that preferable uses fixed pitch fonts it has been an excellent tool for years. With the 32 bit version, the editor I write will run on Win2000 upwards

Using the 64 bit version has been no problems at all in Win10 and they also run fine on Win7 64. I have yet to try the later versions as I don't know much about them or how evenly they are supported in different 64 bit versions of Windows.
Title: Re: Making RichEdit work properly on Windows 10
Post by: TWell on April 19, 2017, 04:38:01 PM
Code: [Select]
msftedit.dll: 11326 ms v 8.5 Windows 10 :(

EDIT: Office riched20.dll after v.12 have problems with reading Word2007RTFSpec9.rtf :(
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on April 19, 2017, 07:32:21 PM
a) keeping richedit compatible with all windows versions prior to WinXP.

I hope you meant "WinXP and later", Guga.

Re documentation, it is OK in general. The problem is slightly different behaviour sometimes. And little bugs :(
Title: Re: Making RichEdit work properly on Windows 10
Post by: guga on April 20, 2017, 12:30:36 AM
Quote
I hope you meant "WinXP and later", Guga.

Oops...Indeed. Sorry :) :bgrin:
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on April 21, 2017, 07:49:27 PM
I've set up a little testbed for the various RichEdit versions, see attachment. Extract everything to a folder on the same drive of your Masm32 installation.

- without arguments, each exe loads \Masm32\examples\exampl01\generic\generic.asm
- drag the source itself (SmallEditor.asc) over the exe to see "normal" rtf
- open or drag SF_BINARY_Good.rmm over the exe to see the behaviour with math and binary format

There are executables for the Office 10, 12, 14 and 15 DLLs.

On my Win7-64 machine,
- Office 11 can't load SF_BINARY format
- Office 12 handles the math correctly (display OK, you can edit the text)
- Office 14 can load the file but the display is garbled (normal RTF is handled correctly)
- Office 15 can load the file and the display is OK, but if you put the cursor behind EndOfCode and hit Return, prepare for trouble (normal RTF is OK)
- Sys32\MsftEdit can't load the math doc (SF_BINARY_Good.rmm), everything else is OK.
 
On my Win10 machine,
- Office 11 can't load SF_BINARY format
- Office 12 handles the math correctly (display OK, you can edit the text)
- Sys32\MsftEdit can load the math doc but the display is minimally garbled, i.e. EndOfCode and How to are in the same line; however, in contrast to Office 15 on Win7, you can edit the text without major problems 8)

Saving is disabled simply because this tests only the loading.

You can use RichMasm (http://masm32.com/board/index.php?topic=5314.0) for math editing, it uses Office12 for the math template (menu File/New Masm source/math) and can save the format. It will warn you if an edit corrupts the file. The procedure is hilarious:
- user types something
- if control is idle for a few seconds, text is EM_STREAMED out to disk
- immediately after, text is EM_STREAMED in to an auxiliary control
- if that control remains empty because the file got corrupted, a MsgBox pops up and invites you to UNDO that edit.

Note that very few formulas corrupt the file. So far, I've found only two - marked in red in the *.rmm file. Both are taken from Murray's own guide (http://unicode.org/notes/tn28/UTN28-PlainTextMath-v2.pdf); all other formulas resp. autocorrect options work just fine.

Enjoy - this is really powerful for adding mathematical formulas to your assembler sources, but be careful - frequent backups please...  8)

Building the source requires MasmBasic of 21 April 17 (http://masm32.com/board/index.php?topic=94.0) - making all DLLs load correctly required some tweaking, but now it works for all of them.
Title: Re: Making RichEdit work properly on Windows 10
Post by: hutch-- on April 21, 2017, 08:18:06 PM
Have you checked to see if the one you want is on the redistributable list ?
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on April 21, 2017, 08:22:59 PM
Have you checked to see if the one you want is on the redistributable list ?

In case you are worried about copyright issues: The exe will tell you that the DLL is not available. Office 11+12 get installed with WordViewer and the compatibility pack, while 14+15 get installed with Office. So you either have them (legally, hopefully), or the testbed will not work for the versions that you don't have...
Title: Re: Making RichEdit work properly on Windows 10
Post by: TWell on April 21, 2017, 09:02:34 PM
MsFtEdit version show text almost correctly in Windows 8.1 and Windows 10 :t

After running that test program, the v.14 don't work any more  ;) So M$ self-destruction works :P
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on April 21, 2017, 09:27:03 PM
After running that test program, the v.14 don't work any more  ;) So M$ self-destruction works :P

Ouch. What exactly happened? I have had no problems so far... the situation is stable as described in reply #13. (http://masm32.com/board/index.php?topic=5383.msg65459#msg65459) The C:\Program Files (x86)\Common Files\microsoft shared\OfficeXX folders are write-protected, too. And the proggies don't write to the registry.
Title: Re: Making RichEdit work properly on Windows 10
Post by: vintech on February 20, 2019, 03:18:12 AM
Hi all,
very interesting topic!  We are currently encountering performance issues with TRichEdit since being upgraded to Windows 10.

The application we are making in written in Delphi, when I check with procexp.exe I can see that the dll that gets loaded is : C:\Windows\SysWOW64\riched20.dll (which is the slow one I guess.  I have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on February 20, 2019, 07:04:14 AM
Good question! Normally, LoadLibrary + GetProcAddress are the right tools to do so, but I have no experience with Delphi. Do you have sample code? A minimum window with the RichEdit control only?
Title: Re: Making RichEdit work properly on Windows 10
Post by: aw27 on February 20, 2019, 08:47:26 AM
https://forums.embarcadero.com/thread.jspa?messageID=771188&tstart=0
Title: Re: Making RichEdit work properly on Windows 10
Post by: TimoVJL on February 20, 2019, 06:00:08 PM
Delphi 3:
riched32.dll
C:\Windows\SysWOW64\riched32.dll
riched20.dll
C:\Windows\SysWOW64\riched20.dll

Test program loads riched20.dll from application dir, also in Windows 10.
Code: [Select]
procedure TForm1.FormCreate(Sender: TObject);
var h : THandle;
        buf: ARRAY[0..256] OF Char;
begin
     h := GetModuleHandle('riched20.dll');
     GetModuleFileName(h, buf, 256);
     RichEdit1.Text := buf;
end;
Title: Re: Making RichEdit work properly on Windows 10
Post by: hutch-- on February 20, 2019, 06:16:07 PM
I do occasionally use RTF in my recent help files and I have little reason to change from the riched 2/3 that I have used for years. The 64 bit version works fine, I have little interest in word processor emulation and no use for any serious maths notation. For plain text mono spaced fonts, these work remarkably well, very fast and with very large capacity.
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on February 20, 2019, 07:00:06 PM
All this is interesting but it doesn't answer the OP's question.

I have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?
Title: Re: Making RichEdit work properly on Windows 10
Post by: aw27 on February 20, 2019, 08:55:44 PM
All this is interesting but it doesn't answer the OP's question.

I have placed the office version of Riched20.dll in the root of my application but it still load the SysWOW64 version.  How can I force (in Delphi) that the dll in the application root directory would be used?

I gave a link to the solution.
You need to edit comctrls.pas unit, modify it to load C:\Windows\System32\MSFTEDIT.DLL, changing the classname reference to RichEdit50W. Then you compile comctrls.pas and drop the compiled unit in the pertinent folders. This may be a delicate operation, all depend on the affected dependencies, so if the user is a full noob, an alternative is copy comctrls.pas to the project folder and modify it for the current project only.
I have done the first option sometime in the past and I am sure there are full instructions somewhere in the internet, but am too lazy to look for them now.

Since richedit will always be a basic el cheapo editor, no matter its version, for serious uses it is recommended to fork a few hundred bucks and purchase TRICHEDIT (http://www.trichedit.com/trichedit.html) . I did it for some private projects and have also used it in a small freeware I have in the website. Amazing.

Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on February 20, 2019, 09:18:20 PM
I gave a link to the solution.
You need to edit comctrls.pas unit, modify it to load C:\Windows\System32\MSFTEDIT.DLL

OP wants to use the Office version, which resides (typically) in C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL (and there are good reasons to load that one).

OP says that despite placing this DLL in the exe's folder, it does not load that one.
Title: Re: Making RichEdit work properly on Windows 10
Post by: TimoVJL on February 20, 2019, 09:46:40 PM
Perhaps it's better to use sysinternals procmon to see if program try to load riched20.dll and if it failed.
Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon)
Title: Re: Making RichEdit work properly on Windows 10
Post by: aw27 on February 20, 2019, 10:25:45 PM
And what about MSPTLS.dll? Is it also in the app folder?
Probably the OP has already found the problem.
Title: Re: Making RichEdit work properly on Windows 10
Post by: jj2007 on February 20, 2019, 10:50:31 PM
And what about MSPTLS.dll?

Good point! The control loads without it, but it leads to crashes further on.