This one is something I’m way too proud of, because it’s about as cursed as these hacks can get!
I used to work full time as one of a two-person IT department at a consulting company that worked with construction.
The owner of the company wrote backend business logic code nearly 30 years ago, in dBASE 5 for DOS, and switching to anything else was a non-starter. This code base was his baby, and he made it clear he’d sooner close up shop than rewrite it, despite the many reasons why it would have been a better idea than what followed.
When I started with the company, they were using computers running Windows XP, which shipped a 16-bit/DOS emulation layer called NTVDM, which was used to run this terrible dBASE software. This was after Windows 7 was released, and we knew that using NTVDM on our office desktops wasn’t going to cut it for much longer — only 32-bit Windows supported NTVDM, and most newer hardware was only getting drivers for the 64-bit variant of Windows.
Of course we tried DOSBox first, and it almost worked perfectly, but we were bottlenecked by a very slow network write speed even on a fast Core i7 at the time. This wasn’t going to cut it, either.
At the time I had been first seriously getting into virtualization, had gotten pretty good at PowerShell, and was intimately familiar with Windows’s RemoteApp functionality from a prior project. This was software that would serve any running Windows GUI application to a remote thin client. And when I tried it, an NTVDM-powered COMMAND.COM window worked just fine as a RemoteApp! Things were getting interesting.
I ended up using and using PowerShell + DOS Batch files to glue together a handful of tools to ultimately build extremely stripped down and locked down 32-bit Windows Embedded VM images, with just enough components to run these DOS applications and serve them over RemoteApp sessions. I basically built a fucking CI/CD system for remotely running DOS applications on thin clients.
The best part? Now this stupid DOS software that we couldn’t get rid of was even usable on Linux, Macs, and mobile devices. Despite it being an awful idea, we really gave that horrifying piece of software a new lease on life!
I no longer work there full time, but I still consult to them occasionally, and to this day they use this setup, and it still works super well!
It’s horribly insecure (though I think we managed to segregate that Windows VM and its access very well), and probably violates numerous EULAs, but it was just about the only way to keep that specific application in service…
(By the way, I’m looking for full time work at the moment if anyone needs a devops/automation engineer that can wrangle cursed environments… My email is hn(at)ibeep(dot)com.)
I used to work full time as one of a two-person IT department at a consulting company that worked with construction.
The owner of the company wrote backend business logic code nearly 30 years ago, in dBASE 5 for DOS, and switching to anything else was a non-starter. This code base was his baby, and he made it clear he’d sooner close up shop than rewrite it, despite the many reasons why it would have been a better idea than what followed.
When I started with the company, they were using computers running Windows XP, which shipped a 16-bit/DOS emulation layer called NTVDM, which was used to run this terrible dBASE software. This was after Windows 7 was released, and we knew that using NTVDM on our office desktops wasn’t going to cut it for much longer — only 32-bit Windows supported NTVDM, and most newer hardware was only getting drivers for the 64-bit variant of Windows.
Of course we tried DOSBox first, and it almost worked perfectly, but we were bottlenecked by a very slow network write speed even on a fast Core i7 at the time. This wasn’t going to cut it, either.
At the time I had been first seriously getting into virtualization, had gotten pretty good at PowerShell, and was intimately familiar with Windows’s RemoteApp functionality from a prior project. This was software that would serve any running Windows GUI application to a remote thin client. And when I tried it, an NTVDM-powered COMMAND.COM window worked just fine as a RemoteApp! Things were getting interesting.
I ended up using and using PowerShell + DOS Batch files to glue together a handful of tools to ultimately build extremely stripped down and locked down 32-bit Windows Embedded VM images, with just enough components to run these DOS applications and serve them over RemoteApp sessions. I basically built a fucking CI/CD system for remotely running DOS applications on thin clients.
The best part? Now this stupid DOS software that we couldn’t get rid of was even usable on Linux, Macs, and mobile devices. Despite it being an awful idea, we really gave that horrifying piece of software a new lease on life!
I no longer work there full time, but I still consult to them occasionally, and to this day they use this setup, and it still works super well!
It’s horribly insecure (though I think we managed to segregate that Windows VM and its access very well), and probably violates numerous EULAs, but it was just about the only way to keep that specific application in service…
(By the way, I’m looking for full time work at the moment if anyone needs a devops/automation engineer that can wrangle cursed environments… My email is hn(at)ibeep(dot)com.)