Posted on

Ancient Web: InterGuru Still Converts Address Books From Eudora, Pine, Elm, and AOL

Moving an address book from one mail program to another used to be enough of a technical problem that somebody built an entire Web service around it. InterGuru says it has been doing exactly that since 1996, and the converter is still sitting there surrounded by the names of mail programs that now read like a software archaeology checklist.

Visit InterGuru’s E-Mail Address Book Conversions

The page converts contact lists between formats used by Eudora, Pine, Elm, Pegasus, CompuServe, Spry, Lotus cc:Mail, Lotus Notes, Microsoft Internet Mail, Netscape, AOL, Claris Emailer, T-Online, LDIF files, CSV-style databases and several other formats.

That list is the interesting part.

Today contacts are usually buried inside a cloud account and synchronized behind the scenes. In the 1990s and early 2000s, changing mail clients could mean figuring out which program stored names in which proprietary file, exporting what you could, and praying the destination application understood it. A Web-based converter was not a novelty. It solved an irritating migration problem that ordinary users actually encountered.

InterGuru’s interface still reflects that world. You choose a source format, choose a destination format, push Continue, and follow the instructions. There is no attempt to disguise the machinery behind a giant onboarding flow. The page assumes you know whether your contacts came from Pine, Eudora, Netscape 3, Lotus Notes, or a Unix .mailrc file.

One surviving subpage even preserves a 1998 update about a small utility for extracting names and addresses from Microsoft’s Exchange personal address book and generating text files suitable for import elsewhere. The language is casual, practical and unmistakably from the era of people swapping little conversion programs because somebody needed one.

For webmasters, the durability lesson is almost embarrassingly simple: a narrowly useful page can outlive the software ecosystem it served. InterGuru is now partly a reference document for dead mail clients, but the original problem is still understandable because the site names the formats, applications and workflow precisely.

That kind of specificity is why the larger 1,967 Ancient Web Domains research list is useful. Old pages often preserve the connective tissue between technologies that modern histories skip.

InterGuru is still online, still recognizable, and still asking questions like whether your address book came from Netscape 3.

Explore InterGuru

Posted on

Ancient Web: DPGraph Drew Eight-Dimensional Math in Assembly Language

DPGraph is a mathematical graphing program from the late 1990s with a specification that sounds increasingly strange the longer you read it. It draws dynamic and interactive mathematical visualizations extending from ordinary two-dimensional plots through what its creator describes as eight-dimensional graphs, and the whole program was written in assembly language.

Visit the DPGraph website

Dave Parker released DPGraph in 1999, and the surviving update history still traces changes from that first release forward. The program was built for interactive mathematics and physics visualization: equations, animated surfaces, transformations, implicit plots, and other objects that are easier to understand when they can be manipulated instead of frozen into a textbook image.

Then there is the implementation detail. DPGraph’s site says the program was written entirely in assembly for speed. That was not unheard of in the 1990s, but an entire high-level visualization application written that way is still a pretty aggressive engineering decision. Modern software stacks often require several layers of frameworks before a window appears. DPGraph went in the opposite direction.

The site’s own usage claim is equally ambitious: it says more than two million mathematicians, physicists, teachers, and students at more than a thousand schools were licensed to use the software. That number is the site’s claim rather than an independently audited statistic, but it indicates the scale Parker believed the program had reached.

The old compatibility notes are now part of the attraction. DPGraph and its viewer were distributed for generations of Windows stretching from the Windows 95/NT era into Windows 10, with references to running under Linux and emulation as well. The viewer could also be used to present graphs through Web pages, a reminder of the period when downloadable helper applications and browser-linked viewers were normal parts of publishing interactive material online.

The latest prominent news on the site dates to 2019, and Parker now describes DPGraph as freeware with no foreseeable updates. That is not necessarily a sad ending. A piece of specialist software can be finished without becoming useless.

For software historians, the site preserves release notes, documentation, examples, downloads, and the author’s own description of what he built. For teachers and mathematically curious visitors, it remains a doorway into a visualization tool that came from a very different software culture.

It also illustrates one of the recurring patterns in CacheRat’s 1,967 Ancient Web Domains research list: small software sites can outlive entire commercial distribution ecosystems because the author kept the files and documentation in one stable place.

The dimensions may be difficult to picture. The old website explaining them is pleasantly straightforward.

Explore DPGraph, its history, documentation, and downloads

Posted on

