Hacker News new | ask | show | jobs
by drblah 1986 days ago
I have a fun anecdote involving DOSBox.

Back in 2012 I worked at a large manufacturing company. They had an old IBM PC running IBM DOS which controlled a vital system at the beginning of their production line. This machine had been chucking along since 1992 and now someone high up had been made aware that it could be a potential risk if this machine stopped working. It was therefore decided that this PC should be replaced/upgrade if possible.

After investigating I learned it communicated with a PLC through the RS-232 interface and ran some special sauce software from a company that stopped existing in 1995. Previous upgrade attempts involved virtualization, but that did not work since the program ran too quickly on modern hardware.

My solution was to copy everything from the old HDD to a new computer, install DOSBox and configure the serial port. The first few attempts caused some sirens and alarms to go off in the building, which was "exiting", but after fiddling with the emulation speed I managed to get it to work.

To this day, unless something drastic has changed, a billion $ company is running DOSBox in production (and I literally mean production).

Also, a side note. The old PC was still connected to a modem with a dedicated phone line. At some point it had been remotely operated through some kind of Norton remote control software. I made sure to turn off the modem and did not bring it over to the new DOSBox setup. Imagine if someone had war dialed into the machine... They could have caused a major disturbance and potentially started a fire.

6 comments

Where you got very lucky was that the plc or other weird industrial system was controlled over rs232, and not from a manufacturer proprietary 8 or 16-bit ISA interface card that comes with device drivers to load in config.sys, and requires direct memory access. Can only run on bare metal. Yes there's vendors for industrial motherboards you can buy brand new with ISA buses on them...

And that's before you deal with the rarity of an interface card that's literally impossible to purchase at any price today, so you better hope someone has saved spares.

If its an ISA card you can probably clone it yourself.
That's a hell of a lot more work than "install DOSBox".
How would you do that? Is this a thing now?
Yup, Home-Brew ISA Cards is a thing. There are people out there who have reverse engineered some to create clones, not only for ISA but for more modern buses too.
Does it have to be working to be reverse engineered?

Typically folks will go looking for these services after the device has failed :(

Seen someone recreate a Sound Blaster: https://news.ycombinator.com/item?id=25029727
on the same vein, in 2008 we have been contracted by a pharma distribution company to replace it's legacy ERP which worked only with DOS. To prove the new ERP is working we had to reproduce the reports from the legacy system bug for bug with the exact same numbers. On my linux workstation, I installed dosbox, a copy of their software and database, and made scripts that exported the data by printing the screen then compared the old and new reports. I did that till I got the reports right. proper TDD.
Love that approach!
There's some particulars in your story that sound awfully familiar- I think I might have been involved with the original installation. Was this company in New Jersey by any chance?
I did nearly the same but with FreeDOS, but it was a warehouse system with a IR Connection, so no emulation/cpu speed problems.
We had a Windows 95 machine running our boiler. I was about to go your route, but luckily, we got together the money to put in a modern control system. I was understandably a bit worried when the age of the machine was greater than many of our students. Also, dust and old hard drives are not good for the blood pressure.
Wouldn't it be easy to just rewrite the software if you leave the PLC?

That said, as long as it works...

Sure! Almost anything would have been a better solution. However, no one knew how the system actually worked, and we were on a shoestring budget.

See, the situation was that IT management, who officially had the responsibility for the PC saw it as a risk because we in IT were unable to do anything if the system died. But the production line management, who had to pay for the upgrade, saw no reason to do it because it was "working fine!".

Sure it was working fine, and had been for almost 20 years. But WHEN it would inevitably give up the ghost they would be completely hosed.

You must not be a programmer if you think it’s generally “easy” to “just rewrite the software”
For RS232 connected to a PLC I would assume it to be comparatively easy. Maybe it is not, but it is probably easier than for modern usb or network attached devices, since you can easily spy on transmitted data.

I would also assume that the PLC just gets some commands from the master.

Granted, these might be too many assumptions.

What are you going to do with just the transmitted data? That's just a tiny part of operations, when the machine is working correctly. What if something breaks? Do you know what all the possible error states are? What does the machine have to do if it gets an eg. "machine on fire" alert? Does your software even recognize the data sent by the machine, if it hasn't been sent before and correctly recognized?

Sniffing a protocol to reverse engineer stuff, is like trying to learn a new language by listening to conversations of a ground-level monitor and a crane operator.

You can download the program from a PLC that supplies the logic aside from labels and comments, if that isn't available anymore. Some PLC even supply the complete project, but that is unlikely on such an old device.
> Granted, these might be too many assumptions.

Yep.

Modern USB/TCP connected PLCs just encapsulate RS-232 data into USB or TCP packets, nothing else (for backward compatibility). Also there are encapsulation and decapsulation devices which enables archaic PLCs and other industrial devices to be retrofitted to more modern systems.

Moreover, the OP noted that emulation speed was at critical importance so, the code is CPU speed sensitive. Missing specs, missing company, missing source plus time sensitivity makes this endeavor very risky if not hard.

It might be easy if they had a detailed (and accurate) spec to work to, a good test environment that mimics the current production one sufficiently, and time/money for the required dev/devtest/qa cycles. It sounds like they had none of the above.