This lesson is being piloted (Beta version)

Using Emulators to Resurrect Recovered Data

Introduction and Icebreaker

Overview

Teaching: 5 min
Exercises: 10 min
Questions
  • Who are we? Who are you?

Objectives
  • Introduce instructors and attendees to each other

Some background on your course designers:

Ethan Gates is the Software Preservation Analyst for Yale University Library, currently working primarily on the “Scaling Emulation and Software Preservation Infrastructure” (EaaSI, for short) project. He started, like many people, using emulators to access nebulously legal Nintendo ports on his laptop, and has been investigating using the technology in archival and media studies contexts since at least 2016.

Claire Fox is a media archivist and 2020 graduate of NYU’s M.A. program in Moving Image Archiving and Preservation. She interned at YUL working on the EaaSI project in summer 2019.

A few questions to reflect/get us started:

Key Points

  • Keep your earliest software/computer you ever used in mind. We’ll try to circle back to it later!


Anatomy of a Computer

Overview

Teaching: 20 min
Exercises: 15 min
Questions
  • What is an emulator?

  • What is a ‘virtual machine’?

  • How can you break down a computer into its component parts?

Objectives
  • Re-consider the computer as a physical object with separate, discrete components

  • Translate each component to its virtual equivalent

  • Define emulation vs. virtualization

What is emulation?

In computing, emulation refers to the representation of a hardware equivalent in software. It allows us to:

To understand how this is accomplished, it’s worth stepping back to consider “hardware”. What is it exactly that we are trying to represent?

Diagram of a physical computing environment

In a computing environment, “hardware” refers to fixed, physical parts - a monitor, a mouse, a keyboard, RAM, the CPU, graphics and audio cards, etc. At a bare minimum, you pretty much need a CPU and a method of communicating with it, and all other parts are technically optional. But some combination of these other components are obviously very, very common.

What we tend to think of as “our computer” - the operating system (MacOS, Windows), the file system, the applications we use, our personal data - is usually stored on a particular piece of hardware: a storage device like a hard disk drive or solid state drive (increasingly the latter, especially if you’re on a laptop). We’ll refer to this as a “bootable system” - some combination of data and software (whatever is required to actually make use of your hardware and not just have a pile of plastic and metal), stored on physical media.

And though it’s not strictly necessary, we usually interact with computers by adding additional content or software to the bootable system: photos from your family, games like The Oregon Trail, the installer for Adobe PhotoShop, encrypted documents passed along by your whistleblower friend - whatever. Though the internet has taken over as the primary method for exchanging additional content, historically this was frequently done with portable, removable storage devices like floppies, CD-ROMs, external hard drives and USB sticks, etc.

So what does it mean to translate all this into a virtual environment?

Diagram of a virtual computing environnment

All of those fixed, physical components will be handled by emulators. Emulators are applications (software) that mimic the behavior of hardware - essentially, you will insert an emulator as an extra layer into your usual computing stack to trick older bootable systems and additional content or software into seeing different/legacy hardware rather than the actual laptop or desktop you are using right now.

Just as there have been a great variety of hardware brands and systems over the history of computing, there are many emulators that have been created by developers and enthusiasts to recreate that variety. Frequently, different emulators will be better at mimicking different types of hardware - you will want a different application if you are trying to emulate a Mac or a PC, or if you are trying to emulate a BBC Micro or a 2018 Raspberry Pi.

Here are some common examples of popular emulators and the hardware they try to recreate:

A sidenote on “disk imaging”

The storage devices that carry bootable systems and additional content - hard drives, floppies, CD-ROMs, etc - are converted to a virtual environment by a process called disk imaging. A disk image is a file that contains both the contents and the structure of a storage device; in other words, a bit-for-bit copy of that physical device, that now exists virtually. Emulation very frequently relies on disk images (and some have been provided to get through this tutorial) - an emulator without a bootable disk image is as useful as a MacBook without MacOS.

Creating disk images from physical media is a process entirely unto itself, which we will not cover in this lesson. We will assume disk imaging has already happened, and proceed from there to demonstrate how emulators use disk images to create a virtual environment. For more information on archival-quality disk imaging, we heartily recommend the resources provided by our friends in the BitCurator Consortium.

https://imgs.xkcd.com/comics/emulation.png

Emulation, Virtualization and Virtual Machines

