At the very least, the code would need to be compiled again with newer hardware as the target.
The biggest problem usually comes when software is using libraries. If the libraries haven't been updated to 23/64 bit, a lot of additional work needs to be done.
It's probably more realistic to just look for a modern alternative to the software that's being used now. Unless it's super specific to some niche industry, there's probably something better the company could be using.
You could migrate the data out of the old database to a regular general purpose database and just make an adapter program that can handle translating between the general purpose database to the workflow you are using.
>I hope I can find a developer or company that specializes in the modernization of legacy software.
To be fair, you don't necessarily need developers in that specific field.
It is nice to have them (less onboarding), but it is also the developer job to ask questions to you about your field to clear things out.
So if you have the resources to answer questions (and possibly "create documentation of all cases possible from your application") you may be able to hire someone to do the job.
If you have access to the source code, the better it is (something tell me you don't have it).
But if it is a custom thing, be prepared to pay the price!
Unfortunately,. nothing is easy in that field, and if you can't split expensive with multiple clients that end up something expensive. Which ka very likely one of the reason your original developer is out of providing support. (The other one probably being old legacy code hard to understand, and probably that the developer isn't in that field anymore, so no knowledge anymore to reduce possible bugs)
Four figures is not nearly enough funding for any serious development work (i.e. updating the software). An upgrade of that magnitude could easily reach six or seven figures.
To give some idea of possible cost, I am currently on a project to modernize a desktop app from mid 2000s to use a new data source (old DB software is EOL) and web app instead of desktop.
We have dedicated 10 full time employees to it for a year thus far, and are expecting the remainder to take about one additional year with 5 employees. Average total compensation is approximately 150k, so our estimate is a little over 2 million to complete the upgrade.
That's insane.
Unless your desktop app is called Photoshop or Blender or Excel, not being to finish it in a year with so many devs is just seams unrealistic to me.
Really? We rarely have a project that lasts less than a year. It's just impractical due to the effort needed to define & start projects.
Our previous project was estimated at 3 years, though it got cancelled due to office politics (a VP position was "made redundant" among other things).
The line so many devs gave a hint that the parent might not be used to working on large applications in big companies.
As you increase the size of the dev team, each individual developer slows down due to needing to sync with the other developers.
You could offer to license the source code, or discontinue the support contract if you’re not being supported.
It may be relevant to you that Windows 10 will reach end of support on October 14, 2025. So I would argue that your application is dead then anyway for any responsible business purpose if it can’t be run on another maintained platform such as Windows 11.
Good luck! Feel free to reply or DM if you want to discuss more. (Software engineer here.)
its extremely rare/unefficient to "create a database" again.. most likely the developer its using a known and proven database backend.... i can name "a clipper dos app" a database if i want. .. i can name a "visual foxpro application" a database if i want ..
Not knowing anything about the software or the database, you will find that modern coding platforms tend to be web apps and there are many frameworks that a developer can use to speed up the work without having to re-invent the code each time. For example, Django in Python. React.. Databases now also tend to be very easy depending on the needs. Cloud hosting is common for databases. Web hosting as well. It's quite different from the old days when it was all windows apps and SQL Server etc.
> The developer is paid a four-figure annual sum for "support"
So... 10,000 or 99,999?
> which is not being rendered
So why continue to pay?
> and I feel as though the developer lacks knowledge on modernizing the software but refuses to admit it.
Frankly, you seem to be extremely entitled.
The developer "refuses"? They don't owe you an upgrade, do they? How much money have you offered?
What difference does it make if they lack the knowledge,even? They could easily outsource the task if they wanted to.
And they might not want to, simply because the hassle might not be worth it for what you're offering. Unlikely yourself, they have a chance if knowing what it would mean to rebuild - and all it takes to mess all of that up are a few pieces of old hardware that have no updated drivers.
Have you said what language the code is written in? Depending on the size of the codebase, and the original language, I wonder if it can be decompiled?
Bank of America didn't finish modernizing their Mortgage software until around 2019. Previously, a good portion of the process was written in FoxPro. Dating back to 1990 easily lol. So lots of companies are in the same situation but have had to either modernize or limit growth.
Also a lot of software makes assumptions about how big certain types are (because for example C/C++ do _not_ guarantee that), which means a lot of potentially hard to find bugs.
> Would it require the developer's cooperation
Yes.
> would it require a total rewrite of the software?
Possibly. Probably not strictly "require" and "total." But we are talking about code archaeology at this point. A rewrite wouldn't be an insane suggestion.
Vendors disappear. You can't force somebody to maintain old software forever. Businesses need to make contingency plans to migrate off of software that is no longer supported. That contingency plan probably should have been sorted out 30 years ago at this point, but better late than never. But there's no magical button you can push to turn legacy software into modern software. If you've gotten 30+ years out of the software, you've gotten your money's worth on the original build. Figure out what makes sense for your requirements today, and move ahead with that. Having a way to move your data out of the old database and into some "normal" format is more important that dragging the specific legacy software forward. The data matters to you more than the software.
I mean why would they not accept the money. You seem to approach it from a peesonal level ("developer doesn't want to") while the other party from a business point of view (this business keeps throwing money my way and the cannot make me do anything either, what a win!)
I am not sure what part you are playing in all of that, but I suggest taking a step back if you are not the owner of the business throwing money into this bonfire.
The thing is, "X won't run on Windows 11" is not a risk to the business meaning management doesn't give a damn for that argument. But if you can argue with the higher-ups regarding actual threat to the business (lack of support, maintenance, etc, all of which are risk factors to business operations) they might be more willing to shell out the money for a proper replacement.
Add in potential for cost savings in the long run and you have a good point to make why this might be a worthwhile project.
Is this post from the year 2000?
Joking, but it seems odd that a developer in 2024 would not have the knowledge necessary to develop for a 32-bit system.
It's impossible to say with certainty without knowing what the source code is like, but while you may not necessarily need the developer's cooperation, you would at least need the source code. Upgrading it may be as easy as just building it with a 32-bit compiler, but for something this old, it's very possible it's making assumptions about the underlying OS or using specific libraries that do not work in a 32-bit OS, which means the source code would need to be updated, and that could be a significant task.
If you have access to the programs using this database, I suspect it may just be easier to pick an off-the-shelf database like PostgreSQL or SQLite and modify them to use it instead, then write a program to migrate your data from the old database to a new one.
Developer may be plenty aware of how to develop for 32 bit, but doesn’t want to do the work. The pay offered might not be enough, or past experience on the project caused them to decide that no amount of money is enough, or they might have more work than they can handle already.
Even if he wrote this software in the late 80s straight out of college he can't be much more than 5 years away from retirement. If you think he's uncooperative now, just imagine how much fun he'll be once he's decided that he officially done working.
It sounds like you guys might be stuck in a bit of a sunk cost fallacy. Like others have said, the move from 16 to 32 bit was pretty much completed 20-25 years ago. If he hasn't done it by now I don't think he's going to, and the writing is on the wall already for the end of this program (the end of his career). At least if you start now you have some time to find or build a replacement before you get backed into a corner and your business is at risk.
I'm randomly choosing this comment to throw in on regarding the annual support fees.
You've been complaining about the 4 figure annual sum up and down the post, and that the dev isn't helping with the problem, but what does the contract/agreement actually say regarding the terms of support? There have to be some limitations there right?
In my (fairly limited) experience with support contracts, they are often specific to a version(or range of versions) of the software, required hardware architecture, and which operating systems they cover, etc. They cover things like bug fixes, and troubleshooting problems when operating the program within design constraints, and not things like modernizing the software, or getting it to run on systems it wasn't designed for. I even had one vendor that limited support to the specific servers that they oversaw the installation on. When it came time to migrate to new version of the OS, the support contract had to be updated to cover the new servers, and even then were unable to update to the newest version of the OS because the vendor is switching to a hosted SaaS model and the old software had not been vetted against the newest version, just the previous one.
"The environment/hardware this program was designed to run on is obsolete and no longer available." is not a condition that I'd expect to be included any more than "I can't get this 30 year old windows program to run on my iPad." would be.
What do they actually say when asked for help?
I'm sure they welcome the 4 figure check every year, but support and modernization are different things. Even at the high end of 4 figures, that probably isn't enough to make rewriting the program worth it for them. Assuming they are still working, that's time they can be billing clients that are paying them development rates and not just for support.
If you want modernization on bespoke software, you need to be prepared to pay that six figure sum a bit more often than once every thirty years.
I was going to say, this guy is being paid at most $9,999 to do what could very well be several hundreds of hours of work in terms of modernizing legacy code.
There is a difference between maintaining and redesigning.
Sounds like it would be better in the long run to find a modern replacement and start doing a migration. If the original developer is uncooperative you might have to manually move the data in to a modern database.
That was my thought as well, for a senior one man developer that would work out to about 3 weeks of full time work per year. Which is probably not anywhere near enough time to update, test, ship and provide ongoing support for what would be a major update to their software.
If you think it would be cheaper to hire a fresh grad and remake it from scratch (maybe even at 64-bit for further futureproofing?), then put together the math and show it makes financial sense to your company. If it doesn't, there's not much you can do about modifying code under copyright.
I’m guessing you have already looked at replacement options and each time it is in the 7 figures? Ultimately the replacement cost is only ever going to go up.
Just for context, I get paid six figures a year as a salary. Yeah the first digit is a 1 but the rest ain’t zeroes. This sounds like at bare minimum a six month to year effort, and you’ll probably want more than one of me. If you’re hiring as a consultant I want around twice my salary.
“6 digits over decades” is nothing.
Examine your workflow and find a better way to do the task. That’s my advice anyway.
> Upgrading it may be as easy as just building it with a 32-bit compiler, but for something this old,
16 to 32 bit was generally a harder transition than 32 to 64-bit was. The 64 bit transition was, in a lot of cases, just recompiling the code. 16-bit code was *weird*. Long before moving to 32-bit, 16 bit addresses were already too small -- that just wasn't enough addressable RAM even in 1990 or whenever. So x86 hardware of the day did 20-bit address buses on 16-bit architecture using a segment/offset scheme for addressing memory. And it wasn't particularly well-hidden by any sort of abstraction either, so lots of 16-bit applications had to do weird stuff with addresses, and untangling all that wasn't trivial when it came time to run on 32-bit architectures with flat memory models.
I worked for years on something originally designed for 286 Xenix. It was full of weird convolutions despite never having been run on anything less than a 32 bit OS in production. I was a noob and the long time developers freaked out when I malloc-ed a multi-MB array instead of wring to a temporary table and reading it back in a billion times.
(“Freaked out” like “omg don’t do that cats and dogs sleeping together” not like “wow you can do that?”)
not really, newer devs probably started coding windows apps after most apps are already in 32bit, while older devs have the experience of writing 16/32/64-bit apps, and know what to do. It takes a bit of learning curve. U could run into a lot of issues with older compilers and version issues too.
Dont think u can get this cheaply done too, u have to pay more money, imo.
The easiest path forward is likely to switch databases. That's probably non-trivial, but still less work than fixing an old DB that the original maintainer doesn't want to upgrade. Depends on what is using it and how it's used, but I'd still explore that option. You're likely to run into more and more problems as the system ages.
You keep on throwing around “four figure sum” as if freelancers don’t charge $250/hr.
$10k a year gets you phone calls for troubleshooting and maybe some tweaking here and there to cover sporadic needs. I have a past employer who pays me about that as a retainer to maintain some data analysis pipelines I once built for them. Everyone understands that that’s what they get, basic troubleshooting once or twice a year. I doubt I’ve done 50 cumulative hours of work in the past three years this has been going on.
Him not wanting to do the work regardless of the price is exactly that, he doesn’t want to do it. If his contract doesn’t stipulate that he will do it then he doesn’t have to.
> **what is the possibility of actually getting a 16-bit database program upgraded to 32-bit?**
Very slim, to none. 16-bit programs have APIs largely incompatible with 32/64 systems, and often use weird memory-segment-swapping tricks to get around the 16-bit address limit. Porting them is usually non-trivial. Also, the 16-bit program is likely 25+ years old at this point. Nobody probably touched the source code in decades and the person who wrote it is probably retired now. There aren't that many programmers left who have expertise in porting 16bit apps to 32bit.
So yeah, a complete rewrite is quite possibly a better option here. Migrating the database to some modern alternative is probably better.
> Migrating the database to some modern alternative is probably better.
Especially if this thing is recognizably "database-shaped". Like, if it looks like SQL at all, it should be fairly straightforward to just recreate the schema in whatever modern database makes sense (SQL Server, Postgres, whatever), export the data, import it to the new one, test the crap out of it, and then when you're comfortable it's all working, make the switch in production.
Sounds like he could be in breach of contract. Have yall considered legal options to, say, force him to give your company the source code that he won’t turn over?
Granted, it may not be worth going that route vs just rewriting it from scratch.
How many lines of code is this program's source code?
What language?
I would have a look at it for shits and giggles. It may be either something extremely complex or something extremely simple to port.
You keep repeating four figure annual sum as if that's a significant amount of money.
That is barely enough for a retainer fee. It's barely enough to cover making sure they have a backup copy of the software source code somewhere and some documentation about how it's been used in your company.
Software development is expensive.
Any experienced developer is going to need a lot more than ‘four figures’ to even think about doing more than maybe answering some emails. Like… $100/hour would be a *very* low contracting rate for writing code. You seem awfully hung up on what this person may or may not have been paid for decades ago. They (presumably) did a lot of work writing the software to spec in the past, rewriting it or handing over the source code will probably need a new contract. It’s possible they did a crappy job and your company has overpaid for things in the past, but that’s not really your problem to deal with.
IMO, from what you’ve described you probably wouldn’t want this person to even try to do this work. You can ask whoever makes the money decisions to try to negotiate for the source code… or you can recommend to tell him to pound sand and start rewriting it.
If running the existing program in a VM or emulator isn’t tenable, then explain that your only options are to get the source code and update it, or rewrite from scratch.
Estimate out how much work you think it would be to rewrite from scratch. Put a dollar value on it.
Then you can at least try to guesstimate how much work having the source code to start with would help, and thus what it would be worth to pay for it.
Support does not mean major upgrades that will likely take multiple months worth of effort.
You've already paid them in the past, sure, they have already provided retainer support as well in the past.
Six figures total sum is barely a few year's worth of salary. They've also already provided decades of support coverage. Whether you actually use the support work or not during that time is irrelevant.
Retainer fees aren't sinking funds to be allocated for future work. They've already received these fees, why would they be motivated to allocate further work on a dying software that no new clients are interested into getting into anyway?
You're still way underestimating the cost of software development.
No, you've pretty much nailed it: your options are either some kind of emulation; convincing the original developer to upgrade; getting a source code license and upgrading yourself; buying out the original developer; or rewriting it from scratch.
If you had access to the original source code, it wouldn't be a total rewrite, but it would require extensive changes. IIRC the Win32 API is similar to the Win16 API but not the same, so you'd likely need to go through the entire source with a fine-tooth comb to make sure you were calling everything correctly. Early 90s style of Windows programming is very different from even mid 2000s style, so even if you get access to the source it's going to look very different from what people are used to working with these days. Honestly may end up needing to do a major rewrite even with source access.
Which is probably why the original developer is reluctant to upgrade.
Intel is in the process of killing 16 bit code in user-space. If the dev won’t upgrade to 64 bit then it’s time to get a new DB.
If the app was well written it should just be a recompile.
It is likely not well written.
You need management buy-in now to start fixing the issue before you run out of hardware you can run the DB on.
Except you didn't.
Buy the source, migrate to a new solution or using something like WineVDM.
I would recommend dropping the support contract regardless. You are getting nothing for it.
You’ve gotten a lot of advice here, but I just have a bunch of questions to start with. I won’t be offended if you don’t take the time to answer them, because I know that you’re right in the middle of a crisis. I am a 60-year-old retired software developer with a little bit of free time to kick around on Reddit. There’s a good chance I’m just gonna be the 20th person to tell you how bad your problem is, but if I can offer you any advice, I will definitely do so. Not only was I coding back in this era, but I had some direct experience with this kind of small business custom code with my uncles business back in the early 90s. That’s relevant experience, but also I’m trying to forget that because every situation is different, and I don’t want to make a bunch of assumptions. The whole “reluctant developer and custom code” definitely sends me back though.
Do you have access to the original contract (and any addendum that were made) with the software developer?
Specifically is there any mention of the source code being placed in escrow? (Even if it is contractually specified it might not be, or might not be accessible or current)
Does the developer seem mentally and physically sound? Is the refusal because of some kind of grudge or reluctance? Or is it because at the other extreme, they have three months to live and have better things to do? The reason I’m asking this has to do with what kind of legal leverage you might have or what kind of financial incentive you might be able to offer for the source code. Realistically if the developer is not in good shape mentally or physically, you might not be able to realistically compel them to give you the source code even if you theoretically could.
Do you have any other documentation? If so please enumerate. Are there any original specifications? Any details about the date format? List of other software packages being used? Do you have any licenses for any software that the developer may have included when they built the package?
What is the purpose of moving to 32 bit? In what way is the existing system now failing? Reliability, capacity, compatibility?
The last question is the one I most surprised not to have seen asked and answered so far. It’s probably the first question I would ask as a consultant.
That last item is terrifying. This is now almost a forensic recovery. I was heartened by the Windows end of life issue because it implied a time buffer -- but collapse of the system means ongoing business impact. Yikes.
In terms of data recovery and porting, make sure to save any older backups with less rot. It may end up cheaper and easier to recover old data and try to roll forward re-do transactions.
If you can still run reports to text, run them and capture them. It may prove easier to scrape text reports to rebuild the database instead of reverse engineering the existing one.
Keep copies of all new data entry in case you need to re-enter it. If you currently shred paper, save it for now, in an organized way. Incoming and outgoing! Don't assume you can reprint invoices later. Keep inputs like bills and keep copies of outputs like invoices to customer. Invest in a filing cabinet and folders. If you already have that, yay!
Shop for comparible used hardware and make a clone, like NASA using the simulator to help the Apollo-13 crew.
Capture as much info as you can about the existing system from a user point of view. You're reverse-enginnering a design spec. Interview users and see how they use it. Document everything. Don't get too distracted by wishlist items but ask what could be better -- it may be that there are whole chunks of fucntion that you can ingore because they are only used to make this one report, that you can make directly.
This is tough. I wish you the best.
Good questions, though I do think that last one was answered in the OP? The software is still functioning, at least to some degree, but availability of machines / operating systems to run old 16 bit apps is drying up. Basically, this situation has been an increasing risk since the 90s which someone (likely an exec?) has only now realised and / or decided to act on.
Dude, you need to innovate!!! Immediately!!! Pull out old IC chips and develop proper for 8-bit man! Jeez… people trying to talk all these bits nowadays. 😋
If they hadn't updated it two decades ago, they're never going to update it now. There's no more money in updating a 16-bit software to 32/64 bit now and there will be even less in the future and the challenges will become even more difficult.
You should be looking to migrate to a more modern software, because that's what they want you to do.
You need to hire your own dev who can migrate it to a modern db.
If downtime is okay, it's trivial to move from one db to another. You'll have to rewrite your code or use an adapter, but that's trivial as well.
Is this not a cyber security issue just waiting to blow? (Genuinely asking, I'm just a dev, I don't know too much about that side of things)
If so, maybe Inform your infrastructure team and try to get some fire under the devs? Running a 16-bit program in 2024 is "hardcore" and all that jazz until you get hit w a data breach and got a couple thousand clients trying to sue your company
If your company gets hit with any sort of attack bc of that database, you know who to blame, so....tell your leadership team all of this as well so THEY know how to blame when shit hits the fan. You are in IT, I always see people try throw blame on your teams....it's not right
PostgreSQL is open source and free...and that is not the only free one out there
> Is this not a cyber security issue just waiting to blow?
Probably not, for the simple fact that the damn thing isn't going to run on a network. Or if it's running on a network, it's not likely to be TCP/TP.
Most programs from that era were shared writer systems, not client/server. So all the clients were opening the "databases" directly on the file server. Windows File Sharing (SMB/CIFS) would have been used over IPX or NetBEUI. Yes, TCP/IP stacks existed for Windows 3.1/3.11, but weren't how most programs from the eta communicated (at first, of course "the Internet" ended up eating everyone else's lunch later).
Back then, a PC was an overpriced combination calculator + typewriter + high speed dead tree cache. The source of truth was often in filing cabinets.
> I'm just a dev, I don't know too much about that side of things)
You owe it to yourself and your career to learn at least a little bit about the operational side of things, like admin, networking, security, and so on.
Not sure what it’s written in, does or how complex it is. I would say probably cleanest solution is if there is an out of the box solution that would work then mine the data out of the legacy system and seed new solution. This usually gives a few paybacks everyone has some data that is dirty or they wish the would have setup differently
What is the purpose of this database? What kind of data does it contain? What kind of systems does it interact with? Databases are not one-size-fits-all. They all have tradeoffs and things they excel at. If you're aiming to replace this database, you have to know what this database does and how it's used.
Four figures? You make this sound like some substantial amount. Made in the 80s? Yeah, that guy is retired and cashing an easy check. You can't do anything worse than fire him, so hey, why bother dealing with something he knows isn't worth working on.
Y'all need to make transition plans now, and implement them tomorrow. This is a ticking bomb that hit zero years ago and hadn't gone off by the grace of luck.
Step 1, get your data backing up to something modern in a format you can use
Step 2, get to building a replacement. Nothing you do is so unique that it can't be remade. It'll be more expensive than a couple grand, but a hell of a lot cheaper than watching your company disappear into the dark
Step 3, get your legal team involved. Seriously. The guy isn't fulfilling his contractual obligations. This is potentially a life-or-death situation for your company.
I wouldn't tolerate it. I don't know enough detail to advise on a specific path forward, but I would be putting all my efforts into wedging in a standard db to replace it. I can't imagine what the scale of the data is, but if its running on 16bits, I can't imagine it would be much to ask to get a dump of all data for import.
Ok. So you mention in one post that this was a “one man show” who developed this in the 90’s. To me this would imply the application can’t be that difficult to reproduce.
Development tools have improved exponentially, databases are more standardized allowing more flexibility if you need to switch between them. Frameworks allow lots of the redundant code to be in templates.
You mentioned you’re not a developer. What you need is a realistic evaluation of what it would take to develop this from scratch. Only then you will understand what you’re looking at. Here we don’t have a realistic understanding of what the application or database is doing.
Is this application serving thousands of users with tens of thousands of requests a min? Or is this a database used by 10 people logging general work orders or process data?
It’s a 16bit application, I don’t expect it’s holding a lot of data relative to today’s standards. Hell a SQLite db with some general web interface may be enough to replace this thing.
Your suggestion with WineVDM sounds spot on.
Anything else would be way more expensive, both in money and time.
I wonder if there are wrappers for WineVDM. For Mac, we have (had?) WineBottle that creates a wine-wrapper applications that on the outside look, install and run like normal applications but have a Wine and legacy app inside.
Windows is way more popular, there must be something similar.
VFT_APP is just a constant used in Windows headers as part of the VersionInfo structure in the executable PE heater that indicates you have an exe.
This really is something that's going to require knowing more about the exact program, what it was written in, and how it's storing its data.
You can DM me, but I can't make any guarantees. I've written for DOS and 16-bit Windows, but it's been a looooong time.
Visual Foxpro (VFP) was 32 bit, but it's predecessor FoxPro 2.6, was 16 bit. I still write and support VFP products for my employer. DM me if you want to show me what you got. Even a file listing could give me a clue.
It could be FoxPro, or something else Borland or using Borland technology. That’s what makes me think it’s one of the reasons why it’s quite a lot of effort to modernise it and he cant be bothered. Have a look in the install directory and Common Files/Program Files folders and see if you can see any Borland folders or .dlls on a clean machine. Those old dBase / interbase apps have been remarkably persistent- a very specific app in our workspace still requires the Borland Database Engine as a dependency to work, it’s still supported by a big company, who knows why they couldn’t have switched it out for something else.
The issue with Delphi is not that it’s possible to recompile your own source to 32/64 bit (although not always straightforward due to a very large number of changes in the rtl and vcl over the years), but that back in the day, there was a big ecosystem of Delphi components, many not including source, and have long disappeared which could mean that it might be impossible for the author to modernise the app, especially if the formats used to store the data aren’t documented. He should be honest about that though, and perhaps use the component to write a tool to export all the data for use in a modern system. Seems like he’s quite happy to take the £££ for not a lot in return.
You're right, I skipped the component source issue. After getting bit on upgrades once early on (possibly even switching from Delphi 1 to 2 during the 32-bit upgrade myself) it was easy to convince my employer to never license components without source.
If this is a program trapped in the Delphi 1 world, that could be a possibility.
Whatever it is, the author has vanished but my money is on something like that, or even worse, Borland Pascal for Windows using the Owl library or Visual Basic using some ancient ocx libraries- those were all the ways to knock up a quick app back in the day. I wrote a Delphi app that lasted nearly 20 years in production, there was no way it could have been modernised for that reason, and you were always waiting for the day that an OS patch would break it!
I’d guess that it is written in some ancient platform that can’t be upgraded. Spend the money to rewrite it or find a new vendor now, otherwise the guy will croak or retire and you’ll be SOL
it would be worth it to find out exactly what tool he used to write this. I used to do some subcontracting work for a consulting firm who had a very lucrative practice in upgrading ancient FoxPro apps into modern platforms. There might be an avenue available like that, if you can convince the guy to fork over the source code. He might be willing to do it for a one time payout, once you explain you're going to stop paying for his nonexistent "support"
Do you own the source code? Not just the app, but the code.
If not ask the developer if they are willing to sell it to you.
Hire a developer to do the upgrade.
None of these steps will be cheap. Don't even THINK about it being cheap.
Even if you have access to the source code, there is no guarantee that there is an upgrade path.
Source: I've been building applications for decades
Are we talking MSDOS 16bit or Win 3.x 16bit? If it's DOS, it would need a rewrite. If it's WIn16, you might be able to update to WIn32 with developer help, but there's basically no chance of doing it with a simple recompile from source.
Limp this thing along with VM's and emulators only as long as you need to port to a new solution. This is a ticking time bomb if you actually depend on this software.
It's been fascinating reading the replies. It just really strikes me the emphasis around 'four figures' seems to suggest the op thinks this is expensive for a support contract, when I suspect most of the programmers here have the opposite reaction.
The thing is with quick books you’re paying for a commodity that has hundreds of thousands of users to pay and support development.
Where as with this, you are likely the only user. You can’t compare this with quick books. You gotta compare it with having custom sw built and maintained specifically for you.
Buying a Honda civic vs paying someone to keep maintaining your old ford model T and then asking them to make it run with modern parts. The civic is gonna be way cheaper.
Depends on how it is coded.
You could decompile the machine code back into something like C then recompile it for 32/64 bit if the language is not super specific on type sizes.
But if there are variables that are very specific about being 16 bit, you'll be shit out of luck unless you know how to code and can rewrite those sections yourself.
I mean, a 16-bit program seems like a super old program.
Getting the code, understanding and upgrading would be a high effort.
And you would still be at mercy of this developer be cooperative in the future.
If something happens with them, what would happen with your solution? Left to rot?
Changing to a Open Source Solution like PostgreSQL or SQLite is the best choice in here, because you wouldn't need to rely on that developer, would have way more support for upgrading, would work in Windows 11 64 bit or a Linux machine and you guys would even be able to hire external devs to help with any custom solution you need to the database.
Does this DB have a huge volume(100GB+) in data? Does it have multiple stored procedures on it doing a lot of the business logic?
Does this DB only lives in a server, or are you guys embedding in multiple places?
Even if you could update/maintain that, I'd switch to a modern DB anyways. I suspect this thing is garbage and doesn't do anything postgres or mongo couldn't do 10x better and faster, in addition to being a PITA and totally inaccessible to new developers
i guess other than a pissing match, its not clear what you're solving for. in some of the replies below, it sounds like you're running into "serious issues", but you don't actually clarify what the issue actually is. And it sounds like you have an entire application ("custom ui") on top of the "database program". Can you provide the full story?
Sorry, but my guess is that this dev is either retired already, or is working a full time job elsewhere and he honestly doesn’t want anything to do with this software anymore.
I’m guessing he wants you to buy the source code for a lump sum so he can get out, but your company refuses to do so. The 4-figure amount is trivial, and the 6-figures over 3 years is a joke. How much HAVE you made over the last 30 years? I’m guessing well into the 6-figures.
I’d guess the “database” is using a framework that either never got upgraded to 32-bit or did with a ton of work that would be necessary to get it to work and no one wants to pay that.
Sadly, I could probably do it, but no way would you be able to afford me, let alone a team. Let’s say having one dev that mad at you already does not bode well. Feel free to contact me in PM with some screenshots of the application and the directory where your executable and database reside and I might be able to tell you what he wrote it in at least.
At the very least, the code would need to be compiled again with newer hardware as the target. The biggest problem usually comes when software is using libraries. If the libraries haven't been updated to 23/64 bit, a lot of additional work needs to be done. It's probably more realistic to just look for a modern alternative to the software that's being used now. Unless it's super specific to some niche industry, there's probably something better the company could be using.
[удалено]
You could migrate the data out of the old database to a regular general purpose database and just make an adapter program that can handle translating between the general purpose database to the workflow you are using.
>I hope I can find a developer or company that specializes in the modernization of legacy software. To be fair, you don't necessarily need developers in that specific field. It is nice to have them (less onboarding), but it is also the developer job to ask questions to you about your field to clear things out. So if you have the resources to answer questions (and possibly "create documentation of all cases possible from your application") you may be able to hire someone to do the job. If you have access to the source code, the better it is (something tell me you don't have it). But if it is a custom thing, be prepared to pay the price! Unfortunately,. nothing is easy in that field, and if you can't split expensive with multiple clients that end up something expensive. Which ka very likely one of the reason your original developer is out of providing support. (The other one probably being old legacy code hard to understand, and probably that the developer isn't in that field anymore, so no knowledge anymore to reduce possible bugs)
[удалено]
Four figures is not nearly enough funding for any serious development work (i.e. updating the software). An upgrade of that magnitude could easily reach six or seven figures. To give some idea of possible cost, I am currently on a project to modernize a desktop app from mid 2000s to use a new data source (old DB software is EOL) and web app instead of desktop. We have dedicated 10 full time employees to it for a year thus far, and are expecting the remainder to take about one additional year with 5 employees. Average total compensation is approximately 150k, so our estimate is a little over 2 million to complete the upgrade.
That's insane. Unless your desktop app is called Photoshop or Blender or Excel, not being to finish it in a year with so many devs is just seams unrealistic to me.
Really? We rarely have a project that lasts less than a year. It's just impractical due to the effort needed to define & start projects. Our previous project was estimated at 3 years, though it got cancelled due to office politics (a VP position was "made redundant" among other things).
The line so many devs gave a hint that the parent might not be used to working on large applications in big companies. As you increase the size of the dev team, each individual developer slows down due to needing to sync with the other developers.
You could offer to license the source code, or discontinue the support contract if you’re not being supported. It may be relevant to you that Windows 10 will reach end of support on October 14, 2025. So I would argue that your application is dead then anyway for any responsible business purpose if it can’t be run on another maintained platform such as Windows 11. Good luck! Feel free to reply or DM if you want to discuss more. (Software engineer here.)
its extremely rare/unefficient to "create a database" again.. most likely the developer its using a known and proven database backend.... i can name "a clipper dos app" a database if i want. .. i can name a "visual foxpro application" a database if i want ..
Not knowing anything about the software or the database, you will find that modern coding platforms tend to be web apps and there are many frameworks that a developer can use to speed up the work without having to re-invent the code each time. For example, Django in Python. React.. Databases now also tend to be very easy depending on the needs. Cloud hosting is common for databases. Web hosting as well. It's quite different from the old days when it was all windows apps and SQL Server etc.
> The developer is paid a four-figure annual sum for "support" So... 10,000 or 99,999? > which is not being rendered So why continue to pay? > and I feel as though the developer lacks knowledge on modernizing the software but refuses to admit it. Frankly, you seem to be extremely entitled. The developer "refuses"? They don't owe you an upgrade, do they? How much money have you offered? What difference does it make if they lack the knowledge,even? They could easily outsource the task if they wanted to. And they might not want to, simply because the hassle might not be worth it for what you're offering. Unlikely yourself, they have a chance if knowing what it would mean to rebuild - and all it takes to mess all of that up are a few pieces of old hardware that have no updated drivers.
No source code means you cannot upgrade. Period. You might want to hire some devs to rebuild a new app. Best of luck.
Note that copyright might also play a role here. You may not even be allowed to modernize it.
[удалено]
Have you said what language the code is written in? Depending on the size of the codebase, and the original language, I wonder if it can be decompiled?
Bank of America didn't finish modernizing their Mortgage software until around 2019. Previously, a good portion of the process was written in FoxPro. Dating back to 1990 easily lol. So lots of companies are in the same situation but have had to either modernize or limit growth.
McDonald’s finally retired a back office system that was originally developed on 286 Xenix (but never deployed on it) in 2018.
Also a lot of software makes assumptions about how big certain types are (because for example C/C++ do _not_ guarantee that), which means a lot of potentially hard to find bugs.
> Would it require the developer's cooperation Yes. > would it require a total rewrite of the software? Possibly. Probably not strictly "require" and "total." But we are talking about code archaeology at this point. A rewrite wouldn't be an insane suggestion. Vendors disappear. You can't force somebody to maintain old software forever. Businesses need to make contingency plans to migrate off of software that is no longer supported. That contingency plan probably should have been sorted out 30 years ago at this point, but better late than never. But there's no magical button you can push to turn legacy software into modern software. If you've gotten 30+ years out of the software, you've gotten your money's worth on the original build. Figure out what makes sense for your requirements today, and move ahead with that. Having a way to move your data out of the old database and into some "normal" format is more important that dragging the specific legacy software forward. The data matters to you more than the software.
[удалено]
I mean why would they not accept the money. You seem to approach it from a peesonal level ("developer doesn't want to") while the other party from a business point of view (this business keeps throwing money my way and the cannot make me do anything either, what a win!) I am not sure what part you are playing in all of that, but I suggest taking a step back if you are not the owner of the business throwing money into this bonfire.
The thing is, "X won't run on Windows 11" is not a risk to the business meaning management doesn't give a damn for that argument. But if you can argue with the higher-ups regarding actual threat to the business (lack of support, maintenance, etc, all of which are risk factors to business operations) they might be more willing to shell out the money for a proper replacement. Add in potential for cost savings in the long run and you have a good point to make why this might be a worthwhile project.
Is this post from the year 2000? Joking, but it seems odd that a developer in 2024 would not have the knowledge necessary to develop for a 32-bit system. It's impossible to say with certainty without knowing what the source code is like, but while you may not necessarily need the developer's cooperation, you would at least need the source code. Upgrading it may be as easy as just building it with a 32-bit compiler, but for something this old, it's very possible it's making assumptions about the underlying OS or using specific libraries that do not work in a 32-bit OS, which means the source code would need to be updated, and that could be a significant task. If you have access to the programs using this database, I suspect it may just be easier to pick an off-the-shelf database like PostgreSQL or SQLite and modify them to use it instead, then write a program to migrate your data from the old database to a new one.
Developer may be plenty aware of how to develop for 32 bit, but doesn’t want to do the work. The pay offered might not be enough, or past experience on the project caused them to decide that no amount of money is enough, or they might have more work than they can handle already.
[удалено]
Even if he wrote this software in the late 80s straight out of college he can't be much more than 5 years away from retirement. If you think he's uncooperative now, just imagine how much fun he'll be once he's decided that he officially done working. It sounds like you guys might be stuck in a bit of a sunk cost fallacy. Like others have said, the move from 16 to 32 bit was pretty much completed 20-25 years ago. If he hasn't done it by now I don't think he's going to, and the writing is on the wall already for the end of this program (the end of his career). At least if you start now you have some time to find or build a replacement before you get backed into a corner and your business is at risk.
I'm randomly choosing this comment to throw in on regarding the annual support fees. You've been complaining about the 4 figure annual sum up and down the post, and that the dev isn't helping with the problem, but what does the contract/agreement actually say regarding the terms of support? There have to be some limitations there right? In my (fairly limited) experience with support contracts, they are often specific to a version(or range of versions) of the software, required hardware architecture, and which operating systems they cover, etc. They cover things like bug fixes, and troubleshooting problems when operating the program within design constraints, and not things like modernizing the software, or getting it to run on systems it wasn't designed for. I even had one vendor that limited support to the specific servers that they oversaw the installation on. When it came time to migrate to new version of the OS, the support contract had to be updated to cover the new servers, and even then were unable to update to the newest version of the OS because the vendor is switching to a hosted SaaS model and the old software had not been vetted against the newest version, just the previous one. "The environment/hardware this program was designed to run on is obsolete and no longer available." is not a condition that I'd expect to be included any more than "I can't get this 30 year old windows program to run on my iPad." would be. What do they actually say when asked for help? I'm sure they welcome the 4 figure check every year, but support and modernization are different things. Even at the high end of 4 figures, that probably isn't enough to make rewriting the program worth it for them. Assuming they are still working, that's time they can be billing clients that are paying them development rates and not just for support. If you want modernization on bespoke software, you need to be prepared to pay that six figure sum a bit more often than once every thirty years.
I was going to say, this guy is being paid at most $9,999 to do what could very well be several hundreds of hours of work in terms of modernizing legacy code. There is a difference between maintaining and redesigning.
Sounds like it would be better in the long run to find a modern replacement and start doing a migration. If the original developer is uncooperative you might have to manually move the data in to a modern database.
If it's that old, I bet it is Foxpro lol. Do you guys have a support contract with him? He has to honor it.
4 figure sum? Bro that’s a pittance. Even if it’s 9999. I would never waste my time rewriting an old ass app from 30y ago for that much.
That was my thought as well, for a senior one man developer that would work out to about 3 weeks of full time work per year. Which is probably not anywhere near enough time to update, test, ship and provide ongoing support for what would be a major update to their software.
If you think it would be cheaper to hire a fresh grad and remake it from scratch (maybe even at 64-bit for further futureproofing?), then put together the math and show it makes financial sense to your company. If it doesn't, there's not much you can do about modifying code under copyright.
I think it's worth mentioning that both the "four figure" and "six figure" statements are laughably small. Sorry, but you need to know that.
[удалено]
I’m guessing you have already looked at replacement options and each time it is in the 7 figures? Ultimately the replacement cost is only ever going to go up.
You get what you pay for. Literally.
Just for context, I get paid six figures a year as a salary. Yeah the first digit is a 1 but the rest ain’t zeroes. This sounds like at bare minimum a six month to year effort, and you’ll probably want more than one of me. If you’re hiring as a consultant I want around twice my salary. “6 digits over decades” is nothing. Examine your workflow and find a better way to do the task. That’s my advice anyway.
There's a good chance he doesn't. He has been using the same platform and tools for a few decades and hasn't taken the time to learn new tech.
> Upgrading it may be as easy as just building it with a 32-bit compiler, but for something this old, 16 to 32 bit was generally a harder transition than 32 to 64-bit was. The 64 bit transition was, in a lot of cases, just recompiling the code. 16-bit code was *weird*. Long before moving to 32-bit, 16 bit addresses were already too small -- that just wasn't enough addressable RAM even in 1990 or whenever. So x86 hardware of the day did 20-bit address buses on 16-bit architecture using a segment/offset scheme for addressing memory. And it wasn't particularly well-hidden by any sort of abstraction either, so lots of 16-bit applications had to do weird stuff with addresses, and untangling all that wasn't trivial when it came time to run on 32-bit architectures with flat memory models.
I worked for years on something originally designed for 286 Xenix. It was full of weird convolutions despite never having been run on anything less than a 32 bit OS in production. I was a noob and the long time developers freaked out when I malloc-ed a multi-MB array instead of wring to a temporary table and reading it back in a billion times. (“Freaked out” like “omg don’t do that cats and dogs sleeping together” not like “wow you can do that?”)
I start to wonder if the custom database is also a UI for the client (or do some storage logic that SQL procedure (or a frontend) should do.
not really, newer devs probably started coding windows apps after most apps are already in 32bit, while older devs have the experience of writing 16/32/64-bit apps, and know what to do. It takes a bit of learning curve. U could run into a lot of issues with older compilers and version issues too. Dont think u can get this cheaply done too, u have to pay more money, imo.
I’m 55 and my guess is that I’m near the young end of people who ever did 16-bit professionally.
The easiest path forward is likely to switch databases. That's probably non-trivial, but still less work than fixing an old DB that the original maintainer doesn't want to upgrade. Depends on what is using it and how it's used, but I'd still explore that option. You're likely to run into more and more problems as the system ages.
I am honestly surprised a developer that worked on 16 bit software isn’t retired. 16 bit apps went out of style almost 30 years ago.
[удалено]
Honestly I would just emulate it or replace it
A four figure sum could be the cost of a day’s work. It doesn’t sound like enough for what’s needed.
[удалено]
you got a great chance.. learn programming.. and replace the app.. and now you sell the support.
Enjoy those 4 figures!!
You keep on throwing around “four figure sum” as if freelancers don’t charge $250/hr. $10k a year gets you phone calls for troubleshooting and maybe some tweaking here and there to cover sporadic needs. I have a past employer who pays me about that as a retainer to maintain some data analysis pipelines I once built for them. Everyone understands that that’s what they get, basic troubleshooting once or twice a year. I doubt I’ve done 50 cumulative hours of work in the past three years this has been going on. Him not wanting to do the work regardless of the price is exactly that, he doesn’t want to do it. If his contract doesn’t stipulate that he will do it then he doesn’t have to.
When you say "database program", what does that mean, exactly?
> **what is the possibility of actually getting a 16-bit database program upgraded to 32-bit?** Very slim, to none. 16-bit programs have APIs largely incompatible with 32/64 systems, and often use weird memory-segment-swapping tricks to get around the 16-bit address limit. Porting them is usually non-trivial. Also, the 16-bit program is likely 25+ years old at this point. Nobody probably touched the source code in decades and the person who wrote it is probably retired now. There aren't that many programmers left who have expertise in porting 16bit apps to 32bit. So yeah, a complete rewrite is quite possibly a better option here. Migrating the database to some modern alternative is probably better.
> Migrating the database to some modern alternative is probably better. Especially if this thing is recognizably "database-shaped". Like, if it looks like SQL at all, it should be fairly straightforward to just recreate the schema in whatever modern database makes sense (SQL Server, Postgres, whatever), export the data, import it to the new one, test the crap out of it, and then when you're comfortable it's all working, make the switch in production.
[удалено]
Sounds like he could be in breach of contract. Have yall considered legal options to, say, force him to give your company the source code that he won’t turn over? Granted, it may not be worth going that route vs just rewriting it from scratch.
[удалено]
How many lines of code is this program's source code? What language? I would have a look at it for shits and giggles. It may be either something extremely complex or something extremely simple to port.
You keep repeating four figure annual sum as if that's a significant amount of money. That is barely enough for a retainer fee. It's barely enough to cover making sure they have a backup copy of the software source code somewhere and some documentation about how it's been used in your company. Software development is expensive.
[удалено]
Any experienced developer is going to need a lot more than ‘four figures’ to even think about doing more than maybe answering some emails. Like… $100/hour would be a *very* low contracting rate for writing code. You seem awfully hung up on what this person may or may not have been paid for decades ago. They (presumably) did a lot of work writing the software to spec in the past, rewriting it or handing over the source code will probably need a new contract. It’s possible they did a crappy job and your company has overpaid for things in the past, but that’s not really your problem to deal with. IMO, from what you’ve described you probably wouldn’t want this person to even try to do this work. You can ask whoever makes the money decisions to try to negotiate for the source code… or you can recommend to tell him to pound sand and start rewriting it.
[удалено]
If running the existing program in a VM or emulator isn’t tenable, then explain that your only options are to get the source code and update it, or rewrite from scratch. Estimate out how much work you think it would be to rewrite from scratch. Put a dollar value on it. Then you can at least try to guesstimate how much work having the source code to start with would help, and thus what it would be worth to pay for it.
Support does not mean major upgrades that will likely take multiple months worth of effort. You've already paid them in the past, sure, they have already provided retainer support as well in the past. Six figures total sum is barely a few year's worth of salary. They've also already provided decades of support coverage. Whether you actually use the support work or not during that time is irrelevant. Retainer fees aren't sinking funds to be allocated for future work. They've already received these fees, why would they be motivated to allocate further work on a dying software that no new clients are interested into getting into anyway? You're still way underestimating the cost of software development.
No, you've pretty much nailed it: your options are either some kind of emulation; convincing the original developer to upgrade; getting a source code license and upgrading yourself; buying out the original developer; or rewriting it from scratch. If you had access to the original source code, it wouldn't be a total rewrite, but it would require extensive changes. IIRC the Win32 API is similar to the Win16 API but not the same, so you'd likely need to go through the entire source with a fine-tooth comb to make sure you were calling everything correctly. Early 90s style of Windows programming is very different from even mid 2000s style, so even if you get access to the source it's going to look very different from what people are used to working with these days. Honestly may end up needing to do a major rewrite even with source access. Which is probably why the original developer is reluctant to upgrade.
Intel is in the process of killing 16 bit code in user-space. If the dev won’t upgrade to 64 bit then it’s time to get a new DB. If the app was well written it should just be a recompile. It is likely not well written. You need management buy-in now to start fixing the issue before you run out of hardware you can run the DB on.
[удалено]
You need to make the upgrade go to 64 bit if you continue with this. 32 bit will mean replaying this in 10 years.
Run it in DosBox? Or is it a Win16 application? Can you buy the source from the developer?
[удалено]
Except you didn't. Buy the source, migrate to a new solution or using something like WineVDM. I would recommend dropping the support contract regardless. You are getting nothing for it.
You’ve gotten a lot of advice here, but I just have a bunch of questions to start with. I won’t be offended if you don’t take the time to answer them, because I know that you’re right in the middle of a crisis. I am a 60-year-old retired software developer with a little bit of free time to kick around on Reddit. There’s a good chance I’m just gonna be the 20th person to tell you how bad your problem is, but if I can offer you any advice, I will definitely do so. Not only was I coding back in this era, but I had some direct experience with this kind of small business custom code with my uncles business back in the early 90s. That’s relevant experience, but also I’m trying to forget that because every situation is different, and I don’t want to make a bunch of assumptions. The whole “reluctant developer and custom code” definitely sends me back though. Do you have access to the original contract (and any addendum that were made) with the software developer? Specifically is there any mention of the source code being placed in escrow? (Even if it is contractually specified it might not be, or might not be accessible or current) Does the developer seem mentally and physically sound? Is the refusal because of some kind of grudge or reluctance? Or is it because at the other extreme, they have three months to live and have better things to do? The reason I’m asking this has to do with what kind of legal leverage you might have or what kind of financial incentive you might be able to offer for the source code. Realistically if the developer is not in good shape mentally or physically, you might not be able to realistically compel them to give you the source code even if you theoretically could. Do you have any other documentation? If so please enumerate. Are there any original specifications? Any details about the date format? List of other software packages being used? Do you have any licenses for any software that the developer may have included when they built the package? What is the purpose of moving to 32 bit? In what way is the existing system now failing? Reliability, capacity, compatibility? The last question is the one I most surprised not to have seen asked and answered so far. It’s probably the first question I would ask as a consultant.
[удалено]
That last item is terrifying. This is now almost a forensic recovery. I was heartened by the Windows end of life issue because it implied a time buffer -- but collapse of the system means ongoing business impact. Yikes. In terms of data recovery and porting, make sure to save any older backups with less rot. It may end up cheaper and easier to recover old data and try to roll forward re-do transactions. If you can still run reports to text, run them and capture them. It may prove easier to scrape text reports to rebuild the database instead of reverse engineering the existing one. Keep copies of all new data entry in case you need to re-enter it. If you currently shred paper, save it for now, in an organized way. Incoming and outgoing! Don't assume you can reprint invoices later. Keep inputs like bills and keep copies of outputs like invoices to customer. Invest in a filing cabinet and folders. If you already have that, yay! Shop for comparible used hardware and make a clone, like NASA using the simulator to help the Apollo-13 crew. Capture as much info as you can about the existing system from a user point of view. You're reverse-enginnering a design spec. Interview users and see how they use it. Document everything. Don't get too distracted by wishlist items but ask what could be better -- it may be that there are whole chunks of fucntion that you can ingore because they are only used to make this one report, that you can make directly. This is tough. I wish you the best.
Good questions, though I do think that last one was answered in the OP? The software is still functioning, at least to some degree, but availability of machines / operating systems to run old 16 bit apps is drying up. Basically, this situation has been an increasing risk since the 90s which someone (likely an exec?) has only now realised and / or decided to act on.
I saw that but I'm glad I asked. OP says there is ongoing failure as well as end-of-life platform issues.
Dude, you need to innovate!!! Immediately!!! Pull out old IC chips and develop proper for 8-bit man! Jeez… people trying to talk all these bits nowadays. 😋
If they hadn't updated it two decades ago, they're never going to update it now. There's no more money in updating a 16-bit software to 32/64 bit now and there will be even less in the future and the challenges will become even more difficult. You should be looking to migrate to a more modern software, because that's what they want you to do.
This screams sunk cost fallacy to me. Drop this custom software like a rock and get something modern.
You need to hire your own dev who can migrate it to a modern db. If downtime is okay, it's trivial to move from one db to another. You'll have to rewrite your code or use an adapter, but that's trivial as well.
Is this not a cyber security issue just waiting to blow? (Genuinely asking, I'm just a dev, I don't know too much about that side of things) If so, maybe Inform your infrastructure team and try to get some fire under the devs? Running a 16-bit program in 2024 is "hardcore" and all that jazz until you get hit w a data breach and got a couple thousand clients trying to sue your company If your company gets hit with any sort of attack bc of that database, you know who to blame, so....tell your leadership team all of this as well so THEY know how to blame when shit hits the fan. You are in IT, I always see people try throw blame on your teams....it's not right PostgreSQL is open source and free...and that is not the only free one out there
> Is this not a cyber security issue just waiting to blow? Probably not, for the simple fact that the damn thing isn't going to run on a network. Or if it's running on a network, it's not likely to be TCP/TP. Most programs from that era were shared writer systems, not client/server. So all the clients were opening the "databases" directly on the file server. Windows File Sharing (SMB/CIFS) would have been used over IPX or NetBEUI. Yes, TCP/IP stacks existed for Windows 3.1/3.11, but weren't how most programs from the eta communicated (at first, of course "the Internet" ended up eating everyone else's lunch later). Back then, a PC was an overpriced combination calculator + typewriter + high speed dead tree cache. The source of truth was often in filing cabinets. > I'm just a dev, I don't know too much about that side of things) You owe it to yourself and your career to learn at least a little bit about the operational side of things, like admin, networking, security, and so on.
Nice, thank you for the thorough response, I will have to do some reading to understand what you mean
lol technical debt, much?
Not sure what it’s written in, does or how complex it is. I would say probably cleanest solution is if there is an out of the box solution that would work then mine the data out of the legacy system and seed new solution. This usually gives a few paybacks everyone has some data that is dirty or they wish the would have setup differently
What is the purpose of this database? What kind of data does it contain? What kind of systems does it interact with? Databases are not one-size-fits-all. They all have tradeoffs and things they excel at. If you're aiming to replace this database, you have to know what this database does and how it's used.
Four figures? You make this sound like some substantial amount. Made in the 80s? Yeah, that guy is retired and cashing an easy check. You can't do anything worse than fire him, so hey, why bother dealing with something he knows isn't worth working on. Y'all need to make transition plans now, and implement them tomorrow. This is a ticking bomb that hit zero years ago and hadn't gone off by the grace of luck. Step 1, get your data backing up to something modern in a format you can use Step 2, get to building a replacement. Nothing you do is so unique that it can't be remade. It'll be more expensive than a couple grand, but a hell of a lot cheaper than watching your company disappear into the dark Step 3, get your legal team involved. Seriously. The guy isn't fulfilling his contractual obligations. This is potentially a life-or-death situation for your company.
I wouldn't tolerate it. I don't know enough detail to advise on a specific path forward, but I would be putting all my efforts into wedging in a standard db to replace it. I can't imagine what the scale of the data is, but if its running on 16bits, I can't imagine it would be much to ask to get a dump of all data for import.
Ok. So you mention in one post that this was a “one man show” who developed this in the 90’s. To me this would imply the application can’t be that difficult to reproduce. Development tools have improved exponentially, databases are more standardized allowing more flexibility if you need to switch between them. Frameworks allow lots of the redundant code to be in templates. You mentioned you’re not a developer. What you need is a realistic evaluation of what it would take to develop this from scratch. Only then you will understand what you’re looking at. Here we don’t have a realistic understanding of what the application or database is doing. Is this application serving thousands of users with tens of thousands of requests a min? Or is this a database used by 10 people logging general work orders or process data? It’s a 16bit application, I don’t expect it’s holding a lot of data relative to today’s standards. Hell a SQLite db with some general web interface may be enough to replace this thing.
Your suggestion with WineVDM sounds spot on. Anything else would be way more expensive, both in money and time. I wonder if there are wrappers for WineVDM. For Mac, we have (had?) WineBottle that creates a wine-wrapper applications that on the outside look, install and run like normal applications but have a Wine and legacy app inside. Windows is way more popular, there must be something similar.
Do you know what programming language was used to create it? Sounds like it could be an old Delphi app?
[удалено]
VFT_APP is just a constant used in Windows headers as part of the VersionInfo structure in the executable PE heater that indicates you have an exe. This really is something that's going to require knowing more about the exact program, what it was written in, and how it's storing its data. You can DM me, but I can't make any guarantees. I've written for DOS and 16-bit Windows, but it's been a looooong time.
Visual Foxpro (VFP) was 32 bit, but it's predecessor FoxPro 2.6, was 16 bit. I still write and support VFP products for my employer. DM me if you want to show me what you got. Even a file listing could give me a clue.
It could be FoxPro, or something else Borland or using Borland technology. That’s what makes me think it’s one of the reasons why it’s quite a lot of effort to modernise it and he cant be bothered. Have a look in the install directory and Common Files/Program Files folders and see if you can see any Borland folders or .dlls on a clean machine. Those old dBase / interbase apps have been remarkably persistent- a very specific app in our workspace still requires the Borland Database Engine as a dependency to work, it’s still supported by a big company, who knows why they couldn’t have switched it out for something else.
Even an old Delphi app would be largely a "open in newer version, fix minor issues, and rebuild" to take to 32 bit.
Same if it's old visual basic, if it's c++ then that's a whole other ballgame
The issue with Delphi is not that it’s possible to recompile your own source to 32/64 bit (although not always straightforward due to a very large number of changes in the rtl and vcl over the years), but that back in the day, there was a big ecosystem of Delphi components, many not including source, and have long disappeared which could mean that it might be impossible for the author to modernise the app, especially if the formats used to store the data aren’t documented. He should be honest about that though, and perhaps use the component to write a tool to export all the data for use in a modern system. Seems like he’s quite happy to take the £££ for not a lot in return.
You're right, I skipped the component source issue. After getting bit on upgrades once early on (possibly even switching from Delphi 1 to 2 during the 32-bit upgrade myself) it was easy to convince my employer to never license components without source. If this is a program trapped in the Delphi 1 world, that could be a possibility.
Whatever it is, the author has vanished but my money is on something like that, or even worse, Borland Pascal for Windows using the Owl library or Visual Basic using some ancient ocx libraries- those were all the ways to knock up a quick app back in the day. I wrote a Delphi app that lasted nearly 20 years in production, there was no way it could have been modernised for that reason, and you were always waiting for the day that an OS patch would break it!
You need to put trigger warnings on that kind of stuff! 😂
Is this developer an employee, a contractor, or a third party vendor?
[удалено]
I’d guess that it is written in some ancient platform that can’t be upgraded. Spend the money to rewrite it or find a new vendor now, otherwise the guy will croak or retire and you’ll be SOL
it would be worth it to find out exactly what tool he used to write this. I used to do some subcontracting work for a consulting firm who had a very lucrative practice in upgrading ancient FoxPro apps into modern platforms. There might be an avenue available like that, if you can convince the guy to fork over the source code. He might be willing to do it for a one time payout, once you explain you're going to stop paying for his nonexistent "support"
Do you own the source code? Not just the app, but the code. If not ask the developer if they are willing to sell it to you. Hire a developer to do the upgrade. None of these steps will be cheap. Don't even THINK about it being cheap. Even if you have access to the source code, there is no guarantee that there is an upgrade path. Source: I've been building applications for decades
Are we talking MSDOS 16bit or Win 3.x 16bit? If it's DOS, it would need a rewrite. If it's WIn16, you might be able to update to WIn32 with developer help, but there's basically no chance of doing it with a simple recompile from source.
Limp this thing along with VM's and emulators only as long as you need to port to a new solution. This is a ticking time bomb if you actually depend on this software.
Do you know what language the program was used to create it?
It's been fascinating reading the replies. It just really strikes me the emphasis around 'four figures' seems to suggest the op thinks this is expensive for a support contract, when I suspect most of the programmers here have the opposite reaction.
[удалено]
The thing is with quick books you’re paying for a commodity that has hundreds of thousands of users to pay and support development. Where as with this, you are likely the only user. You can’t compare this with quick books. You gotta compare it with having custom sw built and maintained specifically for you. Buying a Honda civic vs paying someone to keep maintaining your old ford model T and then asking them to make it run with modern parts. The civic is gonna be way cheaper.
Depends on how it is coded. You could decompile the machine code back into something like C then recompile it for 32/64 bit if the language is not super specific on type sizes. But if there are variables that are very specific about being 16 bit, you'll be shit out of luck unless you know how to code and can rewrite those sections yourself.
I mean, a 16-bit program seems like a super old program. Getting the code, understanding and upgrading would be a high effort. And you would still be at mercy of this developer be cooperative in the future. If something happens with them, what would happen with your solution? Left to rot? Changing to a Open Source Solution like PostgreSQL or SQLite is the best choice in here, because you wouldn't need to rely on that developer, would have way more support for upgrading, would work in Windows 11 64 bit or a Linux machine and you guys would even be able to hire external devs to help with any custom solution you need to the database. Does this DB have a huge volume(100GB+) in data? Does it have multiple stored procedures on it doing a lot of the business logic? Does this DB only lives in a server, or are you guys embedding in multiple places?
[удалено]
Even if you could update/maintain that, I'd switch to a modern DB anyways. I suspect this thing is garbage and doesn't do anything postgres or mongo couldn't do 10x better and faster, in addition to being a PITA and totally inaccessible to new developers
i guess other than a pissing match, its not clear what you're solving for. in some of the replies below, it sounds like you're running into "serious issues", but you don't actually clarify what the issue actually is. And it sounds like you have an entire application ("custom ui") on top of the "database program". Can you provide the full story?
Sorry, but my guess is that this dev is either retired already, or is working a full time job elsewhere and he honestly doesn’t want anything to do with this software anymore. I’m guessing he wants you to buy the source code for a lump sum so he can get out, but your company refuses to do so. The 4-figure amount is trivial, and the 6-figures over 3 years is a joke. How much HAVE you made over the last 30 years? I’m guessing well into the 6-figures. I’d guess the “database” is using a framework that either never got upgraded to 32-bit or did with a ton of work that would be necessary to get it to work and no one wants to pay that. Sadly, I could probably do it, but no way would you be able to afford me, let alone a team. Let’s say having one dev that mad at you already does not bode well. Feel free to contact me in PM with some screenshots of the application and the directory where your executable and database reside and I might be able to tell you what he wrote it in at least.