Abstract – This paper will examine the potential for retrieving and indexing saved executable states and input replays through web browser integration. It explores the emerging possibilities and limitations of executable citation through a discussion of the current development of the Game and Interactive Software Scholarship Toolkit (GISST). GISST is designed to allow for users to load emulators locally in a web browser and then record and retrieve both emulated system states and input recordings of system interactions. These references can then be embedded as links within scholarly works and online documents, or directly executed as objects running within standard HTML elements. The goal of this work is to elaborate on how executable citation can enable easier access to emulation for both researchers and practitioners, along with how these types of references can enable new forms of scholarship and clarify aspects of software object description relative to emulated contexts.

Keywords – emulation, citation, computational state, software studies, software preservation

This paper was submitted for the iPRES2024 conference on March 17, 2024 and reviewed by Tobias Steinke, Tyler Thorsted, Jack O'Sullivan and Stefania Di Maria. The paper was accepted with reviewer suggestions on May 6, 2024 by co-chairs Heather Moulaison-Sandy (University of Missouri), Jean-Yves Le Meur (CERN) and Julie M. Birkholz (Ghent University & KBR) on behalf of the iPRES2024 Program Committee.

Introduction

The focal point of this work is the ongoing development of the Game and Interactive Software Scholarship Toolkit (GISST), a system for the reference, citation, and embedding of emulated systems within web-browsers1. GISST is hoping to create the first ecosystem of persistent and durable references to emulated system states and recordings of input into emulated systems. Though originally designed for the game and software studies community, the ability to quickly and easily configure and retrieve emulated systems in browser is in line with a number of complementary efforts within the digital preservation space. The purpose here is to start a discussion about the potential for the citation and retrieval of emulated state, the challenges it poses to digital preservation processes, and the myriad uses that such an object (a cited emulated state) could enable within research and preservation workflows.

In many instances, a researcher may want to reference the particular state of a system, but needs to rely on written textual description or audio-visual capture (usually screenshots and video) to reify that reference in their work. How does that work change if the reference is a live, executable citation embedded within their argument? In another case, a digital preservation practitioner may want to validate or quickly analyze some recovered software data, but would need to configure an emulated system to represent it. If they could configure that system and then share the reference data and execution with others, how would that change software preservation workflows? How about if they could also record their input and interactions with the object and then let others see and continue that interaction?

GISST foregrounds the discussion of embedded emulated state through the description of a functioning, prototypical system that enables their use. This paper will discuss some background on the rise of in-browser and embedded emulation within the online enthusiast and preservation communities, and then proceed to a discussion of issues raised by the design of GISST. After that, we discuss current and future use cases for embeddable emulated state, limitations present in the initial system, and plans for continued work. The hope is to spur conversation about the new possibilities for software access that arise from the existence of citable references to emulated state, and to open up digital preservation to a new method for revealing the potential of software-based collections.

Background

Over the last decade the prevalence of web-based emulation has grown thanks to the efforts of both the preservation and enthusiast gaming communities. In addition, improvements to WebAssembly runtimes in modern browsers has made it possible to cross-compile existing applications for the browser at close-to-native speeds. Compilation frameworks like Emscripten transform programs written in a range of languages into JavaScript objects [1]. As a result, a number of popular emulation frontends (programs that manage individual emulator cores) and emulators themselves now offer pre-compiled WASM executables for use in-browser. 

GISST currently makes use of two different emulation solutions to provide for the state citation functionality described below. One is RetroArch [2], an emulator frontend that makes use of the LibRetro API (Application Programming Interface) to organize a number of curated emulator “cores” for a large number of gaming (and gaming-adjacent) platforms. RetroArch distributes a WASM version of their frontend application with a smaller selection of cores that are also compiled as WASM binaries. This conveniently provides a uniform I/O and state manipulation API for those systems that are supported through the JavaScript frontend. The other emulator is “v86”, a general x86 PC emulator that is written in the Rust programming language and then compiled to WASM [3]. v86 is intended as a web-based emulator, and as a result has built-in features that support loading and saving executable system state. v86 directly converts x86 instructions into WASM ones and as a result achieves surprisingly good performance for many early Windows and Linux systems. The emulator accepts common disk image formats for floppy, CD-ROM, and hard disks, so it is possible to configure a system in another program (like qEMU [4]) and then import it into v86 for in-browser execution. We have used this functionality to install complex software in a local qEMU instance and then loaded those saved hard drive and floppy disk images into v86 through GISST.

