current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 44 down vote favorite
2

In our company we have a small program (.exe 500Kb size) that does mathematical calculation and in the end it spits out the result on a Excel spreadsheet that we use to continue our workflow.

I want to modify the columns, spacing format and add VBA logic etc. on the Excel spreadsheet but since this parameters are not configurable in that program, it seems to me the only way to modify it is to break down/reverse engineer the .exe

Nobody knows in what language it was programmed in, the only thing we know is:

  1. Developed 20+ years ago
  2. Developer retired 10 years ago
  3. GUI Application
  4. Runs standalone
  5. Size 500Kb

Any suggestions what options I have to deal with such kind of problems? Is reverse engineering the only option, or is there a better approach?

share|improve this question
75  
Do you know what the calculation is that it performs? If so, write a new app, push some test data through both to check the new one works the same, then throw away the old one. Then make the changes you want to make. – David Arno 2 days ago
4  
@DavidArno 's comment would make a good answer. Reverse engineering is possible, but re-spec'ing and rewriting the app will be a lot cheaper/easier/quicker. – Dan Pichelman 2 days ago
13  
The other way to modify it would be to take the result the original program produces and filter it into whatever you want. – Blrfl 2 days ago
4  
@Alec if you open the .exe with a hex editor, you may get clues about what it was written in. For example, the compiler name might be embedded. From there you'll know more about possible decompiling options. – GrandmasterB yesterday
5  
Alternatively, you could attempt to find the gentleman who wrote the application and see if he's willing to come in for a day or two (maybe a couple of hours each day) as a consultant. If he's a retired developer, there's a moderate chance that he might appreciate a little spending money at the rate of $100-150/hr while actually enjoying the moment of doing a bit of work for just a brief period if time. – RLH yesterday
up vote 112 down vote

Reverse engineering can become very hard, even more if you do not just want to understand the program's logic, but change and recompile it. So first thing I would try is to look for a different solution.

I want to modify the columns, spacing format and add VBA logic etc. on the Excel spreadsheet

If that is the only thing you want, and the calculation done by the program is fine, why not write a program in the language of your choice (maybe an Excel macro) which calls your legacy "exe", takes the output and processes it further.

share|improve this answer
4  
Thank you for the tip, that actually might work! – Alec 2 days ago
1  
Why does the new program have to call the old EXE? Why not just make the new program independent and then write a script that calls both and coordinates the output and input? My experience suggests that letting command line languages like bash, PowerShell, or command prompt handle process coordinate is generally simpler than trying to code it yourself in an imperative language. Otherwise, +1. – jpmc26 yesterday
3  
@jpmc26: That's true right up until you have to deal with Bash's absurd quoting rules. Yes, they are (mostly) POSIX-compliant. No, they do not make any goddamned sense. $FOO should not word split, for example. – Kevin yesterday
    
@Kevin I'd rather deal with occasional award quoting rules than with the mess I've seen trying to make an imperative language sit and wait for a program it launched to complete and then trying to use its output (especially if it goes over stdout or stderr). Shell languages were designed to solve the latter problems, and they do so fairly elegantly. I've always found this more difficult and that it requires much more knowledge about the system in imperative languages, but maybe it's just me. – jpmc26 yesterday
4  
@jpmc26: I've never had any trouble calling subprocess.run(), personally. – Kevin yesterday
up vote 56 down vote

