From 32 to 64 bits

It's a few years later, and the retargeting that I described on the previous pages never happened. At some point, I even decided to remove the retargeting compiler from Einstein.

After I got pretty far, I found a few road blocks taht will make a port of the OS quite difficult.

With most host operating systems going 64 bit, one of them, macOS, exclusively, NewtonOS and NewtonScript byte code are no longer a good fit for modern machines. Too much depends on a 32 bit host environment. I thought about using handles for pointers to limit the conversion to one idirection, but what will we get in return?

NewtonOS is fun. It was a pioneering system in a boring world of calculators and enabled Palm and others, and ultimately iOS and Android. But NewtonOS has many flaws as well. At its time, the internet was not fully developed, and internet on mobile devices was insanely expensive. Service providers would charge by the kilobyte.

It should not come as a surprise that very few Newton apps can deal with networks, and even less can deal with modern protocols and the huge amount of data we shuffle around in 2022. SO looking through unna.org, most apps I find are proof-of-concept toy apps, none of which I would install on a modern iPhone. Actually, I have a hard time finding a single app on my phone that does not connect regularly to some remote servers. Solitair maybe, but even that shares my highscore with other Solitair players.

There is simply not that "one app" that makes porting the entire operating system useful.


But wait, we are not done

There is however one way that may be useful in playing with the old Newton apps. And it would even be compatible to the App Store. No ROM required, no copyright issues.

Instead of emulating the entire OS, we could simulate the parts of NewtonOS that we really need. newt/0 gives us already the interpreter and compiler. newt/64 loads 32 bit packages and converts them to 64 bit on the fly. And opening an app is really not that hard to implement.

FLTK, the user interface option used by Einstein, was started around the same time as NewtonOS. It should be no surprise that many concept behind FLTK are very similar to NewtonOS. Sure, FLTK looks different, but that is easily fixed. Internally, those two are very compatible.


What's the strategy then?

Einstein has newt/64 tightly integrated into Toolkit to make it easy to write new apps for NewtonOS. Since the compielr and interpreter are the same thing in NewtonScript, newt/64 generates packages by running NewtonScript code. We are missing a bunch of magic pointer data, the API to the user interface elements, and some modern implementations of old stuff like handwriting recognition and a database to manage soup calls.

And the the implementation can be incremental. With newt/64 running our scripts, we can generate orror messages whenever a function os not yet implemented. And since we can transform bbytecode back into source code quite well and soon quite automated, all secrets of the script parts of the OS will be an open book.

Sound like fun. Now I have to find a way to add another ten years to my life span :-) .