@HelloRaptor said:
When it's getting to the point your program won't even run in a modern OS, and by 'modern OS' we're talking about things that became common a decade ago, it's time to look at more modern options and stop clinging to the familiar comfort of your old ass bullshit.
Spoken like someone who's never watched a dozen "modern" replacements come in at ten times budget (in both time and money) and still not actually managed to replace the system that it was intended to replace.
A decade? That's what you think is old and decrepit?
I've worked on systems in the '90s where the hardware was considered "old, but reliable" in the 70s. The software was a million lines or so of assembler. But it did its job (online flight route display -- yes, this was air traffic control stuff) and it did its job well. When I was working on it (supplying stress testing of the system via a PC that was, ironically, about 400× more powerful than the system it was testing) it was supposed to have been long-since replaced by a fancy "modern" system (<sarcasm>supplied by the incomparable competence of Raytheon</sarcasm>) that used actual chips as the CPU in a multiple-processor design with all the bells and whistles.
It wasn't replaced yet, though. The Raytheon project was already three years overdue when I worked on this older system. A "modern" system with, like, a dozen 68xxx processors, modern hard drives, etc. was still spending over 30 minutes to load the test database (the spec mandated about that many seconds!), took over 2 hours to format a 40MB (yes, M, not G!) hard drive, and generally performed every task worse than the ancient, 1974-era 16-bit minicomputer. The only advantage it had was a flashier user interface. It looked very pretty in comparison to the serial terminals used on the old OIDS system, so you had a much better aesthetic experience while you waited (and waited (and waited (and …))) to get its job done.
Replacing an old information display system written for a computer that had 128KB of magnetic core memory (and that only because of a hardware hack that doubled its capacity) and displayed screens full of information about 1KB at a time was 3 years (and tens of millions of dollars) over budget with no end in sight using "modern" kit that was literally thousands of times more capable in theory. The numbers looked good … until you started actually working on it. Then it turned out that the old system was actually really fucking hard to beat.
That's one system of many I've seen go that route. There was another one via Anderson Consulting that was supposed to replace the payroll system for the Canadian government (the PSCS – Public Service Compensation System) that went so far over budget in both time and money that the government, in a stunning exception to the usual means of doing business, actually cancelled the project and sued to get all payments made on it back. It was that much a debacle. There was another where an ancient CP/M-based Z80 machine running finances for a drug store got replaced by an IBM PC-based "solution" that damned near tanked the business. (I got my first computer from that drug store; it was that CP/M machine.) In the end they actually shut down the computerized system entirely and went to a purely manual system because they couldn't replace the CP/M machine and the "modern" replacement was such a dog it was impossible to use.
I know techies love to use the latest hotness, but only a dumb businessman listens to techies breathlessly talking up their grand future vision of modern hardware and modern software. If you have a system that works and does what you need, you don't replace it. You introduce a new system iff you have clearly-identified business needs that are not being met by your existing system. And even then, you probably start by having the new system only augment what you've got until it has proven itself and can be expanded to replace.