Eagle-eyed EaaSI-watchers may have noticed the “Student Staff” section on our team page – we’ve been extremely lucky over the course of the program to have employed a number of super talented Yale students, and want to highlight their amazing contributions to the software preservation community!
Here at Yale we have a collection of literally thousands of pieces of legacy software waiting to be installed in emulation and published to the EaaSI network. Where to even begin?
Earlier this spring we sent out a public survey to the digital preservation community for some help with that question. What are the most important types of software for unlocking digital collections? The kind we use every day in our professional or personal lives? The sort that are broadly compatible with legacy file formats? Ones that look fun and inviting and generate interest in the grinding work of software preservation and maintenance?
The results were intriguing: the 10 most frequently selected “genres” were:
- Web Browser
- Database
- Media Playback
- System Software (i.e. operating systems)
- Computer Aided Design (CAD)
- Compression
- Drivers and Utilities
- Backup and Recovery
- Office Productivity
- Scientific
Armed with some guidance from our Yale user base, the EaaSI network, and now the community at large, I could cross-reference these priorities against our software holdings and start to generate and batch import lists of titles into Yale’s EaaSI node that merit further inspection, description, and installation in emulation.
This is where our invaluable student staff come in. Description and configuration is painstaking work: the existing metadata for our software can be scattershot, requiring extra research into historical details like system requirements or publishing date – and that’s just to decide what operating system to start with. Once they actually load the installation media into an emulated environment and try to install and use it, all sorts of other considerations emerge: license key validation, changes to the operating system’s default graphics or network settings, hidden software dependencies that weren’t listed on the original CD-ROM packaging or anywhere else.
These are the questions that the student staff take the time to discover, document, and break down into meaningful data, one cell in a spreadsheet at a time. It’s a challenging combination of data entry with troubleshooting and improvisation: while I can guide them on the information we’re looking for (configurable languages, version numbers, file format extensions), the students ultimately are the ones who have to navigate the inevitable, countless quirks and lost details of older operating systems and software that they may very well have never used before.
One of our students, Eric Timperman (who graduates this month with his Master’s degree in Music – congratulations, Eric!!!) – wrote us about the uncanny but enlightening experience of moving *backwards* through computer history:
“Something I’ve learned since working with deprecated software is that the evolution from command prompt operating systems to fully interactive GUI operating systems was not as smooth as I originally thought. My earliest experience with any computer was using Windows 95 (to play Flight Simulator 98, no less), and I always felt that I could pick up any more recent version of Windows and use it intuitively with minimal effort. When I first worked with a Windows 3.11 emulator (which preceded Windows 95 by about 2 years), I quickly found that there were substantial differences between 3.11 and any subsequent version. For example, the windows themselves that make up the basis for the UI are considerably more context specific and less interchangeable, greatly limiting the robustness of the OS as a whole. There are also quirks that appear to be holdovers from text-based operating systems, such as needing a relative file path in order to create a shortcut for a program. The strangeness of Windows 3.11 demonstrates how rapid the evolution of Windows was in its early years, and how relatively few changes to the formula have been made in the over 20 years since Windows 95.”
The details Eric mentions aren’t trivial: metadata like the precise file path to a program shortcut will be critical to the “automagic” functions for recommending and launching environments that are part of EaaSI’s roadmap. Imagine copying out the file paths to all the shortcuts on your Windows 10 desktop. Now imagine doing that 100 times. Now imagine you’re on a 30-year-old computer desktop you’ve never even seen until today. You’re starting to get the idea of the very real, very human work these students are putting in.
We recently published the first batch of environments configured by student staff to the rest of the EaaSI network, and many more will soon follow. I am constantly grateful for their curiosity, flexibility and dedication, and so very glad that they are a part of the EaaSI team.
