Why 16-bit DOS and Windows are still with us

Many people are calling for the abandonment of 16-bit DOS and 16-bit Windows compatibility subsystems. And trust me, when it comes time to pull the plug, I’ll be fighting to be the one to throw the lever. (How’s that for a mixed metaphor.) But that time is not yet here. You see, folks over in the Setup and Deployment group have gone and visited companies around the world, learned how they use Windows in their businesses, and one thing keeps showing up, as it relates to these compatibility subsystems: Companies still rely on them. Heavily. Every company has its own collection of Line of Business (LOB) applications. These are programs that the company uses for its day-to-day business, programs the company simply cannot live without. For example, at Microsoft two of our critical LOB applications are our defect tracking system and our source control system. And like Microsoft’s defect tracking system and source control system, many of the LOB applications at major corporations are not commercial-available software; they are internally-developed software, tailored to the way that company works, and treated as trade secrets. At a financial services company, the trend analysis and prediction software is what makes the company different from all its competitors. The LOB application is the deal-breaker. If a Windows upgrade breaks a LOB application, it’s game over. No upgrade. No company is going to lose a program that is critical to their business. And it happens that a lot of these LOB applications are 16-bit programs. Some are DOS. Some are 16-bit Windows programs written in some ancient version of Visual Basic. “Well, tell them to port the programs to Win32.” Easier said than done.

Why would a company go to all the effort of porting a program when the current version still works fine. If it ain’t broke, don’t fix it.
The port would have to be debugged and field-tested in parallel with the existing system. The existing system is probably ten years old. All its quirks are well-understood. It survived that time in 1998 when there was a supply chain breakdown and when production finally got back online, they had to run at triple capacity for a month to catch up. The new system hasn’t been stress-tested. Who knows whether it will handle these emergencies as well as the last system.
Converting it from a DOS program to a Windows program would incur massive retraining costs for its employees (“I have always used F4 to submit a purchase order. Now I have this toolbar with a bunch of strange pictures, and I have to learn what they all mean.” Imagine if somebody took away your current editor and gave you a new one with different keybindings. “But the new one is better.”)
Often the companies don’t have the source code to the programs any more, so they couldn’t port it if they wanted to. It may use a third-party VB control from a company that has since gone out of business. It may use a custom piece of hardware that they have only 16-bit drivers for. And even if they did have the source code, the author of the program may no longer work at the company. In the case of a missing driver, there may be nobody at the company qualified to write a 32-bit Windows driver. (I know one company that used foot-pedals to control their software.)

Perhaps with a big enough carrot, these companies could be convinced to undertake the effort (and risk!) of porting (or in the case of lost source code and/or expertise, rewriting from scratch) their LOB applications. But it’ll have to be a really big carrot. Real example: Just this past weekend I was visiting a friend who lived in a very nice, professionally-managed apartment complex. We had occasion to go to the office, and I caught a glimpse of their computer screen. The operating system was Windows XP. And the program they were running to do their apartment management? It was running in a DOS box.