As Windows Server 2008 end of life approaches, companies only have a few years left before the operating system...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
is out of support. After January 2020, Microsoft will no longer issue patches and the OS will be considered officially dead. When it goes, so too does our ability to run 16-bit applications on Windows Server.
The common wisdom is that companies still running 16-bit applications should "simply" upgrade, migrate or completely rewrite those applications. Even with four years remaining on the clock, this advice is ridiculous for millions of companies around the world
The inability to break from reliance on 16-bit applications has many possible causes. Application developers could be unwilling to provide a new version of the software. This is usually combined with there being no real alternatives available for that software: an issue common amongst industry-specific applications that address a narrow, but critical, niche.
The software may not have an active developer; many companies are utterly dependent on abandonware that was issued by a company that no longer exists.
All of the above is compounded by the hard reality that most companies can't afford to hire developers to replace the software in question. Many of the world's businesses are small and medium-sized, which are often cash poor. Even if they could afford to hire developers, most wouldn't know how to go about doing so.
What to do when applications need to talk to hardware
Keeping 16-bit applications operational in the face of Windows Server 2008 end of life depends on the uses for those applications. Applications that are tied to industrial control purposes generally need to talk to that equipment in some fashion. This can be done with add-in boards or through peripheral communications systems, such as serial or parallel ports.
The easiest thing to do is to ignore the requirement for a server edition of Windows. Client editions of Windows are capable of doing the majority of tasks that Windows Server can.
Windows 10 comes with a 32-bit edition, which should be able to run 16-bit applications. Compatibility needs to be tested on a per-application basis, and if you are using line cards to talk to your hardware the chances are good that drivers simply don't exist for Windows 10. If you are using serial or parallel ports, you can probably build a Windows 10 system that will work.
Another option is "nothing at all." OSes don't stop working because they pass out of support. Applications will continue to work after support ends. If you choose to go this route, there are precautions to take.
The first step is to assume that these computers are already compromised. Treat them as though they have every single virus on the planet. Automate bare-metal deployments to these systems. Get to know the application in question. Figure out what it takes to deploy that application from a script to a clean OS and load up configuration files.
Build a clean end-of-life copy of your OS, with all relevant drivers and basic applications installed and make a copy. Back up configurations and data for your applications regularly. Make sure you know how to deploy that clean image of the OS, drivers and application and inject the latest configuration files and/or data for the applications.
Test your imaging capabilities. Set up automated procedures to both regularly and randomly image production systems during off hours. This should ensure that the systems are not infected.
If your systems need access to the network, defend the systems. Put these systems on isolated networks and make sure the systems are isolated physically, not just isolated VLANs. Crossing VLANs is far too easy, so assume the attackers who will compromise your out-of-support systems will eventually figure out how to do this.
Put intrusion detection systems, firewalls and so forth in between the systems with 16-bit applications and the rest of the world. If possible, use MAC address filtering to restrict communications within your own network as well as IP address and/or DNS filtering to severely restrict any Internet access those systems might have.
Another possible alternative is DOSBox, which was originally designed to allow running 16-bit DOS games on a 32-bit or a 64-bit operating system. With some tinkering, serial and parallel ports available to the host OS can be passed through to the DOS instance in DOSBox. This probably won't work if line cards are used to interface with hardware, but a surprising number of applications needing only serial or parallel interfaces work just fine.
Similarly, using virtualization software such as Hyper-V or VMware Workstation may work. Again, certain hardware can be passed through to the virtual machine, allowing applications running in DOS or unsupported versions of Windows to access hardware. Windows Server and Windows 10 come with Hyper-V as an option.
Do not assume that just because an application is running in DOSBox, Hyper-V or VMware Workstation that they are automatically safe. The host OS still needs care and feeding, and if you connect the virtual instances to the network they will still need to be defended just as any physical computer running that software would have to be.
Run 16-bit applications in virtualized environments
How are 16- and 32-bit applications different?
Architecture differences in 32- and 64-bit Windows