This guy tried to run a program from 1995 and you can probably guess what happened

I rummaged deep into a dusty box and found a carefully labelled, high-density, double-sided micro floppy disk.

This guy tried to run a program from 1995 and you can probably guess what happened
the cutting edge of email in 1995

Those last few days in December, between Christmas and New Years, sometimes you can lose track of the day of the week. Semi-snowbound, pajamas and nostalgia reign. This year, I rummaged deep into a dusty box and found a carefully labelled, high-density, double-sided micro floppy disk.

Whoa, my child asked, what the heck is that? Well child, allow me to explain. But first, you must understand what email was like in 1995.

Ah, its ok Dad forget it, can I go play Minecraft?

Imagine its 1995 and you need to check your email from home to talk to your Physics lab partner or someone in the Computer Science department. Your housemate is *finally* done tying up the phone, so its time for a little dial up computing:

Sounds like 56k to me

Followed by some ELM or PINE:

This is PINE 4.58, featuring a flat design, after the skeumorphic debacle that was 4.57.

And hopefully nobody else in the house picks up the phone and drops your connection while you are trying to fire off that masterful response.

Seems painful? Look, it was way faster and cheaper than Canada Post lettermail. But yes it sucked. In the spring of 1995, two friends and I believed we could do better.

Being dialed-in the entire time you were reading and composing email was a problem. Imagine if instead you could read and compose offline and then hit a button to briefly connect to the server in order to dispatch your messages and receive anything new.

As far as we are concerned, we invented the Send/Receive button.

We had approximately zero business execution. We were easily distracted and quickly moved on to other things. Soon others were offering similar capabilities for email at home.

Mercury Mail never exited Beta. 20 years later, could this thing still run?

I was going to need one of these to find out:

What technologies did this even use? I recall there was a Visual Basic user interface, with some Unix mail stuff on the backend. I remember coding on a borrowed Toshiba T5200 we called the luggable:

http://www.donellis.com/blog/the-64000-computer-2/

Now, I don’t happen have a 16-bit Windows computer around the house. For easy clean up afterwards, I spun up a Windows server with Remote Desktop preconfigured in Azure. Within minutes I had my sandbox to play in.

Hmm, Windows has changed. I don’t think this Windows is going to run my 16-bit program. Install Virtual Box. Install DOS into Virtual Box VM. Install Windows 3.11 on DOS.

For those following along, the magic trackpad on my Mac is now controlling a mouse pointer in a fresh installation of Windows 3.11, running somewhere in the Central US. Remote desktop and Virtual Box in between.

Time to install Mercury Mail, for the first time in two decades.

We have successful disk read. Copy files up to Google Drive.

Contents of Mercury Mail installation disk: 694 kb.

Download to Azure Windows Server. Need a floppy disk image to get the files into the VM. Grab an ISO program to create the disk image. First one didn’t work, format issues. Try another ISO program and success.

Run a:\setup.exe

Hot Damn.

Its happening.

That seems encouraging.

Read Me first anyone?

Known Issues…

Phone number to dial is at present at hardcoded? Oh crap. I forgot. Like its contemporaries AOL or Prodigy, Mercury Mail was a dial up service. The connection to a Mercury server was made using a phone number, not just an IP address over an established network connection. Even once I have a Mercury Mail server running somewhere, the Virtual Box in my Azure cloud server is not going to have a modem with a phone line plugged into it. That is going to be a problem.

I guess that explains the Modems.txt file…

Well, let’s fire up the mail client anyway.

Check the splash screen. That background pattern looks like a hair metal band’s pants.

Login screen, nice. Do the New User registration process, and Shazam:

We are running (sorta).

Let’s take a moment to examine some of the icon choices. The Mailbox? The Rolodex? The Pencil? Toilet iconography for Delete never got broad adoption. Caps Lock and Num Lock status indicators are curious.

How about we Compose a message?

Adjust those Modem settings. Tone or Pulse Line Type? Disable Call-Waiting?

Time to Send/Receive. But alas:

Check the domain name on last line above. I don’t remember us ever owning that domain, perhaps its just as well.

I found the source code on another floppy. So let me just get Visual Basic 3.0 installed, and I can stub out the modem stuff and get a UUCP running on a server somewhere and setup a UUCP to SMTP bridge … and I’d have my crappy email client running! Nostalgia aside, this was half-baked to start with and doesn’t have the benefit of 20 years of security hardening and simplification.

I think we have reached the end of this exercise.

What does this tell us about the permanence of networked services we create? The Mercury Mail system is incredibly simple compared to the services we build in the cloud in 2015. It uses very little 3rd party software and connected services. It is running on very little platform beyond base OS. If we can’t easily reconstitute Mercury Mail, because it belongs to a hardware and software ecosystem of another time, what hope do we have of ever reviving the systems we build today in the cloud? The answer is essentially: no hope whatsoever. If you have a system that you value, then keep it running and vital, because once it dies its never coming back.

Originally posted on December 31, 2015 to Medium by Craig Conboy