Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.


Vraag & Antwoord


.exe naar .cpp compiler

5 antwoorden
  • Bestaat er een compiler die .exe naar .cpp omzet of iets dergelijks, ik heb me laten vertellen dat ie bestaat maar betwijfel et
  • Er bestaan (bestonden) programma's die .exe omzette naar .asm en als dat kan dan is wat jij zoekt ook mogelijk. Wat ik bedoel was overigens in de tijd dat Dos regeerde.
  • Dat is een disassembler, hoewel je daarmee wel assembler kunt verkrijgen is C vrijwel onmogelijk, je kunt zelf wel de assemblercode lezen, de stappen proberen te achterhalen en een C programma schrijven die dezelfde functies verricht, maar er weer een C programma van maken is bij mijn weten onmogelijk.

    Wat wel kan is sommige programma's waar veel debug informatie in zit de broncode achterhalen. Bijvoorbeeld met Turbo Profiler onder DOS (zolang gebruik ik al geen MS meer;) ) kon je mits je gecompileerd had met de juiste debug opties de broncode ook gewoon in Profiler (/Debugger zijn) AFAIR.
  • Ik heb daar ooit eens iets over gevonden:

    Is there any hope of a decompiler that would convert an executable
    program into C/C++ code?

    This FAQ answer is an excerpt from SNIPPETS by Bob Stout.

    Don't hold your breath. Think about it… For a decompiler to work
    properly, either 1) every compiler would have to generate substantially
    identical code, even with full optimization turned on, or 2) it would
    have to recognize the individual output of every compiler's code

    If the first case were to be correct, there would be no more need for
    compiler benchmarks since every one would work the same. For the second
    case to be true would require in immensely complex program that had to
    change with every new compiler release.

    OK, so what about specific decompilers for specific compilers - say a
    decompiler designed to only work on code generated by, say, BC++ 4.5?
    This gets us right back to the optimization issue. Code written for
    clarity and understandability is often inefficient. Code written for
    maximum performance (speed or size) is often cryptic (at best!) Add to
    this the fact that all modern compilers have a multitude of optimization
    switches to control which optimization techniques to enable and which to
    avoid. The bottom line is that, for a reasonably large, complex source
    module, you can get the compiler to produce a number of different object
    modules simply by changing your optimization switches, so your
    decompiler will also have to be a deoptimizer which can automagically
    recognize which optimization strategies were enabled at compile time.

    OK, let's simplify further and specify that you only want to support one
    specific compiler and you want to decompile to the most logical source
    code without trying to interpret the optimization. What then? A good
    optimizer can and will substantially rewrite the internals of your code,
    so what you get out of your decompiler will be, not only cryptic, but in
    many cases, riddled with goto statements and other no-no's of good
    coding practice. At this point, you have decompiled source, but what
    good is it?

    Also note carefully my reference to source modules. One characteristic
    of C is that it becomes largely unreadable unless broken into easily
    maintainable source modules (.C files). How will the decompiler deal
    with that? It could either try to decompile the whole program into some
    mammoth main() function, losing all modularity, or it could try to place
    each called function into its own file. The first way would generate
    unusable chaos and the second would run into problems where the original
    source hade files with multiple functions using static data and/or one
    or more functions calling one or more static functions. A decompiler
    could make static data and/or functions global but only at the expense
    or readability (which would already be unacceptable).

    Finally, remember that commercial applications often code the most
    difficult or time-critical functions in assembler which could prove
    almost impossible to decompile into a C equivalent.

    Like I said, don't hold your breath. As technology improves to where
    decompilers may become more feasible, optimizers and languages (C++, for
    example, would be a significantly tougher language to decompile than C)
    also conspire to make them less likely.

    For years Unix applications have been distributed in shrouded source
    form (machine but not human readable – all comments and whitespace
    removed, variables names all in the form OOIIOIOI, etc.), which has been
    a quite adequate means of protecting the author's rights. It's very
    unlikely that decompiler output would even be as readable as shrouded
  • Ze zeggen van dat alles kan in de computerwereld behalve het "kraken" van broncode, maar dat is dus eigenlijk niet waar… want er zijn misschien heus wel knappe koppe zijn die assembly taal omzetten in echte C++ taal ofzow… alleen daar ben je erg lang mee bezig

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.