Not necessarily. For example, if there is custom hardware used for communications with other systems, such as radar for example, there might be specific timing and latency requirements that could be difficult to meet under emulation.
The most recent Dolphin Emulator post referenced a bug they had where memory cards were written to too quickly under the emulator (and even on actual hardware if you had memory cards that were sufficiently fast) which caused some games problems because they did not expect save files to be written so quickly. Imagine things like that, but where the worst case isn't having Wind Waker hang while saving, but planes crashing.
A long time ago, ..., so add a huge IIRC for the details.
Anyway, a long time ago, in a physic lab class, we had a custom spectrometer device that was controlled using the printer port. (Probably a light, a detector, a diffraction grid and a steppers motor, and perhaps some weird card as an interface to the computer.) It was controlled by a custom Pascal program in the DOS command line.
It was connected to a Win 95 computer that died and we had to replace it with a Win 2000 one. The problem is that anyone can read/write the printer port in Win 95 but that's not possible in Win 2000. [1] We had to make some magic, probably rewrite the program and use some weird device driver to write to the printer port (IIRC again). And multitasking messed the timing. At the end it worked, but upgrading the computer was not easy.
[1] If that makes no sense, replace that with a Win 3.1 to Win 95 transition, but I think it was not that old.
I had similar many years ago in a custom paint shop. We had an expensive colorimeter that interfaced over serial with a program that ran in DOS.
When the pysical computer gave out, I replaced it with a reasonably new one but instead of using a modern OS I installed MS-DOS in order to get it up and running as reliably and quickly as possible.
If I were doing the same today, I'd likely get a new computer and install FreeDOS.
Back when I was designing electronic circuits, the rule was to design for minimum speed, but faster speed should not cause a failure. The rationale was that newer parts were usually faster, and the older parts disappeared.
Of course, nothing can prevent poorly designed code and hardware.
The speed thing was just an example that easily came to mind. I can imagine there are other kinds of analog vs digital interactions that might be occurring that may not be easily replicated under emulation. Especially with a system that grew somewhat organically over the last half-century.
Emulation is likely possible, probably for many of the systems involved, but this is not a field where bugs, especially ones introduced due to emulation, would be easily acceptable.
> Of course, nothing can prevent poorly designed code and hardware.
Agreed, but the reality is that here, trying to fix things and ending up breaking them can and probably will kill people.
> Being terrified of progress means you're likely to kill far more people.
I'm not really sure what you're arguing for, or against, here. Nobody denies that changes are needed. The hardware is failing and buying new isn't possible to do seamlessly because of the age of the software.
The discussion is whether emulation is a possibility and people are pointing out that this comes with its own risks, so the discussion should centre around whether the cost/risk of emulation is lower than the cost/risk of building completely new systems.
The most recent Dolphin Emulator post referenced a bug they had where memory cards were written to too quickly under the emulator (and even on actual hardware if you had memory cards that were sufficiently fast) which caused some games problems because they did not expect save files to be written so quickly. Imagine things like that, but where the worst case isn't having Wind Waker hang while saving, but planes crashing.