Information Technology Reference
In-Depth Information
lot of different software applications. But preserving the source for the applications
is still a good idea as it gives another option if no emulator for the binary form
of the software has been ported or documented. The other argument is that not all
software has the source available, i.e. propriety applications where only the binary
is available. In this case the only option if one needs to preserve the software is to
run it under an emulation environment.
7.9.4.3 Emulation, Recursion and the UVC
One can look at emulation from the point of view of recursion. One uses an emulator
to preserve software; the emulator is itself a piece of software - which needs to be
preserved, for example as the underlying hardware or operating systems change.
Some testbed examples are given in
Sect. 20.5
.
One way to halt the recursion is to jump out and instead of preserving the
“current” emulator one simply replaces it - one could look at this as a type of
transformation but that seems a little odd.
The source code of many emulators is available and so one can use a less drastic
alternative and make appropriate changes to the source code of the emulator being
used so that it works with the new hardware. This can work with a number of the
emulators discussed in the next section.
If the software one wishes to preserve is written in Java, then the challenge
becomes how to preserve the Java Virtual Machine (JVM); this is discussed in some
more detail in the next section.
It may be possible to develop a Universal Virtual Computer (UVC) [
89
].
However, recognising that one of the prime desirable features of a UVC is that it is
well defined and can be implemented on numerous architectures, it may be possible
to use something already in place, namely the JAVA Virtual Machine [
90
]. However
it is argued [
91
] that since the JVM has to be very efficient, because it needs to
run current applications at an acceptable speed, there are various constraints such
as fixed numbers of registers and pre-defined byte-size. The UVC on the other hand
can afford to run very slowly now, instead relying on future processors which should
be very much faster, as a result it can afford to be free of some of these constraints.
A “proof-of-concept” implementation of the UVC is available [
92
] - interest-
ingly that UVC is implemented in Java.
The only advantage for the UVC is if its architecture remains fixed for all time,
then at least some base software libraries written for it would continue to run. But
as soon software starts to require other software dependencies and specific versions,
then specifying those dependencies becomes a problem for the UVC just as it does
for any other system. Software maintenance is also a problem, in the future one may
need a lot of representation information to understand and use some software source
code or a binary.
Perhaps the biggest hurdle for the UVC is the need to write applications for the
UVC to deal with a variety of digital encoded information. However in principle
this effort can be widely shared for Rendered Digital Objects such as images, for
