A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007. The reason is interesting.
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.
To me the funny part of this story is that they used to show you this warning as part of the EULA when installing Windows NT 4, which I remember joking about:
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
> 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.
LOL at “Chernobyl accident was caused by bad control rods”. This seems to imply other control mechanisms worked, when in fact plant engineers could not even monitor the plant operations. They had malfunctioning Geiger counters. Also - plant engineers had no idea how much water was flowing through the nuclear core cooler. Monitors for the temperature of before mentioned water did not exist even on a whiteboard.
A friend works for an airline as a flight simulator tech. Their entire software stack, including the compiler and OS, is FAA-certified.
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.
There's a mechanical tank simulator at the Swiss Military Museum that was built in the 1970s and used for actual service before being retired and becoming a museum piece:
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.
Custom chips aren't as expensive as you think. About a few million dollars for the design and a hundred thousand chips, way out of reach for a hobbyist, but accessible to large enough companies. Just because it's opaque to us software people doesn't mean it's not a real industry you can buy things from.
Situation: Software-1 on Platform-1, both certified.
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.
Doesn't seem crazy to me. Which one do you suppose needs more proof of correctness: a cake recipe, or the oven you bake the cake in? The recipe has to be correct or the cake won't work, but the oven just has to hold a temperature.
Ovens vary greatly. There is no consistency in how even the heat is in the space, the airflow through the space, how much and how fast the temperature varies around the set temperature, etc. These things all do affect how things bake up and often people have to tweak recipes for their specific oven.
In a case where something is safety critical the computer is super important as very subtle errors could cause catastrophic consequences. This is why you get into things like running software on 3+ computers concurrently depending on how fail-safe something has to be.
When Xerox established PARC, they asked the assembled scientists what computer they wanted. The majority view was a DEC PDP-10 KA10, with the BBN memory management unit that let it run Tenex (the ancestor of DEC TOPS-20). Xerox couldn't really buy a competitor's mainframe, so they built MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
>MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
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".
The clone hardware manufacturer was Systems Concepts. Microsolutions was a software play -- I think they had something to do with trying to port 1022/1032.
IBM released the PC XT/370[1], built around a pair of 68000s and an 8087 with custom microcode to emulate System/370 instructions, in 1983.
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.
It could be an FPGA. Given enough gates, and the know-how to program them, you can make an FPGA emulate anything. Speed and efficiency could be better or worse, but if you're targeting old hardware, better is likely.
I mean...there's some precedent. The XKL TOAD ("Ten On A Desk") implements the PDP-10 instruction set, and will happily run TOPS-10/TOPS-20. LCM had one doing just that.
It's tempting to write a PDP-10 emulator for the Atari ST called TOAST.
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.
>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.
Meh, old architectures are relatively simple and you can get 95% of those via fpga softcores (some freely available, some paid) and run them on fpga. The rest can be implemented by a proper ee team.
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)
Also immortalized as the name of the "gecos" field in the UNIX passwd(5) file, described in the v7 man page[1] as "GCOS job number, box number, optional GCOS user-id" (GCOS = GECOS after the Honeywell acquisition).
Hardware is more amenable to static analysis than running programs which may receive an arbitrary number of inputs and express an arbitrary number of possible intermediate states.
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.
Having worked on nuclear plants (as a reactor operator) around that time this doesn't surprise me in the least.
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.
This is a great post. How does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware? If I were facing this issue today, I might start with an OS that has excellent emulation. Example: Can I run 32-bit MS Windows 95 via emulation on a variety of current 64-bit OSes, like MS Windows, Linux, AIX, HP-UX, etc. If yes, then we can assume(?) this emulation will remain relatively stable even if we upgrade our hardware later. Maybe I am overthinking the whole problem: Can VMs do exactly what I want today? Will VMs running ancient OSes, such as 32-bit MS Windows 95, continue to be stable/viable in the future? I am unsure.
Make sure that you have as thorough a specification of what the system is supposed to do as you can.
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.
Electricity distribution, mainly transformers from 10 kVA to 500 MVA and more.
It takes a long time to design and a lot of material to make a big transformer and they last for decades. They are critical infrastructure so when one fails you want it replaced or repaired quickly but they are too expensive (millions of dollars/pounds/euros) to keep a spare unit idle for decades and the lead time for a new large power transformer might be six months or even longer. So repair makes sense, especially if it can be done on site because moving a big metal box full of oil, steel, and copper that weighs hundreds of tonnes is a major logistical exercise.
This isn't something that can be done by a company that 'moves fast and breaks things' and disappears next year.
> How does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware?
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.
Unfortunately, “popular language/ecosystem” includes JavaScript and PHP.
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.
Yeah agreed. Popular is a good first approximation, but to be more precise I think you want tools where the incentives in the community reward stability over features that require breakage, which would include languages and runtimes like Erlang and Clojure.
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.
My C programs from a few decades ago, before namespaces were invented, no longer compile. However, the old executables still execute. The old C compilers are available but not supported; ChatGPT warns to expect trouble. Perhaps maybe there are compatibility switches that work correctly. Using them would require changing the makefiles.
Wasn't there some idea that went like "if something has been around for x years, it will likely be around for x more years"?
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.
C is very different C. There is C where programmer rushes to call fork(), just because he likes the idea of entering room once and exiting room twice. And this program has got excuse for his behavior. He has fork() in POSIX standard. So programming is using fork() here and there even if not strictly needed. Using fork()/exec() instead of more portable posix_spawn(). Using fork()/accept() instead of multithreading.
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.
Well I think if you were doing the 1976 way you might not even have multi processing or multi threading. Just a single process with a single thread. And so you don't have a database connection pool, you just have a single database connection and do one query at a time maybe.
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.
There were absolutely multiuser computer systems processing transactions from thousands of users in 1976.
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.
It's interesting to think about this in the context of parent poster's story about the Amiga emulator in the nuclear power plant.
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.
Even if VMs do not, whole-system emulators surely will.
But Windows 95 would be a poor choice, as you'd be stuck emulating a bunch of very specific aspects of both Windows (non-Unicode APIs, 16-bit application support, etc.) and the PC archictecture (BIOS, A20 gate, etc.) that exist only to maintain backwards compatibility.
If Windows is a requirement, you'd be better off building against something like the subset of Win32 APIs that has been stable since Windows Server 2003 and ideally testing against Wine, contributing patches as necessary.
If it were me, though, and it was something that required a general-purpose, non-realtime OS, and wasn't so performance-sensitive as to require deep integration with platform-specific APIs, my first thought is to target a Linux-compatible subset of FreeBSD, which should be enough to get you most of POSIX and then some, plus a full-featured GUI if necessary, portable between two open-source OSes that run on a wide variety of hardware.
I'd recommend not having it so dependent on the hardware and choose an OS that is relatively hardware agnostic (e.g. Linux). Also, ensure that the software is open source and if compiled, has an open source toolchain to do so.
Though people often decry it (due to the many, many footguns), writing something in Shell/BASH will make it trivial to move to newer machines.
DOS emulation is available more widely than Win32 emulation, and there is HX DOS Extender. I would try sticking to Win32 dlls runnable in HX DOS Extender. rundll32 or some other exe host. HX DOS Extender has no paging support and has problem loading multiple exe having no relocation info to the very same 4Mb base address they all usually pretend. DLL should have relocation.
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.
> How does someone write software that needs to run for ~50 years
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.
This was one of the promises of Java. You write your application and then you get a virtual machine (JVM). As time goes on you only maintain the virtual machine while the application remains the same.
The funny thing happened and verified this promise. There were several architects working on IBM System Object Model (SOM). In 1996-1997 many good things ended, and SOM was terminated. But the work was so good that two architects did not stop and wrote the book: Putting Metaclasses to Work (1998). That book has got reference implementation in Java. So we have IBM SOM as closed source binary and we have Java source codes.
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.
50 years ago, fortran iv had the "extended range of a do loop". You could jump out of a loop execute some code, then jump back in. Therefore 2 loops could execute the same out-of-loop code. It was useful; preprocessors like Flecs used it to emulate missing control structures.
ChatGPT says, "likely to need manual conversion". So no Fortran hasn't been stable. In another post I showed that C hasn't either.
>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.
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 grew up in a little post soviet republic, in a small town with a big nuclear power plant.
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.
That is an advanced question best asked of the folks in charge of the plant. At the time I was just trying to figure out how to explain to the IT auditors why there was no antivirus software on this piece of crap.
Could you skirt around it and just remark "there are no viruses for AmigaOS"
(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)
It wasn't the AmigaOS running in the emulator that they were worried about, it was the Windows system running the emulator. (Not that the average IT auditor there could have understood the difference.)
If it were a newer version of NT I'd be concerned about USB media, but being NT 4.0 and not supporting USB it's imminently more capable of being air-gapped than later versions. (I recall a fun Ed Skoudis quote-- "At best, an air gap is a high-latency connection". Evidence Stuxnet.)
Depends. A lot of these audits are quite prescriptive and don't leave much room for actually thinking about the problem. There is often some kind of mechanism for 'this is sufficiently segregated it doesn't matter that it's utterly out of date' but then usually some awkward rules develop that prevent some things from being put into that category. More subtly you can get whether the thing even exists as a thing that the audit cares about, and that often depends on the framing (embedded software is often invisible here but it needs to not look too much like a general-purpose OS even though it often is).
(Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory)
This is pretty universal in my experience any time you have inspectors/auditors intended to enforce a set of rules. The most common case is that they just miss some rule: they can be hard to properly map from what you're seeing to the rules reliably, so different auditors will miss different things (so you can get a sign off from one and then another highlights an actual contradiction).
The next level is that the rules are kind of vague or unclear and so different auditors will have different interpretation of it. You can try to fight it but ultimately the auditor is who needs to sign off on it. This is also why switching auditors can be a right pain.
Then you get interpretations which are flat out contradicted by the rules. Sometimes this is necessary to make the rules work (there's some blanket rule that's impractical to impossible to apply literally, so the auditors contort some interpretation that's more workable), sometimes it's just incompetence, and when it's wrong enough to matter sometimes it's easier to just go along with it than try to escalate the issue with the auditor.
You can also get situations where the auditor has their own pet rules, which aren't written down anywhere, but they will become much more adversarial if they are not followed (sometimes they'll outright tell you what they are, sometimes it's a guessing game).
The Amiga thing is funny, but NT 4.0 was still receiving security updates until the end of 2006, so seeing it in 2007 wouldn't be much different than seeing Windows 10 today.
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.
This reminds me of the apocryphal story of the IBM System/360 running a 1410 emulator that ran an IBM 705 simulator that ran a business-critical application.
Which is why we should target VMs directly. Then that VM can be brought forward to new platforms rather than emulating the entire machine, not that emulating the entire machine is bad. One could argue that the emulation stack you outline was made possible by putting in the work to make simple, fully specified and documented hardware.
Interestingly, there are a few places that will sell you a warrantied and new desktop or rackmount PC with a Windows NT 4.0 license. I imagine buyers of their systems are often in similar predicaments, not sure who else would buy these.
There are some things I don't understand about the OP's constraints (are you sure you can't run that Amiga VM on a newer version of Windows, or better yet, run that Amiga-based software on one of the currently supported Amiga VMs?). But they can probably pretty easily keep going as they're going with this software until some other, more significant thing in that plant becomes fully obsolete and the place is shut down.
lol. I know a ... factory, that had a BBC model B (with a rather complicated wiring loom) still doing a job around that time.
The IT supplier at the same factory went to a museum in Cambs. around late '90s, early '00s to ask if they could buy an exhibit because something had failed locally. The museum gave them the part.
That was just aerospace and nothing fancy like your nuke plant!
It is wild to me that you would use any GPOS for something like this instead of dedicated firmware for the task. This is evoking similar reactions to when I read articles about infrastructure being hacked remotely: Something must have taken a wrong turn with the architecture design for this to happen!
You don't need protected memory if your program is the only thing running. Plenty of microcontrollers have no protected memory and get used in safety critical applications.
We're not talking about DOS here. This is AmigaOS, a fully preemptively multitasked OS from day one. No memory protection, but unless your code is running on bare metal like demos and games, there are other tasks running.
Top parent of this thread is talking about a package for AmigaOS being run on a bespoke emulator (as the Unusable Amiga Emulator of the 90s wasn’t really a thing that could be used for that)
I'm curious, how did the hardware present itself? It couldn't have been an Amiga Zorro card since it would've been impossible to get that into a PC. Did it connect over a serial or parallel port?
Was this status indicator simple vertical bars that were black and white and displayed on an old CRT Monitor?
Almost looks like black and white terminal vertical bars (like Alsamixer)?
> A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007.
To put this in perspective, NT 4 was released in 1996, 11 years before 2007. That’s roughly the same as someone running Windows 10 today, which a lot of people still do. The Pentium 1 was only 14 years old at most. These parts of the system shouldn’t be surprising.
The AmigaOS and software from the 80s are of course the older more interesting bits, but for critical infrastructure and safety, shouldn’t we expect and design for our hardware and software to last a long time, and not try to keep up with tech fads every decade? I feel like the main problem isn’t hardware or software that’s old, but that there wasn’t a longevity plan.
It’s always been an interesting question how to write software that will last a hundred years. Maybe with AI this is the first time in history that planning to port & upgrade to new hardware every 5-10 years seems totally reasonable.
> That’s roughly the same as someone running Windows 10 today
While true the situation is different. Hardware and software moved a lot faster in the 90's and early 2000's. Everything has matured, is far more standardized, and moves more slowly now. Hardware from 11 years ago when Win10 was released isn't that different from today's hardware. Same goes for Win10 and Win11.
There might be a seed of truth there, but FWIW, I’m not very convinced by that. CPU speed development has slowed down a bit for sure, but software development is going faster than ever. GitHub and NPM and Python 3 and Rust all didn’t exist in 2007. CUDA was first released that year. LLMs weren’t being used. At the start of 2007, the latest Windows version was Windows 5, one more than Windows 4. Almost same as today. There isn’t a Windows 12 yet, while Windows 6 was released in 2007. So the pace of major Windows versions might be slightly slower. OTOH, the OS is much bigger than it used to be and it gets more frequent updates and point releases now than it did in 2007.
It wouldn’t make a huge difference to me if 6 was released either 6 months earlier or 6 months later. In 2007, NT4 was only 1 major version behind for most people; adoption takes time. The broad timing of major versions being 4-5 years apart didn’t change until Windows 11, and we don’t know if that’s an outlier yet, but we do know that Microsoft has been changing the Windows release strategy, with more frequent updates. https://endoflife.date/windows
I wonder if there is push in the public sector for open source software/hardware for cases like this.
I completely get the decisions over time here, but it's unsettling having a relevant piece of software (reports are important too!) working on with parts from ebay, in 50 years time they might be gone.
I've dreamt of governments hiring devs with promises of full time OSS work. It _might_ get some people over the lower salaries of government work. But I overheard a state CIO once say "We configure, we don't create".
That's to say nothing about opinions of open source that rival early 2000s Microsoft.
For old ass critical software and hardware, the org can always have a backlog of hardware and contingency plans (paying someone to fix the hardware, paying someone to create a fully certified and modern solution..) for when they start running out of parts.
How on earth are these massive pieces of infrastructure relying on software they don't have the code to? i'm just utterly confused how these things happen.
This is crazy. Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Safety and reliability come from understanding the system. Something that's old but that you know everything about is far safer than something new. This risk is that the people who know move on, or the sources of replacement parts stop working, or that other things around the system change. Then the risk curve inverts and you find the old system more of a liability than a asset.
Almost always people choose to update things either too early or too late. Knowing when to do something is hard.
That’s pure negligence. It’s not like the people that have the know how disappear suddenly . It’s the responsibility of the management to make sure the knowledge transferred to new generation.
I guess that kind of thinking is what led to the collapse of ancient civilisations like why even bother to improve anything and let everything decay and die out
You can only say such things with hindsight. In the moment, nobody knows what the future will hold. Take the space program in the US for instance. In 1969 we landed a man on the Moon. We'd repeat that several times until 1972. At that point Nixon made a speech which implied various unpleasant things about space's future, but he'd be out of office, disgraced, a couple of years later, so how big a deal could it have been anyhow?
I think almost nobody from that era would have believed you if you told them that more than 50 years later not a single human would have traveled beyond low Earth orbit, and that we'd now be struggling to recreate what we did in 1969. Furthermore a significant chunk of the world doesn't even believe we landed on the Moon anymore, no doubt in part because of this apparent anachronism.
It's not like there was any sort of collective or even singular decision to just let things die out. I mean sure Nixon did his thing intentionally, but even as a President in the golden years of the US, he was still just one man.
> I think almost nobody from that era would have believed you if you told them that more than 50 years later not a single human would have traveled beyond low Earth orbit
Four people went around the moon earlier this year (leaving earth's orbit for the first time since '72)
Basically everything collapses as far as it is allowed to, and the collapse is slowed only by:
- profit, if a system generates it, people will keep the system running.
- dilligence, usually driven by personal idealism, and unrewarded.
- legal or financial penalties, or insurance costs.
- it has collapsed to a temporarily stable state for now.
For another comment I was looking at the Grenfell Tower fire in the UK around 2017 and the people who lived there had been raising fire risks for years and the landlord (management organization) and the council had been ignoring them, and ignoring the fire department. The companies which replaced the cladding on the tower with flammable cladding were choosing the cheaper flammable option and pointing fingers as well. And during the fire, the fire service had never dealt with such a big fire and didn't have a truck with a long ladder, didn't have extended-breathing gear, had radio problems, water pressure problems from the local water company (who deny that).
This kind of backstory is typical for disasters, and for IT outages - and I've taken to believing that if something "should work" but wasn't tested recently then you should expect that it doesn't work. This is a common saying in backups (you need to test restoring), but it seems to apply everywhere. Backup internet connections that don't have enough bandwidth for the company to keep running. Disaster recovery sites that share resources with the production site. 'Disaster recovery' that recovered into a remote site, but they couldn't do CAD work remotely over their slow connection so it was still disastrous. Multiple power feeds but they were cross-wired so one failing still functionall took down everything.
If knowledge transfer "should be happening" but it's not critical to a job, or it's not profitable, or it's not legally required and audited, then it isn't happening. Subject to the dilligent idealist employee mentioned above who are temporary in the long view. Management's involvement seems not to arrange the larger system to effectively shoulder responsibility, but rather find ways to avoid personal blame while cutting costs beyond the point where everything that needs to happen keeps happening.
It’s the responsibility of the management to make sure the knowledge transferred to new generation.
That's just lazy thinking, and probably a sign you've never been a manager. For all the responsibility to lie with management you'd have to be leading people who enthusiastically do what they're asked to do, raise problems, document things, follow processes, and make sure everything is handed over to the next person when they leave.
That's not how people are. They'll have times when they're unmotivated, underpaid, grumpy, over-worked so they miss things, etc. That's when the organisational tech debt starts piling up, and there's nothing a manager can do to stop it except manage it as best they can even though they're under the same pressure, with the same lack of motivation and crap pay as everyone else.
It's so easy to think you can fix it just by keeping on top of it and micromanaging where it starts to show up. It doesn't work that way.
The Management of a company is a group of managers. There's no real difference between the group and the collective.
The fact that you're willing to absolve an individual manager but still believe Management can fix the problems is a big part of the problem. The Management usually includes the last person in the chain who has the ultimate decision making power. If you assume that when I said 'a manager' I meant that person, it should be fairly obvious that even they don't have unlimited budget or unlimited time, and they can only try to fix problems they hear about. Within those constraints Management are still going to find fixing systemic problems hard.
It's very easy to look at something with hindsight and think the outcome should have been predicted and corrected. If you look at the real world you'll see that just isn't the case. Personally, I wish we had a lot more people applying some systems thinking approaches to at least consider the second- and third-order impacts of their decisions but I imagine that won't ever happen. It makes me sad because it's actually really interesting.
For non-perishable things - i.e technologies, ideas, books, institutions - the expected remaining lifespan is roughly proportional to how long they have already survived
Time acts as a filter: what has already withstood a long stretch of disorder is more robust, so the longer it lasts, the longer it is expected to last.
The old nuclear software running on mainframes have passed the test of time. The new software, has yet to.
Nassim Taleb talks about this at length in his book, Antifragile.
Their 100 y/o hardware is built from stuff that's still produced though. We still make relays (not identical ones but ones that perform the same function), wires, and mechanical levers. The system's behavior is not encoded in the relays but in the connections between them. If you had a CPU made of separate transistors you could replace burned out transistors with any future transistors but if you had one made of chips you'd need those exact chips that were out of production.
Replacing the relays in old telephone switches is a problem because they use so many weirdly specific types of relays - but those systems are only found in museums now. I believe track control uses fairly ordinary DPDT, etc., relay designs.
But similar reasoning is why Canadian trams are worse than other countries, and it's not "good experienced engineering". In this nearly hour long rant by NotJustBikes[1] the section I've linked is about the technology and how the transit authority will not move on from 100 year old track technology which makes everything worse for customers. There are junctions where tram drivers have to stop and look at the track to make sure the junction is correctly set because the single-point switching is less reliable than modern designs. Or the driver has to stop the tram and get out to use a stick to move the track and change the junction because they aren't electrified. And then pass through junctions as slowly as 10km/h because the old track design has higher risk of derailment than modern designs.
The designs for the electrified track switches were made by one company which was sold, re-sold, and then burned down and the designs lost, and there isn't anywhere else to buy them because nowhere else uses such old track design anymore, so not only is Toronto struggling to buy parts to continue electrifying the manual junctions, it's struggling to custom-make enough replacement parts to keep the aging electric switches working faster than they fail.
And they were using trolley poles to connect to the overhead power lines instead of Pantographs until 2017, 50-100 years after everywhere else, which meant a) they couldn't get enough power through them to run air conditioning, and b) they are more likely to fall off the power line and the tram stops and the driver has to get out and reconnect them, and c) their newer trams now have to have custom dual-power connections to go through older parts of the network, and d) the carbon shoes on the trolley poles wear out quicker which means the trams are dirtier and taken out of service for maintenance more often in the wet which is when people want to use trams more.
OK, but the context here is IT in mission critical infrastructure, like energy or banking. These industries will not jump on the latest technology and will drag their feet for as long as possible, and for good reasons.
Also, I happen to be familiar with NotJustBikes, watch regularly. I don't see this as the same kind of problem. What you explained is clearly BROKE. What we're talking about works just fine and migration to newer technology doesn't provide advantages outside easier maintenance. It can't be justifies by costs, either.
A friend discovered that one of the more modern pieces of equipment instrumenting those old signals was an ancient WYSE terminal from the late 90s that had been bricked over during a station project.
They moved a booth or something and the compartment it was stuffed in was missed during the cleanout. The thing was working for at least 20 years and may still be there!
I worked with a client that had a cash disbursement system working on an ancient dBase 16-bit application. They had a very difficult to change process that required multiple transactions because the system couldn't represent the dollar amounts appropriately.
I understand that way of thinking for a small business computer system. Not for a critical infrastructure. Also if people actually thought about like that we would still be in stone age, like why invent something new or use a new technology? Keep on using rocks to crack nuts and kill animals
I think you can imagine the difference between “I did some work and made this thing that is clearly better, but we might have a few kinks to work out” and “I did some work, and if I did it perfectly, it’s just as good as the old thing, but we might have a few kinks to work out.”
I agree with you. First, "broken" is not a binary, it might not be broken but it might not work well either. Second, sooner or later everything breaks, and you better be ready for when that happens.
> Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Same reason they don't modernize health care infrastructure. It's too expensive, people die if they get it wrong and they get voted out of office for their troubles.
Because what they have works well enough to be NRC-certified, and they have enough spare parts to comfortably outlast the rated lifetime of the reactor.
Now you know why "nuclear power may have been dangerous in the past, but with modern technology it's completely safe and Chernobyl will never happen again" is not a good argument.
Chernobyl didn’t happen because of technological blunder or even human negligence. It happened because poverty caused by communism in Soviet Union had to use old outdated (not the modern nuclear technology at that time) graphite tips in carbon rods because it was cheap and also kept it as a secret from the facility operators giving them a false sense of trust on the kill switch.
Chernobyl is the perfect example to not use outdated old technology. Had they used the modern western technology at that time to upgrade their nuclear reactors the kill switch would have prevented the whole disaster instead of increasing the neutrons make the core a nuclear bomb.
Next time educate yourself with facts before making a fool out of yourself
Wikipedia's pages on Chernobyl say that construction started in 1972 and the problem with the control rods causing an initial spike of power was discovered in 1983 ?
Chernobyl was very much not "old", it was a more modern design than the PWRs which are built today. Chernobyl Unit 4 was also basically brand new, only 3 years old at the time of the disaster. The RBMK design dates from the 60s, whereas the PWR is from the 40s.
Frankly, if not for the issue of components aging I would trust 1970s PDP-11 or even a PC-XT running MS-DOS a lot more than a modern system. This vintage's hardware was extremely mature and simple to understand and operate. No Ghz buses, no multiple levels of caching, no speculative execution and long pipelines.
DOS was a single task operating system. Once you proved such a system could run for days, months and years, there's no reason for it not to function 50 years later other than component failure.
That must have been a crazy moment for you when you first saw it and a big sigh moment for whomever had to explain it to you the first time. Thanks for sharing this; it made me smile!
[Source: Was NT developer - have code in NT 4.0...]
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".
dBase, MS-DOS 3.x, not using industrial anything. And as its a front of house tally machine, there's literally zero incentive to ever upgrade it. Downtime is measured in the yearly reboot, but there are non-operational business hours, so everything is just scheduled around that.
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.
I wouldn't call them business-critical computers, but I do have about 3-4 computers under one of my workbenches dedicated to certain work I did for a client. One of them has an EPROM programmer set-up, which includes a custom ISA-card, and a ribbon cable to an external box with a ZIF-socket. The software for that requires MS-DOS. To network that box, which is a 486SX, I run WFWG 3.11. Since these never go on the enternet or anything outside 'the lab', I don't worry about the old MS networking.
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.
Not MSDOS, but I feel obliged to shared the story of an auto shop in Poland using a Commodore 64 to run the calibration and wheel balancing some years back. It was viral news at the time but worth sharing again.
Not DOS, but I sold a '99 HP computer running win98 last month, to replace an identical failed system. It was used to control a 50 meters long custom industrial paint booth line for special equipments (like 57" rims). Luckily, their HDD was OK. Urged them to make a few sector-to-sector copies of it on a few spare HDD. This $100 sell surely has prevented this business from massive bills or even going bankrupt in the meantime from production loss.
Insane to me that someone would use a windows machine to run a piece of equipment when PLCs exist and are supported for decades by companies like Rockwell, Siemens, Allen Bradley
There are lot of windows based solutions since more than 20 years ago for two main reasons : recipe management system, and logging. A basic SCADA of sort. PLCs systems of that era could either not manage it (TSX, S5,S7-100/200), or it would be additionnal very expensive, complex and typically OPC-based solutions (I'm shivering).
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, ...
Oh, and I forgot another great issue that made a lot of companies developping their own PC/windows-based solutions : PANELS.
The panel solutions provided by the main players were quite horrific : proprietary, slow, buggy, limited, very expensive, bad at commissioning (speed, firmware/software compatibility issues).
Siemens Simatic HMI from the '2000 decade was especially lagging and a few generation behind those from, for example, Allen-Bradley with the PanelView +/CE range, based on... Windows CE.
Lots of NCR's ATMs switched from OS/2 to Windows 2000 workstation at the beginning of the 2000's in western europe. Probably the same anywhere else.
Had a lot of fun with token ring networks with the strange square connector plugs.
I had it listed at this price for a few months, simeone from their company purchased it and rode 2 hours and half to come get it. Couldn't and had no reason to up the price at this stage. Indeed, this was a very good deal for them.
I had a functional STA Compact [1] coagulation analyzer until 2022. It ran a customized DOS version on a ITX computer board that was integrated into the analyzer. UI was in text mode and used the keyboard only. It had no mouse. The video in the link shows the UI for a few seconds at the end. We kept it functional as a backup and even used it a few days when the replacement broke down. It was one of the best analyzers I ever used.
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.
Not any longer. Back in the mid-2000s the company I worked for sold point-of-sale systems based upon a multi-user 4GL application (TAS Pro). Similar to dBase/Clipper etc., using the Novell Btrieve ISAM database engine.
With 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.
Not DOS but another dad in my town works for one of the opera houses in NYC.
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."
I worked in a state gov't agency as a temp, twice, in the same department. Several of us had shared access to a PC that let us log-into a special terminal program and read records on some mainframe someplace. That PC had a 233-MHz cpu, I'll assume single-core. At that time, it ran Windows NT 4.0, and it had been patched to use a USB mouse. But we didn't rate an optical mouse, so someone would come in twice a day with a tote of cleaning supplies and clean the mouse ball.
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.
Let me assure you that Deutsche Bahn also still operates about 500 mechanical signal boxes, about 100 are from pre-WW1. Not these fancy, modern electromechanical relays (which Deutsche Bahn of course also has).
That's far superior than running an outdated general computing platform. Electromechanical devices are simple, easy to understand, and replaceable. It may be harder to diagnose problems but with maintenance it will work forever.
+1 from me for relais technique. It is easy to replace, even in 1000 years. Today PLCs are great and fun. We can do a lot of cool things with them. Just with the short and shorter life cycles, sometimes even less than 10 years. If something breaks you have to replace so much stuff for a small broken piece. Thats such a bummer in todays industrie automation.
I had to keep an old clipper/dbase application running until recently. It worked perfectly seamless with vdos (vdos.info). It's commercial software, but very reasonably priced. Dosbox is another alternative, but didn't work as well with printing and I think also wasn't able to do row locking of dBASE databases over the network.
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.
Not DOS but we recently had to virtualise a Windows XP box as it was running crucial software for a visitor attraction. The software was written by a member of staff who sadly passed away and the PC it was running on was approximately 20 years old.
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.
A company I used to work at still ships a piece of hardware with an Intel 186 microcontroller in it. The compilers are 16-bit DOS applications and the tool to program the DIP packages with the program was also a DOS application. I’m not sure what the physical interface between the programmer and computer was.
I run 2 old Juki pick and place machines. They run DOS 6.22 on a 486 I think. My biggest pain points are, 1) booting them up without errors, and 2) transferring files to them wirelessly without any floppies. (without installing any DOS software)
Closest I got was with a GOTEK and an ESP32 emulating a USB. But it was flaky so I dropped it for now.
I work at a multi billion dollar facility for a Fortune 100 company and we still depend on DOS. Keeping the mandatory DOS machines going is an exercise. Especially integrating them into modern systems.
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.
The serial port stuff is very close to what I'm working on - what's on the other end of the connection? What does "integrating them into modern systems" look like for you: getting data out/pushing data in/both?
We typically integrate them by encapsulation. Building multiple layers of more modern systems for them to communicate through. A combination of Windows and Linux boxes. The other end of the connection is very old industrial equipment. This is not to run the equipment per se but to configure and program it.
This thread reminds me that there is a huge benefit to using a super common OS+hardware.
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.
2014-2017 I was supporting a clipper setup for issuing work order and many other tasks for an old civil aviation repair plant. I’ve ended up virtualising and moving it to a hyperv cluster. Definitely the case of “if it works, don’t touch it”.
Also set up a closed network for CNC machines to let engineers in the shop send jobs over the net instead of running around with floppies or manually entering gcode through the console.
Fun times.
The last company I worked for still had customers they were dragging forward to get upgrades from coax connexted green screen terminals to modern network thin clients. It wasnt on DOS, but very old unix OS, tape drives for backups, parallel for printers, serial for scanners. No USB. Lovely troubleshooting when you were dealing with 30+ year old hardware setups. There was only one company that would even servicenthe green screens if they failed, and you couldn't buy them anymore.
Siemens Field PG. It is a rugged Notebook for PLC programmers. At least in the last version until last year, the "Field PG M6" was possible to buy the Notebook with a special serial port for old S5 PLCs ant the Step5 software came in a special DosBox version with it.
The Field PG has also another special port called "MPI/Profibus" for S7 PLCs, 2 Ethernet ports and a DVD drive.
The Gear cutting job shop I worked for had a CNC lathe running with a GE Computer from the late 1970s that stored data on punched Mylar tape, until it was bought out in 2019.
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.
Just out of curiosity: is it possible to somehow attach an ISA Adapter via USB to a VM? ISA does depend a lot on DMA and timing, but the clock is only 8 mhz and gives a software layer on a modern cpu a lot of time to do stuff between ISA bus cycles.
Keeping old hardware running is very fragile. Most spare parts are decades old now too, and nobody knows if they still work properly.
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.
The problem is that a lot of those old ISA drivers were peeking and poking card registers as fast as the bus would allow, which was over 1 MHz (less than 1 microsecond per transaction), not DMAing data to RAM (though some did that too).
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.
Often people confuse latency vs throughput/bandwidth. With streaming and batching USB4 will shuffle a lot data through on average per second. But it will never hit reliable microsecond level or even submicrosecond latencies.
At the same time ISA card will never reach 40Gbps throughout with CPU clocking at tens of MHz only or often less.
I've an AMD K5 processor machine running at 100 mhz. for testing Transputer ISA cards when someone buys one, I also use the same machine to format and copy my Pascal compiler into a pair of 5 1/4" floppy disks. All using DOS.
Is it a physical machine and not a VM? I already had issues with getting XP compatible spare parts years ago. Had to buy used parts that were already pretty old (so high risk of failing again).
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!"
It's not totally for business, but I run some antennae and radio telescopes that feed through a Gateway 386/33/16MB RAM. As well as a Getac, no idea what model, but it's from the early 2000s. They both feed through to a A/B switched Paradise CRT (so cute). dBase is on the list.
My dad ran a commercial 2-way radio business. There were multiple radios with programming software that would not work on anything above a 386 and DOS. He had a couple computers from the late-80s running for nearly 25 years, though I think he had to replace one of them with another of similar vintage. Also, had a 486 that he used for customer notes in WordPerfect up to about 2015.
I suspect he could have found a way to use a newer computer, but if it ain’t broke…
Intel was seling 386 CPU up until 2007. I personally was using brand new special equipment with 386 soldered to custom MBs with no VGA, serial only access.
I suppose you can purchase such boards from ebay/recyclers today.
Book 386 is a ready notebook. It mainly targets gaming, so it has speaker, OPL3 sound and MIDI/GamePart port. But also ISA as yet another "port" on its outer side.
Now that I think of it, some of the software was for Motorola radios. He was not a licensed Motorola shop (Kenwood), so I believe getting more modern software would have been difficult or very expensive, if even possible.
I know a shop that still runs an Apple ][: they have a Numerical Control machine. For those who don't know, NC is the predecessor to Computer Numerical Control, i.e. CNC machines.
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 ][.
Does the idea make use of https://86box.net? Just heard of this recently on hn and it seems promising for anything that requires low level/cycle accurate emulation vs. your typical high level emulator.
My idea is a DOS emulator with a really thorough log of every DOS interrupt called and I/O port interacted with. This could then be used to automatically, say, insert rows into a sqlite table when the DOS app updates a .DBF file, or forward GPIB data to a modern USB adapter. I wanted to avoid low level/cycle-accurate emulation as much as possible, only adding quirks as needed to support the most popular business application suites.
It should work with Siemens MPI/PPI interfaces, but I predict issues with ex-Telemecanique (now Schneider Electric) unitelway realtime DOS driver which is extremely picky.
i know still some accountant who use a DOS program to do his work because he hates the fact modern UI has load times. slows him down too much o.O
(his program is all keybinds).
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.
Don't underestimate the work speed a person can maintain with a reliable, fast keyboard interface. Finding the right spot on a web interface and navigating with a mou---too late, the keyboard user already entered the invoice for that account using some odd VAT rate on 3 of the 5 products.
It's been a few years now, but I know a major manufacturer had some windows XP boxes around because they were the newest hardware/software they could get with native parallel port support to interface with their machines.
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.
For anyone that needs true native serial & parallel ports, a Dell Latitude E series laptop (or Precision 7xx0) with docking station is an easily-available option.
The last machines with dock port have 6th gen Core CPUs (Latitude E5x70), or 7th gen for Precision 7x20.
I don't really know the full details, as it was my brother who worked there and we just chatted over beers, but I believe the software itself that communicated over the parallel ports was 16 bit, and that (along with the native ports) was the reason they kept the old windows XP machines around.
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).
AND more to the question - the contractor who remodeled my house in 2014 was still using some ancient DOS app, possibly running on a DOS machine or at least an emulator of one, to generate billing. Which was handed to me on paper....
(He was a good contractor, so clearly having the latest billing software is not the deciding factor in that.)
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.
An old story. I used to work for Fox Home Entertainment (CDs etc)this is 20+ years ago. And we had proper DOS running on old machines. We used it to do all our finances (including all of Japan, Asia sales). Most of the money we made on movies like Titanic were tracked on DOS. Until about 2003 if memory serves me where we moved to SAP. Why this was worrisome was how easily fraud occurred. In my tenure there $5-10M was stolen. At the time sent to companies in Brazil. I'm still surprised by larger firms where they keep these things alive to retain the data. CocaCola did it. A few large Insurance firms too. Crazy.
We have a client (a factory) I wrote a massive (for one person without AI) Clipper system for that runs the factory; this is decades ago but it just works and when they tried to replace it (not by us, but promises by others), it was worse and they did not switch. Cheating, but another client is a bank; they found its is really inefficient to not use DOS. Their machines use Windows but fullscreen DOS box you cannot close or minimize with the app in it.
I had to keep a disturbingly old machine with GPIB running until a few years back. They are still in operation in Australia (who we sold them to).
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.
You're trying to create and sell a version of dos box? These companies have not replaced their computers because to the user there is no separation between the computer and the machine it controls. So the computer will be updated along with the equipment, which is not connected to the internet or a network anyways so it's not a cybersecurity risk. For the user, if it runs fine, there's no need to update just the computer, and the computer is updated along with the machine
Not exactly, freely available solutions are already good enough for people who just want to run their apps on modern hardware, and have been for a long time. What I was thinking about writing is a tool that eases migration by using interrupt and I/O hooks to detect common patterns and, say, builds a modern SQLite database as the business uses their dBase program. Whether anyone actually needs this, I don't know.
There's a few car dealerships that still use databases from the 80s. As for why they haven't migrated, I'd guess must be reasons I'd assume at this point it's a choice they have made
As someone who works with car dealerships, easy: no one has been able to convince the owner that replacing these systems would help them sell more cars.
If it's a new car dealership, though, they're surely using (relatively) modern systems as well, as there's no way they're using an old DOS system to communicate with manufacturers to order cars, file warranty claims, submit financial reports, obtain service information, …
I know of a DOS machine at a wool testing place that uses an ISA card based imager for measuring the micron and other things. They also have a supporting DOS machine with a dBase looking database on it. When I spoke to the owner he didn’t really understand the risks involved in running ancient hardware and in fact had a storage room with period PCs in it if the machines failed. He didn’t have much of a backup plan for the imaging hardware though.
My opinion is that if these guys are still running this gear, they already have a strategy in place (no matter how flawed) and would likely retire before throwing money at something they consider a non problem.
Good luck with the idea. It likely is a tiny niche market with customisation for every customer and given they are normally hardware constrained AI may not be much of a help.
My idea is basically a DOS runtime with hooks on interrupts and I/O that would allow for either migrating databases to modern formats, or converting I/O accesses for modern USB peripherals. Customization for every customer and AI not being much of a help are pluses for me... lack of money not so much.
I have been porting sections of the business software I mentioned earlier from QuickBASIC on DOS (nice to have the source code!) to Tcl on Linux using ChatGPT to automate the conversion. It gets it right the first try, almost every time.
The BASIC code is very simple by modern standards, and Tcl overlaps BASIC neatly, making conversion easy.
Unfortunately it's just a short-term stopgap to add some features management suddenly can't live without, that weren't practical to implement in BASIC/DOS. They'll replace the whole stack with a commercial product and support contract when they find something they like.
For anything business-critical, I'd tend to want to rely as much original code as possible, running actual MS-DOS on emulated hardware that could be tailored to suit your I/O needs.
Lots of forkable code exists to get started with this, QEMU, 86Box, DOSBox, PCjs, MAME, …
And if you do want to go the route of implementing DOS and BIOS interrupts yourself, DOSBox does this.
One of our vendors is a contract electronic manufacturer (circuit board stuffer) that has a wave soldering machine running MS-DOS on a PC that's built into the control cabinet. It uses the parallel port to communicate with Opto22 industrial i/o modules, which then is wired to all the temp sensors, relays, etc. It just keeps working.
I used to be doing that, but this was a bit over a decade ago at this point. There was an SBC with DOS on a chip that connected to Novell Netware. I set a few variables in autoexec.bat, let it connect to the network drive, then had it run a script from there to admin them / do backups (by which I mean xcopy the C: drive).
These were for some industrial CNC machines with a poorly version-controlled app (send us the single-file .c for the program, we'll make changes & recompile for you, then send back a new .c and .exe file) that would just malloc() all the memory on the machine for a million element array instead of tracking the 1k or so unit IDs a more efficient way. They were six digits long, it worked... mostly.
I kept a 3.5 floppy with the contents of sys a: that I used to run sys c: after restoring a machine from backup in my office.
EDIT: oh, and of course by "restoring from backup" I mean reversing the xcopy to copy everything from the network drive's copy back to C:
EDIT2: My memory is going, they didn't use malloc() at all, anywhere in the programs, they just had a static million element array.
We did at my previous job, obviously airgapped because the equipment (pharmaceutical mixer, worth in the high 8 digits) was still working just fine and was easy to service despite the vendor not being in the business anymore.
A Customer of mine has an 386 machine with an ISA interface board connected to an optical comparator instrument. I believe they also still have some MS-DOS-based computers connected to CNC machines, too.
I have two Customers who use DOS applications under DOSBox (a Clipper-based accounting package at one, and a Symantec Q&A-based application at another).
I remember reading that Disney was running XP on Toy Story Mania at Disneyland for the ride itself. When you stand in line near the loading point you can see the computer screen where the operator monitors everything. Not critical or DOS but comical it's doing a basic control of the ride.
We were talking about Visual FoxPro only a few days ago. [1] And one of those same companies in my comment [2] uses an old ordering system that is still in DOS and they boot up a VM to use it. They still have a printing machine ( not a normal printer ) for those order printing connected via a Parallel Port. I don't know the details of how that works though.
And by the end of all that, the order will be Faxed. Manually.
Did they tried to email it or automate it. Hell yes. Did it work? No.
One interesting thing of living in the AI era is that every single one of these old apps (that people still use and never paid big money to upgrade because it it ain't broke don't fix it) can now be rebuilt for $5 in ten minutes if you really know what to do (YMMV)
If you don't know, you'd have to pay an expert big money to do that and the migration abandoned just like before, so another decade will go buy until AI does that without permission just because it found a possibility for optimization and it is instructed to do so without human approval, because governments
Just as long as you still have all the documentation and the spec was done right and updated as things changed over the whole lifetime of the system up to now. And a good test harness. And industry-specific knowledge.
You would think so, but most of the low hanging fruit has already been rewritten and replaced. The biggest hurdle is hardware lock in, ISA boards, hardware keys, or other hardware interfaces that can’t be easily connected to new systems. Never mind the problem of verification. That app that takes days to rewrite can annoyingly take months to verify.
Perhaps look into environmental services labs that do contract EPA work. I would not be surprised to see entire HP-Agilent(ISA-carded) - (think liquid chromotography analyzers) fleets that would match what you're looking for.
Until recently several customers have an industrial machine that boots DOS. I think the oldest effort we deal with is Win XP now. I do have a C>64 at home ...
In a world that requires security audits etc here's some notes that might help:
Scenarios:
You have a device that only talks NetBIOS or even NetBEUI for file sharing. You need to get files to and from it and your CAD workstations run Windows 11 and anything less than SMB 3, with signing and sealing and all that jazz is laughable.
... Devices requiring ftp, telnet, serial over carrier pidgeon
Solution options:
Networking:
The first job is to segregate your industrial gear from your general network and you might want to create two or more industrial gear and internet of things type networks with differing access policies. Start with one for now, you can improve it later.
You use 801.1Q VLANS logically or physically (why the hell did I want to write literally?) separate via separate switches.
Please do not skimp on this step. Buy a network bod to sort it out or put your IT bod on a course or hopefully they will have labbed this up at home already!
Comms:
Samba is bloody wonderful and speaks everything that MS has ever done and deprecated. Even Samba does need to be asked to start speaking some of those dialects again but it will.
Put a Linux (other Unices are available) box on the same VLAN as your machines. You will need to set quite a few options relating to the minimum version for its server version. When talking to the machines, Samba is the server and when talking to your file server, Samba is the client.
Create a data share on a Windows box on the corp LAN. For example it might be on a file server for multiple access or just a single CAD PC.
Get the Samba box to mount that share to itself at say /srv/data_share_mc1
Now get the Samba box to create a share from /srv/data_share_mc1 which it calls DAT_MC1 (8.3 chars for NetBIOS)
With luck, you should be able to map DAT_MC1 on your machine.
I don't thing Samba supports NetBEUI, though you could run old Windows in a VM or emulator on the Linux box and just add another SMB reshare "hop", and of course only expose the old Windows VM to the "old" network.
Half of our system is running on 2002 versions software. To my desperation, my calls for updating has been persistently denied. There're no technical reasons to keep it as is, it's more about wetware issues.
We still use dBase files in some point as transient format, not using dBase as such though. Oh, and plenty of positional text files, but that's more a question of interop with partners.
Story time: I got handed a ticket to go change a UPS in a “server room”.
I was in Fairbanks visiting family, I had some downtime, so I decided to do some “slumming” to break up the monotony and relive some of the good old days before I was more boardroom than server room.
Besides, a cool grand for what I figured was 2 hours work appealed to me on some “miss the struggles” level, and it was better than walking around the tourist traps or doing video calls at some depressingly fecund coffee shop.
So, I drive up in my borrowed SUV with peeling paint, grab my trusty tool bag I leave with family for adventures like this, and walk boldly through the doors of this apparently normal retail establishment, clipboard in hand. It was 2019, and the smell of denim and factory pressed shirts wafted through my sensorium as I walked through the awkwardly desynchronized automatic doors.
It was a perfectly normal, somewhat 90s nostalgic retail store.., but walking up the stairs (the elevator was out of service) to the second floor, I could just sense that something was a little off.
The office had a smell. I can’t say what it was, it was businesslike, and not unpleasant, but it spoke to me in an unknown language and I was at that moment curiously heartened that my contract was being paid by a 3rd party. It smelled of stagnant ideas, missed opportunities, and a fossilized board of directors.
I’m not just being colorful here in prose. All of these thoughts were projected into my forebrain by some lizard sense I had developed in 40 years of skulking the halls of enterprises large and small. I was involuntarily imagining a half used tin of bengay on the boardroom table, right by the shiny beige speakerphone with the long stroke buttons and the filthy woven grill.
Curious by now about the flood of intuitions, I treaded the slightly dingy burnt orange carpet tiles up to the POC office, checked in, and was shown the door tot the server room. Through there she said, gesturing at a plain flat golden pine door with the elbow thingy at the top. “Through there, straight through, the door at the back. You can’t miss it. I think it’s unlocked.”
Unconcerned with the casual lack of escort (pretty common really), I opened the door and was immediately transported to surreal alternative world. It was dark, there were tens of flickering screens across to the right and one half hanging, flashing fluorescent fixture dangling precariously from the uni-strut above. The suspended ceiling tiles were about 50 percent in attendance.
Fragments littered the floor, and the door closed behind me with a loud thump. for just a moment I was touched by a singular thought….. (run). I shook it off, by now, far too curious to turn back, come what may.
Briefly thinking of my heavy tool bag as a potential weapon, then realizing the ridiculousness of the notion, I let my eyes adjust as I took in the scene with what I confess could only be described as some kind of unhealthy delight.
This was a large room, easily 800 square feet, and a was clearly dedicated to loss prevention surveillance. There was an epic workstation with 2 giant flat screen monitors front and center, and ten smaller monitors on either side. Most of them were dark, and most of the others were flickering with static.a singular monitor had a poor but recognizable image of a small nondescript room with a small desk and two metal chairs, one on each side of the desk in an overtly adversarial position. The image smelled of stale sweat and musty cardboard.
There was seating for two pilots at the helm of this derelict craft, replete with an impressive array of buttons, strange industrial joysticks, and an oddly out of place black dell workstation keyboard with the cord ripped in half. As I made my way up to admire the helm, I nearly tripped on an extension cord, only catching myself on a water filled trashcan with plastic sheeting aspiring to the heavens up through the dark abyss of the half-intact ceiling, which I only now noticed was comprised entirely (if sparsely) of black painted tiles.
Somehow this jolted me out of my entranced state, and I looked for the door I was supposed to find, quickly locating it towards the back of the room, just as I had been told.
Somehow it seemed like not an ordinary door now. It was with great anticipation and not a little trepidation that I examined the door. It was quite ordinary, really, and the knob was less dusty than it might have been. This was encouraging.
I tried the door, and it opened easily. Opened, that is, to a time 30 years in the past.
The buzzing fluorescent lamps were on and radiating furiously, instantly shattering the wreckage of the surveillance spaceship to smithereens. There was a gigantic, wheeled, beige machine in the middle of the room, about the size of an industrial floor scrubber. It hummed patiently, and featured a dim 10 inch green CRT, a beautifully sculpted beige keyboard, and a little less than a quarter inch of dust. I froze like a tourist gaping at a stegosaur’s nose, but quickly recovered my composure as I remembered I was here on purpose. Conveniently, someone had swept a path through the center of the room, back to the newly installed floor rack with a couple of ciscos, a backup cellular telemetry box, and a pile of screws and a throwaway screwdriver scattered haphazardly on top of one of the routers.
The UPS I was to replace was actually pretty complex to configure, but I very carefully completed it in about 45 minutes including some firmware regressions to accommodate some nonstandard plugin the vendor installed. By very carefully I mean without stepping too hard on the floor, dropping any tools, and afraid to sneeze even though I was under intense respiratory assault from the unavoidable clouds of fine carpet dander that had accumulated on the linoleum tile over years of janitorial malfeasance.
I was terrified to make any sudden moves, because sitting on a stackable plastic chair next to the pliestocene PBX was a beige box. Its fans groaned with the wails of a thousand parched capacitors, and its hard drive made a crunchy rattling sound that seemed entirely improbable for a functioning device. Just visible under the dust on the front was a badge proudly displaying “pentium pro” and a giant cable was fed from the back of the artifact, like an implant from the borg, something I strangely remember as “IBM type 1” token ring wire, though I can’t be sure anymore that means anything at all.
At any rate, it was obvious that the entire on-prem server infrastructure was this ancient and faltering nightmare box, and I knew that a fly landing on it could bring it down. The easy money contract was starting to look like a setup.
With terror in my heart, I finished my work, carefully closed the door, and put as much distance between me and that roiling cauldron of liability as I could. I don’t even remember going back through the wrecked starship, just checking out, and thanking Voltaire that I made it out of there in time.
It now made abundant sense that the job had been left on the board for nearly a month and the contract had kept rising… god only knows how many sensible technicians had noped out of there before I was hypnotized into compliance by the sheer bizarre fascination of the thing.
Poking around afterward, I found that the box apparently was the server that ran the terminals in the tire service area. They also had that fat cable that looked more like waveguide than wire, and it must have been an absolute nightmare to install. It was definitely token ring, humming along in 2019.
I don’t know the specifics of their systems but both of my local lumberyards here in SoCal still use DOS systems for their point of sale and inventory management, with slow dotmatrix printers and everything.
They simply have no reason to modernize. The one big benefit they’d have is an online inventory system but they make most of their money from negotiated bulk orders so there’s zero incentive.
Most of the newer to us (1990s+) radio test gear has embedded versions of Windows running the controller. It's much easier than writing custom firmware that hands all the file system I/O for dealing storage, building a GUI, etc.
If "a few years ago" counts, a relative of mine abroad used an MS-DOS application attached to an Epson dot-matrix printer that supported a PITA foreign script to print invoices. It wasn't too painful, since the system supported batch jobs fed by a format that Excel could export.
Not current and not DOS... but years ago, around 2011, I helped set up a series of QEMU emulators running DEC Ultrix and MIPS Unix software that called out and retrieved data from weather stations only reachable by modem. The software had been written years prior in C and nobody had the source.
The box running the QEMU emulators had a bunch of old US Robotics modems hanging off it via USB serial dongles.
This is probably a wrong audience. Most people here are very technical - the kind that would not put up with tiptoeing around a sacred computer from decades ago running some magic software from the DOS era. This crowd will aggressively move it to modernized architecture or at least emulate it using a more modern platform.
The company I worked at in the late nineties, used Managing Your Money (MYM) for bookkeeping - initially on a dedicated DOS machine. My colleague set up a DOSEMU-based emulator and moved the software to it (bye-bye, dedicated DOS machine!). Later, he re-wrote it in STk (Scheme w/ Tk bindings, running natively in Linux) as ageneral-purpose transaction storage. ¯\_(ツ)_/¯
Yeah. Sometimes old hardware forces its hand and causes a big PITA.
I had a job working on VAX/VMS around 2009, but it was actually an emulator running on a PC because they just couldn't find any hardware to fix the VAX. At some point before I joined they had to get a ton of government approvals to use the emulator.
Fortunately they had a project to modernize the whole stack. And it was going to Solaris :-/
What's the reason for not using a more modern MIS?
(I can certainly understand why organisations with niche requirements might hang on to old systems for as long as they continue to work, but I'd have thought that school payroll and attendance were much too commonplace to fall into that category)
I know of some laboratories where they have a host of old machines for software to support some critical instruments that only runs off a dongle or an ISA card and it still does accurate work.
Not recently but when I was a teenager (2001-ish) my supermarket was using a DOS computer to handle stock, print new labels when prices updated each day, etc.
A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007. The reason is interesting.
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.
To me the funny part of this story is that they used to show you this warning as part of the EULA when installing Windows NT 4, which I remember joking about:
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
> 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.
LOL at “Chernobyl accident was caused by bad control rods”. This seems to imply other control mechanisms worked, when in fact plant engineers could not even monitor the plant operations. They had malfunctioning Geiger counters. Also - plant engineers had no idea how much water was flowing through the nuclear core cooler. Monitors for the temperature of before mentioned water did not exist even on a whiteboard.
A friend works for an airline as a flight simulator tech. Their entire software stack, including the compiler and OS, is FAA-certified.
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.
There's a mechanical tank simulator at the Swiss Military Museum that was built in the 1970s and used for actual service before being retired and becoming a museum piece:
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...
It's _very_ hard to believe some company to simply "clone the mainframe" into chip. Mind sharing any link to this effort?
Custom chips aren't as expensive as you think. About a few million dollars for the design and a hundred thousand chips, way out of reach for a hobbyist, but accessible to large enough companies. Just because it's opaque to us software people doesn't mean it's not a real industry you can buy things from.
And all that expensive engineering is still less costly AND faster (!!) than a new software certification.
Cannot refrain myself from asking why ...
Situation: Software-1 on Platform-1, both certified.
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.
Doesn't seem crazy to me. Which one do you suppose needs more proof of correctness: a cake recipe, or the oven you bake the cake in? The recipe has to be correct or the cake won't work, but the oven just has to hold a temperature.
Ovens vary greatly. There is no consistency in how even the heat is in the space, the airflow through the space, how much and how fast the temperature varies around the set temperature, etc. These things all do affect how things bake up and often people have to tweak recipes for their specific oven.
In a case where something is safety critical the computer is super important as very subtle errors could cause catastrophic consequences. This is why you get into things like running software on 3+ computers concurrently depending on how fail-safe something has to be.
That "just" is quite the load-bearing seam ...
Particularly when the task here is "just" to measure some rod positions in a constrained 3D space ...
When Xerox established PARC, they asked the assembled scientists what computer they wanted. The majority view was a DEC PDP-10 KA10, with the BBN memory management unit that let it run Tenex (the ancestor of DEC TOPS-20). Xerox couldn't really buy a competitor's mainframe, so they built MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
>MAXC (maximum access computer), which was a complete emulation of the Tenex machines.
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".
The clone hardware manufacturer was Systems Concepts. Microsolutions was a software play -- I think they had something to do with trying to port 1022/1032.
very apt that xerox parc was full of tenex engineers!
IBM released the PC XT/370[1], built around a pair of 68000s and an 8087 with custom microcode to emulate System/370 instructions, in 1983.
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...
It could be an FPGA. Given enough gates, and the know-how to program them, you can make an FPGA emulate anything. Speed and efficiency could be better or worse, but if you're targeting old hardware, better is likely.
I mean...there's some precedent. The XKL TOAD ("Ten On A Desk") implements the PDP-10 instruction set, and will happily run TOPS-10/TOPS-20. LCM had one doing just that.
https://www.computerhistory.org/collections/catalog/10277383... https://www.twenex.org/?network
It's tempting to write a PDP-10 emulator for the Atari ST called TOAST.
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...
Fascinating stuff; thank you for sharing. Can I follow your work somewhere??
XKL is still in business (https://xkl.com/)
as far as i know the control plane on their equipment is still a pdp-10 compatible
I'd happily run ITS on that.
Meh, old architectures are relatively simple and you can get 95% of those via fpga softcores (some freely available, some paid) and run them on fpga. The rest can be implemented by a proper ee team.
>Then their ancient Honeywell(?) mainframes...
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)
Also immortalized as the name of the "gecos" field in the UNIX passwd(5) file, described in the v7 man page[1] as "GCOS job number, box number, optional GCOS user-id" (GCOS = GECOS after the Honeywell acquisition).
[1] https://man.freebsd.org/cgi/man.cgi?query=passwd&apropos=0&s...
Moltix would have been a better name than OpenClaw.
That's interesting. That means there are fewer checks for hardware than software?
Hardware is more amenable to static analysis than running programs which may receive an arbitrary number of inputs and express an arbitrary number of possible intermediate states.
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.
Software "engineers" like to abstract things. This doesn't pay well e with reliability.
You have inspired a blog post. World, be warned!
Having worked on nuclear plants (as a reactor operator) around that time this doesn't surprise me in the least.
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.
This is a great post. How does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware? If I were facing this issue today, I might start with an OS that has excellent emulation. Example: Can I run 32-bit MS Windows 95 via emulation on a variety of current 64-bit OSes, like MS Windows, Linux, AIX, HP-UX, etc. If yes, then we can assume(?) this emulation will remain relatively stable even if we upgrade our hardware later. Maybe I am overthinking the whole problem: Can VMs do exactly what I want today? Will VMs running ancient OSes, such as 32-bit MS Windows 95, continue to be stable/viable in the future? I am unsure.
Make sure that you have as thorough a specification of what the system is supposed to do as you can.
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.
What is this industry, if I may ask?
Electricity distribution, mainly transformers from 10 kVA to 500 MVA and more.
It takes a long time to design and a lot of material to make a big transformer and they last for decades. They are critical infrastructure so when one fails you want it replaced or repaired quickly but they are too expensive (millions of dollars/pounds/euros) to keep a spare unit idle for decades and the lead time for a new large power transformer might be six months or even longer. So repair makes sense, especially if it can be done on site because moving a big metal box full of oil, steel, and copper that weighs hundreds of tonnes is a major logistical exercise.
This isn't something that can be done by a company that 'moves fast and breaks things' and disappears next year.
> How does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware?
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.
Unfortunately, “popular language/ecosystem” includes JavaScript and PHP.
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.
Yeah agreed. Popular is a good first approximation, but to be more precise I think you want tools where the incentives in the community reward stability over features that require breakage, which would include languages and runtimes like Erlang and Clojure.
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.
My C programs from a few decades ago, before namespaces were invented, no longer compile. However, the old executables still execute. The old C compilers are available but not supported; ChatGPT warns to expect trouble. Perhaps maybe there are compatibility switches that work correctly. Using them would require changing the makefiles.
And worse for posterity, Python
The Amiga was a popular ecosystem.
And as a result it's very well emulated, making it very likely that Amiga code can still be run in 50 years' time.
Today. That was not true a few years ago.
I remember Amiga emulators (notice the plural) going all the way back to when i was in high school - and that was around 1999-2001 or so.
That was about the time frame of the commercial Windows NT emulator mentioned up thread. There was a market for them.
Today’s landscape is shaped by the pandemic. In between, there were many years of impracticality.
Perl was popular
Wasn't there some idea that went like "if something has been around for x years, it will likely be around for x more years"?
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.
C is very different C. There is C where programmer rushes to call fork(), just because he likes the idea of entering room once and exiting room twice. And this program has got excuse for his behavior. He has fork() in POSIX standard. So programming is using fork() here and there even if not strictly needed. Using fork()/exec() instead of more portable posix_spawn(). Using fork()/accept() instead of multithreading.
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.
Well I think if you were doing the 1976 way you might not even have multi processing or multi threading. Just a single process with a single thread. And so you don't have a database connection pool, you just have a single database connection and do one query at a time maybe.
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.
There were absolutely multiuser computer systems processing transactions from thousands of users in 1976.
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.
Lindy effect
run for ~50 years where the hardware will need to be replaced
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.
> how does someone write software that needs to run for ~50 years where the hardware will need to be replaced with non-equivalent, newer hardware?
Make it open-source, or don't buy without source.
It's interesting to think about this in the context of parent poster's story about the Amiga emulator in the nuclear power plant.
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.
You don't need source anymore. Have Claude Code look at the binary and write a new program.
I wouldn't rely on that for mission critical systems.
Even if VMs do not, whole-system emulators surely will.
But Windows 95 would be a poor choice, as you'd be stuck emulating a bunch of very specific aspects of both Windows (non-Unicode APIs, 16-bit application support, etc.) and the PC archictecture (BIOS, A20 gate, etc.) that exist only to maintain backwards compatibility.
If Windows is a requirement, you'd be better off building against something like the subset of Win32 APIs that has been stable since Windows Server 2003 and ideally testing against Wine, contributing patches as necessary.
If it were me, though, and it was something that required a general-purpose, non-realtime OS, and wasn't so performance-sensitive as to require deep integration with platform-specific APIs, my first thought is to target a Linux-compatible subset of FreeBSD, which should be enough to get you most of POSIX and then some, plus a full-featured GUI if necessary, portable between two open-source OSes that run on a wide variety of hardware.
I'd recommend not having it so dependent on the hardware and choose an OS that is relatively hardware agnostic (e.g. Linux). Also, ensure that the software is open source and if compiled, has an open source toolchain to do so.
Though people often decry it (due to the many, many footguns), writing something in Shell/BASH will make it trivial to move to newer machines.
DOS emulation is available more widely than Win32 emulation, and there is HX DOS Extender. I would try sticking to Win32 dlls runnable in HX DOS Extender. rundll32 or some other exe host. HX DOS Extender has no paging support and has problem loading multiple exe having no relocation info to the very same 4Mb base address they all usually pretend. DLL should have relocation.
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.
> How does someone write software that needs to run for ~50 years
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.
This was one of the promises of Java. You write your application and then you get a virtual machine (JVM). As time goes on you only maintain the virtual machine while the application remains the same.
The funny thing happened and verified this promise. There were several architects working on IBM System Object Model (SOM). In 1996-1997 many good things ended, and SOM was terminated. But the work was so good that two architects did not stop and wrote the book: Putting Metaclasses to Work (1998). That book has got reference implementation in Java. So we have IBM SOM as closed source binary and we have Java source codes.
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.
Write it in C or Fortran.
50 years ago, fortran iv had the "extended range of a do loop". You could jump out of a loop execute some code, then jump back in. Therefore 2 loops could execute the same out-of-loop code. It was useful; preprocessors like Flecs used it to emulate missing control structures.
ChatGPT says, "likely to need manual conversion". So no Fortran hasn't been stable. In another post I showed that C hasn't either.
Use Perl
>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.
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 grew up in a little post soviet republic, in a small town with a big nuclear power plant.
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.
Did they not need NRC recertification when they moved from a physical machine running AmigaOS to an AmigaOS emulator?
That is an advanced question best asked of the folks in charge of the plant. At the time I was just trying to figure out how to explain to the IT auditors why there was no antivirus software on this piece of crap.
Could you skirt around it and just remark "there are no viruses for AmigaOS"
(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)
Hello, my name is Lamer Exterminator, pleased to make your acquaintance.
https://en.wikipedia.org/wiki/Lamer_Exterminator
It wasn't the AmigaOS running in the emulator that they were worried about, it was the Windows system running the emulator. (Not that the average IT auditor there could have understood the difference.)
How would a virus get in there?
If it were a newer version of NT I'd be concerned about USB media, but being NT 4.0 and not supporting USB it's imminently more capable of being air-gapped than later versions. (I recall a fun Ed Skoudis quote-- "At best, an air gap is a high-latency connection". Evidence Stuxnet.)
The auditor probably doesn't know nor care. "Every windows machine runs antivirus" is a checkbox item, zero thought involved.
Depends. A lot of these audits are quite prescriptive and don't leave much room for actually thinking about the problem. There is often some kind of mechanism for 'this is sufficiently segregated it doesn't matter that it's utterly out of date' but then usually some awkward rules develop that prevent some things from being put into that category. More subtly you can get whether the thing even exists as a thing that the audit cares about, and that often depends on the framing (embedded software is often invisible here but it needs to not look too much like a general-purpose OS even though it often is).
(Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory)
> 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?
This is pretty universal in my experience any time you have inspectors/auditors intended to enforce a set of rules. The most common case is that they just miss some rule: they can be hard to properly map from what you're seeing to the rules reliably, so different auditors will miss different things (so you can get a sign off from one and then another highlights an actual contradiction).
The next level is that the rules are kind of vague or unclear and so different auditors will have different interpretation of it. You can try to fight it but ultimately the auditor is who needs to sign off on it. This is also why switching auditors can be a right pain.
Then you get interpretations which are flat out contradicted by the rules. Sometimes this is necessary to make the rules work (there's some blanket rule that's impractical to impossible to apply literally, so the auditors contort some interpretation that's more workable), sometimes it's just incompetence, and when it's wrong enough to matter sometimes it's easier to just go along with it than try to escalate the issue with the auditor.
You can also get situations where the auditor has their own pet rules, which aren't written down anywhere, but they will become much more adversarial if they are not followed (sometimes they'll outright tell you what they are, sometimes it's a guessing game).
The Amiga thing is funny, but NT 4.0 was still receiving security updates until the end of 2006, so seeing it in 2007 wouldn't be much different than seeing Windows 10 today.
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.
This reminds me of the apocryphal story of the IBM System/360 running a 1410 emulator that ran an IBM 705 simulator that ran a business-critical application.
Not wholly apocryphal. The U.K.'s air traffic control ran, and possibly still is running, on an IBM 4381 substituting for an IBM 9020.
* https://news.ycombinator.com/item?id=49763972
They've reportedly already tried, and failed, to replace it with a more modern system.
Which is why we should target VMs directly. Then that VM can be brought forward to new platforms rather than emulating the entire machine, not that emulating the entire machine is bad. One could argue that the emulation stack you outline was made possible by putting in the work to make simple, fully specified and documented hardware.
NT4.0 in 2007? That wasn't even very late. I was replacing NT4 servers into the early 10s. Car dealerships were terrible for keeping that crap around.
Interestingly, there are a few places that will sell you a warrantied and new desktop or rackmount PC with a Windows NT 4.0 license. I imagine buyers of their systems are often in similar predicaments, not sure who else would buy these.
https://nixsys.com/products/nx370-t90
There are some things I don't understand about the OP's constraints (are you sure you can't run that Amiga VM on a newer version of Windows, or better yet, run that Amiga-based software on one of the currently supported Amiga VMs?). But they can probably pretty easily keep going as they're going with this software until some other, more significant thing in that plant becomes fully obsolete and the place is shut down.
"Windows NT 4.0 machine running as late as 2007"
lol. I know a ... factory, that had a BBC model B (with a rather complicated wiring loom) still doing a job around that time.
The IT supplier at the same factory went to a museum in Cambs. around late '90s, early '00s to ask if they could buy an exhibit because something had failed locally. The museum gave them the part.
That was just aerospace and nothing fancy like your nuke plant!
It is wild to me that you would use any GPOS for something like this instead of dedicated firmware for the task. This is evoking similar reactions to when I read articles about infrastructure being hacked remotely: Something must have taken a wrong turn with the architecture design for this to happen!
I find it deeply upsetting that anything important for a nuclear power plant is using an OS without protected memory.
You don't need protected memory if your program is the only thing running. Plenty of microcontrollers have no protected memory and get used in safety critical applications.
Protected against what?
Bit flips from cosmic radiation. Pretty common.
they probably mean https://en.wikipedia.org/wiki/Memory_protection actually
Just another program poking memory it’s not supposed to. Not even necessarily maliciously.
That AmigaDOS emulation will almost certainly never run another program. (-:
Far more concerning from a RISKS point of view is the spare parts being physically in the same place as the live machine.
> Just another program poking memory it’s not supposed to. Not even necessarily maliciously.
What other program? Most DOS versions were not multi-tasking beyond "terminate-and-stay-resident" (TSR) programs like mouse drivers.
Whatever application you ran on DOS was THE application your computer was running.
We're not talking about DOS here. This is AmigaOS, a fully preemptively multitasked OS from day one. No memory protection, but unless your code is running on bare metal like demos and games, there are other tasks running.
Top parent of this thread is talking about a package for AmigaOS being run on a bespoke emulator (as the Unusable Amiga Emulator of the 90s wasn’t really a thing that could be used for that)
I wish there was some picts.
If it's still running I wonder what they are going to do about the year 2038.
Set the date back to 1980 and sticky tape over the corner of the screen where the date is displayed.
I'm curious, how did the hardware present itself? It couldn't have been an Amiga Zorro card since it would've been impossible to get that into a PC. Did it connect over a serial or parallel port?
I recall it being some custom ISA card with connectors on the back. The emulation software had drivers that interfaced directly with the card.
Interesting! So they were able to port the hardware but not the software for whatever reason?
If it's what I suspect it might be, it was probably a generic IO card with maybe a bunch of 8255 PIOs on.
Was this status indicator simple vertical bars that were black and white and displayed on an old CRT Monitor? Almost looks like black and white terminal vertical bars (like Alsamixer)?
> A certain nuclear power plant had a Windows NT 4.0 machine running as late as 2007.
To put this in perspective, NT 4 was released in 1996, 11 years before 2007. That’s roughly the same as someone running Windows 10 today, which a lot of people still do. The Pentium 1 was only 14 years old at most. These parts of the system shouldn’t be surprising.
The AmigaOS and software from the 80s are of course the older more interesting bits, but for critical infrastructure and safety, shouldn’t we expect and design for our hardware and software to last a long time, and not try to keep up with tech fads every decade? I feel like the main problem isn’t hardware or software that’s old, but that there wasn’t a longevity plan.
It’s always been an interesting question how to write software that will last a hundred years. Maybe with AI this is the first time in history that planning to port & upgrade to new hardware every 5-10 years seems totally reasonable.
> That’s roughly the same as someone running Windows 10 today
While true the situation is different. Hardware and software moved a lot faster in the 90's and early 2000's. Everything has matured, is far more standardized, and moves more slowly now. Hardware from 11 years ago when Win10 was released isn't that different from today's hardware. Same goes for Win10 and Win11.
There might be a seed of truth there, but FWIW, I’m not very convinced by that. CPU speed development has slowed down a bit for sure, but software development is going faster than ever. GitHub and NPM and Python 3 and Rust all didn’t exist in 2007. CUDA was first released that year. LLMs weren’t being used. At the start of 2007, the latest Windows version was Windows 5, one more than Windows 4. Almost same as today. There isn’t a Windows 12 yet, while Windows 6 was released in 2007. So the pace of major Windows versions might be slightly slower. OTOH, the OS is much bigger than it used to be and it gets more frequent updates and point releases now than it did in 2007.
> At the start of 2007, the latest Windows version was Windows 5, one more than Windows 4
Windows 2000 (NT 5.0) was released in 1999. Vista was NT 6, and released in 2006.
Where do you find 2006? My googling says NT 6 was released in early 2007, so I meant that on Jan 1 2007, Win 5 was still current. https://simple.wikipedia.org/wiki/Windows_NT_6.x
It wouldn’t make a huge difference to me if 6 was released either 6 months earlier or 6 months later. In 2007, NT4 was only 1 major version behind for most people; adoption takes time. The broad timing of major versions being 4-5 years apart didn’t change until Windows 11, and we don’t know if that’s an outlier yet, but we do know that Microsoft has been changing the Windows release strategy, with more frequent updates. https://endoflife.date/windows
I wonder if there is push in the public sector for open source software/hardware for cases like this.
I completely get the decisions over time here, but it's unsettling having a relevant piece of software (reports are important too!) working on with parts from ebay, in 50 years time they might be gone.
I've dreamt of governments hiring devs with promises of full time OSS work. It _might_ get some people over the lower salaries of government work. But I overheard a state CIO once say "We configure, we don't create".
That's to say nothing about opinions of open source that rival early 2000s Microsoft.
For old ass critical software and hardware, the org can always have a backlog of hardware and contingency plans (paying someone to fix the hardware, paying someone to create a fully certified and modern solution..) for when they start running out of parts.
Nothing wrong with this.
If it ain't broke, don't 'fix' it.
Just make sure that its well isolated from the Internet!!
Up until a few years ago the Metrocard machines in New York City were NT4.
How on earth are these massive pieces of infrastructure relying on software they don't have the code to? i'm just utterly confused how these things happen.
This is crazy. Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
This is how we would end up with nuclear disasters, not because the technology is bad, but purely because of mismanagement and human negligence.
This is crazy. Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Safety and reliability come from understanding the system. Something that's old but that you know everything about is far safer than something new. This risk is that the people who know move on, or the sources of replacement parts stop working, or that other things around the system change. Then the risk curve inverts and you find the old system more of a liability than a asset.
Almost always people choose to update things either too early or too late. Knowing when to do something is hard.
That’s pure negligence. It’s not like the people that have the know how disappear suddenly . It’s the responsibility of the management to make sure the knowledge transferred to new generation.
I guess that kind of thinking is what led to the collapse of ancient civilisations like why even bother to improve anything and let everything decay and die out
You can only say such things with hindsight. In the moment, nobody knows what the future will hold. Take the space program in the US for instance. In 1969 we landed a man on the Moon. We'd repeat that several times until 1972. At that point Nixon made a speech which implied various unpleasant things about space's future, but he'd be out of office, disgraced, a couple of years later, so how big a deal could it have been anyhow?
I think almost nobody from that era would have believed you if you told them that more than 50 years later not a single human would have traveled beyond low Earth orbit, and that we'd now be struggling to recreate what we did in 1969. Furthermore a significant chunk of the world doesn't even believe we landed on the Moon anymore, no doubt in part because of this apparent anachronism.
It's not like there was any sort of collective or even singular decision to just let things die out. I mean sure Nixon did his thing intentionally, but even as a President in the golden years of the US, he was still just one man.
> I think almost nobody from that era would have believed you if you told them that more than 50 years later not a single human would have traveled beyond low Earth orbit
Four people went around the moon earlier this year (leaving earth's orbit for the first time since '72)
Basically everything collapses as far as it is allowed to, and the collapse is slowed only by:
- profit, if a system generates it, people will keep the system running.
- dilligence, usually driven by personal idealism, and unrewarded.
- legal or financial penalties, or insurance costs.
- it has collapsed to a temporarily stable state for now.
For another comment I was looking at the Grenfell Tower fire in the UK around 2017 and the people who lived there had been raising fire risks for years and the landlord (management organization) and the council had been ignoring them, and ignoring the fire department. The companies which replaced the cladding on the tower with flammable cladding were choosing the cheaper flammable option and pointing fingers as well. And during the fire, the fire service had never dealt with such a big fire and didn't have a truck with a long ladder, didn't have extended-breathing gear, had radio problems, water pressure problems from the local water company (who deny that).
This kind of backstory is typical for disasters, and for IT outages - and I've taken to believing that if something "should work" but wasn't tested recently then you should expect that it doesn't work. This is a common saying in backups (you need to test restoring), but it seems to apply everywhere. Backup internet connections that don't have enough bandwidth for the company to keep running. Disaster recovery sites that share resources with the production site. 'Disaster recovery' that recovered into a remote site, but they couldn't do CAD work remotely over their slow connection so it was still disastrous. Multiple power feeds but they were cross-wired so one failing still functionall took down everything.
If knowledge transfer "should be happening" but it's not critical to a job, or it's not profitable, or it's not legally required and audited, then it isn't happening. Subject to the dilligent idealist employee mentioned above who are temporary in the long view. Management's involvement seems not to arrange the larger system to effectively shoulder responsibility, but rather find ways to avoid personal blame while cutting costs beyond the point where everything that needs to happen keeps happening.
It’s the responsibility of the management to make sure the knowledge transferred to new generation.
That's just lazy thinking, and probably a sign you've never been a manager. For all the responsibility to lie with management you'd have to be leading people who enthusiastically do what they're asked to do, raise problems, document things, follow processes, and make sure everything is handed over to the next person when they leave.
That's not how people are. They'll have times when they're unmotivated, underpaid, grumpy, over-worked so they miss things, etc. That's when the organisational tech debt starts piling up, and there's nothing a manager can do to stop it except manage it as best they can even though they're under the same pressure, with the same lack of motivation and crap pay as everyone else.
It's so easy to think you can fix it just by keeping on top of it and micromanaging where it starts to show up. It doesn't work that way.
> … underpaid … over-worked
These two (and many others) are well within management’s purview.
> … there's nothing a manager can do … [emphasis added]
Right, but Management (capitalized and plural) can. A manager should report, and management should fix - if not, it’s management’s fault.
The Management of a company is a group of managers. There's no real difference between the group and the collective.
The fact that you're willing to absolve an individual manager but still believe Management can fix the problems is a big part of the problem. The Management usually includes the last person in the chain who has the ultimate decision making power. If you assume that when I said 'a manager' I meant that person, it should be fairly obvious that even they don't have unlimited budget or unlimited time, and they can only try to fix problems they hear about. Within those constraints Management are still going to find fixing systemic problems hard.
It's very easy to look at something with hindsight and think the outcome should have been predicted and corrected. If you look at the real world you'll see that just isn't the case. Personally, I wish we had a lot more people applying some systems thinking approaches to at least consider the second- and third-order impacts of their decisions but I imagine that won't ever happen. It makes me sad because it's actually really interesting.
> This is how we would end up with nuclear disasters, not because the technology is bad, but purely because of mismanagement and human negligence.
I'm pretty sure constant upgrading would be more likely to cause disasters.
I can only imagine how much less reliable a modern JavaScript Electron app would be in this role...
Lindy's law:
For non-perishable things - i.e technologies, ideas, books, institutions - the expected remaining lifespan is roughly proportional to how long they have already survived
Time acts as a filter: what has already withstood a long stretch of disorder is more robust, so the longer it lasts, the longer it is expected to last.
The old nuclear software running on mainframes have passed the test of time. The new software, has yet to.
Nassim Taleb talks about this at length in his book, Antifragile.
If it's not broken, don't fix it.
Same reason why MTA in NYC still operates subway using 100 y/o signaling hardware on most of the lines.
In a way, your comment and the responses you get is a perfect allegory to inexperienced vs experienced engineering.
Their 100 y/o hardware is built from stuff that's still produced though. We still make relays (not identical ones but ones that perform the same function), wires, and mechanical levers. The system's behavior is not encoded in the relays but in the connections between them. If you had a CPU made of separate transistors you could replace burned out transistors with any future transistors but if you had one made of chips you'd need those exact chips that were out of production.
Replacing the relays in old telephone switches is a problem because they use so many weirdly specific types of relays - but those systems are only found in museums now. I believe track control uses fairly ordinary DPDT, etc., relay designs.
But similar reasoning is why Canadian trams are worse than other countries, and it's not "good experienced engineering". In this nearly hour long rant by NotJustBikes[1] the section I've linked is about the technology and how the transit authority will not move on from 100 year old track technology which makes everything worse for customers. There are junctions where tram drivers have to stop and look at the track to make sure the junction is correctly set because the single-point switching is less reliable than modern designs. Or the driver has to stop the tram and get out to use a stick to move the track and change the junction because they aren't electrified. And then pass through junctions as slowly as 10km/h because the old track design has higher risk of derailment than modern designs.
The designs for the electrified track switches were made by one company which was sold, re-sold, and then burned down and the designs lost, and there isn't anywhere else to buy them because nowhere else uses such old track design anymore, so not only is Toronto struggling to buy parts to continue electrifying the manual junctions, it's struggling to custom-make enough replacement parts to keep the aging electric switches working faster than they fail.
And they were using trolley poles to connect to the overhead power lines instead of Pantographs until 2017, 50-100 years after everywhere else, which meant a) they couldn't get enough power through them to run air conditioning, and b) they are more likely to fall off the power line and the tram stops and the driver has to get out and reconnect them, and c) their newer trams now have to have custom dual-power connections to go through older parts of the network, and d) the carbon shoes on the trolley poles wear out quicker which means the trams are dirtier and taken out of service for maintenance more often in the wet which is when people want to use trams more.
[1] https://youtu.be/HhQxNHrD6fA?t=2311
OK, but the context here is IT in mission critical infrastructure, like energy or banking. These industries will not jump on the latest technology and will drag their feet for as long as possible, and for good reasons.
Also, I happen to be familiar with NotJustBikes, watch regularly. I don't see this as the same kind of problem. What you explained is clearly BROKE. What we're talking about works just fine and migration to newer technology doesn't provide advantages outside easier maintenance. It can't be justifies by costs, either.
A friend discovered that one of the more modern pieces of equipment instrumenting those old signals was an ancient WYSE terminal from the late 90s that had been bricked over during a station project.
They moved a booth or something and the compartment it was stuffed in was missed during the cleanout. The thing was working for at least 20 years and may still be there!
I worked with a client that had a cash disbursement system working on an ancient dBase 16-bit application. They had a very difficult to change process that required multiple transactions because the system couldn't represent the dollar amounts appropriately.
> If it's not broken, don't fix it.
I understand that way of thinking for a small business computer system. Not for a critical infrastructure. Also if people actually thought about like that we would still be in stone age, like why invent something new or use a new technology? Keep on using rocks to crack nuts and kill animals
I think you can imagine the difference between “I did some work and made this thing that is clearly better, but we might have a few kinks to work out” and “I did some work, and if I did it perfectly, it’s just as good as the old thing, but we might have a few kinks to work out.”
I agree with you. First, "broken" is not a binary, it might not be broken but it might not work well either. Second, sooner or later everything breaks, and you better be ready for when that happens.
> Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?
Same reason they don't modernize health care infrastructure. It's too expensive, people die if they get it wrong and they get voted out of office for their troubles.
Because what they have works well enough to be NRC-certified, and they have enough spare parts to comfortably outlast the rated lifetime of the reactor.
Relevant: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
There is no reason a more modern system would be better in any aspect.
Now you know why "nuclear power may have been dangerous in the past, but with modern technology it's completely safe and Chernobyl will never happen again" is not a good argument.
Chernobyl didn’t happen because of technological blunder or even human negligence. It happened because poverty caused by communism in Soviet Union had to use old outdated (not the modern nuclear technology at that time) graphite tips in carbon rods because it was cheap and also kept it as a secret from the facility operators giving them a false sense of trust on the kill switch.
Chernobyl is the perfect example to not use outdated old technology. Had they used the modern western technology at that time to upgrade their nuclear reactors the kill switch would have prevented the whole disaster instead of increasing the neutrons make the core a nuclear bomb.
Next time educate yourself with facts before making a fool out of yourself
> old outdated
Wikipedia's pages on Chernobyl say that construction started in 1972 and the problem with the control rods causing an initial spike of power was discovered in 1983 ?
[1] https://en.wikipedia.org/wiki/Chernobyl_Nuclear_Power_Plant
[2] https://en.wikipedia.org/wiki/Chernobyl_disaster#Accident_se... (search 'Ignalina nuclear power plant')
Chernobyl was very much not "old", it was a more modern design than the PWRs which are built today. Chernobyl Unit 4 was also basically brand new, only 3 years old at the time of the disaster. The RBMK design dates from the 60s, whereas the PWR is from the 40s.
"Had they used the modern western technology" ... "Next time educate yourself with facts before making a fool out of yourself"
But you are aware that this thread is about a reactor in the west, that "updated" their certified hardware to a VM instead running on windows NT?
Everyone knows that all technology newer than Windows 2.0 will never be obsolete!
Frankly, if not for the issue of components aging I would trust 1970s PDP-11 or even a PC-XT running MS-DOS a lot more than a modern system. This vintage's hardware was extremely mature and simple to understand and operate. No Ghz buses, no multiple levels of caching, no speculative execution and long pipelines.
DOS was a single task operating system. Once you proved such a system could run for days, months and years, there's no reason for it not to function 50 years later other than component failure.
That must have been a crazy moment for you when you first saw it and a big sigh moment for whomever had to explain it to you the first time. Thanks for sharing this; it made me smile!
[Source: Was NT developer - have code in NT 4.0...]
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".
dBase, MS-DOS 3.x, not using industrial anything. And as its a front of house tally machine, there's literally zero incentive to ever upgrade it. Downtime is measured in the yearly reboot, but there are non-operational business hours, so everything is just scheduled around that.
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.
I wouldn't call them business-critical computers, but I do have about 3-4 computers under one of my workbenches dedicated to certain work I did for a client. One of them has an EPROM programmer set-up, which includes a custom ISA-card, and a ribbon cable to an external box with a ZIF-socket. The software for that requires MS-DOS. To network that box, which is a 486SX, I run WFWG 3.11. Since these never go on the enternet or anything outside 'the lab', I don't worry about the old MS networking.
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.
Not MSDOS, but I feel obliged to shared the story of an auto shop in Poland using a Commodore 64 to run the calibration and wheel balancing some years back. It was viral news at the time but worth sharing again.
https://www.youtube.com/watch?v=tXdLtnt-nvE
Original Polish article - https://www.trojmiasto.pl/wiadomosci/Warszatat-samochodowy-z...
Or McLaren needing to use an ancient, very specific Compaq laptop to service the F1.
https://www.extremetech.com/cars/227828-the-mclaren-f1-super...
Not DOS, but I sold a '99 HP computer running win98 last month, to replace an identical failed system. It was used to control a 50 meters long custom industrial paint booth line for special equipments (like 57" rims). Luckily, their HDD was OK. Urged them to make a few sector-to-sector copies of it on a few spare HDD. This $100 sell surely has prevented this business from massive bills or even going bankrupt in the meantime from production loss.
Insane to me that someone would use a windows machine to run a piece of equipment when PLCs exist and are supported for decades by companies like Rockwell, Siemens, Allen Bradley
There are lot of windows based solutions since more than 20 years ago for two main reasons : recipe management system, and logging. A basic SCADA of sort. PLCs systems of that era could either not manage it (TSX, S5,S7-100/200), or it would be additionnal very expensive, complex and typically OPC-based solutions (I'm shivering).
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, ...
Oh, and I forgot another great issue that made a lot of companies developping their own PC/windows-based solutions : PANELS. The panel solutions provided by the main players were quite horrific : proprietary, slow, buggy, limited, very expensive, bad at commissioning (speed, firmware/software compatibility issues). Siemens Simatic HMI from the '2000 decade was especially lagging and a few generation behind those from, for example, Allen-Bradley with the PanelView +/CE range, based on... Windows CE.
Weren't all the ATMs running a custom Windows 98 into the late 2000's?
Lots of NCR's ATMs switched from OS/2 to Windows 2000 workstation at the beginning of the 2000's in western europe. Probably the same anywhere else. Had a lot of fun with token ring networks with the strange square connector plugs.
You maybe be thinking of OS/2.
https://wiki.os2world.com/index.php/OS/2_on_ATMs
Think that’d be worth more than 100 :)
I had it listed at this price for a few months, simeone from their company purchased it and rode 2 hours and half to come get it. Couldn't and had no reason to up the price at this stage. Indeed, this was a very good deal for them.
I had a functional STA Compact [1] coagulation analyzer until 2022. It ran a customized DOS version on a ITX computer board that was integrated into the analyzer. UI was in text mode and used the keyboard only. It had no mouse. The video in the link shows the UI for a few seconds at the end. We kept it functional as a backup and even used it a few days when the replacement broke down. It was one of the best analyzers I ever used.
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.
Not any longer. Back in the mid-2000s the company I worked for sold point-of-sale systems based upon a multi-user 4GL application (TAS Pro). Similar to dBase/Clipper etc., using the Novell Btrieve ISAM database engine.
With 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.
Not DOS, but two similar era cases.
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.
If you don’t mind me asking, how can a thing that causes disruption when it dies still not be considered essential?
Blind Control for the C-Suite?
Not DOS but another dad in my town works for one of the opera houses in NYC.
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."
0 - https://en.wikipedia.org/wiki/Surtitles
Ah, that sounds like it's The Met, who have a bespoke electronic libretto system.
You're right, it is a bunch of LCDs on a bus (iirc rs485).
I feel like we probably both know the guy who runs it.
Couldn’t you install a cracked windows xp on any kind of machine essentially? Or what is special about “windows xp machines”?
Windows XP drivers don't exist for modern computers. I do wonder if 32-bit Windows 10 would be an acceptable alternative, though.
I worked in a state gov't agency as a temp, twice, in the same department. Several of us had shared access to a PC that let us log-into a special terminal program and read records on some mainframe someplace. That PC had a 233-MHz cpu, I'll assume single-core. At that time, it ran Windows NT 4.0, and it had been patched to use a USB mouse. But we didn't rate an optical mouse, so someone would come in twice a day with a tote of cleaning supplies and clean the mouse ball.
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.
The Detusche Bahn still runs DOS and Window 3.11 in their ICE I trains! They searched for admins 2 years ago. https://www.tomshardware.com/software/windows/ms-dos-and-win...
You should check out the NYC subway, which has electromechanical relays, cloth covered wiring, and pre-WW2 analogue panels.
They do not even have an OS!
Let me assure you that Deutsche Bahn also still operates about 500 mechanical signal boxes, about 100 are from pre-WW1. Not these fancy, modern electromechanical relays (which Deutsche Bahn of course also has).
> about 100 are from pre-WW1
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.
That's far superior than running an outdated general computing platform. Electromechanical devices are simple, easy to understand, and replaceable. It may be harder to diagnose problems but with maintenance it will work forever.
+1 from me for relais technique. It is easy to replace, even in 1000 years. Today PLCs are great and fun. We can do a lot of cool things with them. Just with the short and shorter life cycles, sometimes even less than 10 years. If something breaks you have to replace so much stuff for a small broken piece. Thats such a bummer in todays industrie automation.
i don’t want to say this explains things, but i do want to imply it
I had to keep an old clipper/dbase application running until recently. It worked perfectly seamless with vdos (vdos.info). It's commercial software, but very reasonably priced. Dosbox is another alternative, but didn't work as well with printing and I think also wasn't able to do row locking of dBASE databases over the network.
Me!
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.
A neighboring warehouse/supply place has an old system of some kind, I think DOS.
Old monochrome screens, and one of those printers you can hear ripping off every line, and it has the perforated sides for feeding that you rip off.
I haven't been over there in a while, but someone brought me back a receipt yesterday and it was printed like a modern invoice. I guess they updated.
Not DOS but we recently had to virtualise a Windows XP box as it was running crucial software for a visitor attraction. The software was written by a member of staff who sadly passed away and the PC it was running on was approximately 20 years old.
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.
I've not virtualized things in that way for ages. I think I was using VirtualBox years ago and com0com for serial communication.
What do you use for VMs these days?
We just used Hyper-V
A company I used to work at still ships a piece of hardware with an Intel 186 microcontroller in it. The compilers are 16-bit DOS applications and the tool to program the DIP packages with the program was also a DOS application. I’m not sure what the physical interface between the programmer and computer was.
I run 2 old Juki pick and place machines. They run DOS 6.22 on a 486 I think. My biggest pain points are, 1) booting them up without errors, and 2) transferring files to them wirelessly without any floppies. (without installing any DOS software)
Closest I got was with a GOTEK and an ESP32 emulating a USB. But it was flaky so I dropped it for now.
Would a Grease Weasel work for that situation?
I work at a multi billion dollar facility for a Fortune 100 company and we still depend on DOS. Keeping the mandatory DOS machines going is an exercise. Especially integrating them into modern systems.
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.
The serial port stuff is very close to what I'm working on - what's on the other end of the connection? What does "integrating them into modern systems" look like for you: getting data out/pushing data in/both?
We typically integrate them by encapsulation. Building multiple layers of more modern systems for them to communicate through. A combination of Windows and Linux boxes. The other end of the connection is very old industrial equipment. This is not to run the equipment per se but to configure and program it.
Actual MS-DOS or FreeDOS?
MS-DOS or Windows 2003 running DOS vdm.
This thread reminds me that there is a huge benefit to using a super common OS+hardware.
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.
If you have the source code it's going to be a lot easier to continue.
It depends on the gcc/llvm version.
2014-2017 I was supporting a clipper setup for issuing work order and many other tasks for an old civil aviation repair plant. I’ve ended up virtualising and moving it to a hyperv cluster. Definitely the case of “if it works, don’t touch it”. Also set up a closed network for CNC machines to let engineers in the shop send jobs over the net instead of running around with floppies or manually entering gcode through the console. Fun times.
The last company I worked for still had customers they were dragging forward to get upgrades from coax connexted green screen terminals to modern network thin clients. It wasnt on DOS, but very old unix OS, tape drives for backups, parallel for printers, serial for scanners. No USB. Lovely troubleshooting when you were dealing with 30+ year old hardware setups. There was only one company that would even servicenthe green screens if they failed, and you couldn't buy them anymore.
Siemens Field PG. It is a rugged Notebook for PLC programmers. At least in the last version until last year, the "Field PG M6" was possible to buy the Notebook with a special serial port for old S5 PLCs ant the Step5 software came in a special DosBox version with it.
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 Gear cutting job shop I worked for had a CNC lathe running with a GE Computer from the late 1970s that stored data on punched Mylar tape, until it was bought out in 2019.
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.
Just out of curiosity: is it possible to somehow attach an ISA Adapter via USB to a VM? ISA does depend a lot on DMA and timing, but the clock is only 8 mhz and gives a software layer on a modern cpu a lot of time to do stuff between ISA bus cycles.
Keeping old hardware running is very fragile. Most spare parts are decades old now too, and nobody knows if they still work properly.
To a VM? Possibly.
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.
USB and VM latencies are both questionable here, I would think.
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.
All those layers add some latency, but 8 mhz is really slow. USB 4 can do extremely low latency, otherwise PCIe over USB wouldn't work.
The problem is that a lot of those old ISA drivers were peeking and poking card registers as fast as the bus would allow, which was over 1 MHz (less than 1 microsecond per transaction), not DMAing data to RAM (though some did that too).
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.
Often people confuse latency vs throughput/bandwidth. With streaming and batching USB4 will shuffle a lot data through on average per second. But it will never hit reliable microsecond level or even submicrosecond latencies.
At the same time ISA card will never reach 40Gbps throughout with CPU clocking at tens of MHz only or often less.
This looks quite interesting:
https://www.reddit.com/r/vintagecomputing/comments/jbaw38/is... (2020)
ISA-over-USB, using real ISA cards in an emulator
https://github.com/Manawyrm/ISASTM/
Or maybe expose the LPC bus to a VM, and wire the relevant lines to an ISA bridge?
https://en.wikipedia.org/wiki/Low_Pin_Count#ISA-compatible_o...
https://www.youtube.com/watch?v=putHMSzu5og&t=208s
https://github.com/rasteri/dISAppointment
I've an AMD K5 processor machine running at 100 mhz. for testing Transputer ISA cards when someone buys one, I also use the same machine to format and copy my Pascal compiler into a pair of 5 1/4" floppy disks. All using DOS.
> Transputer ISA cards when someone buys one
Your use of “when” is interesting - suggests it’s not that occasional. Wonder what people are doing with these nowadays.
Not DOS, but my company has a Windows XP machine with a dialup connection that I have to keep running for obtuse legal reasons.
If it goes down, the company gets fined. It happened in the gap between my predecessor leaving, and me being hired.
Does it have to be a XP box or is just keeping a serial dialup connection working the key?
Is it a physical machine and not a VM? I already had issues with getting XP compatible spare parts years ago. Had to buy used parts that were already pretty old (so high risk of failing again).
It's a physical machine.
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.
Put a proper sticker on, that can't be removed easily.
It's not totally for business, but I run some antennae and radio telescopes that feed through a Gateway 386/33/16MB RAM. As well as a Getac, no idea what model, but it's from the early 2000s. They both feed through to a A/B switched Paradise CRT (so cute). dBase is on the list.
My dad ran a commercial 2-way radio business. There were multiple radios with programming software that would not work on anything above a 386 and DOS. He had a couple computers from the late-80s running for nearly 25 years, though I think he had to replace one of them with another of similar vintage. Also, had a 486 that he used for customer notes in WordPerfect up to about 2015.
I suspect he could have found a way to use a newer computer, but if it ain’t broke…
Intel was seling 386 CPU up until 2007. I personally was using brand new special equipment with 386 soldered to custom MBs with no VGA, serial only access. I suppose you can purchase such boards from ebay/recyclers today.
Book 386 is a ready notebook. It mainly targets gaming, so it has speaker, OPL3 sound and MIDI/GamePart port. But also ISA as yet another "port" on its outer side.
I still have a circa-1996 486 running Windows 95. It has an EPROM burner card and software that I use to reprogram the ECM in my car.
The cost of upgrading to modern software and hardware is substantial, plus the learning curve for something I only do rarely nowadays.
Now that I think of it, some of the software was for Motorola radios. He was not a licensed Motorola shop (Kenwood), so I believe getting more modern software would have been difficult or very expensive, if even possible.
I know a shop that still runs an Apple ][: they have a Numerical Control machine. For those who don't know, NC is the predecessor to Computer Numerical Control, i.e. CNC machines.
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 ][.
Does the idea make use of https://86box.net? Just heard of this recently on hn and it seems promising for anything that requires low level/cycle accurate emulation vs. your typical high level emulator.
My idea is a DOS emulator with a really thorough log of every DOS interrupt called and I/O port interacted with. This could then be used to automatically, say, insert rows into a sqlite table when the DOS app updates a .DBF file, or forward GPIB data to a modern USB adapter. I wanted to avoid low level/cycle-accurate emulation as much as possible, only adding quirks as needed to support the most popular business application suites.
It should work with Siemens MPI/PPI interfaces, but I predict issues with ex-Telemecanique (now Schneider Electric) unitelway realtime DOS driver which is extremely picky.
i know still some accountant who use a DOS program to do his work because he hates the fact modern UI has load times. slows him down too much o.O (his program is all keybinds).
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.
Don't underestimate the work speed a person can maintain with a reliable, fast keyboard interface. Finding the right spot on a web interface and navigating with a mou---too late, the keyboard user already entered the invoice for that account using some odd VAT rate on 3 of the 5 products.
It's been a few years now, but I know a major manufacturer had some windows XP boxes around because they were the newest hardware/software they could get with native parallel port support to interface with their machines.
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.
For anyone that needs true native serial & parallel ports, a Dell Latitude E series laptop (or Precision 7xx0) with docking station is an easily-available option.
The last machines with dock port have 6th gen Core CPUs (Latitude E5x70), or 7th gen for Precision 7x20.
I don't really know the full details, as it was my brother who worked there and we just chatted over beers, but I believe the software itself that communicated over the parallel ports was 16 bit, and that (along with the native ports) was the reason they kept the old windows XP machines around.
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).
Not as pure, but for what it's worth I've had success with a Syba SD-PEX50023 in applications where USB-based parallel port emulation failed.
I suspect more modern computers would have chipsets with dead leads for rs232 if your soldering is fine enough
AND more to the question - the contractor who remodeled my house in 2014 was still using some ancient DOS app, possibly running on a DOS machine or at least an emulator of one, to generate billing. Which was handed to me on paper....
(He was a good contractor, so clearly having the latest billing software is not the deciding factor in that.)
Do scanners count?
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.
An old story. I used to work for Fox Home Entertainment (CDs etc)this is 20+ years ago. And we had proper DOS running on old machines. We used it to do all our finances (including all of Japan, Asia sales). Most of the money we made on movies like Titanic were tracked on DOS. Until about 2003 if memory serves me where we moved to SAP. Why this was worrisome was how easily fraud occurred. In my tenure there $5-10M was stolen. At the time sent to companies in Brazil. I'm still surprised by larger firms where they keep these things alive to retain the data. CocaCola did it. A few large Insurance firms too. Crazy.
We have a client (a factory) I wrote a massive (for one person without AI) Clipper system for that runs the factory; this is decades ago but it just works and when they tried to replace it (not by us, but promises by others), it was worse and they did not switch. Cheating, but another client is a bank; they found its is really inefficient to not use DOS. Their machines use Windows but fullscreen DOS box you cannot close or minimize with the app in it.
I bet most AI is capable enough now to migrate you away to some emulator for a few dollars.
And I would even bet that in most cases you could run a solution on a sub $10 board from aliexpress.
or a $25 android phone
I had to keep a disturbingly old machine with GPIB running until a few years back. They are still in operation in Australia (who we sold them to).
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.
You're trying to create and sell a version of dos box? These companies have not replaced their computers because to the user there is no separation between the computer and the machine it controls. So the computer will be updated along with the equipment, which is not connected to the internet or a network anyways so it's not a cybersecurity risk. For the user, if it runs fine, there's no need to update just the computer, and the computer is updated along with the machine
In other words, these are embedded systems.
Not exactly, freely available solutions are already good enough for people who just want to run their apps on modern hardware, and have been for a long time. What I was thinking about writing is a tool that eases migration by using interrupt and I/O hooks to detect common patterns and, say, builds a modern SQLite database as the business uses their dBase program. Whether anyone actually needs this, I don't know.
There's a few car dealerships that still use databases from the 80s. As for why they haven't migrated, I'd guess must be reasons I'd assume at this point it's a choice they have made
As someone who works with car dealerships, easy: no one has been able to convince the owner that replacing these systems would help them sell more cars.
If it's a new car dealership, though, they're surely using (relatively) modern systems as well, as there's no way they're using an old DOS system to communicate with manufacturers to order cars, file warranty claims, submit financial reports, obtain service information, …
I know of a DOS machine at a wool testing place that uses an ISA card based imager for measuring the micron and other things. They also have a supporting DOS machine with a dBase looking database on it. When I spoke to the owner he didn’t really understand the risks involved in running ancient hardware and in fact had a storage room with period PCs in it if the machines failed. He didn’t have much of a backup plan for the imaging hardware though.
My opinion is that if these guys are still running this gear, they already have a strategy in place (no matter how flawed) and would likely retire before throwing money at something they consider a non problem.
Good luck with the idea. It likely is a tiny niche market with customisation for every customer and given they are normally hardware constrained AI may not be much of a help.
All of them have no money as well.
My idea is basically a DOS runtime with hooks on interrupts and I/O that would allow for either migrating databases to modern formats, or converting I/O accesses for modern USB peripherals. Customization for every customer and AI not being much of a help are pluses for me... lack of money not so much.
I have been porting sections of the business software I mentioned earlier from QuickBASIC on DOS (nice to have the source code!) to Tcl on Linux using ChatGPT to automate the conversion. It gets it right the first try, almost every time.
The BASIC code is very simple by modern standards, and Tcl overlaps BASIC neatly, making conversion easy.
Unfortunately it's just a short-term stopgap to add some features management suddenly can't live without, that weren't practical to implement in BASIC/DOS. They'll replace the whole stack with a commercial product and support contract when they find something they like.
For anything business-critical, I'd tend to want to rely as much original code as possible, running actual MS-DOS on emulated hardware that could be tailored to suit your I/O needs.
Lots of forkable code exists to get started with this, QEMU, 86Box, DOSBox, PCjs, MAME, …
And if you do want to go the route of implementing DOS and BIOS interrupts yourself, DOSBox does this.
You can still get ISA slots on systems as new as Broadwell with an adapter.
One of our vendors is a contract electronic manufacturer (circuit board stuffer) that has a wave soldering machine running MS-DOS on a PC that's built into the control cabinet. It uses the parallel port to communicate with Opto22 industrial i/o modules, which then is wired to all the temp sensors, relays, etc. It just keeps working.
I used to be doing that, but this was a bit over a decade ago at this point. There was an SBC with DOS on a chip that connected to Novell Netware. I set a few variables in autoexec.bat, let it connect to the network drive, then had it run a script from there to admin them / do backups (by which I mean xcopy the C: drive).
These were for some industrial CNC machines with a poorly version-controlled app (send us the single-file .c for the program, we'll make changes & recompile for you, then send back a new .c and .exe file) that would just malloc() all the memory on the machine for a million element array instead of tracking the 1k or so unit IDs a more efficient way. They were six digits long, it worked... mostly.
I kept a 3.5 floppy with the contents of sys a: that I used to run sys c: after restoring a machine from backup in my office.
EDIT: oh, and of course by "restoring from backup" I mean reversing the xcopy to copy everything from the network drive's copy back to C:
EDIT2: My memory is going, they didn't use malloc() at all, anywhere in the programs, they just had a static million element array.
We did at my previous job, obviously airgapped because the equipment (pharmaceutical mixer, worth in the high 8 digits) was still working just fine and was easy to service despite the vendor not being in the business anymore.
A Customer of mine has an 386 machine with an ISA interface board connected to an optical comparator instrument. I believe they also still have some MS-DOS-based computers connected to CNC machines, too.
I have two Customers who use DOS applications under DOSBox (a Clipper-based accounting package at one, and a Symantec Q&A-based application at another).
I remember reading that Disney was running XP on Toy Story Mania at Disneyland for the ride itself. When you stand in line near the loading point you can see the computer screen where the operator monitors everything. Not critical or DOS but comical it's doing a basic control of the ride.
We were talking about Visual FoxPro only a few days ago. [1] And one of those same companies in my comment [2] uses an old ordering system that is still in DOS and they boot up a VM to use it. They still have a printing machine ( not a normal printer ) for those order printing connected via a Parallel Port. I don't know the details of how that works though.
And by the end of all that, the order will be Faxed. Manually.
Did they tried to email it or automate it. Hell yes. Did it work? No.
[1] https://news.ycombinator.com/item?id=49808023
[2] https://news.ycombinator.com/item?id=49811716
We keep a FreeDOS machine at work for dialing in to configure and service paging terminals and using old two-way radio programming software.
Most of the stuff I've moved over to run in DOSbox but it's still in use occasionally for the software that's difficult to port over.
I heard somewhere that George R.R. Martin still writes his novels on a DOS machine using WordStar, though I'm not 100% sure how true it is.
One interesting thing of living in the AI era is that every single one of these old apps (that people still use and never paid big money to upgrade because it it ain't broke don't fix it) can now be rebuilt for $5 in ten minutes if you really know what to do (YMMV)
If you don't know, you'd have to pay an expert big money to do that and the migration abandoned just like before, so another decade will go buy until AI does that without permission just because it found a possibility for optimization and it is instructed to do so without human approval, because governments
Absolutely. And run faster, cheaper and safer.
Just as long as you still have all the documentation and the spec was done right and updated as things changed over the whole lifetime of the system up to now. And a good test harness. And industry-specific knowledge.
You would think so, but most of the low hanging fruit has already been rewritten and replaced. The biggest hurdle is hardware lock in, ISA boards, hardware keys, or other hardware interfaces that can’t be easily connected to new systems. Never mind the problem of verification. That app that takes days to rewrite can annoyingly take months to verify.
> if you really know what to do
The so called "load-bearing gap" you pay experts for.
Perhaps look into environmental services labs that do contract EPA work. I would not be surprised to see entire HP-Agilent(ISA-carded) - (think liquid chromotography analyzers) fleets that would match what you're looking for.
Until recently several customers have an industrial machine that boots DOS. I think the oldest effort we deal with is Win XP now. I do have a C>64 at home ...
In a world that requires security audits etc here's some notes that might help:
Scenarios: You have a device that only talks NetBIOS or even NetBEUI for file sharing. You need to get files to and from it and your CAD workstations run Windows 11 and anything less than SMB 3, with signing and sealing and all that jazz is laughable.
... Devices requiring ftp, telnet, serial over carrier pidgeon
Solution options:
Networking: The first job is to segregate your industrial gear from your general network and you might want to create two or more industrial gear and internet of things type networks with differing access policies. Start with one for now, you can improve it later.
You use 801.1Q VLANS logically or physically (why the hell did I want to write literally?) separate via separate switches.
Please do not skimp on this step. Buy a network bod to sort it out or put your IT bod on a course or hopefully they will have labbed this up at home already!
Comms: Samba is bloody wonderful and speaks everything that MS has ever done and deprecated. Even Samba does need to be asked to start speaking some of those dialects again but it will.
Put a Linux (other Unices are available) box on the same VLAN as your machines. You will need to set quite a few options relating to the minimum version for its server version. When talking to the machines, Samba is the server and when talking to your file server, Samba is the client.
Create a data share on a Windows box on the corp LAN. For example it might be on a file server for multiple access or just a single CAD PC.
Get the Samba box to mount that share to itself at say /srv/data_share_mc1
Now get the Samba box to create a share from /srv/data_share_mc1 which it calls DAT_MC1 (8.3 chars for NetBIOS)
With luck, you should be able to map DAT_MC1 on your machine.
I don't thing Samba supports NetBEUI, though you could run old Windows in a VM or emulator on the Linux box and just add another SMB reshare "hop", and of course only expose the old Windows VM to the "old" network.
Half of our system is running on 2002 versions software. To my desperation, my calls for updating has been persistently denied. There're no technical reasons to keep it as is, it's more about wetware issues.
We still use dBase files in some point as transient format, not using dBase as such though. Oh, and plenty of positional text files, but that's more a question of interop with partners.
Story time: I got handed a ticket to go change a UPS in a “server room”.
I was in Fairbanks visiting family, I had some downtime, so I decided to do some “slumming” to break up the monotony and relive some of the good old days before I was more boardroom than server room.
Besides, a cool grand for what I figured was 2 hours work appealed to me on some “miss the struggles” level, and it was better than walking around the tourist traps or doing video calls at some depressingly fecund coffee shop.
So, I drive up in my borrowed SUV with peeling paint, grab my trusty tool bag I leave with family for adventures like this, and walk boldly through the doors of this apparently normal retail establishment, clipboard in hand. It was 2019, and the smell of denim and factory pressed shirts wafted through my sensorium as I walked through the awkwardly desynchronized automatic doors.
It was a perfectly normal, somewhat 90s nostalgic retail store.., but walking up the stairs (the elevator was out of service) to the second floor, I could just sense that something was a little off.
The office had a smell. I can’t say what it was, it was businesslike, and not unpleasant, but it spoke to me in an unknown language and I was at that moment curiously heartened that my contract was being paid by a 3rd party. It smelled of stagnant ideas, missed opportunities, and a fossilized board of directors.
I’m not just being colorful here in prose. All of these thoughts were projected into my forebrain by some lizard sense I had developed in 40 years of skulking the halls of enterprises large and small. I was involuntarily imagining a half used tin of bengay on the boardroom table, right by the shiny beige speakerphone with the long stroke buttons and the filthy woven grill.
Curious by now about the flood of intuitions, I treaded the slightly dingy burnt orange carpet tiles up to the POC office, checked in, and was shown the door tot the server room. Through there she said, gesturing at a plain flat golden pine door with the elbow thingy at the top. “Through there, straight through, the door at the back. You can’t miss it. I think it’s unlocked.”
Unconcerned with the casual lack of escort (pretty common really), I opened the door and was immediately transported to surreal alternative world. It was dark, there were tens of flickering screens across to the right and one half hanging, flashing fluorescent fixture dangling precariously from the uni-strut above. The suspended ceiling tiles were about 50 percent in attendance.
Fragments littered the floor, and the door closed behind me with a loud thump. for just a moment I was touched by a singular thought….. (run). I shook it off, by now, far too curious to turn back, come what may.
Briefly thinking of my heavy tool bag as a potential weapon, then realizing the ridiculousness of the notion, I let my eyes adjust as I took in the scene with what I confess could only be described as some kind of unhealthy delight.
This was a large room, easily 800 square feet, and a was clearly dedicated to loss prevention surveillance. There was an epic workstation with 2 giant flat screen monitors front and center, and ten smaller monitors on either side. Most of them were dark, and most of the others were flickering with static.a singular monitor had a poor but recognizable image of a small nondescript room with a small desk and two metal chairs, one on each side of the desk in an overtly adversarial position. The image smelled of stale sweat and musty cardboard.
There was seating for two pilots at the helm of this derelict craft, replete with an impressive array of buttons, strange industrial joysticks, and an oddly out of place black dell workstation keyboard with the cord ripped in half. As I made my way up to admire the helm, I nearly tripped on an extension cord, only catching myself on a water filled trashcan with plastic sheeting aspiring to the heavens up through the dark abyss of the half-intact ceiling, which I only now noticed was comprised entirely (if sparsely) of black painted tiles.
Somehow this jolted me out of my entranced state, and I looked for the door I was supposed to find, quickly locating it towards the back of the room, just as I had been told.
Somehow it seemed like not an ordinary door now. It was with great anticipation and not a little trepidation that I examined the door. It was quite ordinary, really, and the knob was less dusty than it might have been. This was encouraging.
I tried the door, and it opened easily. Opened, that is, to a time 30 years in the past.
The buzzing fluorescent lamps were on and radiating furiously, instantly shattering the wreckage of the surveillance spaceship to smithereens. There was a gigantic, wheeled, beige machine in the middle of the room, about the size of an industrial floor scrubber. It hummed patiently, and featured a dim 10 inch green CRT, a beautifully sculpted beige keyboard, and a little less than a quarter inch of dust. I froze like a tourist gaping at a stegosaur’s nose, but quickly recovered my composure as I remembered I was here on purpose. Conveniently, someone had swept a path through the center of the room, back to the newly installed floor rack with a couple of ciscos, a backup cellular telemetry box, and a pile of screws and a throwaway screwdriver scattered haphazardly on top of one of the routers.
The UPS I was to replace was actually pretty complex to configure, but I very carefully completed it in about 45 minutes including some firmware regressions to accommodate some nonstandard plugin the vendor installed. By very carefully I mean without stepping too hard on the floor, dropping any tools, and afraid to sneeze even though I was under intense respiratory assault from the unavoidable clouds of fine carpet dander that had accumulated on the linoleum tile over years of janitorial malfeasance.
I was terrified to make any sudden moves, because sitting on a stackable plastic chair next to the pliestocene PBX was a beige box. Its fans groaned with the wails of a thousand parched capacitors, and its hard drive made a crunchy rattling sound that seemed entirely improbable for a functioning device. Just visible under the dust on the front was a badge proudly displaying “pentium pro” and a giant cable was fed from the back of the artifact, like an implant from the borg, something I strangely remember as “IBM type 1” token ring wire, though I can’t be sure anymore that means anything at all.
At any rate, it was obvious that the entire on-prem server infrastructure was this ancient and faltering nightmare box, and I knew that a fly landing on it could bring it down. The easy money contract was starting to look like a setup.
With terror in my heart, I finished my work, carefully closed the door, and put as much distance between me and that roiling cauldron of liability as I could. I don’t even remember going back through the wrecked starship, just checking out, and thanking Voltaire that I made it out of there in time.
It now made abundant sense that the job had been left on the board for nearly a month and the contract had kept rising… god only knows how many sensible technicians had noped out of there before I was hypnotized into compliance by the sheer bizarre fascination of the thing.
Poking around afterward, I found that the box apparently was the server that ran the terminals in the tire service area. They also had that fat cable that looked more like waveguide than wire, and it must have been an absolute nightmare to install. It was definitely token ring, humming along in 2019.
Sears closed for good a few months later.
Made my day.
A few years ago, I helped repair a broken USB port, on a USB-floppy emulator...
...which was so the operators could sneakernet their NC tape files into an IBM PC 5150 that thought it was talking to a floppy drive, of course...
...which hosted an ISA card that emulated the punch-tape reader that the NC lathe had originally been designed with.
The NC lathe hadn't missed a beat in 50+ years, why mess with what works?
I don’t know the specifics of their systems but both of my local lumberyards here in SoCal still use DOS systems for their point of sale and inventory management, with slow dotmatrix printers and everything.
They simply have no reason to modernize. The one big benefit they’d have is an online inventory system but they make most of their money from negotiated bulk orders so there’s zero incentive.
Most of the newer to us (1990s+) radio test gear has embedded versions of Windows running the controller. It's much easier than writing custom firmware that hands all the file system I/O for dealing storage, building a GUI, etc.
If "a few years ago" counts, a relative of mine abroad used an MS-DOS application attached to an Epson dot-matrix printer that supported a PITA foreign script to print invoices. It wasn't too painful, since the system supported batch jobs fed by a format that Excel could export.
Not current and not DOS... but years ago, around 2011, I helped set up a series of QEMU emulators running DEC Ultrix and MIPS Unix software that called out and retrieved data from weather stations only reachable by modem. The software had been written years prior in C and nobody had the source.
The box running the QEMU emulators had a bunch of old US Robotics modems hanging off it via USB serial dongles.
This is probably a wrong audience. Most people here are very technical - the kind that would not put up with tiptoeing around a sacred computer from decades ago running some magic software from the DOS era. This crowd will aggressively move it to modernized architecture or at least emulate it using a more modern platform.
The company I worked at in the late nineties, used Managing Your Money (MYM) for bookkeeping - initially on a dedicated DOS machine. My colleague set up a DOSEMU-based emulator and moved the software to it (bye-bye, dedicated DOS machine!). Later, he re-wrote it in STk (Scheme w/ Tk bindings, running natively in Linux) as ageneral-purpose transaction storage. ¯\_(ツ)_/¯
This is not always possible when the systems are validated and regulated.
Yeah. Sometimes old hardware forces its hand and causes a big PITA.
I had a job working on VAX/VMS around 2009, but it was actually an emulator running on a PC because they just couldn't find any hardware to fix the VAX. At some point before I joined they had to get a ton of government approvals to use the emulator.
Fortunately they had a project to modernize the whole stack. And it was going to Solaris :-/
I did, for a while. Then, I used VMs. I haven't had a Windows VM for years.
If I were a serious gamer (I'm not), then I'd get a hardware rig, but otherwise, I've not needed it.
I had a doctor that kept an original NT machine, for many years, because his bespoke app worked on it.
I don't, but the abbey at the city I live has an ancient PC running a program from the 80s that controls the bell ringing.
I recall seeing it connected via a parallel port to a large board that then operates the switches/relays of the hammers.
It's not DOS but my private school still uses an IBM 5100 to do payroll and record attendance.
What's the reason for not using a more modern MIS?
(I can certainly understand why organisations with niche requirements might hang on to old systems for as long as they continue to work, but I'd have thought that school payroll and attendance were much too commonplace to fall into that category)
I'm kidding. BRO, no school would be running the first (imo) commercial desktop still in the year 2026. The machine I cited was released in 1976!
I know of some laboratories where they have a host of old machines for software to support some critical instruments that only runs off a dongle or an ISA card and it still does accurate work.
Wouldn't an example of the given scenario be writing code 50 or more years ago in mainframe COBOL, and then still expecting to run it to this day?
I've seen some older retail stores use DOS machines, ones where the owners are 70+. They just don't have a reason to upgrade what they're used to.
Not recently but when I was a teenager (2001-ish) my supermarket was using a DOS computer to handle stock, print new labels when prices updated each day, etc.
Few years ago I was working for a F500 company and during an assessment we discovered couple of OS/2 Warp machines that were controlling CNC equipment
I do, for two clipper programs. But no extra machine, just a VM. Until not long ago, it was running without VM on 32 bit Windows 10.
>Anything with a parallel port dongle?
https://news.ycombinator.com/item?id=46849567
Still have a liquid scintillation counter running on DOS with raw data printed on a dot matrix
I've stumbled upon DOS on the LCD screen of the otherwise seemingly modern gas station.
I virtualized a bunch and they seem to work well. At one point, I even had Ultima running on one. =D
What do you think about it .
It’s gone now, but we used to have a random OS/2 box well past the point where that was extremely weird.
What's weird about Warp?
Like most people who bought into the OS/2 hype, I bailed after 1.3.
The weird part was still using it into the 2010s.
What you think about it
Not now, but few years ago I worked on a toll that runs DOS because… yes.
Also worked ~2014 DOS slot machines - in next year we ported to Linux
In the AI era, can’t we just release a new version of DOS?
FreeDOS exists, no need for AI:
https://freedos.org/