Ask HN: Who's still keeping a DOS machine up because the business depends on it?
* dBase/Clipper/CLARION/Paradox/other DOS RAD environments on period hardware to run business processes?
* CNC mills/spectrometers/microscopes/other industrial instruments controlled by ISA cards (either bespoke or standards like GPIB)?
* Anything with a parallel port dongle?
If so, I'd be very interested in hearing your experience here, or feel free to send me an email at the address in my profile. I'm not trying to sell anything, just doing some research for an idea around keeping these going on modern hardware.
Discussion 294 comments
The big problem will almost always be some hardware dependency that breaks, almost always in I/O. I've seen video software used by TV producers that depended on an ISA (not EISA nor PCI, ISA) card to read NTSC input and impose text over it. And it broke as they were getting ready to add commentary to a live broadcast of a race (which I was driving in.)
The world is full of machine tools and metrology devices that are stuck on some ancient computer/software because they made a weird proprietary protocol over the top of a centronics connector, or some other "WHAT were they thinking??" construction...
All of these could be overcome with a new I/O device, and/or writing a device driver. So using say a raspberry PI that talks ethernet to your "monitor" PC is probably relatively change proof.
If there is any documentation, if anybody can find said docs, if there's budget for a new I/O card and the device driver to go with it. Often the parties who have those resources would rather sell you a new machine tool, metrology machine, or I suppose, nuclear reactor (:-)
Of course, certification is a big deal... A particular certification structure led to the 737 MAX tragedies. And since certifying authorities don't always have detailed tech knowledge of what things are, they have a hard time saying "no, you can't slide that by, you have to build and certify a new thing".
A second computer has an MS-DOS program that captures data input on a pair of RS-422 ports (two more special ISA cards) That let me look at packet data at a low level and watch which serial port received what data, and track character-level handshaking of a proprietary protocol.
A third computer under Windows 2000 ran a 68HC11 cross-compiler that didn't require a dongle. I also used this to run a remote debugger that allowed me to single-step through the 68HC11 code running on the target but moved to the target's RAM. To do this 'properly' I was constantly generating hard-copies from the compiler which would show me the C-code, and the resulting assembler code that I'd track through the debugger. I used a lot of paper on a project sometimes.
A fourth computer with MS-DOS, with WFWG3.11 also installed on it, had all my old CAD programs on it, from before they required dongles, so that I could pull-up drawings of some of the hardware I designed. Some of those were finicky about which mouse I use. I still have an old Logitech mouse C7 that two of my CAD programs required.
I was working on a replacement platform that put this into an Atmel-based controller, shipped a couple of samples, then went blind in one eye, while my client had a stroke and was out of action for a year. Between both of our health problems, that project kind of died.
https://www.youtube.com/watch?v=tXdLtnt-nvE
Original Polish article - https://www.trojmiasto.pl/wiadomosci/Warszatat-samochodowy-z...
https://www.extremetech.com/cars/227828-the-mclaren-f1-super...
We've already got it running on modern hardware. It's running under qemu. And the dBase stuff gets ripped out and sent to a REST server for broad monitoring and so on.
We... Have one small oddity? There's a tape backup system, that throws everything through the soundcard. (Sound Blaster only.)
Would be nice if onboarders didn't see dBase and just throw everything at AI instead of actually learning the skills they'll need when data migrations happen. But that's a people problem that can't be solved with tech.
Some of theses solutions are built upon common PLCs but some are built as standalone solutions when I/O are simple enough (modbus mainly, RS232/422/485, ethernet/IP, controlnet, ...). Seen lot of them in breeding nutrition management systems, in-house developped processes, ...
The newer version of that anaylzer, STA Compact Max [2] has mostly the same analyzer hardware, but newer ITX board inside. It runs Windows (XP, 7, 10...). Bugs galore.
I know labs that used a Beckman-Coulter HmX hematology analyzer [3] until 2015 or so. That machine is attached to an external MS-DOS computer via a very thick cable and an ISA board. The cable connector looked a bit like a 68-pin SCSI-3. The software used VGA graphics mode.
[1] https://www.youtube.com/watch?v=Kti6Zdyp8dQ
[2] https://www.youtube.com/watch?v=MJan25vkpEA
[3] https://www.soriaudio.com/index.php?mid=m_eqp&document_srl=62138152With the advent of USB and SATA we ceased to be able to source industrial embedded x86 boards which could run the application. At the time this was with Novell DR-DOS, which was relatively modern in terms of hardware support but still behind the times and we were struggling to manufacture new systems. The company was very small, so a full rewrite was investigated--I did a prototype using PostgreSQL and Gtkmm--but it wasn't realistic. Today, an AI could probably do a full rewrite in a day or two, including migration tooling. Back then, it would have been a multi-year effort for one person given the application's size and complexity.
My solution was to run Linux since it had full support for the hardware. Debian Sarge at the time. This used a Perl frontend and dialog(1) to present a simple menu system at startup. This did backups, software updates (over dialup!), remote access for support (again over dialup), ran backups and ran the main application. It would start DOSEMU which provided the application with VGA display, COM ports and parallel ports for the application to drive "directly" (from its perspective). It also used Samba and CUPS to provide the DOS environment with shared network drives with exclusive byte-range file locking needed for the multi-user network database to work with concurrent users without data corruption, and also multi-user report printing and receipt printing.
I left the company a year after this was put into full production, but the last I heard it kept the company viable with a supportable product for many years after until its owners retired. This kept software from the early 1990s running well into the 2010s, and there are likely still sites running it to this day.
A FTSE 100 company I used to work for, still maintains a SCO UNIX machine that was first installed in 1993. It hasn't had any upgrades since, has specialist hardware in it, and still has an IP stack that is classful (ie. no subnet masks, 10.x.x.x is always a /8). It runs in a 100% airgapped network, and it isn't essential to keeping the core companies operations, but it is a ticking time bomb nobody seems to want to address that will cause a lot of distruption when it finally dies.
Also I was recently (very lightly) involved in a consultancy project to remove an OS/2 based point of sale system for a small local retailer with 6 stores.
They have what are called "supertitles" [0] so that people can follow along with what the opera singers are actually saying. There is one on the back of each seat in the theater.
As near as I can figure, it's basically hundreds of LCD displays on some kind of bus network and connected to a computer via serial connection aka "D pin connector".
The software only runs on Windows XP and he has to keep finding old Windows XP machines on eBay in order to keep it working. I think he also has a couple hard drive images of the working OS + software.
I had suggested using a USB to D pin adapter and then use an LLM to sniff the protocol and then reverse engineer it.
His response:
"It HAS to work correctly. In 30 years we've never had an outage with the old system."
You're right, it is a bunch of LCDs on a bus (iirc rs485).
After September 11, 2001, somebody came in from the federal government and ordered Windows XP to be the minimum OS for some security issue. The person who had to update that system said a 233 MHz machine was too-slow for XP, and she didn't have a replacement computer, she was already short on computers.
The next time I saw it, it was running XP.
They do not even have an OS!
You're underselling it. The ex oldest operating signal box in Hörlkofen was finally removed from service less than a year ago, 2025-12-12.
It entered service in 1899.
We managed to virtualise it and then run it in a VM, and it needed a couple of USB-to-serial adapters passing through as well.
We're also finding some kiosks are running Shockwave Flash apps provided by companies that are no longer trading. We can decompile the files to extract the assets but at some point it's easier to just replace completely.
What do you use for VMs these days?
I have a client with some business software that runs on DOS. They have a dozen seats. A single Linux server gives serves a dozen VNC sessions with the software running in DOSEMU. Printing is done with the Linux print stack and three Ethernet print servers.
It has been working without a hitch since 2008. Oh, so has the server, which is a VirtualBox VM.
Closest I got was with a GOTEK and an ESP32 emulating a USB. But it was flaky so I dropped it for now.
Edit: There is no required hardware, however maintaining a stable serial connection through a VM and timing issues due to faster hardware has been fun.
In 30 years time it will all be outdated... But emulators will exist and a business process in 2050 that still depended on something I built today could still run with minimal effort or risk.
The Field PG has also another special port called "MPI/Profibus" for S7 PLCs, 2 Ethernet ports and a DVD drive.
https://support.industry.siemens.com/cs/document/109766662/d...
The bevel gear generator setup was some formula calculations running in version 1 of TK!solver, which would have been a $5000 upgrade to get the latest version, so they ran them under MS-DOS in DOSbox, and saved the grief.
Without that software, they would have to pay Gleason $500+ to do the calculations for each new gear setup.
There are strong and reasonable reasons to keep very old systems alive in offline production environments.
Keeping old hardware running is very fragile. Most spare parts are decades old now too, and nobody knows if they still work properly.
The DMA might actually be the easy part.
The main concern is how many VM exits per second a modern CPU can handle. Even though the interface is "slow", you can probably do ~500k to 1 million IN/OUTs or MOVs per second to ISA. You'd have to trap (VM exit) every access to a IO port or memory within the ISA window.
During the pandemic I cobbled together a KVM-accelerated emulator for an old 386EX based board I had and trapping every memory access to IO was slower than the real hardware.
ISA motherboards still work and have been mass produced in the hundreds of millions. (I have about a dozen in my retro closet.)
The esoteric ISA expansion cards would be the bottleneck, not the motherboards.
With a modern 4 GHz CPU, that means your budget is only 4000 clocks per interrupt. The context save alone can make it hard to hit 1MHz, and you really want to have your interrupt code pinned to the L1 cache because a few memory reads will blow your entire budget.
As nice as USB4 is, I’ve never heard anyone claim it has single-digit microsecond latency, to say nothing of sub-microsecond latency. The typically-quoted ~20 usec latency of USB4 limits it to around 50 kHz for an emulated ISA card.
At the same time ISA card will never reach 40Gbps throughout with CPU clocking at tens of MHz only or often less.
https://www.reddit.com/r/vintagecomputing/comments/jbaw38/is... (2020)
ISA-over-USB, using real ISA cards in an emulator
https://en.wikipedia.org/wiki/Low_Pin_Count#ISA-compatible_o...
They run on punch tape.
So this Apple ][ is connected to simulate the punch tape reader, and send the (I think) G-code commands to the machine. So it's now a CNC, managed by an Apple ][.
Your use of “when” is interesting - suggests it’s not that occasional. Wonder what people are doing with these nowadays.
If it goes down, the company gets fined. It happened in the gap between my predecessor leaving, and me being hired.
Fortunately, I don't have to deal with swapping parts. There's an outside contractor on call 24/7 for that.
The last time I saw it was about two years ago when I taped yet another piece of paper to the filing cabinet it sits on reading "DO NOT TURN OFF UNDER PENALTY OF LAW!"
Someone keeps taking the paper down.
I suspect he could have found a way to use a newer computer, but if it ain’t broke…
The cost of upgrading to modern software and hardware is substantial, plus the learning curve for something I only do rarely nowadays.
i do not have exp myself but i found it a delightful reasoning. i told him modern PC could also do the same on modern OS (ncurses or ratatui or so maybe) but that if he ask a programmer to make an upgrade he'd need to find the right kind of guy. He had someone do it few times but they came back with web interfaces.
(He was a good contractor, so clearly having the latest billing software is not the deciding factor in that.)
To give you an idea of the complexity of the manufacturing lines, shutting the machines down and starting them back up again was measured in days. Upgrading them would be obscenely expensive, let alone replacing them, just in the opportunity cost of not making anything alone.
The last machines with dock port have 6th gen Core CPUs (Latitude E5x70), or 7th gen for Precision 7x20.
It is possible, perhaps almost a certainly, that the company did not own the source code for the application and could or would not attempt to rewrite it to work with a modern operating system.
This is a top brand name company, so it isn't like they couldn't throw money at the problem, but with the number of lines in the number of plants they had, there wasn't really any reason to not keep the old hardware running (sans Internet connection).
I'm pretty sure they moved on from them, but a while ago I did seasonal work for a company that rented out scanners for year end inventory (tax related, IIRC). The scanners had to be "cooked" (flashed) on racks, boxed, and sent. The flashing usually worked, but on occasion, the scanner would fail the checksum or something and drop you into a DOS prompt.
And I would even bet that in most cases you could run a solution on a sub $10 board from aliexpress.
It was a test/repair bench for military aircraft avionics, with the only flying platform left using it being the legacy F/A-18 (A/B/C/D). Harris H-100 minicomputer hooked to an HP terminal and several full racks of GPIB test equipment with half of a rack of solenoids for switching between stimulus and response and which pin.
Not what you asked, but the question brought back memories.
The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.
The original software was written back in the 80's, when the plant was originally commissioned, for AmigaOS. Of course, it's hard to buy Amigas anymore, and the original one died long ago (nobody remembers when).
So in the mid '90s, the utility purchased an AmigaOS emulator that ran on Windows NT 4.0, which was current at the time. The emulator (IIRC) was developed by a firm in the UK. The firm went out of business sometime in the late '90s. The control rod monitoring software ran under this emulator on top of NT4.
Windows NT 4.0 was the last OS to allow the emulation software direct access to the physical hardware that produced the status signal. Later versions of Windows abstracted the hardware access away, and the monitoring software broke. Because the emulation company had gone belly up, there was no way to fix the incompatibility.
So the utility had a choice: get new hardware/software certified (by NRC?), or keep doing what they were doing with the software (and hardware) that they had. They chose the latter.
So this is how, in 2007, during a tour of the facility, I stumbled across a Pentium 1 system running an AmigaOS emulator on Windows NT 4.0 that was responsible for displaying the status of the control rods of a nuclear power plant.
Spare hardware for this setup was purchased off of eBay and stocked on an adjacent shelf.
NOTE ON JAVA SUPPORT. THE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ONLINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Sun Microsystems, Inc. has contractually obligated Microsoft to make this disclaimer.
Also:
The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.
It would take a whole lot more context to make this somehow comforting. :D
This is this fascinating 6 part documentary about the Chernobyl incident explaining how it was caused by bad control rods. But the main point is that control rods prevent the facility from going boom, so be glad it’s not the AmigaOS emulator on a NT machine handling it.
Then their ancient Honeywell(?) mainframes reached end-of-life they scouted for compatible hardware, of which there was none. The cost of certifying new software, plus the time involved, was astronomical. So, after consulting with the FAA, they paid a hardware company to clone the ancient mainframes in modern silicon. The FAA signed off on it, and they had all-new computers - much smaller than the originals - running the old stack.
Compuserve also had a software dependency on the PDP-10 and Decsystem 20, and when those machines were no longer available they bought a company making clones so they could continue to manufacture them for themselves. The company they bought, Microsolutions, was Mark Cuban's first startup.
making clones of mainframes (IBM's) had been a big area of intellectual property litigation, but also facing monopolization investigations, IBM had to allow them. They were referred to as "plug compatibles".
It's not hard to imagine a similar system fabricated around an open or licensed processor core today being well within the budget of a major airline today.
Software emulation would no doubt be less expensive, but there could have been regulatory reasons for building plug-compatible hardware.
[1] https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
Cannot refrain myself from asking why ...
Time-evolution: P1 is deprecated, replaced by uncertified P2, but S1 remains certified.. just nowhere certified to run yet.
Solution: There's another software S2 which originally vouched for P1, itself still certified, which can still be used to certify P2.
Counterfactual?: If S1 were deprecated in favor of new S3.. there'd be no plan to certify it!
The problem: None of this actually makes any sense! But we're trying to fake due diligence. Everyone knows the hardware/platforms kinda need to be certified with respect to each other anyway, but if we did it that way it would all be even more expensive an time-consuming.
https://www.computerhistory.org/collections/catalog/10277383... https://www.twenex.org/?network
as far as i know the control plane on their equipment is still a pdp-10 compatible
FWIW I'm developing "tiny-titan", a stand-in for Cambridge's Titan mainframe that talks to Heinz Lemke's 1972 PIXIE program over an emulated version of Neil Wiseman's PDP-7 <=> Titan link. It doesn't emulate Titan itself, just the conversation PIXIE had with it, so the unmodified 1972 PDP-7 code dials home and uploads its drawings.
https://en.wikipedia.org/wiki/Titan_(1963_computer)
>Titan was the prototype of the Atlas 2 computer developed by Ferranti and the University of Cambridge Mathematical Laboratory in Cambridge, England. It was designed starting in 1963, and in operation from 1964 to 1973.
https://news.ycombinator.com/item?id=49407938
https://news.ycombinator.com/item?id=40617894
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
UNIVERSITY MATHEMATICAL LABORATORY, CAMBRIDGE: Cambridge Supervisor - Planning Document 10 Software for the Titan/PDP-7 link:
https://cucps.soc.srcf.net/titan/supplan/pd10.htm
Here is a photo of Heinz Lemke operating PIXIE with the light pen and 340 display on the PDP-7 (also seen in the video above):
https://www.facebook.com/groups/779220482206901/posts/629772...
I am interested in how firmware is treated, since perhaps in the case of these old machines it's small enough to be analyzable or at least cloned bit-for-bit.
https://www.youtube.com/watch?v=AcQifPHcMLE
The simulator has a simulated cockpit for the user, which controls an armature with a camera attached that is piloted around a miniature battlefield environment and provides a video feed to the cockpit. A "foot" on the armature senses terrain elevation changes, which are then supplied as movement feedback to the simulated tank cockpit. All of this was controlled by a 1970s mainframe, for which replacement parts were unavailable so it was replaced, in the museum exhibit, with a Raspberry Pi.
It looks like hardware emulation was NOT used; rather, they translated the original program from paper printouts to a modern programming language: https://www.raspberrypi.com/news/simulate-driving-a-1970s-ta...
https://en.wikipedia.org/wiki/GE-600_series from the 36-bit era which turned out to be a sweet-spot for Lisp; also "famous" for running Multics (old joke flipped: "which was many of whatever unix is one of")
GE sold it's division to Honeywell, and from there to Group Bull (French) and then to NEC (Japan)
[1] https://man.freebsd.org/cgi/man.cgi?query=passwd&apropos=0&s...
Thats far more advanced than the systems I worked with, one of which reported rod position via resistance measurement on a brushed cylinder (one for angular and one for depth).
Cleaning and calibrating those was a constant maintenance item every time the reactor was shut down.
Then define the version control system and the build process, specifying the dependencies, and so on.
Think about any opaque blobs in the system and try to eliminate them so that you have plain text source code so that no tools are needed to read the code.
Make sure that the build process runs entirely locally and never fetches anything from outside.
Simplify everything, use only tools and languages that are well understood and supported.
The real problems are not strictly technical but social: how do you prevent loss of the code, the tools, the specification, how do you maintain the expertise needed to maintain it. How do you ensure that all those things that are obvious to you now are written down in all their gory detail so that your great grandchildren will not apply their new and different preconceived ideas to the system?
Document all this on paper as well as electronic storage, make sure that version ids are recorded on every page as well as being available to the user of the machine or program.
In the industry in which I worked for the last thirty years of my career it was not uncommon to have things come back for repair after fifty years use and to be able to consult the original drawings and bill of materials so that exact replacement parts could be made.
Some ideas:
Write it in a popular language/ecosystem, stick rigidly to well-defined APIs, use commodity hardware, flatten out any malignant cleverness, maintain documentation on why every part does the thing it does, and make the source code readily available.
This is based on working with some very old systems, and each point above is the opposite of something that made life harder.
I’d go for “universal and timeless”, which has meant C for several decades now. There is, I’d concede, a reasonable chance that Rust obtains that label in our lifetimes.
Neither is popular when compared to for example Python or PHP, but they both have cultures that care about stability in the core runtime and the libraries. Most folks probably don’t know that about Erlang and maybe think it’s some new whiz-bang thing, but Erlang is incredibly stable and well supported by a dedicated team that has been doing it for years and years at this point. I don’t know if Erlang will be more or less popular in 20 years but it 100% will be around and be receiving updates, I would put money on it.
Maybe follow that. It's 2026 right now. What way of writing code would have worked 50 years ago (1976) that still works today?
Well, C, SQL and Lisp were all around 50 years ago and still exist today.
In terms of hardware, 50 years ago there was intel 8080. apparently code for that can still work via emulation today.
So if you wrote C for low level, Lisp for high level, and compiled the software to run in an Intel 8080 emulator, that combo would likely still work in 50 years.
Then it becomes impossible to introduce database connection pool. Well, probably possible, but in single-process multithread server this is BSc grade job, and in multi-process server this is PhD grade job. libmysqlserver and others maintain some context near to the socket, in opaque way. Hard to pass context between processes. At least, hard to return used connection back to pool in main process. Proxy is also not an easy walk.
On client side although Windows NT had POSIX layer, and XP/2003 still had Interix SFU. But Windows Vista broke SFU. But then Vista has got SUA. But SUA was not binary compatible, required recompilation. And as of Windows 10 there was surely no SUA. Was it dropped in Windows 8? Windows 10 has got WSL eventually, but there was a gap between SUA and WSL. And deploying Windows application with SFU, SUA or WSL part is not easy walk. Writing installer is MSc grade job.
Then comes iPhone OS and Android. They are POSIX OSes. Kind of. But spawning external processes is prohibited or not desirable. This is what was blocking LaTeX adoption on mobiles.
That may not work for network connected software with lots of requests per second. But such software did not exist too much in 1976 either as there was not very much networking going on.
As for networking, both the ARPANET and Ethernet predate 1976, though neither were ubiqutitous and most high-volume networking would have been mainframes and related hardware connected via leased lines.
If it needs to run for fifty years, specify hardware that has a long support cycle such as Mil-Spec.
That’s why the Z80 was around for so long and why so many companies in the 80’s and 90’s still deigned around it. (1)
If you let programmers drive system design, winding up with an “Amiga” in your certified design is a more probable outcome…
(1) there’s a moderate chance that new hardware that can run Z80 code will be around fifty years from now.
Make it open-source, or don't buy without source.
Or, more broadly, in the context of any situation where the software is closely coupled to a specific operating system and/or hardware.
Having the source code would have helped tremendously, but might not have been sufficient because of the hardware story and the regulatory approval factor.
I thought "but what is the problem to generate EXE with relocation?" and tried GCC GNAT (from 2017), and GCC said no. EXE and DLL formats are very much the same, but GCC is completely unable to generate relocatable EXE. A very suprising discovery. More recent toolkits became aware that adding relocation to EXE is not a rocket science, just do the same like in DLL. But these recent toolkits may call APIs that HX DOS Extender does not support yet.
You in a lot of ways have to respect the ability to have done this in the first place, compared to todays slopware which manages to break within 1-2 mandatory OS update cycles.
IBM SOM executes on Windows 10. I have checked Visual Age for C++ Direct2SOM extensions, OpenDoc for Windows. Very good. 32-bit i386, but otherwise runnable, usable.
And Java is hard to build, hard to execute on modern Java toolkit. Java seemingly had no List, and authors made their own List, but when Java also got its List, that breaks the build. When building problems are resolved, runtime problems come. Original Java was seemingly fine with Property key being object, but modern Java only wants strings. And Property-based dictionaries are all around. PMtW is about building VMT, and there is multiple class inheritance in PMtW model, not matching Java's comparably limited OOP. So PMtW is building dictionaries for methods to support what is described in book, and foundational Java class is malfunctioning.
I did not finish this road, don't know so what does it take after all to run Java code from 1998 on modern Java toolkit. So far looks pathetic compared to Win32 programming.
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://web.archive.org/web/20231114211656/http://www.gareth...>
(Heck, recently I migrated a VM to its third hypervisor. It began as a physical machine a quarter century ago.)
I'm curious what changed in Windows 2000 that would have broken the emulator, though, as direct hardware access in any version of Window NT requires a driver, and I don't recall any major breaking changes to the driver architecture between NT 4 and Vista.
Coincidently, that's where my father was working as a programmer until the shutdown of the plant.
Anyways, he was maintaining a bunch of systems related to collecting data from environment monitoring sensors around the plant. In mid 2000s or so he showed me some data collecting machines using what looked like DOS text UI that mentioned being written in Leningrad, 1989 or 1988.
The software was running in an emulator on Linux, which my father used to replace original x86-compatible machines runninh dos.
Pretty sure thr whole thing was running for quite a while since my family moved elsewhere.
(Probably not literally true. But functionally true in the sense that they were likely transmitted via infected floppy disks, of which there'd be virtually none left in the wild in 2007)
https://en.wikipedia.org/wiki/Lamer_Exterminator
(Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory)
Sounds interesting, could you elaborate?