What happened?
I’ve been working with web technologies in three different phases over all these years. First was the tumultuous start in the early nineties where we were participating in teaching and research at the University of Essen. This was a great time, everything was fresh and new, we participated and organised conferences on web technologies, experimented and implemented. There was a feeling that the browser can be a very capable runtime environment, but it wasn’t yet clear how it would look like. My own take on where things should be going were Active Hyperlinked Documents(AHDs), and the keen reader will see which great technology inspired parts of that idea :)
In the second phase in the 2000’s, things had settled down, and a common setup was to have a server which ran PHP or Ruby on Rails and which served HTML with CSS, often with a sprinkle of JavaScript. With that stack, I developed a bunch of small tools, and was also using it for 40Hz.org. Things still happened on the server side, but slowly moved to the frontend.
I took a break from this until the late 2010’s, when I started to get curious again and wanted to update my skills. This current phase is again a very turbulent time, with the pendulum having swung full time to browser based frameworks with WASM on the extreme end. It is however also a bit tiring. Frameworks and tools come and go, many things not making it past beta, tools which look promising being abandoned for the next great idea, and technical and architectural decisions increasingly hard to make. Of course I have to say we wanted this back then, the ability to run full scale applications in the browser was one the ideas behind the above linked AHDs, so I can only blame myself :) And there are some good sides to be able to fully encapsulate an application on the client side and treat the backend simply as a data source - as an application developer, you don’t have to involve yourself with running and updating server side components to develop your code. But the overall execution of this model doesn’t look too convincing.
As a software architect I should have answers to this, but I guess a good architect is also one who knows when to say “it depends.” Maybe one line to draw is whether you are building something for the World Wide Web, or whether it is indeed a desktop or mobile application. Take for example GitHub, which I see as a web site, but which has degenerated into a sluggish application. Compare that to SourceHut, which deep linkable, fast and quick to navigate.
Bits and Pieces
Literally! Now that the biggest problems with the Y2010 problem on the Apple Newton are fixed (the patch for the German MessagePads is under testing, and eMates should be next), here are some other things that I played around with along the way.
First, as written before, it would be great to move patch creation to a
more modern tool chain. It is already now possible to use
tntk to create packages
on macOS and Linux (Windows as well with some effort), but creating a
patch would be great. A patch package consists of three parts, the ROM
patch, the ROM Extension (REx) patch, and the patch loader, and tntk
is in theory capable of producing multi-part packages, but in practice,
there are some issues with combining the parts. It seems that the
garbage collection in NEWT/0 which
compiles the packages collects a bit more than I expected, resulting in
a crash. Something to improve I gu
ess!
Then, to get the patches onto actual hardware, I was planning to use RDCL, but I haven’t used it in a long time, and the Ruby world has moved on, so that there’s still quite a bit of work needed to update to Ruby 3.4. The alternative is zdcl, but Zig has a very fast update rate, and also here, an update to the latest version didn’t work out of the box. Next up was gdcl, and since I anyway wanted to use Go more, I did spend a bit more time to get it to at least cover package installation.
Finally, and more on topic for the actual Y2010 problem, I was wondering how to fix any issues that would go beyond the original issue, and which would require more deeper reverse engineering. I did dig out the earlier artifacts such as symbol tables and ROM listings, but I was curious about the more recent advances in the world of rev erse engineering. Specifically, AI seems like a very good fit: Using the old Norcroft compiler to create lot of sample binary code, and then training a dedicated model with it. I didn’t go as far yet, but I did come across Ghidra in the process. And that tool seems to be covering quite a few cases. I’m planning to play more with it and post my findings, even though right now it looks the immediate problems are under control :)
712000
The patch is out :) After some of my own testing and with the help of volunteers on the NewtonTalk mailing list, I uploaded Patch 712000 now. All in all it was not too difficult to update the patch for the next sixteen years of Newton happiness, but there are still some loose ends: I want to also update the German MessagePad and eMate patches, move the patch creation off from the MacOS classic toolchain, and improve documentation.
Ok so I lied
I could of course not resist the temptation to check out how my Mac museum is doing, and if I can create patch packages without BasiliskII. The museum seems fine, my Pismo PowerBook booted nicely, the batteries seem now finally dead, but otherwise it was working well. Same with my former workhorse, the G4 Cube, its only problem is that my current monitor doesn’t like the low resolution the stock graphics card produces.
Neither machine was however in the end used to work on an updated Y2010 patch, that honor does indeed go to BasiliskII. Resource forks are as usual a challenge to move across platforms, so resorted to moving StuffIt archives around, but all pieces for the patch are in place.
It took a bit to figure out how the patch package is put together, I’ll document that later, same with the actual patch approach, but the good news is that my dear development Newton JE7420LHAYL is now reporting patch version 711999, and comes alive just at the end of 2023, December 31st 11:48 to be precise. I’ll still do some more testing and then start a proper release.
The sad part is that this will be the last patch for the Y2010 problem. By 2040, the NewtonOS low level time functions will overflow, and that is a much harder problem to fix.
Rocking like it's 1990
In order to fix the recent date related problem with the Apple Newton, the first question is how to actually develop any fix. Since I’m suspecting that the problem is related to the Y2010 problem, the starting point would be the patch 711000, making the tooling setup a bit more complex.
Patch 711000 consists of a bunch of ARM assembly files, an MPW makefile and three Newton Toolkit packages. If it were only for the assembly files, the modern tool chain brought in with mosrun would work, but the NTK packages are slightly more problematic. In that sense, the options for working with the patch are:
- MacOS Classic capable hardware: Either a PowerPC machine with MacOS X, or to go full retro, a 68k or PowerPC Mac (old enough to still run MacOS 8/9). In the latter category, I still have two G4 Cubes. In the former category, I used to have a Quadra 610, but that is long gone, and I doubt sorting out the connectivity issues would be fun.
- An emulated 68k Mac, using BasiliskII: Not very user friendly, but very close to the actual hardware.
- Using modern tools: Compiling the assembly files using mosrun, and packaging using tnkt. This is probably the most future proof setup.
The target will be Einstein, it allows for a very quick development cycle, and it can also bring some deeper insights into running code if needed.
In the end, I think I’ll go with BasiliskII for now since I’ve used that before with Blunt related work. But the other two options are interesting as well, especially reviving the G4 Cubes would be nice!
Time travel
It seems our dear friend, the Apple Newton MessagePad 2x00, has been bitten by another time related bug. While this looks like the Y2010 bug, this seems to be a new problem. I noticed that my MP2100 ran out of batteries the other day, but didn’t pay too much attention, however a lot of people are now reporting strange behavior of their devices, with freezes and dates being set randomly. And I just checked, also my MessagePad went back to 1990! It seems this happened after January 4th this year.
From what Matthias Melcher reported, it unfortunately looks like the bug is happening quite a few layers down from the Y2010 bug. That bug is an issue in the NewtonScript layer, but this new one (we need a clever name for it still) is related to timers in the OS layer. That will likely make it quite a bit harder to fix, but we’ll see. The good news is that we have Einstein now which makes any kind of experiments much easier and with less danger to actual hardware!
So let’s get to it, fire up Einstein and play a bit with dates and times…