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.
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.
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.
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.
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.
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)?
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.)
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 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.
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.
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!
>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.)
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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 :-/
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.
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.
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!"
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.
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.
It's not DOS but my private school still uses an IBM 5100 to do payroll and record attendance.
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.
If it's still running I wonder what they are going to do about the year 2038.
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.
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.
It's _very_ hard to believe some company to simply "clone the mainframe" into chip. Mind sharing any link to this effort?
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.
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.
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)?
I find it deeply upsetting that anything important for a nuclear power plant is using an OS without protected memory.
Protected against what?
Just another program poking memory it’s not supposed to. Not even necessarily maliciously.
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)
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?
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?
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.
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.
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.
"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!
>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.)
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.
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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...
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/
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.
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.
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.
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…
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.
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.
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.
You can still get ISA slots on systems as new as Broadwell with an adapter.
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.
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
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.
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 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.
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?
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.
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.
I virtualized a bunch and they seem to work well. At one point, I even had Ultima running on one. =D
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?
The weird part was still using it into the 2010s.
Like most people who bought into the OS/2 hype, I bailed after 1.3.
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.
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.
>Anything with a parallel port dongle?
https://news.ycombinator.com/item?id=46849567