[Info-vax] Reverse-Engineering for Lost Source Code (was: Re: 1 year.)

[Stephen Hoffman]

On 2015-08-06 15:53:37 +0000, IanD said:

> Can anyone help provide guidance on how / who, to contact so that one 
> can 'function rip' an application that was developed with corba / c++ I 
> believe many years ago and work out a way to develop a new solution on 
> VMS when the source code is, shall we say, somewhat hard to acquire?
> Solve this issue and VMS will remain in the workplace, otherwise it's 
> pending doom is already here :-(

While you might like VMS, this certainly appears to a dead-end 
near-end-of-life application based on your comments, and it's either 
going to get reversed and ported, or — more likely — it'll eventually 
and incrementally be replaced on a different platform, or very much 
more likely it'll be discontinued after the remaining contractual 
and/or financial justifications expire.

Usual approach here would have been binary translation, but that was 
apparently nixed.  Which usually means that one or more prerequisite 
products are unavailable, or the code was otherwise untranslatable 
<http://labs.hoffmanlabs.com/node/641>.  Quite possibly CORBA itself, 
though I've not confirmed that — the associated ObjectBroker product 
was apparently sold off to BEA, and that's now all at Oracle, and I 
don't see very much published on ObjectBroker and CORBA now.

As for reverse-engineering, I'm not aware of any publicly-available 
tools akin to Hopper, Snowman or Capstone Engine for OpenVMS, either.  
There are no publicly-available modern disassemblers, and that will 
produce something approaching C code from a binary.

There are some publicly-available tools — srm_check — that'll produce 
Alpha assembler, but then you're left with assembler.

Or maybe you extend Capstone Engine, or work with somebody else that 
can extend it to OpenVMS Alpha on your behalf?  Or see if somebody has 
some privately-available reverse-engineering tools?

Disassembly and reverse-engineering in general tends to be expensive, 
and will usually produce code that's usually not particularly 
maintainable.

With any of these tools, this expenditure produces OpenVMS code that's 
(still) using CORBA, and that's not exactly a platform seeing a whole 
lot of usage.   (See <http://queue.acm.org/detail.cfm?id=1142044>, but 
I digress.)

The other approach that's used here is an incremental migration or 
incremental replacement, and that maps the functions and incrementally 
rewrites features or hunks of the environment, and preferably targeting 
a platform and language and tools that can be supported in your 
environment.  I know of various OpenVMS sites that are pursuing this 
approach; incremental ports.

Given the drag-on-profits and lost-source-code environment that you've 
described, this old Alpha configuration will likely continue to rattle 
along near the bottom of the corporate priority and funding list, 
possibly getting transferred to Alpha emulation, at least until the 
project is spun off, sold off, or killed.  Or — unlikely, but still 
theoretically possible — ported or rewritten.

Then there are the discussions of how second-guessing management 
priorities and funding usually work out for the employees involved, and 
the usual discussions around the life and business cycles of products 
and applications and sometimes careers, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC