Just for grins, let's sum this up.
It is impossible to decompile and .exe file and come up with the original C or C++ code that created it. The problem is that a lot of language sematics is lost in reducing the source to binary. Take, for instance, the first pass of the compile - the C preprocessor. Among other things, it strips comments, changes macro calls into their definitions, and drops the include file contents right into it's output in place of the include statemnents, so all preprocessor information is lost. And that's just the first step.
It is possible to de-assemble binary back into a pseudo-assembly code. Experienced programmers (experienced in C++ and in assembly, and who have taken the time to look at their own code de-assembled) can use this to make guesses about the C code that created the assembly. There are usually better ways to use that person's time, though.
As someone mentioned above, a lot of the newer libraries and frameworks are leaving information lying around in the binary, for many reasons. Since de-compiling a program is the pot-at-the-end-of-the-rainbow for the cracking community, this may well serve as a warning to the paranoid.
It has been rumored that MS does indeed have at least a fair de-compiling technology, but for obvious reasons keeps it for in-house use only. Conspiracy theories abound, but then again, that's just plain paranoid - the question is, is it paranoid enough?
If you really want to get into this in a big way, then you need to take up digital electronics, I/O and interrupt programming and assembly level programming, on all the machines you want to target - essentially learn the cracker's game. Wouldn't hurt to learn some law about Copyright infringement and what lawyers mean by the word de-engineering in those shrink-wrapped licenses, not to speak of what the latest copyright laws do for tooling intended to crack, even if not used for that purpose. Be very careful.