It is now possible to run complex historical operating systems directly in a web browser. This means that in addition to the benefits of easily distributed, pre-configured emulated systems, there are also new possibilities that emerge when considering what complete, local, introspective access may provide for researchers and digital preservation practitioners.

Web-based Emulated Collections

The Internet Archive began significant promotion of web emulation with the release of the Internet Arcade in 2014 [5], and has continued providing access to browser-based emulation through their open-source Emularity project [6]. Many collections within the Internet Archive now support embedded emulation, including collections comprised primarily of non-game software [7]. The breadth and reach of the Internet Archive’s offerings have shown the potential and sustainability for online access to executable collections. However, the main use of online execution contexts still appears to be located primarily within the game enthusiast communities. Many sites exist in a legally gray area, and provide access to large collections of so-called “abandonware” through in-browser emulation. In some instances, the sites appear to be legitimate, in that if a game is available for purchase through online stores, it is not emulated on the site. This is primarily the case for sites that distribute historical DOS games [8]. Sites for game console ROMS also provide in-browser emulators but will not be cited here as they are likely also vectors for malware dissemination. The hope with GISST is to provide a similar type of access to embedded emulation but under the control of institutions that have clear policy and legal frameworks in place to manage dissemination.

Comparative Systems

The pre-eminent, browser-based emulation solution is currently the Emulation as a Service Infrastructure (EaaSI) project [9]. EaaSI functions by running containerized emulators on a cloud-based server and then streaming the visual output of those emulators to the browser window. This allows EaaSI to run a large range of systems, including relatively recent ones, at the expense of some latency issues, particularly when dealing with complex, continuous input. EaaSI also supports embedding emulations within other contexts that link to running, cloud-based machines. The benefit is that the data is stored on servers managed and owned by the institution using EaaSI. This embedding has provided compelling use cases, including Rhizome’s dissemination of the Theresa Duncan CD-ROM games [10], and the ability to retrieve embedded environments directly from library catalogs [9]. EaaSI allows for federation of multiple different EaaSI “nodes” through which users can share pre-configured emulated systems between institutions to remove the necessity for repeated re-configuration of common operating systems and software packages. 

EaaSI has also recently experimented creating and retrieving complete snapshots of system execution through the use of Checkpoint/Restore in Userspace (CRIU) [11]. Their goal is to develop a way to sustainably recover encapsulated, emulated environments in the far future. The main issue they articulate with the recovery of emulated computational states is that the emulator itself must be preserved in a manner similar to other preserved software objects. That is, if you want to recover a future emulated state you must also recover the emulator and its execution context. This leads again to a well-known issue with the “chaining” or “nesting” of preserved software systems. GISST does not resolve this fundamental preservation conundrum, as discussed below, but it does provide one more vector for the future reproduction of emulated systems, that of a linkage between compiled WASM files and supporting data. 

The current GISST is a re-implementation and expansion of a previous prototypical system developed as part of the Game and Metadata Citation Project (GAMECIP) from 2015-2017 [12]. That system was a proof-of-concept use of emulated executable citations, and was embedded in an experimental article about game bibliography published in Digital Humanities Quarterly [13]. Our original work on GISST inspired others in the game studies community to begin experimenting with the potential of emulated citations. One prominent example is that of “playable quotes”, which are embeddable snippets of memory and gameplay associated with the Nintendo Game Boy [14]. The “playable quotes” are embeddable within pages in a similar fashion to images, and make use of a custom protocol to load each emulated snippet. Interestingly, the snippets only include the segments of memory addressed by the emulator while the quote is being recorded. In this way, the “quotes” are limited to only the specific segment of gameplay shown. If a user wanders outside of the immediately quoted area, the system memory will not be present and interaction will stop. This was implemented to address issues surrounding the dissemination of complete Nintendo Game Boy ROM files. The quotes have already been used to create playable maps of games, and to compare similar locations within successive game versions. We will discuss these ideas more in the use cases section below, including thoughts on integration between GISST, and EaaSI.

Game and Software Scholarship Toolkit (GISST)

