Some time ago I wrote here that Metapad has big problems with international characters because of problems in riched20.dll.

Now I have found that the same problems (not only in Metapad) can be solved on Windows XP by using newer versions of riched20.dll. These new versions have some unresolved dependencies in delay-loaded modules but I'm not sure if it is real problem - my short tests found none.

I have prepared package riched20.zip that contains four different versions of riched20.dll

5.30.23.1221 - Windows XP SP2 (this one is present in the uSP 2.1a)
5.30.23.1226 - Windows XP SP2 KB896430
5.40.11.2212 - Office XP SP3
5.50.99.2012 - Office 2003 KB900459

Please test the newer versions (5.40 and 5.50) if they break anything.

Or maybe anybody already did these tests?

In case of success I'd suggest to add the highest functional version into the next uSP.

Petr

Petr, MDGx's RICHED9X.EXE contains a later version of RICHED20.DLL than the SE SP - 5.31.23.1224:



http://www.msfn.org/board/?showtopic=61407

Apologies for using this quote if more recent information/files make it obsolete now. I don't know if MDGx tested the later versions of RICHED20.DLL that are in your package, and he seems pretty busy at the moment, so I'm not sure if he's available to give any further input regarding his testing.

I'll try out the two later versions (in 98 SE) and post back any findings.

Thak you for reminding me that we already discussed this topic.

Version 5.31.23.1224 has the same problem as all known 5.30.x.x versions.

In short, "ě" and "č" letters (maybe more) cause switching to different font for all 5.3x.x.x versions so the problem I'm trying to rectify is specific to some languages only.

But the possible incomaptibility of 5.40 and 5.50 versions would be the same in all language versions I suppose.

I forgot to mention that riched20.dll is language independent so it could be tested in any language Windows version.

Petr

In which exact circumstances do the fonts switch ?

I haven't got any eastern european fonts but I never noticed any problem so far with the special accentuated characters of the western european fonts I am using (french, spanish, german characters etc).

Could you say what are the ASCII codes of those characters that create problems ?

I use riched20.dll 5.31.23.1224 and Riched32.dll 5.0.1461.82.

"č" is E8 (0232) in codepage 1250
"ě" is EC (0236) in codepage 1250

See also http://www.microsoft.com/typography/unicode/1250.gif

I will do some additional tests and let you know.

Petr

They are è and ì here and I have no probs with them on winME.

So this is my test result - very briefly:

I have prepared simple table with all characters with 8th bit set, i.e. code 80 to FF in hex, or 128 to 255 in dec. They can be manually enterd as ALT+0128 to ALT+0255. The table can be downloaded here.

In Notepad, with default fixedsys font in 1250 codepage, everything is correct because it does not use riched20.dll:


In Metapad, with default fixedsys font in 1250 codepage and riched20.dll any version from 5.30.23.1200 to 5.31.23.1224, the display is broken significantly and at least 4 different fonts appear:


With riched20.dll 5.40.11.2212 (from Office XP SP3) everything look good, with exception of character AD (173), soft hyphen, that is not displayed at all. Maybe it is by design.


Surprisingly, riched20.dll version 5.50.99.2012 (from Office 2003) has the problem of 5.3x versions corrected only partially, just accented letters display correctly, but other signs (with code 132, 134, 135, 137, 149, 150, 151, 155, 161, 162, 178, 189, 255) change the font again.

I tried to set font to Courier - Western script and there are also font changes visible:
[Edit: it seems Metapad is too clever and always uses 1250 codepage (Central European) for displaying, even if 1252 (Western) is set. So I have renmoved the screenshot]

So if there will be no incompatibility with other applications, the best choice would be version 5.40.11.2212.

Petr

The sole problem I have here is that the editors using riched20.dll (5.31.23.1224 ) do not display character 173 at all with any font. Otherwise no particular problems with the fixedsys font.





How can I know if I am in 1250 codepage like you ?

Edit : I have just read your post and I will try to find the place where to change codepage.

Edit 2 : MS-DOS codepage 850 in MSConfig. Is that the one ?

Now I tried the same test on Windows 98 English and I have the same result as you - i.e. no problems.

