h3. Hardware emulation
Emulation avoids the need to write new software in the future to render obsolete formats. This is a significant advantage, since an obsolete format must be understood in great detail in order to write such rendering programs, which may require extensive research and possible reverse engineering 23 if the format in question is not well documented.
The hardware emulation approach described here is the only way that has so far been proposed to run original software on future computers. This means that the behaviour of that original software will be recreated (within the limits of the emulation approach, as discussed below) without anyone needing to understand or rewrite any of that software. None of the original rendering programs or their original operating system environments need be recreated or modified in any way: they are simply saved and run exactly as they were originally, albeit under emulation on future computers. When this original software is run under emulation in the future, it should be completely unaware that it is running on anything other than its original hardware. Running a digital record's original rendering software in this way should allow preserving and rendering the record in its original format.
The major advantage of hardware emulation is that the original file does not have to be migrated of converted. However, writing an emulator of a given computer system (including its peripherals) is not a trivial undertaking. Yet only one such emulator need ever be written for any given type of computer.
Examples: [QEMU|http://wiki.qemu.org/Main_Page] and [Dioscuri|http://dioscuri.sourceforge.net]
h3. Other approaches
h4. Virtual machine approach
like UVC could in principle be used as a virtual host for a hardware emulator
h4. operating system emulation
Emulation on this level mimics the behaviour of a certain operating system on top of a host computer. This approach allows the user to run any application on the emulated operating system as it were the native system. However, accurate recreation of the OS is difficult when the source code is not open or when documentation about its inner workings is scars.
One example often mentioned in this context is [Wine|http://www.winehq.org/] . Although Wine is officially not an emulator itself (its recursive name stands for Wine Is Not an Emulator), it does mimic a Microsoft Windows environment on top of a Unix-like operating system. It does this by reimplementing the DLLs used by Windows and refer them to the look-a-like DLLs.
h4. application emulation
On this level an emulator mimics the exact behaviour of one or a group of applications.
Emulation avoids the need to write new software in the future to render obsolete formats. This is a significant advantage, since an obsolete format must be understood in great detail in order to write such rendering programs, which may require extensive research and possible reverse engineering 23 if the format in question is not well documented.
The hardware emulation approach described here is the only way that has so far been proposed to run original software on future computers. This means that the behaviour of that original software will be recreated (within the limits of the emulation approach, as discussed below) without anyone needing to understand or rewrite any of that software. None of the original rendering programs or their original operating system environments need be recreated or modified in any way: they are simply saved and run exactly as they were originally, albeit under emulation on future computers. When this original software is run under emulation in the future, it should be completely unaware that it is running on anything other than its original hardware. Running a digital record's original rendering software in this way should allow preserving and rendering the record in its original format.
The major advantage of hardware emulation is that the original file does not have to be migrated of converted. However, writing an emulator of a given computer system (including its peripherals) is not a trivial undertaking. Yet only one such emulator need ever be written for any given type of computer.
Examples: [QEMU|http://wiki.qemu.org/Main_Page] and [Dioscuri|http://dioscuri.sourceforge.net]
h3. Other approaches
h4. Virtual machine approach
like UVC could in principle be used as a virtual host for a hardware emulator
h4. operating system emulation
Emulation on this level mimics the behaviour of a certain operating system on top of a host computer. This approach allows the user to run any application on the emulated operating system as it were the native system. However, accurate recreation of the OS is difficult when the source code is not open or when documentation about its inner workings is scars.
One example often mentioned in this context is [Wine|http://www.winehq.org/] . Although Wine is officially not an emulator itself (its recursive name stands for Wine Is Not an Emulator), it does mimic a Microsoft Windows environment on top of a Unix-like operating system. It does this by reimplementing the DLLs used by Windows and refer them to the look-a-like DLLs.
h4. application emulation
On this level an emulator mimics the exact behaviour of one or a group of applications.