How much software is still built on decades-old Delphi code?
Asked by
MellowKite47
I recently saw an EOleSysError dialog on a Windows 11 machine and wondered whether the application was written in Delphi. It made me think about how much everyday enterprise and desktop software still relies on code that may be 20–30 years old. Modern interfaces can hide very old foundations, but error names such as EAccessViolation and EOleSysError sometimes seem to reveal them. How common is Delphi in production software today? Are those exception names a dependable clue, and are people still developing new applications in Delphi in 2026?
Answers
Yes, there is still a substantial amount of Delphi in business software, especially applications that have been reliable for years and are expensive or risky to replace. Delphi 7 and Delphi 2007 systems in particular can remain in service for decades. Some companies still maintain and extend them, although recruiting developers and upgrading old code can be difficult.
Reply to this answer
The same pattern exists far beyond Delphi. Businesses still depend on Visual FoxPro, XBase, COBOL, mainframes, AS/400 systems, and old Visual Basic front ends. If the software is dependable and replacement would be expensive, organizations often keep it running while gradually adding newer layers around it.
Reply to this answer
Delphi is definitely still used for new development, though it is much more niche than C# or Java. Examples of actively maintained Delphi software include Inno Setup, Total Commander, Beyond Compare, HeidiSQL, FastReport, The Bat!, and Delphi itself. There is also a continuing commercial ecosystem and regular compiler releases.
Reply to this answer
Later Delphi versions added 64-bit, mobile, and cross-platform support, but upgrading older projects was not always straightforward. Changes such as the move from ANSI to Unicode strings could break code that treated strings as raw byte arrays. That compatibility cost is one reason older Delphi applications continue to be maintained instead of modernized.
Reply to this answer
Those exception names are a strong hint, but not absolute proof. EAccessViolation and EOleSysError are Delphi-style exception classes, though similar errors can appear around COM or OLE components used by other languages. You would need to inspect the executable, symbols, dependencies, or runtime behavior to identify the toolchain with confidence.
Reply to this answer
Add your answer
Answers are reviewed before publication.
SilverMango5: EOleSysError is especially suggestive because it is a standard Delphi exception name, but the underlying Windows or COM error could still be surfaced by a different application.