Old Vintage Computing Research

Time for another MacLynx save point in its slow, measured evolution to become your best choice within the remarkably narrow niche of "classic MacOS text browsers." Refer to prior articles for more of the history, but MacLynx is a throwback port of the venerable Lynx 2.7.1 to the classic Mac OS last updated in 1997 which I picked up again in 2020. Rather than try to replicate its patches against a more current Lynx which may not even build, I've been improving its interface and Mac integration along with the browser core, incorporating later code and patching the old stuff. The biggest change in beta 6 is bringing it back to the Power Macintosh with a native PowerPC build, shown here running on my 1.8GHz Power Mac G4 MDD. This is built with a much later version of CodeWarrior (Pro 7.1), the same release used for Classilla and generating better optimized code than the older fat binary, and was an opportunity to simultaneously wring out various incompatibilities. Before the 68000 users howl, the 68K build is still supported!

In the distant nethermists of time, documents once briefly ruled the earth (or at least Mac OS), and to that end I managed to find a verrry interesting book recently, complete with an unopened CD-ROM. But seriously, though: what was Apple thinking with that name? It's not this cyberdog (image credit). Not that cyberdog, though this is one of my favourite weirdo pinball machines. Definitely not that cyberdog. But thanks to all those other cyberdogs, Apple's own Cyberdog — a seemingly ordinary web browser and Internet suite with some unusual capabilities — has since slid into search engine obscurity. Apple had some big plans for it, though, and even wanted to give developers a way to develop their own components they could run inside of it. Not just plugins, either: we're talking viewers, UI elements and even entire protocol handlers, implemented using Apple's version of OpenDoc embedding.

Cyberdog's initial release belied some wild changes afoot, for in the world it inhabited, the document told the system what it needed to display, and the parts within the document displayed it. The document ruled all. The document was king.

And all of this came together in a special Cyberdog software development kit, complete with example code and the very first 1.0 release of the browser. Now that we have our PowerBook Duo 2300 rehabilitated, guess what we're gonna look at?

I've been working off and on doing further Mac-ification to my updated fork of MacLynx, the System 7-compatible port of the venerable text browser Lynx for classic 68K Macintoshes (and Power Macs) running A/UX 3.x or System 7.x and later. There's still more to do, but a lot has been worked in since I last dropped beta 4, so it's time for another save point. Meet MacLynx "beta 5."

Last weekend was sad, so let's do something fun. I've mentioned I collect non-x86 laptops and portables (and not just PowerBooks: see my previous entries on the "MIPS ThinkPad" IBM WorkPad z50, the PA-RISC SAIC Galaxy 1100 and these Sun Ray laptops, among others) because they're always — and sometimes wildly — different than your average Best Buy special.

Every rule's got an exception, though:

I will try to pick up x86-based systems with "personality" (as I see fit). The PCjr, for example, had personality: love it or loathe it, it was definitely different. And the Brother GeoBook series of laptops were certainly different too, late 1990s appliance-style laptops sold at low-end prices intended for basic home tasks. Besides their chunky form factor, flash memory instead of a hard disk and an entire operating system in ROM, that operating system they ran was also different: PC/GEOS, the bigger spiritual sequel to the GEOS operating system for the Apple II and Commodore 64/128. Out of the box and built-in, you got a capable word processor, spreadsheet, drawing program, file manager, and basic personal information management, plus pervasive fax support for the included fax/modem. If you wanted, you could even install a basic web browser and E-mail client included on floppy disk.

And by golly, I do mean basic. But it was notable that a browser option existed at all, so we should make it live again. Let's take a tour around the unit's built-in applications and explore its guts, then get its PPP connection working again over null modem, hack the browser to understand what an HTTPS URL is and forward it to a Crypto Ancienne proxy, and get the GeoBook back on the Web and accessing current sites. Slowly — but it works! No Betteridge's law around here! (Teaser: see it load Hacker News and Lobste.rs at the end.)

But first, how on earth did GEOS get into the ROM of a chonktastic plastic laptop?