We have been discussing computing “environments” to broadly encompass everything that makes up a computer: not just hardware, but the software, files and settings that you manipulate and personalize as a user. Emulators and disk images help us move this interaction from a physical to a virtual space.

Instead of a virtual “environment” you could also fairly refer to what we are doing with emulation as the creation of a virtual machine or VM. And indeed, you will see this term, as well as virtualization, come up a lot online, in similar contexts to emulation. The distinction between emulation and virtualization is very technical and largely contextual, so it is worth clarifying before we proceed.

As noted above, emulation is about recreating hardware in software - at a high level, its purpose is to overcome incompatibility and obsolescence. Without an emulator, it is impossible to run an SNES game on a desktop computer, or run a Apple II program in Windows, for instance. The guest system (the Apple II operating system) and the host (let’s say, a modern Dell laptop) are fundamentally incapable of talking to each other otherwise.

Virtualization also refers to a process of creating virtual machines, and setting up a “guest” system on a “host”. But it generally refers to cases where the guest system is totally compatible with the host’s hardware, but the user wants the option of running two or more different operating systems, or wants to isolate some of their applications and files, or otherwise has a reason to split their single computer into multiple computers. We can return to our example of a modern Dell laptop again here - that Dell laptop is perfectly capable of running either Windows 10 or Ubuntu 18.04 for its operating system, just not both at the same time. But you could run Windows 10 as the “host” with an Ubuntu virtual machine as the “guest” via a virtualization program, and take advantage of applications written for both operating systems.

Virtualization is less about overcoming incompatibility and obsolescence and more about managing and splitting hardware resources (the modern internet, for instance, pretty much runs on souped-up server racks that are split into virtual machines to manage and host different web sites - this is more efficient than setting up a separate physical machine for every site on the web). It’s also usually much faster than emulation, because programs run in virtualization are still communicating directly with hardware, rather than working their way through extra layers and layers of software.

However, confusingly, some programs are capable of both emulation and virtualization. VirtualBox, VMWare, and QEMU are all popular examples. QEMU is capable of either virtualizing Windows 10 or emulating Mac OS 9.2. The line of “compatibility” can also get muddy and sometimes has nothing to do with our usual markers of age or obsolescence: there is software originally written in the 1980s for MS-DOS that is probably perfectly capable of being run on modern hardware via virtualization.

All of this is to say that we will refer exclusively to emulation for the rest of this lesson, because contextually we are seeking to “resurrect” recovered data and that purpose is more commonly associated with creating virtual machines via emulation rather than virtualization. But, the further you pursue this work, the more likely these terms are going to come up in the course of troubleshooting and research. And, the more the digital preservation field considers how to proactively safeguard contemporary digital materials and computing environments, virtualization will become more and more relevant as well.

Mapping hardware components to emulator applications

An additional challenge of working with emulators is that there is little in the way of “controlled vocabularies” for computing environments. So different emulators may be referring to more or less the same thing and just use different words in their menus and support pages.

For an example: here is essentially the same MS-DOS virtual machine, displayed first in VirtualBox and then as a QEMU configuration. Both machines feature:

MS-DOS running VirtualBox

MS-DOS running in QEMU

The selected settings in both applications are essentially choosing the same pieces of hardware to emulate, but communicating it differently (and it’s possible that neither is referring to a piece of hardware the way you would in everyday conversation, when thinking about, using, or buying a physical machine). And these are both applications meant to either emulate or virtualize generic PCs!

Hardware component VirtualBox setting QEMU setting
CPU/processor Chipset Architecture qemu-system-[arch] (generic architecture) and/or -cpu (specific model)
RAM Base Memory -m
Monitor and Graphics Card Display -vga
Sound Card Audio Controller -soundhw
Network Interface Controller Network Adapter -nic
Floppy Disk Drive Floppy Device -fda [floppy_file.img]
CD-ROM Drive Optical Drive -cdrom [cd_file.iso]
Hard Disk Drive Virtual Hard Drive -hda [harddisk_file.img]
Mouse Pointing Device -device
USB USB Controller -usb

Exercise: Emulator Documentation

Running a virtual machine in QEMU consists of “building” your emulated PC by selecting hardware components to recreate from the program’s list of options.

