Artsnova Digital Art and Space

The Doomed Diskettes

I recently undertook the Herculean task of going through all my diskettes, moving their contents onto my hard drive if worth keeping and then disposing of them. I had been pretty good about backing up data files and program installations to the extent that over the years I had accumulated in excess of 1800 diskettes. I haven’t actually used diskettes for several years now, all of which were created on old PCs. Going back through these diskettes was like going through a dust laden trunk from the attic. The worst part of going through all my diskettes was that the data transfer rate was agonizingly slow. You get used to the speed of CDs and USB memory sticks and then you pop in a diskette and drum your fingers as you wait.

This was not my first experience with migrating to a new media. Recall that 3.5 inch diskettes were preceded by 5.25 inch diskettes. Try today to find a disk drive able to read those! But that transition was very simple given that those diskettes (at least the ones I had) only held 720 kilobytes of data and I didn’t have very many of them. That was a piece of cake migration. This was different: 1800 diskettes able to hold 1.44 megabytes of data each. Not only did I have an order of magnitude difference in the number of diskettes but each diskette held twice as much information as their predecessors.

Amongst my old disks I did find quite a few surprises. The best gem was a diskette containing the source code and executable for the classic computer game Colossal Cave. I can remember playing this text-based adventure game in college - accessing the host system it was on over my 110 baud modem. If memory serves me correctly, this game was the original computer Adventure game.

Some of the other software I came across included:

• CorelDraw version 2 (1991)
• Windows 3.0 (1990)
• PhotoFinish 1.0 by WordStar (1991)

The oldest software I found was IBM DisplayWrite 4 dated 1986. DisplayWrite was IBM’s first word processing software for the PC and an abomination it was. Rather than use it at work, I went out and bought a copy of Samna’s Ami Pro which was later purchased by Lotus and became Word Pro. I also found a diskette of software and references to BBS’ (Bulletin Board System). BBS’ were computer systems that you would dial into with your modem - the only way to fly in those pre-Internet days. Most of the BBS’ I wanted to connect to were a long distance phone call away and this was back in the days when long distance calls weren’t cheap.

The oldest data files dated back to 1989 and consisted of tables of data on near Earth asteroids. I also found backup copies of all the issues of Spacewatch and PSF News from the time when I was the editor of those publications.

At the finish of the project, the stacks of diskettes to toss numbered in excess of 1,700. I kept about 70 diskettes containing software, system utilities, etc. and another 20 blank diskettes. I next went through the files I had copied to my hard drive more closely, deleting those I considered either unimportant or redundant. At the conclusion of my project, I had just over 180 megabytes worth of files. It’s remarkable to think that of the files contained on over 1,700 diskettes, I was able to write all those I kept to a single CD with room to spare.

It’s even more remarkable to consider the great strides that have been made in data storage. In the early 1980’s diskettes could hold only 100 kilobytes of data. Today I have a portable USB hard drive that fits in my pocket and holds 250 gigabytes of data. Measured in terms of my 3.5 inch 1.44 megabyte diskettes, that’s the equivalent of 177,777 diskettes! (See Math Note 1 below) Here is another analogy: if each of my 1.44 megabyte diskettes had been filled to capacity, then my entire collection could have been written to four CDs or just one DVD.

Just as work grows to fill the available time, so to do files grow to fill the available space. When I started working with graphics files some 20 years ago, the files were small enough so that a number of them could fit on a single diskette. Today the size of my graphics files has grown to the extent that some consume the bulk of a single CD. And liberal use of a digital camera means that I now have tens of gigabytes of RAW files to back up. Now we have music and videos as well. At present I have in excess of 20 gigabytes worth of MP3 files and I expect that number to continue to grow. And there is every reason to believe that this trend will continue.

What does this all mean? The continued evolution of data storage technology means that the medium we save our files on today will not be accessible in the future. Combine this with our ability to save files of ever larger size in ever larger quantities. The bottom line is the next migration from CDs and DVDs to their successor could be a real nightmare - a task too hard even for Hercules.

Happy Computing, Jim

Math Note 1: Okay so I have a portable USB hard drive that holds 250 gigabytes which works out to be equal to the storage capacity of 177,777 3.5 inch diskettes. The picture at the top of this post is of a pile of something over 1,700 diskettes. That pile measures about 30 inches long by 14 inches wide and 13 inches tall. So a 5,460 cubic inch volume of space can hold 1,700 diskettes. Assuming the same degree of packing, it would take 570,980 cubic inches of space to hold 177,777 diskettes. That’s 330 cubic feet or a space that is approximately 7 feet long by 7 feet wide by 7 feet tall!. Imagine all that squeezed into a space that fits in my pocket.

There are times when I have my laptop disconnected from the network and I want to do some serious graphics work. Because graphics software is very CPU intensive, I want my graphics program to have as little CPU competition as possible. This is especially true when I am working on very large images in Photoshop or running a render using one of my 3D applications, be it Lightwave, Mojoworld, or Bryce.

Now I could use the Windows Task Manager to go in and one by one shut down processes that I know aren’t needed. Or I could use the Windows XP System Services tool services.msc to accomplish the same thing.

There are a few problems with this approach. First I need to remember what processes to shut down each time. Being disconnected from the network allows me to shut down quite a few additional processes like antivirus, firewall, and other internet-related processes. On a typical Windows PC, this can be a rather lengthy list. And once I know what I want to shut down, I have to find each process in the list of processes and manually shut them down one by one. What a pain.

My solution was to automate the process. I had previously created a directory on my laptop called a_Utils which contained a variety of DOS batch programs I had written. One thing I did when I created this directory was to make sure that it was in the Windows Path environment variable - a variable that tells Windows where to look for programs. This variable can be set on Windows XP as follows:

1. Right click the My Computer icon and select Properties
2. Click on the tab labeled Advanced
3. Click on the Environment Variables button
4. In the System variables window, locate the variable Path and select it by clicking it once.
5. With Path selected, click on the Edit button at the bottom of the window.
6. In the Variable value field, go to the end of the field, add a semicolon if one is not already there and type in the full path to the directory that contains your batch file.
7. Click the trail of OK buttons back to the System Properties window
8. Click the OK button

In my directory a_Utils I created a DOS batch program file named !KillTasks.bat. This file consists of a list of taskkill commands. Taskkill is a Windows command line program that is used to terminate one or more tasks or processes which are identified by either their process ID or image name. I use the command in the following form:

taskkill /f /im ImageName

The parameters I specify are:

• /f which tells Windows to “forcefully” terminate the process. In other words, don’t take no for an answer.
• /im tells Taskkill that I am specifying the image name of the process to be terminated.
• ImageName gives Taskkill the name of the process to terminate.

So far this has all been rather straight forward. Now the trick is in identifying what tasks or processes you can safely terminate. My method of doing this was to open Windows Task Manager and go to the Processes tab. Looking over the list of processes, the function of several was obvious and I knew whether or not it was a process that must run or a process I could kill. For others, I plugged the Image Name into a Google search in order to determine what the process does and whether or not I could kill it.

Following is an extract of what my !KillTasks.bat looks like. In this extract I am only including the commands for terminating my Nikon camera monitor and Copernic desktop search tool. The actual list is much longer.

I close my program with the PAUSE command. This prevents the DOS window from closing until I press the Enter key, giving me the opportunity to look over the command output. This is just a personal preference on my part.

Now whenever I want to disconnect from the network and do some serious graphics work all I have to do is run my batch program. To make it really easy I created a shortcut to the program on my desktop. One double-click and my laptop is ready for some heavy duty graphics work.

Ad Astra, Jim