[NTLK] Einstein and newton-re roadmap ideas

[Matthias Melcher]

> On 24. Oct 2026, at 13:26, Eckhart Köppen <eck at 40hz.org> wrote:
> 
> Here are some ideas where to take Einstein and newton-re, would be 
> interesting to get some discussion around this.
> 
> newton-re is very easy to port to new platforms, if we were to build 
> e.g. 
> a MessagePad 3000, this would be a good basis. It can also easily use 
> host OS services such as USB to serial or networking. To me, newton-re 
> looks like the ideal candidate to cover the use cases for the general 
> public, e.g. use NewtonOS apps in day to day scenarios. The gaps right 
> now would be enabling the platforms Einstein supports right now, and 
> adding additional user interface components as needed.

Yes, I think NewtonOS and NewtonScript is good enough to create apps that can be used every day. Some apps, Calendar, Notes, are still good enough. With newton-re and the newtc decompiler, they can be improved.

> Einstein is on the other hand a true emulator, and very useful for any 
> development work which should end up on actual MessagePads or eMates. 
> The Y2010 patch development was for example much nicer with Einstein 
> (...) is an important 
> part of the history of the Newton.

It's the "Museum of Newton" ;-)

> I would however simplify Einstein quite a bit, and exclude the cases 
> newton-re can handle. Einstein covers a lot of platforms, not all of 
> them with maintainers behind them, has three UI frameworks, and two 
> build systems.

Yes, this is true for Einstein. I was never brave enough to throw away the Cocoa implementation as it is Paul's original vision. It's complicated for mobile devices if you want to have an user interface besides the pure emulation. At that point, iOS apps can *only* be built by Xcode, and Android apps require all the Java wrapper stuff from Android Studio.

> My thinking would be to only support Linux and macOS, 
> and keep either FLTK or SDL3 as the graphics layer. Windows support 
> could possibly be kept, or then be handled via WSL.

Windows support currently runs just fine, AFAIK. If we stick with FLTK for Einstein, it "just works" under Windows. I rarely have to write Windows specific code. WSL requires X11 and gives only limmited access to the underlying Windows system, IIRC.

> I would also move 
> the existing support for developing Newton apps to newton-re. On the 
> other hand, it would be interesting to add DAP support and improve the 
> way we can control Einstein remotely so that it can be used as the 
> ground truth when working with newton-re. All of that obviously 
> reflected via GitHub issues.

Please take a look at `newtc` and `VSNewt`. They are based on newton-framework and implement DAP already. It doesn't matter much if `newtc` uses newton-framework or newton-re.

https://github.com/MatthiasWM/VSNewt
https://github.com/MatthiasWM/newton-framework/tree/dap_to_toolbox

> Until newton-re is on par, a 'legacy' branch for Einstein would be 
> present for urgent fixes such as security vulnerabilities, forked off 
> the last official Einstein release. An alternative is to create a fork 
> of Einstein for the above simplifications, but forks make more sense if 
> there are two concurrent development efforts, or the original branch 
> cannot be updated. Neither of that is true here though, I see this more 
> as an evolution.
> 
> Some of the above is likely controversial, but I hope we can make it 
> easier for people to contribute to either project, so that we can 
> support new use cases quicker!
> 
> Anyways, eager to hear what people think!


A bit of a longer answer. Apologies.

We have two different use cases here, as you already say. Einstein is the museum case. It's NewtonOS in a box. Everything around it is FLTK, Cocoa, or whatever, supporting the shortcomings of Newton in the modern world: serial ports, encrypted networking, etc. etc. . The core code is never changed (well, we patch it, but most stays the same).

newton-re right now is still limited to the core functionality, but the source code is there to expand it in any direction we wish. Newton is a complete system, and we can take it apart now and stitch is back together

Newton is a
 - Operating system
   - all basic OS functionality, streaming I/O, etc.
   - limited multitasking 
   - hardware abstraction via licensee driver system
 - Byte Code interpreter
   - NewtonScript package reader
   - NewtonScript interpreter
   - NewtonScript compiler
 - Database
   - Soups give database style access
   - Removable Media handling
 - User Interface library for pen computing
   - large set of widgets 
   - handwriting recognition
   - desktop metaphor, multiple application simultaneously

This makes it very similar to other ByteCode based engines that already exist: Java is probably the most prominent. A Java app can run on any platform and in any browser and doesn;t need to be recompiled. It virtualizes access to the underlying OS or browser. NewtonScript does exactly the same.

We don't have to rewrite the operating system. All that exists on all our target machines. We just need to give NewtonScript access to it.

Do we need the desktop part? Does the app bar at the bottom add anything to the experience, or could be just run individual packages from whatever the host OS offers. MacOS already has dock. The Newton bottom bar just duplicates that. My take would be to give a .pkg enough to run completely on its own. If a user has multiple .pkg files, they could communicate, but they can all run individually too.

The Soups are great in a way, but also a security nightmare. Everyone can read and write anything. Should every Newton app have its own set of Soups, or should they share one single soup?

As for the GUI library like FLTK or Cocoa, well, they are no longer needed. There would be nothing to wrap. "Notes" would just be an app, like many other too. It has all the buttons and sliders and dialog boxes it needs using the underlying NewtonOS. There is no need to call back into host GUIs. All it needs is a rectangular pixel canvas. I think, SDL would be the perfect base. It supports graphics, audio, pen input etc. on all machines that we could possibly target. It supports multiple windows on desktop machines for dialog boxes, and single windows on mobile devices, where NewtonOS provides the dialog boxes. It's all there.

`newtc` alredy is a pretty complete compiler and debugger. Maybe a graphical GUI editor is missing. But here again, everything is pretty much there.

`newtc` even has a GUI Mode where it emulates a bunch of Newton GUI widgets, enough to run nBattleship as a tech demo. It is tested on macOS, but should run on Linux and Windows as well:


https://github.com/MatthiasWM/newton-framework/releases/tag/v0.4.0

```
newtc -pkg nBattlehip.pkg -run
```