Today we're adding TLS 1.3 to the one and only web browser on a 36MHz MIPS handheld running Magic Cap, the most unique mobile operating system from the most influential startup you never heard of. But before we do, a thank-you to Scott and Barbara Knaster: Scott, who is of course well known for his Macintosh books and his work at Alphabet-Google, also worked at General Magic as a technical writer. Barbara, his wife, wrote this very complete third-party book on Presenting Magic Cap — apparently the very first! — and all the cool things users could do with it, from basic E-mail and contacts (there's a reason why there's a cloud downtown, long before the term was fashionable) all the way to building forms and interfaces with the Magic Hat in construction mode. (One demonstration is making an E-mail form for lunch orders. You send it to people, they fill it out and send it back. It's all supported by the operating system.) It also includes a look at tinker mode, letting you steal the painting from the hallway and put it in your office behind the desk, or change the pictures on the doors. All this was possible without writing a line of code: as she concluded at the end of the book, "Magic Cap has great potential to expand and enrich the way people communicate." It sure did. Thanks, Barbara and Scott!

Some things you just gotta get off your Quadra 800's desktop and out to the people. Plus, the Q800's Barracuda SCSI drive is getting a little iffy and I foresee a retrofit in the not-too-distant future, and ain't no backup better than an interim release. There's still more work to be done but enough's here to make it worth a save point. C'mon now, two years after beta 3 isn't that bad, is it?

Yes, MacLynx is a real, honest to goodness port of Lynx 2.7.1 to the classic Mac OS, compatible all the way back to System 7. What makes it particularly interesting as a port is its partial integration with the Mac OS: the home page is set through Internet Config, it supports the Speech Manager, you can drop URLs on it and you can even click on links directly (cooooool!). I used it myself on my first Mac, a Macintosh IIsi, for which it was very well suited. It was released as a beta by its original author and no further releases were made, so a couple years back I decided to dust it off, reconstruct the toolchain and do some upgrades to it just for fun. It's probably the most practical browser you can run on a compact Mac, does very well on later 68Ks and runs just fine under A/UX. I build it with CodeWarrior Pro 2, CWGUSI 1.8.0 (comes with CW Pro 2) and Internet Config Programmer's Kit 1.4.

The original idea for this new beta 4 was to do both some updates to the Lynx render core to make it more congruent with later versions (there are so many hacks in this that it would be a very lengthy undertaking to find and up-port them to a current Lynx, assuming it would even compile) and also add more GUI elements, but the biggest issue remained MacLynx's Frankenstein event loop. From "beta 2" to beta 3, I managed to cut down on unnecessary screen updates but the event loop still seems to be doing a lot, a probable impedance mismatch between Lynx's main loop which reasonably expects a terminal all to itself and bolting the classic Mac OS event loop onto that. (I wonder if Olivier was struggling with the same thing when he was working on it.) While working on this release I spun my wheels quite a bit trying to figure out where key down events were getting dropped or delayed while mouse events like clicks on links were seemingly unaffected, and ended up putting further work on it aside for awhile, which is why we're now into 2023.

Then it hit me: I had always intended to make MacLynx more Mac-like and use more Mac controls. In fact, beta 3 has a dialogue resource in it I did some initial messing around with but never hooked up. If moving more things into the native mouse-driven GUI makes it faster ... let's make it faster by moving more things into the native mouse-driven GUI! Time to dig out that well-worn hardcover copy of Inside Macintosh and dive in!

(How do you pronounce BeOS?)

This is a real 133MHz BeBox running otherwise stock BeOS R5, surfing Hacker News and Lobste.rs using a modified, bug-fixed NetPositive wired to offload encryption to an onboard copy of Crypto Ancienne (see my notes on the BeOS port). NetPositive is the only known browser on the PowerPC ports of BeOS — it's probably possible to compile Lynx 2.8.x with BeOS CodeWarrior, but I've only seen it built for Intel, and Mozilla and Opera were definitely Intel/BONE-only. With hacks for self-hosted TLS bolted on, NetPositive's not fast but it works, and supports up to TLS 1.2 currently due to BeOS stack limitations.