In addition to the already given answers by Doc Brown and Telastyn, I would like to suggest an alternative approach (under the assumption it's mission critical).

If you do not know the computations it performs and the calculations are (somewhat) mission-critical: Deduce the original logic in the .exe file by any means necessary. Decode it using a decompiler/disassembler like IDA if necessary. Hire a consultant (or a batch of consultants) if necessary.

Sure, work around it for now using their solution, but do not let it be.

The reason I suggest is as follows: You have admitted that the calculations are very complex (according to an engineer you spoke to). It's also mission-critical. So if somehow the original .exe stops working due to changes in the platforms you have (maybe 16-bit support gets dropped?), you have just lost a mission-critical piece of knowledge.

Now, I'm not concerned about losing the .exe, but about losing the knowledge it encodes. That knowledge must be recovered.

As before: if that knowledge is already available, make sure to write it down in a format that it's not going to be lost anytime soon. Otherwise, recover it and write it down.

share|improve this answer
7  
Modern decompilers actually produce code that's usually quite legible, especially if the original source was in plain C or assembler, and not a higher level language. – phyrfox yesterday
2  
Very good point. Also: Just patching it up so that it works again will only work until the next fix needs to be implemented. – Daniel Jour yesterday
9  
@phyrfox 20 years old... developer retired 10 years ago... only output is an Excel spreadsheet... I'd put money on it being a VB6 application. – J... yesterday
4  
@micaho: or the company still exists and the person with the know-how to verify the results and hidden assumptions has just been hit by a truck. Of course, it's a business risk so ultimately the stakeholders should decide. I just wanted to emphasise that the "wrapper" will work now, but only adds to the technical debt. – Sjoerd Job Postmus yesterday
3  
@J...: If it is VB6 then the original poster is in luck. You can recover the source code from a VB6 compilation pretty easily. – Eric Lippert yesterday
up vote 29 down vote

Any suggestions what options I have to deal with such kind of problems?

If all you're looking to do is modify the output, then why not simply use composition?

Instead of modifying the black box you can't easily access, you create a new program that takes the Excel output, and does your formatting/column changes too. Then you could make a new exe/script that calls the two programs in order, so it appears to the end user that there is just one program that does all of the work - even though it's two distinct steps under the hood.

share|improve this answer
2  
@Alec Whether java is a suitable language or not mainly depends on the amount of data you need to handle / the amount of computation that you need to do. If both are low, java is fine. If either one is critical, you better drop down to C or C++. But since you seem only to be using an amount of data that fits into an Excel spreadsheet anyway, I don't think there's enough data involved to make java a bad choice (Excel would likely explode before your app does). – cmaster 2 days ago
11  
@cmaster the idea that Java is prohibitive for heavy computation is an outdated notion. The worst benchmark listed here isn't even 4x (most are 2x or less) and if a single digit scalar is your breaking point, the savings in safety (which translate directly to developer dollars) is more than likely going to offset the performance hit. – corsiKa yesterday
3  
@Alec any language will work. VBA seems a good choice because it already integrates with Excel so well. – Captain Man yesterday
4  
@corsiKa That depends entirely on the scale of your application. If a single run consumes several tens of thousands CPU-hours, a factor of 2 or 4 becomes prohibitive: It translates directly into the amount of results that you can get out of a multi-million machine. Also, such applications typically work in lockstep, so garbage collection is pure poison for their performance, the small interruptions would multiply by the number of processes. I tell you, such applications exist, and they are most certainly not written in Java. They are just not used by the average internet business. – cmaster yesterday
4  
@cmaster We're talking about some simple calculations , not a full blown AAA game engine with realtime global illumination, physically based rendering, animated sparce voxel octrees, universal physics field simulation and the like. No offense, but inserting any argument RE performance here is bad. Ease of use should be #1, and as someone who's been using C++ for a few years it's the last language I would recommend in this case. – Technik Empire yesterday
up vote 24 down vote

Ask the original programmer, if possible.

A few weeks ago i've been contacted by a firm I used to work for 10 years ago with the very same question about an mdb file developed mid 90s.

share|improve this answer
21  
This is the real low hanging fruit. Everyone (including myself) romanticizes the use of hard programming skills like reverse engineering, reimplementing the program's functionality or adding layers to the data processing. In reality, the best place to start is a friendly email which might come back in an hour with the location of the source code or some other ideal solution. – user1717828 yesterday
1  
When at home with a 10 years old application me too I fire up a disassembler but during work hours the goal is different ^^ – Paolo yesterday
    
Did you remember anything about it? :) – Ángel yesterday
1  
of course! unfortunately the company undergo 3 acquisition & merge so lots of information got lost and part of the backups was in the lost bag... the development was on site on their machines so I have no copy of the source and that's it. – Paolo yesterday
up vote 0 down vote

Try to reverse engineer the exe. Only for the purpose of finding the computation logic or at-least to get a fair hint of what it actually does and if your reverse engineering can get you to that point, you can write new application based on that computation logic. Apart from that, I don't see other wayout.

Easier said than done, reverse engineer an exe created 20 years back is real challenge.

share|improve this answer
6  
The dating of the exe shouldn't really matter – Ángel yesterday

protected by gnat yesterday

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.