Volume Number: 26
Issue Number: 03
Column Tag: 25th Anniversary Stories

25 Years of MacTech: Mac Memories by Adam Engst

Back when I was an undergrad at Cornell University, before I started TidBITS, I worked in Cornell's public computer rooms (this was before everyone had their own computer, so most students had to go to a computer room to use a Mac). Cornell was an extremely early adopter of the Mac, so we had quite a few rooms of Macs around campus. After a semester and a summer of working as a PTOP (Part Time Operator)-the person who sat behind the desk, signed out boot floppies, and made sure no one stole the LaserWriters-I was promoted to being a "STOS" - Student Terminal Operations Supervisor. (Cornell was a little acronym happy in those days.)

One of the rooms I was in charge of was actually had no PTOPs-it was an unmanned facility in which the Macs were locked down to desks, though that didn't prevent students from stealing the mouse balls as a way of ensuring that there would always be a computer available. It was in Carpenter Hall, the Engineering Library, and it was frequented primarily by Computer Science students.

For the most part, we didn't have a lot of interaction with the computer science students. Although many CS majors applied for jobs in the computer rooms, most couldn't interview their way out of a paper bag. People skills were far more important than programming skills for someone who was babysitting recalcitrant printers and helping sorority girls use tabs to format their resumes. But we always assumed the CS students knew their way around a Mac, since they were learning programming.

One day I was in Carpenter Hall's computer room with one of my employees, discussing how we were going to rearrange the room to get several Macs out from under a leaky water pipe. Non-stop excitement, I assure you. We weren't wearing badges or anything else that identified us, but somehow the upperclassman CS consultant who was in the room to help the freshman CS students figured out that we were responsible for the Macs, so he came over to ask us if we could help one of the students with a problem her Mac was having.

Keep in mind, we're talking about single-floppy Mac Plus machines here, so you had to have a boot disk that stored the system, your applications, and your documents on a single 800K floppy. (More amazingly, they all fit!) So, even though it wasn't our job to help the CS students, we figured it might be a hardware problem with the Mac, which was our problem.

When we walked over to look at the Mac in question, it had a modal dialog box on the screen that had apparently flummoxed both the student and the consultant. It said, and I quote, "You cannot erase the startup disk." There was only one button to click, though I can't remember if it was an OK or Cancel button.

My guy and I looked at each other, and we looked at the students and we said, in unison, "It means that you can't erase the startup disk." Both the freshman and the upperclassman looked relieved, and said, "Oh, well, that's okay then" and clicked the button. We smiled at them and walked back to look at our leaky pipes.

Though this was a popular story among our Mac-savvy colleagues, few of whom were taking any CS classes, the real point was that we learned that no matter how clear a user interface may be, sometimes it takes a person to explain precisely what it means.

Of course, we had plenty of other run-ins with far more sophisticated students, such as the one who figured out how to make an invisible copy of MacPlaymate the startup application on the hard drive-equipped Mac Pluses that drove our LaserWriters, or the students who figured out how to hack infinite amounts of money onto the vendacards that we used to charge students for laser printing. Then there was the excitement of discovering and dealing with some of the very first Macintosh viruses; after graduating and starting TidBITS, a colleague at Cornell and I were the first to discover the MDEF virus.

But no one held a candle to the guy who figured out how to send PostScript code directly to a LaserWriter and change the password from the default of 0 to some number between 0 and 32,767. The problem was that each attempt to change the password took 11 seconds, so it could have taken up to 4 days of constant execution to try each possible number. But we couldn't even do that, since the LaserWriter EEPROM, where the password was stored, was rated for only 10,000 writes. So if our program didn't guess in the first 10,000 tries, the LaserWriter's motherboard was toast. We were at an impasse, but eventually the solution presented itself in the form of a "friend" of the hacker who told us the password. We suspected it was the hacker himself, but we had no evidence and were just happy to avoid an expensive repair.

Wait, one more! One of the other computer rooms I was in charge of had a network of 20 double-floppy Macintosh SEs, with a pair of hard-drive equipped SEs in a cabinet to act as file servers over LocalTalk. Our PTOPs signed out boot disks that provided access to the applications on the servers, with a particular floppy for each Mac, and each Mac having access to a folder of applications on the server. It was an odd setup, with the primary goal being to ensure that we could use only 20 copies of the applications, since that's all we had licenses for.

But we only had 20 Macs, and replicating the folder of applications 20 times seemed silly. In fact, the main reason there were 2 servers was because the 20 MB hard drives were large enough to hold only 10 copies of all the applications.

At some point, I learned that it was possible to set a shared bit for applications using ResEdit, at which point multiple people could use the same application over the network at the same time. Once I realized this, I couldn't see any reason for the second server, since a single copy of all the applications could be shared among all 20 Macs from one server. So late one night, after we closed up, a friend and I tested this theory, and discovered that not only did it work, it increased performance because the server hard drives didn't have to seek all over to satisfy requests from different Macs. So we reconfigured one of the servers and redid all the boot disks, and watched it carefully the next day.

When it proved to be a smashing success, we gleefully informed our boss, who didn't respond with particular enthusiasm, which we didn't understand. After all, we'd just improved performance for users and freed up an expensive server for our organization, all while staying entirely within the terms of our software licenses. It turned out that we had stepped across organizational boundaries, since networks were installed by a different department, and those people were unamused at being shown up by a couple of students. Nevertheless, they didn't make us put the network back, though they never did take the unnecessary server away for some other use.

Much as I love how the Mac has evolved and become far more capable and stable than it was in those days, I still miss some of the excitement of being presented with entirely novel problems that were close to the core of the system, and that could be solved even by people who didn't have years of experience.