folklore.org
The Original Macintosh:    16 of 15 
Disk Swapper's Elbow
Author: Steve Capps
Date: January 1984
Characters: Steve Capps
Topics: Software Design, Technical, Bugs
Summary: a last minute bug causes some problems

One of the more common afflictions of early Macintosh users was the dreaded "Disk Swapper's Elbow" caused by a disk copying operation run amok. Disk swapping was a necessary evil caused by having 400KB floppy disks, 128KB of RAM, and a single floppy drive. If a user wanted to make a backup of a disk, she had to eject the source disk, insert a blank one, format it, drag the source disk over the new disk, and then the Finder would copy data piece-by-piece with the necessary swapping.



A typical application on a 128K Mac had about 85K of memory available; the rest was used by the system, mostly for the bitmap display. A simple calculation shows that copying a 400K disk should involve about 5 or 6 swaps. Five disk swaps was barely tolerable, but, as early Finder users will remember, occasionally it would take well over 20 disk swaps.

You'd start a disk copy and hold your breath during the fifth, and hopefully, final swap. If the Mac dutifully disgorged the floppy that sixth time, you'd convince yourself you miscounted, cross your fingers, and hope for the best. By the seventh swap you start cursing because you knew you were trapped and you'd start wondering about investing in a second, external drive.

Even though the whole Finder was only 46K of code and had about 10K of overhead, the remaining 30K of memory was too small for practical copying. So, I had to break up the code into two chunks: the bare minimum for copying and all the rest. Then, I had to carefully flush out all data that was cached in memory, preload the small disk-copying chunk of code, and coalesce the balance of RAM. Usually, the Finder ended up with 75K of free memory and things worked as planned. But, sometimes the system would mysteriously reload the larger chunk of the Finder code, fragment the free memory, and cause another case of Disk Swapper's Elbow.

It took me a long time to figure out what happened because we had rarely seen this in testing. There were a few bug reports of this problem that were never reproducible. The bug reports went like this: "Copied a disk, it took 20+ swaps $%#@!!! Tried a second time, it was fine." The reason this was not reproducible was because we were all expert mouse users and usually skipped the crucial misstep.

When anybody first starts using a mouse, dragging is one of the more difficult things to do. It's actually quite awkward to click down, move the mouse while holding down the button, and then release. Beginners very often accidentally release the mouse button while dragging. In the Finder, this means you could "drop" an icon you were dragging. You rarely thought about this (unless you happened to drop it over a folder and it disappeared); you'd immediately pick the icon up and continue the drag. It turned out if you dropped the disk icon during a disk copy, you'd induce the bug.  Since all of the team members had been using the mouse for years by this time, we rarely dropped icons which is why we could never reproduce the problem.

To support the user's spatial memory, the Finder always remembered where icons were located on the desktop. When you dropped the icon -- even for a half a second -- the Finder would dutifully record its location. The routine to save the icon's location was, as you probably guessed, in the big portion of the Finder's code. When this bug occurred, the Finder would carefully massage the memory for copying and then belatedly discover the icon's location hadn't been flushed out. It would blindly call the routine to flush it and you now know what would happen...

I introduced this bug about 2AM the morning we built the final disks. This bug was caused by a fix to a much more egregious bug, so it was definitely the lesser of two evils....really!

Five Different Macintoshes
Back to The Original Macintosh

Login
Account Name:

Password:

Create new account
Rating
Overall Rating: 3.85
(good)

Your rating:

  1

  2

  3

  4

  5
12 Comments     
By the way, dragging pervaded the original Mac User Interface and in retrospect it wasn't a very good for beginners. If you let up on the mouse button while dragging, you could choose the wrong menu command, draw shapes incorrectly, drop a file in the wrong folder, or do many other surprising things. Ironically, Windows menus permit you to click once to open the menu and then again to choose a command or you can drag to the command a la Mac. In fact, Windows menus are actually easier for beginners to use
When I started in Mac developer tech support in April 1984, I got a prototype external floppy drive. It had no case and it only worked about 80% of the time, but this homely device was a prized possession at that time, because they were in short supply. I often came in to work and had to go find whoever had "borrowed" my external drive.
Our Macintosh Users Group referred to the 20+ disk swap copy event as "The Apple Manual Dexterity Test.
ok, I'm at a loss... i recall having the exact same problem on a Mac Classic with a whopping 4 MB of RAM. With that much memory, it should be able to hold the entire 1.44 MB floppy in RAM before spitting out the source floppy. Of course i can't for the life of me figure out why i wasn't using the 40 MB Hard drive as a go between. But since i was 12, my memory is probably quite fragmented. ;)
My first Mac was a brand new Platinum Mac Plus with only one floppy drive. My uncle who helped me set it up warned me that I wouldn't last long without an external drive. So after a week or two of swapping I resigned and my father bought an external drive. System 6.0.4 at the time was taking almost a full 800k disk and running apps on another disk via swapping triggered a "toaster" session while starting the app and after that whenever an uncached or purged system resource was called. Definitely at the time, you were better off with an HD or at least an external floppy drive.
Calculations shows that when the bug happened, there was less than 20k in the heap.
Yikes!
Nate Friedman, under System 6 with MultiFinder, even the Finder have a fixed memory partition, so the Finder sometimes ran out of memory, and I don't know if the Finder uses temp. memory for disk copying or not. System 7 provides a dynamically adjustable partition for the Finder.
This is a good example of how usablity testing can uncover bugs.
In 1988, I spent just one afternoon with my ($1399.00 used) Mac Plus doing the disc swap routine before I decided to spring for a HUGE 20 MB hard drive. Still the best $700 I ever spent.......it preserved my sanity.
"By the way, dragging pervaded the original Mac User Interface and in retrospect it wasn't a very good for beginners. If you let up on the mouse button while dragging, you could choose the wrong menu command, draw shapes incorrectly, drop a file in the wrong folder, or do many other surprising things. Ironically, Windows menus permit you to click once to open the menu and then again to choose a command or you can drag to the command a la Mac. In fact, Windows menus are actually easier for beginners to use" Mac OS 8 changed the menus so it worked like Windows menus.
It is funny notice that 30 years later Apple's first/second generation products still struggle with memory constraints. My iPhone 3G simply drive me crazy when I need to switch quickly from one intensive memory app (a game or some photo morph app) into, say, dial pad. It is simply too slow...sometimes it even crash, forcing the phone to return to the main screen. I know for sure that if I need some emergency service I would be in trouble if the iPhone is the only available cell phone around me...