The current version of GISST is an attempt to create a robust, and sustainable, implementation of a repository for emulated executable states and input recordings. In GISST’s parlance, emulated executable states are known as “moments” of game play or software interaction, and input replays are “performances”. Primarily, GISST was designed to help researchers make use of reliable and retrievable references to executable states of a given game or piece of software. In this way, a future scholar would be able to “jump” into a running computation at the exact spot (and with the exact system configuration) as the initial author. Once a citation is configured, GISST also provides a small JavaScript library that allows for embedding references in hypertext, in a similar fashion to video and social media post embedding. The citation of software and games is a sticky issue that is still being negotiated in both evolving metadata standards, and within the game and software studies communities. GISST is intended to foreground and interrogate the potential for executable citation while at the same time providing a viable and stable initial attempt at such a framework. 

The usage of GISST within the software and game studies communities is (and will be) covered in other publications [15]. Our purpose here is to elaborate on how the ideas and functionality behind GISST might inform thinking within digital preservation circles about the further potential of emulated objects. While a lot of work has been conducted on the evaluation and critique of emulation as a method for software preservation, there is relatively little work on what new forms of scholarship and digital preservation practice are enabled through emulated systems. The rest of this section will discuss some of the metadata, citation, and data management issues that emerged in the creation of GISST’s framework and data model.

Object Description and Citation

Since our purpose is to manage the creation of retrievable emulated states (or performances), the design focus is on the effective citation of a particular configuration of software objects, dependent files, and execution contexts (emulators). In order to stably retrieve a reference to the state of an emulated system, information about the emulated environments and input data need to be organized in a way that supports both multiple versions of the software objects themselves as well as the environments they operate within. To accomplish this, GISST draws inspiration from previous work in the description of computer games as software objects within bibliographic standards. 

As highlighted by McDonough et al’s work on the description of early computer adventure games [16], aligning the complex dependencies and potential existential states of games with standards is daunting and fraught with unresolved ontological questions. That work described the Preserving Virtual Worlds project and its attempts to align related versions of the original text adventure game (known simply as ADVENTURE), developed by Don Woods and William Crowther in the late 1970s, with the Functional Requirements for Bibliographic Records (FRBR) and the Open Archival Information Systems (OAIS) models. FRBR, a precursor to the current BIBFRAME, used a concept-entity framework designed to allow for the hierarchical description of objects through relationships relating general “works” to individual known “items” held in collections. The relationships of FRBR could then be described with machine-interpretable semantic web languages to encapsulate complex contextual and functional interdependencies between items. 

Generally, the FRBR framework operated from the top-down, with top-level “works” appearing through multiple “expressions” that then linked to a particular physical “manifestation” of an individual “item” (the so-called WEMI model). The trouble develops in attempting to align this conceptual hierarchy with the curious material conditions of computer games (and by extension software objects). In attempting to work through the ADVENTURE example, the team collected a large number of versions of ADVENTURE as it was developed, released, and ported to new source code, but the distinction between works, expressions, and manifestations became blurred. The crux of the issue was when and where to create a delineation to a new concept. Is a complete rewrite of a game in a new language, in this case from FORTRAN to C, a new expression (i.e. edition) of the work? Or, if there are no changes to the game play or player-facing text, is it simply a new manifestation of a particular version of a game? Further, the notion of the compilation of code into an executable created more issues, as both the code and executable would likely count as “manifestations” of a particular work, but have completely different dependencies for rendering (the former through any text editor, the latter through a complete computational stack). 

While FRBR has been supplanted by the BIBFRAME descriptive model [17], a similar WEMI organization is still present and therefore similar issues regarding the description of software-based objects arise. BIBFRAME collapses the “expressions” and “manifestations” of FRBR into a single concept of an “instance”, and it is from this concept that we developed the descriptive model used in the current version of GISST. In our system, there are “works”, “instances”, and “objects” that link to a particular configuration “environment”. The notion of “environments” here is borrowed from the conceptual framework behind EaaSI, which delineates between “base” environments, and derived “software” and “object” environments. An “environment” is generally the organization of system dependencies needed to execute a particular “instance”. An instance in GISST can combine an arbitrary amount of objects into a single collection of data intended for execution in an environment; and instances are the base referential point around which the executable citations are constructed. Objects can fulfill multiple roles in relationship to the instance. There is usually a single “content” role for the target execution path (in a game console emulation this is the Read-Only Memory [ROM] file dumped from a physical media item, and in more complex setups it would be a specified executable file in a file system), with any number of “secondary” or “config” files that might also be required by the instance. Similarly, an “environment” might also be the result of a progressive installation of other software packages, or even other instances. 

