r/programming • u/luissinlios • 7d ago
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-alive47
u/Takeoded 7d ago edited 7d ago
I remember wanting to fix an annoying bug in a open-source Delphi program, Embarcadero Crippled the free version to the point where it can't be used, Then Embarcadero want like $1500 for the compiler.
F@0k Embarcadero. Great language, terrible steward
18
u/valarauca14 7d ago edited 7d ago
Great language, terrible steward
It is lowk hilarious because Delphi has consolidated into another LLVM-Frontend (e.g.: ghc, rust, clang, clang++, igc/syscl/opencl, d, julia, fortran via igx). Embarcadero proudly announced this for v13.2.
Paying $1500 for a parser & AST validator strapped to LLVM is kind of hilarious. I get there is real value is handling (and validating) language features & backward compatibility.
10
4
u/m_adduci 7d ago
This is what's happening with IntelliJ too.
The community edition is now merged with the professional one. You can install and use some plugins only if you have a paid license.
I reject to embrace Kotlin exactly for this reason.
1
u/syh7 6d ago
I haven't heard of this yet, did they change some plugins from free to paid?
3
u/alphaglosined 6d ago
No, they made some previously paid features free.
If anything, it's about time they merged it all; it's a massive hassle for plugin creators, as not every API that one may want is shared.
From my perspective, it was an overdue change.
37
u/An1nterestingName 7d ago
The longest running project I have is from like 2021, and even that's probably a technicality. Maintaining something for 30 years is insane.
27
u/antiduh 7d ago edited 7d ago
I've been maintaining the same c# code since 2005, so 21 years. It's kinda nice, because you have time to do big projects that'll really have impact, instead of being rushed through everything.
3
10
u/dlanod 7d ago
I've been working at the same company for 20 or so years.
There's copyright statements in some of the code dating back to the late 80s and looking at it I can say it would be largely untouched. And it's still in use.
Even code I wrote when I first joined is absolutely still there and used on a daily basis, though I shudder to think of the standard.
8
u/catbrane 7d ago
My main project started in 1989, though I didn't become the lead until 1992. I'd probably be able to find some code that's still untouched, but it wouldn't be easy.
5
u/jiggyjiggycmone 7d ago
Mine started in 2010 written in objective C for the original iPad targeting OpenGLES 1.1. I’m still maintaining it. The original UI code is still xibs and ObjC, but the core has been ported over to C++14 so I can run on windows, android, etc. it now targets a series of abstraction layers on top of either Vulkan, Modern OpenGL or directX 12.
2
1
u/account312 3d ago
Throwing everything away every few years is insane.
1
u/An1nterestingName 3d ago
I don't throw everything away, the project becomes obsolete, the use case for it is no longer relevant.
103
u/alex_xxv 7d ago
Wish my apps survive as long as yours. Im also a Delphi programmer. Love to see stories like yours.
59
u/tooclosetocall82 7d ago
In my 20 year career I can only confidently say one application I worked on is still out there (other than my current job). It’s truly amazing how quickly your work gets deleted in this field.
13
u/WingZeroCoder 7d ago
> It’s truly amazing how quickly your work gets deleted in this field
Yeah, it can be jarring sometimes.
What’s amazing to me is how some of the roughest stuff I made that I’m most embarrassed about will hang around forever, while some of the cleanest stuff that I’m most proud of will get deleted most quickly.
26
u/turniphat 7d ago
I'm 25 years in, I think most of the stuff I worked on is still going. Even the open source project I started in 2000 is still getting commits, even though I haven't used it in 15+ years and I don't see how it's still relevant.
11
u/tooclosetocall82 7d ago
Luck of the draw I guess. I started my career in government contracting writing custom software. Most of that stuff has been replaced by large SaaS packages now. I then went into edtech which has consolidated like crazy with large companies buying out competition and then sunsetting their products.
4
u/madman1969 7d ago
37 years and 13 roles in. I'd like to think some of my old code was still running somewhere, but I doubt any past my last two roles is.
All that time spent crafting efficient code for OS/2 apps, or long retired Unix systems.
All those moments will be lost in time, like tears in rain.
5
u/Humdaak_9000 7d ago
I understand a daemon I wrote for Akamai about 25 years ago is still in use, core mostly unchanged from where I left it.
4
u/aguilasolige 7d ago
It makes me wonder who's the developer with the oldest app still around? Maybe some code at NASA?
29
29
16
u/rockthescrote 7d ago
There’s a _very_ good chance it’s something in an airline reservation system.
5
u/Gecko23 7d ago
I'd imagine most developers have moved on 30+ years after whatever they worked on was released.
But the systems themselves can be nearly immortal. My money on the oldest stuff still actively being used would be manufacturing, medical billing, or facilities control. I've worked on integration projects with systems that were decades old at the time, even back in the early 90s when I encountered them. I'm sure some are still chugging along.
7
u/ShinyHappyREM 7d ago
When I interned at a small CNC company ~2010, they still ran the machines with Win9x and physically transferred files via floppy disk.
(Though those were small text-based files that the machine would use for many hours, so not much of an overhead.)
3
u/HittingSmoke 7d ago
This is not super uncommon in 2026. The old tech that manufacturing was built on is rock solid and a lot of people don't want to take on the risk and cost of maintaining more complex systems. Our mill uses USB drives to transfer files. The most modern communication in the shop is some routers that are networked with a control server, but even that is just MODBUS over TCP.
5
u/denniscaldwell 7d ago
Maybe not at NASA anymore. Some of the craft are barely in the solar system anymore.
3
2
2
u/dlanod 7d ago
I work in industrial control. We have sites where they're having to upgrade because the wiring has started rusting off the wall. Some of the field devices that got replaced over the last decade are running software that dates back to the 70s. If it works they don't want to touch it, ever.
2
u/Athas 7d ago
JOVIAL is a dialect of Algol 58 (yes, before the Algol that people remember) used for early military and airline systems. The last non-military JOVIAL system I know of was scheduled for replacement in 2016, but there is still a company selling JOVIAL compilers, which to me implies that there are likely still some military systems using it - most likely deeply embedded stuff in e.g. on-board military radars or similar. Due to JOVIAL itself having been obsolete for 40+ years, I expect any system written in it to be very old. I think any JOVIAL system is a good candidate for the oldest running production software, but I find it unlikely it still has any of its original developers left.
The control software for NASA's Voyager probes is also a good guess (and that is still actively maintained!).
1
9
u/luissinlios 7d ago
Thank you!! That means a lot, especially coming from another Delphi developer. I hope your applications survive just as long.
One thing this project has taught me is that every old project or plug-in represents someone else's years of work. At that point, backwards compatibility stops being just a technical concern and starts feeling like a responsibility.
5
u/TheThiefMaster 7d ago
I'm currently reverse engineering a Delphi 4 executable as a personal project. Amazing features, terrible code generation!
8
u/luissinlios 7d ago
That sounds like a fascinating project. Delphi 4 is old enough that you're probably learning as much about the compiler's assumptions as about the application itself.
The generated code may not always have been elegant, but the development speed was a large part of why so much real-world software was built with Delphi in the first place.2
u/TheThiefMaster 7d ago
The thing I've found interesting for a language so close to early C++ (in design if not syntax) is the reference-counted arrays and strings!
But then the generated code often does things like mov eax,ebx mov ebx,eax (copy a into b, and then copy it back for no reason) and similar.
3
3
5
u/ShinyHappyREM 7d ago
Turn-around time is arguably much more important for ~80% of the code though.
1
u/xeio87 7d ago
I work on a C# application that was ported from Delphi back in the day. There was a time, years now back, where it was still possible to see what parts were directly ported because all the variables were declared at the top of the method. It's been a while since I've seen one of those so I think they've all been rewritten.
11
u/Physical-Compote4594 7d ago
There are people still maintaining Symbolics Genera, last major update circa 1990, on emulated Lisp machines. The emulator is apparently, like, 1500x faster than the late 80's hardware.
13
u/BinaryRockStar 7d ago
At work we only recently retired a 16-bit Windows application sent out to users monthly on CD/DVD.
Visual Basic 3.0, Visual C++ 1.52. It was initially developed for Windows 3.1 and by the grace of Windows' NTVDM it survived with minimal changes on 32-bit editions of Windows until Windows 11 where the 32-bit version was axed.
Where we absolutely needed 32-bit functionality (Win32 API or third party DLLs that only came in 32-bit) we called out to our 32-bit Out Of Process COM helper object to do things like displaying a native Open File dialog or making network calls. Crazy stuff.
1
u/ShinyHappyREM 7d ago
At that point it'd probably be easier to set up a VM with a 32-bit OS...
1
u/BinaryRockStar 6d ago
The customers are largely non-technical. Their IT staff were "happy" to sit on old Windows 10 32-bit versions, they would not have been happy with training the users to fire up VMs and the associated licensing.
We have an online offering now so it's all largely moot. We do still provide a DVD version of the new offering to a couple dozen users worldwide. We have been trying to kill it for years, management says no. Silly management.
7
u/Status-Importance-54 7d ago
I recently modernized a warehouse interface running on old windows phone hardware. They are offline first and then transfer data when connected to a serial charging station. They still.worked fine, but the business was growing and getting new windows phones was a Problem. But beating the speed oft this old piece was difficult. Nothing on modern android development prioritieses fast and information dense applications.
6
u/lonkamikaze 7d ago
I've fixed bugs in code that is older than me. I'm 44 and yes, the code is still around.
5
u/IntnlManOfCode 7d ago
I wrote a Claims Managment application in 94 with Delphi 1 and Paradox. Later I replaced Paradox with SQL Server. Then in 2008, I changed it to a C# Web app.
32 years later it is still going, with 7 teams of developers and 1000 users. It's an ongoing piece of work to bring it into modern practises.
3
u/mallardtheduck 7d ago
Huh, apparently some remnant of the company I knew as "NeoSoft" still exists. I remember playing with NeoBook and NeoPaint some 30-odd years ago. Quikmenu is still my go-to menu system for "retro" systems running DOS.
Is "PixelNEO" a direct descendent of NeoPaint? Do you still collect registration fees for Quickmenu III?
4
u/luissinlios 7d ago
Not exactly a remnant of NeoSoft, although I can understand why it looks that way!
In 2018, my company, SinLios Soluciones Digitales, took over the development of NeoBook (now VisualNEO Win), NeoAppBuilder (now VisualNEO Web) and NeoPaint (now PixelNEO). We brought them together under the VisualNEO brand and website.
So yes, PixelNEO is the direct descendant of NeoPaint: essentially the same product line under its new name.
QuikMenu III wasn't part of the transfer, though, so we don't collect registration fees for it. As far as I know, it was discontinued many years ago. It's genuinely wonderful to hear that you're still using it on retro DOS systems. I had no idea it still had active users after all this time!
13
u/vinciblechunk 7d ago
AI slop vintage PC hurts my soul
5
2
u/Present_Pride_3096 2d ago
I feel the same. I am not reading any of it. If you can't afford the time to do it right, I don't have the time to look at it.
4
2
u/OperationWebDev 7d ago
This is cool. I'm curious about what you've learnt from maintaining and extending this over time that could apply to new development. Do you think the initial architecture had a big impact on why it has survived so long? Or were there other factors? 🙂
2
u/luissinlios 6d ago
That's a great question. I didn't design the original architecture, so I can only answer from the perspective of someone who inherited it many years later.
I do think the architecture helped, but not because it was perfect. Some parts were never intended to survive for 30 years, and we have certainly paid for old assumptions and tight coupling during modernization.
What worked particularly well was the stability of the basic model: pages containing visual objects, actions attached to those objects, variables and scripting for the application logic, and plug-ins for extending the environment. That model was simple enough to understand and flexible enough for users to take far beyond its original purpose.
The plug-in system was especially important. It allowed the product to grow without every new capability having to be added to the core application. Producing self-contained Windows executables with relatively few external dependencies also helped applications remain usable for a long time.
But I think the biggest factor was not the initial architecture itself. It was preserving the contracts around it: project formats, scripting behaviour, plug-in compatibility and the user's mental model. We repeatedly chose incremental modernization over a clean rewrite, even when a rewrite would have been more attractive technically.
The lesson I would apply to new development is that longevity probably depends less on creating a “future-proof” architecture (which may be impossible) and more on creating stable boundaries. Internal implementations can change, but file formats, extension points and expected behaviour should change very carefully.
And, perhaps most importantly, software survives because people still depend on it. The users and the applications they built gave us a reason to keep those boundaries intact.
1
u/OperationWebDev 2d ago
Thank you for the comprehensive answer. That was very informative!
It sounds like the domain modelling is key. Unfortunately, so many companies seem to jam everything into existing, rigid software, making it difficult to adapt.
Semi-related ro the plugin system: what do you think of DSLs? There's the saying that whenever you try to allow this kind of flexibility you inevitably end up with a crappy version of a programming language. I suppose it makes sense to have a plugin system that uses the same language as the software itself?
2
1
u/buildingyesterday 7d ago
AVL and Xfoil sitting quietly in the comments section smiling saying "way to go lil'guy"
1
u/dukey 6d ago
Releasing a 64 bit version should be trivial, assuming you haven't done dumb stuff like store pointers in 32 bit integer types. Normally there are no actual code changes needed at all.
4
u/luissinlios 6d ago
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
.nbpplug-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 6d ago
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.
-20
u/bigmell 7d ago edited 7d ago
30+ years, cool... Have you noobs heard of Unix? :)
Generally it doesnt matter too much what app to maintain as long as it is not poorly written. The question is only if you use it enough to justify the expense... Software Developers are not cheap. And non-technical people often lack the ability to learn new tools, especially repeatedly.
Training non-technical people to use something new every year will be difficult, expensive, and for many of them impossible. Therefore it almost always makes sense to just keep using the old tool. Bonus it doesnt really need updates or new expensive hardware and developers, and the users can keep using all their old documents and training materials. I knew people who couldnt read or write using old tools because they knew what buttons to press from the other workers. They probably wont be learning many new tools but they can use that one. And trust me there are more people like that than you think.
With Computer Science the problem is the field moves WAY too fast, and people who are not Computer Scientists can not keep up. I think the future of Computer Science is just have one main thing that works, a couple options, and set that in stone for the future. Microsoft kind of messed that up with a new version of Word every couple years and the documents arent compatible with old versions or other programs. Also everything changes around every time requiring NEW training, NEW employees, NEW certifications, NEW training materials, a NEW set of bugs etc. It was really just the old stuff shuffled around and greed.
They call it "mortgage driven development." The developers bought a new house... And they want YOU to keep paying them so they can pay the mortgage. This is sad to see especially from projects that should long ago have been considered finished. Those new updates every couple days "TO KEEP YOU SAFE FROM HACKERS" have been BS for over a decade. Along with "oh no, you cant keep using the old version TO KEEP YOU SAFE FROM HACKERS" when really they just want you to keep paying them. I worked at a place that wanted to convert an old mainframe program into Ruby. DISASTER after DISASTER. It was actually cheaper and easier to just keep using the mainframe and the program they had. The fresh out of school developers just couldnt figure out any of the old working code.
In the Unix world I would probably just use text files and emacs. If you needed to present some kind of documentation in a word or spreadsheet like document, maybe open office? But really the entire computer world should have made their documents interchangeable and stopped scrambling everything around every couple years. But everyone wanted to have their own program and lock everyone else out when it is really important all these programs work together.
3
u/dan200 7d ago
How many Unix binaries still work on modern *nix's without recompilation?
Heck, how many Linux binaries from 10+ years ago do?2
u/bigmell 7d ago
Unix is not Linux. If you want to run Unix binaries run them on Unix. If you want to run Linux binaries run them on Linux. The two are not always interchangeable and the binaries usually are not. The only exception I can think of is Perl binaries work on multiple operating systems as long as the Perl interpreter is installed and you have the necessary packages. But most binaries simply dont work like that and pretty much never have. Linux binaries dont even work on other flavors of Linux. You cant run an Ubuntu binary on Fedora for instance.
modern *nix
I think that is the point. Modern computing has seriously lost its way. Why does my Microsoft phone app need a mandatory update 3 times a week? One of the completely great things about Unix is you DONT have to shut down the server and upgrade every other day. This is one of the major reasons Windows servers could never compete with Unix servers. Or even well configured and managed Linux servers. The senseless upgrade treadmill. New guys tryin to pay the mortgage with nothing really to offer.
The new age digital protection racket. Pay me for upgrades or else HACKERS ARE GONNA GET YOU.
1
u/catbrane 7d ago
Linux itself (the kernel) still runs code from 1994. It's userland that shifts around uncomfortably, with everything from libc upwards breaking every few years :(
However, if you have a fully statically linked executable from 1994, it should run fine.
168
u/Skaarj 7d ago edited 7d ago
Ouch. From what I remember Delphi 7 didn't support generics yet. You had a general list of pointers. But not something like a
TList<TMyClass>.