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!

Every collector has that machine, the machine they sunk so much time and, often, money into that they would have defenestrated it years ago except for all the aforementioned time and money. Yours truly is no exception. That machine is my first Lisp Machine and my only one actually using real Lisp Machine hardware, this Symbolics MacIvory III in a Macintosh IIci host. To date it's cost me over $6000 total, primarily its initial purchase price, but also to rehabilitate it and just keep it alive. That's nearly as much as what I paid out of pocket for my $7300 (in 2018) POWER9 Raptor Talos II Linux workstation and my $10,000+ IBM POWER6 server, which I acquired in 2010 and in 2024 dollars would be over $14,000 — and both of those machines have been substantially less troublesome.

For those of you unfamiliar with the general world of Lisp machines, they are, as their name implies, workstations entirely designed around the Lisp programming language. That doesn't just mean using conventional processors with a Lisp runtime either: these devices are built to run Lisp from the silicon up with specific hardware support. (Some of these systems could also run Prolog, my personal favourite AI-adjacent language. We'll play with a surprising small Prolog implementation in a future article.) They existed in highly technical environments as workhorses of the first wave of AI hysteria (you crazy kids today with your LLMs) for applications like natural language processing and expert systems. The genre more-or-less flourished from the end of the 1970s to the early 1990s and included some of the first systems to implement advances like bitmapped displays, networking and pointer devices. In turn, those unusual capabilities caused them to also develop distinctive user interfaces for their unique feature set, years before today's GUI and keyboard conventions we almost unconsciously take for granted were even conceived of. Working with a Lisp machine can be a remarkably different user experience from modern computing and the occasionally jarring nature of those differences isn't something present-day emulators fully capture.

Unfortunately, their rarity also makes them the whitest of white elephants sometimes. Besides what I had to do to get it working properly to start with, the hard drive started timing out and it randomly froze during boot or shortly afterwards. (There was also the matter of me never finishing its setup, let alone getting it networked.) I'm not letting this benighted thing die on me after all I've put into it — it's time for a Refurb Weekend.

A few months ago I introduced you to one of the more notable Apple pre-production units in my collection, a late prototype Macintosh Portable. But it turns out it's not merely notable for what it is than what it has on it: a beta version of System 6.0.6 (the doomed release that Apple pulled due to bugs), Apple sales databases, two online services — the maligned Mac Prodigy client, along with classic AppleLink as used by Apple staff — and two presentations, one on Apple's current Macintosh line and one on the upcoming System 7. Now that I've got the infamous Conner hard drive it came with safely copied over, it's time to explore its contents some more. We'll start with this Macintosh Portable itself and Apple's sales channel applications, moving from there to a brief presentation of Apple's Macintosh product line as Apple's own marketing staff would have presented it, at a distinct point in the company's history. After that, we'll also look at the upcoming System 7.0 circa 1989-90 and a couple very different views of the operating system during its alpha phase. Finally, after a brief glance at Mac Prodigy, we'll explore a little taste of AppleLink in its classic incarnation on General Electric's Mark III network — and spoof it enough to actually get it to log in.

Most of my systems are microcomputers (and commensurately sized), though I do have some moderately larger beasts: you've met homer, my 1987 HP 9000/350 rack system, and Floodgap is powered by uppsala, a 2U-in-a-tower IBM POWER6 520 running AIX. But my first "large" machine, and indeed the first Unix server I ever personally owned, was this Apple Network Server 500. Its name is stockholm. A mini-fridge-sized server with its famous translucent blinkenlight-friendly front sliding door and oodles of drive trays, this $11,000+ box (almost $22,000 in 2023 dollars) sat forlorn and unused at the University I was employed with as an IT working stiff in 1997. The bookstore had bought it at a substantial academic discount for their UniVerse-based (a Pick descendant, now Rocket U2) point-of-sale system, but the vendor wouldn't support the hardware anymore after then-CEO Gil Amelio cancelled the ANS line, so it got dumped off as surplus in the service bay where it lurked in a corner. As it was just sitting around, I got to use it as my personal server, shown here circa 1998 in my old office on a bad scan from a bad Polaroid. In this picture it's acting as a terminal server for my Commodore SX-64 with a CMD SwiftLink 6551 ACIA serial cartridge (the SX-64 is sitting on a parallel port switchbox because its handle got busted).

About a year later the University said they'd throw it in with my consultant compensation because they wanted to get rid of it anyway, so it became officially mine, and I was delighted to have it. That machine, later upgraded to 200MHz and 512MB of parity FPM RAM, variously powered my E-mail and the Floodgap gopher and webservers from 2000 to 2012, and still does backup duty when the POWER6 has to be down for repairs.

