How can we help recompile this as a 64-bit app?

[juandesant]

Because this is just a 32-bit app, there is no way to run it in Catalina or later macOS releases without 32-bit support.

[tedchoward]

So, to get a 64-bit macOS build would require a pretty extensive rewrite. This application started it's life as a "classic" Mac app utilizing the Macintosh Toolbox APIs. Around 20 years ago it was ported to Carbon to run on Mac OS X. Apple decided not to release a 64-bit version of Carbon. When they removed the 32-bit libraries from macOS, that ended our ability to run Frontier on modern versions of macOS.

In order to create a version of Frontier that runs on modern macOS, we would need to remove all the Carbon APIs and replace them with Cocoa equivalents.

One approach would be to look at how the Windows build works. It makes heavy uses of #ifdefs and additionally provides "stub" implementations of the Macintosh Toolbox APIs that call Windows APIs. A theoretical macOS "port" could take a similar approach. This is also the approach to use for a Linux port.

[jgrisham]

The other possibility is that at in the future, someone may create an open-source version of the Carbon APIs for 64-bit systems (that can be used on multiple platforms and CPU architectures, similar to what 'Wine' does for the Windows API), so that applications like Frontier can be run un-changed (or with a simple wrapper).

This might have to wait for a few years for some final patents to expire, the existence of which may explain why no one has done this before.

(Even doing this for the 'classic' Macintosh Toolbox might be practicable some day... Apple actually did a great deal of that work years ago in order to provide cross-platform versions of QuickTime.)

[scripting]

Wow I really like that idea!

Maybe work should start on that in anticipation of the patents expiring.

We could spend a few years testing.

I run Frontier scripts all day every day as part of my codewriting suite. I'd love to get it all on Linux.

[jgrisham]

Absolutely! Even if there are any still in force, they'll be long gone before development and testing on something like this was complete.

(There are tons of good ideas that died over the years due to patent wrangling / encumbrances that are now just there for the taking; dusty gems on a shelf patiently waiting for someone to remember them.)

…

(Once their authors retire and get bored of island life, we may even find free experts floating about.)

---

Taking the next step, and partially inspired by the 'Bochs' 'QubesOS' Linux distribution, I don't see any technical* reasons why interested parties couldn't today create an universal, extensible, OS graphical shell.

Imagine:

• When an application is 'opened' by the user, the shell scans the file (e.g. like the 'file' or 'binwalk' Linux utilities do) and automatically determines what API, emulator, simulator, or VM hypervisor to launch.

• If an app doesn't work properly using a lightweight API emulator (WINE or an open-sourced Carbon), it would try again using a full (transparent) virtual machine.

• The 'parent OS' could initially be BSD, Linux, macOS, Windows, something new. Eventually it could be ported to run on all of those.

"It's Turing machines all the way down."

(show/hide more dreaming)

For example, one could have any combination of the following types of applications on the same 'desktop', and they would all 'just work':

• Win16 (classic MineSweeper, anyone?)
• Amiga
• Java
• MS-DOS (e.g., opens in 'DosBOX' or a similar emulator; 'Use WordPerfect on Windows 12!')
• PalmOS
• BeOS / Haiku
• Mac OS (68k, 68k + MMU, or PPC)
• Mac OS X (32-bit; PPC or Intel)
• Android app archive
• iOS app .ipa (may be difficult for 'App Store' versions due to DRM, but running a build straight from Xcode should be easier)
• VirtualBox-style virtual machines
• 'X windows'-style apps running on remote machines

The same thing could probably be done for command-line executables.

'Who cares what it was compiled for... if performance isn't critical, just run it, robot!'

Need to run a very old version of Netscape or Firefox to test something from the archives? No need to set up a VM, just double-click it!

Worst-case (thinking of PalmOS here, specifically), copy / paste (of plain text) could be provided by simulating keypresses when pasting and using OCR for copying (the current MS Edge has this built-in for any web page, for example).

* There would be horrible pushback from established OS vendors and software publishers, I'm afraid. 'Why buy Photoshop CC 2027 when my old copy of Photoshop 7 will run just fine on macOS 17 et. al.?'