Software, technology, sysadmin war stories, and more. Feed
Friday, June 15, 2012

Back when "The Internet" was floppy-based

Remember when "The Internet" came on floppy disks because normal consumer operating systems didn't speak TCP/IP natively? I sure do. One summer, I was given the task of making a custom set of disks so that my users could get online from their old Windows 3.1 machines. They'd need a web browser, mail client, and a bunch of DLLs and config files. Expecting our users to somehow install all of those things correctly was unreasonable.

I came up with a better idea: I would write something which would install and configure all of that stuff from a single program. My program had to cope with a bunch of situations all by itself in order to minimize the support calls which might arise. It was supposed to go out on a set of 3.5" disks and only required a single direction: "From inside Windows, run A:SETUP". The rest was supposed to be obvious.

The first thing I did was check for free disk space. I had a pretty good idea of what a full install of all of those programs would need, and would refuse to install if at least that much space did not exist. This seems obvious, but a fair number of installers would gladly run head first into a wall they could have checked for trivially, leaving debris scattered everywhere.

Then I had it make sure nothing that it planned to install was already there. If it found a match, it asked the user if it was okay to overwrite those programs and gave them a chance to bail out. This was for the unlikely possibility that someone ran it twice or otherwise had tried to install things on their own at some point.

Next, it asked for disks by volume ID. Those MS-DOS floppy filesystems could be given unique IDs, and this way it wouldn't try to open a file which did not exist on that disk. It would just loop until you fed it the right one or aborted the procedure.

In these days, most ordinary people did not have pkunzip installed, so that was the first thing it copied. Then it went through and used that to install Trumpet Winsock and something called WinQVTNet from ZIP files. Those were relatively small, and all fit on the one disk if I remember correctly. Netscape is where it got interesting.

At that point in time, Netscape 2.02 (!) didn't fit on a single floppy no matter how you compressed it, so I had to write my own tools to split it up across disks. My installer knew about this splitting scheme, and it would reconstitute the original Netscape installer from those pieces. Then it would start that program to get things going.

This was back in the days of Windows 3.1 and Program Manager, so after the Netscape installer returned control to me, I created an "Internet Tools" group and added it to the top-level Program Manager screen. This kept our new programs from polluting their system too badly. Everything wound up in one place as far as they knew.

The final disk was the "identity" disk. It contained nothing but a text file with their userid and password. The design was to reuse the "program" disks from user to user (with the write-enable tab knocked out), but the identity disk would be rewritten before being handed out again. This was my way to make sure there would be no transcription errors in usernames or passwords on those client machines. I thought it was clever at the time.

After doing all of this, it was time to look for a modem. My program attempted to open both COM1 and COM2, and stepped through a list of baud rates while sending "AT" and expecting "OK". It made a note of the highest speed at which it could get a response.

If nothing responded or if the speeds were below 19200 bps, it would abort and let the user handle this manually. If it found two modems, then they could pick. Otherwise, it took what it found and continued. I was proud of this, because people always seemed to be confused by the notions of COM ports, baud rates, parity, data bits, stop bits, and so on. The common case should be easy, and I wrote my program to make that happen.

All of this data was written into the trumpwsk.ini along with the common parameters for our dialup users and then it was done. Another note on the instruction sheet told them what to start to get things going and hopefully get online.

Of course, while this was going on, people were starting to ditch Windows 3.1 for Windows 95, and that came with just enough "dialup networking" support to make most of my work obsolete. My happy little installer probably only served a couple of users in its entire life.

We ultimately switched to a scheme where we'd point people at a web page with instructions for configuring their systems. They were expected to print a copy at work, take it home, and do it themselves.

The days of automated installers were over.