Character 173 (soft hyphen) is displayed just with riched20.dll version 5.0.153.0, not with any newer version.

Codepage 1250 is native to some Windows 9x language versions, it cannot be changed because all system dialogs would become corrupted. Here: http://www.microsoft.com/globaldev/referen...sion.mspx#win98 you can find which language version has which ANSI and OEM codepage. (ANSI codepage is used in Windows and OEM codepage is used in DOS).

Petr

BTW, I see differenet characters (CP1252) on Windows 98 English:



Code Pages Supported by Windows:
Windows Code Pages
OEM Code Pages
ISO Code Pages

Petr

I have tried now all the riched20.dll you have posted and I also have the problem with riched20.dll 5.50.99.2012 but not with any of the others.

I'm still not sure why on your screenshots are displayed characters from 1250 codepage but some of them witout accents. Maybe because your browser has changed the encoding? I have packed the file into zip archive: table2.zip, please let me know if your screenshots are still the same.

Anyway, it looks like 5.40.11.2212 versions has no display problems on all systems, now it is necessary to know if it works well with all possible applications.

Petr

It does not do it with the new table. All the characters are properly accentuated.



I didn't pay too much attention to this because I had my own ASII table test file and everything was OK with it.



http://www.stashbox.org/uploads/1145195740/ASCIITable.txt

Riched20.dll 5.40.11.2212 has a non-existant dependency here, mso.dll. I guess it is a component of MS Office.

What is funny here is that this lower and upper case accentuated Z do not normally display on my computer but Metapad displays them from your file.

The table is the same as the old one but maybe the character set was translated by the browser.

I wanted to have table with more characters per code to see if the font has changed or not.

The dependency to mso.dll is delay-load, maybe it is never used?. Yes, I already mentioned that it is from Office XP SP3.

Current SHLWAPI.DLL 6.00.2800.1740 (xpsp2.050831-1533) has also unresolved dependency to delay-loaded modules APPHELP.DLL (file missing), USERENV.DLL (file missing), OLE32.DLL (CoWaitForMultipleHandles missing), SHELL32.DLL (SHBindToParent missing) and everything seems to be OK.

Petr

Do you mean that all those files are in the 98SE uSP currently ?

I mean SHLWAPI.DLL that is a part of the April 2006 Security update IE6.0sp1-KB912812-Windows-98-ME-x86-ENU.exe. uSP is not resolving these dependencies.

Petr

Right but what about the other ones ?

Now I'm not sure what do you mean.

SHLWAPI.DLL was just an example of a DLL with unresolved delay-load dependencies, officialy made by Microsoft for Windows 98. I expressed my hope that also RICHED20.DLL with unresolved delay-load dependency could work.

Petr

Using RICHED20.DLL build 5.40.11.22.12, I have the same Metapad result as you did Petr when you tried viewing your table in Windows 98 English (98 SE English here). So, "ě" and "č" don't appear for me in TABLE2.TXT.

I just wondered what those files were current for.

USERENV.DLL and APPHELP.DLL don't exist on my system and OLE32.DLL is 4.71.3328.0, SHELL32.DLL is 5.50.4134.100 and they have no unresolved dependencies. I have WinME + IE5.5 SP2.

Yes, these characters don't exist in 1252 codepage used in English, Brazilian, Danish, Dutch, Finnish, French, German, Italian, Norwegian, Portuguese, Spanish and Swedish versions of Windows 98.

1250 codepage is used in Czech, Hungarian, Polish, Slovak and Slovenian versions of Windows 98.
1251 codepage is used in Russian version.
1253 codepage is used in Greek version.
1254 codepage is used in Turkish version.
1255 codepage is used in Hebrew version.
1256 codepage is used in Arabic version.

Apparently the probems with font switching do not occur with riched20.dll version 5.30 and 5.31 on systems with 1252 codepage.

They occur in systems with 1250 codepage and riched20.dll version 5.40.11.2212 sems to be the only one that works correctly.

I have not tested any other Windows version although I have them in my MSDN library, maybe some time.

Petr

