Ask HN: Who's still keeping a DOS machine up because the business depends on it?
Do you currently work with or know anyone who is still using:
* dBase/Clipper/CLARION/Paradox/other DOS RAD environments on period hardware to run business processes?
* CNC mills/spectrometers/microscopes/other industrial instruments controlled by ISA cards (either bespoke or standards like GPIB)?
* Anything with a parallel port dongle?
If so, I'd be very interested in hearing your experience here, or feel free to send me an email at the address in my profile. I'm not trying to sell anything, just doing some research for an idea around keeping these going on modern hardware.
285 comments
[ 3.0 ms ] story [ 141 ms ] threadMy 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.
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.
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.
Your use of “when” is interesting - suggests it’s not that occasional. Wonder what people are doing with these nowadays.
If it goes down, the company gets fined. It happened in the gap between my predecessor leaving, and me being hired.
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.
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.
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!
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.)
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.
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.
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.
Then their ancient Honeywell(?) mainframes reached end-of-life they scouted for compatible hardware, of which there was none. The cost of certifying new software, plus the time involved, was astronomical. So, after consulting with the FAA, they paid a hardware company to clone the ancient mainframes in modern silicon. The FAA signed off on it, and they had all-new computers - much smaller than the originals - running the old stack.
Compuserve also had a software dependency on the PDP-10 and Decsystem 20, and when those machines were no longer available they bought a company making clones so they could continue to manufacture them for themselves. The company they bought, Microsolutions, was Mark Cuban's first startup.
https://www.computerhistory.org/collections/catalog/10277383... https://www.twenex.org/?network
as far as i know the control plane on their equipment is still a pdp-10 compatible
Cannot refrain myself from asking why ...
Time-evolution: P1 is deprecated, replaced by uncertified P2, but S1 remains certified.. just nowhere certified to run yet.
Solution: There's another software S2 which originally vouched for P1, itself still certified, which can still be used to certify P2.
Counterfactual?: If S1 were deprecated in favor of new S3.. there'd be no plan to certify it!
The problem: None of this actually makes any sense! But we're trying to fake due diligence. Everyone knows the hardware/platforms kinda need to be certified with respect to each other anyway, but if we did it that way it would all be even more expensive an time-consuming.
Particularly when the task here is "just" to measure some rod positions in a constrained 3D space ...
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.
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...
https://en.wikipedia.org/wiki/GE-600_series from the 36-bit era which turned out to be a sweet-spot for Lisp; also "famous" for running Multics (old joke flipped: "which was many of whatever unix is one of")
GE sold it's division to Honeywell, and from there to Group Bull (French) and then to NEC (Japan)
[1] https://man.freebsd.org/cgi/man.cgi?query=passwd&apropos=0&s...
https://www.youtube.com/watch?v=AcQifPHcMLE
The simulator has a simulated cockpit for the user, which controls an armature with a camera attached that is piloted around a miniature battlefield environment and provides a video feed to the cockpit. A "foot" on the armature senses terrain elevation changes, which are then supplied as movement feedback to the simulated tank cockpit. All of this was controlled by a 1970s mainframe, for which replacement parts were unavailable so it was replaced, in the museum exhibit, with a Raspberry Pi.
It looks like hardware emulation was NOT used; rather, they translated the original program from paper printouts to a modern programming language: https://www.raspberrypi.com/news/simulate-driving-a-1970s-ta...
* https://news.ycombinator.com/item?id=49763972
They've reportedly already tried, and failed, to replace it with a more modern system.
Far more concerning from a RISKS point of view is the spare parts being physically in the same place as the live machine.
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.
This is how we would end up with nuclear disasters, not because the technology is bad, but purely because of mismanagement and human negligence.
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.
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
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.
Four people went around the moon earlier this year (leaving earth's orbit for the first time since '72)
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.
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 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.
- 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.
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.
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
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.
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
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.
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
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?
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')
I'm pretty sure constant upgrading would be more likely to cause disasters.
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.
Relevant: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
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.
Make it open-source, or don't buy without source.
Or, more broadly, in the context of any situation where the software is closely coupled to a specific operating system and/or hardware.
Having the source code would have helped tremendously, but might not have been sufficient because of the hardware story and the regulatory approval factor.
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.
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.
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.
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.
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.
ChatGPT says, "likely to need manual conversion". So no Fortran hasn't been stable. In another post I showed that C hasn't either.
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.
Maybe follow that. It's 2026 right now. What way of writing code would have worked 50 years ago (1976) that still works today?
Well, C, SQL and Lisp were all around 50 years ago and still exist today.
In terms of hardware, 50 years ago there was intel 8080. apparently code for that can still work via emulation today.
So if you wrote C for low level, Lisp for high level, and compiled the software to run in an Intel 8080 emulator, that combo would likely still work in 50 years.
Then it becomes impossible to introduce database connection pool. Well, probably possible, but in single-process multithread server this is BSc grade job, and in multi-process server this is PhD grade job. libmysqlserver and others maintain some context near to the socket, in opaque way. Hard to pass context between processes. At least, hard to return used connection back to pool in main process. Proxy is also not an easy walk.
On client side although Windows NT had POSIX layer, and XP/2003 still had Interix SFU. But Windows Vista broke SFU. But then Vista has got SUA. But SUA was not binary compatible, required recompilation. And as of Windows 10 there was surely no SUA. Was it dropped in Windows 8? Windows 10 has got WSL eventually, but there was a gap between SUA and WSL. And deploying Windows application with SFU, SUA or WSL part is not easy walk. Writing installer is MSc grade job.
Then comes iPhone OS and Android. They are POSIX OSes. Kind of. But spawning external processes is prohibited or not desirable. This is what was blocking LaTeX adoption on mobiles.
That may not work for network connected software with lots of requests per second. But such software did not exist too much in 1976 either as there was not very much networking going on.
As for networking, both the ARPANET and Ethernet predate 1976, though neither were ubiqutitous and most high-volume networking would have been mainframes and related hardware connected via leased lines.
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.
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.
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.
NOTE ON JAVA SUPPORT. THE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ONLINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Sun Microsystems, Inc. has contractually obligated Microsoft to make this disclaimer.
Also:
The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.
It would take a whole lot more context to make this somehow comforting. :D
This is this fascinating 6 part documentary about the Chernobyl incident explaining how it was caused by bad control rods.
If it ain't broke, don't 'fix' it.
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.
While true the situation is different. Hardware and software moved a lot faster in the 90's and early 2000's. Everything has matured 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.
Windows 2000 (NT 5.0) was released in 1999. Vista was NT 6, and released in 2006.
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
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.
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.
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.
Keeping old hardware running is very fragile. Most spare parts are decades old now too, and nobody knows if they still work properly.
ISA motherboards still work and have been mass produced in the hundreds of millions. (I have about a dozen in my retro closet.)
The esoteric ISA expansion cards would be the bottleneck, not the motherboards.
With a modern 4 GHz CPU, that means your budget is only 4000 clocks per interrupt. The context save alone can make it hard to hit 1MHz, and you really want to have your interrupt code pinned to the L1 cache because a few memory reads will blow your entire budget.
As nice as USB4 is, I’ve never heard anyone claim it has single-digit microsecond latency, to say nothing of sub-microsecond latency. The typically-quoted ~20 usec latency of USB4 limits it to around 50 kHz for an emulated ISA card.
At the same time ISA card will never reach 40Gbps throughout with CPU clocking at tens of MHz only or often less.
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.
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
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.
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, ...
https://wiki.os2world.com/index.php/OS/2_on_ATMs
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 suspect he could have found a way to use a newer computer, but if it ain’t broke…
The cost of upgrading to modern software and hardware is substantial, plus the learning curve for something I only do rarely nowadays.
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 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, …
To give you an idea of the complexity of the manufacturing lines, shutting the machines down and starting them back up again was measured in days. Upgrading them would be obscenely expensive, let alone replacing them, just in the opportunity cost of not making anything alone.
The last machines with dock port have 6th gen Core CPUs (Latitude E5x70), or 7th gen for Precision 7x20.
It is possible, perhaps almost a certainly, that the company did not own the source code for the application and could or would not attempt to rewrite it to work with a modern operating system.
This is a top brand name company, so it isn't like they couldn't throw money at the problem, but with the number of lines in the number of plants they had, there wasn't really any reason to not keep the old hardware running (sans Internet connection).
https://news.ycombinator.com/item?id=46849567