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.

My idea is a DOS emulator with a really thorough log of every DOS interrupt called and I/O port interacted with. This could then be used to automatically, say, insert rows into a sqlite table when the DOS app updates a .DBF file, or forward GPIB data to a modern USB adapter. I wanted to avoid low level/cycle-accurate emulation as much as possible, only adding quirks as needed to support the most popular business application suites.

It should work with Siemens MPI/PPI interfaces, but I predict issues with ex-Telemecanique (now Schneider Electric) unitelway realtime DOS driver which is extremely picky.

You can still get ISA slots on systems as new as Broadwell with an adapter.

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.

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.

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.

Put a proper sticker on, that can't be removed easily.

Does it have to be a XP box or is just keeping a serial dialup connection working the key?

Like most people who bought into the OS/2 hype, I bailed after 1.3.

The weird part was still using it into the 2010s.

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.

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.

If it were a newer version of NT I'd be concerned about USB media, but being NT 4.0 and not supporting USB it's imminently more capable of being air-gapped than later versions. (I recall a fun Ed Skoudis quote-- "At best, an air gap is a high-latency connection". Evidence Stuxnet.)

The auditor probably doesn't know nor care. "Every windows machine runs antivirus" is a checkbox item, zero thought involved.

Hello, my name is Lamer Exterminator, pleased to make your acquaintance.

https://en.wikipedia.org/wiki/Lamer_Exterminator

Also, in my experience, what the auditors think the rules are and what is written down can often be divergent and even contradictory

Sounds interesting, could you elaborate?

"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!

If it's what I suspect it might be, it was probably a generic IO card with maybe a bunch of 8255 PIOs on.

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.)

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'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.

Hardware is more amenable to static analysis than running programs which may receive an arbitrary number of inputs and express an arbitrary number of possible intermediate states.

I am interested in how firmware is treated, since perhaps in the case of these old machines it's small enough to be analyzable or at least cloned bit-for-bit.

Software "engineers" like to abstract things. This doesn't pay well e with reliability.

very apt that xerox parc was full of tenex engineers!

MAXC (maximum access computer), which was a complete emulation of the Tenex machines.

Compuserve also had a software dependency on the PDP-10 and Decsystem 20, and when those machines were no longer available they bought a company making clones so they could continue to manufacture them for themselves. The company they bought, Microsolutions, was Mark Cuban's first startup.