Open a text editor or word processor (Text Editor, Notepad, Microsoft Word, Google Docs, whatever you’d like, just open something to write things down). Also open a new tab in your browser and navigate to the official documentation for QEMU’s “PC System Emulator” (qemu-system-x86_84, though the commands apply as well to qemu-system-i386).

Below is a list of several specific pieces of hardware emulated by QEMU. Copy the list to your open word document. Using the QEMU manual, can you write down, next to each device in the list, the appropriate setting and option to specify that particular hardware?

Since QEMU is a command line application, settings are selected with this structure (brackets for illustrative purposes only): -setting [option]

  • a Pentium processor:
  • 512 megabytes of RAM:
  • a USB mouse:
  • a Cirrus Logic GD5446 Video card:
  • an ENSONIQ AudioPCI ES1370 sound card:
  • a RealTek RTL8139D network card:

Solution

  • a Pentium processor: -cpu pentium
  • 512 megabytes of RAM: -m 512
  • a USB mouse: -device usb-mouse or -usbdevice mouse (the latter is deprecated syntax and may be removed in a future QEMU version)
  • a Cirrus Logic GD5446 Video card: -vga cirrus
  • an ENSONIQ AudioPCI ES1370 sound card: -soundhw es1370
  • a RealTek RTL8139D network card: -net nic,model=rtl8139

Key Points

  • Emulators recreate computing hardware in software. These are called ‘virtual machines’ to distinguish from physical machines.

  • You will need disk images to load software and files into emulators.

  • Virtualization and emulation are technically very similar but usually employed in slightly different contexts.

  • Different emulators are designed for different brands or models of hardware, and may refer to similar components in different ways. The variety of possible applications and vocabulary is confusing, but surmountable.


1st Break

Overview

Teaching: min
Exercises: min
Questions
Objectives

Important Things

Key Points


Emulation and Virtualization Applications

Overview

Teaching: 25 min
Exercises: 45 min
Questions
  • What does emulation look like in practice?

  • What are unique challenges to Mac emulation?

Objectives
  • Boot a Windows 95 virtual machine in QEMU

  • Boot a Mac System 6 virtual machine in Mini vMac

  • Load and run a disk image in emulation

Create a Windows 95 Virtual Machine

Using the following steps, we will now demonstrate emulation in practice by creating a Windows 95 virtual machine using the emulation/virtualization application QEMU (Quick EMUlator).

NOTE: Again, QEMU is primarily a terminal or “command line” application. If you have never used the command line before, we recommend reading or completing a command line tutorial before attempting this section of the workshop to ensure that you are comfortable with basic conventions and principles of using command line software.

Please make sure you have followed all the steps and instructions in Setup before proceeding.

  1. Open a command line terminal (Terminal in MacOS/Linux, Command Prompt in Windows)

  2. Change directory into the “Windows95” folder you downloaded during Setup (e.g. Downloads -> Windows95) e.g. type “$ cd /path/to/Windows95 (cd, space, drag-and drop the “Windows95” folder on to the terminal screen, hit Enter)

  3. Create a blank hard disk image: $ qemu-img create -f qcow2 WindowsHDD.img 2G
    • This command calls QEMU’s program for manipulating and creating disk images (qemu-img) and directs it to create a blank disk image with a maximum size of 2 GB and using the “qcow2” file format.
    • The qcow2 format is a disk image format unique to QEMU optimized for emulation and virtual machines. It allows you to create a disk image that goes up to 2 GB without actually taking up that much space on your host storage!
  4. Start installation by typing: $ qemu-system-i386 -m 256 -vga cirrus -soundhw sb16 -net nic,model=pcnet -hda WindowsHDD.img -fda Windows95_boot_disk.img -cdrom Win95_installer.iso -boot a
    • qemu-system-i386 calls QEMU’s generic 32-bit x86 PC emulator (ideal for mid-90s Windows!)
    • -m 256 assigns 256 MB of RAM to the virtual machine
    • -vga cirrus
    • -soundhw sb16
    • -net nic,model=pcnet
    • -net user
    • -hda WindowsHDD.img
    • -fda Windows_95_boot_disk.img
    • -cdrom Win95_installer.iso
    • -boot a directs the virtual machine to boot from the floppy drive
      The Windows 95 installer was distributed on a CD-ROM but was not bootable - so if you’re starting from scratch/a blank hard drive like we are, you needed a boot floppy in addition to the Windows 95 installer to get set up.
  5. A QEMU window should open and you will boot to an MS-DOS prompt: Select or type “1” to boot your virtual machine with CD-ROM support.

  6. When MS-DOS loads, you should receive a prompt: A:\> . Type fdisk then hit Enter.
  7. DOS will ask if you want to “enable large disk support”. This is obscurely asking how you would like to format the blank hard disk drive: FAT16 or FAT32. Type “Y” and Enter to format your hard drive with the NTFS file system and allow for formatting drives over 2GB.

  8. In the fdisk (Fixed Disk Setup Program) menu, Enter choice “1” to create a DOS partition on your hard drive.

  9. Select “1” again to create a Primary DOS Partition.

  10. Finally, select “Y” to use your entire 2 GB hard drive for the Primary DOS Partition.

  11. Hit “Esc” to exit fdisk, then close the QEMU window entirely to “turn off” your virtual machine.

  12. Back in your terminal, hit the Up Arrow key and restart QEMU again (with all the same flags/settings). Again, select “1” to boot with CD-ROM support.

  13. At the DOS A:\> prompt, type format c: to complete the process of partitioning and formatting your hard drive. Proceed with the formatting “Y” when prompted.

  14. When formatting is complete, label the hard drive volume as desired (e.g. “WINDOWS”)

  15. At the A:\> prompt, type “D:” to change directories to the CD-ROM drive.

  16. At the D:\> prompt, type “SETUP” to launch the Windows 95 installation program. (Allow the installer to run a ScanDisk check of your “hard drive” first)

  17. The Windows 95 installer instructions should at this point be relatively self-explanatory, and most default options can be accepted.
    • At the “Setup Options” screen, choose the “Typical” setting
    • At the Certificate of Authenticity screen, enter in the serial number provided in the “serial.txt” file included in the downloads for this tutorial.
    • At the “User Information” screen, enter anything for “Name” and Company”.
    • At the “Analyzing Your Computer” screen, check the boxes for both “Network Adapter” and “Sound, MIDI or Video Capture Card” so that the installer looks for those pieces of hardware.
    • At the “Windows Components” screen, choose to the install the most common components.
    • At the “Startup Disk” screen, select “No, I do not want a startup disk”!!!. You already have a startup/boot disk - we started this tutorial with it!
  18. When files are done copying and installing you will be prompted to reboot the computer, and see a warning that there is still a floppy disk in your floppy drive.
    • Make sure QEMU is your active window and type “CTRL-ALT-2” to access the “QEMU Console” (which allows you to perform some actions that you would for a physical machine, like eject a floppy disk!)
    • type “eject floppy0”
    • type “CTRL-ALT-1” to return to your virtual machine
    • reboot as prompted
  19. After rebooting, you will be asked to set up a few operating system settings.
    • You can select whatever Date & Time/Time Zone you would like, but we recommend unchecking the “Automatically adjust clock for daylight saving changes” box. This will avoid a number of annoying pop-up warnings.
    • “Cancel” to avoid configuring a printer. (Unless you have a spare Apple LaserWriter around?)
    • Reboot again.
  20. At this point, you have a working Windows 95 installation. Congratulations!!! But let’s set up a few more things to get the most you can out of Windows.

  21. Avoid configuring Internet Explorer. It’s not going to do well with the internet anyway.

  22. To get proper video and audio, go to the Windows menu -> Settings -> Control Panel.
    • Select the “System” menu
    • Under “Device Manager”, there will be a question mark next to “Plug and Play BIOS”. QEMU does not properly emulate the hardware necessary to play nice with this part of Windows 95, but we can fix it. (It will get a bit scary. Don’t panic!)
  23. Select “Plug and Play BIOS” and then click on “Properties”.

  24. On the “Driver” tab, click on “Update Driver”.

  25. In the Update Device Driver Wizard, select “No, select driver from list”

  26. In the list of options presented, select “PCI bus”, then “Finish”. You will be prompted to reboot.

  27. When you reboot, a bunch of stuff will happen. This is basically Windows 95 suddenly detecting and configuring lots of pieces of hardware that it was unable to see before. Continue accepting whatever default options are presented to you (e.g. to overwrite or keep certain files) and allow the system to reboot several times.

  28. At some point the installer will properly detect your network adapter and ask you to configure your network. You must fill in a user/computer name and Workgroup, but you can put anything.

  29. Eventually, you should reboot back to the Windows 95 desktop. To log on Windows will ask for your user name (the user/computer name you selected a minute ago) and a password. You may invent any password you like here, or just leave the field blank to have an empty (no) password.

  30. If you didn’t hear audio before…you should hear the beautiful Microsoft Sound now!

  31. At the desktop, return to the Control Panel (Start -> Settings -> Control Panel) and select the “Display” menu.
    • In the “Settings” tab, select “High Color (16-bit)” under “Color Palette” and boost “Desktop area” to 1024 by 768 pixels.
    • Select “Apply” - Windows will give you a warning about changing the desktop resolution on the fly, but you can safely apply these settings without restarting.
  32. Congrats, you now have the latest in cutting-edge 1995 Soundblaster and SVGA audiovisual technology!

  33. Try out a CD-ROM: enter the QEMU Console (by typing CTRL-ALT-2)
    • Enter change ide1-cd0 MarbleDrop.iso to insert the demo CD-ROM included with the Windows 95 downloads for this tutorial.
    • Hit CTRL-ALT-1 to return to the Windows 95 interface. “Marble Drop” should appear in the CD-ROM (D:) drive!
  34. To properly shut down your Windows 95 machine, go to the Start menu -> Shut down. The QEMU window should close automatically when you shut down the operating system and return you to your terminal.

  35. If you ever want to run your Windows 95 machine again, make sure you are in the “Windows 95” directory and run: $ qemu-system-i386 -m 256 -vga cirrus -soundhw sb16 -net nic,model=pcnet -usb -hda WindowsHDD.img. You no longer need the -boot, -fda or -cdrom flags, although you can use the latter two if you have another floppy or CD-ROM image you would like to try with your Win95 virtual machine! (Try browsing the options at the Internet Archive or WinWorld - have fun!)

