Interest in a port?

[jrhorn424]

Saw Dave’s post today about his desire to port to Linux. I do not know C or C++, but would be happy to help in the event a port is feasible in Ruby, Node, or Python. My experience is in web development, but I understand UI frameworks for Ruby and Python are full-featured.

If a port to the web is possible, that would make it cross-platform and maintainable for quite a while.

I have not used Frontier, I do not know the full feature set, nor the architecture. I do agree with the value of making it easier for the average user to customize their software.

I’d like to talk about ways I can help.

[scripting]

I appreciate the interest, but porting it to a different language virtually guarantees it's not compatible with what we've been using for almost 30 years now. (amazing). it really has to be C.

one of these years i'll stop fucking around and do it myself, but i was hoping other people would do this, so it would have a future that doesn't depend on me. there's already too much of that.

[rhempel]

Round figures - how big is the code base in files and lines of code? I know Frontier ran on OSX (I was a paying user).

What do you see as the main portability pain points? My guess is the drawing library that does the outliner UI and the filesystem access (unless it’s POSIX) compliant stdio based. Also networking - is that based on BSD sockets?

[jsavin]

There are around 700 c source files totaling about 300k lines of code. I'm reaching back into my long-term memory here -- challenges will at least include the things rhempel mentioned:

• Filesystem access is not POSIX, and is forked between the macOS and Windows versions, each of which call into native OS SDKs.
• Networking is similar, and was one of the challenges moving forward on macOS especially, since the original code was based on OpenTransport which was deprecated by Apple quite a while back. That was addressed in the open source release of the OPML editor IIRC, by moving to a supported SDK.
• Code assumes 32-bit, and this may cause some issues with both the script runtime and database operations (both in memory and on disk). If the internals and database storage can be made to work natively with 64-bit alignment then there may been to be a migration path implemented in order to port legacy object databases to a 64-bit storage format.
• UI is probably the biggest challenge since on both macOS and Windows it uses very old SDKs. The major things that would need to work are (at least): table views, outline views, the WPText editor (rich text), menu system, and various dialog boxes.

I'm sure there's more that I'm missing.

[jsavin]

One other thing: It may be possible in the long run to make it so that the runtime and database run in C and build UI using web tech. A project I was on a few years ago took this approach to building a new user interface on a large, old C-based legacy system, and we used WebAssembly to implement a bridge layer that communicated between the frontend JavaScript runtime (running in Electron) and the legacy backend C code. We were also able to run some legacy UI directly in the browser layer using WebAssembly, although I probably wouldn't attempt to port the legacy Frontier UI to run this way.

[tedchoward]

@jsavin has it right.

I've done some work to make the data structure alignment work on a 64-bit architecture. The reason the Mac build is stuck at 32-bits is because of Carbon dependencies (and libpaige for wp-text).

A lot of the Mac I/O layer is based on posix now.

To build a Linux port, I wo up of concentrate on the db and language. That code should be able to be "ported". And then I'd build a new UI based on Gtk (probably).

[scripting]

I've done major ports in my day. I took ThinkTank from the Apple II to the IBM PC, for example, in the 80s.

I thought it was going to be a slog, but it wasn't.

The hardest part, as you guys are thinking, was the screen and keyboard, the stuff the user interacts with.

But even back then, before Frontier, I was layering my code, so that only the lowest levels needed to be changed.

The port didn't take nearly as long as I thought it would. And the app ran so much better on the PC than it did on the Apple II.

And Frontier is layered that way too, btw.

Okay -- so now to the pragmatic.

How come no one has talked about WINE?

I've heard it said that it does a semblance of running Frontier on Linux right now!

Why not start there, and start fixing stuff, and then optimizing.

The important thing, the only thing that really matters, is that it has to run the code we're running today. Much of Frontier is implemented in itself, so if the port isn't a real port, forget it, you'll be working on it for twenty years, and the result will be probably not worth very much.

Where is it written that the Mac version is the one that has to be ported? There is a Windows version too.

Think creatively.

[rhempel]

I've had a casual look around and there are some potential portability issues with short and long types - not critical unless the data structures assume short is 16 bits and long is 32 bits - which is incorrect on a 64 bit machine. This gets worse if you assume value ranges for short and long. Not a BIG challenge but can be handled with modern C types that reflect the size of a value in bits if that's important.

I agree with @scripting that the core has to stay C so that you don't have a complete testing mess - and the code does look nicely layered, so in the best case we can use POSIX compatible calls to the file system and networking and get the guts working reliably. In an ideal world we'd want to use TDD to make sure we are not breaking stuff along the way - but this is just a fun project for free :-)

I also agree with @jsavin that WebAssembly is the more portable way to do the UI side of this project - get the db and runtime doing their thing in the exact same C code (with minor mechanical tweaks for portability). Unfortunately my knowledge of WebAssembly stops at being amazed at how portable modern app development is - I'm a hard core / no GUI old school C programmer.

One approach that I have found useful for porting legacy code like this is to build the current codebase on a machine (it can be a VM) that it was designed to run on back in the day. As @scripting says the Windows (MINGW?) port might be an easier way to get started. Then I would:

1. Make mechanical changes to the problematic types and ensure the whole thing still runs
2. POSIXify the file system access and ensure the whole thing still runs
3. POSIXify the network access and ensure the whole thing runs

While all that's happening, have a friendly WebAssembly programmer look at how to separate the guts of Frontier from the db and runtime - this can be wireframed with stubs that will eventually be translated into hooks to the runtime and db.

Unfortunately @scripting - using Wine is another pain in the ass for Linux users to install and maintain - and for all the trouble you are basically running Windows on Linux so why not use a VM.

A pure C runtime and db with a WebAssembly front end (maybe running in Electron) would be a really nice cross platform way to package up Frontier ...

[scripting]

I thought WINE was available as a library you can bake into an app.

In any case, I'm the only user, at least for now, and I'm happy to install whatever I have to to run this. Esp if it gets a result sooner.

[rhempel]

You're right, I was thinking of the Wine that lets you run Windows executables when you can't compile them. @scripting - what's the actual use case here - are you just wanting to get Frontier running on a Linux machine with a desktop for personal use, or is it to make Frontier available as an outliner based scripting/writing tool for the Linux GUI?