Ancient Web: ToastyTech Never Stopped Making Doom WADs

Some people played Doom in 1993 and moved on. The person behind ToastyTech apparently interpreted Doom’s release as a long-term maintenance obligation.

Visit ToastyTech’s Doom pages

The page opens with a simple explanation: id Software released Doom on December 10, 1993, and “I never stopped playing.” What follows is less a polished portfolio than a fossil bed of Doom enthusiasm—custom levels, screenshots, old versions, experiments, joke material, music files, and work-in-progress archives accumulated over years.

MarsWar is the obvious centerpiece. It is a Doom II megawad with its own story about a Martian terraformer, an invasion from Earth, and space-warp ships built by a company whose initials happen to be “MS.” The site keeps multiple versions available, including older builds because people asked for them. That small detail says a lot about the culture around old game mods: history survives because somebody decides an obsolete ZIP is still worth leaving online.

Elsewhere there is a Doom 1 MegaWad compilation, a Hexen level, Skulltag and jDoom material, Doom Alpha levels modified for deathmatch, original MOD and MIDI files, Ranma 1/2 character skins, unfinished maps, and even a Firefox-themed WAD. There are also screenshots from very early Doom versions and a “Doom Guys Vacation” section whose description is simply: went to hell, took pictures, posted them here.

The important thing is not that every file is a masterpiece. The page preserves how PC game modding actually looked when personal websites were the distribution system. A ZIP file sat next to a TXT file. Screenshots were separate. Compatibility notes mattered. Old versions stayed reachable. The author’s own jokes, experiments, and unfinished work remained mixed in with the serious releases.

Modern mod sites are much better at indexing and downloading. They are often worse at preserving the creator’s original neighborhood around the files. ToastyTech still has that neighborhood.

For researchers studying Doom, homebrew level design, WAD distribution, early fan culture, or the long tail of DOS-era games, these personal pages can be more revealing than a clean database entry. They show what the creator thought belonged together.

That is the same reason CacheRat maintains the 1,967 Ancient Web Domains research list: sometimes the useful historical unit is not the file. It is the whole weird page around it.

Doom is still alive almost everywhere. ToastyTech is interesting because it preserves one person’s uninterrupted relationship with it.

Dig through ToastyTech’s Doom stuff

Posted on

Ancient Web: The First Church of Grady Booch Made Object-Oriented Design a Religion

In 1997, somebody looked at the increasingly serious world of object-oriented software design and decided what it really needed was a church. The resulting First Church of Grady Booch is still online, still speaking in inheritance hierarchies, and still treating software methodology with exactly the amount of reverence programmers tend to deserve.

Read the Booch Bible

The joke works because Grady Booch was not an obscure name. Booch was one of the major figures in object-oriented analysis and design, and in the mid-1990s he worked with Jim Rumbaugh and Ivar Jacobson on the effort that became the Unified Modeling Language. UML was an attempt to bring order to a period when competing object-modeling systems had multiplied into what the Object Management Group itself describes as the “method wars.”

The Church takes that seriousness and runs it through the class hierarchy.

Its front page explains that the church is itself an object. It inherits from Grady Booch, becomes a superclass of the people, and occupies a church building that is a subclass of Religious Structure, which is a subclass of Building. The joke is not merely “programming is a religion.” It is written in the actual conceptual vocabulary that object-oriented programmers were spending their working lives thinking about.

The linked Booch Bible extends the bit into scripture. That makes the site a small but unusually clean fossil of 1990s programmer culture: people building a public joke for other people who would immediately understand terms such as classes, inheritance and object models without needing a glossary or a platform algorithm to deliver it to them.

There is also a useful historical accident here. The Church says it was founded in 1997, the same period when UML was becoming a formal standard. The parody therefore survives beside the technology it was parodying. Modern developers can read polished histories of UML anywhere; this page shows what programmers were joking about while that history was still happening.

For a webmaster, the site is another reminder that a tiny joke can outlive entire generations of frameworks if its dependencies are basically “HTML and a domain name.”

CacheRat’s larger 1,967 Ancient Web Domains research list contains many sites like this: not necessarily historically important on their own, but excellent evidence of how people actually used the Web.

The First Church remains online, and its sacred text remains mercifully shorter than most enterprise architecture documentation.

Return to the Booch Bible

Posted on

Ancient Web: Don Eyles Explains What the Apollo 11 Computer Alarms Actually Meant

