Making RichEdit work properly on Windows 10

[jj2007]

After "upgrading" one of my machine to Windows 10, I discovered a glitch in its handling of the RichEdit control:
When launching RichMasm 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 loads successfully.

This is fixed for RichMasm in the latest MasmBasic release, 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 ("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
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.

[hutch--]

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.

[jj2007]

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

Even the man behind RichEdit complains:

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

[TWell]

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


[jj2007]

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 install as C:\Program Files (x86)\Common Files\microsoft shared\Office1?\RICHED20.DLL (see Oct 2013 thread)

The Office11 folder gets filled by the free Word Viewer (recommended, the best and fastest RichEd20 imho), the Office12 folder by the free Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint File Formats.

[jj2007]

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 ;)

[murrays]

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.

[jj2007]

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)

... 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 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.

[guga]

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.

[hutch--]

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.

[TWell]

Code: [Select]

msftedit.dll: 11326 ms v 8.5 Windows 10 :(

EDIT: Office riched20.dll after v.12 have problems with reading Word2007RTFSpec9.rtf :(

[jj2007]

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 :(

[guga]

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

Oops...Indeed. Sorry :)

[jj2007]

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 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; 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 - making all DLLs load correctly required some tweaking, but now it works for all of them.

[hutch--]

Have you checked to see if the one you want is on the redistributable list ?