home *** CD-ROM | disk | FTP | other *** search
/ POINT Software Programming / PPROG1.ISO / c / snippets / decompil.txt < prev    next >
Text File  |  1995-03-13  |  3KB  |  49 lines
  1. Question:
  2.  
  3.   Is there any hope of a decompiler that would convert an executable program
  4. into C/C++ code?
  5.  
  6. Answer:
  7.  
  8.   Don't hold your breath. Think about it... For a decompiler to work
  9. properly, either 1) every compiler would have to generate substantially
  10. identical code, even with full optimization turned on, or 2) it would have to
  11. recognize the indivdual output of every compiler's code generator.
  12.  
  13.   If the first case were to be correct, there would be no more need for
  14. compiler benchmarks since every one would work the same. For the second case
  15. to be true would require in immensely complex program that had to change with
  16. every new compiler release.
  17.  
  18.   OK, so what about specific decompilers for specific compilers - say a
  19. decompiler designed to only work on code generated by, say, BC++ 3.1? This
  20. gets us right back to the optimization issue. Code written for clarity and
  21. understandability is often inefficient. Code written for maximum performance
  22. (speed or size) is often cryptic (at best!) Add to this the fact that all
  23. modern compilers have a multitude of optimization switches to control which
  24. optimization techniques to enable and which to avoid. The bottom line is
  25. that, for a reasonably large, complex source module, you can get the compiler
  26. to produce a number of different object modules simply by changing your
  27. optimization switches, so your decompiler will also have to be a deoptimizer
  28. which can automagically recognize which optimization strategies were enabled
  29. at compile time.
  30.  
  31.   OK, let's simplify further and specify that you only want to support one
  32. specific compiler and you want to decompile to the most logical source code
  33. without trying to interpret the optimization. What then? A good optimizer can
  34. and will substantially rewrite the internals of your code, so what you get
  35. out of your decompiler will be, not only cryptic, but in many cases, riddled
  36. with goto statements and other no-no's of good coding practice. At this
  37. point, you have decompiled source, but what good is it?
  38.  
  39.   Like I said, don't hold your breath. As technology improves to where
  40. decompilers may become more feasible, optimizers and languages (C++, for
  41. example, would be a significantly tougher language to decompile than C) also
  42. conspire to make them less likely.
  43.  
  44.   For years Unix applications have been distributed in shrouded source form
  45. (machine but not human readable -- all comments and whitespace removed,
  46. variables names all in the form OOIIOIOI, etc.), which has been a quite
  47. adequate means of protecting the author's rights. It's very unlikely that
  48. decompiler output would even be as readable as shrouded source.
  49.