Wine: When using winetricks' msftedit, passing text with certain characters to the RichTextBox causes an uncatchable SEHException

[FenPhoenix]

Yeah, I was testing manually setting encoding, and I set Alcazar's readme.txt to "Unicode (1200)" (that would be UTF-16). That's supposed to simply result in visual garbage, but instead it caused a SEHException, uncatchable.

I did the crazy-ass thing where you tell it to catch it anyway, and the log was:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.RichTextBox.WndProc(Message& m)
   at AngelLoader.Forms.CustomControls.RichTextBoxCustom.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd, Int32 msg, Int32 wParam, Int32 lParam)
   at System.Windows.Forms.RichTextBox.UpdateMaxLength()
   at System.Windows.Forms.RichTextBox.StreamIn(Stream data, Int32 flags)
   at System.Windows.Forms.RichTextBox.StreamIn(String str, Int32 flags)
   at System.Windows.Forms.RichTextBox.set_Text(String value)
   at AngelLoader.Forms.CustomControls.RichTextBoxCustom.ChangeEncoding(Encoding encoding, Boolean suspendResume)

I don't see wtf sending EM_EXLIMITTEXT (what UpdateMaxLength does) would have to do with anything. Apparently it's crashing on that message though, but only when the text contains certain characters. winetricks' msftedit is apparently from like Windows 7 for some reason, so it's older and maybe it doesn't support Unicode 5.1+, but to just CRASH on an unknown Unicode char though?!