OK, it seems I have not expressed clearly enough.

SHWLAPI.DLL from IE 6.0 SP1, all versions from 6.00.2800.1106 to 6.00.2800.1740, have four unresolved dependencies to delay-loaded modules:
APPHELP.DLL (file missing),
USERENV.DLL (file missing),
OLE32.DLL (CoWaitForMultipleHandles function missing),
SHELL32.DLL (SHBindToParent function missing)

So although Dependency Walker shows them, IE 6.0 SP1 has no problem with them and other applications too.

Therefore I guessed it might be possible that delay-load dependency to mso.dll in riched20.dll version 5.40.11.2212 will cause no problem too.

Latest SHLWAPI.DLL for IE5.5 SP2 seems to be 5.50.4957.200 and has no unresolved dependencies.

Petr

Understood you know. Sorry about that. I am a bit dumb sometimes.

Petr,

I've also done some tests with different versions of RICHED20.DLL [I've used among others the newer 5.40.11.2218 from KB872798 you sent recently], and looks like on my computer [Win98 SE, WinME + WinXP SP2] RICHED20.DLL 5.40.11.2218 displays best most code page characters.
Therefore I updated RICHED9X.EXE + RICHEDNT.EXE to include RICHED20.DLL 5.40.11.2218:
http://www.mdgx.com/add.htm#RTF

* Microsoft Windows 9x/NT4/ME Malformed Word Rich Text (RTF) Edit Controls RICHED20.DLL 5.40.11.2218, RICHED32.DLL 5.0.1461.82 + USP10.DLL 1.0422.3790.1830 Security Vulnerability Fix (English):
http://support.microsoft.com/?id=249973
- Unofficial Windows 95/98/ME Fix [841 KB]:
http://www.mdgx.com/files/RICHED9X.EXE
- Unofficial Windows NT 4.0 Fix [723 KB]:
http://www.mdgx.com/files/RICHEDNT.EXE
______________________________________________

erpdude8:
RICHED9X + RICHEDNT copy their files into %windir%\system(32) without any nagging dialogs/prompts, and even newer versions are overwritten with the ones from these updates.
Same goes for the new OLEUP update:
http://www.mdgx.com/files/OLEUP.EXE
posted here:
http://www.mdgx.com/add.htm#OLE
which now installs newer OLE files 2.40.4528: older OLEAUT32.DLL 2.40.4522 [the only 1 that works properly with 9x OSes] is kept this way, even if some people installed newer [but buggy] OLEAUT32.DLL versions.

All these updates [and more] posted here 5-3-2006:
http://www.msfn.org/board/?showtopic=46581

Hope this helps.

um, I will have to check to see if Riched20.dll v5.4 would work under a Win95 [Yes, a Windows 95] machine. V5.4 of RICHED20.DLL is from Office XP and Office XP is not compatible with Win95 (last version of MS Office supported under Win95 is Office 2000). I'll let everyone know if RICHED20.DLL Ver. 5.40.11.2218 works okay under Win95.

SHWLAPI.DLL from IE 6.0 SP1, all versions from 6.00.2800.1106 to 6.00.2800.1740, have four unresolved dependencies to delay-loaded modules:
APPHELP.DLL (file missing),
USERENV.DLL (file missing),
OLE32.DLL (CoWaitForMultipleHandles function missing),
SHELL32.DLL (SHBindToParent function missing)

How do we resolve these dependencies?

APPHELP.DLL + USERENV.DLL are present [sometimes] only on NTx OSes, which means MS developers made those files using the same NTx models [sloppy programming ].
The other 2 dependencies are not important [they load as delay-load], and are probably both present only on NTx OSes.
You can remove those unresolved APIs by modding SHWLAPI.DLL in a hex editor, but does not matter, it does function properly as is.

Same goes for other DLL and eventually OCX files developed for 9x OSes [mostly for MS IE + WMP = the only updates MS is still releasing until July 11 2006], but using NTx models.

EOL + EOS for 98 + ME:
http://www.microsoft.com/windows/support/endofsupport.mspx

Hope this helps.