This slippery bibliographic territory is commonly highlighted in the case of games and software installed within operating systems. For example, if we examine the game DOOM (a popular early first-person shooter game) as installed on an emulator, we find multiple (and perhaps contradictory) bibliographic statuses for the game. To specify, if we wanted to install version 1.9 of DOOM on the v86 emulator that GISST uses, we would need to first install a version of the DOS operating system that could support the game. So, we install the FreeDOS 1.2 operating system (an open-source implementation compatible with most DOS programs [18]), and then install DOOM 1.9 within that environment. In GISST, we therefore create a new work in “DOOM Version 1.9”, a new environment that includes the specific version of the v86 emulator we are using, and a new instance that links the work to a collection of objects (in this case DOOM’s executable, installation program, and secondary files). The instance also links to the environment needed by the instance to execute the files. 

On the backend, GISST is loading a hard disk image with the FreeDOS and DOOM files present into the v86 emulator when the browser loads the program. As a result, the user is then confronted with a command prompt in the browser window that lets them run programs within our preconfigured environment, and that environment happens to contain the executable that runs DOOM. However, since the DOOM program is essentially an interpreter for DOOM game files (known as WADs), we could just as easily have defined a particular fan-created WAD file as the “work” and then have the instance link that WAD file to an environment that already contains DOOM 1.9. This malleability of description is necessary as individual software objects can be considered objects of study or reference on their own, or as dependencies for the execution of other software objects.  

Another bibliographic challenge is in the description of software objects, moments, and performances. In the preceding example, the GISST system does not care (in of itself) about the human readable descriptions provided for the work or environment. As long as the records are linked, GISST will attempt to load an instance (which remember is just a collection of an executable and its dependencies) into its linked environment based on the particular method necessary for the emulator being used. Once loaded into GISST, the description of a saved state moment or input recording performance is up to the user of the system, and here we are in an uncharted and unexplored descriptive landscape. If a player of a game decides to save their place as an executable reference, what exactly are they saving in a conceptual sense? Literally, the saved moment is the specific configuration of the memory state within a system at a particular time, but the player is likely interested in what is represented by that state. They could be saving a reference to an individual level by saving once the level has loaded, or they could be referencing a particularly challenging sequence of a game as an input recording. Perhaps they have an interest in an enemy or item that is present within the saved state and are using the state to point those objects out to a future player. In all these cases, there are no standards or conventions for the description of saved program states. This game example could extend to interface interactions within an historical photo-editing software, or the rendering of a file within a historical word processing system. GISST currently allows for free-text description and search to mollify the descriptive constraints on users, but the primary issue remains. How do we describe software moments and performances in a way that is locatable by others in the future? GISST does not provide a solution, but is one of the first systems to even introduce this problem.

Federation and Sharing Constraints

In addition to the bibliographic constraints imposed by a system like GISST, there are also data management challenges to address. The GISST system functions through the use of two main components, a front-end web and desktop editor application (“editor”) and a backend database of configured environments and instance data (“repository”). The editor is a TypeScript application that loads an emulator within an HTML div element, and then configures the emulator by preloading files or attaching hard drive and disk images downloaded from the server. The editor allows users to save moments and performances through a collection of simple interface buttons and shortcuts, and then upload them to the server for retrieval at a later time. The repository is effectively just a file server that provides the ability to upload newly created states and performances, and to download the emulators, program files, and references to the browser. At this time, there is a single repository instance running on GISST’s alpha testing site, but since each entity within GISST’s data model makes use of a Unique Universal Identifier (UUID) it will be possible to run individual GISST repositories and link their references with each other. 

In the initial project work, it became apparent that a globally available repository disseminating software and its executable state for local use within browsers might not be amenable to many institutions’ legal and policy guidelines for data sharing. While the hope is that within a particular community, say the game studies community, it might be possible to host and manage a repository of executable references, in many other cases bespoke and rights-managed installations might be necessary. As described in use cases below, there are potential uses for a system like GISST that are not linked to its primary use case of scholarly citation and reference. The ability to easily and quickly load up a particular moment or performance of an executable system could benefit internal operations for any institution managing software objects and concerned about their representation to a constituency. Regardless, there are two development routes we are pursuing to allay concerns about improper dissemination. First, the GISST repository uses relatively standard dependencies and is a portable Rust application wrapping a conventional PostgreSQL database and flat file server. Configuring a deployable GISST instance through a containerization framework, like Docker [19], is currently planned and would allow institutions or individuals to run GISST within any network context they desire. Second, because a computation state is not a complete system but the specification for the memory state of one, we have already collected checksums for all the objects inserted into the GISST repository. It would be possible to adopt a bring-your-own-data (BYOD) approach in which the user provides the executable data component to GISST, which then layers the state and performance recordings over it. 

