Hacker News new | past | comments | ask | show | jobs | submit login

Ah, I can relate. While not as old as these, all the interactive stations at my parents museum still run on ancient win nt 4 boxes connected via bnc. Guess who they call when one breaks again...



I worked on at a company that was running all their billing software on DOS with FoxPro (I was there in 2012).

We eventually "upgraded" them to a VM running OS/2 on a Windows XP machine (I wasn't able to get it working with DosBox or FreeDOS)...Management didn't want to give us budget to rewrite it in a modern language, sadly.


> ...Management didn't want to give us budget to rewrite it in a modern language, sadly.

I fully agree with the management. The problem with software developers of today is that instead of being engineers and getting shit done they are more like script kiddies trying to do cool 1337 things. There are some golden rules in engineering: never touch a running system, if ain't broke, don't fix it and don't reinvent the wheel - just use it.


I don't think I agree with that at all. There aren't security updates, older hardware becomes harder and harder to get fixed.

It's easy to say "if it ain't broke, don't fix it", but in effect everything is breaking all the time. Hard drives fail, processors burn out, security holes are discovered, and the more out-of-date something is, the harder it is to replace or fix. If there were periodic attempts to modernize stuff, the blow of this is less severe.

Example, I'm sure the people running the Target POS devices five years ago had the mentality "if it ain't broke, don't fix it", and it led to a huge breach.


> There aren't security updates

From the story i get that this doesn't matter as it is a single isolated DOS program they run inside a VM.

> older hardware becomes harder and harder to get fixed

I'm sure you'll be able to find billions of computers that can run OS/2 in a VM both now and in the future.


> I'm sure you'll be able to find billions of computers that can run OS/2 in a VM both now and in the future.

Fair enough, I probably could have gotten it working in DOSBox at some point as well, further increasing the compatible devices, but that still doesn't deter from the fact that no one really knows Foxpro anymore. It's hard to fix bugs in dead languages.


AFAIK FoxPro is part of the xBase family of database systems and while these aren't as popular as they used to be, there is still a lot of information about them out there (and they were meant to be easy to learn and use). There are even some open source implementations (Harbour). So it shouldn't be that hard to fix things, at least for a good programmer.

The hard part would be convincing said programmer to work on it :-P.


I'm surprised it couldnt be migrated to a new version of foxpro with minimal work.


There's a chance that it could have been; none of the engineers still at the company knew anything about Foxpro and none of us really wanted to learn it; typically I (or anyone else suckered into fixing stuff) learned the very minimum required to find a bug.

However, until we finally got sign-off to do it in a VM it was a pretty big pain to log into the DOS boxes and fix stuff, so we were even less incentivized to become competent.

Even we had ported it over to Visual Foxpro or something, it was discontinued in 2007, meaning it would probably still have problems now...more even, since I'm reasonably certain that I could have gotten DosBox to work given enough time, which would at least effectively allow permanent free "operating system" updates.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: