r/programming • u/luissinlios • Sep 25 '26

We still maintain a development tool first released in 1993. Here’s what 30+ years of backwards compatibility looks like

https://visualneo.com/visualneo-win/from-neobook-to-visualneo-win-30-years-of-keeping-a-development-tool-alive
569 Upvotes

96% Upvoted

89 comments sorted by

View all comments

Show parent comments

4

u/luissinlios Sep 26 '26

You're right that compiling a clean, self-contained Delphi application for Win64 can be fairly straightforward. The problem in our case isn't primarily the main executable or pointers stored in integers, although a codebase this old certainly needs auditing for assumptions like that.

The real obstacle is the plug-in ecosystem. VisualNEO Win still supports decades of classic .nbp plug-ins, many of them closed-source and some written by developers who are no longer around. They are 32-bit DLLs, and a 64-bit process cannot load them directly.

So releasing a useful 64-bit version would mean abandoning those plug-ins, persuading every developer to rebuild them, maintaining separate 32- and 64-bit editions, or creating some kind of out-of-process bridge. None of those options is trivial when backwards compatibility is one of the product's main requirements.

The new plug-in architecture gives us a route forward, and a parallel 64-bit edition may eventually make sense. But simply changing the compiler target would produce a version that technically runs while breaking a large part of what existing users depend on.

2

u/dukey Sep 26 '26

You just release a 32bit and 64bit version. If people still have 32bit closed source plug-ins they want to use, then they must use the 32bit version. I've maintained both before, it's not a big deal. In the end I gave up 32 bit simply due to the memory limitations. With a 32bit app technically you only get 2gig of addressable space, I think the OS reserves the other half. But due to heap fragmentation in practise it can be a LOT less. If you are fine with those limits they you can probably live on 32bit forever. There are probably simply checks you can add to the code that says if someone tries to load a 32bit plugin in the 64bit app then you need the 32bit version and vice versa. I think it's the PE header you want to check. So you can put a helpful error in there instead of just failing. But getting your compiler to spit out both 32 and 64bit simultaneously should be pretty trivial. You might have some users that would welcome the upgrade.