188.8.131.52 Potential Emulation Approaches
There may be a mandatory requirement from the Designated Community to maintain the look and feel of proprietary Access Software because of the large number of AIUs that are dependent on that Access Software. Proprietary Access software will not have readily available Structure and Semantic Representation Information for the Content Data Object. In this case, if the OAIS is unable to obtain the source code, or has the source code but lacks the ability to create the required application for example because of unavailability of a compiler or operating environment, it may find it necessary to investigate use of an emulation approach.
The OAIS could consider emulating the application. If the application provides a well- known set of operations and a well-defined API for access, the API could be adequately documented and tested to attempt an emulation of the application.
One approach is emulation of the underlying hardware. One advantage of hardware emulation is the claim that once a hardware platform is emulated successfully all operating systems and applications that ran on the original platform can be run without modification on the new platform. However, the level of emulation is relevant (for example whether it goes down to the level of duplicating the timing of CPU instruction execution). Moreover, this does not take into account dependencies on input/output devices.
Emulation has been used successfully when a very popular operating system is to be run on a hardware system for which it was not designed, such as running a version of Windows™ on a SUN™ machine. However, even in this case, when strong market forces encourage this approach, not all applications will necessarily run correctly or perform adequately under the emulated environment. For example, it may not be possible to fully simulate all of the old hardware dependencies and timings, because of the constraints of the new hardware environment. Further, when the application presents information to a human interface, determining that some new device is still presenting the information correctly is problematical and suggests the need to have made a separate recording of the information presentation to use for validation. Once emulation has been adopted, the resulting system is particularly vulnerable to previously unknown software errors that may seriously jeopardize continued information access. Given these constraints, the technical and economic hurdles to hardware emulation appear substantial except where the emulation is of a rendering process, such as displaying an image of a document page or playing a sound within a single system.
There have been investigations of alternative emulation approaches, such as the development of a virtual machine architecture or emulation at the operating system level. These approaches solve some of the issues of hardware emulation, but introduce new concerns. In addition, emulation research efforts often involve a centralized architecture with control over all peripherals. The level of complexity of the interfaces and interactions with a ubiquitous distributed computing environment (i.e., WWW and JAVA or more general client-server architectures) with heterogeneous clients may introduce requirements that go beyond the scope of current emulation efforts. Emulating an operating environment with a small number of applications to be supported would make testing easier and appear to offer less risk of information loss. When emulations are developed to support long-term preservation, their deployment is a logical extension of the Representation Information employed by the Access software they support. Therefore deploying such emulations is considered to be a Transformation type of Migration and the process should be documented in the associated PDI of all the AIUs.