Create a Mac OS 6 Virtual Machine

What’s the deal with the “ROM” file?

Mac emulation presents additional challenges compared to general PC/x86 systems (e.g. our Windows 95 VM). Apple operating systems and emulators are often tied to very particular Mac machines/models rather than being able to run on a “generic” emulated processor. For instance, the Mini vMac emulator is designed rather specifically to emulate a Macintosh Plus and handle the operating systems available for that model, whereas BasiliskII can potentially recreate a slightly broader range of Motorola 68K-based Macs (Quadras, Performas, etc.)

In order to recreate a particular Mac machine, several of these emulators (including Mini vMac) require a “ROM” (read-only memory) file, containing firmware dumped from an original machine’s motherboard.

The legality of distributing ROM files is considered murky enough that many emulator projects and even “abandonware” software download sites will not post them. Along with the other downloads used in this lesson, we are making a Macintosh Plus ROM file freely available with the stipulation that it be used in a non-profit educational or digital preservation context (i.e. to access legacy digital files that would otherwise be abandoned and not served by Apple)


Key Points

  • Running an emulator can require a challenging combination of troubleshooting legacy software/operating systems and the emulator itself.

  • Mac hardware is more unique than generic PC hardware, so emulation is more challenging and requires extra files to recreate particular Mac models. These extra files are called ‘ROMS’.


2nd Break

Overview

Teaching: min
Exercises: min
Questions
Objectives

Important Things

Key Points


Emulation as a Service

Overview

Teaching: 20 min
Exercises: 20 min
Questions
  • How can we scale emulation for institutions and collections?

Objectives
  • Load an environment in the EaaSI sandbox

  • Consider extra-technical implications of emulation for digital preservation (Fair Use, software preservation and description, shared collections and infrastructure)

Emulation-as-a-Service

Emulation-as-a-Service, or EaaS, is a web-based platform originally developed by the bwFLA team at the University of Freiburg. It allows users to access multiple emulators (or multiple versions of the same emulator) from a single browser interface - greatly simplifying the redundant configuration work necessary to run emulators at scale (many different operating systems, many different combinations of hardware, etc.)

The EaaSI project, which designed and sponsored this lesson, also maintains a sandbox version of EaaS to demonstrate the experience and capabilities of running emulation in a browser. It is populated with open source software (e.g. Linux, BSD, and OpenSolaris systems).

