Funny isn’t it how things seem to overlap. My previous musing was on Monkey Island a 16 bit MS-DOS game. It was just after writing that that I was flicking through Reddit when I came across a rather interesting post.

Who needs old software anyway?

The idea of running MS-DOS software or Windows 3.1 software today sounds totally weird, I mean why would you? For most office productivity software we have open source and commercial software which far exceeds what was available in the MS-DOS / Windows era. Maybe digital archaeology?

Having said that there are some industries which continue to run old operating systems and old software. Manufacturing is one. Often manufacturing equipment is controlled by a PC. The manufacturing equipment bought decades ago continues to work well and is still running on shop (factory) floors around the world. The software running on these machines is often decades old too. In fact for some machines it’s the software and PC which is the weakest link. If that breaks the manufacturing equipment stops working.

This is so much of a problem, that Linux Tech Tips (a Youtube channel) just a few days ago released video all about how popular Windows XP still is.

The Reddit Article

The Window I found on Reddit was from u/FederalPralineLover, a system admin at a manufacturing facility who was working on removing old Windows XP machines from the company network.

Windows XP, of course, is old, out of support and at risk of being compromised, it’s so much of an issue that Microsoft even has guidance recommending that you don’t use XP for browsing the Internet or opening emails.

16 Bit Windows Applications

However u/FederalPralineLover had an issue. They were asking for help in running 16 bit Windows applications in a 64 bit world. These old Windows applications where helping to support production hardware on a shop floor.

16 and 32 Bit Windows

16 Bit Windows Applications (Win16) are typically Windows application that were originally designed to run on Windows 3.1, and also IBM’s OS/2. The OS/2 overlap is a quirk of history, and interesting by it’s self. I may save that for another time. Win32 (32 bit Windows Applications) where supported by Windows NT and Windows 95. Today modern versions of Windows no longer support Win16, 32 bit Windows 11 will of course run 32 bit Windows applications, and 64 bit versions of Windows will run Win64 and Win32.

There is a legacy system called the NTVDM (Windows NT Virtual Dos Machine) that allows 16 and 32 bit DOS applications, and Win16 applications to run on 32 bit version of Windows. However, this is no longer support and Microsoft is actively telling customers to move away from this.

Ohh My Retro Assumptions

This desire to run old sofware overlaps kinda nicely with retro gaming, and computing, and a little bit with my day job, where I look at runtime systems for distributing computing platforms. I had a load of possible ideas - so let me brain dump some of the options which come to mind. But before I do, we should probably outline any assumptions. In the original post u/FederalPralineLover didn’t outline much more, other than the need to remove legacy XP systems from the shop floor. However I would assume that:

The systems running XP and 16 bit applications are directly controlling machinery.
The 16 bit applications will pre-date USB and will therefore be using serial ports / parallel ports to interface with the equipment. Yes, I know USB existing and it could be supported, but it’s unlikely.
I’m assuming that no proprietary ISA cards or other legacy interconnects are required.
If you are upgrading from XP, you will probably also upgrade the hardware; The author also mentioned the need to move toward a 64 bit operating system, and since most modern OSs require modern hardware, I’m guessing this is the case.
In this same vain I’m guessing getting legacy hardware which supports XP is also a concern. So moving toward a more modern hardware platform may also be a requirement.

Basically, we need to use modern hardware and communication to machinery over serial and parallel ports, we need to use a modern 64 bit OS for network security reasons.

Emulation Solutions

It is possible to emulate DOS and then run applications inside the emulator. This

16 Bit solution only

Assuming these applications are 16 bit only, either legacy Win16 (aka Win3.1) or DOS applications. Then you could run these applications via DosBox. - Yes you can install a copy of Win 3.1 in DosBox I’m not certain of the connectivity to Serial / Parallel ports, but I’d assume that would be possible. This would make the applications effectively OS neutral as you could run it on Win 10/11, or Linux / BSD.

Virtual Machine Solutions

