Making RichEdit work properly on Windows 10

[greenozon]

I filed a bug report (kind of) at Microsoft

Very interesting reading indeed!
Looks very much like you are talking wtih MS GPT3 dumb robot :)

[jj2007]

Office and System32 versions of RichEd20.dll have no problem in selecting the ranges of text. Even the System32\MsftEdit.dll version can select the second text, but now it's the first one that displays this behaviour.

It's clearly a bug in MsftEdit.dll, and apparently it has been fixed in Windows 10, but that doesn't help those who are still coding for Windows 7 clients.

Update: Yes, this bug has been fixed in Windows 10, but the price to pay is a msftedit.dll version that is roughly a factor 3 slower for loading big files - see Beta testers please.

[jj2007]

Attached a testbed demonstrating that the EN_LINK notification is broken in the Windows 10 version of msftedit.dll

Extract all files to a folder and launch the exe (it's pure Masm32 SDK code, no MasmBasic involved).

You will see two RichEdit controls side by side. One uses the Win7 msftedit, renamed to msftedjj.dll, the other one the standard Windows System32 version.

When hovering over the links, cpMin is shown above the controls. It's different.

Source attached.

[jj2007]

Below three versions of the RichEdit control for comparison, to be run on Windows 10 (or Win11 - any volunteers?).

The attached program (with source; plain Masm32 SDK) loads the same identical rtf file into three controls created with
a) C:\Windows\System32\msftedit.dll
b) same but dll stolen from Windows 7 (minimally modified; PM me for details)
c) C:\Program Files (x86)\Common Files\Microsoft shared\Office12\RICHED20.DLL

- for all three controls, it sets the EN_LINK style for the range 555...666 and 777...888
- the link style is set automatically for the examples links
- note the extra spacing introduced only by the Win10 msftedit
- note the different "automatic" ranges selected only by the Win7 msftedit; they are one off per link
- note the selected text ranges: tText... for Win10+Office12, extText for Win7

The msftedit-based control on Win XP (not shown here) behaves exactly like the Win7 version. It is therefore likely that Microsoft, in the process of fixing the EM_EXSETSEL bug for Win10, introduced a new bug.

[hutch--]

I guess it depends on you reason for choosing later rich edit versions. I have been using richedit 2 and 3 since the XP days because they are at least consistent. They definitey do have their own bugs but with enough practice, you can work around them. It depends on what your target is, if you want word processing, spreadsheet functionality and other additions, apparently the later versions can do this but the earlier rich edit versions do plain text very well and RTF with no problems.

With the earlier versions, you don't have to look for better versions in Word or whatever else, software written for the earlier versions work from XP upwards (I forget how Win 2000 worked).

[jj2007]

With the earlier versions, you don't have to look for better versions in Word or whatever else

For about 10 years, I used the Office11 and Office12 versions; now I switched to sys32\msftedit because a) it's the officially recommended one, b) everybody has it, from XP onwards, and c) it goes beyond Sys32\RichEd20.dll in several aspects, such as Unicode and speed.

My main reason for switching, though, is speed. When you have sources in the megabyte range, it takes ages to load them with Sys32\RichEd30.dll; the Win7 version of msftedit.dll is a factor 20 or so faster.

Microsoft's handling of this control is not professional.

[hutch--]

I gather that your main usage is RTF which is always slower than plain text due to its size and complexity.

[jj2007]

One more fat RichEdit bug in Windows 7 (signalled by Limitless Technology):

An application that uses the RichTextBox control cannot display an .rtf file correctly in Windows 7 or in Windows Server 2008 R2

To create a sample test file, paste the following lines in Notepad, and then save the file as an .rtf file.

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}
{\f43\froman\fcharset163\fprq2{\*\panose 00000000000000000000}Times New Roman CYR (Vietnamese{\*\falt Times New Roman};}
}
{\*\generator Msftedit 5.41.15.1515;}\viewkind4\uc1\pard\f0\fs20 hello there... this is a sample document\par
\par
}

The Micros*t page continues to say: A supported hotfix is available from Microsoft. If one of you is able to find that hotfix, I owe you a beer or two.

I attach the test file. It should display the string "hello there... this is a sample document", and does so in MS Word but not in WordPad or RichMasm on Windows 7.

[jj2007]

RichMasm of 2 February 2024 (included here) takes care of one more exotic bug:

When selecting a range of text where the start is in visible text but the end is inside a hidden text range, the control ignores the start value and sets start and end to the same value inside the hidden text.

With RichMasm, if that happens (a rare event), a MsgBox pops up to instruct the user how to deal with it.

There is one bug for which I can't give an official fix (PM me if you need one): Certain big rtf files (over 2MB) don't get loaded at all with the Win10 version of System32\msftedit.dll - the control just hangs, keeping its cpu core busy.

Shame on you, Microsoft, that you can't produce a RichEdit control that simply works as it should. Murray Sargent, responsible for the control in the last decades, loves talking about exotic features but is apparently not interested/not willing/not able to fix its serious bugs. Given the overwhelming importance of a control that is able to display more than plain text, and the fact that Windows has arrived at several Gigabytes of bloated code, this is a shame for the whole software industry.

[jj2007]

One more bug in the Win10 System32\msftedit.dll: abnormal character spacing for the system font (other fonts are not affected).

[TimoVJL]

Normal MS cripled code.
This was a culprit.

Code Select Expand

CYR (Vietnamese

[jj2007]

Another goodie, quoting M$ Learn EM_STREAMOUT:

SF_USECODEPAGE
Rich Edit 3.0 and later: Generates UTF-8 RTF and text using other code pages. The code page is set in the high word of wParam. For example, for UTF-8 RTF, set wParam to (CP_UTF8 << 16) | SF_USECODEPAGE | SF_RTF.

So performing the streamout with...

Code Select Expand

SF_UTF8=CP_UTF8 shl 16 or SF_USECODEPAGE or SF_RTF... writes indeed a lot of rtf code to the file.

Instead of the usual {\rtf1\, the file starts with {\urtf1\

Congrats, Micro$oft! You have made it possible to save text to Utf8 Rtf format.

Now the next step might be to convince your popular Windows applications Notepad, WordPad and MS Word that this new innovative format is not plain text (see image below) but rather a variant of the Rich Text Format

P.S.: Micros*t suggests to "reinstall the application"