EaaS Reflection

  • In the EaaSI Open Source Software Sandbox, click on the tab in the navigation menu labeled “Environments.”
  • Select an option from the menu presented - any Environment, it’s up to you.
  • Click on the “Choose Action” button for your selected Environment, then select “Run Environment”.
  • An emulation session should start in your browser, and you’ll see something like this:

Please be patient - depending on the strength of your connection and the health of EaaSI’s servers, Environments may load slowly.

Questions

  • What is the experience of using an emulator in a browser?
  • How does it compare to the experience of running QEMU or Mini vMac?

Software Description

Scaling the use of emulation and tools like EaaS across many cultural heritage organizations and archives will require organized and agreed-upon ways to talk about computer software and hardware. Otherwise, we will launch many redundant and unnecessary efforts: if Museum X emulates a copy of “Microsoft Office” and University Archive emulates a copy of “Microsoft Office 2003 Small Business Edition”, how can we be sure they are or are not in fact running the same program?

However, establishing a standard for description of software and emulated hardware is a difficult task, not least of which because software programmers and distributors have used such a wide variety of methods, practices, and style guides to describe their own work and requirements.

Let’s try a brief activity to identify and demonstrate some of the challenges involved with software description and metadata.

Cataloging Software

  1. Return to the EaaSI Open Source Software Sandbox. Select and run another Environment of your choice.
  2. Inside the emulated operating system, explore the menus and select one or two programs to try to “catalog” - a web browser, an image editor, a word processor, a music player, it doesn’t matter. Any two applications will do - any of them could potentially be necessary for study and description!
  3. In the Setup folder downloaded for this lesson, open the “Software Metadata Scavenger Hunt - EaaSI Sandbox” spreadsheet. This spreadsheet offers a minimal schema and fields/columns for describing software applications, including an example item to guide you in this activity.
  4. To the best of your ability, use the spreadsheet to “catalog” the two applications you selected, one application per row.
  5. When finished, consider the reflection/discussion questions below.

Questions

  • Was it easy to catalog your selected programs? Difficult?
  • Do you think the challenges in describing your software were unique to the program you chose? Or inherent to the schema and fields provided?
  • Try to identify three factors that would make this task easier - think big! Technology, resources, knowledge, staffing, collaborative efforts, etc.

Though legacy software, like the examples we have emulated during this lesson, is an essential tool for accessing recovered and historical data, emulation and software preservation have not yet been widely incorporated into preservation workflows. A persistent concern, visible even in the hobbyist and enthusiast communities that push emulators forward, is legal uncertainty. Copying or modifying digital works, including software, can technically constitute “reproduction” or “distribution”, putting core preservation activities potentially under the purview of U.S. copyright and intellectual property law.

While preservation activities for analog materials have been, largely, explicitly blessed by the U.S. copyright system (e.g. that digitizing library copies of VHS tapes is alowed under Section 108 of the Copyright Act, or that the scanning and discovery activities behind HathiTrust and Google Books are a transformative “Fair Use”, benefiting the common good rather than infringing on publishers’ business and copyright), there has been no clear guidance from Congress or the courts as to equivalent activities for software preservation.

Thankfully, recent work from the Association of Research Libraries, the Software Preservation Network, and the Harvard CyberLaw Clinic have resulted in a series of empowering guidance and documents that provide a firmer legal footing for preservation organizations and practitioners to discuss, assess, and undertake risks in this gray area.

This section is less a structured activity and more of a homework assignment. It is highly recommended that any individual seeking to use emulators and legacy software to recover, access, or otherwise preserve digital works read these two documents. Though it is especially relevant and geared toward those who work at cultural heritage or non-profit institutions (gallaries, libraries, archives, museums), the Fair Use doctrine is an extremely broad and flexible legal principle (though context sensitive), with potential implications and application to preservation activities at many levels.

Further Resources

For more information on the EaaSI program of work:
https://www.softwarepreservationnetwork.org/projects/emulation-as-a-service-infrastructure

For everything you need to deep dive further on using emulators of all sorts:
https://github.com/eg-tech/emulation-resources

Key Points

  • Emulation-as-a-Service offers a technical platform to simplify the use of emulation in broad-ranging digital collections.

  • Standardized description of software and hardware is a difficult but essential task for collaborative recovery and preservation efforts.

  • The doctrine of ‘Fair Use’ is a flexible legal tool that can potentially be used to legally many software preservation activities - but be mindful that context matters, and that these recommendations are as of yet unproven in court.