There are a number of solutions where you could use a VM and host legacy operating systems with in. I’ve had luck with Virtual Box from Oracle, however I’m not sure - as I’ve not tried, if you’d have the same with Microsoft Hypervisor.

Virtual Box with XP

Aka “lift and shift”. If you are going to run a VM, you could just stick with the existing XP software stack. Stick the XP machine image in a Virtual Box VM and just run it on top of your chosen OS of choice. I’ve done this in the past when upgrading from an old laptop (Windows XP) to a new one. I simply took an image of the old machine and run it on the new.

Virtual Box with FreeDOS / MS-DOS

An alternative to DosBox would be to run FreeDOS in a VM. VirtualBox supports DOS operating systems. I have in the past tried to install Windows 3.1 on FreeDOS, but it just didn’t work. If I ever get the chance I will try that again.

An unusual choice - how about IBM OS/2 ?

OS/2 shipped with an internal copy of Win 16 (as mentioned above, this is long story). Allowing OS/2 to run 16 bit Windows applications, DOS application and OS/2 applications. There is a supported version of OS/2 called ArcaOS, this is a 32bit OS, but it will come with production support, handy for the mission critical work. Again, you could run this in a VM if necessary.

Compatibility Layers - aka ‘Wine’

Wine is a compatibility layer, essentially it translate Windows API calls to POSIX compliant calls and therefore should run on anything OS which supports POSIX.

Wine in a Container aka Proton

The Valve the games company have been working on a platform called called Proton which uses Wine. Essentially they are packing Wine inside a container along with the software application (a game) which they need to run. This bundled Windows Game + Wine compatibility layer can then be shipped to folks running Linux machines. There is an article explaining how a similar approach to Valve’s works is provided here. Not sure how mission critical / ready this solution could be. But it would be pretty epic if you could wrap almost any application up and distribute it this way.

Wine and WSL and Linux GUI applications on Windows 10/11 64 bit.

It is even possible to now run Linux GUI applications WSL on Windows 10/11. So you could run Wine on WSL and run a 16 bit Windows application on Wine on WSL on 64 bit windows… this might be a more appealing option, without the need for docker… bit of configuring to go, but this could be the way forward.

But again, it depends if the applications are console based (DOS), or Win 16 GUI (aka Win 3.1) based.

WineVDM

This is a Wine based project which has been designed to address this very issue! - It aims to allow 16 bit Windows applications to continue to execute on Win64 systems. To do this it uses a CPU emulator, it apparently uses hyper-v and to support DOS applications, DOSBox. When Windows detects the user is attempting to launch a 16 bit executable a trigger is fired by Windows allowing another process to intercept the request, WineVDM attempts to use this to allow seamless support for Win16 applications.

Original Installation ?

These solutions would appear to be possible solutions, I’ve not experimented with all of them. The little experimentation I have done shows that there are some practical issues. On the Emulator and VM based solutions you will probably need to original installation media for the application you want to host, and you are going to want to re-install it. For DOS Box we can just share a directory, for the VMs running DOS / Windows you might need to make floppy disk images containing the software, so you can trick the old OS / system into thinking your inserting floppy disks with the application on it.

Extracting the software

For existing software it should be possible to extract the application from a pre-installed instance on the existing machine. For most DOS applications, they are simply installed into a single directory. The same is basically true for Windows 3.1 applications, these will also install into a single directory, however they may store “ini” files in the Windows directory, of have some cross dependencies on additional libraries.

Software Performance

Of course it is not just emulation or virtualisation, but if this software is controlling a device then, potentially, any change in the timing of the software’s execution can impact the device it is controlling; a command sent to late, or too early, etc. Most of the emulation based solutions (Wine) related are focused on games and supporting games. There is concern that office software is not particularly well supported.

Conclusion

While the ideas above sound straight forward, implementing them could be a lot more involved than you think. None of the solutions are “production” ready, and none of them will support old extension boards (ISA Boards) that older PCs used to use, and which are not supported today.

The best solution today may well be to buy old hardware, back up these systems, and simply air-gap the from the internet. In fairness air-gapped networks are common place for most manufacturing systems.