Skip to content

Latest commit

 

History

History
19 lines (14 loc) · 6.42 KB

Cross-platform notes.md

File metadata and controls

19 lines (14 loc) · 6.42 KB

Cross-platform notes

To make AngelLoader cross-platform ready, the following things would need to be accounted for:

The main blockers are:

  • It's written for .NET Framework and Wine has generally poor support for newer versions (we require 4.7.2). This precludes the easiest option of doing literally nothing and just using Wine to run it.
  • It's written for .NET Framework rather than .NET Core. It's trivial to switch between them, but .NET Core measures (with both a profiler and also with the naked eyes) catastrophically slower: 2x-10x, and with a MASSIVE and perceptible startup delay, with the main window taking ten times longer (~400ms) to initialize. So, it works, but startup is glacial and I seem to be the only one in the entire world who's noticed(?!). Everyone else is raving on and on about how fast .NET Core 3+ supposedly is. Weird.
  • It's using the Windows-specific Windows Forms (WinForms) UI framework. We use this because a) we need the RichTextBox control in order to display .rtf files which is one of the main features of AngelLoader, and b) we need the fast "virtual mode" DataGridView that WinForms provides. WPF also provides a RichTextBox control, but its DataGridView does not have a proper "virtual mode" like WinForms' does, meaning it gets extremely slow with even a moderate number of rows. (WPF's DataGridView does have something called "virtual mode" but it's not the same thing and does nothing to improve performance.)
  • We need to display .rtf files in-app. A massive number of FMs have .rtf readmes and new ones continue to be released with them. From the FM authors' perspective, .rtf files make for an easy way to have nice-looking readmes, no muss no fuss. Unfortunately, .rtf files are not widely supported outside of Windows. In fact, even within Windows, support is notoriously incomplete and changes from version to version of the built-in RichEdit control. Just take a look at AngelLoader's RichTextBoxCustom section to see the insanity required to handle it all. And FMs' .rtf readmes were all designed and tested to be displayed in the Windows RichEdit control, with all its quirks and failings. This is by far the biggest showstopper of all: Other than Mono, I'm not aware of any cross-platform UI framework that can display .rtf files natively. Qt has a "rich text" box, but unfortunately it merely means "text that is rich" (in other words, HTML or an HTML-like subset), and not the Microsoft Rich Text Format (.rtf). Mono may be a possibility. I decided I didn't want to use it at some point in the past and I can't remember why. Meh.
  • The FM scanner also uses the WinForms RichTextBox for the purpose of converting .rtf files to plaintext. We need to scan readmes for many pieces of data (title, author, release date, etc.) and .rtf files must be converted to plaintext before doing so, as they're full of masses of markup and insanity that makes it impossible to extract anything useful out of them with a mere line-by-line scanner. This is not as large of a blocker as the above, because there exist rtf-to-plaintext converters out there, or we could maybe even write our own. We have a custom RTF-to-plaintext converter now that doesn't use RichTextBox and is cross-platform ready.
  • The issue of file paths and Wine vs. non-Wine. Normally for a cross-platform conversion we would just go through the code and remove any Windows-centric assumptions. However, in this case, there are several places where we'll need to specifically continue to use Windows-style paths (ie. anything that will be read by the games, such as cam_mod.ini). One possible hitch I can think of right off the top of my head is that we need to put a full path to AngelLoader_Stub.dll into cam_mod.ini, and that path points into the AngelLoader install directory (ie. "C:\AngelLoader\AngelLoader_Stub.dll"). That means AngelLoader, or at the very least the stub file, is going to have be installed in a directory that maps to a Wine Windows-style path so that the games can find it. It also means the stub file must still be a Windows .dll file so the game can load it. We also need to "read the registry" (Wine must surely provide that, but can we access it from a native Linux app?) to find out the location of Thief 3 Sneaky Uprade's SneakyOptions.ini file. This sounds like a headache to me, having to tell users to put AL somewhere in the Wine filesystem, and have it awkwardly straddle two platforms. One option would be to keep it Windows-native but switch to C++ and Qt. That way, Wine could run it and it would just slot right into the Wine ecosystem along with everything else. Otherwise, we would have a Linux-native main app that still needs to interface with the Wine world, and then a Windows .dll that comes with the main app that needs to be placed in the Wine ecosystem which pretty much means the main app does too even though it isn't actually running on Wine...

RTF format

If we use Qt, we're going to have to be able to convert .rtf files to Qt-supported "HTML 4 subset" markup. I'm not aware of any free or open-source RTF-to-HTML converters, although there exist proprietary web-based ones for example. But they're useless to us unless we can legally and practically link them with AngelLoader. The only real option that I can see would be to write our own parser, which I've never done before. There do exist examples of such online, but support is inevitably less complete than the already interminably incomplete Windows RichEdit control. Or maybe I could just pilfer the code from Mono's WinForms implementation. That could at least make for a valuable reference, because they will almost certainly be as accurate and quirk-compatible as possible with the closed-source Windows RichEdit control.

So basically our requirements here are:

  • The ability to display .rtf files on platforms other than Windows.
  • Near-as-possible behavior compliance with the Windows RichEdit control, rather than compliance with the .rtf spec. FM readmes weren't designed to the spec, they were designed to the loaders (DarkLoader, NewDarkLoader, AngelLoader) which all use the crappy half-baked RichEdit control. However, if we can support more of the spec - or support the spec more correctly - and NOT break any FMs' readmes, we should of course do that. I'm thinking of An Enigmatic Treasure With A Recondite Discovery's readme, which looks incorrect in loaders but correct in Microsoft Word. If we can support that correctly and not break anything else, it would be a nice bonus.