It should also be noted that while the editor currently pulls in all its required data from the repository, it will be possible to provide the editor with links to data stored in other repositories as well. For example, if a reference makes use of a file available on the Internet Archive, the editor could (in theory) pull the program data from that site and therefore would not be hosting any of the software data itself.

Use Cases and Vision

The prospects for shareable and retrievable citations to the internal executable state of a system, and performances linked to a progression of states, are quite extensive (and also unknown). In presenting this work to its advisory committee, and making use of the alpha-version of the system with student researchers, a few primary areas for use cases emerged. For researchers, the benefits primarily include ease of access to emulated systems, new forms of scholarship based on interactive performances and comparative reference, and the use of ready-at-hand examples for pedagogical use. For practitioners, the system is a way to better codify the issues around software citation and reference, to provide for an easier means for viewing and comparing data in archival collections, and to allow for interactive training with historical systems.

Research Use

The GISST editor (Figure 1) allows a user to create a large number of indexed references to a piece of software, and to record their input into the system for later replay. This opens up a new space for scholarly activities, as a researcher can navigate to a complex or hard-to-reach execution state, say a later level in a computer game or the rendering of a complex design file, grab a reference, and then allow future readers to jump in where the researcher left off. Because the reference brings about the original execution context, the reader can then branch off of those references to create new ones for themselves. Additionally, because each emulated instance is just JavaScript running in an HTML element in browser, it is easy to embed multiple references to a comparative set of objects and interact with them at the same time. In the previous version of GISST, an example included playing through a Japanese game and its North America localization at the same time with the same input stream to reveal real-time interactive differences between the two games. 

With a large enough corpus of searchable references, future game and software scholars could immediately recover emulated states from a broad swath of commercial and entertainment software. A demonstration poster of GISST at a recent games conference included QR code links to running games that attendees could load immediately on their smartphones [15]. Further, because the emulator is running completely within the browser context (instead of being streamed in through cloud-based video output) it is possible to manipulate and introspect on the system itself as it is running. Users could add specific visual effects and shaders to the appearance of games to mimic historical displays. Others could run system profiling software to analysis the execution and design of legacy software systems. The possibility space for program analysis and visualization is vast, and having indexed references to a variety of interesting pre-configured moments could accelerate those areas of study. 

Lastly, the creation of a large number of references could also allow for the analysis of a corpus of software states and interactions for training machine learning models. The trained model could then help locate similar input sequences or state representations across disparate objects. In effect, you could record a software interaction or a state and then see if other programs provided similar structures.

Practitioner Use

In digital preservation, there is a consistent need for easier methods to visualize and validate software dependent data. Many times, one needs to have an intimate knowledge of a piece of software or the contents of an imaged disk to begin the often arduous process of recovery through emulation. GISST would allow for a practitioner, in a standard browser window, to load disk images into a configured system quickly and check the disk’s contents. As the references to a number of different environments are saved, it would become easier and easier to recover a larger range of items. Once an environment is configured and referenced, bringing it up again is as simple as loading the page. Since each browser tab is a complete instance of a GISST reference, they are also cheap to throw away and reconfigure. 

Saving input performances also provides avenues for both interactive training in historical systems and in the application of the same input stream onto different, though related, instances of particular software items. If there was a need to illustrate how to interact with data in a particular historical context, an interactive reference to that interaction could be recorded and then imitated and repeated within the exact same context. In the alpha-testing work, a number of users were unfamiliar with how to do common things within older operating systems, like managing software installations, or even understanding how to navigate to different OS windows or shut down a system. With the possibility of referencing and retrieving these interaction issues comes the possibly of a library of references to common software interaction problems and their resolutions. 

