I look at old .exe files for a living. Here's how I tell what they're built with in 2 minutes

Jaime Moreno — Mon, 26 Oct 2026 10:07:10 +0000

Almost every legacy project I look at starts with the same question, and it is never "what language is this written in?". It is quieter and more urgent:

"Somebody left, nobody has the source code, and all we have is this .exe. Can we do anything with it?"

The good news: you can usually answer that in a couple of minutes, without running the program. A Windows executable leaves fingerprints everywhere. You just need to know where to look.

The fingerprints

A Windows .exe is a PE file. Its header, its import table and the files sitting next to it tell you most of the story:

If you see...	It is probably...
A CLR header and an import of `mscoree.dll`	.NET (WinForms apps also reference `System.Windows.Forms`)
`msvbvm60.dll` (or `msvbvm50.dll`)	Visual Basic 6 / 5, often with `.ocx` controls in the folder
`borlndmm.dll`, `.bpl` packages, Borland or Embarcadero strings	Delphi / C++Builder
`vfp6r.dll`, `vfp8r.dll`, `vfp9r.dll` and folders full of `.dbf` tables	Visual FoxPro
`pbvm*.dll` and `.pbd` libraries	PowerBuilder
A `.jar`, or a launcher that loads `jvm.dll`	Java
`python3x.dll` or PyInstaller markers	Packaged Python

Two more things worth a glance: section names that give away a packer (UPX0, .aspack, .themida, .vmp0), and the Details tab in the file properties (product name, version, copyright, date).

Do it yourself in four steps

Look at the folder. The DLLs and OCXs next to the program say a lot.
Open Properties, then Details. Product, version and date tell you who compiled it and when.
Use a local analyser. Tools like Detect It Easy show the compiler, the imports and any packer.
Never run what you do not know. Identifying the technology only needs reading the file.

Or skip the manual work

I got tired of doing this by hand, so I built a free tool that does it in the browser. You drop the file, it reads the headers and tells you the technology and how recoverable the code probably is. The file never leaves your machine, everything runs locally:

Browser version: https://www.stellariscode.com/en/free-exe-analyzer
Command line version (zero dependencies, MIT) to inventory whole folders: https://github.com/morexulo/legacy-scan

What the result actually means

This is the part that matters when the code is gone:

.NET or Java: usually high. They keep almost all their structure when compiled (classes, methods, queries). You lose comments and some local names. Obfuscation makes it harder, but rarely impossible.
VB6, Delphi, FoxPro, PowerBuilder: medium. Forms, resources and part of the logic come back. The rest is rebuilt from analysis, behaviour and the database.
Native C/C++, Go, protected binaries: low. You can study the behaviour, but the original code does not come back. The logic is rebuilt from analysis and from the data.

"Recoverable" never means "identical to the original". It means the business rules can be reconstructed and tested against the real application.

Gotchas

A launcher can hide the real app. An .exe that loads jvm.dll is just a wrapper: go find the .jar.
Installers are not the app. If you see Inno Setup or NSIS, install it first and analyse what it leaves behind.
It is a heuristic. It is right with the common stacks and can be wrong with unusual ones, packed binaries especially.
Mind the legal side. Only analyse software you own or have the right to analyse. Recovering or modifying code depends on ownership and licensing.

Your turn

Which old stack is still alive where you work? I am collecting real cases, and misdetections are especially welcome: open an issue on the repo with what the tool said and what it really was (no third-party binaries, please).

DEV Community: Jaime Moreno

[Boost]