making clones of mainframes (IBM's) had been a big area of intellectual property litigation, but also facing monopolization investigations, IBM had to allow them. They were referred to as "plug compatibles".

Meh, old architectures are relatively simple and you can get 95% of those via fpga softcores (some freely available, some paid) and run them on fpga. The rest can be implemented by a proper ee team.

I mean...there's some precedent. The XKL TOAD ("Ten On A Desk") implements the PDP-10 instruction set, and will happily run TOPS-10/TOPS-20. LCM had one doing just that.

https://www.computerhistory.org/collections/catalog/10277383... https://www.twenex.org/?network

Situation: Software-1 on Platform-1, both certified.

Time-evolution: P1 is deprecated, replaced by uncertified P2, but S1 remains certified.. just nowhere certified to run yet.

Solution: There's another software S2 which originally vouched for P1, itself still certified, which can still be used to certify P2.

Counterfactual?: If S1 were deprecated in favor of new S3.. there'd be no plan to certify it!

The problem: None of this actually makes any sense! But we're trying to fake due diligence. Everyone knows the hardware/platforms kinda need to be certified with respect to each other anyway, but if we did it that way it would all be even more expensive an time-consuming.

That "just" is quite the load-bearing seam ...

Particularly when the task here is "just" to measure some rod positions in a constrained 3D space ...

Ovens vary greatly. There is no consistency in how even the heat is in the space, the airflow through the space, how much and how fast the temperature varies around the set temperature, etc. These things all do affect how things bake up and often people have to tweak recipes for their specific oven.

In a case where something is safety critical the computer is super important as very subtle errors could cause catastrophic consequences. This is why you get into things like running software on 3+ computers concurrently depending on how fail-safe something has to be.

It could be an FPGA. Given enough gates, and the know-how to program them, you can make an FPGA emulate anything. Speed and efficiency could be better or worse, but if you're targeting old hardware, better is likely.

Then their ancient Honeywell(?) mainframes...

https://en.wikipedia.org/wiki/GE-600_series from the 36-bit era which turned out to be a sweet-spot for Lisp; also "famous" for running Multics (old joke flipped: "which was many of whatever unix is one of")

GE sold it's division to Honeywell, and from there to Group Bull (French) and then to NEC (Japan)

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.

Not wholly apocryphal. The U.K.'s air traffic control ran, and possibly still is running, on an IBM 4381 substituting for an IBM 9020.

* https://news.ycombinator.com/item?id=49763972

They've reportedly already tried, and failed, to replace it with a more modern system.

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 AmigaDOS emulation will almost certainly never run another program. (-:

Far more concerning from a RISKS point of view is the spare parts being physically in the same place as the live machine.

Just another program poking memory it’s not supposed to. Not even necessarily maliciously.

What other program? Most DOS versions were not multi-tasking beyond "terminate-and-stay-resident" (TSR) programs like mouse drivers.

Whatever application you ran on DOS was THE application your computer was running.

You don't need protected memory if your program is the only thing running. Plenty of microcontrollers have no protected memory and get used in safety critical applications.

Set the date back to 1980 and sticky tape over the corner of the screen where the date is displayed.

You can only say such things with hindsight. In the moment, nobody knows what the future will hold. Take the space program in the US for instance. In 1969 we landed a man on the Moon. We'd repeat that several times until 1972. At that point Nixon made a speech which implied various unpleasant things about space's future, but he'd be out of office, disgraced, a couple of years later, so how big a deal could it have been anyhow?

I think almost nobody from that era would have believed you if you told them that more than 50 years later not a single human would have traveled beyond low Earth orbit, and that we'd now be struggling to recreate what we did in 1969. Furthermore a significant chunk of the world doesn't even believe we landed on the Moon anymore, no doubt in part because of this apparent anachronism.

It's not like there was any sort of collective or even singular decision to just let things die out. I mean sure Nixon did his thing intentionally, but even as a President in the golden years of the US, he was still just one man.

It’s the responsibility of the management to make sure the knowledge transferred to new generation.

That's just lazy thinking, and probably a sign you've never been a manager. For all the responsibility to lie with management you'd have to be leading people who enthusiastically do what they're asked to do, raise problems, document things, follow processes, and make sure everything is handed over to the next person when they leave.

That's not how people are. They'll have times when they're unmotivated, underpaid, grumpy, over-worked so they miss things, etc. That's when the organisational tech debt starts piling up, and there's nothing a manager can do to stop it except manage it as best they can even though they're under the same pressure, with the same lack of motivation and crap pay as everyone else.

It's so easy to think you can fix it just by keeping on top of it and micromanaging where it starts to show up. It doesn't work that way.

Basically everything collapses as far as it is allowed to, and the collapse is slowed only by:

- profit, if a system generates it, people will keep the system running.

- dilligence, usually driven by personal idealism, and unrewarded.

- legal or financial penalties, or insurance costs.

- it has collapsed to a temporarily stable state for now.

For another comment I was looking at the Grenfell Tower fire in the UK around 2017 and the people who lived there had been raising fire risks for years and the landlord (management organization) and the council had been ignoring them, and ignoring the fire department. The companies which replaced the cladding on the tower with flammable cladding were choosing the cheaper flammable option and pointing fingers as well. And during the fire, the fire service had never dealt with such a big fire and didn't have a truck with a long ladder, didn't have extended-breathing gear, had radio problems, water pressure problems from the local water company (who deny that).

This kind of backstory is typical for disasters, and for IT outages - and I've taken to believing that if something "should work" but wasn't tested recently then you should expect that it doesn't work. This is a common saying in backups (you need to test restoring), but it seems to apply everywhere. Backup internet connections that don't have enough bandwidth for the company to keep running. Disaster recovery sites that share resources with the production site. 'Disaster recovery' that recovered into a remote site, but they couldn't do CAD work remotely over their slow connection so it was still disastrous. Multiple power feeds but they were cross-wired so one failing still functionall took down everything.

If knowledge transfer "should be happening" but it's not critical to a job, or it's not profitable, or it's not legally required and audited, then it isn't happening. Subject to the dilligent idealist employee mentioned above who are temporary in the long view. Management's involvement seems not to arrange the larger system to effectively shoulder responsibility, but rather find ways to avoid personal blame while cutting costs beyond the point where everything that needs to happen keeps happening.

I think you can imagine the difference between “I did some work and made this thing that is clearly better, but we might have a few kinks to work out” and “I did some work, and if I did it perfectly, it’s just as good as the old thing, but we might have a few kinks to work out.”

Their 100 y/o hardware is built from stuff that's still produced though. We still make relays (not identical ones but ones that perform the same function), wires, and mechanical levers. The system's behavior is not encoded in the relays but in the connections between them. If you had a CPU made of separate transistors you could replace burned out transistors with any future transistors but if you had one made of chips you'd need those exact chips that were out of production.

Replacing the relays in old telephone switches is a problem because they use so many weirdly specific types of relays - but those systems are only found in museums now. I believe track control uses fairly ordinary DPDT, etc., relay designs.

OK, but the context here is IT I mission critical infrastructure, like energy or banking. These industries will not jump on the latest technology and will drag their feet for as long as possible.

A friend discovered that one of the more modern pieces of equipment instrumenting those old signals was an ancient WYSE terminal from the late 90s that had been bricked over during a station project.

They moved a booth or something and the compartment it was stuffed in was missed during the cleanout. The thing was working for at least 20 years and may still be there!

I worked with a client that had a cash disbursement system working on an ancient dBase 16-bit application. They had a very difficult to change process that required multiple transactions because the system couldn't represent the dollar amounts appropriately.

Why on earth wouldn’t the respective government spend money to modernize a critical infrastructure like a nuclear power plant?

Same reason they don't modernize health care infrastructure. It's too expensive, people die if they get it wrong and they get voted out of office for their troubles.

Now you know why making arguments from 20 year old anecdata makes you look foolish

Everyone knows that all technology newer than Windows 2.0 will never be obsolete!

Chernobyl was very much not "old", it was a more modern design than the PWRs which are built today. Chernobyl Unit 4 was also basically brand new, only 3 years old at the time of the disaster. The RBMK design dates from the 60s, whereas the PWR is from the 40s.

old outdated

Wikipedia's pages on Chernobyl say that construction started in 1972 and the problem with the control rods causing an initial spike of power was discovered in 1983 ?

[1] https://en.wikipedia.org/wiki/Chernobyl_Nuclear_Power_Plant

[2] https://en.wikipedia.org/wiki/Chernobyl_disaster#Accident_se... (search 'Ignalina nuclear power plant')

I can only imagine how much less reliable a modern JavaScript Electron app would be in this role...

Lindy's law:

For non-perishable things - i.e technologies, ideas, books, institutions - the expected remaining lifespan is roughly proportional to how long they have already survived

Time acts as a filter: what has already withstood a long stretch of disorder is more robust, so the longer it lasts, the longer it is expected to last.

The old nuclear software running on mainframes have passed the test of time. The new software, has yet to.

Nassim Taleb talks about this at length in his book, Antifragile.

There is no reason a more modern system would be better in any aspect.

It's interesting to think about this in the context of parent poster's story about the Amiga emulator in the nuclear power plant.

Or, more broadly, in the context of any situation where the software is closely coupled to a specific operating system and/or hardware.

Having the source code would have helped tremendously, but might not have been sufficient because of the hardware story and the regulatory approval factor.

I wouldn't rely on that for mission critical systems.

Unfortunately, “popular language/ecosystem” includes JavaScript and PHP.

I’d go for “universal and timeless”, which has meant C for several decades now. There is, I’d concede, a reasonable chance that Rust obtains that label in our lifetimes.

And as a result it's very well emulated, making it very likely that Amiga code can still be run in 50 years' time.

What is this industry, if I may ask?

I'd recommend not having it so dependent on the hardware and choose an OS that is relatively hardware agnostic (e.g. Linux). Also, ensure that the software is open source and if compiled, has an open source toolchain to do so.

Though people often decry it (due to the many, many footguns), writing something in Shell/BASH will make it trivial to move to newer machines.

Write it in C or Fortran.

run for ~50 years where the hardware will need to be replaced

If it needs to run for fifty years, specify hardware that has a long support cycle such as Mil-Spec.

That’s why the Z80 was around for so long and why so many companies in the 80’s and 90’s still deigned around it. (1)

If you let programmers drive system design, winding up with an “Amiga” in your certified design is a more probable outcome…

(1) there’s a moderate chance that new hardware that can run Z80 code will be around fifty years from now.

How does someone write software that needs to run for ~50 years

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.

Wasn't there some idea that went like "if something has been around for x years, it will likely be around for x more years"?

Maybe follow that. It's 2026 right now. What way of writing code would have worked 50 years ago (1976) that still works today?

Well, C, SQL and Lisp were all around 50 years ago and still exist today.

In terms of hardware, 50 years ago there was intel 8080. apparently code for that can still work via emulation today.

So if you wrote C for low level, Lisp for high level, and compiled the software to run in an Intel 8080 emulator, that combo would likely still work in 50 years.

To me the funny part of this story is that they used to show you this warning as part of the EULA when installing Windows NT 4, which I remember joking about:

NOTE ON JAVA SUPPORT. THE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ONLINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Sun Microsystems, Inc. has contractually obligated Microsoft to make this disclaimer.

Also:

The machine's purpose was to report status of the control rods that mitigate nuclear reactions. Basically, "are the rods inserted, and if so, how many / how far?". I want to emphasize that this was reporting only, NOT control.

It would take a whole lot more context to make this somehow comforting. :D

It is wild to me that you would use any GPOS for something like this instead of dedicated firmware for the task. This is evoking similar reactions to when I read articles about infrastructure being hacked remotely: Something must have taken a wrong turn with the architecture design for this to happen!

Just make sure that its well isolated from the Internet!!

Where do you find 2006? My googling says NT 6 was released in early 2007, so I meant that on Jan 1 2007, Win 5 was still current. https://simple.wikipedia.org/wiki/Windows_NT_6.x

It wouldn’t make a huge difference to me if 6 was released either 6 months earlier or 6 months later. In 2007, NT4 was only 1 major version behind for most people; adoption takes time. The broad timing of major versions being 4-5 years apart didn’t change until Windows 11, and we don’t know if that’s an outlier yet, but we do know that Microsoft has been changing the Windows release strategy, with more frequent updates. https://endoflife.date/windows

How on earth are these massive pieces of infrastructure relying on software they don't have the code to? i'm just utterly confused how these things happen.

That must have been a crazy moment for you when you first saw it and a big sigh moment for whomever had to explain it to you the first time. Thanks for sharing this; it made me smile!

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 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.

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/

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.

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.

I virtualized a bunch and they seem to work well. At one point, I even had Ultima running on one. =D

Until recently several customers have an industrial machine that boots DOS. I think the oldest effort we deal with is Win XP now. I do have a C>64 at home ...

In a world that requires security audits etc here's some notes that might help:

Scenarios: You have a device that only talks NetBIOS or even NetBEUI for file sharing. You need to get files to and from it and your CAD workstations run Windows 11 and anything less than SMB 3, with signing and sealing and all that jazz is laughable.

... Devices requiring ftp, telnet, serial over carrier pidgeon

Solution options:

Networking: The first job is to segregate your industrial gear from your general network and you might want to create two or more industrial gear and internet of things type networks with differing access policies. Start with one for now, you can improve it later.

You use 801.1Q VLANS logically or physically (why the hell did I want to write literally?) separate via separate switches.

Please do not skimp on this step. Buy a network bod to sort it out or put your IT bod on a course or hopefully they will have labbed this up at home already!

Comms: Samba is bloody wonderful and speaks everything that MS has ever done and deprecated. Even Samba does need to be asked to start speaking some of those dialects again but it will.

Put a Linux (other Unices are available) box on the same VLAN as your machines. You will need to set quite a few options relating to the minimum version for its server version. When talking to the machines, Samba is the server and when talking to your file server, Samba is the client.

Create a data share on a Windows box on the corp LAN. For example it might be on a file server for multiple access or just a single CAD PC.

Get the Samba box to mount that share to itself at say /srv/data_share_mc1

Now get the Samba box to create a share from /srv/data_share_mc1 which it calls DAT_MC1 (8.3 chars for NetBIOS)

With luck, you should be able to map DAT_MC1 on your machine.

I had it listed at this price for a few months, simeone from their company purchased it and rode 2 hours and half to come get it. Couldn't and had no reason to up the price at this stage. Indeed, this was a very good deal for them.

dBase, MS-DOS 3.x, not using industrial anything. And as its a front of house tally machine, there's literally zero incentive to ever upgrade it. Downtime is measured in the yearly reboot, but there are non-operational business hours, so everything is just scheduled around that.

We've already got it running on modern hardware. It's running under qemu. And the dBase stuff gets ripped out and sent to a REST server for broad monitoring and so on.

We... Have one small oddity? There's a tape backup system, that throws everything through the soundcard. (Sound Blaster only.)

Would be nice if onboarders didn't see dBase and just throw everything at AI instead of actually learning the skills they'll need when data migrations happen. But that's a people problem that can't be solved with tech.

I 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.

It depends on the gcc/llvm version.

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

Not as pure, but for what it's worth I've had success with a Syba SD-PEX50023 in applications where USB-based parallel port emulation failed.

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.

Anything with a parallel port dongle?

https://news.ycombinator.com/item?id=46849567

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.

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.

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.

MS-DOS or Windows 2003 running DOS vdm.

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.

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 :-/

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.

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.

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...

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?

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

I'm kidding. BRO, no school would be running the first (imo) commercial desktop still in the year 2026. The machine I cited was released in 1976!

I had a functional STA Compact [1] coagulation analyzer until 2022. It ran a customized DOS version on a ITX computer board that was integrated into the analyzer. UI was in text mode and used the keyboard only. It had no mouse. The video in the link shows the UI for a few seconds at the end. We kept it functional as a backup and even used it a few days when the replacement broke down. It was one of the best analyzers I ever used.

The newer version of that anaylzer, STA Compact Max [2] has mostly the same analyzer hardware, but newer ITX board inside. It runs Windows (XP, 7, 10...). Bugs galore.

I know labs that used a Beckman-Coulter HmX hematology analyzer [3] until 2015 or so. That machine is attached to an external MS-DOS computer via a very thick cable and an ISA board. The cable connector looked a bit like a 68-pin SCSI-3. The software used VGA graphics mode.

  [1] https://www.youtube.com/watch?v=Kti6Zdyp8dQ
  [2] https://www.youtube.com/watch?v=MJan25vkpEA
  [3] https://www.soriaudio.com/index.php?mid=m_eqp&document_srl=62138152

The Gear cutting job shop I worked for had a CNC lathe running with a GE Computer from the late 1970s that stored data on punched Mylar tape, until it was bought out in 2019.

The bevel gear generator setup was some formula calculations running in version 1 of TK!solver, which would have been a $5000 upgrade to get the latest version, so they ran them under MS-DOS in DOSbox, and saved the grief.

Without that software, they would have to pay Gleason $500+ to do the calculations for each new gear setup.

There are strong and reasonable reasons to keep very old systems alive in offline production environments.

i know still some accountant who use a DOS program to do his work because he hates the fact modern UI has load times. slows him down too much o.O (his program is all keybinds).

i do not have exp myself but i found it a delightful reasoning. i told him modern PC could also do the same on modern OS (ncurses or ratatui or so maybe) but that if he ask a programmer to make an upgrade he'd need to find the right kind of guy. He had someone do it few times but they came back with web interfaces.

Few years ago I was working for a F500 company and during an assessment we discovered couple of OS/2 Warp machines that were controlling CNC equipment

A Customer of mine has an 386 machine with an ISA interface board connected to an optical comparator instrument. I believe they also still have some MS-DOS-based computers connected to CNC machines, too.

I have two Customers who use DOS applications under DOSBox (a Clipper-based accounting package at one, and a Symantec Q&A-based application at another).

Would a Grease Weasel work for that situation?

FreeDOS exists, no need for AI:

https://freedos.org/

Not any longer. Back in the mid-2000s the company I worked for sold point-of-sale systems based upon a multi-user 4GL application (TAS Pro). Similar to dBase/Clipper etc., using the Novell Btrieve ISAM database engine.

With the advent of USB and SATA we ceased to be able to source industrial embedded x86 boards which could run the application. At the time this was with Novell DR-DOS, which was relatively modern in terms of hardware support but still behind the times and we were struggling to manufacture new systems. The company was very small, so a full rewrite was investigated--I did a prototype using PostgreSQL and Gtkmm--but it wasn't realistic. Today, an AI could probably do a full rewrite in a day or two, including migration tooling. Back then, it would have been a multi-year effort for one person given the application's size and complexity.

My solution was to run Linux since it had full support for the hardware. Debian Sarge at the time. This used a Perl frontend and dialog(1) to present a simple menu system at startup. This did backups, software updates (over dialup!), remote access for support (again over dialup), ran backups and ran the main application. It would start DOSEMU which provided the application with VGA display, COM ports and parallel ports for the application to drive "directly" (from its perspective). It also used Samba and CUPS to provide the DOS environment with shared network drives with exclusive byte-range file locking needed for the multi-user network database to work with concurrent users without data corruption, and also multi-user report printing and receipt printing.

I left the company a year after this was put into full production, but the last I heard it kept the company viable with a supportable product for many years after until its owners retired. This kept software from the early 1990s running well into the 2010s, and there are likely still sites running it to this day.

I've stumbled upon DOS on the LCD screen of the otherwise seemingly modern gas station.

Blind Control for the C-Suite?

I did, for a while. Then, I used VMs. I haven't had a Windows VM for years.

If I were a serious gamer (I'm not), then I'd get a hardware rig, but otherwise, I've not needed it.

I had a doctor that kept an original NT machine, for many years, because his bespoke app worked on it.

I bet most AI is capable enough now to migrate you away to some emulator for a few dollars.

And I would even bet that in most cases you could run a solution on a sub $10 board from aliexpress.

i don’t want to say this explains things, but i do want to imply it

+1 from me for relais technique. It is easy to replace, even in 1000 years. Today PLCs are great and fun. We can do a lot of cool things with them. Just with the short and shorter life cycles, sometimes even less than 10 years. If something breaks you have to replace so much stuff for a small broken piece. Thats such a bummer in todays industrie automation.

Let me assure you that Deutsche Bahn also still operates about 500 mechanical signal boxes, about 100 are from pre-WW1. Not these fancy, modern electromechanical relays (which Deutsche Bahn of course also has).

Not recently but when I was a teenager (2001-ish) my supermarket was using a DOS computer to handle stock, print new labels when prices updated each day, etc.

I've seen some older retail stores use DOS machines, ones where the owners are 70+. They just don't have a reason to upgrade what they're used to.

Not MSDOS, but I feel obliged to shared the story of an auto shop in Poland using a Commodore 64 to run the calibration and wheel balancing some years back. It was viral news at the time but worth sharing again.

https://www.youtube.com/watch?v=tXdLtnt-nvE

Original Polish article - https://www.trojmiasto.pl/wiadomosci/Warszatat-samochodowy-z...

if you really know what to do

The so called "load-bearing gap" you pay experts for.

You would think so, but most of the low hanging fruit has already been rewritten and replaced. The biggest hurdle is hardware lock in, ISA boards, hardware keys, or other hardware interfaces that can’t be easily connected to new systems. Never mind the problem of verification. That app that takes days to rewrite can annoyingly take months to verify.

Absolutely. And run faster, cheaper and safer.

Just as long as you still have all the documentation and the spec was done right and updated as things changed over the whole lifetime of the system up to now. And a good test harness. And industry-specific knowledge.

I don’t know the specifics of their systems but both of my local lumberyards here in SoCal still use DOS systems for their point of sale and inventory management, with slow dotmatrix printers and everything.

They simply have no reason to modernize. The one big benefit they’d have is an online inventory system but they make most of their money from negotiated bulk orders so there’s zero incentive.

Still have a liquid scintillation counter running on DOS with raw data printed on a dot matrix

Ah, that sounds like it's The Met, who have a bespoke electronic libretto system.

You're right, it is a bunch of LCDs on a bus (iirc rs485).

Couldn’t you install a cracked windows xp on any kind of machine essentially? Or what is special about “windows xp machines”?

Not DOS but we recently had to virtualise a Windows XP box as it was running crucial software for a visitor attraction. The software was written by a member of staff who sadly passed away and the PC it was running on was approximately 20 years old.

We managed to virtualise it and then run it in a VM, and it needed a couple of USB-to-serial adapters passing through as well.

We're also finding some kiosks are running Shockwave Flash apps provided by companies that are no longer trading. We can decompile the files to extract the assets but at some point it's easier to just replace completely.

I don't, but the abbey at the city I live has an ancient PC running a program from the 80s that controls the bell ringing.

I recall seeing it connected via a parallel port to a large board that then operates the switches/relays of the hammers.

2014-2017 I was supporting a clipper setup for issuing work order and many other tasks for an old civil aviation repair plant. I’ve ended up virtualising and moving it to a hyperv cluster. Definitely the case of “if it works, don’t touch it”. Also set up a closed network for CNC machines to let engineers in the shop send jobs over the net instead of running around with floppies or manually entering gcode through the console. Fun times.

An old story. I used to work for Fox Home Entertainment (CDs etc)this is 20+ years ago. And we had proper DOS running on old machines. We used it to do all our finances (including all of Japan, Asia sales). Most of the money we made on movies like Titanic were tracked on DOS. Until about 2003 if memory serves me where we moved to SAP. Why this was worrisome was how easily fraud occurred. In my tenure there $5-10M was stolen. At the time sent to companies in Brazil. I'm still surprised by larger firms where they keep these things alive to retain the data. CocaCola did it. A few large Insurance firms too. Crazy.

I do, for two clipper programs. But no extra machine, just a VM. Until not long ago, it was running without VM on 32 bit Windows 10.

Not now, but few years ago I worked on a toll that runs DOS because… yes.

Also worked ~2014 DOS slot machines - in next year we ported to Linux

One of our vendors is a contract electronic manufacturer (circuit board stuffer) that has a wave soldering machine running MS-DOS on a PC that's built into the control cabinet. It uses the parallel port to communicate with Opto22 industrial i/o modules, which then is wired to all the temp sensors, relays, etc. It just keeps working.

I know a shop that still runs an Apple ][: they have a Numerical Control machine. For those who don't know, NC is the predecessor to Computer Numerical Control, i.e. CNC machines.

They run on punch tape.

So this Apple ][ is connected to simulate the punch tape reader, and send the (I think) G-code commands to the machine. So it's now a CNC, managed by an Apple ][.

[Source: Was NT developer - have code in NT 4.0...]

The big problem will almost always be some hardware dependency that breaks, almost always in I/O. I've seen video software used by TV producers that depended on an ISA (not EISA nor PCI, ISA) card to read NTSC input and impose text over it. And it broke as they were getting ready to add commentary to a live broadcast of a race (which I was driving in.)

The world is full of machine tools and metrology devices that are stuck on some ancient computer/software because they made a weird proprietary protocol over the top of a centronics connector, or some other "WHAT were they thinking??" construction...

All of these could be overcome with a new I/O device, and/or writing a device driver. So using say a raspberry PI that talks ethernet to your "monitor" PC is probably relatively change proof.

If there is any documentation, if anybody can find said docs, if there's budget for a new I/O card and the device driver to go with it. Often the parties who have those resources would rather sell you a new machine tool, metrology machine, or I suppose, nuclear reactor (:-)

Of course, certification is a big deal... A particular certification structure led to the 737 MAX tragedies. And since certifying authorities don't always have detailed tech knowledge of what things are, they have a hard time saying "no, you can't slide that by, you have to build and certify a new thing".

AND more to the question - the contractor who remodeled my house in 2014 was still using some ancient DOS app, possibly running on a DOS machine or at least an emulator of one, to generate billing. Which was handed to me on paper....

(He was a good contractor, so clearly having the latest billing software is not the deciding factor in that.)

We have a client (a factory) I wrote a massive (for one person without AI) Clipper system for that runs the factory; this is decades ago but it just works and when they tried to replace it (not by us, but promises by others), it was worse and they did not switch. Cheating, but another client is a bank; they found its is really inefficient to not use DOS. Their machines use Windows but fullscreen DOS box you cannot close or minimize with the app in it.