VB6 "decompiler"

The short story is: there is no such thing.

The slightly longer story is: There never has been any such thing, there is no such thing now, and there never WILL be such a thing. Despite how much some people WANT for there to be such a thing, it isn't going to happen, so if all you care about is finding one, you can stop reading right now and go back to doing something productive such as designing yourself a daily backup regimen that will keep you from ever needing one in the first place.

Some people will say "well, yes, BUT there is the capability to disassemble the EXE file, so you CAN get back to a form of source code which can be modified. This is theortically true but has even less practical importance than does saying that you know the Egyptian pyramids are made from stone, so you should be able to recreate one any time you want.

a brief explanation:

(with apologies to folks who understand compilers and linkers and such. This simplistic explanation is intended for those who basically have no idea what is going on)

Compilers take human-readable "source" code and convert it to machine code, which is just a string of ones and zeroes in a form that the CPU recognizes and knows how to process as instructions. There is a human-readable equivalent to this string of ones and zeroes and it is called "assembly language", but assembly language has the same practical relationship to compiler languages as do stones to pyramids. Actually, that is an overly generous analogy. If you KNOW you want a pyramid, then knowing it is made of stone is an important first step in building one, but given a stone, that does NOT tell you that you can put them together to make a pyramid. So the actual analogy is more like this: assembly language has the same practical relationship to compiler languages as do stones to really large physical objects of an infinite number of sizes and shapes.

The string of ones and zeroes will vary in relationship to the original source code. Some lines of VB source code will result in only a few machine language instructions and others will results in HUNDREDS of machine language instructions. To make it all even more fun, if you see a long list of machine language instructions, there is, except in some limited cases, NO way to tell where the break point is between one set (that came from one VB line) and the next set (that came from the next VB line). This is just one of many problems in decompilation, but it is a significant one.

Complicating the executable creation process even further is the fact that, ESPECIALLY with VB, the execuatble will generally contain TONS of code that is brought in by a linker and not written by the original programmer. BUT a function call in machine language is exactly the same whether it is calling a function YOU created or one that was brought in by the linker.

In older versions of VB, the compilation process had the option of producing an intermediate "pseudo code" (aka pcode) which COULD be brought back to the original source code, at least to a reasonable degree. This fact causes some people to believe that there should be a decompiler for VB6 just because there was one for VB3. Dream on. VB6 also has a pcode option, but it does NOT have the same characteristics as previous versions and I have been told reliably (although I've not explored it myself) that it is no more decompilable than is native code ("native code" is another name for the ones and zeroes).

The ones and zeroes of an EXE file DO contain all of the relevant information from the original source code. This doesn't include variable names and a lot of the other stuff that we humans take for granted at design time, but it DOES have all of the needed information. How could it not? If it did not, then it would not do what the program was designed to do. Nonetheless, getting from the ones and zeroes back to the VB source code is, for all practical purposes, impossible. I say "for all practical purposes" because it is not theoretically impossible to get back to a compilable version (NOT the one you started with but one that is functionally equivalent). I say again, it is not theoretically impossible to build a new pyramid, since you know it is made from stone and you know what shape it has to be, but getting a program in assembly language back into a compilable version has AT LEAST as much difficulty as being given a HUGE pile of stones and then being told to build a really large object out of it, and then happening to end up with a pyramid of some exact size and shape. It just isn't going to happen, no matter how much you want it to.