That's because the POWER6 runs everything the ANS did — because the ANS also runs AIX. The ANS 500 and 700 were not Apple's first Unix-specific servers (that would be the Apple Workgroup Server 95, a Quadra 950 using a special PDS card that only worked with A/UX, Apple's own Unix with a bolted-on Mac compatibility layer), but they were Apple's first Mac derivatives that could not boot classic Mac OS at all and natively ran a non-Apple operating system. Indeed, most people treated it as exactly that, a big Unix server from Apple, and at the time I did too.

However, there was a secret weapon hidden in ANS AIX most of us at the time never knew about. Built-in to the operating system was a fully Unix-native AppleTalk stack and support for receiving and sending Apple Events, surfaced in the form of Apple's disk administration tools and AppleShare. But Apple had a much more expansive vision for this feature: full server-client "symbiotic" applications that could do their number-crunching on the ANS and present the results on a desktop Mac. Using the Program-to-Program Communication Toolbox ("PPCToolbox"), and because AIX's throughput far exceeded anything the classic Mac OS ever could ever handle, an ANS could augment a whole bunch of Macs at once that didn't have to stop to do the work themselves.

Well, today we're going to write one of those "symbiotic" applications doing something this little Mystic Color Classic could never efficiently do itself — accessing and processing a JSON API over TLS 1.3 — and demonstrate not only how such an client application looked on the Mac side, but also how the server component worked on the AIX side. If you're lucky enough to have an ANS running AIX too, you can even compile and run it yourself. But before we do that, it might be a little instructive to talk about how the Apple Network Server came to run AIX in the first place.

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."

This article has been revised with recollections and corrections from former Apple employee Al Kossow, some good folks on Hacker News and the Vintage Computer Festival forums, and an anonymous individual with high-level knowledge of the project. One of the coolest things to come along in the 68K Mac homebrew community is the ROM Boot Disk concept. Classic Macs have an unusually large ROM that contains a fair bit of the Mac OS, which was true even in the G3 New World Mac era (it was just on disk), so it's somewhat surprising that only one Mac officially could boot the Mac OS entirely from ROM, namely the Macintosh Classic (hold down Cmd-Option-X-O to boot from a hidden HFS volume with System 6.0.3). For many Macs that can take a ROM SIMM, you can embed a ROM volume in the Mac ROM that can even be mirrored to a RAM disk. You can even buy them pre-populated. How's that for immutability?

Well, it turns out Apple themselves were the first ones to implement a flashable Mac OS ROM volume in 1994, but hardly anyone noticed — because it was only ever used publicly in a minority subset of one of the most unusual of the Macintosh-derived systems, the Apple Interactive Television Box (a/k/a AITB or the Apple Set Top Box/STB). And that's what we're going to dig into — and reprogram! — today.

I guess this is a review of sorts, so here's the review part: you should buy Tech by Androda's new 7MB Macintosh Portable RAM card. On my DVT prototype O.G. (non-backlit) Macintosh Portable, I get a total of 8MB of RAM as expected from 1MB on board and 7MB on the card, and System 6 works great. The card is compatible with both backlit and non-backlit machines, though on the backlit system you'll only get 5MB total without tapping one of the PDS slot addressing lines. When they're back in stock, get one, because finding RAM cards of any size (let alone maxxed out) for the Portable is difficult, and the older MacEffects 8MB upgrade — pricier but giving you up to 9MB — is no longer being made due to a lack of chip supply. Wait, you say you want pictures of this prototype Macintosh Portable? Including its beta OS version and System 7 pre-release presentation? Oh, well, then! No, you can't escape! Sit down and watch my slide show!

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!

I've been building up a few of these entries in my head as I run across things, so this will be the first of a recurring series of "prior art": technologies and ideas we use today that had earlier, different paths and implementations. For this inagural entry we'll be looking at OWL Guide, an early hypertext system for the Macintosh, and contrasting it with HTML and the modern Web.

Of course, hypertext didn't start with the microcomputer; one of the earliest document-oriented forms (as opposed to card- or frame-oriented like HyperCard or KMS, as well as other concepts) was the 1967 Hypertext Editing System, running on a partition on an IBM System/360 Model 50, contemporary with the baroque but much celebrated oN-Line System which formed the basis for the 1968 Mother of All Demos. However, the microcomputer was where it started to gain steam, with early text-only implementations like the DOS-based 1983 PhotoQuery, which became TIES in 1984. TIES' key innovation was advancing the convention that the text itself contained the links embedded within it, rather than navigating using external numbered menus, codes, icons or other gadgets. (TIES later evolved into HyperTIES, which in 1988 introduced early implementations of imagemaps and style sheets using its own "HTML" [HyperTIES Markup Language] for screen design, also based on SGML. HyperTIES was credited as the first instance where hyperlinks are blue.)

This was a natural fit for GUIs, and hypertext/hypermedia flourished on the early Macintosh. Naturally everyone remembers HyperCard and its various clones, the archetype (but not the prototype) of card-based hypermedia, but one of the earliest hypertext systems on any desktop computer was OWL Guide for the Mac, dating to 1986.

Yes, I'm back to further hijinx with the port of Lynx 2.7.1 to the classic Mac OS. I have great fondness for it because it was the first browser I ran on the first Mac I personally owned (a IIsi) and I'm delighted to be dusting it off. No, it's not just a monkeypatch like "beta 2" (in scarequotes) was: this is a real rebuild off the real original source code once I did some housecleaning and refactoring. Here it is, running in A/UX: Or, here's some actual proof it's different. Even with Crypto Ancienne providing bolt-on TLS 1.2 capability, you couldn't view Hacker News with MacLynx previously because it was sent as text/html;charset=utf-8. Now you can (admittedly System 7 doesn't understand what UTF-8 is, but let's just handwave that away for now). There's no easy way to monkeypatch in a fix like that because it's new logic and new strings, not just changing old ones, so only a code change will fix it. And, symmetrically, here's lobste.rs, though the reason you couldn't view it before was a bug in Cryanc that was fixed in current 1.5: That's not the only change, either. Besides accepting UTF-8 (or at least not refusing), it also has a proper fix for beta 1's inappropriate Content-Encoding header, has a "live" scrolling area (click the top or bottom halves of the scroll area to advance or go back a page), and reduces the event loop's constant redrawing of the screen. There are no changes to the rendering core in this version.

Under the hood, although the alpha 5 source code (the only version that survives) claimed to have been built with CodeWarrior Pro 2, the projects are actually from an earlier IDE, and it isn't clear which version of GUSI or CWGUSI (GUSI being a shim library to map "conventional" Berkeley sockets and file handling onto MacTCP and MacOS) was used. In addition, even though CWGUSI 1.8.0 is included with CW Pro 2, MacLynx won't, er, link with it (it can't find stdout or _Stdout, depending on where the symbol occurs). I don't blame the GUSI authors for this; that's Metrowerks' fault because the Metrowerks Standard Library (MSL) made stdout a preprocessor define, not an actual compiler symbol, meaning the pre-built version of 1.8.0 included on the CD could not have been built with CW Pro 2 in the first place.

That said, because reproducibility with classic Mac OS homebrew is a problem (the cool kids now use Retro68 but this doesn't help much with old codebases), I'm sticking with CWGUSI 1.8.0 because it's already on the disk and for MACINTOSH software there's a veritable GARDEN worth of places to find CodeWarrior Pro 2. Rather than go to the inconvenience of rebuilding it again, this ugly hackery in the main MacLynx source file made the linker error go away and doesn't affect the SIOUX debugging window.

#undef stdout
FILE *stdout;

I also purged and cleaned up the filepaths in the project after converting it to the "new" IDE. The only other piece you'll need to build is Internet Config Programmer's Kit 1.4, which you can get from Info-Mac. Everything else is nice and relative to compiler and project so it's portable again:

There are now also separate prefix files for debug and release builds, too, so you can cut out debugging code completely from a release build. Right now this only excludes the SIOUX debug window from the release version, but I'll be looking for more targets to cut the fat in future versions.

That's not to say there weren't other significant problems with the toolchain upgrade, even after the application built successfully. As another symptom that CWGUSI 1.8.0 was mismatched, various errnos were wrong because GUSI's set originally encroached on other errnos used by the MSL and used a different set of values to compensate. That was no longer the case with CW Pro 2 and thus manifested as failure to open any network connection at all (because errno didn't correspond to any of the expected signals you would get on a non-blocking socket), and required forging new processor defines that matched up with the expected values.

With that fixed, HTML pages came up all smushed together, with no links. Gopher menus appeared fine, but anything that generated HTML from a Gopher menu (like a CSO search) also didn't work, as well as Lynx's internal interfaces for downloads and image helpers. Some flailing around in the CodeWarrior debugger traced the problem down to the binary search algorithm that finds SGML tags: it wasn't matching any, even though the tags were there and correct. The problem turned out to be Lynx's internal strcasecomp (not strcasecmp), which seemed to barf on the MSL's implementation of TO_LOWER() and was returning unexpected values. I rewrote it in an embarrassingly obvious form to the compiler and finally got sane results.

With the browser basically working again, I turned my attention to something which always used to annoy me in the day: if the pointer is over the MacLynx screen, it flickers. The issue here turned out to be how Olivier had originally merged the Mac event loop and Lynx's main loop. Lynx waits patiently for a key, but you have to keep spinning the Mac event loop to service the GUI and allow other apps to run. Thus, the Mac event loop, even if the user is doing nothing, goes through all the work to update the status line and screen as if the user had done something, and the Mac curses implementation is inefficient enough that this ends up requiring an entire screen refresh every. single. tick. of the main loop. That's why the pointer flickers, and why keystrokes lag.

To reduce the need for keystrokes, I expanded the mouse support (which right now is pretty much limited to selecting links and manipulating the pulldown menu) to make the previously unused scroll area live. You can now page back and forth in a document by clicking in the top or bottom halves, and then click on links, reducing waiting for the main loop to catch up with keying around from link to link. But the pointer still obnoxiously flickered, so I worked on several ways of reducing the screen update frequency. The Mac curses is rather dumb and I wasn't sure how effective making it do partial updates would be (an exploration for another day), but it seemed like I could short-circuit all that work if a key wasn't being pressed. This turned out not to be the case. Lynx desperately assumes you pressed something, and trying to skip whole portions of its event loop when you didn't would maddeningly cause it to drop or delay other keystrokes. Eventually I added a simple global hack to Mac curses that just turns refreshes on or off and I tried to batch them as much as possible, which besides improving responsiveness also cut out a lot of CPU load too. It might have been possible to extricate the two loops with a little thought using the Thread Manager and spinning both loops separately, but I didn't want to introduce a new dependency (I like it being able to run on very minimal systems, and Thread Manager wasn't a standard part of Mac OS until System 7.5), and I didn't want to add too much complexity by telescoping yet another event loop inside Lynx's wait-for-a-key routine, at least not this time around.

Now, after everything that's been added and updated, there is one thing that's been removed: the PowerPC native build. That might seem strange coming from a vehement pro-Power ISA bigot like me (typing this post on a Raptor Talos II POWER9 workstation, even), but the reason is simply because I don't want to deal with multiple versions of CodeWarrior on my MDD G4, so I'm building this on my Quadra 800 instead and only a 68K target is available. Doing so, however, also allows me to test it on the same machine in System 7.1, System 7.6, MacOS 8.1 and A/UX 3.1, and keeps any additional toolchain changes I may need to make localized. I may resurrect the PPC build in the future but Classilla with styles off is more functional than MacLynx PPC, and of course this 68K build will run just fine on a Power Mac anyway.

What's next? I thought about porting a later Lynx but later releases may incorporate changes I might not want, and I have no idea if they would even build. More to the point, I haven't even been able to enumerate all the other changes Olivier already made to get it working, all of which would probably have to be adapted or dragged forward. I think improving its handling of <div> tags, especially with respect to positioning, as well as tables and HTML entities will get us a large part of the way to parity without introducing other potential incompatibilities. There are unused menu resources in MacLynx; those should be hooked up. I did initial work on a dialogue box for entering URLs instead of using Lynx's prompt, which is much faster than typing into the curses-driven prompt and lets you use cut and paste and the mouse, but that isn't in this version yet. And, because Lynx does know how many pages long a document is, it should be possible to actually have a real scroll bar which works by sending events to Lynx instead of the up/down mouse shortcuts (for that matter, we also need a mouse hotspot for backing up -- which is actually in this release, but I don't know if I'll keep it in its present location).

Finally, there's the whole topic of TLS 1.2. MacLynx can only access TLS sites by using Crypto Ancienne as a proxy (or anything else that offers an HTTP-HTTPS proxy, but I haven't seen others). It might be possible to build this into Lynx, but also keep in mind that most 68K Macs aren't fast enough for modern servers. My Quadra 800 is clock-chipped to 40MHz and is able to keep up by running the proxy self-hosted in A/UX or MachTen, but in my experience systems start running into trouble below that speed: my 36MHz Solbourne S3000, a SPARC, times out on a couple sites, while my 25MHz '030 IIci with no cache card can sometimes take up to 20 seconds to do a transaction and failed on most of the sites I tried. With those numbers it's painfully obvious a 8MHz 68000 wouldn't have a chance. For these, it makes more sense to run Crypto Ancienne on some other system and have the Mac talk to it because only the fastest 68040s are swift enough to do so themselves. However, current versions of Lynx don't allow offloading TLS to another system using an HTTPS URL to an HTTP proxy anymore, another reason to stick with 2.7.1.

Anyway, visit the MacLynx page for updated builds and the source code, and post your comments. Watch this blog for beta 4 when I feel up to it.

I've been working more frequently with A/UX as actually a user rather than merely a collector/tourist to improve support in Crypto Ancienne (by the way, git tip has fixed the known remaining issues with A/UX and it now passes my internal test suite). Here are a couple things that don't appear in the manual or in the otherwise comprehensive A/UX FAQ.

If you're puzzled why you can't Telnet into your A/UX machine, nfs0 needs to be set to wait and net9 needs to be set to respawn in /etc/inittab, or incoming connections like Telnet and FTP don't (or, depending on what inetd you're using, connections may just sit there and inetd fails to spawn the daemon, sometimes for as long as a half an hour). This means you need to be running /etc/portmap as well as /etc/inetd; you can't run just inetd. You should probably also upgrade to jagubox inetd. You might be able to get around this by not using portmap services in /etc/servers but I haven't needed to try that.

If you are sitting at the "Welcome to A/UX" dialogue box (i.e., you aren't logged into the machine and you have autologin disabled), you have to select Special, Restart to properly unmount the file systems. Selecting Special, Shut Down bizarrely leaves them dirty (forcing a long and unnecessary fsck on the next boot), and running shutdown from a root console doesn't consistently work right either. So now I have it rigged to not autoboot from the Mac boot partition, I select Restart from A/UX when I'm done, and then when the machine comes back up in the Mac boot partition, the A/UX filesystem is clean and I just shut down the Mac partition without continuing through the boot. The downside is I have to press Cmd-B manually to start the boot when I do want to be in A/UX.

This machine runs A/UX with my custom partitioning, which I document in more detail elsewhere.

I do have to say that on my clock-chipped Quadra 800 (to 36MHz), A/UX is a real pleasure. If they had ported it to PowerPC natively I bet it could have really been something spectacular even though it was sort of a dog's breakfast under the hood (but in that respect no worse than the classic MacOS).

Only a few people remember there was once a native Lynx port to the classic Mac OS, circa 1997. A text-based browser on a GUI-only computer would seem contradictory, and certainly wasn't congruent with the HIG, but it was an honest-to-goodness Lynx 2.7 in a terminal-like window and it worked. It also has very low system demands (basically "just" System 7), making it one of the few web browsers you could even run on a Mac Plus. I used it quite a bit on a Mac IIsi, which was the first Mac I ever owned and for awhile the only web browser that machine ever ran.

Dusting it off as a test case for a secondary project, I discovered it has a problem which was not apparent during the days I used to use it: it inappropriately sends a Content-Encoding header that says it can accept gzip, but (possibly a MacLynx-specific bug) it is unable to decompress and view any pages sent accordingly. Back in the day not many servers supported that, so no one really noticed. Today everybody seems to. As a stopgap I figured the easiest way to fix it was simply to make that header incomprehensible and thus the server would ignore it, so I monkeypatched the binary directly to munge the gzip string it sends (the data fork for the PowerPC version and inside the DATA resource for the 68000 version). Ta-daa:

Now, credit where credit is due: it looks like Matej Horvat discovered this issue independently about a half-decade before this post. His solution was a bit better: he munged the Content-Encoding string itself rather than its value. This is not quite so straightforward in the 68000 version because of how strings are encoded in the DATA resource, but as a belt-and-suspenders approach I went ahead and implemented his approach too (after all, I suppose it's possible my munged string may match an encoding method that could be supported in the future).

Olivier's old site has not been up for years, so I resurrected it from a local copy and MacLynx is again hosted this time on Floodgap. Unfortunately I don't have his old French localization, but I do have the source code also (for CodeWarrior Pro 2), and you can download this unofficial "beta 2" from there as well. Both the 68K and PowerPC versions have both patches.

Sharp-eyed readers will have noted something a little odd about the screenshot. The secondary project works, but needs some polish and a couple minor bug fixes. More later.

I have the very first computer my parents ever bought (a Tomy Tutor, a strange relative of the Texas Instruments 99/4A). I have the first Mac I ever owned, a Macintosh IIsi which was a gift from a family at church; they got it as part of some pallet of stuff they bought and had no use for it. And I still have the first Mac I ever bought new. In fact, now that I think about it, I think this was the first computer I ever bought new. Here's its sales receipt: a Power Mac G4 DP 1.25GHz (what is colloquially called a "Mirrored Drive Doors" or MDD variant). This was, at least officially and at that time, the last generation of Power Mac that could boot Mac OS 9 natively and the most powerful specification Apple offered that did so. In fact, I bought it specifically for that reason even though I was a starving student and really couldn't afford it because I still had, and have, a big investment in classic Mac applications. I don't remember if I got the education discount, but as specified with dual 1.25GHz 7450 CPUs, 512MB of RAM, 120GB hard disk, 64MB ATI Radeon 9000 Pro and an extra 512MB stick it cost me $3339 before tax in December 2002 (they comped me the install fee). The Quad G5 I bought a little over three years later cost roughly the same out of pocket, so in today's dollars the MDD was actually more expensive. I bought it on an Apple Loan, natch; the Quad I paid for in cash.

The MDD is still connected to my KVM along with my SGI Fuel, Quad G5 and the Raptor Talos II I'm typing on which is my current daily driver. The MDD was my daily driver for about three years, dual-booting Jaguar and Mac OS 9.2.2. Even after the Quad G5 replaced it as my primary machine, I upgraded it to 2GB of RAM (though Mac OS 9.2.2, now its sole operating system, only supports 1.5GB), a 256MB Radeon 9000 Pro and a Sonnet Encore/MDX processor card with dual 1.8GHz 7447A G4 CPUs. It also got a second SuperDrive and a second hard disk, a G4Port serial adaptor to replace the modem which I rarely used and a Formac ProTV tuner/digitizer, and it still has two slots and two more drive bays free. It's not survived perfectly -- the audio jacks got mangled in an accident, so I have to use a USB adaptor for audio in and a set of Pro Speakers -- but the important stuff still works dandy. Classilla is built on this machine, along with my work on Power MachTen and of course all those great late 1990s Mac game ports (though No One Lives Forever, which I bought with it, requires 10.1.4 so I play it on the G5 in Tiger).

On Sunday I was making progress on getting the classic Mac OS to speak TLS 1.3 with a little help (more about this soon). I pressed the power button to transfer my work over and test it and ... nothin'.

MDDs are great machines, but they're notorious for two particular failings: they can howl like anything (nicknamed the "Windtunnel G4") when they heat up, and their power supplies suck. The power supply was undoubtedly what failed, so that means ... a Refurb Weekend!

Ugh, dusty. The Post-It note on the front was to remind me of the Open Firmware path for the internal hard disks. Let's clean it up a little first. (By the way, I hate the speaker grille for these things, so I never installed it.) The MDD was the last of Apple's "outrigger" Macs. This started with the Power Mac 7200, 7300, 7500 and 7600, and then evolved into the desktop Beige G3 and then reached its zenith with the Blue and White "Yosemite" Power Macintosh G3. These, along with the Power Mac G4, simply open by lifting a latch on the side and the entire motherboard swings down. No screws. Upgrades are a snap.

At this point we paused for a few minutes to blow out all the dust.

Naturally, the power supply (up top) is non-standard, just to be difficult. It is a modified ATX supply (in a weird case that reminds me of the Mini-ITX form-factor, at least in width) with different pinout that in addition to the usual voltages also provides 25V for the Apple Display Connector on the ATI GPU. They came in a 360W Samsung and a 400W AcBel. Fortunately I keep spares, so we will be replacing this 400W AcBel with the NOS 360W Samsung I had in my stock closet. (It is possible to rewire an ATX supply to provide the voltages sans the ADC's 25V line, but an ATX supply won't fit on the shelf inside the case to hold the PSU. We'll consider potential mounting options for the next time this thing chews through one.) Giving the new PSU a quick test after unplugging the duff PSU's main power connector. You can see the power LED on the board and the fan for the Sonnet upgrade both activate and the Mac "bongs." Time to install it. The main power connector and the power connector for the accessory drive bay run through the back of the case. This means the optical drives need to be pulled out to access them. Two screws, one at the top front facing the case front and one at the bottom rear facing you, hold the optical drive cage in place. Remove those, take the Faraday panel off the back, unplug the ATA and power cables and set the cage aside. The main case fan doesn't need to be unplugged, though it might make this easier. Either way, lift it straight up from its little guides and put it aside. The main power cable is now exposed. To remove the power connectors to the hard disks in the rear drive bay, remove the screw from the drive cage's little eyelet (if the screw is there), then find the release lever on its left, pull it towards you and slide the drive cage up just a bit to free it from its socket. Remove the power connectors and, if you like, the ATA connectors as well and set it aside. If you choose to remove the ATA connectors, this is assisted by sliding off the flat black cable clip on the bottom of the case that keeps the ATA cable from bunching up. A little aperture just in back of where the main fan sits is where the main power and the power lines for the accessory hard disk bay (unpopulated here) are threaded. Pull them out one at a time. Two screws attach the power supply. The first is a 2.5mm hex screw. This usually needs some cranking to remove and replace. The second is a Phillips-head screw that bolts a little metal eyelet on the end of the PSU to the case wall. Remove both, slide the PSU from the rear of the case towards the front and take it out. Install the new PSU and bolt in both the front hex screw and rear Phillips screw. (The hex screw will spin uselessly if it doesn't mate. You need both in because without doing so the PSU will tend to wiggle or shift trying to connect the power cord.) Thread one of the power connectors and the main power connector back in through the rear aperture. Reconnect the main power. Whenever I have one of my Power Macs open, I always check the 3.6V 1/2AA PRAM battery. This one was, not unexpectedly, dead as a doornail (that's 18.6 millivolts). Fortunately, I keep some of them in stock also. Replace the main case fan, reconnect the hard disk and optical drive cages, and close it back up. Back in action. I needn't point out that Mac OS 9 absolutely screams on a machine of this specification. And just as pretty as ever. I actually do have an Apple Studio Display in storage with an ADC connector I've thought about pairing this with, but fortunately I also have the ADC converter box (basically a power supply that breaks out DVI and USB), so even if I did convert this to some sort of mutant SFF ATX (or SFX) power supply I could still use the Studio Display. In the meantime, I'll see about possibly getting this supply professionally refurbished. I have at least one other in stock along with a full body double but I'd like to keep this trusty machine going as long as I can.

One of the machines in my office is a non-descript Am5x86/133 (486 class, infamously claimed by AMD to be "Pentium 75 equivalent") in a generic tower case that exists purely to play MS-DOS games I like and run a few DOS-only applications. Its name is Alex, after Alex St. John, who was the evangelist for DirectX during his tenure at Microsoft (despite the fact this machine does not have any version of Windows on it).

Being a late 486-era system it has an ISA motherboard with a couple VESA Local Bus slots and not a scrap of PCI. Most of us of a certain age will remember how rickety lots of cards in a VLB/ISA system could be, though fortunately the (ISA) Sound Blaster ViBRA 16X and (VLB) S3 86C805-P cards work, so games work and that's what it's largely here for anyway. In fact, some games only work on this system that won't work with my AT&T Pentium 75. One thing I have never gotten working on it, however, is networking. I've tried several ISA network cards, even a Xircom parallel port adaptor, and nothing will talk to anything else on the network -- with the exception of AppleTalk using Apple's own ISA LocalTalk card.

The Apple LocalTalk ISA card was actually a fairly early release, appearing in 1987 just two years after LocalTalk debuted to allow Macintoshes to connect to the new LaserWriter printer, an integral part of the benighted Macintosh Office initiative. The fact that AppleShare for the Mac appeared the same year is notable, since PC support for LocalTalk networks must clearly not have been an afterthought at Apple. Although a company called Tangent Technologies was apparently first to the punch in 1985, it doesn't look their PC MacBridge product sold in any large numbers, and I've never seen one myself.

The card uses a standard 8-bit ISA slot and has its own 6502 CPU (a Rockwell R65C02) running at 3.6864MHz with an 8K 2764 ROM ("© APPLE '86") and an 8K 6264 RAM chip. Like Macintoshes, the RS-422 serial support is provided by a Zilog Z8530 Serial Communications Controller (here the second-source VLSI Technology VL8530). The "PCI" marking in this case means PC Interface, not actually PCI slot logic, provided by an MMI PAL16R4ACN programmed for the purpose. I don't know what the DIP switches do; my cards have switches 1, 3, 4 and 6 off and 2, 5, 7 and 8 on, so I assume those are the factory settings.

The sticker 630-5306 on top is covering the original Apple part number, 630-0113. I don't know why Apple used a different number, because I have a -0113 also, and they seem to be otherwise identical. Just to make things confusing, there is also a later 630-5306 card ("©1986/87" rather than "©1986") with that part number actually printed on the board that has a later ROM copyrighted 1989.

Here it is installed in the back of Alex. You'll note it does not have the more typical Mac 8-pin mini-DIN connector and instead has a more PC-like DE-9 serial port. That's actually because Macs of that generation didn't have mini-DINs either, so you had to get the Apple LocalTalk Locking Connector Kit DB-9 [sic] package, sold separately of course, to hook it all up. However, I have a Farallon PhoneNET connector plugged in here instead which they manufactured with a DE-9 port as well, and I then use a Dayna EtherPrint-T to bridge the LocalTalk segment to wired Ethernet. The EtherPrint-T doesn't do MacIP (that is, IP over LocalTalk) but it does do LocalTalk to EtherTalk bridging pretty much seamlessly and was less mucking around than with a GatorBox, so that's what we've got.

The software side was provided as a DOS Terminate and Stay Resident (TSR) program, sold as AppleShare PC. I have both AppleShare PC 2.0 (1987) and 2.0.1 "2.01" (1989), but unless you have very old machines on your network you really want 2.0.1 for proper support of AppleTalk Phase 2. Interestingly, the earlier version was on 3.5" floppies, but the later version I have is on 5.25". The TSR provides a "desk accessory" triggered by a hotkey combination (by default Ctrl-Alt-Esc) that pops up and lets you log on, mount and unmount network shares as DOS drive letters. Since I have two hard disks and a CD-ROM as C: through E:, the AppleShare volume invariably appears as F:.

Let's see how this works. I took these pictures transferring across yet another vain attempt to get the NIC working for useful purposes (it failed, of course, because this machine hates me). Rather than do screen captures I've chosen just to photograph it with my phone to give you the full 1990s PC CRT monitor experience.

Booting up. All the little submodules consume rather a lot of conventional memory to the point where many games won't run, so one of the first things I did after installing the software was set up a boot menu (it runs MS-DOS 6.22) with separate profiles for games and the LocalTalk card. With the 2.01 software loaded, and the sound and CD-ROM drivers, I have just 432K of conventional memory free despite loading 66K of everything else into the UMB. (I don't miss DOS memory management at all.)

The desk accessory immediately starts after load to let you mount a volume. Here I will mount Jonathan, my Power Mac 7300 with a Sonnet G4/800 running Mac OS 9.1. You don't need to know the other servers, spank you very much, but the software seems only to "like" "real" Macs: it will not log on properly to thule, my NetBSD Macintosh IIci running netatalk, despite it being a "real" Mac, and it obviously doesn't know how to do AFP-over-TCP so you're limited to hosts running Jaguar (10.2.8) and prior.

Logging on. Using function keys to proceed is not really intuitive. One wonders if Apple did that on purpose.

Jonathan has two drives, each an individual volume (HFS+ volumes work fine), so we will pick the main drive and mount it as F:. As a convenience you can automount drives on boot, just like a Mac could.

And here are the contents of the newly mounted network share. Files and folders that have a resource fork have an exclamation point prepended as a visual warning they are not PC files, and there are no LFNs (please, it's 1989), so filenames just spill into the extension (!System.Fol for System Folder). If names clash, a digit is used (!Games_t.hat versus !Games_t.ha0, using underscores to replace spaces within the filename and extension fields). Just two files show up without a "!", which are the ones I earlier FTPed over to the Power Mac 7300 and have only a data fork.

While network transfers are in progress, a little set of arrows appears at the upper left, almost sorta kinda like a Mac would do.

Files are copied (regular old DOS COPY), so let's log off. It still doesn't work, of course, and I'm pretty sure I have the right packet driver and everything else. I'm going to have to take this machine apart down to the slots to figure out why. Anyway!

AppleShare PC 2.01's "About" box, just for completeness. Interestingly, the PC driver is given as version 2.61, but everything else is 2.01. I don't know anything about the authors. Do you?

There are some odd things about this card but it could again just be something wacky about this system. One of the oddest is that the packet driver I tried to set up for the SMC EZ 1660 NIC it has in it now actually knocks the LocalTalk ISA card completely off line, as in it won't respond to commands anymore until I power down the system, let it sit a bit, and bring it back up.

LocalTalk was gradually displaced by EtherTalk as Ethernet became more commonplace, and the PC ISA card was relatively expensive and limited to environments where Macs and PCs co-existed, so Apple never observed strong sales and discontinued the package with the rest of their LocalTalk offerings around 1991. There were a surprising number of third-party versions, though. After Apple quit LocalTalk entirely and handed the market over to Farallon, Farallon produced their own version of the card, allegedly strongly based on Apple's, until 1993 or so and integrated the software into the Windows 3.x versions of Timbuktu. It was still DOS-based, however, and the two halves I'm told never fit together well; issues with Windows 95 seem to have limited its further evolution. Daystar reportedly bought out Tangent and produced additional cards branded as the Daystar LocalTalk PC Card, but I've never seen one of those either. Dayna and Centram Systems also apparently made their own versions too; a company called COPS bought out Dayna's and Daystar's products and continued to produce them for several more years. Some of these cards had proper DOS ODI and NDIS drivers, so it was eminently possible to use those under Windows 95 or 98 with Miramar MacLAN or Thursby TSSTalk. NT 4.x drivers also apparently existed for the Daystar card(s). Miramar MacLAN is particularly handy as it allowed peer-to-peer networking with other AppleTalk clients without needing Windows NT.

Other than ISA cards, there were parallel port ones, but these were apparently crummy. One company even made a prototype PCMCIA LocalTalk adapter but it was never released.

Besides regular EtherTalk, some DOS Internet suites provided packet drivers for the LocalTalk card, the analogous equivalent to MacIP on a "real" Mac. However, you need to set up a AppleTalk IP router for this, so I haven't tried this functionality and it would be just as slow as MacIP would be otherwise. Still, I guess it beats no networking at all. Overall the card is an interesting device, it worked out of the box and it's still working reliably years later, so if I end up only being able to transfer files this way there are worse first world problems to have.