The Apollo 11 computer alarms are usually told as a thirty-second story: alarms appeared, Mission Control said continue, and the landing succeeded. Don Eyles’s version takes about as long as it should.

Read Tales from the Lunar Module Guidance Computer

Eyles was one of the programmers who developed software for the Lunar Module guidance computer at the MIT Instrumentation Laboratory. His paper, presented to an American Astronautical Society conference in 2004 and expanded online with illustrations and comments, explains the system from the perspective of somebody who had actually lived inside the code.

The famous Apollo 11 alarms are only part of it.

During powered descent, an interface problem involving the rendezvous radar consumed roughly 13 percent of the computer’s duty cycle. The overloaded computer issued program alarms and restarted work in a controlled way, discarding lower-priority tasks while preserving the important ones.

That distinction matters.

The computer was not simply “crashing.” Its executive system was doing something recognizably modern: managing scarce processing time under overload and keeping the critical work alive.

Eyles also describes a less famous problem involving the Lunar Module’s descent-engine throttle control. Erroneous assumptions and a marginally stable control algorithm could produce violent throttle oscillations. His account reaches backward to Apollo 5 and forward through changes made after the early lunar missions, showing how flight software evolved because the spacecraft kept teaching the programmers things the simulations had not.

Then there is the hardware.

The Apollo Guidance Computer worked with 36K words of fixed memory and 2K words of erasable memory. The Lunar Module and Command Module each carried one. Eyles notes that, counted together, the Moon landing was accomplished with about 152 kilobytes of onboard computer memory.

That number is fun trivia until you read what the software actually did.

Navigation. Guidance. Engine sequencing. Displays. Radar interfaces. Crew interaction through the DSKY. Real-time task scheduling. Failure recovery. All while flying a machine that could not be rebooted by walking over to it.

The page matters in 2026 because it is not a retrospective assembled from simplified quotations. It is a technical witness explaining the architecture, mistakes, fixes, naming conventions, people, and operational pressure in enough detail that the old software becomes engineering again instead of mythology.

CacheRat’s 1,967 Ancient Web Domains research list keeps finding pages like this: documents sitting quietly on personal domains that are better than the summaries built on top of them.

Apollo had plenty of heroes.

One of them was a scheduler that knew which jobs could wait.

Read Don Eyles’s complete Apollo paper

Posted on

Ancient Web: MS Word Sucks Turned Software Frustration Into a Manifesto

Before software complaints became app-store reviews, angry tweets, and one-star screenshots, somebody had to buy a domain, write several thousand words, and explain exactly why the program deserved to be thrown into the sea.

Read MS Word Sucks

The page known as MS Word Sucks is a fine specimen of that older Internet tradition. It is not a tidy product review. It is a sustained grievance against Microsoft Word, written with the energy of someone who has been interrupted by AutoCorrect one time too many.

By 2004 the essay was circulating widely enough to become the subject of a Slashdot discussion, where readers quoted some of its more volcanic passages and immediately began arguing about Word, OpenOffice, LaTeX, document formats, user interfaces, and whether the author’s suffering was self-inflicted.

That reaction is almost as historically useful as the rant itself.

Software used to inspire manifestos

The complaints are recognizable even now: unwanted formatting, preferences that refuse to stay put, automatic features that feel less like assistance than sabotage, document behavior the user did not request, and the suspicion that increasingly complicated software had stopped serving the person sitting in front of it.

What makes the page feel old is not the subject. People still hate software.

It is the form.

A frustrated user did not need to compress the complaint into 280 characters or optimize it for a video. He could publish a plain HTML page, swear at Microsoft for as long as necessary, and leave it sitting on the public Web where search engines, mailing lists, forums, and friends would eventually find it.

The Web was full of pages like this: personal essays that were too opinionated for documentation, too specific for journalism, and too long for anyone except the author and the exact stranger who desperately needed to know that somebody else had noticed the same stupid behavior.

That is why these pages matter as artifacts. They preserve the emotional history of computing, not merely the release history.

Microsoft Word can be documented through version numbers, file formats, screenshots, and feature lists. A rant tells you what using the software felt like to at least one technically literate person while those design decisions were still current annoyances rather than historical curiosities.

CacheRat’s 1,967 Ancient Web Domains research list includes pages like this because old software culture was partly built from documentation and partly built from people yelling at the documentation.

Sometimes the rant ages badly.

Sometimes, twenty years later, you read it and immediately recognize the exact argument.

Revisit the original MS Word Sucks page