I recently saw an EOleSysError dialog on a Windows 11 machine and wondered whether the application was built with Delphi. It made me curious how much software people still use every day is based on code that may be 20 or 30 years old. Modern applications can hide their age until an old exception name, legacy executable convention, or unusual error dialog appears. For people who have worked in enterprise or Windows desktop development: how common is Delphi in 2026, are names such as EAccessViolation and EOleSysError a dependable clue, and are companies still writing new software in Delphi today?
4 Answers
Legacy software is not limited to Delphi. Businesses still run systems built with COBOL, Visual FoxPro, xBase, old Visual Basic, mainframe tools, and AS/400 technologies. If a system works, is understood well enough to operate, and would be costly to replace, organizations often keep it running for decades. There are also plenty of well-known Delphi applications and tools still in active use, including Inno Setup, Total Commander, Beyond Compare, HeidiSQL, FileZilla, Resource Hacker, and The Bat!.
There is still quite a bit of Delphi in long-lived business software, especially desktop and enterprise applications. One example I have seen was a large financial product with roughly 1.4 million lines of Delphi that had been upgraded over the years. Other organizations still maintain Delphi 2007 or Delphi 7 systems because they are reliable and replacing them would be expensive and risky.
Yes, new Delphi development still happens, although it is much more niche than C# or JavaScript. Some companies maintain older systems while adding new features, and Embarcadero continues to release Delphi versions. The biggest practical problems are finding developers and dealing with compatibility changes, especially the move from older ANSI string assumptions to Unicode and newer platform support.
Those exception names are a strong hint that Delphi might be involved, but they are not conclusive proof. EAccessViolation and EOleSysError are standard Delphi exception classes, while OLE or COM errors can also surface through other layers. Looking at the executable, debugging symbols, imported runtime libraries, resources, or compiler-specific metadata would provide better evidence than an error message alone.
The names themselves are particularly associated with Delphi, but a wrapper, component library, or manually written code could reproduce similar wording. It is best treated as a clue rather than a fingerprint.
Older Delphi versions stayed popular because they were productive and could produce fast native Windows applications. Moving to a newer compiler is not always a simple rebuild when the original code treats strings like byte arrays.