SHLWAPI.DLL v6.00 from IE6 can work for both 9x and NT-based Windows OSes. some functions will be available for certain versions of Windows, others will not.

BTW - Still testing v5.4 of RICHED20.DLL file under a Win95 machine. I'll post up the results in a few days.

so far, riched20.dll version 5.4 works okay under Win95.

Gape, please include RICHED20.DLL version 5.4 in the next version of the 98SE Service Pack 2.x. It's stable enough to be used on all 9x versions of Windows.

What exactly can the Rich Edit Control do anyway?
http://www.chami.com/tips/delphi/013097D.html

HTH

version 5.3 of the riched20.dll file is also bundled in the Windows Installer 2.0 packages. so I guess MSI 2.0 uses the riched20.dll file.

Microsoft Office programs like MS Word & MS Outlook also use the riched20.dll file. If you can't start these programs because of a bad or corrupted riched20.dll file, replace that DLL file with a clean one.

I've been using 5.50.30.2002 for a while in Win98SE and had no problems with it.

Please check the colors of the links in the other older versions. AFAIK, there was an issue with that and it's been fixed only in some of the latest builds. The link color on black (dark) background should become white automatically.

Richedit 5 has the same font switching problem as Richedit 3 and 3.1, only Richedit 4 works fine.

Something was corrected in version 5.50.99.2012 (rom KB900459) but still it is not OK.

Petr

As Drugwash reported here @ Dec 12 2006, 12:58 PM RichEdit 4.0 riched20.dll (5.40.11.2218) has problem with somer applications, like eMule (not clickable link) or Miranda IM spellchecker (spelling errors not underlined).

I don't know how to use Miranda IM but I have installed eMule and the link is really not clickable with riched20.dll 5.40.11.2218.

Both Miranda IM and eMule are open source but I'm not a programmer so I cannot guess if the code can be modified to work with all riched20.dll versions.

It is not an issue for Windows language version that use US-ASCII 1252 codepage but for other language versions it is real problem, there are many applications that exhibit unwanted font switching with RichEdit 3.0 and RichEdit 4.0 is solution for this problem.

Exactly the same situation is on all operating systems till Windows XP and Vista.

It is possible to place the right version of riched20.dll to the application folder and so far it seems to be the only possible solution.

Maybe somebody could be able to patch RichEdit 3.0 riched20.dll to correct the font switching bug?

Petr

Irony or mistake?

You may guess... Corrected.

Petr

Here are some screenshots for the tests in Miranda IM. They are self-explanatory. The options on the settings page were exactly the same for both tests. First test was run with riched20.dll v5.30 installed in %system%, while for the second test I just dropped riched20.dll v5.40 in Miranda's main folder.

Microsoft has just released the MS07-013 RICHED20.DLL security updates:
http://www.microsoft.com/technet/security/...n/ms07-013.mspx

updated riched20.dll file for RichEdit 3.x is now 5.30.23.1227 (if using Office 2000 or Windows 2000; the WinXP edition of MS07-013 has riched20.dll version 5.30.23.1228 while the Win2003 edition has riched20.dll versions 5.30.23.1224 and 5.30.23.1226)
updated riched20.dll file for RichEdit 4.0 is now 5.40.11.2220
updated riched20.dll file for Richedit 5.0 is now 5.50.99.2014

Posted new RICHED20.DLL updates:

* Microsoft Windows 9x/NT4/ME Malformed Word Rich Text (RTF) Edit Controls RICHED20.DLL 5.40.11.2220, RICHED32.DLL 5.0.1461.82 + USP10.DLL 1.0422.3790.2706 Security Vulnerability Fix (English):
- Unofficial Windows 95/98/ME RTF Fix [911 KB]:
http://www.mdgx.com/files/RICHED9X.EXE
- Unofficial Windows NT 4.0 RTF Fix [795 KB]:
http://www.mdgx.com/files/RICHEDNT.EXE

HTH

There is no change in 5.40.11.2220 in respect to the problems posted by me above.

I couldn't test 5.50.99.2214 as I have no compatible product installed and I couldn't extract the needed file from the patch, but I suspect, that one wouldn't make any difference either.