As noted in Cochrane [20], comparative rendering is also a common method for evaluating the validity and consistency of digital objects. GISST’s ability to juxtapose multiple versions of a file in multiple execution contexts would allow for more fine-grained analysis of different representations of certain objects. Once configured, it would be relatively simple, for example, to load a historical Microsoft Word .doc file in a number of different Microsoft Word contexts across a variety of Microsoft Windows platforms. Currently, the v86 emulator powering GISST provides consistent performance up to Microsoft Windows 2000. Additionally, while GISST is primarily a web-based tool, the state files, disk images, and other referenced data objects are all compatible with other common emulation frameworks. An image manipulated in v86 can be saved then loaded into a local qEMU instance, and a save state from GISST’s WASM-compiled version of RetroArch will also load within a local version of RetroArch since they are literally the same code base compiled for two different contexts. The practical advantages of ready-at-hand referenced emulated states are still to be determined, but GISST enables this experimentation to begin in earnest.

Finally, since GISST supports floppy disk and hard drive images, it will be possible to allow users to import those images into GISST and immediately access their contents within the corresponding emulated system. For example, one could locate an imaged disk from an archived collection, and if they knew the corresponding operating system, could load the disk in GISST and examine its contents. GISST also supports file-level indexing of compatible image formats, so a user could then easily extract files from the image to their local system, or use the emulator to migrate files and then extract them. As everything is managed through the browser, the ease of accessing data within the emulated system is more straightforward than other local and cloud-based solutions.

Limitations

While most of this paper details the potential for executable citations through GISST, we are aware of a number of significant limitations with this approach. This section will elaborate on issues telegraphed earlier in the paper, and point toward some tentative solutions where applicable.

The goal of any system of reference is toward durability and persistence. While the design of GISST does allow for persistent storage of references and their accompanying data, the durability of the preserved works is still in the hands of evolving browser standards and compatibility. Each GISST reference is a compiled JavaScript WASM emulator with historical data installed into or mounted within it. While the data itself will remain consistent, the emulators themselves will continue (or may cease) development. As seen with the recent collapse of the Citra and Yuzu Nintendo DS and Switch emulators [21], the development of certain emulators will always occur within dubious legal territory.

The emulators powering GISST are long-standing open-source projects run by computing enthusiasts. They are constantly updating to newer versions and potentially changing internal APIs in a way that may break saved state compatibility. GISST does save the compiled binaries for all the environments its references, so backward compatibility is preserved within the system. However, if standards for the interpretation of WASM are fundamentally altered, then even the compiled binaries may not function correctly in updated browsers. In this eventuality, one would need to run a compatible browser within an emulator to maintain the connection to the correct WASM interpreter. Given that WASM is an emerging standard, it is likely that some compatibility layer will be present to prevent this eventuality but there is no guarantee.

Another potential issue is in the fragmentation of resolvable references. If a paper is published with a GISST reference, will the link need to be globally resolvable or will there be an expectation that one would need access to the specific GISST server on which the reference was stored. This issue is a major threat to wide-scale adoption of a system like GISST, but does not preclude many of the local, intra-institutional or personal use cases for the system. In these cases, the reference might need to be recovered through VPN or proxy access to a particular archival collection.

Conclusion

As elaborated above, the potential for cited embeddable emulated state is great, and the GISST system allows for the beginnings of experimentation with the citable state concept. The team behind GISST is working on a variety of improvements to the current system as well as the generalization of GISST functionality to allow for integration with other systems that managed pre-configured emulations. Because the emulator underlying GISST’s x86 emulation (v86) is compatible with many common hard disk, optical, and floppy disk image formats, it is already possible to configure an emulated system in qEMU and then insert it directly into GISST’s infrastructure. Similarly, members of the EaaSI team are also advising on the GISST project, and we are working on the potential for integration of GISST and EaaSI. In the most limited sense this would just involve sharing configured images between the systems.

Future work is currently planned on allowing for easier user configuration of emulations within GISST. Currently, we are manually adding items and systems as requested by users but a drag-and-drop interface is being developed to allow for users themselves to setup objects within GISST. Other pending enhancements include the automatic generation of textual citations to referenced states and embed codes for use in other online contexts. There is also a desktop version of GISST in development through the web-app to native-app framework Electron. A desktop version of GISST would function identically to the web-based one but allow for the native application to load most recent emulators, including current operating systems like Microsoft Windows 10 and 11.

In conclusion, this work is only the beginning for GISST and our explorations of executable citations. We are planning on organizing a consortium of institutions and partners to continue testing the system. Hopefully an ecosystem of similar projects manifests in a way that enables interoperability and standardization of references to emulated states and performances.

ACKNOWLEDGMENTS

This work made possible by US National Endowment for the Humanities Digital Humanities Advancement Grant (HAA-290396-23).