Best VB6 decompiler?

Why would you want to take apart someone's program? Seems rude and of questionable ethics.
 
Why would you want to take apart someone's program? Seems rude and of questionable ethics.

It is a program from one of our other sites. They don't have the source code and it will not run on a system with any Office newer than 2010. I have to redo it to make it work with Office 2016.
 
I have never been able to get any of those kinds of decompilers to work very well. They all have some sort of limitation that makes them more trouble than they are worth.

If they dont have source code, just re-write it and let it be a lesson to the company.
 
I have never been able to get any of those kinds of decompilers to work very well. They all have some sort of limitation that makes them more trouble than they are worth.

If they dont have source code, just re-write it and let it be a lesson to the company.

Yeah, I know it won't be able to get all the code, but it will at least give me the forms, all text, and most of the logic for the program.

I am more interested in the logic so I don't have to spend who knows how much time testing out the program to figure out exactly how everything works.
 
I asked this same question a while back, so hopefully this thread helps... https://hardforum.com/threads/vb6-dll-viewer.1233951/

Edit:
This thread got me thinking more about this topic and any changes since my thread from 9 years ago. At my company, we have a handful of VB6 applications that are being re-written, but we do not have source. (Another sin of the past that we are dealing with, but I digress.) This SO link gave some decent options for viewing the native code if necessary (e.g. evaluate a user assertion about the product's behavior, or see what queries are being executed and how).
 
Last edited:
The problem with decompilers is you're only getting a close approximation of the original code.

For basic troubleshooting of a binary, that's fine.

For recompilation? Yeah. Be prepared for some pain...
 
The problem with decompilers is you're only getting a close approximation of the original code.

For basic troubleshooting of a binary, that's fine.

For recompilation? Yeah. Be prepared for some pain...

I don't expect any semblance of code that can recompile. It's a small program so not worried about that one bit.
 
So what're you trying to do? Build a wrapper for the old link so it'll talk to the wrapper and the wrapper will talk to newer Office?
 
So what're you trying to do? Build a wrapper for the old link so it'll talk to the wrapper and the wrapper will talk to newer Office?

No, I have to rewrite the program in VB.NET. It is a frontend for data entry / report generation/viewing for an Access DB which I already converted to 2007+ format. So the old interface is not only looking for an old file name, but also will not work with the new format.

I guess I could make an intermediary program, but that would mean that it would probably stop working at some point in the future anyway and make stuff more complicated than it needs to be. Plus a lot of the older VB to Access DB calls are deprecated and will not work at all anymore as I found out last time I had to convert a VB6 program to VB.NET for a different site. We had the original source code for that though so it was pretty easy to change over.
 
Ok, so I got approved to get VB Decompiler.

10.6 is the newest version.. and it is pretty sweet.

Full form recovery and the native code decompilation is very useful.

I will have to look up some stuff, but the output is pretty easy to follow from what I have looked at so far.

They have added a pretty big increase in the decompiing functionality in the last few versions and I am actually impressed with it.
 
Access? Ugh...

Why not do a SQL conversion?

You may as well be using dBase.
 
Access? Ugh...

Why not do a SQL conversion?

You may as well be using dBase.

The db is very small and Access works just fine for this.

The db itself has a front end as well. So instead of redoing one front end, I would have to redo 2 front ends.

No, it is definitely not the best setup, but the newest version was made 15 years ago and all I need to do is get it working properly with Access 2016.
 
*SHUDDER*

HEHEHE. You should have seen the VB6 / Access program I had to work on that used a .doc file to hold most of the configuration info. Whoever coded it like that wanted to make sure that they were the only person that was able to maintain it.

1. Get it to recompile in VS 2013... had to change a decent amount of code because of deprecated functions.

2. Hunt down all the hard coded file locations and change them to be able to be changed with a simple .ini file change.
 
No thanks. I'd rather remove all my teeth, with a chainsaw, myself, via rectal access.
 
No thanks. I'd rather remove all my teeth, with a chainsaw, myself, via rectal access.

Heh.

Well, I got all the forms recovered.

1. Decompile with VB Decompiler and save project.
2. Load project into VB6 and comment out all code so it will compile.
3. Convert to .NET with VS2008
4. Open with VS2015 and convert project
5. Find that it needs VB Powerpacks.
6. Download and install VB Powerpacks and add the reference to it.

So now I just have to redo all the backend coding.
 
Nice progress so far, glad things are working for you!

If you are still using MS Office interops in your code stack, you may want to look into the NetOffice DLLs. They act as a bridge between your Interop/PIA calls and the actual installed version of MS Office, but without the version-specific requirement of Office DLLs -- it will simply work with any version of Office installed on the destination machine. We've been using it for some internal Excel and PowerPoint interaction at my company, and the switch was painless.
 
Nice progress so far, glad things are working for you!

If you are still using MS Office interops in your code stack, you may want to look into the NetOffice DLLs. They act as a bridge between your Interop/PIA calls and the actual installed version of MS Office, but without the version-specific requirement of Office DLLs -- it will simply work with any version of Office installed on the destination machine. We've been using it for some internal Excel and PowerPoint interaction at my company, and the switch was painless.

Thanks for the tip. I'll take a closer look at them once I get that far.
 
So... after fighting with VB to save the updates to the DB for a few hours yesterday... no errors, it just acted like it was saving and then when I loaded it back up, the old data was there.

Read a huge number of posts, ideas, and anything I could find on it. Tried a few different ways and nope, nada, nothing.

Come to find out, it doesn't save the data to the real db you are accessing when you run it via Visual Studio, but to a copy of the db it puts in the bin folder with the executable.

Maybe just a configuration issue/misunderstanding on my part.

Overall though, VB.NET in VS2015 rocks for doing DB front ends. Once you figure it out, it is pretty sweet as it does pretty much all of the hard work for you.
 
Come to find out, it doesn't save the data to the real db you are accessing when you run it via Visual Studio, but to a copy of the db it puts in the bin folder with the executable
This sounds like the Access DB is being copied to the "bin/[dev|release]" directory during the debug/run/F5 process, and that the copied DB file is the file being interacted with. If so, take a look at your "Copy to output directory" setting for the DB file. (This SO link gives specifics.)
 
Back
Top