The char in question was 0x0D3D, "Malayalam Sign Avagraha" (https://www.compart.com/en/unicode/U+0D3D). There may be (must be, I guess) others, but I don't have all year to take like 2 and a half minutes each to test every single character under the sun.

This issue could potentially be really bad. Assuming the charset detector is accurate and there are no triggering characters in legitimate text, then it won't ever cause a problem in normal use. If the user manually chooses a wrong encoding (like "Unicode (1200)" for a UTF-8 file), they could possibly get a crash, but the new encoding selection won't be saved, so an app restart will fix it. However, if the charset detector is not guessing accurately and the text ends up with triggering chars, or if they're there legitimately, then we have a VERY BAD situation, which is that the user will not ever be able to select that FM because it will just crash when trying to load the readme.

This problem doesn't seem to occur on the wine-mono RichTextBox, but then wine-mono RichTextBox is complete crap-garbage that doesn't even show images.

So... yeah, till I can figure something out, this is a bit of a show-stopper. At the very least I won't really be able to tell people to use winetricks' msftedit till I can get something worked out.

[FenPhoenix]

Welp, it's also crashing on 0x300 (Combining Grave Accent) which has been in the spec since 1993. Sure why the hell not. Testing continues.

[FenPhoenix]

So yeah, it just crashes on whatever random characters it feels like, and I can't automate testing either because it still throws an error dialog even when I set it to let me catch the exception. So... yeah. It's either stick with the default wine-mono rich text box, which doesn't show images, or use the better native Microsoft one but then you might get a crash if the encoding is weird.

If we wanted to keep the native Microsoft rich text box, I'd either... have to just ignore anything non-ASCII or otherwise just not detect encoding and let the mojibake exist like in the early days, or else laboriously find all the bad characters and then replace them all with '?' or some junk, which is not much better and not really feasible. This really, really stings.

[FenPhoenix]

Tried loading the offending character as rtf, but no dice - still the same problem!

[FenPhoenix]

My best wild-ass guess is that this is a font problem, that perhaps msftedit is expecting certain fonts to always exist and can't find them. This is because trying to display the offending character on other controls just shows up the same square unknown character box crap that the pin icon originally did. However, I've copied all my Windows fonts into wine's windows\fonts folder like the site said to, but that doesn't work, because of course it doesn't, because every time someone breezily and confidently says something works on the internet it turns out to just be completely false and it doesn't.

I also tried installing every single font explicitly in winetricks even though I already did "allfonts" before, and yeah some of them remain unchecked after the install still, again with no explanation why. Not that that would have helped probably, the native msftedit probably wants native Windows fonts, but the official site is just a blatant liar and says you can throw fonts in there BUT THEY'RE OBVIOUSLY NOT BEING FOUND. Is any Linux information accurate?!!??!!?

[FenPhoenix]

And now, after setting the font fallbacks in the registry and then un-setting them again, Wine fonts are now permafucked as if I had NOT, in fact, set the registry back to how it was.

Yep. Sure. Why not.

[FenPhoenix]

I'm furious. This is just unacceptable. Crashing on Unicode, or fonts, or whatever the hell is wrong here, is completely unacceptable. I don't care what the excuse is, "oh, that's a Microsoft dll, not our problem" or "reverse engineering is hard" or whatever the hell else you might care to think of. I don't care. I have users trying to read rich text files with images and non-ASCII text a lot of the time. On Windows they can do this. On Wine they either can't see the images or they crash unrecoverably on non-ASCII text. This is not an acceptable user experience and I don't care what the excuse is. My users can't do what they need to do. Windows, for all its increasing number of faults, at least works. Windows gets the basics right. Yes, the house of Windows has spy cameras in every room and ads on every wall, but when the house of Linux is four sticks with a concrete slab on top that's always falling on you and you have to take ten years of wizard school to learn the arcane incantations for it to even let you open the kitchen cupboard, then you have to choose the house with spy cameras and ads and where you trip over boxes saying "AI" on them. Because at least it has walls and a floor and it's structurally solid, and its cupboards open by you pulling on the #$@$@ handle. That's why people stay on Windows, it's not because they like all the BS, it's because it's the only OS that gets the #$#@$@#$@ basics right.

[FenPhoenix]

I seriously can't believe this. Handling Unicode without crashing is basic, basic shit. But I suppose when after 32 years of existing Wine still can't even draw a circle correctly without pulling in the native Microsoft dll, all bets are off.

This is why I've traditionally just curtly dismissed Wine users with a "sorry, not supported", because what the hell can I do?! If more and more taffers start using Wine, what happens when someone inevitably reports "this non-English language isn't displaying text right" and there's nothing I can do? People gonna blame me or what? People should not be promoting Wine as being something it's not. As far as my experience with it goes, it's a marginal solution at best, that might let an app get its job done, sometimes, if you don't fiddle the options or look at it too askance. It's certainly not something I'd use to try to get real work done, that's for sure.

I'm not even sure if I'm setting a good precedent with all these Wine fixes. Now people are going to get the impression the Wine bugs are my fault, and that a given Wine bug is fixable by me.

Just use Windows. Please just use Windows. It's so much better of a tradeoff. Just throw on ShutUp10+ and an update blocker. Please, please, please just use Windows, and marvel at the revelation of shit actually working.

[FenPhoenix]

My guess is that the font glyph problem and the rtf crash problem are the same. I'm guessing that the msftedit control is finding itself unable to render the character, but instead of substituting in an unknown-character glyph, it explodes and crashes. Possibly because it can't find a fallback font or whatever, but yeah.

I've looked up wine and fonts, and it might have to do with font fallback, or installing MS fonts (not sure if dumping them in the wine/drive_c/windows/fonts folder counts as them being "properly installed", the official Wine page says it does, but who knows), or even possibly locales maybe, although those seem to be on the Linux side so I don't even really know wtf about that, but I couldn't edit the locales.whatever file like the article said, protected file no doubt and Linux has actual security so yeah.

This is seriously demoralizing even just to think about. I wanna forget about it for a while.

[eskay993]

I think I found a fix if this is the same issue.

I noticed that msftedit downgrades the version of certain dll's since it uses an old installer to grab the files (a Windows 4.5 exe which believe is NT 4.0 / 98 era). Same when you do winetricks msftedit.

Here is my testing:

• Use this attached RTF test doc with dark bg, smiley faces and the Malaysian character mentioned (I used Code 2000 font).

• Create a new prefix by launching AL. No crash, bg is white and characters are squares since correct font not installed.

• Copy Code 2000 font to prefix Fonts folder and now launch AL. No crash and fonts look good. Still white bg.

• Install msftedit with winetricks - launch AL and crash with:

wine: Unimplemented function msls31.dll.LssbFDonePresSubline called at address 00006FFFFF3DD127 (thread 0024), starting debugger

test-unicode.zip

So I copied msls31.dll from my Windows 11 install into the AL folder and did a dll overwide and no crash. It worked. Fonts rendered plus all the other fixes that come with mfstedit. I haven't tested with a txt file.

Looking into msls31, it is specifically related to Unicode support, so it makes sense that this is the culprit. It ships with IE, so I installed ie8 using winetricks after installing msftedit and it worked! ie8 updates the dll.

I know you want a break from this,. but let me know if this works for you when you get a chance.

Ideally winetricks should use a newer version, or at least give an option for a newer version, and they can easily (I think) use a newer one directly from MS. I might raise an issue on their github about it.

Just use Windows. Please just use Windows. It's so much better of a tradeoff. Just throw on ShutUp10+ and an update blocker. Please, please, please just use Windows, and marvel at the revelation of shit actually working.

Ha.. sorry this has stressed you out so much. I didn't mean to open a can of worms and you have gone above an beyond what others have done to get support for wine. The thing to remember, no one using Linux is expecting a perfect 1-2-1 experience. It's completely different platform and the fact that is works 90% is great.

Also shit actually working... but at what cost. 🤔🙃

[eskay993]

Slight correction:

Looks like the order of installing things doesn't matter. winetricks msftedit is a actually installing the Win 7 SP1 version of msftedit.dll, which is fine, and it doesn't touch msls31.dll. Wine seems to ship with a version of msls31.dll which clashes with msftedit.dll from winetricks.

winetricks msls31 installs a really old version of the dll and doesn't fix things.

winetricsk ie8 installs an updated version of msls31.dll.

So installing everything in any order is fine. For those terminal inclined, the command would be:

winetricks -q gdiplus msftedit ie8

Ideally, this should just be winetricks -q gdiplus msftedit msls31 but hey.. installing ie8 works.

[eskay993]

I'm furious. This is just unacceptable. Crashing on Unicode, or fonts, or whatever the hell is wrong here, is completely unacceptable. I don't care what the excuse is, "oh, that's a Microsoft dll, not our problem" or "reverse engineering is hard" or whatever the hell else you might care to think of. I don't care. I have users trying to read rich text files with images and non-ASCII text a lot of the time. On Windows they can do this. On Wine they either can't see the images or they crash unrecoverably on non-ASCII text. This is not an acceptable user experience and I don't care what the excuse is. My users can't do what they need to do. Windows, for all its increasing number of faults, at least works. Windows gets the basics right. Yes, the house of Windows has spy cameras in every room and ads on every wall, but when the house of Linux is four sticks with a concrete slab on top that's always falling on you and you have to take ten years of wizard school to learn the arcane incantations for it to even let you open the kitchen cupboard, then you have to choose the house with spy cameras and ads and where you trip over boxes saying "AI" on them. Because at least it has walls and a floor and it's structurally solid, and its cupboards open by you pulling on the #$@$@ handle. That's why people stay on Windows, it's not because they like all the BS, it's because it's the only OS that gets the #$#@$@#$@ basics right.

And sorry I missed this comment but I have to reply to it. I think this is an unreasonable position. These are Windows apps running on a completely different platform. This is like getting angry that Mac apps don't run in Windows so everyone should just use Mac because it just works. It's a minor miracle and literal decades in the making to get us to the stage where we just "expect" Windows apps to run on Linux (a completely different platform remember!).

You are under no obligation to make it work, and it's perfectly reasonable to tell your users sorry Linux is an unsupported platform, but here are some things you can try. Literally no one will think anything of it (apart from the extremely entitled but who cares about them).

I would recommend taking a step back, contextualizing what Wine is and would and wouldn't be expected of you as the dev to support and approach this with a fresh mindset. Attacking Linux users (not just in this comment but in others as well) it not the way.

[FenPhoenix]

Thanks so much for the detective work. I never got that error message when crashing, it was just a generic "SEHException" and then a stacktrace involving a bunch of WndProc() calls and such.

Okay, I'll try this all out later. Like I said, I need a break.