Tadpole has this storied history as a maker of truly unusual laptops, particularly after their 1998 merger with RDI, another company that made truly unusual laptops. Most geeks are aware of Tadpole's (and RDI's) SPARC line, and I myself own a 2005 Sun Ultra-3 (a rebadged Tadpole Viper, complete with its unique lavender case) and a 1998 UltraBook IIi, plus a 1991 RDI BriteLite IPX, basically a portable SPARCstation IPX that even required a separate mouse. However, Tadpole didn't just make SPARC laptops: they made the N40, a PowerPC 601 workstation under contract for IBM that ran AIX, the PrecisionBook, a PA-RISC based laptop that runs HP-UX (I have the 160MHz version, basically a HP 9000 C-class workstation), and the one and only DEC Alpha-based portable, the ALPHAbook. With a 233MHz 21066A CPU, the very-hard-to-find ALPHAbook was at least briefly the world's most powerful laptop.

But for however original their early designs were, in 2005 General Dynamics bought them out, merged them with their other acquisition Itronix and triggered the end of the RISCy business. General Dynamics wasn't in the retail market; they sold to the military and other large institutional customers, and those folks wanted thin clients. All the rage then was Sun Ray, launched by Sun in 1997 and killed, like many things, by Larry "The Terrible" Ellison's Snoracle in 2014.

