Comment by dzdt
9 years ago
I once worked at a place which lost part of the source code for their giant mission-defining application. They spent a decade linking in object code for which there was no corresponding source code.
The build team was very proud when they announced that the application would finally start being built from the source code in version control.
Stuff happens!
Stuff happens, indeed, and more often than most of us realise.
Getting on for a decade ago now I was working at Red Gate when they bought .NET Reflector - a decompiler for .NET code - from Lutz Roeder. After the acquisition we started asking people what they were using it for.
Turns out a significant minority of them were trying to recover lost source code, or source code they never had in the first place (e.g., where a supplier went out of business). I don't remember the exact figure but it might even have run into low double-digit percentages. Bear in mind this is a tool that was being downloaded tens of thousands of times every month by all manner of people working for all kinds of organisations of every size and you can see the scale of the problem.
There were a couple of Reflector add-ins that would allow you to take a .NET binary and generate a C# or VB.NET Visual Studio project with all source code from it. The source code was never perfect and wouldn't likely compile first time, but it was certainly better than starting from scratch. Not surprisingly these add-ins were among the most popular.
Granted, times have changed, and I think source control is probably the default for almost everyone these days - although I would have expected that even in 2008 - but, bottom line: I think this sort of thing happens a lot, for one reason or another.
Heh can say I know some guys who have done this, and I myself have done this (and with similar but open source tools) there's also the "what is this sketchy .NET app really doing" moment where you want to know it's not doing anything "funny" to your system and you peek at the code.
I've done a significant amount of work with decompiling and rebuilding executables of crazy levels of complexity. It's definitely time consuming -- but not as bad as you'd think. Maybe 1-4 weeks with a dedicated team working through it and testing functionality. Definitely a viable solution if you've lost source code.
Yeah we used ILSpy for exactly this reason - a vendor went out of business and our client needed patches REAL QUICK.
A friend once told me a story about a software company that had offices in the World Trade Center in New York. Their offices were totally destroyed by 9/11; thankfully, all the staff got out alive, but it turned out they didn't have offsite backups of the source code repository, and it was lost completely. They found various bits of the source code floating around (e.g. some developers had bits of it on their home computers), but there were a few key components they could not locate any source for. Well, the customers still had the compiled binaries, so they got the binaries back from the customers, extracted the missing bits, ran them through a decompiler, and checked the result into the source code repository – since the application was written in Java, this actually worked quite well. Years later, new developers would find bits of obviously decompiled code still in the source repo (you can tell, it has a distinct look to it, e.g. variable names with numbers in them), and scratch their heads, and then get told the tale.
Stuff may happen but I would put replacing the module I lost to the source code to pretty high on the list of things that need fixing.
There is no way I could rely on something like that.
Am I the only one that thinks relying on something that has no source code is just asking for trouble and headaches in the future?
Then there is the situation where, one day, your source code control system tells you there are no files .... because someone in the org you are working at figured noone was using the server and wiped it. This really happened on a job I was on. Luckily we still had source dotted around a dozen or so machines, at various levels of up-to-datedness, so it was possible (with a load of scripting code generating some helpful timeline pix) to forensically reconstruct not just the tip but a decent portion of the history too. Fun times.
No, you're not the only one. But, at the same time, it isn't always the absolute top priority. Right now I'm working on a couple of systems that have had a few mystery DLLs in them. Not necessarily anything lacking source code - it's around "somewhere" - but certainly things we've lacked the immediate capability to rebuild.
But those DLLs aren't the only, or the biggest, problems with the systems. Hence finding the source and building them from it isn't necessarily the top priority, although we are progressively doing exactly this.
> They spent a decade linking in object code for which there was no corresponding source code.
How would you go an entire decade without noticing this?
Wouldn't you have to use that missing source code for something within ten years?
I only know details at the level of war story, secondhand. I may have overstated a bit. For sure there was a build process relinking in old object code for many years which no one knew how to reproduce. Possibly there was still associated source code, but the object bits had been declared "golden" and no one knew exactly what source version or build process had produced those "golden" bits.
I've had something similar before at a prior employer caused by bad linking of some C# to some C++. Someone thought it was a good idea to P/Invoke directly the mangled names. Needless to say that changed once I was finally able to get my hands on the source.
Oh, undoubtedly it was noticed, but an enterprise software company has a tremendous capacity to procrastinate on fixing things.
Likely the source was used to build an object library which then got linked in to form the executable. If the library Just Worked, there would be no reason to rebuild it.