Sun Ray clients are simply networked display devices that connect to a server using ALP, or Appliance Link Protocol. Properly configured, a user could go from terminal to terminal and have their session follow them from client to client with no interruption (with a smart card, they wouldn't even need to type their login and password). The user has no local storage access; everything is centrally administered, including their desktop and the apps they run. Naturally Sun Ray Servers were originally Solaris-based, but there was a later binary available for Linux, and the Java open-source kOpenRay (which yours truly maintains) implements portions of the protocol. Using the Sun Ray Server as a gateway, connection to "conventional" Windows Terminal Server sessions via RDP was also possible.

The clients themselves came in several distinct generations. The first generation ("Sun Ray 1") were based on the MicroSPARC IIep, first discretely, and then as a custom SoC; the second generation were MIPS, more specifically the orphaned Alchemy microarchitecture which we'll talk about in a future post, and the third generation at least initially continued with the same. However, since the firmware was CPU-agnostic (in fact, later there was even a software client you could run as a Windows application), there was nothing particular about the protocol or the implementation that irreversibly tied Sun Ray to any one specific architecture.

That brings us back to the zombified Tadpole under General Dynamics (I'll call it "GD-Tadpole"). The MIPS Sun Rays were very power-efficient (again, a topic for a future post when we look at the Accutech Gobi systems) and performed well in laptops and even several Sun Ray tablets, but the chips weren't available in volume and didn't have the economies of scale of low-end PC laptops. So GD-Tadpole chose ... a low-end PC laptop, specifically the Taiwanese Compal FT01, fitted it with Sun Ray software and a custom BIOS, and released that as the Tadpole M1400 in 2008. And here are two, one so new the sticky protective plastic cover picked up hairs:

Notice that one is badged General Dynamics and one is not. More about that in a moment. Opened up, however, they are indistinguishable: And here it is with my Gobi 8 (Sun Ray 2), both connected to a default configuration of kOpenRay. The M1400 is the larger of the two on the right. These laptops were a larger family of otherwise unremarkable PCs with weird firmware, the M1400 being the first. In 2010 General Dynamics delivered the successor Tadpole M1500, which is a rebadged Compal HL91, along with the netbookish M1000 with a smaller screen and form factor. All of these machines were only meant to run as Sun Ray clients, enforced by their modified BIOS, but the desktop Tadpole Pulsar and Pulsar Premium introduced at the same time have a hidden conventional AMIBIOS and can boot a conventional operating system. Not so the laptops: Sun Ray or bust.

The FT01 wasn't a terribly flash laptop even for the time, but it didn't have to be. The M1400 variant has 512MB of RAM (one SO-DIMM with two sockets) and a Socket P receptacle with a 1.86GHz Intel Celeron 540. We can confirm that by carefully cutting the warranty stickers on the "new" 1400:

and then removing the retaining screws from the doors: This exposes the CPU (peeping out from under the heatsink), the fan, the single SO-DIMM and the Intel PRO/Wireless 3945ABG mini-PCI card. There is a second mini-PCI slot available, but the M1400's default OS probably wouldn't make use of it. Similarly, I installed a second SO-DIMM for a total 1GB of RAM as an experiment but it didn't seem to make any difference.

Also notice that there is no obvious main storage; the SATA hard drive bay is empty. That's because it's actually in the optical drive slot where the smart card reader is, using a carrier tray that is the system's only custom GD-Tadpole component. It is an otherwise off-the-shelf 256MB Transcend 40-pin IDE flash module which connects to the optical drive's PATA and power port using a bespoke passive interposer board. The smart card reader connects internally with its own data cable and draws power from the drive connection using the flash module's interposer. Like all such optical drive trays of the era it is easily extracted once the data cable is disconnected by removing the retaining screw and gently pulling it out. We will take advantage of this later.

The M1400's BIOS is locked down to only boot an approved OS. It can be on a drive in the SATA bay if you pull out the flash module's carrier tray, but if it doesn't recognize the operating system, it will put up a red screen with an error message and refuse to continue. There is no obvious way to enter the BIOS setup, if it even has one. So far there are at least three OS versions, all Linux-based. By default the machines use a 1280x800 screen resolution neither my 1080p flat panel nor my INOGENI VGA2USB3 like, so these screen grabs are unfortunately not at their native resolution.

The earliest version I have came with the "unbadged" laptop. This version of the firmware flashes a plain cyan screen if the discovered boot device and operating system pass muster and then starts the client. If installed in the "badged" laptop it will flash the same cyan "happy" screen, but then the screen blacks out and it doesn't get any further. As the hardware is the same I can only conclude there is a difference in the BIOS between these two units.

Once loaded it starts up directly in the typical Sun Ray On-Screen Display "OSD" client window of the time, with its MAC address as its ID and various icons and progress codes as it obtains a DHCP address and then tries to connect to its configured server.

All firmware versions of the M1400 implement the standard Sun Ray key combinations and add some unique ones. Menu-M, for example, brings up the internal configuration menu (the trackpad is also active) from which network and other system settings are adjusted. However, an unusual feature of the M1400 family is the built-in minibrowser, which can be enabled from the menu. This version of the firmware has an annoying habit of automatically resetting and trying to reconnect if it isn't connected to a Sun Ray server instance, making the minibrowser a bit less useful than it would be ordinarily. There doesn't seem to be any easy way of turning that off, so to placate it we'll startup kOpenRay on the Raptor Talos II to give it something to connect to. Here is its firmware version ("Tadpole-mb02-V3.4.0-0101," dated 15 September 2008). Although the menu says we can "enable features," there appears to be only one feature to enable (virtually all of the later generation Sun Ray clients have some sort of VPN support, including encryption). Now that we are connected to our dummy server, let's enable the minibrowser with Menu-B. Huh, that's ... a unique choice of layout engine. The übernerds have recognised this atypical choice of browser already, but for the rest of you ... it's Links! More specifically, it's 2.1pre33, which would have been approximately current at the time. The user agent also rats out the underlying operating system as Linux 2.6.25, running everything on a custom framebuffer. (A consequence of its limited user interface is that the browser window can be moved but not resized.)

This is actually the only mass-produced device I've seen that comes with Links from the manufacturer as the browser of choice. It's certainly very quick and small and I delight in its quirkiness, but there were more mainstream choices available in 2008 — including one we'll examine in a moment — so I'm not sure what went into the decision.

You can browse to file:///, but it seems to exist in a very limited chroot environment (darn) that is apparently recreated on startup. For example, you can download files and they appear in your home directory, and you can use the bookmark manager and changes appear to stick, but when you reboot the machine and go back to file:///home/user everything is wiped. It would have seemed a simple matter to disable these features but for some reason they didn't.

Only four files are in the chrooted /etc; here's ld.so.conf: And here's the only inhabitant of /usr/bin, the links binary itself. TLS 1.0 is supported, which would have also been appropriate for the time. It does not seem to use the same certificates as the rest of the system; indeed, it accepted gopher.floodgap.com's Let's Encrypt certificate without complaint (it doesn't appear to validate them at all). Still, one thing they did customise, if you can call it that, was the name ("Browser"). I don't know why they just didn't keep Links. If you're going to be weird, be proud. The "badged" laptop came with a later version of the firmware. Instead of just a plain cyan "happy" screen when powered on, it also has a Bondi blue screen that says "Loading." After possibly flashing the Loading screen a couple times, it then launches into the Sun Ray client. (The "unbadged" laptop halts at this point with this firmware, by the way. It shows "Loading" and briefly displays the Sun Ray OSD status window, but then goes back to "Loading" and freezes.) Here's the firmware version ("Tadpole-mb02-V3.6.1-0101," dated 25 June 2009). This firmware version doesn't have the earlier one's obnoxious watchdog reset if it has no Sun Ray Server to connect to. This not only makes the minibrowser more functional as a standalone application, but also facilitates logging into networks using the browser itself, which the prior firmware would make rather difficult. In fact, there's even an option in the menu for it: The minibrowser (also on Menu-B) is very different in this release: It's WebKit! The toolkit is Qt for Embedded Linux; the layout engine version (527) is comparable to Safari 4.0, which again would have been roughly current at the time of release. It calls itself meteorbrowser/0.1: Meteorbrowser is both more and less functional than Links. For example, the encryption support went backwards; Meteorbrowser cannot connect to gopher.floodgap.com over TLS, even TLS 1.0, and doesn't explain why: They also closed the "hole" with file:/// (ftp://, recently killed by Firefox for no good reason, generates the same error). Still, the improved engine means its layout capability is more modern (with odd gaps like fonts and Unicode characters, however) and things like basic JavaScript work. Here, testing it on my page on California State Highway 136, popups and closes for the images work correctly (as tabs). There are undoubtedly some potential exploits possible in this version of WebKit though its JavaScriptCore version does not seem to have a JIT. Shellcode explo(it|r)ations perhaps to come in a future post ... You may have noticed that the kOpenRay session didn't look quite right. That's because it seems to bug out on this version of firmware. It's probably kOpenRay's bug, but I'm not sure why it happens yet.

The third version of the firmware I've encountered was courtesy David Parkinson, who was one of the early explorers of this system and discovered it could be booted over SATA if the IDE flash module tray was ejected. He sent this firmware image to me and I flashed it to a CF card of the same size, booting it from an off-the-shelf CF-to-SATA adapter.

This firmware works on both the "badged" and "unbadged" systems. It uses a Windows XP-inspired interface and is much more sophisticated than the basic Sun Ray OSD even though it still preserves the same status codes. It is also clearly badged "General Dynamics" — not Tadpole. This image came up defaulting to the WiFi, though if you connect an Ethernet cable it would still get a DHCP address from it. It has specific tabs in its interface with better video configuration options, more user interface configurations, and a status tab showing it as Tadpole-mb02-V4.6.2-0101, but undated. If it corresponds with the M1500, then this would put it circa 2010. However, Menu-M yielded a nasty surprise, as photographed when I initially tried it: I tried all the usual typical passwords. It naturally resets if you try too many, which slows you down further. The browser was disabled and there seemed to be no way to set network information. Locked down hard! At this point I figured I should have a look at what was actually in the firmware.

The 256MB image David sent me mounts as two VFAT volumes called CONFIG and CARD. Here they are in Midnight Commander.

The CARD side seems to have most of the meat. 1* files are bitwise identical copies of 0*, presumably spares if something goes wrong with the filesystem. The extensions .ime and .tle are opaque binary files. They do not appear obviously compressed and strings shows no recognisable ASCII text within them, and their magic number 80 00 00 00 doesn't match any file format I know. The only readable files are factory.conf, with two lines (KbdType=pc and Language=uk), features with some sort of hex product key, a 384-byte license file also containing ASCII hex, and 0meteor.bom and 1meteor.bom, which are identical and have lines like this:

0meteor.bom=Tadpole-mb02.bom,S,4.6.2,3.0.0,30c4[...]
0initrd.ime=mb02_initrd.ime,H,4.6.2,3.0.0,42e6[...]
0browser.tle=mb02_browser.tle,S,4.5.15,3.0.0,971d[...]
0opengl.tle=mb02_opengl.tle,H,4.5.6,3.0.0,01e2[...]

Like the license file, the hex data is 384 characters encoding 192 bytes. Best guess is some sort of checksum hash which is checked on startup. The 4.6.2 matches the version number of the firmware, but I don't know what the H or S indicate, or the 3.0.0. BOM therefore probably stands for Bill Of Materials.

The CONFIG side is mysterious in different ways. Notice that the 0* files have a different modification date than the 1* files, and they are not identical copies (their CRC32 checksums differ). The significance of this was not known to me at the time, but we'll come back to why they differ presently. These files, however, are not encrypted. In fact, 0certs.img is another mountable FAT image that despite its filename calls itself METEOR:

This is obviously the certificate store. However, I didn't find any of the configurable screen or UI settings in CARD, CONFIG or this METEOR.

Were the other firmware versions the same? Time to dump them and see! Attempting to extract the IDE module started to perilously bend the pins on the interposer because of its tight fit, so I pulled a beat-up Dell Vostro 1400 out of the closet with a PATA optical drive slot to plug the whole tray in as a unit. The retaining screw didn't quite align between its drive and the GD-Tadpole tray; since I have two trays I decided it was Dremel cutting tool time for one of them:

I chose the tray from the "badged" unit since that one was in worse shape anyway. Notice that there were differences in the smart card reader too (earlier one at left), but they probably look the same to the operating system. Once installed dumping the images was then a matter of booting Clonezilla on the Dell Vostro, having it mount a second USB drive and dd the entire IDE module with both partitions over to it. To dump both modules I just switched the entire interposer board with the module attached. The older firmware versions lack factory.conf, but are otherwise laid out the same with a set of similarly mysterious binaries and corresponding license, features and *.bom files. Fewer components are in these earlier versions, and the Links-based firmware's BOM is the only one where every file's version matches the firmware's displayed version (3.4.0). They also divide themselves into CARD and CONFIG partitions.

The second version firmware allows you to configure the default address for Meteorbrowser. I figured this was a useful test, so I made a single character change from "i" to "j" to see how this altered the dump and compared both images in VBinDiff. The result was unexpected:

It's cleartext ASCII! I grepped every single file in the image to determine where it was stored and found it in CONFIG/0meteor.cfg ... which turns out to be another FAT image! This image is also called METEOR: The string appeared in base.conf. You can see all the folders for the individual profiles, suggesting this is where user settings are written to. The clock was set wrong on this unit, but the times differed here as well, just as they did on David's image. I should have realized there was something special about those files in the first place.

With this new information I returned to his image and mounted CONFIG/0meteor.cfg. After grepping around a little, in profiles.conf appeared this string:

Password_Enc=d8f9[...]

A theory came to mind: if I munge it to a key it doesn't recognise, then it hopefully will think it doesn't have a password at all. I directly loaded the image into a hex editor and changed every occurrence of Password_Enc to Aassword_Enc (gotta make sure the length matches). This string appeared in four places. I then flashed this to the CF card and rebooted, and pressed Menu-M.

Bingo! No password, unrestricted access! Time to turn on the minibrowser, which it calls a Mini Bowser. Unlike every other version of the firmware, this one directly allows you to update the BIOS. I didn't try this because I actually like what's there, but I bet David will try. It did not prompt for a filename and I did not click Confirm. Another nice feature: NTP is supported. Time to fix the clock. Configured and talking to kOpenRay. Whatever issue was with the second firmware version is fixed now. Unfortunately, Meteorbrowser is still the same and has all the same limitations. Fixing the clock didn't fix TLS. I haven't found any other versions of the firmware. If you have one, let's explore it.

Things to do:

• Try to bust into the OS by exploiting the version of WebKit in Meteorbrowser. Hopefully it isn't similarly chrooted.
• Figure out what those hashes are and what algorithm it uses. It may have something to do with license, which could be an encryption key. However, the 192 byte length is a little unusual.
• Unmunge at least one of the files. The obvious target is ?bootarg.ime, which is small enough where brute forcing may actually be possible especially since I strongly suspect it should yield ASCII text, and at that size it probably isn't compressed.
• Links can do "more" and is more "fun," so see if I can make a hybrid firmware using the improved General Dynamics launcher but replacing ?browser.tle with the ones from the original firmware. Assuming the hashes match between releases, I should be able to just copy the needed lines from ?meteor.bom.

In a future blog post besides hopefully any or all of the above, we'll look at the Gobi series, the MIPS-based Sun Ray 2 ancestors to the M1400 and their unusual Alchemy-based CPUs. [UPDATE: The future is now! Read about the MIPS Sun Ray laptops.]